软件测试员比软件开发员要求低些吗？

　　问题：51Testing软件测试网p$Z;b)w+O?I1Vm^v

　　在学校的时候，老师说女生以后如果从事不了开发，可以去做测试，有次面试，我问在公司一般程序员未来几年的发展，他说看个人能力发展，如果水平差点可以去做测试。51Testing软件测试网~[YfXc__Ttv

　　精彩答案：51Testing软件测试网K@;|0d6[ s%xi M

　　pansz：51Testing软件测试网$S#XiO5pz

x6E],z2h0　　水平差的开发人员，其绩效是负的，意即不但自己没有产出，还需要耗费其他人的时间帮他解决问题。意即为了解决他写的代码相关的问题会拖慢整个团队的进度。

　　但是水平再低的测试人员也不会出现负绩效。最多是没绩效而已。所以从leader的角度，如果没把握这个人能达到开发的门槛，去做测试是个更稳妥的选择。

　 　如果是回答楼主的问题，那么到这里也就差不多了。因为这就是现实。至于这个“现实”是不是合理，这种“现实”是否需要改进，那么就请参见其他人的回答 了，因为我觉得吧，现有的情况，在实际操作中很难保证把优秀的测试人员留在岗位上。你给钱太多了人家赚点钱就自己去创业，给钱少了人家想办法升职，升职完 了就又脱离测试岗位了。——测试人员创业的可能性甚至更大，因为他更了解需求层面。51Testing软件测试网'J1|/|%ttv

ny"BaPGSJS-D*sq0　　陈甫鸼：

,d9fvYV'mb` z0　　现实地说，我得承认@pansz 的看法很有代表性。我所知的很多公司的看法都是这样。但这不是我认同的看法。水平差点可以做测试，实际上就是把测试部门当作垃圾收容所。但是实际上说这些话的人，我相信并不理解测试究竟是什么。51Testing软件测试网3gmIaxQ&@

9r"F2u*b@#{0　　如果我们不打算做深入的分析，其实要驳倒这个所谓的理论只需要一个例子就可以了。很多程序员不是总喜欢用架构来形容程序么？架构这个概念来自建筑行业。可是我相信很多人都知道建筑需要专门的人负责质量管理的，也就是保证交付建筑的质量满足需要。我们不会允许建筑公司自己做完工程自己验收然后直接交付使用的。我们都知道测试本身存在的目的是为了保证软件的质量满足需要，那么为什么乐于用架构对比软件的程序员们却认为软件可以不需要测试人员？显然这是荒谬的。

　　当然，我知道这种对比是驳不倒骄傲的程序员们的。我们从数学家那里继承了高傲的本性，天真地自以为算法就是一切（当然，他们中间的许多人其实多数时间用的算法都不曾超出过大学二年级那一年的课覆盖的内容），却不曾真正接受工程师的严谨。所以我们还是需要详细的分析。51Testing软件测试网:on |-O6w

3cX;B0wpt]0　　首先，测试是什么？保证产品质量，这个过于模糊的说法说明不了问题。最直接的方法就是数一数测试究竟需要做什么：

{L}cim'XO0　 　1、监控产品流程。从时间控制的角度来说，开发新功能和修bug是一个平衡。开发得太快就可能把交付给下一个阶段一个问题较多的版本，从而使得后面的问 题更难处理。我们如何知晓每个阶段软件质量怎么样？具体的方法很多，回归测试，代码覆盖、压力测试等等。但是这些信息谁来收集和分析，怎么分析？能得出什 么样的结论？有多少程序员会自己做这些？51Testing软件测试网9_ZN)F3P4QR9G

b^v"N(J*z.X0　　2、搭建复杂的应用场景。谁能知道测试一个完整的Active Directory服务器的回归测试环境需要多少台域控？我搭建的纪录是11台，还不包括中间可能动态加入和删除的客户端。其中包含大量故意的毁坏性操 作。每一次毁坏之后都必须恢复现场进行下一个测试。有多少程序员构造过这种场景？51Testing软件测试网(v ?JR;SG8A

*R%e2[PO0　　3、简化问题报告。当发生用户报告时，他们最初给出的 步骤往往过于简化或者过于繁琐，缺乏直指问题所在的步骤描述。很多时候由于步骤不清楚，导致分析过程中存在很多弯路。这个时候需要有一个人来不停地和客户 打交道并定位关键步骤。这个步骤总是必须完成的，那么谁来处置？有多少开发人员真正负责处理过这些？51Testing软件测试网b w Y
CX

　　当然我知道很多程序员们会高傲地昂起头：这些我们都不需要。只要我保证每个函数是对的，最后的软件必然是对的，所以只要单元测试就够了。这种理论我不止听一个人说起过了，也实在是没法说清楚。我只能说这些信息是有很多人需要的，既然有人需要，就得有人做。51Testing软件测试网J0K&D"v}k(i+I4vt

　 　我承认，有些情况下我们确实不需要专门测试。这种典型场景实际上有一个很简单的前提，即软件本身不包含复杂的应用场景。比如单机软件，比如单服务器网 站。但是这不包括那些本身需要复杂使用场景的软件，比如Exchange、比如Active Directory。这类包含集群和分布式要求的软件系统不是一个人花一个小时坐在一台电脑前试一试就能做好的。

　　当然，对于开源软件来说还有一个方法，就是可以通过大量的发布让使用者做小白鼠。但是这不适用于所有的软件公司。对于一个app，也许崩溃就崩 溃了，反正也许无非就是一条微博没发出去；可对于股票软件的服务器系统，你敢崩溃下试试看？我不知道在这里侃侃而谈水平不行就可以做测试的人，是不是确实 长时间负责过此类复杂系统。51Testing软件测试网 v+?T_;t1u

　　说了这么多，总结起来就是一句话：测试和开发需要的技能有交集，但基本上是两个要求不同的岗位。开发技术不行去做测试，不等于你能成为一个好测试人员。51Testing软件测试网 }&~:r gvQ+J6x4?

　　当然，我也得承认一点。现在开发和测试分离的做法其实助长了一个倾向，就是开发部门的一些程序员越来越不关注自己的程序质量，也不关心自己的程 序是被如何使用的。我记得当初曾经在CSDN的微软测试专家群论坛上看过有人如此发言，他说一个产品到发布的那个时候对他来说就是死掉了，他就不再关心 了。时间太久，我不记得说这话的人究竟是谁。但是我得说这代表了我认识的一部分程序员的看法。但这不是程序员的错，也不是分工的错。该指责的是无能的领 导，他们设置测试这个职位就是为了丢垃圾的，而没有能力把握两个角色的关系改进产品。这种无能的另一种倾向就是雇用大量的测试人员，以为用人去堆就能堆出 好产品。他们忘记了，测试人员起到的是监控质量变化的作用，而不是提高质量。提高质量的唯一办法是开发。

　　丢包袱能让人轻装前进，但是只知道丢包袱是丢不出好产品的。

X[0@FX0　　另外，从我的经验上看，我承认测试人员对编码和算法的要求可以比开发低一些（现实告诉我，我这种成天直接给开发扔fix的测试即便在微软不是多 数派），但我强调的是对编码能力的要求较低，不表示开发人员可以自动成为一个合格的测试。就像随便拉一个战斗部队的人让他去负责炊事班，他不可能自动地做 得很好一样。

#uOV,n#w O6h0　　测试这个岗位有测试的能力要求，它和开发的主要差异是在于分析和统计的能力。测试的基本能力是能够严格地按步骤执行测试，这个确实是很容易入门 的。但好的测试要求的绝对不仅仅是这个。当一个人在测试到达一定程度的时候，他/她就必须开始注意很多流程上的分析工作。我说的流程不是很多人想像的一个 老板坐在那里要求手下人做事之前必须做这个做那个，而是对整个开发周期里质量变化趋势的把握，以及如何用合理的技术手段支持这种趋势的分析（比如回归，比 如fuzzing，比如压力测试）。从这个意义上说，我承认测试本身是一个相对容易向管理转化的职位。但这本身是可以理解的，就像建筑质量检查员必须了解 建筑学常识，但不需要自己去画蓝图一样。反过来，他们需要强化交流和沟通能力以备出问题的时候可以有效地要求开发商承认问题，这不等于谁都能做这些事。51Testing软件测试网t7ijM!uU[({

　　其实开发在这个位置上也是一样的。最开始面试的时候，只要是计算机科班出身大学又大学四年不太混事的，写个排序之类的算法都不是难事。但一个好 的开发不是只会这些就够的。当入行时间长了，开发就必须开始注意领域知识（比如东哥最近刚发布的Adaptive Wide Angle滤镜）、架构、设计（比如互操作性，微软已经被人骂了很多年了）等等东西。这些东西都和编码本身无关，但是成为一个好的开发必须掌握这些。这两 个职位也许开始时能力要求接近，随着时间的发展则差异会越来越大。但这不是开发部门可以用来鄙视测试部门的理由。51Testing软件测试网/t:M$g[4sf SJ

B0{#u?7v@x0　　另一方面，也正是因为有了两个职位的差异，所以才会有兴趣爱好方面的区别。有的人一开始不理解测试这个职位，慢慢地越做越喜欢；有人试了之后还是觉得不符合自己的兴趣，所以选择离开。这都很正常。人各有志，这东西勉强不来。51Testing软件测试网9nZ},q"W(u

:f }7X6x_1v)k0　　所以再次重申，测试不是开发的垃圾桶。不是说编码技术不行的人就该搞测试去。如果一个人希望把开发作为自己的事业却能力不足，那么他能做的只能是提高开发技术，而不是靠测试混饭吃。51Testing软件测试网+kzg7^_t bY

5[ l(`6Z*DXW!?0　　当然了，如果确实是想在微软这样的公司做开发却发现暂时能力不足，申请做测试也是一种为自己争取机会的权宜之计。但是如果这样则更需端正自己的 心态，要是觉得做测试是委屈了自己，那么接下来引发的就不是技术问题，而是人事问题了。如果刚开始就抱着一个混饭吃的心态，最后到哪里都是混不下去的。51Testing软件测试网"o(j`wh6k"X2yg%e