测出Bug就完了？教你从4个方面分析缺陷√

科技 2024-07-03 17:30 上海

测试团队在项目或版本测试完成后，需要对本次项目或版本所发现的缺陷做统计分析，在分析的过程中，总结项目或版本在哪些方面可以进行改进，为下个项目或版本的管理，做更好的管理和风险预防。

分析缺陷一般从以下角度来进行：

以某个项目为例，此项目共涉及6个关联系统，整个项目周期，发现的缺陷数共508个（缺陷数已按等级进行换算）。下面从各方面分析缺陷的分布情况。

从缺陷的根本原因上分析

上表中，根本原因中，各项内容的含义如下：

文档问题

指的是在静态测试（包括文档的正式及非正式评审）时，测试人员发现的各类文档的问题，投产手册的问题。

程序代码问题

程序存在各种的代码问题，程序未按需求功能实现等。

需求分析不全

需求分析不全面导致的部分场景或功能未实现。

需求变更

由于出现缺陷，导致需求需要变更。

环境问题

部署操作不正确；
参数设置没按投产手册要求执行；
控版出错（含：未与生产同步、未与上一个版本同步等）。

数据质量问题

不符合需求的测试数据，测试中产生的脏数据。

项目组的问题由程序代码问题、需求分析不全和文档问题组成。

其中，程序代码问题的占比是最高的，程序代码问题表现在：一是程序员在编码时只考虑正常场景的情况，一些异常和特殊的场景的情况都没考虑到；二是修改一个缺陷后，引出另外的缺陷。

需求分析不全、和文档问题，加起来占比6.7%，从另一方面说明项目组不重视文档及文档质量，对功能分析不透彻。

从以上可以看出，项目组需要加强文档编写质量、需求的充分评审和代码评审及走查。测试交付团队方面的问题，数据质量问题和环境的问题共占比9.8%，数据质量问题单项占到6.3%，这个比例偏高，测试团队应该管理好测试数据的质量，以免由于不合规的数据浪费大家的时间和精力。

环境问题，交付团队应该在项目或是版本开始时，测试环境的配置与生产环境的配置一致，以保证测试版本的有效性，在部署时，需要与测试团队先做沟通，避免一些没有必要的环境问题。

从缺陷发现的阶段分析

测试分析阶段处于测试人员对需求文档、概要设计文档的评审（评审包括文档的测试和评审会），这个阶段的缺陷数，主要由文档问题、评审问题组成。

测试执行阶段包括冒烟测试、第一轮、第二轮和回归测试。在这个阶段，测试团队对整个项目或是版本做全面的测试，用各种测试方法来验证项目或版本是否符合上线标准。

冒烟测试：只对项目或是版本做主流程的验证。
第一轮、第二轮测试，是执行所有的测试用例，对所有的功能做全面的验证，测试类型包括了功能测试、性能测试、可靠性测试、安全性测试、接口测试等等。
回归测试是对项目或是版本做全面的回归测试，包括第一或第二轮测试过程中，本来测试通过的用例，再加上此次未改造的功能。
补丁测试，指的是在项目或版本已经定版后，仍存在非改不可的，影响流程性的缺陷。

各个阶段出现的缺陷数量，也可以分析项目组或是测试团队在哪个阶段是否有问题。

从缺陷的引入系统上分析

缺陷数已按等级进行换算：

系统2和系统3的改造量排名第一和第二，难道就证明了改造量大的，出的缺陷就多吗？

也不是，像系统4的改造量只是比系统3少了10%，但缺陷数却少了3分之一。

虽然系统与系统之间的缺陷没有什么可比性，但如果加上各个系统的开发工作量，计算出各个系统的缺陷密度，虽然可比性的不大，但是以整体来看项目组的程序质量来说，这样子有一定的可比性了。

缺陷密度以1为基准，缺陷密度高于1的系统，可能需要分析一下程序的质量，看问题出在哪里。

从测试漏检上分析

此次项目上线运行一个月内，生产上出现的故障数量如上表所示。从上面可以看出，测试团队在漏检的问题上占了3个，是总故障数量的一半，且测试分析遗漏一个，用例遗漏一个，而执行还遗漏了一个，这说明测试团队的内部存在流程或沟通的问题。需要测试团队进行分析具体的原因。

总结

以上从各个方面来分析项目或版本的缺陷，都是希望从各种渠道来了解项目组和测试团队的情况，分析是否他们存在内部规范或是流程上的问题，需在哪一方面做进一步改进措施。

除此之外，还能收集各团队的项目指标，与公司的基准数据做对比，看是否与之相匹配，是否存在改进的方面，能以更好的姿态去迎接下一次挑战。

End

声明：本文为51Testing软件测试网陆空用户投稿内容，该用户投稿时已经承诺独立承担涉及知识产权的相关法律责任，并且已经向51Testing承诺此文并无抄袭内容。发布本文的用途仅仅为学习交流，不做任何商用，未经授权请勿转载，否则作者和51Testing有权追究责任。如果您发现本公众号中有涉嫌抄袭的内容，欢迎发送邮件至：editor@51testing.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。

点分享

点收藏

点在看

点点赞

http://mp.weixin.qq.com/s?__biz=MzU1MjI2MzA0Mw==&mid=2247511725&idx=3&sn=e8bd760b492eef0e74c92d19d7b93fc3

51Testing软件测试圈

博为峰20周年，青春正当燃，一起向未来！博为峰51Testing软件测试圈——坚持以专业技术为核心，关注软件测试领域最前沿技术和管理思想，凝聚行业力量，共同分享软件测试理论与实践经验，是一个测试人的生活与技术圈。

最新文章

比Selenium好用！用这款工具来做UI自动化测试效率翻倍！

测试工程师要进阶，就得明白这3点！

Web自动化神器——Selenium+Helium最佳拍档~

专职自动化测试期间，我的5个思考与结论

测试大佬亲自下场，教你怎么做UI自动化测试！

测试成果量化工具|关键绩效指标那么多，这6个最关键！

【大咖专访】13年软件测试经验，我总结了这10个质量保障策略

功能测试都做不好，就别想其它了吧！

测试新手如何有序开展工作？大佬有话说~

工作太闲？这样写周报，工作饱和度提升300%！

面试5家公司拿3个Offer，大佬的面试经验全总结给你了！

Charles使用功能详解，你学废了吗？

裁员的风吹到了2024，软件测试行业的下一个风口在哪里？

如何有效选择回归测试用例集

鉴权是什么？测试员一定不能错过的内容！

完胜LoadRunner！Jmeter并发性能测试总结

这款超好用的自动化测试工具，就是我的神！

APP专项测试，提高用户体验和产品质量

玩转自动化测试工具Puppeteer：这个高级玩法，你一定要知道！

功能测试都做不好，就别想其它了吧！

运用实战案例深入学习JMeter，干货满满

WPS连崩3次！果真软件崩都逃不出这4大原因！测试人必看！

性能测试进阶：提前设定TPS如何做测试？

测试人员必备测试技能！猛戳学习~

【鸿蒙专题】掌握这3点，快速入门鸿蒙测试！

测试结果居然还能这么用？！

一种让需求更明确，团队更高效工作的技术—BDD

测试用例评审会议开得好，事后甩锅没烦恼！

面试必问的7大测试分类！一文说清楚！

浏览器开发者工具下的一些技能！

从普通测试到测试管理岗，你差的就是这份测试管理流程！

4大类75项BUG场景大盘点！测试人必看！

白盒测试你了解吗？点击查看详情！

自动化测试会取代手工测试？谁说的！

亲测好用！巧用国产大模型Kimi生成测试用例，只需5步！

Postman接口测试，这里可以看教程！

良好的开端是自动化测试成功的一半：攻克首页验证码登录难题

告别肉眼检测！测试必会的自动识别检测字体大小的方法

接口自动化之Postman，搭配实战演练

低代码平台实战：5个数据集案例分析及高效测试技巧

性能测试工程师成长之路（第五讲）

测出Bug就完了？教你从4个方面分析缺陷√

亲测有效！性能压测异常竟能自动化分析！

JMeter分布式部署实践详解，看看总没错！

从由来到工具，一次性讲清契约测试！

车载通信测试的11个关键点：从基本功能到国际化支持

测试人员必须掌握的浏览器开发者工具下的一些技能！

不写脚本也能做自动化测试！这么省时省力的方法是我能看的么？

如何提高系统可靠性？混沌测试故障场景分析法太香了！

从零开始，深入学习接口测试及管理！

分类

时事

民生

政务

教育

文化

科技

财富

体娱

健康

情感

旅行

百科

职场

楼市

企业

乐活

学术

汽车

时尚

创业

美食

幽默

美体

文摘

原创标签

时事社会财经军事教育体育科技汽车科学房产搞笑综艺明星音乐动漫游戏时尚健康旅游美食生活摄影宠物职场育儿情感小说曲艺文化历史三农文学娱乐电影视频图片新闻宗教电视剧纪录片广告创意壁纸头像心灵鸡汤星座命理教育培训艺术文化金融财经健康医疗美妆时尚餐饮美食母婴育儿社会新闻工业农业时事政治星座占卜幽默笑话独立短篇连载作品文化历史科技互联网

发布位置

广东北京山东江苏河南浙江山西福建河北上海四川陕西湖南安徽湖北内蒙古江西云南广西甘肃辽宁黑龙江贵州新疆重庆吉林天津海南青海宁夏西藏香港澳门台湾美国加拿大澳大利亚日本新加坡英国西班牙新西兰韩国泰国法国德国意大利缅甸菲律宾马来西亚越南荷兰柬埔寨俄罗斯巴西智利卢森堡芬兰瑞典比利时瑞士土耳其斐济挪威朝鲜尼日利亚阿根廷匈牙利爱尔兰印度老挝葡萄牙乌克兰印度尼西亚哈萨克斯坦塔吉克斯坦希腊南非蒙古奥地利肯尼亚加纳丹麦津巴布韦埃及坦桑尼亚捷克阿联酋安哥拉