大家好，我是十一，关于测试报告，还是有很多人想了解，今天带大家一起回顾下有关测试报告的内容。

前情回顾

概念：测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

前提：保障测试用例覆盖较全（最起码重点部分全部覆盖）的前提下，测试按计划完成，且测试用例执行100%，缺陷只有已关闭和已挂起两种状态时，开始准备测试报告。

内容：测试报告应包含首页、概述、测试概要、测试结果与缺陷分析、测试结论与建议、附录。

本篇内容

上篇文章中提到了测试报告中的很多内容，今天主要讲那些内容分别有什么用处。

首页

报告相应信息描述篇，通常包含如下信息：

1、报告名称

软件名称+版本号+用户端类型（android，iphone，后台管理等等）+测试范围（单元，集成，系统，模块等等）+测试报告，必填部分，例如：CRM1.0-移动端-集成测试报告，CRM1.0-移动端-性能测试报告等。

2、报告委托方

报告责任方，报告日期等，选填项，日期最好有，其他有则写，无则不写。

3、 版本变化历史

建议有，通常表格形式展示，测试/开发过程中的所有文档都必须经过审核，审核则可能会发生变动，这个表格就是为了显示变动情形，变动内容，变动时间、变动目的、变动作者、变动版本号。

4、 密级

加密级别，选填。

概述

概述部分通常是对本次测试任务做一个简单描述，包含任务来源（背景）、任务说明、任务目的、任务目标、任务中用到的相关术语描述、任务过程中参考的文档。

1、 背景：可选项。通常来说项目背景或者测试背景，指的是为什么要做这个任务/项目。

2、产品描述：必填项，描述产品是什么。

3、目的：必填项，此次任务的目的，比如：本次测试是为了验证产品/项目各个功能的符合任务书描述。可以与背景、产品描述一起合三为一做项目/产品概述。

4、任务目的：必填项，目标中描述本次测试的最终结果要求，比如：验证任务中规定的任务项，功能符合描述；所有的验收测试用例都执行完毕，且验收缺陷都验证通过。

5、术语和缩略语：列出设计本系统/项目的专用术语和缩写语。对于技术相关的名词和多义词一定要注明清楚，以便阅读时不会产生歧义。可选项。

6、参考文献：建议有，也是他人阅读理解时的参考物。通常是需求、设计、测试用例、手册、其他项目文档以及国家标准、行业指标、公司规范等等。

测试概要

测试活动的总结，包含但不限于：测试方法说明、测试范围、测试软硬件环境、测试所用到的工具、测试周期。

1、测试范围：本次测试的范围，通常来源于任务书。讲明本次测试的功能模块、性能任务、稳定性任务等等。必填项。

2、测试方法：测试所采用的方法，比如功能测试、性能测试、稳定性测试等等，可以包含在测试范围内，也可以单独写，注意两者内容不要重复。

3、测试环境：测试的软硬件环境，测试结果本身应该包含测试环境+测试结果，因为所有的测试结果都是依赖于测试环境的，在不同的测试环境下就有可能产生不同结果。故测试环境必须要描述清楚。必填项。

4、测试工具：测试中所采用的工具，有些测试结果是依赖于第三方工具得来的，采用不同第三方工具得到的结果可能不大相同，可信度受第三方工具本身可信度影响较大。故一定要列出，给读者以参考。建议必填。

5、测试周期：测试活动的周期，测试工作量的体现。可选项。

测试结果与缺陷总结

整个报告中的重中之重，这部分包括两方面，一个是软件测试覆盖评估，一个是测试结果的质量分析。

1、测试覆盖评估

测试覆盖是对测试完全程度的评测。是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

黑盒测试中通常使用基于需求的测试覆盖。它是分析现有的测试用例对软件需求的覆盖程度，是为了说明所设计的测试用例满足指定的需求覆盖准则。是衡量测试完成多少的一种量化指标。具体计算公式如下：

测试覆盖率 = Tx / Rft;

其中Tx表示的是已经执行的、已经成功的或者已经计划的测试用例数，Rft表示的是测试需求的总数。

2、质量分析

质量分析是对测试对象的可靠性、稳定性以及性能的评估。质量是反映软件与需求相符程度的指标，而缺陷被认为是软件与需求不一致的某种表现，所以通过对测试过程中所有已发现的缺陷进行评估，可以了解软件的质量状况。也就是说，软件缺陷评估是评估软件质量的重要途经之一。

软件缺陷评估我们通常从如下几个维度来分析：

a、按照缺陷状态统计：分析当前状态下bug的状态分布情况，比如总共多少，已解决多少，挂起多少，无法复现多少，拒绝解决多少等等，通过分析这个可以判断出测试是否可以结束，或者说测试是否已经达到可以结束的标准。

这里要注意下，报告中最好将拒绝解决和挂起的缺陷列出来，并且标明原因。

b、按照缺陷原因（分布）统计：分析当前状态下有效bug的类型，即产生原因，通过这个可以判断软件主要问题是哪些原因引起的。我们来看看通常产生缺陷的原因有哪些。尽管我们日常工作中遇到的bug类型数以百计，但是所有错误其实都可以追述到如下原因中的一个或者几个：

· 需求说明不完整或者说明错误

· 未按需求实现

· 违反编程标准

· 数据表示有错

· 模块接口不一致

· 设计逻辑有错

· 不完整或者错误的测试

· 不准确或者不完整的文档

· 没有考虑兼容性

· 编程时逻辑错误

· 页面错误

· 没有覆盖多场景

· 常识性错误

· 其他

这些每个公司会有自己的定义，但是大致在如上范围内，我们分析缺陷情况时也不用手动分析，缺陷管理工具直接生成如下图所示的图（下图是jira生成的）：

测试结论与建议

可以依据缺陷状态与缺陷分布图来分析：

1、通过分析缺陷状态来说明测试是否可以结束；

2、通过分析缺陷分布图来分析我们经常出现缺陷的原因，并且给出合理意见来改进过程。比如：上图中页面错误占比5个，占总数的18%，那么我们可以指定通用的页面规范，然后下发到每个开发与测试，以此为开发和测试准则，如此后续开发中可以很好的规避此类错误。

OK~，今天的内容到此结束。我们下期再见！Bye~