怎样写完整的软件测试报告？

Question

软件测试报告的格式是

Answer 1

摘要

测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。本文提供测试报告模板以及如何编写的实例指南。

关键字

测试报告 缺陷

正文

测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。

PARTⅠ 首页

0.1页面内容：

密级

通常，测试报告供内部测试完毕后使用，因此密级为中，如果可供用户和更多的人阅读，密级为低，高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。

XXXX项目/系统测试报告

报告编号

可供索引的内部编号或者用户要求分布提交时的序列号

部门经理 ______项目经理______

开发经理______测试经理______

XXX公司 XXXX单位 （此处包含用户单位以及研发此系统的公司）

XXXX年XX月XX日

0.2格式要求：

标题一般采用大体字（如一号），加粗，宋体，居中排列

副标题采用大体小一号字（如二号）加粗，宋体，居中排列

其他采用四号字，宋体，居中排列

0.3版本控制：

版本 作者 时间 变更摘要

新建/变更/审核

PARTⅡ 引言部分

1.1编写目的

本测试报告的具体编写目的，指出预期的读者范围。

实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。

提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。

1.2项目背景

对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。

1.3系统简介

如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。

1.4术语和缩写词

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

1.5参考资料

1．需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。

2．测试使用的国家标准、行业指标、公司规范和质量手册等等

PARTⅢ 测试概要

测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分）

2.1测试用例设计

简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类方法(3-4句)。

提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。

2.2测试环境与配置

简要介绍测试环境及其配置。

提示：清单如下，如果系统/项目比较大，则用表格方式列出

数据库服务器配置

CPU：

内存：

硬盘：可用空间大小

操作系统：

应用软件：

机器网络名：

局域网地址：

应用服务器配置

…….

客户端配置

…….

对于网络设备和要求也可以使用相应的表格，对于三层架构的，可以根据网络拓扑图列出相关配置。

2.3测试方法(和工具)

简要介绍测试中采用的方法(和工具)。

提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。

Answer 2

一.模板的使用
很多公司有测试报告模板，往往公司模板更新换代了，但测试人员仍然在沿用原来的模板（从原来的测试报告上修改）。轻则说明你粗心，重则说明你不关心公司的变化、磨洋工。我曾经遇到过真实的例子，有一同事使用旧文档模板，但实际公司的名字和Logo都发生了变化，发送到产品经理，后果肯定是测试报告被打回，并通报批评。如果极端点，测试报告放到更高层，如公司主要领导，那后果和影响不言而喻。
二.修订记录
修订记录应该在首页后，并标示清楚，是自己劳动成果的过程记录，这点也是测试人员容易忽视的地方。
有的测试人员，每次提交的测试报告，修订记录都只有一条。实际测试报告应该是有审查和修订过程的，比如你在发出测试报告之前，通常都应给测试经理审查过目，往往过后还会有些问题修订。如果不标识清楚，在测试经理可能提出的一些特别要求时，会让测试报告写作过程显得用了较长时间。这可能让公司高层客户认为你的能力不行，也不能让外部（如ISO审查组织）了解你们的工作合规性。
修订记录主要包括：修改时间、版本号、修订人、修订内容及审查人。
三.内容应该清晰易懂，简明扼要
不要把测试报告的内容写成一篇中篇小说。各种修饰词，流水话一大堆，导致看的人雾里看花，似是而非。
我看过有把测试报告写成文章的，通篇报告都是文字，“我认为”、“我想”、“他们应该”等一大堆称谓词，最后草草下个结论，让人不明所以。
测试报告应该尽量避免主观看法，加入一堆的主观认识。而应该客观的、简明扼要的把过程表述清楚。并且尽可能结合图文和表格辅以说明。这样的测试报告才令人赏心悦目，也让人一目了然，从而把测试结果很好地呈现给客户。
测试报告要用数据说话，比如本次测试的需求有多少，发现了多少问题，执行了多少用例。分析每个需求的用例数和bug数，通过覆盖率和二八原则分析风险点。
测试报告的内容往往针对很多读者客户，每个客户关心的内容不同，为方便快速查找，把测试报告按照客户关心的内容划分章节。
四.绝不放过一个错字
软件测试人员应该是一群吹毛求疵的人，如果自己的报告中有一堆错别字，哪怕是一个错别字，可能都会尴尬难堪。
原来就有同事非常粗心，导致测试报告出现多个错别字。而开发人员一句"平时找bug时，连一个错别字都被你单独列为一个bug，XX，你看你自己的文档有好多bug"，这个测试人员闹得非常尴尬。
最好的做法就是，写完测试报告后，自己一定要通篇检查一到两遍，这样严格要求自己，才能去高要求别人。
五.遗留问题单
没有闭环的bug，哪怕是往期版本遗留的bug，都应该用表格罗列出来，标明严重级别，给出每个bug的规避措施。
往往测试人员在一些外部压力下，容易把承诺修改但还来不及验证的bug在测试报告中抹去，或者有意疏漏。但这样不呈现出来，一发出去，可能高层不知道具体情况而做出错误的决策，导致后期出现人为的事故。
以前碰到过软件系统的一小工具，因为使用频率不高，所以bug经测试经理、开发经理和项目经理达成一致意见延期修复，但测试人员没有在测试报告中把这些bug呈现出来，导致市场人员在给用户演示是为了说明系统的强大，从而错误地展示了该有bug的工具，以至在用户面前出现冷场。
更极端的结果可能是，用户拒绝采用该系统。所以我们在测试报告中，应该把没有闭环的bug，哪怕是往期版本遗留的bug，都应该详细罗列出来。这样才能让公司高层或推广部门规避或作出应对措施。
六.产出成果恰当呈现
这一环常常是大家极容易忽视的一环。
往往测试人员的做法是，报告写好了直接发送一封带附件的邮件给客户，好点的可能会加几行文字。
但是，我想说，除了你的直接领导、平级同事外，其他客户往往是没有太多时间和耐心下载附件并仔细查看你的报告的，他们关心的是"现在的软件质量到底如何，是否能放给用户使用"。
最好的做法是在邮件内容页开头，写上测试结论、问题建议，并可以把主要的测试结果统计放在后面，最后才是附上完整测试报告的附件。
写一份测试报告不难，要写好一份合格高质量的报告需要我们花费更多的心思。本回答被网友采纳

Answer 3

XXX公司
XXX（产品或产品）/XXX（模块） 测试报告
1.概述
（1）测试目的
简述本次测试的目的，如：验证某模块是否符合设计
项目背景 简述测试所在项目的背景，如：XXX（项目）目前进入什么阶段，以及其他信息
（2）测试环境
硬件环境 仅针对测试对象的硬件环境及其版本信息加以说明
产品环境 仅针对测试对象的产品环境及其版本信息加以
说明
（3）测试人员
人员
角色
4.实际进度
占用时间 描述整个测试过程的时间跨度，如：xxxx-xx-xx至xxxx-xx-xx
进度情况 原因 如果测试提前或延后完成，请说明具体原因
5.测试参考文档
（1）《XXX测试计划》
（2）《XXX测试用例》
（3）《文档三》
（4）《文档四》
（5）版本信息 V1.0
6.测试数据
（5）测试数据
测试项总数
测试项编号
测试项
通过与否
PASS 0 PASS率
FAIL 0 FAIL率
问题描述
问题严重度
严重度——高 其中： 高--
严重度——中 中--
严重度——低 低--
问题严重度的界定：
高——导致系统死机或后续部分测试项功能不能实现；
中——影响该部分的测试功能的完整性且急需解决；
低——仅属于系统中的小bug，或根据测试过程发现的需要调整的部分，但并非急需解决。
7.项目的总结
对整个测试项目进行总结性阐述，如：测试是否通过，导致FAIL的主要原因。
8.意见和建议
针对本次测试工作，提出自己的意见或建议。没有可填“无”。

Answer 4

关于出具软件产品测试报告需要的周期问题，要根据项目的规模和测试机构的测试技术来看，毕竟软件产品测试一整套流程下来需要耗费人力物力资源，从测试设计到测试执行出结果都需要时间的。比如卓码软件测评做软件测试的话，快的话一到两周就能出具软件产品测试报告。

如何写完整的软件测试报告：

软件测试报告格式模板一般分为以下几个部分：

（一）引言部分；

介绍测试项目相关背景资料、用途、以及测试过程中所参考的相关资料；

（二）测试基本信息

1、测试范围；软件测试范围包含单元测试，集成测试和系统测试等。

2、测试设计思路；如何进行测试环境搭建，测试人员分配等。

（三）测试执行及缺陷分析

1、测试执行过程；这一部分主要介绍测试时间、如何开展测试工作，对系统稳定性、功能性能、界面情况开展的测试执行过程，测试过程中的冒烟情况，测试用例等。

2、测试缺陷分析；对测试过程中发现的程序bug进行记录，并分析可能带来的风险。

（四）测试结论与建议

得出测试结论并给出合理的修复建议。

来源：卓码软件测评