四个维度，拆解「软件测试中的80 / 20原则」

一、80% 的软件缺陷，聚集在软件 20% 的模块中

优秀的测试人员会根据这个原则，非常快速的找出较多的缺陷（这个原则可以解释一个你的苦恼：为何你苦苦测了几天，都没发现有啥缺陷；你老大慢悠悠的走了过来，随便点点，新鲜出炉3个Bug）。

普通的测试人员，非常焦虑 & 忙碌的加班加点，漫无目的地到处搜寻，一个Bug都没发现 。

此处，俗称：探索性测试；

在测试时间有限 / 测试人员有限的情况下，非常适用 。

此原则：

对于软件测试人员提高测试效率及缺陷发现率有着重大的意义

二、软件测试工作尽早介入

在需求阶段、系统分析、系统设计、系统实现阶段的复审，能够发现和避免 80% 的软件缺陷 。

老徐一直认为，测试的价值，不是测试出多少个Bug ，而应该去思考，如何减少缺陷流出到线上生产系统 ；

三、反映在软件测试的自动化方面

经过大量企业的实践证明，80% 的软件缺陷可借助人工测试发现， 20% 的软件缺陷可以借助自动化测试收到发现和避免。

二者间具有交叉的部分，尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

比如，测试右移的，线上监控、灰度测试 、日志分析 等等 ；

四、80%的缺陷，集中在某20%的开发工程师代码中 ；

IDO老徐在带质量部门的过程中，让每位测试同学详细分析各团队的开发人员，分析每位开发同学的过程缺陷数据；把有限的时间，集中在某几位同学提交的代码中；能够发现80%的Bug ；

注：还有很多企业落地实战，在践行 80 / 20原则 ；这篇文章，先写这四个维度 ；

另，关于软件测试的一些观念澄清：

一、缺陷是解决不完的

质量 & 效率的平衡 ，需把控一个适当的“度”

一味追求Bug 解决 100% ，期望一个缺陷不留，只会导致版本上线遥遥无期；对于99%的系统，这不是科学的玩法（特别是快速发展、迭代的电商等系统） 。

对于每位测试从业者，都需要去思考的一个事：“当发版时间临近，还存在一些Bug没解决完时，如何处理 ？”

老徐的建议是：拉上相关人（业务、IT老大、测试老大、项目经理），梳理Bug优先级，确定发版前必须要解决的Bug，可暂缓的，遗留到下个版本解决 ；

二、是不可能发现100%缺陷的

所以考核指标，才存在“线上漏测率”这个指标 。

软件测试能做到的是：尽可能多的发现软件的缺陷 ；

没人能够保证100%发现所有缺陷 ；这就是为何现在各企业在落地实战「测试右移」；

虽然不能发现100%的缺陷，但我们可以做到实时监控，以及在用户发现缺陷之前，把缺陷给“偷偷的”解决了（这就是老徐之前说的：软件测试从业者终极目标，线上零BUG如何实现 ？） ；

三、缺陷是相对的

除了明显的功能不可用、Error报错等；不符合预期结果，也可以称为“Bug” ；

如果连预期结果都没有，或者产品经理，根本就没有告诉你，这个点，应该是怎么样的 ；

这个时候，就得跟产品经理，好好勾兑，怼需求了；

这就是为何IT团队，经常跟产品经理，讨论如此火热的原因（每个人对预期结果的想法是不一样的）；

但，

这里有一个点：作为一名软件测试工程师，你是可以通过接触足够多的行业软件 / 行业系统 ，去引导产品经理、开发工程师，按你的想法，达成你期望的结果 ；

这就是所谓的“用户体验测试” ；

End 。