❤️四个维度,拆解「软件测试中的二/八原则」❤️

陈大圣阁下 发表于 2021/10/12 17:03:47 2021/10/12
【摘要】 为何你苦苦测了几天,都没发现有啥缺陷;你老大慢悠悠的走了过来,随便点点,新鲜出炉3个Bug

一、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团队,经常跟产品经理,讨论如此火热的原因(每个人对预期结果的想法是不一样的);

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

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

【版权声明】本文为华为云社区用户原创内容,未经允许不得转载,如需转载请发送邮件至:cloudbbs@huaweicloud.com;如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。