最近参与了几次面试，面试者的简历中都会提及：需求或者版本测试结束后会进行测试总结，不仅仅提供一份测试报告以及相关文档手册。

于是特意追问了一下，测试总结中都包含什么内容。

答复上基本都是：执行了多少用例、发现了多少问题、解决了多少问题，待解决的问题还有多少、bug的修复率是多少，很少有其它方面的延伸。

于是自己也思考了一些，整理了这篇文章，也希望大家多多补充，提提意见。

一、何为测试总结

区别与测试报告一般是针对开发完成编码后对开发质量的一个总结。

测试总结站的角度，更多是在整个软件研发过程中所有问题的总结，总结的范围相对更宽一些。

包含需求搜集阶段的问题、产品需求分析设计阶段的问题、开发设计编辑阶段的问题、产品测试阶段的问题、项目上线后反馈的问题的总结等等。

二、何时进行

1.需求测试或者发布测试结束后

此时进行总结更具有时效性，但缺少使用者对此版本的直接反馈，只能算是内部总结。

2.产品上线应用一段时间之后

此时总结，增加了客户使用后的反馈，更有利于从第三方视角反馈发布版本的质量情况及用户视角暴露的问题。

三、谁来组织/谁要参与

组织者：一般由测试经理或者对应项目的负责人发起。

参与者：项目经理、产品经理、开发经理、测试经理及其它相关人员。

四、总结形式/载体

1.召开总结会议（载体：word、excel、ppt、视频等），常用ppt。

2.邮件沟通反馈

3.视频会议等

具体形式因团队而已，重点要关注效果，总结后要形成可落地的改进计划。

五、总结内容

版本总结中应该包含哪些内容？

有那些量化的数据可以分析？

之前收藏了Vincent的一篇博客，，针对研发及测试阶段的分析说明已经很到位。

涉及到开发、测试计划偏离度的分析，缺陷类型、优先级、分布、质量趋势的分析，建议大家可以仔细拜读下。

里面涉及的内容这里就不再次体现，其他方面的内容这里做下补充，大家可以整合一份适用于自己公司的一套标准。

前边我们提到，要总结需求搜集阶段的问题、产品需求分析设计阶段的问题、开发设计编码阶段的问题、产品测试阶段的问题、项目上线后反馈的问题等。

1.需求搜集阶段

针对需求提交是否及时、是否符合提交规范、描述是否清晰、业务场景是否完备等几个维度进行统计分析。

如图中V1.0版本需求按时提交率只有75%，很有可能造成版本规划延期或者版本发布时间压缩。

根据相关数据及测试过程中产生的影响，针对需求搜集放提出相应建议，并要求需求搜集放给出相应的保障措施及计划。

一般提交需求的是客户的业务人员或者公司内部相关对接人员，相关建议和改进需要传递到这些人，并督促改善。

2.需求分析及设计

针对需求，产品是否按时审批、按时提交相关分析设计文档、组织相关需求评审沟通会议、插入需求占比等相等 。

此处插入需求占比，也可根据插入需求工时与版本规划工时进行对比统计。

此阶段的问题主要集中在产品，需要传递到产品去进行相应改进。

3.开发设计编码

针对开发设计提交及时性、开发计划按时完成情况、缺陷数量、缺陷密度、缺陷修复周期、缺陷分类、缺陷修复情况分析Vincent文章中已经说明。

下面我们从另外一个角度，人力成本投入角度去分析。

从上述看，我们能够发现开发在自测与设计阶段的投入较少，从而造成大部分精力都在修复BUG。

此阶段问题主要集中在开发，可建议开发：定期进行设计Review、代码Review，要求开发做单元测试，写自测报告等手段来提升开发质量。

4.产品测试阶段

针对测试用例、测试报告提交的及时性、版本发布内容提交的完备性、计划按时完成情况、缺陷遗留情况、客户，项目反馈问题情况进行分析。

下面我们从另外一个角度，人力成本投入角度去分析。

从上述看，测试在BUG与产品设计优化上的投入将近占了测试工作的一半，说明开发质量与产品设计存在一定的问题。这时测试工作需要左移，配合产品和开发，将一些问题扼杀在摇篮里。

5.项目上线后问题反馈

针对项目/客户反馈问题进行分析总结，类似缺陷分析，重点总结遗漏的原因及后需的规避措施。

上述看，场景遗漏导致的问题较多，需要质量部门重点关注，加强用例设计及评审，丰富完善测试场景。

六、汇总整理各部门总结并发布

基于测试总结过程中的数据分析，我们提出了对部门的建议。

针对提出的建议，各部门要配合梳理可落地的改进措施，汇总到质量部门，质量部门负责整理发布，并监督各节点的改进情况。以保障在下个版本测试过程中，相关问题能够得到有效的规避，从而提升工作的效率与质量。

针对上述各个阶段的分析总结，除了一些具体的数据以外，可以增加一些具体的案例，这样在分析总结是大家才能切身体会。

数据的背后不是吐槽那个阶段，那个环节做的不好，初衷是透过数据看本质，不断完善我们的工作流程，达到高效协作，高质输出的目标。