前言

在软件测试中有很多重要的指导原则，这些原则看上去大多是显而易见的，但是总是被我们忽略，作为虫师，我们当然应该把这些原则牢记于心，作为专业测试人员的基本素养。

测试用例中一个必需部分是对预期输出或结果的定义 这条原则是软件测试中常犯错误之一，但是如果不按照这条原则进行，由于“所见即所想”这样的一个心里现象的存在，某个似是而非的错误结果可能会被当成是正确的结论。解决问题的办法就是事先在设计用例的时候就精确地定义程序的预期输出，鼓励人们对输出的结果仔细检查。

因此一个测试用例必须包括两个部分：

对程序输入数据的描述；

对程序在上述输入数据下的正确输出结果的精确描述。

程序员应当避免测试自己编写的程序

这个大家都能够理解，因为亲自编辑或者校对自己的作品作品确实是有失公允的。当程序员“建设性”地设计和编写完程序之后，很难让他改变视角“破坏性”的来审视程序。但是我们要注意一点，这一条原则并不适用于“调试”，相反的，“调试”由程序员自己完成会更有效。

编写软件的组织不应当测试自己编写的软件

这一条原则的论据与上一条想死。虽然很多组织在某种程度上面成功地做到了这一点，但是更经济的方法是由客观、独立的第三方来进行测试。

应当彻底检查每个测试的执行结果

这条原则很多人觉得简直是废话，但是却还是常常的被忽略。我们见过很多大量的例子，即便错误的症状在输出清单中可以清楚地看到，但是还没是没有找到那些错误出来。

5.测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入结果

在软件测试的时候，有一个自然的倾向，就是将重点集中在有效和预期的输入情况上，而忽略了无效和未预料的情况。但是用户真正使用软件的时候，就有了很大的随机性，因此软件产品会突然暴露出很多问题在测试的时候未被预料到。因此，针对未预料的和无效输入情况的测试用例，似乎比针对有效输入情况的那些用例更能发现问题。

检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”

这一条原则是上一条原则的必然结果，必须检查程序是否有我们不希望的副作用。虽然程序员会觉得委屈：我做了更多的功能难道还错了吗？测试人员只能含泪点头：亲，确实错了。不论IT世界是如何的倡导自由开放，基本的规则还是要遵守的，给用户想要的，做到最好足矣。

应避免测试用例用后即弃，除非软件本身就是一个一次性的软件

饱含虫师们宝贵投入的测试用例，在测试结束之后就消失了，一旦软件需要重新测试，比如改正了某个错误或者作了某种改进，又必须重新设计这些测试用例。保留测试用例，当程序其他部分发生更动后重新执行，这就是我们所谓的“回归测试”。

计划测试工作时不应默许假定不会发现错误

测试，就是为了发现错误而执行程序的过程。

程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比

这个原则也叫缺陷的二八定理，指的是一般情况下，软件80%的缺陷集中在20%的模块中。我们测试的时候要抓住主要矛盾，如果发现某一个程序模块比其他模块有更多的缺陷，就要投入主要的人力和精力重点测试这20%的模块，以提高测试的效率。缺陷的二八定理成为缺陷的集群现象或者是虫子窝现象。

如果对软件测试、接口测试、自动化测试、技术同行、持续集成、面试经验交流。感兴趣可以进到902061117，群内会有不定期的分享测试资料。

如果文章对你有帮助，麻烦伸出发财小手点个赞，感谢您的支持，你的点赞是我持续更新的动力。