软件测试员比软件开发员要求低些吗？
水平差的开发人员，其绩效是负的，意即不但自己没有产出，还需要耗费其他人的时间帮他解决问题。意即为了解决他写的代码相关的问题会拖慢整个团队的进度。
但是水平再低的测试人员也不会出现负绩效。最多是没绩效而已。所以从leader的角度，如果没把握这个人能达到开发的门槛，去做测试是个更稳妥的选择。
至于这个“现实”是不是合理，这种“现实”是否需要改进，那么就请参见其他人的回答了，因为我觉得吧，现有的情况，在实际操作中很难保证把优秀的测试人员留在岗位上。你给钱太多了人家赚点钱就自己去创业，给钱少了人家想办法升职，升职完了就又脱离测试岗位了。我曾经遇见过非常优秀的测试人员，但，能一直留住他吗？
测试人员创业的可能性甚至更大，因为他更了解需求层面。准确的说是测试入职时的技术门槛低。
开发入职时技术门槛高一些，但是其实也高不了多少。（就应届计算机毕业生而言）
测试往往基于业务。
比如做会计软件的，测试人员一般选择会计专业毕业的人。
测试做基于技术的测试一般比较少，因为开发组自己会review，版本组、平台组、构架组也会分别组review的。
所以，测试只是技术门槛低，对业务、沟通、逻辑等要求会高一些。
开发的技术门槛高，但是对业务、沟通相对来说要求低一些。
开发和测试是两个工种，没有对谁要求比谁低这一说的。
就像你不能说对学会计的比对学计算机的要求低一样。我不太赞同@pansz的观点
你的观点，反映了国内大多数的重视实现，不重视质量的普遍思潮。
试想一下，一个不合格的开发人员，所造成的问题，还能够在项目内部进行消化，但是一个不合格的测试人员，他没有能够及时发现的问题，却要遗留到客户面前，轻者造成客户满意度下降，重者会是灾难性的客户流失，甚至是潜在客户的流失。这样的灾难，是不是要比一个不合格的开发人员索造成的问题要大很多？
但是，国内的现状是，不太重视客户，只要赶快实现了，拿到客户的Money就OK了，很少有人去关心后继的工作。所以，在项目经理们看来，赶快出货才是关键，有一两个问题没有发现没有太大关系，他们的理由是“哪个软件还不得有一两个Bug啊”，所以他们更重视开放而轻视测试。
我并不认为对测试人员的要求比开发人员低一些，我认为反而要高一些，这就像拆炸弹，你说是安装炸弹的水平高呢还是拆卸炸弹的水平高呢？這幾天買了 Kindle 再重读 Joel on Software。Joel 很喜欢用 Big Mac 和餐飲業來類比軟件開發。所以我突然覺得這是一個很貼切的比喻。
結論就是，如果你真的非常非常非常喜歡在一個餐廳工作，廚師這個角色是你唯一要追求的。
你想做很好的老闆？那麼你祇是碰巧在一個餐廳。你可以向任何領域投資。你想做很好的 waiter？真正尊貴的客人都是由廚師接待。你想做美食家？你應該屬於媒體而不是這個餐廳。我們不要求每個人都成為廚師，但是只有一個角色屬於餐廳。
以下是原來的答案：
赢得一场战争，每个人都很重要。只是，读读克劳塞维茨《战争论》的开篇你就有答案。
看到 @陈甫鸼 的答案，不能不说一些。甫鸼的技术水平是有目共睹的，但是如果因为测试队伍中有这样的人才，就认为测试和开发是同一个境地，那就错了。
在一场战争中，特别是现代战争中，有无数的人员支持战斗人员和指挥链上的指挥人员。没有这些支持人员，战斗人员和指挥人员就是瞎子，聋子。但是，即使有人把这些支持人员做到最好，一个没有战斗指挥人员的军队就等于零。虽然在双方的战斗指挥人员旗鼓相当的情况下，支持人员的优劣可以决定胜负，但是另一方面，战争是千变万化的，在某些极端时刻，战斗指挥人员甚至可以分出一部分精力来执行支持人员的功能，甚至在局部短时间可以放弃支持。而支持人员一刻离开战斗指挥人员，他的功能就是零。
好，我们可以说这两者各有分工，他们的技能完全不同，他们的角色都不可或缺。但是作为一个把军事作为最高追求而不是勉强靠服役获取福利的人，你选择哪种角色？作为一个资源有限的团体，你会先照顾哪种角色？我们不是生活在真空里，就用有人提出的造炸弹和拆炸弹的比喻，如果你只能招一个人，你会招哪个（造炸弹的起码可以当半个拆炸弹的，因为这是他的工作本质决定的）。如果你非要说拆炸弹的也会造炸弹，我只能说你给他的 title 错了（因为这不是他的工作本质决定的，而是他的兴趣决定的，@陈甫鸼 的兴趣十分广泛）。
在这个软件工业里，只有开发者旗鼓相当的公司，才能拼测试。而实际上，开发者的生产力可能会相差到十几倍。现实地说，我得承认@pansz 的看法很有代表性。我所知的很多公司的看法都是这样。但这不是我认同的看法。水平差点可以做测试，实际上就是把测试部门当作垃圾收容所。但是实际上说这些话的人，我相信并不理解测试究竟是什么。
如果我们不打算做深入的分析，其实要驳倒这个所谓的理论只需要一个例子就可以了。很多程序员不是总喜欢用架构来形容程序么？架构这个概念来自建筑行业。可是我相信很多人都知道建筑需要专门的人负责质量管理的，也就是保证交付建筑的质量满足需要。我们不会允许建筑公司自己做完工程自己验收然后直接交付使用的。我们都知道测试本身存在的目的是为了保证软件的质量满足需要，那么为什么乐于用架构对比软件的程序员们却认为软件可以不需要测试人员？显然这是荒谬的。
当然，我知道这种对比是驳不倒骄傲的程序员们的。我们从数学家那里继承了高傲的本性，天真地自以为算法就是一切（当然，他们中间的许多人其实多数时间用的算法都不曾超出过大学二年级那一年的课覆盖的内容），却不曾真正接受工程师的严谨。所以我们还是需要详细的分析。
首先，测试是什么？保证产品质量，这个过于模糊的说法说明不了问题。最直接的方法就是数一数测试究竟需要做什么：
- 监控产品流程。从时间控制的角度来说，开发新功能和修bug是一个平衡。开发得太快就可能把交付给下一个阶段一个问题较多的版本，从而使得后面的问题更难处理。我们如何知晓每个阶段软件质量怎么样？具体的方法很多，回归测试，代码覆盖、压力测试等等。但是这些信息谁来收集和分析，怎么分析？能得出什么样的结论？有多少程序员会自己做这些？
- 搭建复杂的应用场景。谁能知道测试一个完整的Active Directory服务器的回归测试环境需要多少台域控？我搭建的纪录是11台，还不包括中间可能动态加入和删除的客户端。其中包含大量故意的毁坏性操作。每一次毁坏之后都必须恢复现场进行下一个测试。有多少程序员构造过这种场景？
- 简化问题报告。当发生用户报告时，他们最初给出的步骤往往过于简化或者过于繁琐，缺乏直指问题所在的步骤描述。很多时候由于步骤不清楚，导致分析过程中存在很多弯路。这个时候需要有一个人来不停地和客户打交道并定位关键步骤。这个步骤总是必须完成的，那么谁来处置？有多少开发人员真正负责处理过这些？
当然我知道很多程序员们会高傲地昂起头：这些我们都不需要。只要我保证每个函数是对的，最后的软件必然是对的，所以只要单元测试就够了。这种理论我不止听一个人说起过了，也实在是没法说清楚。我只能说这些信息是有很多人需要的，既然有人需要，就得有人做。
我承认，有些情况下我们确实不需要专门测试。这种典型场景实际上有一个很简单的前提，即软件本身不包含复杂的应用场景。比如单机软件，比如单服务器网站。但是这不包括那些本身需要复杂使用场景的软件，比如Exchange、比如Active Directory。这类包含集群和分布式要求的软件系统不是一个人花一个小时坐在一台电脑前试一试就能做好的。
当然，对于开源软件来说还有一个方法，就是可以通过大量的发布让使用者做小白鼠。但是这不适用于所有的软件公司。对于一个app，也许崩溃就崩溃了，反正也许无非就是一条微博没发出去；可对于股票软件的服务器系统，你敢崩溃下试试看？我不知道在这里侃侃而谈水平不行就可以做测试的人，是不是确实长时间负责过此类复杂系统。
说了这么多，总结起来就是一句话：测试和开发需要的技能有交集，但基本上是两个要求不同的岗位。开发技术不行去做测试，不等于你能成为一个好测试人员。
当然，我也得承认一点。现在开发和测试分离的做法其实助长了一个倾向，就是开发部门的一些程序员越来越不关注自己的程序质量，也不关心自己的程序是被如何使用的。我记得当初曾经在CSDN的微软测试专家群论坛上看过有人如此发言，他说一个产品到发布的那个时候对他来说就是死掉了，他就不再关心了。时间太久，我不记得说这话的人究竟是谁。但是我得说这代表了我认识的一部分程序员的看法。但这不是程序员的错，也不是分工的错。该指责的是无能的领导，他们设置测试这个职位就是为了丢垃圾的，而没有能力把握两个角色的关系改进产品。这种无能的另一种倾向就是雇用大量的测试人员，以为用人去堆就能堆出好产品。他们忘记了，测试人员起到的是监控质量变化的作用，而不是提高质量。提高质量的唯一办法是开发。
丢包袱能让人轻装前进，但是只知道丢包袱是丢不出好产品的。
——我，现在。
最后推荐一篇文章作为注脚：http://www.aqee.net/on-testers-and-testing/
=== 对@冯东 老哥增补回答的回应 ===
从我的经验上看，我承认测试人员对编码和算法的要求可以比开发低一些（现实告诉我，我这种成天直接给开发扔fix的测试即便在微软不是多数派），但我强调的是对编码能力的要求较低，不表示开发人员可以自动成为一个合格的测试。就像随便拉一个战斗部队的人让他去负责炊事班，他不可能自动地做得很好一样。
测试这个岗位有测试的能力要求，它和开发的主要差异是在于分析和统计的能力。测试的基本能力是能够严格地按步骤执行测试，这个确实是很容易入门的。但好的测试要求的绝对不仅仅是这个。当一个人在测试到达一定程度的时候，他/她就必须开始注意很多流程上的分析工作。我说的流程不是很多人想像的一个老板坐在那里要求手下人做事之前必须做这个做那个，而是对整个开发周期里质量变化趋势的把握，以及如何用合理的技术手段支持这种趋势的分析（比如回归，比如fuzzing，比如压力测试）。从这个意义上说，我承认测试本身是一个相对容易向管理转化的职位。但这本身是可以理解的，就像建筑质量检查员必须了解建筑学常识，但不需要自己去画蓝图一样。反过来，他们需要强化交流和沟通能力以备出问题的时候可以有效地要求开发商承认问题，这不等于谁都能做这些事。
其实开发在这个位置上也是一样的。最开始面试的时候，只要是计算机科班出身大学又大学四年不太混事的，写个排序之类的算法都不是难事。但一个好的开发不是只会这些就够的。当入行时间长了，开发就必须开始注意领域知识（比如东哥最近刚发布的Adaptive Wide Angle滤镜）、架构、设计（比如互操作性，微软已经被人骂了很多年了）等等东西。这些东西都和编码本身无关，但是成为一个好的开发必须掌握这些。这两个职位也许开始时能力要求接近，随着时间的发展则差异会越来越大。但这不是开发部门可以用来鄙视测试部门的理由。
另一方面，也正是因为有了两个职位的差异，所以才会有兴趣爱好方面的区别。有的人一开始不理解测试这个职位，慢慢地越做越喜欢；有人试了之后还是觉得不符合自己的兴趣，所以选择离开。这都很正常。人各有志，这东西勉强不来。
所以再次重申，测试不是开发的垃圾桶。不是说编码技术不行的人就该搞测试去。如果一个人希望把开发作为自己的事业却能力不足，那么他能做的只能是提高开发技术，而不是靠测试混饭吃。
当然了，如果确实是想在微软这样的公司做开发却发现暂时能力不足，申请做测试也是一种为自己争取机会的权宜之计。但是如果这样则更需端正自己的心态，要是觉得做测试是委屈了自己，那么接下来引发的就不是技术问题，而是人事问题了。如果刚开始就抱着一个混饭吃的心态，最后到哪里都是混不下去的。
P.S.：关于我的一些状态变化的解释。
我承认我前一阵子刚刚从测试转到了开发。虽然在这个背景下为测试说话貌似在打自己的耳光，但确实值得说道说道。我必须得说我转岗位的理由和@冯东 老兄所说的理由不符。我之前负责的是服务器相关，现在转到了语音。这两个部门的差别恰恰满足我之前分析中提到的一个关键差异，即从一个对应用场景和部署要求非常复杂而算法要求相对较低的部门，转到了一个对部署要求非常简单而对算法要求很高的部门。平心而论，这个新岗位对测试的要求以及发挥空间其实比原来的部门要低很多。对我来说我两者都可以做得不差，那么我当然会希望找一个更有挑战性的职位来试试看。另一方面是作为一个五年的测试，我也希望换一个角度看看自己之前的岗位是什么样子。对于这个选择，我多少也是遗憾的。
所以我换了一个岗位，但是我换岗位的前提是我两者都能做，而且领导也愿意给我这个机会。这和两个岗位孰高孰低并无干系。肯定是测试比开发工资低，要求低阿。
如果你在微软之类的公司做测试，那想必也有很多东西可以学，晋升空间也可观的吧。
但是，如果你是以下例子中的情况：
如果有人在一家很普通的中小企业，还可能不是IT行业的公司做了专职的[软件测试员]，几年之后，那真的很难在职业上有提升，更难跳槽。
而如果有人在一家很普通的中小企业，还可能不是IT行业的公司做了专职的[软件开发]，几年之后，该人在公司成为技术带头人，公司已经无法给他适合他的薪资了，他轻松的跳槽到500强的公司，工资翻几倍。从很多公司的实际操作来讲，楼主的问题答案是"是的"，应届生招聘经常达不到开发要求的人转测试看看! 但是应届生开发和测试的起薪一般是一样的。假如是去大公司，测试的前景还可以，职业阶梯常见是转管理，系统工程师，产品经理等。小公司千万别去干测试了，干出来就是个打杂的。
测试的素质非常重要，假如觉得不重要，那是因为你没有看过真正好的测试。
公司的测试部门也有几个相当不错的人。公司的年度之星研发中心有测试评上了一个人，但是开发没有。这都可以说明测试的重要性。
测试对于耐心、沟通、条理性等相对偏重，综合素质要求比较高; 开发的话，要求从低了说，要对写程序这个事情有兴趣，否则那么多的知识，那么多的要求你记不住也用不来，到头只是个平庸的开发而已，往高了走，开发的思维，耐心毅力沟通等也很重要。 但是一个主要的问题是开发的基础要求比较"硬"，coding基础和能力是比较好评估的，而测试的一些综合能力偏软技能, 对于应届生不太好评估，所以出现了楼主说的情况。
在招聘操作里面，主要是尊重个人的意愿，在应届生招聘的时候，常见的方式也是发现开发技能不行就看看测试部门是否要，说不定别人其它素质不错呢，女生去测试比例较高，这也和女生的个人倾向有关，实话说开发常常也比较苦一点，加班多一点。
另外楼主问题里那个人(也许是HR吧)说的话有问题，“问在公司一般程序员未来几年的发展，他说看个人能力发展，如果水平差点可以去做测试”，开发技能不够可以转测试，这只是个人特长的一个问题，但是假如是一个人的综合水平差，比如做事不细心，缺乏沟通能力，他干啥都不行的。
------------------------
BTW, 本人并非测试，而是开发部门的头，也和测试部门老大一起招过几次人，感觉目前国内目前对测试人员还是重视不够，测试人员的薪资涨幅和找工作容易程度的确是不如开发，而且8年以上的测试人员假如不转型，职业出路还是窄了点，这都是现状。 这个现状有部分合理性，虽然要开发测试都好才能出好产品，但是假如是难度高的项目，条件限制只能选择开发强测试一般或者开发一般测试强，大部分人会选择开发强。当test和dev两个职位达到同一个高度的时候，那么tester本身无论是深度还是广度都是需要比dev来的强。否则何以测试bug？再者说，测试不单单要掌握的是一门语言，一个平台，而是包括软件工程在内，测试方法设计等等非常多的技能。甚至测试需要了解这个世界上任何一个存在的平台，因为你是一个测试，不能象dev一样深入一个点。对于测试而言，测试设计的方法，思想的进化才是根本。其余的都是工具。所以无论从什么样子的角度来看，测试的要求绝对不会比开发低。我也不评论谁高谁低，但各有千秋。我做了两年测试了～从我自身经验来看～测试入门门槛相对较低～但是入门以后想要得到长足发展～能力要求超过开发。可能我做外包的缘故～我感觉做不同项目后测试人员需要会的东西太多了～可能开发技术没有开发人员好～但是技能要求多样化非常高！而且不止技术方面～还要有很好的理解能力～应变能力和交流能力，否则在测试工作中会遇到很多问题！大部分企业都不需要高仿测试人员，一般都是点鼠标黑盒测试即可。【我说的是一般情况，高仿测试朋友勿怪】
测试比开发门槛低、起薪低，自然不能吸引好的应届生，试想一个计算机应届生自身水平足够的话，会选择起薪高而且发展路线清晰的开发岗位，还是起薪低且公认较低端的测试岗位？
人都有逐利性，有能力者必然会尽量选择一个略靠谱且工资高的岗位，所以按平均素质来说，测试人员必然会低于开发人员的。
下面是腾讯的待遇信息，来源于分智网
@冯东 的回答其实是真实的现象。他所论述的，不过就是生产者的重要性。的确，一个餐厅里最重要的是厨师，如果我所有人都雇不起，我至少也要雇个厨子来。一个软件公司最重要的当然是开发人员，没有产品，测试人员测个屁。
@陈甫鸼 将产品开发工作与传统建筑行业进行类比，提出了质量管控的重要性。但是这个提法是模糊的，混淆了产品质量与过程质量，测试团队的过程质量管理角色本来是一些更偏重敏捷的团队使用后置工序督促前置工序的便宜之法，如果这样也可以，开发人员对设计人员的督促，也可以看作是过程质量管理工作。
但是，题主问的问题是，“软件测试员比软件开发员要求低些吗？”
公司的战略肯定是要先发展核心力量，提高生产者的能力，这是没错的。所以如果在同一个公司里，测试的投入和开发的投入，肯定是后者多。所以体现到行业上，就是测试人员比开发人员要求低一些了。实际上说就是如此，不管是国内还是国外，没有什么需要避讳的入门低，是对的，但以后没那么简单，如果一说到测试就呲之以鼻的话，那就肤浅了我不同意软件测试的岗位要求比开发低！
首先，测试和开发是两个不同岗位，不同岗位的职业要求无所谓高低，没有标准比较！如果非要从编程能力的角度来评判，那我只能，呵呵。
其次，测试想做的好做的精通是需很好的代码能力的，这样来看是不是要说做测试的就能做开发了呢？！测试要求更高些呢？
最后，还是想强调一下，两个不同的岗位，没有什么标准可以评判岗位要求的高低！
谢谢，拙见！
普遍意义上是这样的，都被最近几年国内一些公司把风气带坏了。测试在国内给大部分老板和开发人员的印象就是点鼠标，跑脚本，写报告。
因为只要是软件就会有bug，无论有没有测试团队存在，再牛逼的测试团队也不能保证100%测试出所有的bug。所以很多公司认为不需要特别牛逼的测试人员，主要还是kpi不好衡量，线上出现bug到底是谁的锅？测试出多少bug算好的测试人员？于是越来越多的公司不想花高薪去找一个好的测试人员，由于不受重视的原因，很多好的测试人员对测试也逐渐失望转行做开发去了。最后几年下来的后果就是很多开发人员认为同级别的测试人员工资比自己高心态就失衡。
于是慢慢的测试要求就低了，要求高了也招不到人啊。
不过也有例外，比如渗透测试或者说挖漏洞也是软件测试的一种，要求就是开发会的都要会，测试会的都要会，还要有智商，还要有毅力。比如像TK教主这样的牛逼的“软件测试人员”(大部分情况还是黑盒测试)，年薪和能力难道不是吊打各种开发？
对题主的问题的回答：对软件测试人员的要求不是必然低于软件开发人员。好的测试人员同好的开发人员一样难找。
现状：
从目前在岗的平均水平来看，软件测试人员平均水平要低于软件开发人员。
原因是多方面的：
1. 软件测试无法带来直接的效益，难于衡量工作效果
2. 软件测试工作可以由开发来替代完成
3. 软件测试工作不受重视（通常重视是在出了问题之后）
4. 部分测试工作门槛低，特别是给外包公司的部分测试工作，直接原因不外乎：没有找到好的模式做自动化，业务变化快，外包成本最低。
作为一个合格的测试人员：
1. 了解产品，这个需要在需求分析/产品定义阶段就介入了解，了解产品的基本功能场景。
这时候要考虑功能边界（哪些功能支持，哪些功能不支持，什么时候支持，什么时候不支持，不支持要给什么提示等等）
2. 了解实现架构，这个需要了解各个模块的功能定义和交互模式。
每个模块要做什么样的测试；集成测试时，一个异常会导致哪些后果，哪些异常需要进行测试。
3. 了解（关键点）实现细节，设计测试用例，保证代码尽量被测试用例覆盖
这个是通常说的白盒测试
以上是不同开发阶段测试的一部分工作，其他还包括：
搭建测试环境，尽量模拟开发环境
自动化测试用例
其他方面的测试：稳定性测试，压力测试，时延测试，本地化测试，国际化测试，用户体验（界面友好）测试，安全性测试，破坏性测试。
给产品做整体的质量评估，这个评估当然是基于之前的测试计划和测试结果的。
测试人员需要掌握的技能树比开发人员的更大：
一个好的测试人员是要审阅开发代码的（至少要有这个能力），
要了解开发中使用的产品和技术。
除此之外还要掌握至少一门脚本语言。
还有多种的测试工具和其他工具（bug管理，自动化管理，测试用例管理，任务管理）。
bug分析能力，这是个综合能力，包括对现象的分析，日志的分析，数据流动的判断，功能/模块的分析等等，
说到这里，你还觉得测试是个轻松容易的活吗？
说到最后，在当前的环境下，开发周期越来越短，团队依赖越来越大，产品/开发/测试的角色并不是固定的，敏捷开发中对于个人的要求往往不只一个角色，需求分析阶段你需要做产品的事，开发阶段你要做开发，开发到一个阶段后，你还要做测试，一个人的角色不是固定不变的，是可能随着产品周期变化的，一个产品在不同的阶段的需要也是不同的，人数会变化，角色也会转换。
一个人所体现的价值也不应当被一个角色所限定，除了漂亮的代码之外，积极的沟通/精准的需求分析/合理的架构设计/严格的测试都是一个成功的项目必不可少的部分。
作为女生，如果不愿意在编码工作上做过多深入的话，作为产品设计者，项目协调人，项目架构师，资深测试师都是可以大有可为的。可以考虑的其他职位还有技术/解决方案专家的职位，运营维护专家。不需要努力的高级职位是没有的。
这个问题其实很好回答。行业决定产品质量要求，质量要求决定测试地位和对测试能力的要求。
没听懂，是吧。
没关系，我把各个行业按照质量要求划分为四个档，帮助大家理解。
第一档，航空航天。比如NASA规定软件缺陷密度不能超过0.1/kloc，我国的航天要求为1/30kloc。而软件工程师的平均水平是100/kloc，最牛逼软件工程师水平也就是50/kloc。说明个啥？说明航天行业上，一个人的代码要两个人，甚至更多人进行白盒测试。如果不这样做那就等着观赏高空大呲花吧。损失的可能是百亿美金和数人的生命。
第二档，金融，医疗，通信，汽车电子。其实这个技术难度不高，主要是安全和可靠性。出了问题要么是丢了钱，要么是丢了命。不可儿戏。
第三档，嵌入式设备的固件。这玩意失效的主要问题是不好更新。比如自动报数的电表，如果它坏了，你得拆下来送到维修站返修，还得接受消费者的投诉和漫长的协商。你说电力公司能饶了供应商吗？供应商能饶得了工程师吗？废话少说，测试严肃一点。
第四档，手机apk，web应用。有bug？发布新版本喽。宕机了？重启喽。还是不行？我去机房值夜班喽。
再举个例子，苹果的测试工程师，就比谷歌的测试工程师要求要高。谷歌甚至没有严格意义的测试工程师，coder自己上。只有专项的验收工程师（搭建复杂验收环境，产品专家，大规模模拟用户操作等），以及测试开发工程师（教coder打桩，输出测试框架，参与软件设计但是不参与软件测试执行）。如果按照这套模式，开发出来的iPhone，那质量有的瞧了。虽然iPhone也可以升级刷机，但是三天两头刷机，用户不骂娘才怪。而谷歌的产品不太一样，拿gmail来说，主要问题在服务器，服务器可以本地维护，可以倒换升级，用户影响很小。这样的产品做那么多测试，有什么必要？直接发布，错了就改。
ps1，关于谷歌的测试理解源于三年前一次学习调研，时过境迁，记忆可能有偏差，或者谷歌更新开发模型，本人不做保证。
ps2，四档划分是本人的从业理解，班门弄斧，哗众取宠。
扣题：
在航空航天行业，测试能力要高于开发。
在金融医疗等行业，需要测试能力和开发水平相当。
在嵌入式设备固件开发，测试也要紧跟开发者水平。
在手机app，web行业，测试能力要求真的不高，你想提升水平也没空间。想提升就得换行业。
=================
在很多码农心目中，coding能力是唯一的能力，所以题主的发问引来了一堆论战。
还是看项目。近来，手机app和web的繁荣巨浪，带来了很多纯软件项目，在这些项目中软件工程师确实一家独大，说一不二。但这样的项目并不是唯一的，甚至是很小一部分。而且是可能坚持不久的行业，因为你们多数是在重复造轮子，不符合生产力发展方向。
跳出你们的框框，实体产品的开发需要硬件，结构，id，资料等等。软件只是一部分。测试的目的不是给软件工程师下绊子，而是保证产品成功。测试还包括硬件测试，可靠性测试等。
没有参加过这种复杂的系统化的项目的软件工程师，别评论本回答。谢谢。
==============
再次回到题主的问题？女生是否适合做测试。
我只能说，女生可以做测试。因为这里的测试一般指低级的测试，黑盒的功能测试。
但是好做的事情，一般来说竞争大，回报低。
开发更苦更累，但是收入，跳槽机会相对来说更多。
如果只是怕累怕熬夜的姑娘，那就做测试吧。
如果逻辑能力不强的姑娘，你可以做测试，但是别和我一个组，最好别和我说话，谢谢。
如果有的姑娘自我感觉沟通能力强，可以在测试工作中大显身手，其实我的建议是去做销售。
测试需要的是逻辑能力，逻辑能力和逻辑能力。不然，怎么打coder的脸？
看了很多答案，都说测试门槛低，拿个鼠标点点点就可以，没有技术含量。其实这只是测试方法中的一种：随机测试，即想点哪里点哪里，完全不需要考虑每一步操作的逻辑，也许当前在模块A，下一步就跳到模块D。而如此测试，极容易产生测试遗漏，测试猿自己都会忘记做了什么操作，哪些地方测试哪些还没有，出现BUG时也不易重现，极大地增加开发人员的负担。
实际上，要做好一个产品或项目的测试，需要了解产品或项目的背景，用户群，用户场景，用户需求，系统架构，系统业务流和数据流，等等。然后再根据这些来编写相关测试文档，组织项目组评审文档，最后才是根据评审通过的文档对系统进行点点点，提交BUG，编写测试报告。如此，完成一轮测试。接下来就是若干轮的回归测试，而测试猿需要在每轮回归测试开始前决定测试策略：全部重新测？重点模块测？只对修改的部分测？这极大地依赖于测试猿对系统、业务的了解程度。所以，很多时候，测试猿比开发人员更熟悉系统，更熟悉业务。
以上，只是功能测试的范畴，接下来需要开展的有：性能测试、UI测试、兼容性测试、安全性测试、健壮性测试==如果涉外，还需要做本地化测试。
所以，好的测试猿，想拿高工资的测试猿，需要掌握的技能绝对比开发人员多。开发人员也许掌握JAVA就行，对C++可以不理会（反之亦然），但测试猿不行，需要熟悉多种开发语言和脚本语言（JAVA/JS/C++/C/PHP/PYTHON/SHELL/==），掌握多种数据库（MSSQL/MYSQL/ORACLE）,因为做白盒测试和接口测试会用到；需要掌握多种测试工具（QTP/SELENIUM/LR/JMETER）,因为自动化测试和性能测试会用到；还需要掌握多种操作系统（WINDOWS/LINUX），多种协议，因为做UI测试、兼容性测试、安全性测试、健壮性测试会用到。
所以，让开发人员或其他什么人员兼职做测试，是不可行和不可靠的。
结论：测试猿的技能要求，不比开发人员低，甚至还要高。
呵呵....要求低..
我做了5年测试了，从最开始，公司是Java，后来安卓，再后来，网元、存储
换一家公司，就换一套工具，换一种脚本语言。
自己算把，js/shell/python/perl....
工具，各种benchmark and 各种不同的工具。
这个要求低？？
现在一些新手，包括很多IT从业者，都可能对软件测试有一些偏见或者误解。大体总结如下（包括你听说或者认为的软件测试员要求比软件开发员低），希望对大家认识软件测试有所帮助。
1) 测试人员不需要了解软件开发的知识
这个很要命的，我们谈到软件测试人员未来的发展方向大致有：自动化测试，性能测试，测试管理，项目经理。这其中自动化测试和性能测试包括项目管理，都会要求对软件开发有深入的理解，如何能设计一个好的自动化框架，好的性能测试用例，如何管理一个开发团队，这都需要我们在软件开发方面有所掌握。不单要掌握，而且要精通，此其一。
其二，如果不了解开发知识，测试人员很容易被开发人员牵着鼻子走，因为开发人员随便一忽悠，你如果不了解个中奥妙，你一个字也说不上来。（以前我们讨论Cookie和Session，由于GoAhead不支持Session，只能用Cookie来控制，差点别开发人员忽悠了。）
2) 测试很简单
如果你这么想，那么请别去做测试，如果你做了，你也做不长久。以前面试一位小伙子，做了3年测试，问他测试都怎么做的？答不上来，原来他测的都是很简单的小软件，根本就没有系统地去学习过测试，无语。
3) 测试就是为了找到Bug
很多人最初都是这样的看法，千万要小心。如果你只是为了找到Bug，那么Bug会成天缠着你。
4) 测试人员和开发人员从来都是死对头
我以前发起过一个倡议，我们讨论的时候不要用他们（开发人员）和我们（测试人员），而是统一用咱们（开发人员和测试人员本来就是一起的）。如果测试人员能与开发人员成为朋友，你会发现，生活是多么美好。
5) 自动化测试太难
有的人一进公司就想做自动化，觉得它有难度，有挑战。我说你如果做不好手工测试，你同样做不好自动化，手工测试才是基础。而另外还有一部分人一说到自动化便望而生畏，认为这个东西太难了，不想碰（特别是很多女生，就有这个心理）。其实大可不必这样想，自动化测试工具它只是一个工具而已，它跟Word这样的工具没有任何区别。
6) 手工测试太没挑战
什么都不说了，能把它做好的人没几个。
7) 大量的重复性的工作很乏味
于是大家学得测试这份工作不好玩儿，特别一些男生，特别一些开发人员，从来都瞧不起做测试的，觉得这玩意儿太没劲。我想说的是，要掌握方法，要学会创新，任何东西都有它的特点，你如果总觉得成天在做重复性的工作，那么请静下心来想想，怎么能让它不重复（事情本身是死的，人是活的）。
8) 白盒测试是开发人员干的事
一个合格的测试人员必须掌握白盒测试，理解其中的原理。不管什么样的测试，都必须要有测试人员的思维才能做好。
9) 女生适合做测试
不管适合不适合吧，反正我以前所在的公司有5个Team Leader，3个Test Manager，其中只有两个是男生（加上我），这是现实。但是做自动化测试的，全是4个男生，这也是现实。不太想加以评论。只想说，女生未必适合做测试，男生同样能把测试做好，且做得更加专业。
10) 测试就是给开发擦屁股的
如果这样想，那么请每天多准备些手纸。测试人员永远要站在客户的角度来想问题，很显然，客户是从来不会给谁擦屁股的，相反，是客户在驱动着软件的进展与成型。测试人员就应该扮演这样的角色，在大部分时候，要驱动开发人员完成软件的功能，驱动他们做改变。
11) 我做开发可能不行，做测试吧
这个观点特别适应于应届毕业生，在以前面试的过程中，有一部分人就是觉得我代码写不好，所以入行做测试，还有一部分人稍微明白一点的，是觉得自己在开发方面没什么优势，主动给自己定位做测试工作。其实测试要掌握的技能远比开发多得多，至少面要广得多，要做一个好的测试人员，远比做一个开发人员难得多。
12) 功能性测试掩盖了可用性测试的必要
测试人员甚至我们的设计人员，开发人员都不太注重可用性（usability）方面的设计和测试。
我们往往只在意功能性或者性能方面的测试，而忽略了用户体验，即使谈不上用户体验，哪怕是方便使用也行，这些方面往往从软件需求，设计一开始就没怎么考虑。到后来，用户使用的时候便是边用边骂娘。（我常举的例子是，咱们买手机的时候，手机功能一切正常，但偏偏盖子上有条划痕，我相信大家都会要求重新换一台，就这意思。）
以上观点有则改之，无则加勉，希望大家在进入软件测试这一行以前，能对测试有一个更深入的认识。
接下来，我们来重点聊聊很多IT新人比较关心的一个话题：软件开发和软件测试，该从事哪个方向？
我一直认为，在开发领域，强哥的测试技术非常扎实，在测试领域，强哥的开发能力实在牛逼。如果我天天纠结到底是开发好还是测试好，还活不活了？
我们先来谈谈技术追求这个事情，就像强哥学院的Logo一样，“工匠精神”这个词，自从被罗胖提出来以后，现在全民都在提，这不是什么坏事。至少，让浮躁的人们知道了，“工匠”其实是最受人尊敬的，也是最有尊严的一个群体，就像现在丈母娘都越来越喜欢IT宅男一样的道理（钱多，事儿少，脾气好，俗称“经济适用男”）。所以，偶你还在纠结做开发还是做测试，证明你其实是没有技术追求的，这一点你不一定会承认，但是身体是诚实的。
为什么这么说，其实道理很简单，我们来设想这样一个场景：如果你是一个爷们儿，突然在你的生命中出现了一个美丽的姑娘，你会怎么办？
你会纠结吗？
你纠结什么？
假设正常情况下，你不纠结。
为什么呢？
因为你内心很笃定，就是她了，你一定不会跑来问强哥的。我们选择职业，道理也是差不多的，人为什么会纠结，只是因为不够坚定而已。就像到底学Java好还是学Python好这样的问题，每天充斥着QQ群或者交流论坛中。现实的情况是，测试也好，开发也罢，如果你不去执著于对技术的追求，你相信我，你一样都干不好，建议你也别干这行了。就像很多人之所有选择测试，是因为害怕编程，基本上来说，不懂编程，要想在测试技术领域有所作为，很难，30岁以后转行的不少，中年危机更甚。
人性就是这样，这山望着那山高，老婆总是别人的好，那个优秀的孩子总是别人家的，或者经常听到一些自我催眠的话，哥的人生哥作主，等等言论。我们不谈对错，只谈现象。强哥接触的人，特别是学生，各种风格，各种性格，形形色色，当然也有各种奇葩，基本上，我在很多人身上，都能够感受到一点：很多人总是把希望寄托在一些不切实际的未来，而不是把握当时当下确定的现在。得不到的永远是最好的。这些都是人之常情。
强哥也是热爱技术，大学一直自学编程，但是，当第一家公司安排我去做测试工作时，我想都没有想，我要做程序员，还是接受公司的安排，做软件测试。因为原因很简单，我只想搞技术，我必须要进入IT这个行业，特别是当年我还是一个小菜鸟的时候，尤其又是一个统计学的学生。至于IT这个行业未来会怎样，管它呢，我又掌控不了，我唯一能确定的是，我喜欢这个行业。再退一步，无论我做什么工作，谁都阻挡不了老子写代码的热情。所以，强哥现在仍然保持足够的代码量，所以我能写书，出视频，写教材，所以我能在公司里面保持技术的领先地位，即使现在我是一个CEO，很多朋友都劝我作为一个CEO，要做好三件事情：“找人，搞钱，定战略”。去他妈的三件事，老子就想做好一件事：“用技术去征服世界”。让技术，成为蜗牛学院的定海神针，建立培训机构的技术壁垒。为什么我们不能强大到让人来找我，让钱主动送上门，这才是格调！
回到本话题的出发点，学软件开发还是软件测试？
强哥给你的建议就是两句话。第一句：“做任何你周边的朋友不敢做的事”。第二句：“做你认为你自己最想做的那件事”，强哥怎么建议你，不重要，朋友怎么建议你，不重要，老师怎么建议你，不重要。当然，如果你仍然无法抉择，那么你就跟随强哥吧，把测试和开发，前端和后端，管理和技术，通吃。走向人生巅峰，指日可待。
这个世界上，为什么成功的人总是少数？
可能只有1%，强哥来告诉你，因为那99%的人都选择走大路，走一条容易走的路，只有1%的极少数人，走的人别人从未走过的路，是一条难走的路，他们不成功，天理难容。
注：本文观点节选自蜗牛学院资深IT屌丝兼CEO邓强老师知乎专栏“强哥学堂”，如需转载请私聊本号获得授权并注明出处。
