1. 测试目标
[描述进行项目测试的目的或所要达到的目标。包括但不限于功能测试目标、性能测试、安全测试目标等。]
2. 测试策略
2.1 总体原则
[描述将要执行哪些类型的测试,常见的测试类型有:功能测试、接口测试、性能测试、安全测试、可靠性测试、数据与数据库完整性测试、故障转移与恢复测试、兼容性测试等。可根据产品、项目特性进行裁剪。]
|
测试类型 |
是否实施[Y/N] |
备注 |
|
功能测试 |
Y | |
|
接口测试 |
N | |
|
性能测试 | ||
|
安全测试 | ||
|
可靠性测试 | ||
|
数据与数据库完整性测试 | ||
|
故障转移与恢复测试 | ||
|
兼容性测试 |
2.2 功能测试
[描述功能测试的测试范围、测试策略]
测试策略
[例如:
计划分N轮测试,其中冒烟测试、回归测试采用接口自动化进行,其余阶段测试通过手工执行。]
测试范围:
[这部分说明哪些产品模块在测试范围中,哪些是本次测试不考虑的。对于在测试范围中的模块,需要给出优先级以便响应测试资源不足的情况;对于不在测试范围中的模块,需要给出原因。]
需要测试的模块:
|
系统名称 |
功能模块 |
优先级 |
备注 |
|
xx系统 |
xx功能 |
高 | |
|
xx系统 |
xx功能 |
中 | |
不测试的模块:
|
系统名称 |
模块 |
说明 |
|
xx系统 |
xx功能 |
该功能不做测试 |
|
xx系统 |
xx功能 |
该功能不做测试,但是要测试xxx正确性 |
|
xx系统 |
xx功能 |
增量开发,本次未改动到,该功能不做测试 |
2.3 接口测试
[描述接口测试范围、测试策略,若本次不开展该类型测试,则可去掉该章节]
|
系统 |
场景描述 |
被测接口 |
备注说明 |
|
xx系统 |
xx功能 |
新增业务功能接口 | |
|
xx系统 |
xx功能 |
原有接口涉及字段、逻辑变更 | |
2.4 性能测试
[描述性能测试范围、测试策略,若本次不开展该类型测试,则可去掉该章节]
|
系统 |
业务模块 |
测试场景 |
业务数据量 |
关键性能指标 |
|
xx系统 |
xx模块 |
xx功能场景 |
| |
2.5 安全测试
[若有开展安全测试,则本章节描述安全范围、策略;若本次不开展该类型测试,则可去掉该章节]
2.6 可靠性测试
[同上]
2.7 数据与数据库完整性测试
[同上]
2.8 故障转移与恢复测试
[同上]
2.9 兼容性测试
PC兼容性:
|
操作系统 |
版本 |
浏览器版本 |
分辨率 |
|
Windows |
Win11 |
Chrome 81以上 |
1920*1080 |
|
Win10 |
Firefox 56以上 |
1600*900 | |
|
... | |||
|
Mac |
macOS Ventura |
Safari | |
|
... |
移动端兼容性:
|
操作系统 |
版本 |
机型 |
分辨率 |
浏览器 |
网络兼容 |
|
iOS |
iOS15.x |
iPhone12 |
1170*2532 |
Safari |
5G |
|
... | |||||
|
Android |
Android11.x |
华为x |
1344*2772 |
自带浏览器 |
4G |
|
Android10.x |
vivo |
2250*1080 |
UC |
WiFi | |
|
... |
3. 测试时间
[仅描述测试里程碑时间即可,具体的执行计划在《测试计划》中说明]
|
测试活动 |
计划开始时间 |
计划结束时间 |
备注 |
|
需求评审 | |||
|
测试方案/评审 | |||
|
测试计划/评审 | |||
|
用例设计/评审 | |||
|
功能测试 |
计划安排N轮 | ||
|
性能测试 | |||
|
安全测试 | |||
|
其他专项测试 | |||
|
验收测试 | |||
|
发布上线时间 |
4. 测试资源
4.1 测试环境
|
服务名称 |
硬件环境 |
操作系统 | ||
|
CPU |
内存 |
硬盘 | ||
|
xx服务 |
centos | |||
|
xx服务 | ||||
4.2 测试工具
|
工具名称 |
用途说明 |
|
xx工具平台 |
缺陷管理 |
|
xx测试平台 |
测试计划、测试执行、测试用例管理 |
|
jmeter |
性能测试 |
|
BurpSuite |
安全渗透测试 |
|
... |
4.3 测试人员
|
角色 |
成员 |
职责 |
|
测试负责人 |
张三 |
|
|
测试人员 |
李四、王五 |
|
5. 测试准则
5.1 测试准入
[以下提供通用标准,可根据项目实际情况进行调整]
- 测试用例设计完成并评审通过
- 测试环境准备就绪
- 需求规定的功能均已实现;若未完全实现,需提供测试范围
- 开发完成自测,自测覆盖率100%、通过率100%
- 冒烟测试完成,且通过率100%
5.2 测试准出
[以下提供通用标准,可根据项目实际情况进行调整]
- 需求功能均已实现
- 测试用例执行率100%,通过率96%
- 性能、安全、兼容性等均满足要求
- 遗留BUG:P0、P1级BUG全部修复完毕并通过验证,存在少量P2、P3级BUG,不影响核心功能使用,经项目组评审确定可遗留
- UAT测试通过
- 测试报告已输出
BUG等级说明:
严重程度为 P0(致命):系统崩溃、中断、死机、数据丢失、安全问题、主要功能未实现、严重错误且没有应急解决方案、系统性能严重低于最低要求
严重程度为 P1(严重):数据错误、程序逻辑错误
严重程度为 P2(一般):功能小错误且有应急解决方案
严重程度为 P3(轻微):人机交互或界面优化建议、提示语等拼写小错误,不影响用户正常使用。
6. 风险应对
[风险列表及应对措施]
|
风险分析 |
风险等级 |
解决方案 |
责任人 |
|
高/中/低 | |||
责任矩阵
|
部门 |
项目经理 |
产品经理 |
开发负责人 |
测试负责人 |
测试人员 |
|
需求评审 |
⊙ |
⊙ |
⊙ |
⊙ |
⊙ |
|
测试策略制定 |
⊙ | ||||
|
测试策略评审 |
⊙ |
⊙ |
⊙ |
⊙ |
⊙ |
|
测试用例设计 |
⊙ |
⊙ | |||
|
测试用例评审 |
⊙ |
⊙ |
⊙ |
⊙ |
⊙ |
|
测试环境准备 |
⊙ |
⊙ | |||
|
测试执行 |
⊙ |
⊙ | |||
|
测试报告 |
⊙ |
⊙ |


被折叠的 条评论
为什么被折叠?



