如何用二八原则理解软件测试，你且看下文

前言

你如何理解软件测试？

软件测试属于软件开发过程的一个环节，与软件工程一起兴起于小型软件向大型软件开发额过渡期，按照中国人所说的人体是金木水火土的说法，如果用在软件工程上，那么测试就是一个对结构进行校验的作用。

按照我的理解，测试是一种思想，软件测试只不过是把测试思想用在了软件的开发过程当中了，测试是一种过程，从软件开发的微观上讲，他和软件开发的可以分离的，但是又会有联系，就像俩条平行线，开发出产品，测试测产品，就是这个样子。

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

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

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

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

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

此原则：

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

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

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

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

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

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

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

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

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

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

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

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

一、缺陷是解决不完的

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

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

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

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

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

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

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

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

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

三、缺陷是相对的

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

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

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

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

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

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

下面是一份非常优质的学习资源，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

以上软件测试资料需要的可以私信我都可以****

这还有一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中资料包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

学习不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。