目录
一、引言
1.1 编写目的
1.2 项目背景
1.3 适用范围
1.4 专业术语
二、测试任务
2.1 测试范围
2.2 测试目标
2.3 参考文档
2.4 提交文档(交付件)
三、测试进度
四、测试资源
4.1 人力资源
4.2 环境资源
4.3 测试工具
五、测试策略
5.1 功能测试
5.2 压力测试
5.3 负载测试
5.4 兼容测试
六、测试完成标准
6.1测试充分性
6.2测试有效性
七、风险和约束
7.1流程约束
7.2风险分析
八、问题严重程度描述和响应时间规范
九、审批签字
入行软件测试的人员最需要掌握的基本功有三：设计测试用例、发现缺陷、撰写测试报告，透过这三个基本功基本可以摸清一名测试人员的专业度及其在其他方面的测试技能熟练程度，而从测试报告可以看出用例设计和发现缺陷两项基本功是否扎实，本文简短的梳理了软件测试报告需要包含哪些基本内容。
特别备注：本文案例是笔者所在项目的实践，仅作为互联网软件研发质量保证参考，因地制宜的实施，而不是时机不成熟就统计，那可能本末倒置，甚至带来负面影响。
一、引言
1.1 编写目的
本文档涵盖了测试范围、测试需求、测试策略、测试方法、测试工具、测试资源、测试交付文档、风险分析等内容，为后续的测试工作提供清晰的流程，确保测试工作有效地进行。
| 编号 | 确定项目 | 描述 |
| 1 | 确定测试范围 | 确定被测项目中功能模块，子功能模块等需要测试的范围。 |
| 2 | 确定测试需求 | 确定每个功能结果定义，确定此功能是否存在缺陷。 |
| 3 | 确定测试策略 | 确定对项目做哪些测试。如：功能测试，性能测试等。 |
| 4 | 确定测试方法 | 确定对每个策略是用哪些方法。如：边界值，等价类等。 |
| 5 | 确定测试工具 | 如: 功能测试使用Selenium，性能测试使用jmeter等。 |
| 6 | 确定测试资源 | 测试需要的服务器、测试人员、任务分工，测试工作的进度。 |
| 7 | 确定测试交付文档 | 确定测试工作中生成哪些文档，可提交文档有哪些。 |
1.2 项目背景
随着人们生活水平的提高，目前汽车已经成为大众出行必不可少的交通工具之一，每天新购买需要上牌的汽车数量已经超过100万辆，导致各个车管所车辆上牌网点无法满足人们轻松上牌的需求，湖南交警特地委托我司定制开发此软件，旨在让人们在家即可轻松选择自己中意的车牌号码。以及完成与车牌号码相关的交易、转让、赠送等事项。
1.3 适用范围
| 编号 | 岗位 | 人员 |
| 1 | 测试工程师 | |
| 2 | 测试经理 | |
| 3 | 开发成员 | |
| 4 | 开发经理 | |
| 5 | 产品人员 | |
| 6 | QA | |
| 7 | 部门经理 |
1.4 专业术语
| 专业术语 | 术语解释说明 |
| 冒烟测试 | 针对产品的基本功能进行测试。 |
| 功能测试 | 又称正确性测试，它检查软件的功能是否符合规格说明书。 |
| 压力测试 | 对服务器施加一定压力后进行功能测试，测试服务器在一定压力下是够可以正常工作。 |
| 负载测试 | 对服务器施加压力，测试服务器可以容纳多少人访问，多少人访问后出现性能问题。 |
| 兼容测试 | 测试Web页面是否支持所有浏览器，访问后页面所有功能无异常。 |
| 验收测试 | 这是相关的用户根据测试计划和结果对系统进行测试和接收。它让用户决定是否接收系统。 |
| 回归测试 | 开发修改后的BUG在测试一遍。 |
二、测试任务
2.1 测试范围
本计划文档覆盖《湖南交警一网通》功能测试、压力测试、负载测试、兼容测试、验收测试等。
2.2 测试目标
测试《湖南交警一网通》系统与需求规格要求的功能和性能是否全部实现，是否满足用户的明确需求和隐含需求，系统发布是否存在风险等。
2.3 参考文档
| 文档（版本） | 已创建 | 已审核/已核准 | 作者或来源 |
| 湖南交警一网通需求规格说明书1.0.doc | 是■ 否□ | 是■ 否□ | |
| 湖南交警一网通开发计划文档1.0.doc | 是■ 否□ | 是■ 否□ |
2.4 提交文档(交付件)
| 文档名称 | 责任人 | 交付日期 |
| 湖南交警一网通项目测试需求文档.doc | 2019-05-19 | |
| 湖南交警一网通项目测试计划.doc | 2019-05-21 | |
| 湖南交警一网通项目测试要点分析.doc | 2019-05-26 | |
| 湖南交警一网通项目测试用例.doc | 2019-06-18 | |
| 湖南交警一网通项目测试执行.doc | 2019-07-31 | |
| 湖南交警一网通项目测试报告.doc | 2019-08-04 |
三、测试进度
| 测试活动 | 工作日 | 开始日期 | 结束日期 | 责任人 |
| 制定测试计划 | 2 | 2019-12-26 | 2019-12-28 | |
| 测试需求分析 | 10 | 2019-12-29 | 2020-01-05 | |
| 功能测试 | 60 | 2020-01-11 | 2020-01-28 | |
| 压力测试 | 7 | 2020-01-28 | 2020-02-03 | |
| 负载测试 | 7 | 2020-02-03 | 2020-02-04 | |
| 兼容性测试 | 3 | 2020-02-05 | 2020-02-05 | |
| 验收测试 | 5 | 2020-02-07 | 2020-02-12 | |
| 产品发布 | 3 | 2020-02-14 | 2020-02-116 |
四、测试资源
4.1 人力资源
| 角色 | 姓名 | 分配的专职角色数量 | 具体职责或注释 |
| 测试组长 | 1 | 负责完成测试需求分析，编写测试计划和测试报告，组织测试工作。 | |
| 测试工程师 | 2 | 编写测试用例，执行测试用例，找出系统存在的缺陷并报告。 |
4.2 环境资源
4.2.1 硬件环境
| 资源名称 | 资源项 | 描述 |
| 硬件资源 | Web服务器硬件配置 IP：192.168.1.100 用户名：root 密码：123456 | CPU：Intel(R) Core(TM) i7-5800U 2.3GHZ 内存：8G |
| 数据库服务器硬件配置 IP：192.168.1.200 用户名：root 密码：123456 | CPU：Intel(R) Core(TM) i7-5800U 2.3GHZ 内存：8G |
4.2.2 软件环境
| 资源名称 | 资源项 | 描述 |
| 应用软件 | 操作系统 | CentOS 7 |
| Web应用服务器 | JDK1.8/Tomcat8.0 | |
| 数据库 | 数据库Mysql5.7 |
4.3 测试工具
| 资源名称 | 资源项 | 描述 |
| 测试工具 | 缺陷管理工具 | 禅道 |
| IE兼容性测试工具 | IETest | |
| 压力/负载测试工具 | Jmeter | |
| 抓包分析工具 | Fiddler |
五、测试策略
5.1 功能测试
| 测试目标： | 测试系统是否满足用户的功能需求（包括显性和隐性） |
| 测试范围： | 湖南交警一网通系统的所有功能模块，包括： 【首页】：子模块名,子模块名 【车牌管理】：子模块名,子模块名 【统计查询】：子模块名,子模块名 【系统设置】：子模块名,子模块名 |
| 测试方法： | 请参照《湖南交警一网通需求规格说明书》，使用等价类、边界值、场景法、因果图、正交表等。 1.针对各个功能点使用有效数据时得到预期的结果； 2.针对各个功能点在使用无效数据时显示相应的错误或警告消息； 3.各业务规则、业务流程得到了正确的执行。 |
| 开始标准： | 1.编码工作已经全部结束。 2.测试环境已经搭建完成。冒烟测试通过。 3.集成测试的测试报告已修改完毕，集成测试阶段测试用例基本已经通过。 |
| 完成标准： | 1.所计划的测试点和测试用例已全部执行完成，系统测试报告已经修改完毕 2.功能已达到用户需求。 |
| 测试重点和优先级： | 各业务流程是否得到正确的执行。 |
5.2 压力测试
5.3 负载测试
5.4 兼容测试
六、测试完成标准
6.1测试充分性
a.用例已全面覆盖需求：测试用例覆盖率要求达到100%。
b.原则上要求所有用例都100%执行，即优先级高、中、低的用例都必须100%执行。
c.工作投入充分性：项目测试工作要充分投入，保障测试投入的合理性。
6.2测试有效性
a.严重性以上程度的缺陷解决率必须达到100%。
b.缺陷密度达到一定的标准，Bug数呈正态分布。
c.相关责任部门认可测试结果,包括客户的试用、验收测试等。
七、风险和约束
7.1流程约束
(2)测试流程：略
(3)缺陷流程：略
7.2风险分析
| 序号 | 风险描述 | 规避措施 | 责任人 |
| 1 | 测试时间短导致测试用例覆盖不全面 | 与PM申请更多测试时间， | PM |
| 2 | 测试人力不足导致测试进度滞后 | 与PM沟通 1）建议再增加2-3名测试，或到后期调用公司技术支持、市场、财务等人员进行全员测试 2）适当推迟产品上市时间 | PM |
| 3 | 客户需求更改导致工作计划被打乱 | 提出双赢的解决办法 | 产品人员 |
| 4 | 开发部门不能按时发布版本，导致测试周期缩短 | 要求开发人员赶工 | 开发人员 |
| 5 | 质量标准不统一，某些优先级方面，测试与研发意见不统一 | QA制定出统一标准 | QA |
| 6 | 测试人员经验不足导致测试结果分析不全面 | 多组织培训、多进行技术、经验交流 | 测试总监、TE |
| 7 | 设计文档不全导致测试设计不准确 | 多与开发人员沟通 | 开发人员 |
八、问题严重程度描述和响应时间规范
| 问题严重程度 | 问题描述 | 响应时间 |
| P0 | 严重级别比较高的，影响测试进行或者系统无法继续操作，立即修复。 | 1天 |
| P1 | 基本功能没有实现，对系统操作有影响 | 3天 |
| P2 | 一般性功能，页面缺陷 | 5天 |
| P3 | 准备在下一轮测试前修改完毕。 | 下一版本修改 |
九、审批签字
| 项目经理审批意见：
签字： 日期： |
最后：下方这些项目已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】
![[Halcon3D] 主流的3D光学视觉方案及原理](https://img-blog.csdnimg.cn/3c6a3e0afc4940fca2c857b87d4dfe2b.png#pic_center)
