软件测试报告怎么写

以前写的东西 省略着写
XX软件测试报告 共 x 页 拟制 年 月 日审核 年 月 日会签 年 月 日批准 年 月 日
1 范围本文档适用于XX软件的单元/集成测试。1.2 系统概述1.3 文档概述本文档用于对XX软件的测试工作阶段成果的描述。包括对软件测试的整体描述，软件测试的分类和级别，软件测试的过程描述，软件测试的结果等内容。2 引用文档《XX软件需求规格说明》《XX软件设计说明》《XX系统接口协议》3 测试概述3.1被测软件的基本概况使用的编程语言：XXX 汇编语言程序行数：1590子程序个数：11单行注释行数：669注释率：约为42%3.1.1. 测试小结本次测试对XX软件进行了静态分析和动态测试。测试工作分为两个阶段。第一阶段进行了软件静态分析，软件测试人员和开发人员分别对软件V1.00版本的代码进行走读。在此基础上软件开发人员对代码走查中发现的问题进行了修改，做了97处代码变更并提交了V1.01版本进行动态测试。在测试过程中针对发现的软件缺陷进行了初步分析，并提交程序设计人员对原软件中可能存在的问题进行考查。在软件测试中首先根据软件测试的规范进行考核，将书写规范，注释等基础问题首先解决，其次考核软件测试中的问题是否存在设计上的逻辑缺陷，如果存在设计缺陷则应分析该缺陷的严重程度以及可能引发的故障。软件开发人员在以上基础上对软件的不足做出相应的修改，同时通过软件回归测试验证软件修改后能够得到的改善结果。 软件代码1.00与1.01版变更明细表： 编号 1.00版行号 1.01版行号 更改说明 1 19 22 注释变更 2 26 29 注释变更 3 29 32 注释变更 4 95 98 注释变更 5 108行后 113～116 增加新变量 6 171、172 180、181 命令字大小写变更 7 以下略 从上表可以看出，注释变更一共有15处，主要排除了对原程序的理解错误问题；根据程序的书写规范要求，一行多条语句改为一行一条语句的更改一共有42处；命令字大小写变更一共有7处；在代码走查中对冗余和无用的代码作了更改，将这些代码注释掉，此类更改一共有14处。上述4类更改一共有78处，这些更改对程序本身的功能没有任何影响，但从软件规范的角度来看提高了程序的可读性和规范性。其余19处变更为代码变更，主要是在软件测试中发现原程序的可靠性不足，在不改变原程序功能的基础上相应的增加了新变量、新语句、新程序以提高整个程序的可靠性。在动态测试阶段进行了单元测试和集成测试。此阶段发现的软件问题经软件测试人员修改，提交了V1.02版本，软件测试人员对此版本的软件代码进行了回归测试，确认对前阶段发现的软件问题进行了修改，消除了原有的软件问题并且确认没有引入新的软件问题。认定V1.02版为可以发行的软件版本。3.1.1.1 静态分析小结静态测试采用人工代码走查的方式进行。参加代码走查的软件开发人员有：（略）；参加代码走查的软件测试人员有：（略）。代码走查以代码审查会议的形式进行。静态分析过程中共进行了四次会议审查。静态测试阶段的主要工作内容是：l 根据对软件汇编源代码的分析绘制详细的程序流程图和调用关系图（见附件1）；l 对照软件汇编源代码和流程图进行程序逻辑分析、算法分析、结构分析和接口分析；l 对软件汇编源代码进行编程规范化分析。通过静态测试查找出软件的缺陷18个，其中轻微的缺陷4个，占所有缺陷的22.2％中等的缺陷11个，占所有缺陷的61.1％严重的缺陷：3个，占所有缺陷的16.7％上述软件缺陷见附件《软件问题报告单》3.1.1.2 动态测试小结动态测试使用的测试工具为XXX软件集成开发环境。总共的测试用例数：143个。全部由测试人员人工设计。其中单元测试用例138个，集成测试用例5个。发现的软件缺陷有2个，都是在单元测试过程中发现的。集成测试阶段未发现新的软件缺陷。在发现的软件缺陷中：中等的缺陷1个，占所有缺陷的50％严重的缺陷1个，占所有缺陷的50％上述软件缺陷见附件《软件问题报告单》动态测试中代码覆盖率：代码行覆盖率 100%分支覆盖率 100%程序单元调用覆盖率 100％3.1.1.3 回归测试小结对软件测试过程中发现的缺陷经软件开发人员确认后进行了代码更改，并对更改后的代码进行了回归测试。本报告中的数据是回归测试后的测试数据。3.1.1.4 测试分析下面将对此次软件测试中的所有缺陷以及改进设计进行分析。1． 静态测试中的缺陷分析： 1） 4个轻微缺陷属于代码冗余，由于在程序设计中加入了部分调试程序，在程序设计完成后未将这些调试代码注释或删除掉而造成代码冗余，但对程序本身的功能并无影响。修改后程序的效率得到提高。2） 11个中等缺陷属于注释变更，在原程序代码的注释中存在注释不准确的问题，会影响程序员对程序的理解，修改后的程序提高了程序的可读性。3） 重点分析3个严重缺陷：第一个严重缺陷属于XX号的无效判别和相应的处理问题，程序对XX号进行无效判别时，判别界限并不完全，在本跟踪程序中XX号的有效数为01-10（用4位表示），而判别无效时只判了为00的情况，没有判别大于10的情况。而且在为00时也没有作相应的处理，修改后的程序对设计进行了改进，详见改进设计分析3。第二个严重缺陷属于程序设计中读取地址错误问题，经分析在调试中读取的数据是正确的，但是读取的地址与设计初衷不相符，修改后问题得到了解决，详见改进设计分析1。第三个严重错误是近区/远区子程序判断与进入条件反了，经分析对程序的影响不大，但与设计初衷不一致，修改后问题得到了解决，详见改进设计5。2． 动态测试中的缺陷分析：1） 中等缺陷1个，在程序的注释中出现错误，将近区注释为远区，修改后问题得到了解决，提高了程序的可读性。2） 严重缺陷1个，在XX号无效的判别中，本应判断大于10，但误设计为0，修改后经回归测试问题得到了解决。 3． 改进的设计分析：（因和产品相关，略） 3.1.2 测试记录a 测试时间：2005年8月5日至2005年9月17日。b 地点：（略）。c 硬件配置：P4CPU/2.0G，内存256M，硬盘1Gd 软件配置：Wondows98，e 被测软件版本号：V1.0，V1.01，V1.02f 所有测试相关活动的日期和时间、测试操作人员等记录见软件测试记录文档。4 测试结果在两个阶段测试过程中共发现软件缺陷20个，经软件开发人员确认的缺陷为20个，经过改正的代码消除了所有以确认的软件缺陷并通过了回归测试。因测试条件所限，未能进行软件的确认测试和系统测试。5 评估和建议5.1 软件评估 5.1.1 软件编码规范化评估经过回归测试，未残留的软件编码规范性缺陷。软件代码文本注释率约为42%，代码注释充分，有利与代码的理解和维护。5.1.2 软件动态测试评估被测软件单元的总数：11个使用的测试用例个数：143个达到软件测试出口准则的软件单元数为11个，通过率100％通过单元和集成测试得知：软件代码逻辑清晰、结构合理、程序单元间接口关系一致，运行稳定。5.2 改进建议a. 建议在软件开发项目中全面实施软件工程化，加强软件开发的管理工作。b. 建议进一步加强软件需求规格说明、软件设计文档编制以及编写代码的规范化。特别是应该将系统中的硬件研制和软件研制分别管理，软件文档编制的种类和规格按照相关标准执行。c. 尽早开展软件测试工作。在软件研制计划安排上给软件测试留有必要的时间，在资源配置上给软件测试必要的支撑。d. 建议结合系统联试，开展软件的确认和系统测试。附件：软件问题报告单（略）软件更改通知单（略）软件测试记录（略）

测试分析报告
1 引言
1.1编写目的
说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
1.2背景
说明：
a. 被测试软件系统的名称；
b. 该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境 之间可能存在的差异以及这些差异对测试结果的影响。
1.3定义
列出本文件中用到的专问术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2测试概要
用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3测试结果及发现
3.1测试1（标识符）
把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
3.2测试2（标识符）
用类似本报告3.1条的方式给出第 2项及其后各项测试内容的测试结果和发现。
4对软件功能的结论
4.1功能1（标识符）
4.1.1能力
简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
4.1.2限制
说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
4.2功能2（标识符）
用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。
．．．．．．
5分析摘要
5.1能力
陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异 对能力的测试所带来的影响。
5.2缺陷和限制
陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。
5.3建议
对每项缺陷提出改进建议，如：
a． 各项修改可采用的修改方法；
b． 各项修改的紧迫程度；
c． 各项修改预计的工作量；
d． 各项修改的负责人。
5.4评价
说明该项软件的开发是否已达到预定目标，能否交付使用。
6测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。

摘要

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

关键字

测试报告 缺陷

正文

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

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

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测试方法(和工具)

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

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

测试分析报告
1 引言
1.1编写目的
说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
1.2背景
说明：
a. 被测试软件系统的名称；
b. 该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境 之间可能存在的差异以及这些差异对测试结果的影响。
1.3定义
列出本文件中用到的专问术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2测试概要
用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3测试结果及发现
3.1测试1（标识符）
把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
3.2测试2（标识符）
用类似本报告3.1条的方式给出第 2项及其后各项测试内容的测试结果和发现。
4对软件功能的结论
4.1功能1（标识符）
4.1.1能力
简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
4.1.2限制
说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
4.2功能2（标识符）
用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。
．．．．．．
5分析摘要
5.1能力
陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异 对能力的测试所带来的影响。
5.2缺陷和限制
陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。
5.3建议
对每项缺陷提出改进建议，如：
a． 各项修改可采用的修改方法；
b． 各项修改的紧迫程度；
c． 各项修改预计的工作量；
d． 各项修改的负责人。
5.4评价
说明该项软件的开发是否已达到预定目标，能否交付使用。
6测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。

摘要

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

关键字

测试报告 缺陷

正文

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

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

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测试方法(和工具)

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

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