软件测试大纲（模板）

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 “六性”

• 可靠性维修性具体需要开展的工作如下：

1. 编制可靠性工作计划
2. 编制可靠性设计准则、可靠性设计准则符合性报告、可靠性预计报告、BUG影响及分析报告
3. 制定维修性设计准则，并进行符合性分析
4. 提供系统自我实现的故障监控和预警能力
5. 开展可靠性维修性定性要求测试

• 安全性具体需要开展的工作如下：

1. 数据脱敏：在软件研发测试过程中需要保证使用脱敏后的数据，数据本身不能暴露真实数据的特性、结构和使用意图。
2. 断电保护：在数据存储时应当考虑断电保护，系统故障和断电不能造成数据无法使用或大面积丢失。
3. 安全运行规范

• 测试性具体需要开展的工作如下：

1. 编制测试性工作计划，制定测试大纲
2. 制定测试性设计准则并进行符合性分析
3. 编制测试性设计详细方案，制定测试用例
4. 测试结果预计
5. 测试包含单元测试、集成测试、系统测试三个阶段
6. 功能测试和性能测试的实施方式
7. 测试工具的有效性管理
8. BUG修复情况的管理

• 环境适应性

4.2.2.2 性能

     xxxx

5 测试进度表

测试系统名称	测试系统功能	计划完成时间	人员

6 测试终止条件

      一般有“基于测试用例” 和基于“缺陷密度”两种评比准则，在这里我们采用前者：

1. 功能性测试用例通过率达到100%；
2. 性能：
3. 没有高于优先级3以上的问题。

      备选通过方法：根据实际由开发部门经理、项目经理、测试负责人共同讨论确定本测试阶段是否结束。

7 注释

7.1 严重程度

严重程度	说明
一级缺陷(1-紧急)	导致被测软件响应明显很慢（假死）、死机、非法退出、崩溃； 导致后台数据受损或丢失； 死循环 数据库发生死锁
二级缺陷（2-严重）	用户需求实现错误，且影响到用户完成业务； 用户需求未实现，且影响到用户完成业务； 用户使用频繁的功能，响应时间超出忍耐限度，但不影响其他功能模块； 数据无法保存的； 主要功能链接实现有误的； 用户频繁操作的功能没有实现或者实现有误的；
三级缺陷（3-一般）	UI上存在错误引导用户的信息； UI上信息缺失、无法显示完整或出现乱码从而给用户造成疑惑的； 用户频繁使用的功能易用性差（操作起来麻烦、复杂、效率低）； 用户使用不频繁的功能，响应时间超出忍耐限度； 用户操作过程中系统出现异常报错，但不影响系统功能的使用； 用户需求实现错误，但不影响用户完成业务或者用户使用不频繁的； 用户需求未实现，但不影响用户完成业务或者用户使用不频繁； 必填/必选项没有做验证的； 由于图片丢失而影响功能实现的； 页面排版问题，且影响用户阅读的； 由于字段类型/长度没有约束而出现功能实现错误的；
四级缺陷（4-微小）	页面排版有误，但不影响阅读的； 拼写语法错误，但不误导用户操作的； 鼠标覆盖在图片上但没有显示Alt文字的； 背景颜色风格不一致的； 默认值缺失； 光标定位错误，影响默认操作的； Tab顺序没有遵循自左向右，由上而下顺序的； 由于图片丢失但不影响功能实现的； 其他用户不频繁使用的功能易用性差；
五级缺陷（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