软件测试复盘思路个人总结

以下内容均个人总结，请尊重原创，转载请注明出处，谢谢

一、概述

对测试期间的测试工作和测试数据做简单复盘，目的在于从数据中找到项目管理过程中存在的问题，并对问题进行解决或对项目过程做优化。

先简单介绍下站在测试角度的复盘过程。

1、复盘数据说明

As we knows, 测试应该尽早参与到项目中，应该从需求接收阶段就开始介入，然后经过需求分析 → 测试分析 → 测试设计（用例）→ 测试执行 → 项目上线 → 测试总结这些阶段后，测试可以积累到【需求、用例、缺陷】这3大块数据，这3类数据就是测试用于复盘的重要数据。一般来说，我会对这3类数据做以下维度的复盘（需要注意的是，复盘并不是在最后一个阶段“测试总结”才做的事情，在项目进程中，就应该阶段性的使用这些数据进行小范围复盘；其次，复盘也不是一定要做的，当你觉得缺少数据帮你发现问题、说明问题严重性、做决策的时候，就可以用下面的数据做分析、复盘）：

（1）【需求】

首先，从【需求】这类数据，我们可以知晓，项目整体共划分了几个迭代？每个迭代有多少需求？

我会有意识的统计和收集，每个迭代计划要实现的需求是哪些？计划要提测的需求是哪些（因为有些需求可能不需要提测）？达到提测时间后实际提测的需求是哪些？未提测的需求后续计划是怎么样的？以及该迭代测试完成后，实际测试通过的需求是哪些？没有测试通过的需求后续计划是怎么样的？

	需求总数	计划提测需求数	实际提测需求数	需求测试通过数	需求提测率	需求测试通过率
迭代1
迭代2
总计

表A

当一个迭代即将结束或项目要上线的时候，通过这个表格，我们可以了解项目任务的完成情况，这些具体的数据可以帮助我们清晰的梳理出每一项任务的测试情况，如果有需求未提测或测试不通过，需要进而进一步分析风险是什么，按目前提测的、测试通过的需求是否可以上线.....

（2）【用例】

这类数据，我更多的应用在测试过程把控，同时可以作为衡量研发提测质量和项目质量的指标之一

在测试执行过程中，每天测试结束后，我需要知道总体的测试进度是多少？是否有阻塞？如果没有用例执行数据衡量的话，我们一般通过“感觉”去判断，然后给出一个进度，但如果测试的体量比较大的话，精确的执行数据会帮助我们的更好把控测试进度和风险。

在每一轮的测试执行过程中，我会用以下表格（表B）管理我本轮的测试数据：

模块	用例总数	有效用例总数	已执行	通过数	通过率	失败数	阻塞数	进度（已执行/有效用例总数）	取消数	未执行数
模块A
模块B
总计

表B

每一轮测试结束后，我会用以下表格（表C）管理我每轮测试的数据，除此之外，最好保存每轮测试的测试用例源文件（下一轮测试不要直接在上一轮的测试文件里修改），因为每轮“取消”、“阻塞”备注的原因可能不一样，最好保持源文件，以便我们在做最后的全局复盘的时候，可以根据需要找出当时的原因。

在这份表格里，我首要关注的是，每个迭代首轮的测试通过率，这个指标可以帮助我们衡量研发的开发质量，我觉得将研发开发质量划分为以下4个等级，还是很合理的：

A 优秀: 通过率 >=90 %
B 良好： 90% > 通过率 >=80%
C 合格: 80% > 通过率 >=70%
D 差: 通过率 < 70%

研发的开发质量说明了项目质量，项目质量当然是越高越好啦

其次，公司一般会要求研发自测，并在提测的时候提供自测用例执行情况（自测用例可以由研发自己写，也可以由测试提供）。
假设某功能，测试共设计了100条用例，其中20条标记为研发自测用例，研发承诺这20条用例都通过，才提测。则提测后，测试执行完这100条用例，统计下研发提测时承诺通过的20条用例，实际通过情况是怎么样的，比如20条用例中，经过测试后发现实际通过的只有10条，则10除以20这个指标则可以帮助我们衡量研发的自测质量。

这个指标，可以叫做，研发自测用例实际通过率。一般而言研发自测用例实际通过率要≥95%，才算自测良好。

轮次/迭代	提测时间	有效执行用例总数	用例通过数	测试通过率	用例阻塞数	异常取消数
第X轮/XX迭代						本列指因需求变更等原因导致的取消

表C

表格B、C字段说明：

“用例总数”是指测试人员设计的全部用例数，“有效用例总数”是指最终执行的用例数。在测试执行过程中，可能有些测试设计与需求不符，或者需求变更和删除不需要测试了，或者需求在本轮未提测等原因，则把这类已经被设计好的用例标记为“cancel”（需要在备注中说明cancel原因），归到“取消数”中。因需求不符、需求删除、需求变更而被取消的需求数不应太多，太多则需要引起注意：是否测试、研发、产品之间的协作有问题？是否因沟通不及时导致在测试执行过程中过多用例被取消？
阻塞数是指在本轮测试时间内因其他缺陷阻塞无法测试的用例，需要备注说明阻塞原因

（3）【缺陷】

最后是关于【缺陷】，这个阶段的数据最重要，不仅可以用于衡量研发提测质量，跟重要的是可以帮助我们发现流程、协作上的问题。项目前期埋的坑，在这个阶段基本都会暴露出来。但这个数据需要研发、测试共同按规范去维护，不然可能会不准确。

基本的缺陷分析维度：缺陷总数、缺陷修复率、缺陷等级分布、缺陷重新打开的个数和次数、缺陷类型

分析维度	说明
缺陷总数和缺陷修复率	迭代/项目的缺陷总数是多少？已关闭多少？未关闭多少？缺陷修复率=已关闭/缺陷总数严格的项目管理，需要规定要迭代或上线的准出条件，其中之一就是缺陷修复率要≥95%，如果有遗留问题需要评估遗留问题的风险，总之就是评估是否能带着这些遗留问题进入下一个迭代或者上线，并且需要明确遗留缺陷的修复时间
缺陷等级分布和严重缺陷占比	统计致命、严重、中等、轻微、建议（一般都是这个5个等级）的缺陷数量，其中严重缺陷占比不能超过8%（超过则表示研发质量一般，且需要做进一步原因分析），同时也需要关注其他等级的缺陷修复，如果某一等级缺陷分布过多，需要具体进一步分析原因，比如轻微+建议的缺陷特别多，可能是研发没有对这块进行自测或产品提供的交互不合理等，那测试就要给相关角色提问题、提需求
缺陷重新打开的个数和次数	返工是一种浪费，倡导一次性将事情做正确。通过这一指标来度量开发人员一次性正确修复缺陷的能力（研发的缺陷修复效率）。同时这个指标可以帮助衡量研发和测试的协作是否顺畅、测试人员提的缺陷是否准确等问题统计迭代内缺陷被重新打开的个数和次数，将每个迭代的数据做一个趋势图，通过看趋势，帮助我们看团队问题是否得到改善。
缺陷类型	测试过程中发现的缺陷一般分为如下几类：功能问题：不满足需求、功能实现错误；对产品或项目质量有影响的bug可统一划入；设计缺陷：页面美观性、交互友好性、错别字等用户体验：对产品、项目的建议性意见，不强制要求修改性能问题：进行性能测试时使用，如：网络延时、内存问题、CPU占用、硬盘问题安全问题：业务功能存在的安全问题接口问题: 涉及有模块间数据传递时使用配置问题: 由于提供的配置不当或者配置不能够满足实际要求而出现的问题假设从缺陷等级分布统计中，发现“轻微+建议”的缺陷比较多，我们可以通过缺陷类型进一步分析，这两个级别的缺陷类型是什么如果大部分缺陷类型集中为功能性，可能揭示了团队在其余质量指标的关注不足
缺陷解决方案分布	解决方案一般分为以下几种：已解决：研发按缺陷描述修复了缺陷延期解决：延后处理设计如此：无需改动重复bug：已有记录同样的bug 外部原因：非本系统原因无法重现：按复现步骤复现不了的bug 不予解决：因其他原因不予解决的bug 特别说明：其中“已解决”和“延期处理”的bug视为有效bug。如果无效bug数量过多，需要引起注意，具体进一步分析原因，是否测试对需求理解存在较多偏差？是否测试人员对缺陷的描述不够准确？无效缺陷分析：软件测试中的无效缺陷率分析 - 51Testing软件测试网
缺陷模块分布	这个模块帮助我们看到每个模块的缺陷情况，从模块缺陷分布可以看出，哪个模块的代码质量最好
缺陷生命周期	缺陷从创建到关闭的时间统计，反映缺陷修复效率问题，特别是级别高的缺陷，是否被及时得到解决？
缺陷趋势分析	缺陷趋势可以是每日新增(new)、每日关闭(closed)、累计活跃的(all-active)，累计关闭(all-closed)、bug总数的，通过分析缺陷增长和减少的趋势，分析来了解测试的效率和开发修复bug的效率、测试瓶颈、测试延期原因、测试生命周期等。（1）其中每日新增(new)趋势分析来了解测试的效率，正常看，提测准入通过的1-2天后每日新增应该在一个高峰值，总体呈下降趋势，最后趋向于0。整个测试周期，80%＋的bug发现在测试周期中前期，测试后期甚至回归测试的bug新增数趋于平稳到0，可以说明测试效率是比较高的，测试质量较高，且开发修复bug新引入bug的概率是比较小的（2）每日关闭(closed)趋势反映了开发对bug处理响应快，修复bug效率高，累计活跃的(all-active)bug得到收敛（3）如果新建的bug越来越少，但关闭的bug曲线一直在打开bug下面，说明，瓶颈在研发那边，他修改bug的效率过低（4）bug总数曲线和累计关闭(all-closed)应该呈对数曲线，坡度应当逐渐变缓，最后无限接近并且重合（5）如果累计活跃的(all-active)bug上升的坡度一直很陡，说明整个团队中，bug的平均生命周期长，越平滑越好。本指标分析摘抄自：浅谈通过缺陷分析进行项目质量分析 - 简书

表D