在经历了多年的痛苦之后，我感觉已经找到了一条通往软件测试事业的道路。尽管如此，我还是忍不住感到沮丧，因为我花了这么长时间才找到一个有意义的答案。作为一名软件测试人员，我觉得我应该能够更快地找到答案，回顾我之前的工作，有几条纪律需要额外注意。
第一，覆盖范围广的正式测试比随机测试更好。当我们第一次接触一个系统是，总是想根据经验来解决它。也许应该控制参数长度？也许该改变参数类型？这些想法虽然都很正确，但更多的是基于猜测而非证据。
一次检查需要很多时间，结果却是不可控的。正式的测试用例设计也需要花费时间，但是它能得到明确的结果，之后还可以复用。
当一切正常时，随机测试是可以接受的，但当系统性问题出现时，随机测试毫无帮助，此时必须建立覆盖范围广的正式测试用例，确凿的证据胜过胡乱猜测。
运行一组已建立的测试，即使它们看起来很小，也可以在短时间内提供巨大的价值。
第二，当测试产生结果时，知道什么是“好”和知道什么是“坏”一样重要。通常，软件工程师只关注失败的测试，如果测试通过了，谁在乎呢？
当你试图考虑哪些参数格式可能引发异常时，也要看一看，用户常见的一些输入格式是否会引发异常。
第三，没有任何测试具有“完整”的覆盖范围。作为一名软件测试人员，永远应该有的担忧是测试无法完全涵盖产品行为。这就是为什么我们试图用拥有的资源最大限度地覆盖风险最大的因素，我们也会尽可能多地了解测试中的行为，以尽量减少未知因素。
第四，测试成本虽然贵，但值得一试。 软件测试的成本是非常高的，但是相比上线后可能产生的损失，测试行为是非常划算的。 许多软件团队回避常规的正式测试工作，因为他们不想花时间做这件事，也不想花钱请第三方的机构，这会为产品上线后的用户使用埋下巨大隐患，甚至决定产品的发展和增长，不重视测试的软件团队是不值得呆的，因为他的未来有很大的产品风险。
第五，测试结果只有得到纠正才具备意义。如果测试团队测试出的 bug 迟迟得不到修复，测试人员提出的建议总是被搪塞和延迟执行，软件的总体质量也会被侵蚀。
测试并不能提高质量，它只是指出质量问题。作为工程师，我们必须根据测试反馈改进软件行为，无论这意味着修复 bug、改善用户体验，还是针对已知问题发出警告。
版权归原作者 程序员小雷 所有， 如有侵权，请联系我们删除。