知乎上有一篇文章： 软件测试员比软件开发员要求低些吗？ http://www.zhihu.com/question/20156659
其中有段回答：
“
陈甫鸼，生长于闽，求学入秦，漂泊适燕，实秦人也。
现实地说，我得承认@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.：关于我的一些状态变化的解释。
我承认我前一阵子刚刚从测试转到了开发。虽然在这个背景下为测试说话貌似在打自己的耳光，但确实值得说道说道。我必须得说我转岗位的理由和@冯东 老兄所说的理由不符。我之前负责的是服务器相关，现在转到了语音。这两个部门的差别恰恰满足我之前分析中提到的一个关键差异，即从一个对应用场景和部署要求非常复杂而算法要求相对较低的部门，转到了一个对部署要求非常简单而对算法要求很高的部门。平心而论，这个新岗位对测试的要求以及发挥空间其实比原来的部门要低很多。对我来说我两者都可以做得不差，那么我当然会希望找一个更有挑战性的职位来试试看。另一方面是作为一个五年的测试，我也希望换一个角度看看自己之前的岗位是什么样子。对于这个选择，我多少也是遗憾的。
所以我换了一个岗位，但是我换岗位的前提是我两者都能做，而且领导也愿意给我这个机会。这和两个岗位孰高孰低并无干系。
”
------------------------------------------------------------------------------------------------------------
我的思考
从开发者角度讲，开发者对自己写的代码的质量负有不可推卸的责任，必须自己担起质量的重任。
从测试者角度讲，测试的主要目的是提供一个监控软件质量的功能，一定程度上降低在快速开发的时候引入bug数量，防止对已有稳定的代码造成负面影响，提高开发效率。
从管理者角度讲，提高软件质量关键还在于提高开发者的技术水平和素质，可以从几个方面入手：
1.减少测试人员的数量。
不能让开发人员对测试人员形成依赖，比例要控制在一定的范围之内，比如谷歌的开发人员和测试人员比例为10：1，怎么做到的呢？
“
经过与段念先生的交流，我了解到Google中国的测试工程师只有十多个，外包大约二十多个。从绝对数量上看，测试工程师的数量确实不多。但，在Google，测试有一个721的原则：70%的测试工作在底层接口测试和单元测试；20%的测试工作在集成测试；10%的测试工作在界面测试。之所以做这样的选择，源于Google工程师对测试的一些看法。Google工程师认为底层接口测试及单元测试的自动化成本比较低，自动化的程度高、稳定性好。在段念先生看来，基于界面的自动化测试时最难的（他反复向我强调这个观点）。我基本上认同这个观点。然而，关键的问题在于，这与1:10之间有什么关系呢？
从软件产品质量控制来看，开发工程师提交的代码质量越高，测试成本也会相对变小。首先，高质量代码的可测试性强，自动化成本低，测试成本会明显降低；其次，高质量的代码会使系统bug绝对数量减少，测试工程师消耗在bug上的时间减少，因而与开发之间的沟通成本明显降低；再次，高质量代码的返工率会降低，研发流程更加顺畅，效率更高；最后，单元测试和接口测试的自动化持续集成也可以有效降低回归测试的成本。Google工程师的价值在于将70%的工作花在提高系统架构和代码质量上。因此，1:10也不难解释了。
”（摘自http://www.taobaotest.com/blogs/show/1171）
2.提高开发人员的能力和素质，怎么提高呢？
一方面招人的门槛要高些，起码有潜质，且做人方面踏实认真负责；
二，在团队内部”惩恶扬善“，褒奖好的，树立学习的榜样，惩罚最不好的，杜绝懈怠心理，但是惩罚的方式有很多种，扣钱属于最下等，最好是比较有意思一些的惩罚。
三，多搞一些团队一起参与的活动，增加同事间工作之外的联系，互相信任对方，把团队的力量拧起来，要让团队成员内部知道，一个成员做事做不好整个团队会受到影响，接受惩罚，只有大家互相帮助，整体提高才是目标，有人不认同这种方式要离开也没关系，寻找合适的人，组建一个强大的团队而不是参差不齐的团队成员。等等。尊重并满足员工的合理要求，关怀员工，这是公司对员工的好，“惩恶扬善”，光明磊落，不要让你的员工对公司产生怨气，员工自然从心里更认同公司，从而对激发员工从内心真正的想要做好这样一件事的心态有帮助。