四个维度，拆解「软件测试中的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 。

1、之前写的一些数据调查文章：

关于这100位Tester，这里有几份数据报告 。

2019年软件测试从业者生存现状报告

1/3 的软件测试从业者，孤军奋战且薪资下降 。

软件测试群体，占比20%的专科生机会

60% 软测从业者是这样入行的，并一条路走到黑

测试从业者，提升工作效率的TOP 2 姿势

2、职业发展 + 知识体系 ：

软件测试人员职业发展方向2020

软件测试从业者知识体系大纲V2.0