都是执行测试，大家的差异点在那里？（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秒，图像忽然颤抖一下，可能就需要一定的敏感度。比如声音质量测试，声音输出始终断断续续，可能每个测试人员都能发现，但是每隔一分钟，有几个字被“吃”掉，就需要依靠测试人员的敏感度和责任心。

　　八、业务熟练度

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

　　上面林林总总说了很多，但是还没有概括全面。如果有疑问，我希望提问者能观察大家彼此的差异点，然后尝试总结，学习。正像提出问题的人自己所说，你意识到有差异性，然后提出问题，这是很好的第一步。大家需要做的是第二步：观察学习高薪水的人，他们的做事方法和能力、业绩。第三步：就是模仿学习。

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