一、概述

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

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

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