软件测试培训
美国上市软件测试培训机构

400-111-8989

热门课程

软件测试系列-版本质量总结的纬度

  • 时间:2018-07-06 15:07
  • 发布:软件测试培训
  • 来源:网络

在一些大的团队,一般会有专职的角色来负责质量管理,即QA。QA在每个项目或版本结束时,追本溯源,重新审视项目过程,从不同纬度来分析版本的各种数据,从而挖掘出整个研发流程和团队存在的问题,进行流程改善和质量、效率提升。

那么通常可以从哪些方面来进行版本质量分析呢。

1 开发交付质量

项目研发流程里的第一个环节是资源规划:包括设备利用(硬件设施的分配)、资金(开发资金的来源和使用目的)、人力分配(开发团队的组建)、时间安排(开发周期)。资源规划制定好后,才能有秩序的开展研发工作,按时按质研发和提测,才能保证项目最终按时交付。

从准时提测率、一次性提测通过率、首次提测案例通过率、失败再次提测平均时间四个维度来分析,有利于监督开发提测质量和效率,让整个项目的进度处于可控的状态。

但是开发角度对QA 所进行的交付质量监督表示排斥的,所以前期的交付时间、交付标准务必要要求明确,才能保证数据源的准确性和完整性。下方通过一个示例来体现计算公式,示例来自某个项目的开发提测数据:

准时提测率=提测未延期次数/提测总次数(即3/4=75%)

一次性提测通过率=一次性提测通过次数/提测总次数(即2/4=50%)

首次提测案例通过率=首次案例提测通过率求和/提测总次数(即375%/4=94%)

失败再次提测平均时间=失败再次提测时间总和/失败提测总次数(即2/2=1H)

2 发版质量监测

2.1 发版质量

通常发版失败的主要原因主要有:生产环境与测试环境差异过大、生产包或生产环境漏改或改错相关配置文件、测试环境无法测试或漏测、多个子系统相互依赖,可能导致某个子系统发版本时,需要等待另一个子系统也发出对应版本,这样版本间形成等待关系和依赖关系,最后可能导致发版失败。

2.2 发版时效

发版时效是指一个项目开始准备部署发版到最后发版成功的时间。所以发版时效跟发版流程有直接关联。

下方通过一个示例来体现计算公式,示例来自某个项目的发版时序:

发版一次性通过率=发版一次性通过次数/发版次数(即0/1=0%)

发版时效=离场时间-部署准备时间(即5.5H)

部署时效=部署完成时间-部署实施时间(即2H)

测试验证时效=测试进行首次发版验证的时间,不包含问题回归的时间(即2H)

发版时效一般可能是大于等于测试验证时效+部署时效,因为可能有修复生产验证发现的问题和进行回归(如上表的差值1.5H)

通过统计发版质量和时效,分析发版数据,有助于清晰的看到项目项目生产与测试环境期间的问题,针对环节中人力和时间损耗大的点进行改善,有助于减少发版频率和发版人力损耗,敏捷项目流程,实现构建即上线。

3 版本bug数据

从项目初期的产品需求PK,到开发阶段的自测、迭代提测、集成上线提测,直至发布后用户反馈,bug几乎贯穿了产品发展的各个阶段。

这是一份bug清单,被隐去了某些项目内部信息。

正常一个bug描述以及跟踪过程所必须的字段有:系统、版本、项目、主题、模块、提交人、引入者、问题类型;各个项目根据实际需要也可以有一些自定义的字段,比如下方示例取自我所在项目的bug清单中的:端(为了区分不同的开发团队)、测试阶段(为了分析项目周期中bug的走势)

对于测试人员来说,提升对产品的理解,做好bug的提交、跟进和分析,能够更高效、更有效的测试,并能够更好的把控和提升项目质量。

3.1 bug状态分布

根据bug状态的分布,可以看出有效和无效 bug 的占比,已解决和未解决问题的占比,从而看出 bug 的质量以及版本的质量。

非缺陷:一般出现原因为两种,一是对测试同学对需求理解有误误报了bug,一种是需求不明确或不完善导致的bug。这两种都是应该在项目中优化和避免的。

缺陷遗留:一般出现原因为两种,一般是因技术难点或架构原因难以修改导致的bug遗留,但缺陷遗留必须是开发、产品、测试、PM等多方共同商议达成一致才可遗留

后续解决:一般是一些体验和优化问题,对用户使用影响不大,多方确认下个版本再修复的。

正常一个项目发版时,这几项特殊状态的bug都应该占比极少。

3.2 bug级别和模块分布

一般情况下,用例和bug的级别可分为四级,这是大多数公司对于用例和bug级别的标准定义:

当各等级的 bug占比严重出现偏差时,需要分析具体原因。如果紧急和高的bug过多,可能是开发质量太不过关。如果是低的bug过多,可能是产品需求设计不够好,或者是测试同学发现深度bug的能力欠缺。

在软件开发中有着八二原则:80%的bug是由20%的代码造成的,90%的停机是由10%(甚至更少)的缺陷造成的。bug总是集中爆发在某几部分代码中,特别是严重的bug。

bug数排前或者 bug 等级偏高的几个模块,即不稳定模块,不仅是开发和测试的关注重点,是重构和回归测试的依据,也是一个研发项目要改善和提升的重点模块。并且可以针对各个模块的bug具体原因进行分析,比如是CMS配置问题、代码质量问题、接口设计不合理、还是需求规则不明确导致的问题,从而针对性的一一改善。

3.3 bug责任人分布

可以从bug提交人、bug引入者、前端、后端问题几个详细维度去分析。如果项目区分了前端开发、后端开发、H5开发,则还要区分下对应的责任人。

从bug责任分布,可以明显的看出测试同学的bug数排名,以及开发的bug数排名。对于代码的质量、测试和开发同学的工作能力、以及工作量投入产出评估都具有参考价值。

3.4 bug生命周期和生长趋势

bug生命周期以bug创建日期算,bug关闭日期结束。各个项目、各个测试阶段都会有bug生命周期的标准,比如某个项目SIT测试期间要求bug日清,那么bug的生命周期正常情况下应该不超过24H。

bug生长趋势是指一个项目或版本进行期间,每日bug增长和关闭的曲线。理想的项目流程中,新增和关闭的bug曲线伴随着项目的进行应当是有个一致坡度的增幅和减幅的。

正常情况下,80%以上的bug应该在模块化测试及STORY阶段被发现,SIT集成期间发现与集成有关的bug,而UAT和PVT期间发现的bug数应该极少趋向于零。

3.5 典型bug案例

另外还可以从一些典型bug案例上进行分析。比如:

选择比较有特性难以发现的bug,分析一下测试的方法和测试粒度

选择测试用例未覆盖的bug,根据bug补充测试案例

4 线上用户反馈

4.1 问题反馈

收集市场和各种反馈渠道上用户的问题,对整个版本的质量进行一个更加深入的了解,毕竟测试期间能够覆盖的机型,能够覆盖的场景还是有限的,不可能模拟到大千用户。

分析Crash日志,进行分析和归类,快速相应解决问题。

4.2 运营数据

关注版本的留存、日活、月活、停留时长等是另一个纬度对版本质量的分析。

总之,从版本总结的角度,追溯项目流程中涉及到的各个角色,各个环节,各个bug,各个踩过的坑,思考后续如何避免类似问题,在下次测试中得到提升,在下个版本的项目流程中进行优化改善,提高质量和效率才是根本目的。

上一篇:软件测试中的移动端的埋点测试(干货)
下一篇:测试分布式系统的线性一致性

达内4月软件测试免费训练营开班啦!

迈出编程,要怎么做?

选择城市和中心
贵州省

广西省

海南省