1、前言
1.1 目的
内容自己填写，页码自己修改，不会可以百度
1.2 术语说明
列出本文件中用到的专门术语的缩写、英文名称及定义。
术语
缩写
英文名称
解释
1.3 参考资料
参考文档放置处。
ID
文件
文件名
备注
2、系统概况
2.1 项目背景
内容自己填写，页码自己修改，不会可以百度
2.2 测试目标
以《需求文档》为准，通过功能测试及非功能等测试方法，达到需求文档要求，满足客户需求。
2.3 测试范围2.3.1 功能测试
测试内容
测试方法
执行人员
需求中功能是否在系统实现
手工
测试人员
2.3.2 界面测试
测试内容
测试方法
执行人员
页面ui显示正常，数据正常
手工
测试人员
2.3.3 压力测试
测试内容
测试方法
执行人员
模拟多用户传输数据得出性能指标
测试工具
测试人员
2.3.4 兼容测试
测试内容
测试方法
执行人员
不用浏览器版本或手机版本是否能正常使用
手工
测试人员
2.3.5 安装/卸载测试
测试内容
测试方法
执行人员
安装和卸载可以正常操作，过程不出现中断
手工
测试人员
2.3.6 升级测试
测试内容
测试方法
执行人员
版本升级后功能系统功能可以使用
手工
测试人员
2.3.7 接口测试
测试内容
测试方法
执行人员
调用接口url，成功返回相应报文
测试工具
测试人员
2.3.8 验收测试
测试内容
测试方法
执行人员
uat环境执行测试
手工
产品人员
2.4 非测试范围
无
3 缺陷定义
3.1 缺陷严重级别定义(目前jira没有缺陷等级字段)
Ø 一级致命性(系统崩溃/三一系统丢失)：主流程无法跑通，系统无法运行，崩溃或严重资源不足，三一系统丢失，应用模块无法启动或异常退出，主要功能模块无法使用等影响系统流程的BUG；
Ø 二级严重性（重大错误）：影响系统功能或操作，主要功能存在严重缺陷，或者功能没有按照《系统需求说明书》实现或功能实现错误，但不会影响到系统稳定性；
比如：1.功能未实现；
2.功能存在报错；
3.数值轻微的计算错误；
Ø 三级功能一般性：界面、性能缺陷；
比如：1.边界条件外错误；
2.提示信息不合理，三一系统错乱；
3.三一系统操作时无响应；
4.三一系统操作时，没有提供进度条；
Ø 四级易用性/建议性：易用性及建议性问题；
比如：1.界面颜色搭配不合理；
2.文字排列不整齐；
3.出现错别字，但是不影响功能；
4.界面格式不规范；
5.为便于客户使用而提出的改进意见；
3.2 缺陷优先级定义
优先级描述了BUG被修复的优先顺序。优先级别根据项目开发安排或功能对目前版本系统的影响做相应的设置。优先级别有一=以下几种：
Ø 高：系统功能未实现导致其他功能无法实现或系统损坏，系统UI或功能在可能接受的范围内未实现，需尽快修复。
Ø 中：系统的功能或UI未完全正确实现，无需立即修复。
Ø 低：系统的功能或UI可以暂时接受忽略。
Ø 待定：对于该BUG影响待评估或者该BUG在现阶段不用修复。
3.3 测试环境
软件测试环境
名称
产品和型号
操作系统
Windows10 64位
浏览器
Google 69.0.3497.92
3.4 测试工具
软件测试工具
工具名称
工具版本
Soapui
4.0
Loadrunner
11
Jmeter
Python
Jira
4 测试概括
4.1 测试目的
内容自己填写，页码自己修改，不会可以百度
4.2 测试进度计划
测试内容
开始时间
结束时间
需求评审
编写测试用例
测试用例评审
需求版本提测
测试结束，出测试报告
UAT环境验收测试
上线日期
4.3 测试过程4.3.1 准备阶段
ü 基于项目生命周期的节点编制测试计划。
ü 基于需求说明书梳理测试功能点。
4.3.2 编写测试用例阶段
ü 基于需求说明书设计功能测试用例。
ü 基于需求说明书设计业务流程测试用例。
ü 基于需求说明书设计系统UI方面测试检查点
ü 基于需求设计测试123567，简单的123567将在Excel相应case里面以参数化的形式列出。
从两方面检查测试用例：
ü 检查测试用例是否100%覆盖了需求的各个功能点。
ü 检查每个测试用例与相应需求功能点的一致性，确保正确理解各个功能。
ü 已经审核通过的测试用例将作为执行测试的最终用例。
4.3.3 执行测试阶段
测试的执行将实施手工测试，相应的测试结果也会记录在Excle中。在执行阶段，主要有以下活动：
ü 执行测试用例。
ü 在jira内记录并追踪BUG。
ü 经开发人员修复后对BUG进行验证。
4.3.4 测试汇总阶段
在汇总阶段主要有以下活动：
ü 分析BUG，记录BUG修复状态。
ü 生成测试报告 。
ü 在整个测试过程中，将会使用Excel表格或者测试工具作为测试管理工具。
4.3.5 验收阶段
UAT环境执行验收测试，并提示各种文档，做最后的汇总。
4.4 测试准则4.4.1 介入测试准则
ü 需求文档是得到客户的检验和认可的最终版本。
ü 产品的单元测试顺利完成，相应的接口已经连接好，系统可用。
ü 测试管理和测试策略已经清晰定义在测试计划并被检验得到PM的认可。
ü 测试时间安排定义好并得到认可。
ü 测试要求的软硬件环境在测试正式执行之前经检测稳定可用。
ü 被测系统测试版本部署完好，通过冒烟测试稳定可用。
ü 测试人员全部到位随时可投入测试。
ü 测试用例必须为检验以后的最终版本，测试三一系统可用。
4.4.2 测试通过准则
ü 《需求说明书》中定义的所有功能已全部实现，性能指标全部达到要求。
ü 所有BUG必须符合以下标准：(以下比例为对应级别BUG数/总BUG数)。
一级BUG
二级BUG
三级BUG
四级BUG
无
无
<5%
<10%
ü 需求文档、设计文档和编码实现一致。
ü 测试覆盖率（已设计测试用例的需求数/需求总数）达到100%
ü 测试执行率（已执行的测试用例数/设计的总测试用例数）达到100%以上
ü 测试通过率（执行结果为通过的测试用例数/实际执行的测试用例总数）达到90%以上
ü 以上如有一项不满足要求，视为测试不通过。
4.4.3 暂停准则
ü 假如下列事项有一项发生，测试就暂停：
ü 需求临时变更影响集成测试执行。
ü 开发人员提交的测试版本中关键功能测试不通过，测试中止。等待开发人员提交新的稳定功能版本之后才会重新开始测试。
ü 测试环境挂掉，无法执行测试。
ü 在测试过程中发现一些阻碍流程的缺陷，影响后继功能，测试无法继续进行，系统测试暂停。
ü 一些关键的缺陷数量超过了预计评估的20%,系统测试暂停。
4.4.4 恢复准则
ü 测试环境修复好，一个新的基线系统版本可以稳定使用，提交给测试组继续执行测试
ü 测试暂停中发现的阻碍流程的缺陷已经被修复，测试重新启动。
ü 经确认新的需求变更在下个版本中实现，不影响目前版本功能测试。
ü 满足测试启动准则。
5 测试交付文档
以下列表为测试交付需要的文档与交付人员。
序号
文档名称
交付人员
1
测试计划
2
测试用例
3
测试报告
6 风险预警
目前依赖方数据测试环境无法使用，需要进行线上验证
收藏收藏