测试职业的惑与获（二）-都是执行测试，大家的差异点在那里

柳舞随风

都是执行测试，大家的差异点在那里？（0~2年工作经验）

有的新人很奇怪，测试环境大家一字排开，每天看大家做的事情都差不多，都是换版本，执行测试用例，有问题就反馈给开发人员，然后打bug，验证bug……为什么看起来大家做一样的事情，彼此的薪酬会有差距，或者差距那么多？

你看到的只是表象，内在的东西没有看到。如果看不到内在的东西，或者想不明白内在的东西，只能说，你距离合格的测试工程师，还有很远的距离。

执行黑盒测试和测试员是有差距的，测试员和测试工程师是有差距的，测试工程师和高级测试工程师是有差距的。测试是有技术含量的，不是单纯的工厂生产模式，大家都是进行的同样的操作，输出的都是同样的产品——话又说回来，即使单纯的工厂生产模式，因个人的差异，合格率也是不一样的。

那么，貌似同样的工作方法，彼此的差异点在那里?

一、输出成果质量

对执行测试来说，输出成果质量是决定性的因素。在考核的角度，bug的遗漏率也是负面的，决定性的因素。举个例子，几个人执行同样的测试用例，面对同样的测试任务：

A员工测试执行用了3天，执行100条测试用例，测试出了20个bug，完成测试任务。

B员工测试执行用了5天，执行100条测试用例，测试出了50个bug，完成测试任务。

C员工测试执行用了3天，执行100条测试用例，测试出了51个bug，完成测试任务。

如果你是老板，你会给这三个人同样的工资么？或者，你会给谁较高的工资？
   

二、耐心

在目前的工作模式下，少不了出现开发人员提供临时版本到测试环境调试，或者开发人员短时间内提供多个版本进行测试的情况。面对这种情况，是很好的考验测试人员耐心的时候。

同样的测试反复的执行，然后每次都有各种乱七八糟的问题，重复性的操作……人都会有惰性，可能最后一次的版本测试，很多前面测试执行过的没有问题的用例，会因为策略的修改或者开发人员拆东墙补西墙的解决方法，出现新的问题。

一次次的反复执行，这种工作是很枯燥，结果也是因人而异。笔者遇到的更多的情况，是测试人员根据惯性因素，直接跳过测试用例，认为不会有问题——出现这种情况，测试人员是不是很委屈？自己这么辛苦，反复执行了7、8次测试用例，每次都ok，谁知道最后一次有问题，最后还被k说漏测。

这种耐心和责任心，真的是因人而异。

   三、责任心

              责任心是任何职业岗位都要求的职业素养，在测试岗位的体现是什么？

针对bug，从开发的角度，必现的问题是最容易解决的问题，偶尔出现的，没有必然出现条件的问题是痛苦的，拷机十天半个月才出现的问题是绝望的。那么对于测试人员来说：测试出必现的问题是很容易做到的事情和做出的成绩。对于偶尔出现问题和长拷问题的责任心，是对测试人员的一个挑战。

版本迭代快，在测试中不知道为什么出现了一个问题，然后开发人员要求复现，或者bug打出去两天才过来要求查看现场，你怎么处理？

面临下班，一个随机的异常出现，你是选择无视，还是继续排查问题，尝试各种操作组合，业务逻辑组合，把bug抓住？

一个模块测试执行差不多了，一个很诡异的现象出现。然后尝试复现失败，那么对这个现象是放过，还是追下去？

四、排查问题的能力

            排查问题的能力依赖于对业务的理解能力，依赖于经验积累。这点老员工比新员工有 优势，但是差不多时间进入团队的同事，对业务的熟悉各自有差异，这就是用心不用心做事的结果。

        发现同样一个bug，还是有几个人，假设分别表现如下：

A人员用一个小时，请三个组的五个开发人员来看问题，然后定位出问题的责任人

B人员用两个小时，被几个组的开发人员推过来推过去，最后现象被破坏，需要自己复现

C人员用30分钟，定位出是那个模块哪个负责人的问题

D人员用10分钟，指出问题点和责任人，并分析出原因是哪个地方的业务逻辑问题。

         同样的问题，如果你是老板，会给同样的工资么？或者，你会给谁较高的工资？

    五、回归测试的覆盖度

回归测试的执行，按照书本上的理想模式或职业憧憬中，应该是这个样子：开发人员对提交修复的bug，填写仔细的问题产生原因、修复策略方法以及回归测试建议。测试人员根据开发人员填写的信息，在测试用例库中选取回归测试用例，并执行回归测试用例。

但很多公司在实际执行时，因种种现状，回归测试的深度和波及面，更多的会依赖于执行回归测试的人员的职业素质：比如业务熟悉程度，比如责任心。

建立一个回归测试的流程，对团队的积累（软件）和过程质量控制的投入（硬件）的要求是比较高的。提高回归测试质量，最快速有效的方法，就是提高测试工程师的业务能力和自我的责任心（属于末端反控，治标不治本的方法）。

面对同样的回归测试，还是有几个人，假设分别表现如下：

       A人员执行了原bug中的复现步骤，然后宣布回归完成

B人员执行了原bug的步骤，并把同模块的其他测试用例进行了一定的回归测试
       C人员执行了原bug步骤，并根据系统架构，把可能波及的点也做了回归测试

同样的问题，如果你是老板……？

     

柳舞随风

    六、快速测试模式的效率

       这是最考验测试工程师的测试任务。

在实际的工作中，除了正常的开发测试模型外，还有部分开发测试任务是临时性、定制性、紧急性的测试任务，比如打标测试。

常规的测试，我们可以依赖于完整的测试策略和测试计划、规格学习和讨论、测试用例编写评审、测试执行、bug分析和各种控制方法。但是紧急测试，前端的交付件可能不够全面，测试策略和测试用例也可能来不及构建。所以更多的测试执行和软件质量，就要求测试工程师对系统框架的熟悉情况，对各种测试工具的熟练应用，对测试策略和测试方法，测试环境构建方面都了如指掌。

   

七、敏感度

            敏感度是一个比较务虚的词，同时也没有特别具体的量化指标来考核。部分可借鉴的指标，比如bug遗漏率、测试用例补充数目、评审反馈问题数、案例编写数目等。

            借用上文说到的一个事情，就是不容易出现的问题点，一是需要责任心，另外就是需要敏感度。对系统的敏感度，对细节的敏感度。

举个例子，图像质量的测试，彩色的图像忽然变成黑白的，可能任何一个测试人员都能发现问题。但是每隔30秒，图像忽然颤抖一下，可能就需要一定的敏感度。

比如声音质量测试，声音输出始终断断续续，可能每个测试人员都能发现，但是每隔一分钟，有几个字被“吃”掉，就需要依靠测试人员的敏感度和责任心。

   八、业务熟练度

          业务知识的掌握和理解程度，在产品线的测试团队中，是根本，也是核心。在上述各种方面，已经阐述过业务知识导致的测试人员差异性：输出成果质量、排查问题的能力、回归测试覆盖度、快速测试模式等等。

     上面林林总总说了很多，但是还没有概括全面。如果有疑问，我希望提问者能观察大家彼此的差异点，然后尝试总结，学习。

     正像提出问题的人自己所说，你意识到有差异性，然后提出问题，这是很好的第一步。大家需要做的是第二步：观察学习高薪水的人，他们的做事方法和能力、业绩。第三步：就是模仿学习。

     自己发现问题，然后有良好的榜样在身边，也有明确的目标和途径在身边，这种提升能力和报酬的好机会，怎么能轻易放弃？

愚人

goopy

说的不错，很有道理

柳舞随风

修改了一下文章题目，RT

探路者

楼主讲的很好，但我有一些疑问：
1. 不同的人执行相同的用例，产出却不同，这是否跟用例设计人员有很大关系？ 如果用例设计得详细、全面，对用例执行人员的能力要求就会降低，测试结果的差异就会减少。
2. 对于"开发人员短时间内提供多个版本进行测试的情况"，这是不正常的现象。测试部门有权约束开发部门的版本提交，频率不能过快且开发必须进行自测，否则测试会被开发拖跨。
3. 既然有许多重复劳动，为啥不考虑自动化？

柳舞随风

楼主讲的很好，但我有一些疑问：
1. 不同的人执行相同的用例，产出却不同，这是否跟用例设计人员有很大关系 ...
探路者 发表于 2011-4-7 19:10

1、和测试用例设计人员有很大关系，这是一个比较久远的辩证题目：测试用例颗粒度的问题。颗粒度大，对测试执行人员的要求较高，节省测试用例构建的时间，需求变动对测试用例的冲击较小。颗粒度小，对测试执行人员的要求较低（所谓的民工也能做测试的论调），但是构建测试用例、维护测试用例、需求规格对测试用例的冲击太大。
     看公司测试团队的具体模式和偏重性。不同的公司不同的做法，理论上测试用例更新及时，测试执行人员执行有力的公司挺少的。

2、看具体公司的模式，测试部门和开发部门是以部门维度进行配合，还是测试隶属于开发部门，还是大家都在项目组里面，听项目经理的。不同的模式，测试服务的领导不一样会导致考核的方式不一样。是偏质量，还是偏项目进度等。不可一概而论。
     
3、重复劳动自动化，或者说自动化程度，取决于产品和团队、老板三个维度。一些行业的产品，用主流的测试工具无法实现自动化，或者只能部分实现自动化；团队来说，有没有自动化方面的储备；老板更现实，测试毕竟是讲投入产出比的一个投资，是黑盒搞定，还是养一些高级测试人员，不同的老板想法不一样的。

柳舞随风

楼主讲的很好，但我有一些疑问：
1. 不同的人执行相同的用例，产出却不同，这是否跟用例设计人员有很大关系 ...
探路者 发表于 2011-4-7 19:10

1、和测试用例设计人员有很大关系，这是一个比较久远的辩证题目：测试用例颗粒度的问题。颗粒度大，对测试执行人员的要求较高，节省测试用例构建的时间，需求变动对测试用例的冲击较小。颗粒度小，对测试执行人员的要求较低（所谓的民工也能做测试的论调），但是构建测试用例、维护测试用例、需求规格对测试用例的冲击太大。
     看公司测试团队的具体模式和偏重性。不同的公司不同的做法，理论上测试用例更新及时，测试执行人员执行有力的公司挺少的。

2、看具体公司的模式，测试部门和开发部门是以部门维度进行配合，还是测试隶属于开发部门，还是大家都在项目组里面，听项目经理的。不同的模式，测试服务的领导不一样会导致考核的方式不一样。是偏质量，还是偏项目进度等。不可一概而论。
     
3、重复劳动自动化，或者说自动化程度，取决于产品和团队、老板三个维度。一些行业的产品，用主流的测试工具无法实现自动化，或者只能部分实现自动化；团队来说，有没有自动化方面的储备；老板更现实，测试毕竟是讲投入产出比的一个投资，是黑盒搞定，还是养一些高级测试人员，不同的老板想法不一样的。

柳舞随风

楼主讲的很好，但我有一些疑问：
1. 不同的人执行相同的用例，产出却不同，这是否跟用例设计人员有很大关系 ...
探路者 发表于 2011-4-7 19:10

1、和测试用例设计人员有很大关系，这是一个比较久远的辩证题目：测试用例颗粒度的问题。颗粒度大，对测试执行人员的要求较高，节省测试用例构建的时间，需求变动对测试用例的冲击较小。颗粒度小，对测试执行人员的要求较低（所谓的民工也能做测试的论调），但是构建测试用例、维护测试用例、需求规格对测试用例的冲击太大。
     看公司测试团队的具体模式和偏重性。不同的公司不同的做法，理论上测试用例更新及时，测试执行人员执行有力的公司挺少的。

2、看具体公司的模式，测试部门和开发部门是以部门维度进行配合，还是测试隶属于开发部门，还是大家都在项目组里面，听项目经理的。不同的模式，测试服务的领导不一样会导致考核的方式不一样。是偏质量，还是偏项目进度等。不可一概而论。
     
3、重复劳动自动化，或者说自动化程度，取决于产品和团队、老板三个维度。一些行业的产品，用主流的测试工具无法实现自动化，或者只能部分实现自动化；团队来说，有没有自动化方面的储备；老板更现实，测试毕竟是讲投入产出比的一个投资，是黑盒搞定，还是养一些高级测试人员，不同的老板想法不一样的。

zxdqlzyfnx

最厌说得头头是道的人.实干就是个250