测试报告模板
测试报告模板
引言
编写目的
| 编号 | 确定项目 | 描述 |
|---|---|---|
| 1 | 确定测试结论 | XXX 软件依据《XX需求文档》测试是否通过。 |
| 2 | 参与测试人员 | 整个测试阶段参与的所有人。 |
| 3 | 总测试用时 | 整个测试阶段所用的时间。 |
| 4 | 执行测试阶段情况 | 记录测试执行过程中，编写用例数量，发现缺陷数量，修复缺陷数量，缺陷分布情况，等信息。 |
| 5 | 缺陷数据统计 | 统计各模块出现数量，比例。 |
测试项目
项目名称 某某系统
此处编写你的项目描述！
服务器测试环境
| 编号 | CPU | 内存 | 硬盘 | 系统 | 软件 |
|---|---|---|---|---|---|
| 1 | 2.5 | 4+ | 100+ | Java、tomcat、…… |
测试参考文档
| 编号 | 文档名称 | 作用 |
|---|---|---|
| 1 | 需求文档 | 确定项目功能模块，功能运行结果。 |
| 2 | 技术文档 | 确定项目中使用开发语言，数据库数据限制。 |
| 3 | 项目模型文档 | 初步了解项目页面内容，方便编写用例。 |
| 4 | 测试计划 | 此文档根据测试计划执行内容作出总结。 |
名词解释
| 编号 | 分类 | 名词 | 解释 |
|---|---|---|---|
| 1 | 功能测试 | 模块名称 | 被测模块名称 |
| 2 | 功能测试 | 用例 | 执行用例数量 |
| 3 | 功能测试 | 缺陷 | 发现缺陷数量 |
| 4 | 功能测试 | 比例 | 发现缺陷的百分比。公式：用例 / 缺陷 * 100 |
| 5 | 功能测试 | 用时 | 执行测试用例消耗的时间。 |
| 6 | 功能测试 | 人员 | 执行测试用例测试人员。 |
| 7 | 兼容测试 | 浏览器 | 使用浏览器名称。 |
| 8 | 兼容测试 | 版本 | 浏览器版本 |
| 9 | 性能测试 | Vuser | 进行压力测试的虚拟用户数量。 |
| 10 | 性能测试 | Time | 施加压力的时间。 |
| 11 | 性能测试 | 响应时间 | 预计平均响应时间。从请求发送到页面加载完成耗时。 |
| 12 | 性能测试 | 实际响应时间 | 实际平均响应时间。 |
| 13 | 性能测试 | 情况 | 用例情况：Y=通过、N=失败。 |
| 14 | 性能测试 | 预计峰值 | 预计服务器最高承受Vuser数量 |
| 15 | 性能测试 | Max峰值 | 实际服务器最高承受Vuser数量 |
| 16 | 回归测试 | 缺陷分类 | 缺陷是哪个测试策略产生的 |
| 17 | 回归测试 | 缺陷 | 缺陷数量。 |
| 18 | 回归测试 | 修复 | 回测后成功的缺陷数量。 |
| 19 | 回归测试 | 修复率 | 缺陷修复比例。公式 修复 / 缺陷 * 100 |
测试概要
对“XXXX”进行的测试工作，具体涉及各大模块测试。根据《XXX测试计划》通过测试，使系统符合《XXXX需求文档》中的需求标准，实现全部功能。
测试用例设计
-
等价划分： 将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
-
边界值分析法： 确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
-
场景法： 通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
- 基本流： 是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
- 备选流： 一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）
-
因果图： 利用图解法分析输入的各种组合情况，设计测试用例，检查程序输入条件的各种组合情况。
-
正交表： 在界面中有多个控件，控件之间有多种组合关系，如果组合的数量巨大（一般超过20种），没有必要将所有组合都测试，可以通过正交排列法将组合中最优，最少的组合进行测试。
-
正确性测试： 输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
-
容错性（健壮性）测试： 程序能够接收正确数据输入并且产生正确（预期）的输出；输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
-
完整（安全）性测试： 对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
-
接口间测试： 测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
-
数据库测试： 依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
-
压力测试： 输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行，进行测试。
-
错误推测： 主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
-
效率： 完成预定的功能，系统的运行时间（主要是针对数据库而言）。
-
可理解（操作）性： 理解和使用该系统的难易程度（界面友好性）。
-
可移植性： 在不同操作系统及硬件配置情况下的运行性。
-
回归测试： 按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员。
-
比较测试： 将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。
-
兼容性测试： 操作系统的兼容性测试内容不仅包括软件的安装，还需对关键流程和功能点进行检查。而需要测试哪些操作系统的兼容性，首先取决于软件用户文档上对用户的承诺，其次就需要对一些常用操作系统兼容的检查
-
历史版本兼容性测试： 某些功能存在新版本和历史版本数据显示、页面展示不一致的问题。需要不同版本进行测试。
测试结果及缺陷分析
测试执行情况与记录
功能测试
| 编号 | 模块名称 | 用例 | 缺陷 | 比例 | 用时 | 人员 |
|---|---|---|---|---|---|---|
| 1 | 后台/联合出版 | 100 | 5 | 5% | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 2 | 后台/账户信息 | 84 | 7 | 8.3% | 2019-03-03 – 2019-03-06 3天 | |
| 3 |
易用测试
| 编号 | 模块名称 | 缺陷 | 用时 | 人员 |
|---|---|---|---|---|
| 1 | 后台/联合出版 | 100 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 2 | 后台/账户信息 | 84 | 2019-03-03 – 2019-03-06 3天 |
兼容测试
| 编号 | 浏览器 | 版本 | 缺陷 | 用时 | 人员 |
|---|---|---|---|---|---|
| 1 | IE 浏览器 | 9 | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 2 | IE 浏览器 | 10 | 2 | 2019-03-03 – 2019-03-06 3天 | 赖文举 |
| 3 | IE 浏览器 | 11 | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 4 | QQ浏览器 | 35 | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 5 | 360浏览器 | 40 | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 6 | 搜狗浏览器 | 9 | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 7 | 谷歌浏览器 | 61 | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 8 | 火狐浏览器 | … | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 9 | 世界之窗 | … | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 10 | 欧朋 | … | 1 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
数据完整性
| 编号 | 模块名称 | 用例 | 缺陷 | 比例 | 用时 | 人员 |
|---|---|---|---|---|---|---|
| 1 | 后台/发布图书 | 100 | 5 | 5% | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 2 | 后台/注册 | 84 | 7 | 8.3% | 2019-03-03 – 2019-03-06 3天 | |
| 3 |
性能测试
| 编号 | 模块名称 | Vuser | Time | 响应时间 | 实际响应时间 | 情况 | 人员 |
|---|---|---|---|---|---|---|---|
| 1 | 后台/联合出版 | 100 | 8H | >3m | 2.18m | Y | 赖文举 |
| 2 | 后台/账户信息 | 100 | 8H | >3m | 2.18m | Y | 赖文举 |
| 3 | 组合测试 | 500 | 8H | >3m | 5.19m | N | 赖文举 |
压力测试
| 编号 | 模块名称 | 预计峰值 | Max峰值 | 用时 | 人员 |
|---|---|---|---|---|---|
| 1 | 后台/联合出版 | 200 | 300 | 2019-03-01 – 2019-03-03 3天 | 赖文举 |
| 2 | 后台/账户信息 | 150 | 200 | 2019-03-03 – 2019-03-06 3天 | |
| 3 |
可靠测试
| 编号 | 模块名称 | Vuser | Time | 情况 | 用时 | 人员 |
|---|---|---|---|---|---|---|
| 1 | 后台/联合出版 | 100 | 8H | Y | 2019-03-01 >1天 | 赖文举 |
| 2 | 后台/账户信息 | 100 | 8H | N | 2019-03-01 >1天 | 赖文举 |
| 3 |
负载测试
| 编号 | 模块名称 | Vuser | Time | 用例 | 缺陷 | 用时 | 人员 |
|---|---|---|---|---|---|---|---|
| 1 | 后台/联合出版 | 100 | 8H | 15 | 3 | 2019-03-01 >1天 | 赖文举 |
| 2 | 后台/账户信息 | 100 | 8H | 15 | 3 | 2019-03-01 >1天 | 赖文举 |
| 3 |
回归测试
| 编号 | 缺陷分类 | 缺陷 | 修复 | 修复率 | 用时 | 人员 |
|---|---|---|---|---|---|---|
| 1 | 功能测试 | 15 | 10 | 100% | 2019-03-01 >1天 | 赖文举 |
| 2 | 易用测试 | 15 | 10 | 100% | 2019-03-01 >1天 | 赖文举 |
| 3 | 兼容测试 | 15 | 10 | 100% | 2019-03-01 >1天 | 赖文举 |
| 4 | 数据完整性 | 15 | 10 | 100% | 2019-03-01 >1天 | 赖文举 |
| 5 | 性能测试 | 15 | 10 | 100% | 2019-03-01 >1天 | 赖文举 |
| 6 | 可靠测试 | 15 | 10 | 100% | 2019-03-01 >1天 | 赖文举 |
| 7 | 压力测试 | 15 | 10 | 100% | 2019-03-01 >1天 | 赖文举 |
| 8 | 负载测试 | 15 | 10 | 100% | 2019-03-01 >1天 | 赖文举 |
功能测试结果报告
缺陷提交/修复情况（天）
按照模块分类（缺陷数量）
按缺陷严重等级分类
按缺陷提交者分类
按照修改者分类
性能测试结果报告
每秒事务数量分布图
服务器资源使用情况
事务平均响应时间
每秒钟吞吐量
负载测试缺陷模块分类（提交/修复）
压力测试工具不同，所生成的报告结果不同，没有贴图，但是jmeter，LR 都有响应报表！
测试结论与建议
测试结论
系统功能测试结果表明，“XXXX”项目基本实现了需求规格说明书中提出的功能，无任何逻辑错误和功能遗漏，基本具备可用性，可以交付用户使用。对于本次测试中已发现而未能解决的问题，应尽快给出相应的解决方案，在下一版中进行解决和完善。
建议
- 建议用户使用较高配置的服务器，以提高运行速度。
- 开发人员在以后的开发过程中应强化需求设计和设计过程控制，对各模块进行更加完善的开发。
- 在系统友好性方面还要加强。