墨菲定律
墨菲定律的原话是这样的：Anything that can go wrong will go wrong。
凡事只要有可能出错，那就一定会出错。在测试工作中，我们经常会遇到这样的场景。
关注我，每天分享软件测试技术干货、面试经验，想进《Python自动化测试学习交流群》可以直接加V：atstudy-js
场景一
在需求评审阶段，我们凭借着以往项目的测试经验预感到这个项目的某些功能点或者某些环节会有潜在问题。
如果这个时候我们没有及时思考和评估并暴露出风险，等到开发人员完成项目编码并提交测试时，我们会发现，之前预感到可能发生的bug果然出现了。
场景二
在临近项目发布上线，项目依然还有严重等级比较高的bug需要修复，在开发人员的不懈努力下终于修复好了一个bug让我们去验证。
如果我们只是验证这个bug并不展开验证的话，开发人员与测试人员的“互相伤害”也就到此为止了，但是，出于职业意识，我们还是会去验证下该bug关联且有被影响风险的模块，结果就是，我们又发现新的bug。
关于墨菲定律，以上两个场景并不一定是完成成立的，但是在大多工作中，墨菲定律在测试工作得到了印证：当我们凭借经验预感到相关的风险时，如果我们没有及早暴露风险和问题，这些问题最后还是会发生。
二八定律
二八定律在软件测试领域是这样描述的：80% of all bugs can be found in 20% of program modules。
80%的问题可以在20%的模块中发现，换句话来说，软件系统中的问题存在群集现象，大部分的问题会集中在少数的模块上。
在软件项目开展过程中，如果我们没有对需求和研发方案进行必要且充分的评审，在测试过程中，我们就会发现并记录更多数量的缺陷。
开发类bug的统计结果如图2-1所示，软件项目中的bug确实存在群集现象，在少数模块或者功能上，集中了大部分的缺陷，而这部分模块，通常情况下就是软件系统或者是本次迭代中比较核心的功能模块。
图2-1 二八定律
木桶定律
木桶定律阐述了这样一个道理：A bucket's capacity is determined by its shortest stave。
一只水桶能装多少水取决于它最短的那块模板。如图3-1所示，软件系统的质量正如这个水桶的容量，其质量不是只取决于测试环节，而是同时取决于测试节点之前以及测试节点之后的所有环节。
如果任何一个环节的质量把控不好，整个软件系统的质量也会受之影响。
所以为了及早捕获系统缺陷，我们就要在更早的环节提前介入，尽可能地预防潜在的问题发生，将测试工作从测试环节向左移动。
为了保障系统发布后在线上正确稳定运行，我们需要持续跟踪线上系统的运行情况。
图3-1 木桶定律
本文分享的三大定律可能存在一定的片面性，但是想分享的思想是明确的：提高风险控制和质量保障意识，及早地发现和推动问题的解决。
其中：
·墨菲定律告诉我们要有风险意识和风险控制能力。
·二八定律告诉我们要识别工作中的主要内容和次要内容，预防软件系统中最核心且高风险的部分。
·木桶定律告诉我们软件系统的质量不仅取决用软件生命周期的某一个环节的质量，而是依赖软件生命周期中的每个环节，正如一只水桶能装多少水取决于它最短的那块模板，软件系统的质量也取决于那个质量最差的环节。