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测试工具
软件测试工具
工具名称工具版本
Soapui4.0
Loadrunner11
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 风险预警
目前依赖方数据测试环境无法使用，需要进行线上验证
网友评论