1 范围
1.1 系统概述
xxxxxx
1.2文档概述
本文档为xxx软件测试说明，为保证系统达到设计目标，对系统进行测试，编制此文档以对测试过程进行详细说明。整个系统测试工作以本文档为指导，严格按照本文档的要求进行测试，测试中要对平台的内容进行保密。
2 引用文件
xxxxx
3 测试准备
3.1 测试环境
| 资源名称/类型 | 配置 |
| 操作系统环境 | |
| 数据库 | |
| 其他 |
3.2 测试工具
| 设备/设施/工具 | 要求 | 备注 |
| Microsoft visual studio enterprise 2017 | V15.9.50 | 软件版本功能正常 |
| SQLyog | v13.1.7 | 软件版本功能正常 |
| Jmeter |
3.3 测试人员
| 姓名 | 角色 | 主要工作职责 | 测试参与度 |
| xxx | 测试人员 |
| 100% |
| xxx | 测试人员 |
| 100% |
| xxx | 测试人员 |
| 80% |
4 计划
4.1总体设计
系统测试是对软件产品质量的检验和评价，所以本次测试分模块、按功能完全模拟用户需求的方式进行测试。
4.1.1 整体测试目标
- 测试覆盖率：100%
- 测试覆盖率=已执行用例总数/用例总数*100%
4.1.2 整体质量目标
- 系统所有功能及性能都已实现，且达到设计要求；
- 业务流程正确且符合规范；
- 友好且易于学习和操作的用户界面；
4.1.3 风险和约束
| ID | 风险描述 | 严重性 | 可能性 | 风险规避方法 |
| R1 | 需求文档不明确，不健全，影响到测试用例的准确性 | 中 | 中 | 在测试过程中有文档不够明确的地方，项目开发组应提供尽可能多的帮助，以便测试可以顺利进行。 |
| R2 | 中途出现其他需要优先处理的事情 | 中 | 中 | 将根据事情优先级和重要程度进行评估 |
4.1.4 测试范围
本次功能测试范围如下软件模块：
| 系统名称 | 软件模块 | 子模块 | 优先级 | 是否重点测试 |
| 1 | 是 | |||
| 1 | 是 | |||
| 1 | 是 |
本次性能指标如下：
xxxx
4.1.5 功能测试
| 测试目标 | 核实所有功能均已正常实现、即是否与需求一致 |
| 技术 | 采用黑盒测试、自动化测试等测试方法 |
| 工具与方法 | 手工测试、编写脚本验证 |
| 开始标准 | 开发阶段对应的功能完成并且测试用例设计完成 |
| 完成标准 | 测试用例通过并且高级缺陷全部解决 |
| 需要考虑的特殊事项 |
|
4.1.6 性能测试
| 测试范围 | 系统的数据处理性能是否与需求一致 |
| 测试目标 | (性能指标) |
| 技术 | 手动测试、测试脚本 |
| 开始标准 | 测试脚本设计并评审通过、项目组移交系统测试 |
| 完成标准 | 系统满足用户需求的性能要求 |
| 需要考虑的特殊事项 |
4.1.7 回归测试
| 测试目标 | 核实所有bug均已通过用例回归 |
| 技术 | 采用黑盒测试、自动化测试等测试方法 |
| 开始标准 | 开发阶段对应的bug修复 |
| 完成标准 | Bug确认修复且几个版本不再复现 |
| 需要考虑的特殊事项 |
4.2 计划执行的测试
4.2.1 功能测试
4.2.1.1 xx功能
本模块主要测试内容包括：xxxxxx
4.2.1.2 xx功能
本模块主要测试内容包括：xxxxxx
4.2.2 非功能性测试
4.2.2.1 “六性”
- 可靠性维修性具体需要开展的工作如下：
- 编制可靠性工作计划
- 编制可靠性设计准则、可靠性设计准则符合性报告、可靠性预计报告、BUG影响及分析报告
- 制定维修性设计准则，并进行符合性分析
- 提供系统自我实现的故障监控和预警能力
- 开展可靠性维修性定性要求测试
- 安全性具体需要开展的工作如下：
- 数据脱敏：在软件研发测试过程中需要保证使用脱敏后的数据，数据本身不能暴露真实数据的特性、结构和使用意图。
- 断电保护：在数据存储时应当考虑断电保护，系统故障和断电不能造成数据无法使用或大面积丢失。
- 安全运行规范
- 测试性具体需要开展的工作如下：
- 编制测试性工作计划，制定测试大纲
- 制定测试性设计准则并进行符合性分析
- 编制测试性设计详细方案，制定测试用例
- 测试结果预计
- 测试包含单元测试、集成测试、系统测试三个阶段
- 功能测试和性能测试的实施方式
- 测试工具的有效性管理
- BUG修复情况的管理
- 环境适应性
4.2.2.2 性能
xxxx
5 测试进度表
| 测试系统名称 | 测试系统功能 | 计划完成时间 | 人员 |
6 测试终止条件
一般有“基于测试用例” 和基于“缺陷密度”两种评比准则，在这里我们采用前者：
- 功能性测试用例通过率达到100%；
- 性能：
- 没有高于优先级3以上的问题。
备选通过方法：根据实际由开发部门经理、项目经理、测试负责人共同讨论确定本测试阶段是否结束。
7 注释
7.1 严重程度
| 严重程度 | 说明 |
| 一级缺陷(1-紧急) |
|
| 二级缺陷（2-严重） |
|
| 三级缺陷（3-一般） |
|
| 四级缺陷（4-微小） |
|
| 五级缺陷（5-建议修改） |
|
7.2 优先级
| 优先级 | 说明 |
| 1-紧急 | 必须在一个工作日内修复 |
| 2-严重 | 必须在三个工作日内修复 |
| 3-一般 | 必须在五个工作日内修复 |
| 4-微小 | 有时间再修复 |
7.3 缺陷类型
| 缺陷类型 | 说明 |
| 功能性 | 与系统功能实现相关的缺陷 |
| 安全性 | 与系统安全性相关的缺陷 |
| 易用性 | 与系统易用性相关的缺陷 |
| 界面性 | 与系统界面相关的缺陷，如文字错误，排版错误等 |
| 性能类 | 由性能测试提交的缺陷，或者是响应时间明显很长的 |
| 配置类 | 由配置因素引起的缺陷 |
| 平台缺陷 | 研发中心平台原有的缺陷 |
| 用户体验类 | 与用户体验相关的缺陷 |
| 建议类 | 现有需求不明确，但按照使用习惯等需要实现的功能 |
7.4 缺陷状态
| 缺陷状态 | 说明 |
| 新建 | 新提交缺陷所应存在的状态 |
| 打开 | 说明缺陷正在处理当中，还未有最终处理结果 |
| 已修复 | 开发人员同意缺陷描述，并已修复缺陷 |
| 已关闭 | 测试人员对缺陷进行验证，并确认缺陷已经修复 |
| 重复 | 缺陷与其他缺陷所描述的问题相同，可置为重复。但需要在注释中说明重复的Bug编号，以方便测试人员进行跟踪处理。 |
| 重新打开 | 测试人员不同意开发人员的处理结果，或者是缺陷再次出现的，可将缺陷重新打开给相关开发人员。 |
| 后期修复 | 开发人员同意缺陷描述情况，但是需要在后期修复。后期修复并不是不修复，除非项目组同意该缺陷后期修复，否则将影响到测试统计，必须予以修复。 |
| 测试拒绝 | 缺陷明显无效，由测试人员自己发现并处理的。 |
| 开发拒绝 | 缺陷明显无效，开发人员决定不修复的。 |
| 需补充信息 | 不明确缺陷所描述的问题，需开发/测试人员补充信息以便处理的。 |
8 测试用例
| 项目名称 | xxxx测试用例 | |||||||
| 编制人 | xxx | |||||||
| 编制时间 | xxx | |||||||
| 测试目的 | 依据立项功能点进行功能覆盖测试用例设计 | |||||||
| 测试环境 | Windows 11 x64、Google Chrome 94 | |||||||
| 用例编号-title | 模块名称 | 用例描述 | 前置条件 | 操作步骤 | 期望结果 | 测试结果 | 备注 | |
| pass | failed | |||||||
| C001 | ||||||||
| C002 | ||||||||
| C003 | ||||||||
3177
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
