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

 一、概述

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

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

1、复盘数据说明

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

（1）【需求】

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

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

                                                                      表A

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

（2）【用例】

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

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

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

                                                                              表B

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

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

•  A 优秀:  通过率 >=90 %    

• B 良好： 90% > 通过率 >=80%

• C 合格:   80% > 通过率 >=70%  

• D 差:  通过率 

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

                                                                                       表C

表格B、C字段说明：

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

• 阻塞数是指在本轮测试时间内因其他缺陷阻塞无法测试的用例，需要备注说明阻塞原因

（3）【缺陷】

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

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

                                                                         表D