五、回归测试的覆盖度
回归测试的执行，按照书本上的理想模式或职业憧憬中，应该是这个样子：开发人员对提交修复的bug，填写仔细的问题产生原因、修复策略方法以及回归测试建议。测试人员根据开发人员填写的信息，在测试用例库中选取回归测试用例，并执行回归测试用例。
但很多公司在实际执行时，因种种现状，回归测试的深度和波及面，更多的会依赖于执行回归测试的人员的职业素质：比如业务熟悉程度，比如责任心。
建立一个回归测试的流程，对团队的积累（软件）和过程质量控制的投入（硬件）的要求是比较高的。提高回归测试质量，最快速有效的方法，就是提高测试工程师的业务能力和自我的责任心（属于末端反控，治标不治本的方法）。
面对同样的回归测试，还是有几个人，假设分别表现如下：
A人员执行了原bug中的复现步骤，然后宣布回归完成
B人员执行了原bug的步骤，并把同模块的其他测试用例进行了一定的回归测试
C人员执行了原bug步骤，并根据系统架构，把可能波及的点也做了回归测试
同样的问题，如果你是老板……？
六、快速测试模式的效率
这是最考验测试工程师的测试任务。在实际的工作中，除了正常的开发测试模型外，还有部分开发测试任务是临时性、定制性、紧急性的测试任务，比如打标测试。常规的测试，我们可以依赖于完整的测试策略和测试计划、规格学习和讨论、测试用例编写评审、测试执行、bug分析和各种控制方法。但是紧急测试，前端的交付件可能不够全面，测试策略和测试用例也可能来不及构建。所以更多的测试执行和软件质量，就要求测试工程师对系统框架的熟悉情况，对各种测试工具的熟练应用，对测试策略和测试方法，测试环境构建方面都了如指掌。
七、敏感度
敏感度是一个比较务虚的词，同时也没有特别具体的量化指标来考核。部分可借鉴的指标，比如bug遗漏率、测试用例补充数目、评审反馈问题数、案例编写数目等。
借用上文说到的一个事情，就是不容易出现的问题点，一是需要责任心，另外就是需要敏感度。对系统的敏感度，对细节的敏感度。
举个例子，图像质量的测试，彩色的图像忽然变成黑白的，可能任何一个测试人员都能发现问题。但是每隔30秒，图像忽然颤抖一下，可能就需要一定的敏感度。比如声音质量测试，声音输出始终断断续续，可能每个测试人员都能发现，但是每隔一分钟，有几个字被“吃”掉，就需要依靠测试人员的敏感度和责任心。
八、业务熟练度
业务知识的掌握和理解程度，在产品线的测试团队中，是根本，也是核心。在上述各种方面，已经阐述过业务知识导致的测试人员差异性：输出成果质量、排查问题的能力、回归测试覆盖度、快速测试模式等等。
上面林林总总说了很多，但是还没有概括全面。如果有疑问，我希望提问者能观察大家彼此的差异点，然后尝试总结，学习。正像提出问题的人自己所说，你意识到有差异性，然后提出问题，这是很好的第一步。大家需要做的是第二步：观察学习高薪水的人，他们的做事方法和能力、业绩。第三步：就是模仿学习。
自己发现问题，然后有良好的榜样在身边，也有明确的目标和途径在身边，这种提升能力和报酬的好机会，怎么能轻易放弃？
相关链接：
