一、80%的软件缺陷，集聚在软件20%的模块中
出色的测试人员会根据这个原则快速发现更多的缺陷(这个原则可以解释你的一个烦恼:为什么你经过几天的努力测试，没有发现任何缺陷；你老大慢慢走过来，随便点，新鲜发布三个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团队，经常跟产品经理，讨论如此火热的原因（每个人对预期结果的想法是不一样的）；
但，这里有一个点：作为一名软件测试工程师，你是可以通过接触足够多的行业软件/行业系统，去引导产品经理、开发工程师，按你的想法，达成你期望的结果；
这就是所谓的“用户体验测试”
最后:【可能给你带来帮助的教程】(评论区留言领取)
这一些资料，对做【软件测试】的朋友而言应该是较为完整了，这类学习资料也陪伴我走过了最艰难的路程，希望也可以帮助到你！万事要尽早，尤其是技术行业，一定要提升技术功底。