软件测试报告编写模板
本测试报告的具体编写目的，指出预期的读者范围。
实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试情况以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）并对测试质量进行分析。作为测试质量参考文档提供给用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理阅读。
（注意：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。）
列出本计划中使用的专用术语及其定义
列出本计划中使用的全部缩略语全称及其定义
|
缩写词或术语
|
英文解释
|
中文解释
|
|
|
|
|
|
|
|
|
列出本计划各处参考的经过核准的全部文档和主要文献。
对测试项目进行简要的说明。
对项目目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。
对测试项目的测试目的进行简要的说明，主要描述测试的要点、测试范围和测试目的。
简要说明测试开始时间与发布时间。
列出项目参与人员的职务、姓名、E-mail 和电话。
|
职务
|
姓名
|
E-Mail
|
电话
|
|
开发工程师
|
|
|
|
|
CVS Builder
|
|
|
|
|
开发经理
|
|
|
|
|
测试负责人
|
|
|
|
|
测试人员
|
|
|
|
对系统的结构进行简要描述。参考系统白皮书，使用必要的框架图和网络拓扑图能更加直观。
简要介绍测试用例的设计方法，使得开发或测试经理等人员阅读的时候容易对测试用例的设计有个整体的印象，特别是一些异常的设计方法或关键测试技术，需要在这里进行说明。
描述建立测试环境所需要的设备、用途及软件部署计划。
“机型（配置）”：此处说明所需设备的机型要求以及内存、CPU、硬盘大小的最低要求。
“用途及特殊说明”：此设备的用途，如数据库服务器，web服务器，后台开发等；如有特殊约束，如开放外部端口，封闭某端口，进行性能测试等，也写在此列；
“软件及版本”：详细说明每台设备上部署的自开发和第三方软件的名称和版本号，以便系统管理员按照此计划分配测试资源；
“预计空间”：说明第三方软件和应用程序的预计空间；
“环境约束说明”：建立此环境时的特殊约束。如需要开发外部访问端口，需要进行性能测试等。
|
机型（配置）
|
操作系统
|
软件及版本
|
SUN450
|
|
oracle8.1.2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
平台2：IBM
|
|||||
|
机型
|
IP地址
|
操作系统
|
用途
|
第三方软件及版本
|
预计空间
|
||||||
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
||||||
|
软件需求
|
用途
|
|
|
|
此项目将列出测试使用的工具以及用途：
|
测试工具
|
用途
|
|
自动测试工具
|
|
简要介绍测试中采用的方法和测试技术。主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。
这是测试报告的核心，主要汇总测试各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
|
需求/功能（或编号）
|
测试点描述
|
是否测试
|
重要等级
|
是否通过
|
备注
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
根据测试结果，按编号给出每一测试需求的通过与否结论。
需求覆盖率=测试通过需求点/需求总数×100％
测试覆盖是指根据经过测试的测试用例和设计测试用例的比值，通过这个指标获得测试情况的数据。
|
需求/功能（或编号）
|
测试用例数
|
执行数
|
未执行数
|
通过数
|
失败数
|
备注
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
测试覆盖率=执行数/用例总数×100％
测试通过率=通过数/执行数×100％
对测试过程中产生的缺陷进行统计和分析。
这部分主要列出测试过程中的所有bug，并对其进行描述。
|
序号
|
BUGID
|
描述
|
等级
|
模块
|
测试人员
|
开发人员
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.2.1.2 重要解决bug列表
这部分主要列出测试过程中产生关键的并且解决了的bug，对于重要的bug，需要对其产生的原因和解决方法进行分析说明。
|
序号
|
BUGID
|
描述
|
等级
|
模块
|
测试人员
|
开发人员
|
Bug分析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.2.1.3 遗留bug列表
这部分主要列出已经发现尚未被解决的bug，并对其进行描述，对于未解决的问题，需要在测试报告中详细分析产生的原因和避免的方法。
|
序号
|
BUGID
|
描述
|
等级
|
模块
|
测试人员
|
开发人员
|
Bug分析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
本部分对上述缺陷和其他收集数据进行综合分析
4.2.2.1 缺陷综合分析
缺陷发现效率 ＝ 缺陷总数/执行测试用时
可到具体人员得出平均指标
用例质量 ＝ 缺陷总数/测试用例总数 ×100％
缺陷密度 ＝ 缺陷总数/功能点总数
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。
4.2.2.2 测试曲线图
描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向。比如：
这部分简要地列出性能测试结果，并对测试结果进行分析说明，以说明是否符合软件需求。该部分也可以在性能测试报告中进行说明。
记录测试输出结果，将测试结果的数据表格，图表如实的反映到测试结果中。用于数据分析。例如：
|
短信数目
（万条）
|
时间
(秒)
|
平均速度
(条/秒)
|
最高速度
(条/秒)
|
最低速度
（条/秒）
|
IDLE占用率
(平均，%)
|
MEM使用率
(平均，%))
|
CPU使用率
(平均，%)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
记录测试输出结果。用于数据分析。例如：
在分别处理1万条神州行和全球通的MO短信的情况下，短信处理速度为400条/秒。
测试结果对比：IAGW1.1短信最大处理能力为330个条/秒，本次release的IAGW1.1性能略有提高。
各模块运行稳定。
这部分主要是软件质量量度的一个尺度总表，主要是对上述分析的一个总结。
|
项目
|
结果
|
描述
|
|
测试执行时间跨度
|
|
|
|
测试执行总天数
|
|
|
|
测试准备时间
|
|
|
|
测试总时间
|
|
|
|
软件Build次数
|
|
|
|
测试人力资源
|
|
|
|
测试硬件资源
|
|
|
|
测试项目总数
|
|
|
|
自动测试项目总数
|
|
|
|
推迟测试项目总数
|
|
|
|
未测试项目总数
|
|
|
|
测试案例总数
|
|
|
|
自动测试案例总数
|
|
|
|
成功测试案例总数
|
|
|
|
发现错误总数
|
|
|
|
修正错误总数
|
|
|
|
已知错误总数
|
|
|
|
测试执行时间细分
Accecpt Test
Smoke Test
Build First
Regress Test First
Build Second
Regress Test Second
Release Check
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这部分是测试报告中最关注的内容，主要是对测试过程产生的测试结果进行分析之后，得出测试的结论和建议。这部分为测试经理、项目经理和高层领导最关心的部分，因此需要准确、清晰、扼要地对测试结果进行总结。
说明该软件的开发是否达到了预期的目标，能否交付使用。
说明测试后可能存在的风险，对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响。
对测试计划执行情况以及测试结果进行总结，包括：
1．测试计划执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2．对测试风险的控制措施和成效
3．测试目标是否完成
4．测试是否通过
5．是否可以进入下一阶段项目目标
对软件的各项缺陷所提出的改进建议，如：各项修改的方法、工作量和负责人、各项修改的紧迫程度、后续改进工作的建议、对产品修改和设计的建议、对过程管理方面的建议等
版权声明：本文为Testingfox原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。