对测试工程师的建议

• 不要承担发布产品的责任

     当测试工程师对产品的发布有决定性权力的同时，也承担了产品质量的全部责任，团队中的其他成员会为此放松一点。如果测试遗漏了，导致线上bug，团队其他成员会置身事外，并责备测试工程师，为什么交付了存在问题的产品。另一方面，如果测试工程师延误发布，也会被追究被承担很大的压力。

    所以要由控制项目的人或者集体来决定是否发布产品。如果你被授权决定产品的发布，那么建议你毫不犹豫地坚持与项目团队的其他成员一起分担这种权力。

• 当心『事不关己，高高挂起』

      有些测试工程师认为，自己的工作内容就是找出产品和需求之间的差别，任何超出这个范围的问题，比如可用性问题、需求逻辑问题、兼容性问题、易用性问题等都『不关我的事』。建议改变这样的想法，测试工程师的职责是尽其所能，通知团队可能会对产品的质量产品消极影响的所有问题。

• 不要指望其他人会理解测试，或理解测试工程师需要具备怎样的条件才能做好测试

    开发或者产品可能会觉得测试很简单，点点点就可以。产品提出一个需求的时候，可能会觉得这个功能测起来非常简单，想要尽快上线。

• 进行技术性、创造性、批判性和实用性思考（如使用测试工具）
• 直觉可以是好的开始，但不能作为结束

     我们可以使用直觉来推断存在问题的地方，但不能作来作为合理性证明。当有『这是问题，因为它显然是问题』的想法是，我们可以换一种方式：这是个问题，因为它的行为与需求XXX不一致。

• 运用试探法快速产生测试思路

     由于可能的测试用例的数量是无限的，因为要选出在一定时间和预算等约束条件下有效的少量测试用例。有经验的测试工程师会收集并共享能够改进其猜测质量的测试试探方法。一组好的试探方法有助于快速地生成测试。

1. 测试边界。边界更可能暴露模糊问题
2. 测试所有错误消息。错误处理代码与主流功能代码相比，一般比较弱
3. 执行比较难想到的测试。在其他条件相同下，易于想到的测试更有可能已经被执行过
4. 避免冗余测试。如果某个测试实际上是重复其他测试，那么就不会产生价值。

• 注意其他测试工程师所发现的自己本来应该发现，但是没有发现的问题
• 如果遗漏一个问题，检查这个遗漏是意外还是必然

     抛硬币时猜正反面，猜错了，并不意味着策略上有问题，而是概率问题，除非在硬币上做了的脚。

     同理，如果是因为测试策略的问题，导致了测试的遗漏，那么就需要总结与改进；如果只是偶发的问题，那么保持原有方法不变。

• 困惑是一种测试工具，利用困惑

     当测试工程师感到困惑时，这可能是某种重要的预示。

1. 是需求没有说明清楚吗
2. 设计不规范吗
3. 产品不方便使用呈