相信很多做软件测试的小伙伴在软件测试后期，都为软件测试报告总结花费了很多的精力，那么如何做好软件测试报告呢？一份优秀的测试报告又包含哪些内容呢？

测试报告的核心要素

一、测试结论

从测试工程师的专业角度分析，是否达到发布标准，是否可发布 。如果你的测试报告，结论都没有，那这份报告的意义是什么？

二、风险

已知风险 & 未知风险 ，抛出。项目经理、产品经理等多部门，需要根据这份风险分析，确定最终这个版本是否发布出去。

三、测试时间 & 测试人员

这是非常重要的，投入了哪些人，用了多少时间，测试起止时间。

四、测试环境、测试设备

用到哪些测试手机，什么客户端环境，什么浏览器等等。

五、需求大纲

当前的这个版本，到底包含了哪些大的需求点。

六、Bug数据分析（非常重要的一点）

可以从多个维度分析， 比如，Bug等级分布，遗留Bug分析，Bug类型分布，模块Bug分布，Bug激活次数分析 等等（具体可根据公司实际情况，进行多维度分析）。

七、测试总结

从测试角度，对这个版本，你觉得存在的一些问题，一些建议，等等。

下面的我搜集的一些测试报告模板，需要完整版的可以关注我公众号【伤心的辣条】获取~

测试报告模板

一、XXX系统产品安全测试报告

1. 介绍

1.1 编写目的

本报告为XXX系统产品的安全测试报告，目的在考察软件安全性、测试结论以及测试建议。

2. 测试概要

2.1 测试方法和测试工具

本次安全测试，主要使用了账号安全管理、权限管理、安全日志、访问控制安全、输入安全、缓冲区溢出、SQL注入、跨站脚本攻击等安全测试方案。

针对以上提供的测试方案进行对应测试用例以及测试脚本编写,并使用APPScan作为安全测试工具。

2.1.1 账号安全管理

1、 账号的惟一性：系统中账号名称具有惟一性

（1） 普通用户、工程师、管理员具有惟一性；

（2） 是否有可能绕过系统的账号惟一性校验

2、 账号不能写死在代码中，须提供可管理机制

2.1.2 权限管理

1. 采用基于角色的账号权限管理模型

2. 授权和用户角色数据存放在服务器端

2.1.3 安全日志

1. 对安全事件以及操作事件记录日志

2. 检查系统是否对以上所以操作记录相应日志记录，包括用户ID、用户IP、时间、事件类型、操作来源（APP、网页）等；

2.1.4 访问控制安全

需要验证用户身份以及权限的页面，复制该页面的url地址，关闭该页面以后，查看是否可以直接进入该复制好的地址；

2.1.1 输入安全

XXX系统系统主要对没有被验证的输入进行如下测试：

数据类型（字符串、整形、实数等）允许的字符集、最小和最大的长度、是否允许空输入、参数是否为必须、是否允许重复、数值范围、特定的值（枚举型）特定的模式（正则表达式）等；

2.1.2 缓冲区溢出

没有加密关键数据：

例：view-source：http地址可以查看源代码

在页面输入密码，页面显示为加密字符****，右键鼠标，查看源文件就可以看到刚刚输入的密码。

2.1.3 SQL注入

例：一个验证用户登录的页面

如果使用的sql语句为：

Select * from A where username=’ ’ + username+’ ’ and password……

SQL输入or 1=1——就可以不输入任何password进行攻击，或者是半角状态下的用户名与密码均为：‘or’‘=’。

2.1.4 跨站点脚本攻击

分析：攻击者使用跨站脚本来发送恶意代码给没有发觉的用户，窃取他机器上的任意资

料。

2.1.1 测试工具

3. 测试组织

3.1 测试人员

4. 测试结果及缺陷分析

4.1 遗留缺陷列表

5. 测试结论

1） 本次测试覆盖全面，测试数据基础合理，测试有效。

2） SQL注入测试，已执行测试用例，问题回归后测试通过。

3） 跨站点脚本测试，测试发现已对相关特殊字符进行转义，测试通过。

4） 权限测试，已严格对相关角色进行权限控制，测试通过。

综合以上结论得出本次安全测试通过。

6. 测试建议

在系统研发时便需要逐步对相关字符进行转义，可列成安全文档，定义如何防范各种安全漏洞，以便在开发项目阶段直接杜绝问题。

测试模板太多，就不一一列举了，需要完整版本的记得转，发并S我噢~

---

最后：如果对软件测试、接口测试、自动化测试、技术同行、持续集成、面试经验交流。感兴趣可以进到 902061117，群内会有不定期的分享测试资料。

如果文章对你有帮助，麻烦伸出发财小手点个赞，感谢您的支持，你的点赞是我持续更新的动力。

好文推荐

2021软件测试工程师面试题汇总（内含答案）-看完BATJ面试官对你竖起大拇指！

什么样的人适合从事软件测试工作？

软件测试和软件开发哪个发展更好

那个准点下班的人，比我先升职了…

【备注】本说明书由华中农业大学2018级计算机科学与技术专业的刘畅、刘铠铭、张清望、卢家伟四位同学共同完成。

1 引言

1.1 编写目的

  编写本报告的目的是研究Asking软件的总体需求、背景。对开发结果、开发评价进行分析，得出经验与教训，本文档的预期读者为软件开发者。

1.2 背景

  该软件的名称为Asking，与之类似的软件有知乎、微博等软件，Asking软件的测试环境为浏览器。

1.3 术语和缩略词

无

1.4 参考资料

[1]窦万峰.软件工程方法与实践(第三版).北京：机械工业出版社，2016

[2]普莱斯曼.软件工程：实践者的研究方法(原书第8版).北京：机械工业出版社，2016

[3] 辣鸡搬砖喵喵团队.Asking需求规格说明书.

[4] 辣鸡搬砖喵喵团队.Asking软件概要设计说明书

[5] 辣鸡搬砖喵喵团队.Asking软件详细设计说明书

2 测试用例设计

（1）登录操作

表1 登录_第一组测试用例

测试用例编号	Asking_SignIn_001
测试项目	用户登录
测试标题	输入正确的用户名和与之对应的密码
重要级别	高
预置条件	系统存在该用户
输入	用户名123@qq.com，密码123
操作步骤	1打开Asking应用；2输入用户名123@qq.com；3输入密码123
预期输出	密码输入时被隐藏，提示用户“登录成功”

表2 登录_第二组测试用例

测试用例编号	Asking_SignIn_002
测试项目	用户登录
测试标题	输入错误的用户名或密码
重要级别	高
预置条件	系统存在该用户
输入	用户名456@qq.com，密码123
操作步骤	1打开Asking应用；2输入用户名456@qq.com；3输入密码123
预期输出	提示用户“您输入的用户名或密码错误，请重新输入”

表3 登录_第三组测试用例

测试用例编号	Asking_SignIn_003
测试项目	用户登录
测试标题	不输入密码
重要级别	高
预置条件	系统存在该用户
输入	用户名789@qq.com
操作步骤	1打开Asking应用；2输入用户名789@qq.com
预期输出	提示用户“请输入密码”

（2）创建问题操作

表4 创建问题_第一组测试用例

测试用例编号	Asking_Create_001
测试项目	创建问题
测试标题	创建后在搜索栏搜索该问题
重要级别	中
预置条件	用户成功登录
输入	标题“熊猫为什么这么聪明”，标签“生活”
操作步骤	1点击创建问题；2输入问题标签“熊猫为什么这么聪明”；③选择问题标签生活；④在搜索栏搜索这个问题
预期输出	1提示用户“问题创建成功”；2搜索栏下方出现该问题

表5 创建问题_第二组测试用例

测试用例编号	Asking_Create_002
测试项目	创建问题箱
测试标题	创建后通过链接和问题箱密钥搜索该问题
重要级别	高
预置条件	用户成功登录
输入	标题“熊猫为什么这么聪明”
操作步骤	1点击创建问题；2输入问题标签“熊猫为什么这么聪明”；③勾选问题箱选项；④把生成的密钥和问题箱链接分享给另一个用户
预期输出	1提示用户“问题箱创建成功”；2另一个用户点击链接，输入密钥，查看该问题

（3）删除问题操作

表6 删除问题_第一组测试用例

测试用例编号	Asking_Delete_001
测试项目	删除问题
测试标题	删除后在搜索栏搜索不到该问题
重要级别	中
预置条件	用户成功登录，问题“熊猫为什么这么聪明”存在
输入	无
操作步骤	1点击问题“熊猫为什么这么聪明”；2删除该问题；③在搜索栏搜索这个问题
预期输出	1提示用户“问题删除成功”；2搜索栏下方不出现该问题

表7 删除问题_第二组测试用例

测试用例编号	Asking_Delete_002
测试项目	删除问题箱
测试标题	删除后通过无法通过链接和问题箱密钥搜索该问题
重要级别	高
预置条件	用户成功登录，问题箱“熊猫为什么这么聪明”存在
输入	无
操作步骤	1点击问题箱“熊猫为什么这么聪明”；2删除该问题箱；③另一个用户用之前创建该问题箱时生成的密钥和链接搜索该问题箱
预期输出	1提示用户“问题箱删除成功”；2另一个用户点击链接，输入密钥，查看不到该问题

（4）回复问题操作

表8 回复问题_第一组测试用例

测试用例编号	Asking_Answer_001
测试项目	回复问题
测试标题	搜索问题后进行回复
重要级别	中
预置条件	用户成功登录，问题“熊猫为什么这么聪明”存在
输入	评论“熊猫棒棒”
操作步骤	1搜索问题“熊猫为什么这么聪明”；2在问题相方回复栏输入“熊猫棒棒”
预期输出	问题下方出现该回复

表9 回复问题_第二组测试用例

测试用例编号	Asking_Answer_002
测试项目	回复问题并点赞该回复
测试标题	搜索问题后进行回复并点赞
重要级别	钟
预置条件	用户成功登录，问题“熊猫为什么这么聪明”存在
输入	评论“熊猫棒棒”
操作步骤	1搜索问题“熊猫为什么这么聪明”；2在问题相方回复栏输入“熊猫棒棒”；③点赞该回复
预期输出	问题下方出现该回复，并且该回复的点赞量加一

3 测试结果及分析

3.1 测试环境

该软件的测试环境为windows10的浏览器。

3.2 测试用例执行

(1) 测试登录操作

1执行测试用例Asking_SignIn_001，运行结果如图1所示

​ 图1

图2

图3

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

2执行测试用例Asking_SignIn_002，运行结果如图2所示

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

③执行测试用例Asking_SignIn_003，运行结果如图3所示

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

(2) 测试创建问题操作

1执行测试用例Asking_Create_001，运行结果如图4-1、4-2所示

图4-1

图4-2

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

2执行测试用例Asking_Create_002，运行结果如图5-1、5-2所示

图5-1

图5-2

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

(3) 测试删除问题操作

1执行测试用例Asking_Delete_001，运行结果如图6-1、6-2所示

图6-1

图6-2

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

2执行测试用例Asking_Delete_002，运行结果如图7-1、7-2所示

图7-1

图7-2

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

(4) 测试回复问题操作

1执行测试用例Asking_Answer_001，运行结果如图8所示

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

2执行测试用例Asking_Answer_002，运行结果如图9所示

结果分析：实际运行结果与该测试用例预期输出一致，测试通过。

图8

图9

3.3 结论及建议

(1) 该软件实现了登录、创建问题、删除问题、回答问题等功能，基本满足测试标准，但仍需不断完善。

(2) 建议：登录时应该收到一个token作为登录后操作的权限证明，这样可以实现不同设备不同人无法同时操作同一个账号。

测试报告是测试的结果,也是测试机构向委托人提交的最终成果。测试机构的一切质量管理行为都是围绕保证测试报告质量实施的。因此测试人员,无论是从事管理的还是开展测试的,必须了解测试报告应完成的任务和质量把关的主要内容,充分认识测试报告对测试机构的重要性。

(一)测试报告应反映的信息

测试报告应包含委托和测试的所有信息。其来源为委托合同和原始记录中的信息，主要包括以下内容:

(1)委托:产品名称、委托单位、联系地址、监理单位、委托测试产品的内容和要求。

(2)产品资料:产品名称、开发单位、开发平台、开发语言。

(3)样品:样品名称、设计(委托)要求、样品(对象)的特征和技术状态描述、代表性、送样日期和样品委托编号及其标识。计算机软件测试申请表，功能技术指标列表，用户手册，软件安装包等。

(4)测试条件和依据:测试时间(如标准有要求应有开始和结束时间,并准确到分钟)、地点环境条件、采用的对测试结果准确性有影响的所有测试仪器设备(包括设备名称编号和检定/校准有效期)、测试参数检测依据的标准(包括方法标准和指标标准)及采用非标准方法的说明和有关文件的标识。

(5)测试结果和结论:测试数据、分析整理结果、与指标相对比的结论。

(6)含有分包结果的:①有能力的分包。本报告引用包含另一测试机构分包结果及说明。其报告中应明确分包项目，并注明承担分包的另一测试机构的名称和资质认定许可编号。②没有能力的分包。由承担分包的另一测试机构单独出具测试报告。若经客户许可，测试机构可将分包给另一测试机构的测试数据、结果纳入自身的测试报告,在其报告中应明确标注分包项目，且注明自身无相应资质认定许可技术能力，并注明承担分包的另一测试机构的名称和和资质认定许可编号。

(7)需要说明的问题:对使用的方法、环境以及测试中发生的偏离等情况予以说明。必要时应附以图表、数表、曲线、简图、照片说明测量、测试和导出结果，以及样品失效的有关证明。

(8)其他需要的说明:对除上述问题以外还有需要说明的问题应加以说明。

(9)审核与批准:审核人、授权签字人履行审核、批准职责,并应按要求在相应栏目签署姓名和日期。

(10)有效性声明:如本测试结果/结论仅对委托送样有效的声明、未加盖测试机构印章的复印件无效,未加盖骑缝章的报告无效的声明。本报告的著作权属测试机构所有,未经授权不得复制的声明。

(11)投诉:受理对报告不同意见或投诉的途径。

(二)测试报告的基本格式

测试机构的测试报告应设计规范统一的格式,内容和形式由专业技术人员根据测试参散的技术特点和要求提出，经技术负责人审批同意后使用。报告主要由封面、扉页、报告主页、附件组成。各部分一般包括如下内容。

(1)封面。测试报告名称、编号、测试类别(软件产品登记测试、科技项目验收测试、科技成果鉴定测试等)、委托项目、委托单位、测试机构名称、报告完成时间。

(2)扉页:相关问题的说明(如报告有效性的说明、投诉的受理方式等)、测试机构的地址、联系方式和联系人的姓名。

(3)报告主页:主页为统一制定的表格,栏目可根据专业特点适当修改，但信息应要求齐全。

(4)附件：综合性参数测试结果应以附件方式给出测试结果与指标对照的表格，分析图表、曲线也应在附件中给出结论，对有关问题的说明，以及应提交的有关材料等。

(三)测试报告的结论

测试报告的结论是测试报告的核心内容，也是委托方关注的主要内容，结论应按合同要求给出,不能遗漏;应按标准的要求给出。总之,结论应准确、得当、全面、严密。报告中的结论应注意以下方面:

(1)凡有相应指标规定的，应以指标为依据,结论应明确是否符合规定要求或是否合格。

(2)凡有相应设计文件对指标有规定的,应以设计指标为依据,结论应明确是否符合设计要求。

(3)凡需要通过统计分析才能给出结论的,应仅给出单次测试的结果,不给出结论。是否合格应由委托单位根据样品批的总体测试结果统计分析后自己给出，除非该数据已经足以判断样品批所代表的产品是不合格的。

(四)测试报告的校/审核

测试报告应根据测试机构的情况规定相应的程序进行校/审核,目的是消除测试报告中出现的差错,保证测试报告的质量。下面的审查过程可作为参考。

(1)试验室负责人或质量监督员可对测试过程进行监督并对原始记录和测试报告进行检查核对。

(2)由指定的技术人员对编写好的报告和原始记录进行技术性校核,并签字。

(3)已经定稿交付打印的测试报告(数量根据委托要求和测试机构留存),由技术管理室负责管理性审查,并具体提出是否可加盖CMA印章,并签字。

(4)经校核和管理性审查的测试报告,由测试机构指定的可以承担审核工作的技术人员审核并签字。

(五)测试报告的批准和保管

(1)经审核的测试报告由授权签字人按核准的授权范围的职权批准签发,任何情况下，其他人无权代替签字批准。

(2)技术管理室将签字盖章生效的测试报告按合同规定的要求分发给接受方。留存的报告正本与测试原始记录一并存档保管。

(六)授权签字人

(1)《检验检测机构资质认定能力评价检验检测机构通用要求》(RB/T214-2017)释义指出:“授权签字人是由检验检测机构提名,经资质认定部门考核合格后,在其资质认定授权的能力范围内签发检验检测报告或证书的人员。”检验检测机构的授权签字人是检验检测机构根据本机构报告审批的专业特点和需要推荐提名的、由依法组成的资质认定评审组依据《检验检测机构资质认定能力评价检验检测机构通用要求》进行专门考核合格并报国家认证认可监督管理委员会批准的,从根本上来说,其对授权范围的检测报告的签字批准的职权是获得国家认可的。因此,一旦获得确认之后,不经法定程序,任何人无权自行免除或代行其职权。

(2)授权签字人应按授权的专业范围和规定的替补顺序行使检测报告的批准签字职权,任何情况下,不得超越范围。

(3)授权签字人需要变更(免除或增加)的,检验检测机构应按要求向资质认定发证机关履行变更手续,并由依法组成的资质认定评审组对新推荐提名的授权签字人进行考核,合格后按程序上报国家认证认可委批准,方可获得对授权范围的检测报告签字批准。

(七)加盖印章

(1)检验检测专用章加盖在测试报告封面的机构名称位置或测试结论位置,骑缝位置也应加盖。加盖骑缝章应确保每页均有印章痕迹。

(2)在资质认定范围内出具的测试报告上予以使用资质认定标志，加盖(或印刷)在测试报告封面上部适当位置(一般在左上角位置)。

(八)对可疑结果的处理

(1)当怀疑、发现、得知有关于报告数据或结论有误的信息后,技术负责人应立即从技术管理室资料员处调阅原测试报告档案,迅速组织有关试验室的负责人、监督员和检测员对报告中的可疑数据或遗漏部分进行核查。

(2)在核查中对已发报告的数据和结论产生怀疑或发现问题时,技术负责人应立即起草一份书面文件通知所有测试报告的持有人，要求测试报告持有人暂停使用该编号为xxx的测试报告,申明待查实报告的数据和结论后再以书面文件告之。

(3)通知发出的同时,试验室负责人应认真组织实施对所有与测试有关的文件以及测试数据的核查,并根据与委托人签订的测试执行标准核查测试遗漏项日。

(4)试验室负责人应在核查结束时起草一份核查报告,指出存在的问题,提出修改或补充测试报告的处理意见。

(5)如果需要补充测试,则试验室负责人应提出补充测试的可行方案报技术负责人审批。

(6)批准后的补充测试方案,由试验室负责人组织实施并出具补充测试原始记录。

(7)试验室负责人根据补充测试原始记录和核查绪果,起草一份“测试报告的修改/补充文件”,必要时应提交新的测试报告，代替测试报告。

(8)试验室负责人起草的“测试报告的修改/补充文件"或新的测试报告应由试验室负责人签字后转至技术管理室审查。

(9)技术负责人应对“测试报告的修改/补充文件”中的修改或补充内容,以及发生测试问题的追溯情况进行分析审核,经审核无误后将“测试报告的修改/补充文件”或新的测试报告转至授权签字人批准签发。

(10)经授权签字人签发后的“测试报告的修改/补充文件”或新的测试报告由技术管理室盖章后按规定程序发出。

(11)“测试报告的修改/补充文件”或新的测试报告的发放应执行第七条的规定。“测试报告的修改/补充文件"或新的测试报告应发送到所有原测试报告的持有人。

(12)“测试报告的修改/补充文件”或新的测试报告应包含以下内容:①“测试报告的修改/补充文件”的标题，如测试报告的修改/补充通知书,新的测试报告应按测试机构专门设计的测试修改报告的格式提交。②与原测试报告中相同的或经核查应修改的所有关委托项目参数的信息，委托、监理测试机构以及联系人。联系方式的信息,样品的信息,测试依据、测试设备和检测环境条件的信息。③“测试报告的修改/补充文件”或新的测试报告的唯一编号标识和每页及总页数的标识。④补充测试的日期、地点使用的仪器设备和环境条件。⑤补充测试执行的标准或方法。⑥原报告的编号。⑦修改前和修改后内容的对照或修改说明。⑧更改原因的说明。⑨关于本“测试报告的修改/补充文件”或新的测试报告的使用和发放范围的声明,以及撤销原测试报告的再次申明。⑩修改/补充文件的编制人、校核人、审核人和批准人的签字。修改/补充文件的签发日期。

(九)测试报告的归档

(1)留存的测试报告正本应与委托测试协议(测试任务指令)原始记录、委托人修改测试方案的书面请求,以及分包测试和批准的例外允许申请等有关的文件一并归档保存。

(2)测试机构留存的“测试报告的修改/补充文件”应与原测试报告一并存档保管。

(3)原始记录与测试报告保存期应按规定实行。

(十)测试报告的发送程序和方式。

(1)技术管理室资料员应将待发的测试报告根据合同要求的寄达地址用挂号信函寄出。

(2)当委托人提出保密要求,则应通过机要部门按保密文件规定进行交接。

(3)如委托人提出通过电话或传真或电子邮件发送报告,则测试机构经办人应详细询问并记录委托人的姓名、电话、传真号码(电子信箱)、收件人姓名,还应认真仔细核对委托测试合同中的记录内容。

(4)当委托人提出索要测试报告的磁盘文件时,测试机构向委托人申明,测试报告的磁盘文件不具有法律效力,其结果仅供参考。

(5)发送报告的经办人应如实填写报告发送的有关信息,报告发送记录应包含以下内容:

①发送报告的编号。

②报告发送的数量。

③采用挂号信发送的应有挂号信回执单据,直接送达的应有接收人签字。

④通过电子信箱送达的(如委托人要求),应有接收人确认收到报告的电子回函记录。

⑤通过传真送达的(如委托人要求) ,应有接收人确认收到报告的回函记录。

⑥发送磁盘拷贝的(如委托人要求),应有接收人确认收到磁盘报告的回函记录。

⑦发送记录的汇总文件,经办人签字。

(十一)发送测试报告的保密要求

(1)测试机构的任何人员,不得违反规定私自发布、公布、评价测试结果,也不得通过任何方式向任何人透露测试数据和结果。

(2)除非委托人要求,测试机构禁止使用图文传真和电子网络发布传送检测报告。

(3)通过委托代理人领取测试报告,应凭有效的合法委托授权文件签字领取。

(十二)保密文件的交接

(1)有保密要求的文件(包括测试报告)应由机要部门经手交接,不得通过邮局邮寄。

(2)委托单位的保密文件应按委托时双方协商的方式进行交接。

(3)保密文件的交接必须严格履行规定程序,并留有记录。