一篇完整的测试方案怎么写
一篇完整的测试方案怎么写
看上面的目录，详细
文档说明
| 文档名称 | 创建人/修改人 | 版本 | 时间 | 备注 |
| v1.0 | 2022-11-17 | 新建 | ||
| v1.1 | 2022-11-25 | |||
| v1.2 | 2022-12-05 | |||
| v2.0 | 2022-12-13 | |||
| v2.1 | 2022-12-14 |
一、文档目的
为软件开发项目管理者、软件工程师、系统维护工程师、测试工程师、项目经理提供关于项目系统整体功能和性能的测试指导，同时也是用户确定软件是否完整测试的重要依据
二、项目概述
xxx
三、测试目标
- 需求覆盖100%，功能错误修复率100%；
- 测试用例覆盖需求100%，用例执行率100%；
- 最后一轮回归覆盖率100%，发现问题为0；
- bug关闭率100%；
四、测试参考文档
1、GBT 9386-2008 计算机软件测试文档编制规范
2、GBT 15532-2008 计算机软件测试规范
3、本项目原型材料
4、本项目设计图
五、测试范围
1、测试计划和设计：按照项目进度计划和功能清单、产品原型等材料编写测试计划、设计用例，完成测试工作安排；
2、黑盒测试：按照测试用例执行测试，通过输入输出验证系统功能是否满足需求说明书要求；
3、性能测试：根据性能指标进行场景设计和脚本开发，并执行性能测试，评估系统性能情况。
六、测试资源
- 测试人员、职位、工作职责：
| 成员角色 | 姓名 | 职责、任务 |
| 测试组长 | xx | 编写测试计划，缺陷管理，测试结果分析，开发脚本，性能测试执行，编写测试报告 |
| 测试工程师 | xx | 用例编写，执行测试，记录跟踪报告缺陷 |
| 测试工程师 | xx | 用例编写，执行测试，记录跟踪报告缺陷 |
- 需要配合的部门和人员：
| 成员角色 | 姓名 | 工作内容 |
| 产品经理 | xxx | 帮助解决测试人员对产品材料的疑问 |
| 技术负责人 | xx | 协助搭建压测环境，性能指标分析 |
| 业务负责人 | xx | 协助测试了解业务需求，获取第三方原始数据支持测试，提供业务帮助 |
七、测试规模
7.1 功能点清单
| 模块 | 子模块 | 测试人员 | 启动时间 |
| 2022-12-19 | |||
| 2022-12-18 | |||
| 2022-12-15 | |||
| 2022-12-15 | |||
| 2022-12-19 | |||
| 2022-12-15 | |||
| 2022-12-16 | |||
| 2022-12-26 |
八、里程碑
8.1 进度进度及工作量
xxx项目测试人员数量为3人，测试时间为29个工作日。
| 任务名称 | 开始时间 | 结束时间 | 工作量（天） | 人数（个） | 阶段输出 |
| 编写测试计划 | 2022-11-14 | 2022-11-15 | 2 | 1 | 《xxx项目测试方案】 |
| 系统培训 | 2023-05-31 | 2023-05-31 | 1 | 1 | 培训内容记录 |
| 编写测试用例 | 2022-12-01 | 2022-12-07 | 5 | 2 | 各模板测试用例文件 |
| 用例评审 | 2022-12-08 | 2022-12-09 | 2 | 2 | 完善的用例文件 |
| 功能测试 | 2022-12-15 | 2023-01-04 | 15 | 2 | BUG |
| 性能测试 | 2023-01-05 | 2023-01-07 | 3 | 1 | 性能数据 |
| 内部验收测试 | 2023-01-04 | 2023-01-06 | 3 | 2 | 验收测试报告 |
| 编写测试报告 | 2023-01-08 | 2023-01-09 | 2 | 2 | 功能测试报告 性能测试报告 |
8.2 测试轮次安排
根据项目实际情况，本次测试共分为4轮，具体安排如下：
| 测试活动 | 计划开始 | 计划结束 | 实际开始 | 实际结束 |
| 冒烟测试 | 2022-12-15 | 2022-12-15 | ||
| 第一轮测试 | 2022-12-18 | 2022-12-23 | ||
| 第二轮测试 | 2022-12-25 | 2022-12-30 | ||
| 第三轮测试 | 2023-07-19 | 2023-07-21 |
- 测试内容
1、冒烟：验证系统整体主流程是否已实现，达到提测标准
2、第一轮：功能测试
3、第二轮：缺陷验证，功能测试，用户界面测试，兼容测试
4、第三轮：回归所有功能
九、测试工具
测试管理工具为禅道，性能测试工具为jmeter和takin，用例维护是用例管理平台
| 工具 | 版本 | 用途 |
| 禅道 | 12.5.3 | 缺陷管理 |
| jmeter | 5.3 | 性能脚本开发 |
| takin | - | 性能测试 |
| evolute studio | - | 功能测试，用例管理 |
十、测试方法
10.1、黑盒测试
| 名称 | 描述 | 备注 |
| 冒烟测试 | 对主要功能流程进行验证而设计的案例 | 此案例针对冒烟测试，通常为每个流程设计一条用例，只需验证正常流程通过即可 |
| UI测试 | 根据需求文档提供的规则设计用例，检测页面风格一致性，用户操作习惯，显示风格统一等 | 一个项目的总体规则是固定的，既要保证案例的执行覆盖度，又要避免案例的冗余，所以总体规则可由一个人完成设计，在各个模块下直接复用；测试执行时，可根据需要来进行执行情况的统计。 |
| 必填项、输入项验证 | 主要指在客户端所进行的各类输入数据项的合法性，页面中所必须录入/选择的项目，是否在为空的情况下仍然可以通过提交的检查。 | 输入验证主要是主要指在xx端和管理系统能够验证或限制的内容，如数据输入长度限制、是否含有非法字符等。必填项则是根据各个页面的必填项不同，要考虑必填项的显示方式，以及非必填项是否也被做了必输限制等。 |
| 基本功能测试 | 当前功能本身的操作及数据流程正确性的测试，包括正常流程和异常流程。 | 例如，执行报名操作，输入正确和错误密码是否得到了正确的正常和异常返回结果；以及显示的返回结果是否与实际结果一致等。 |
| 数据流转测试 | 主要指xx端与xx端之间的数据通讯是否准确，以及xx和xx流程的数据流转是否正确等。 | 例如：xxxx成功后，分配的xx是否准确，做的数据权限是否正确 |
| 后台线程测试 | 系统定时任务检查是否正确执行 | 当前xx结束后，账号是否清除，下次是否需可以重新注册，到xx节点，流程流程是否按时间更新流程数据状态 |
10.2、兼容测试
兼容性测试主要应针对客户端，并且根据客户的要求并结合实际，确定本次测试把B/S架构项目兼容性测试的重点，在于浏览器和操作系统的兼容测试
| 兼容对象 | 测试重点 | 备注 |
| 操作系统 | 不同的操作系统访问考试系统是否存在问题验证 | 主要包括Windows7,8,10,11，mac |
| 浏览器 | 页面各功能的可用性，界面显示的美观、一致性 | 此为兼容性测试的重点。通常需要兼容谷歌浏览器，火狐浏览器，IE浏览器，360安全浏览器，Edge浏览器，搜狗浏览器，Safari浏览器，UC浏览器，360极速浏览器，QQ浏览器 |
| 主流软件 | 验证支付流程打开其他主流软件，是否会造成冲突 | 主要针对本次支付过程配置的不同渠道：支付宝，银联，微信等支付流程正常 |
| 网络兼容 | 对不同网络，系统功能是个有影响 | wifi，接网线 |
| pc端分辨率 | 验证主流分辨率下系统的正常性 | 次为兼容测试重点，包括：1920x1080，12801024，1024768，1400*1050主流分辨率下的页面展示正常 |
10.3、性能测试【需要确认流程考试阶段日常数据量】
根据客户要求和实际应用场景，性能测试将对以下场景和流程进行性能测试，详细策略如下：
10.3.1 性能测试场景
- 注册流程：
1、用户从输入信息到提交注册过程中，响应不超过5秒
- 登录流程：
1、登录接口并发100000用户，响应时间不超过3秒
2、用户从输入账号密码，到登录成功，跳转主页，全流程响应时间不超过10秒
- 查成绩流程
1、点击查询xx，数据请求到渲染响应不超过5秒
- 报名提交接口
1、50000用户，下载xx流程1小时内下载50000不报错，稳定运行
2、50000用户，点击上传xx，选择文件，到文件正确渲染流程响应时间不超过10秒
3、50000用户，填写信息后，点击确认提交xx过程响应时间不超过3秒
- 门户
1、xx开始入口跳转到登录页面，页面正确渲染，不超过5秒
10.3.2 性能测试策略
- 负载测试：不断增加压力，直到超出预期性能指标，或某种资源达到饱和状态。
（1）能找到系统所能承受的压力（在正常指标、资源范围内，如响应时间超过10秒，CPU大于70%）
（2）可以配合系统调优
- 并发测试：多用户并发访问同一个应用或模块
（1）主要关注并发访问时，是否内存泄露、死锁、其它资源争用的问题。
（2）“并发用户数”的估算，需要结合实际，并根据特定计算公式得出。
- 疲劳测试：较长时间的使系统处于一定压力下，看是否能够稳定运行。
（1）使CPU或其他资源处于较高的利用率下，持续运行一定时间，并关注整体运行状况。
（2）使CPU压力增大，可以等同于小压力情况下更长时间的运行效果，相当于是“压缩时间的测试”。
10.4 验收测试
内部验收测试是为了验证系统满足需求说明书要求，满足项目组规定的要实现的功能流程，通过内部验收测试标准
| 测试项 | 测试方法 | 预计结果 | 实际结果 |
| xx | 手工测试 | 和需求一致 | |
| x | 手工测试 | 和需求一致 | |
| xx | 手工测试 | 和需求一致 | |
| x | 手工测试 | 和需求一致 | |
| x | 手工测试 | 和需求一致 | |
| x | 手工测试 | 和需求一致 |
十一、测试通过准则
11.1 验收标准
按照《xxx测试验收标准》当作本项目测试准出标准。即按照用例执行情况作为判断标准：
（1）功能性测试用例通过率达到100%
（2）非功能性测试用例通过率达到95%
（3）没有高于优先级3以上的问题
11.2 验收备选标准
根据实际情况由软件开发部门的经理，项目经理和测试负责人共同讨论确定本测试阶段是否结束。（实际按照每个阶段的准入准出规则）
十二、交付成果
| 文档 | 文档内容 | 文档类型 | 责任人 |
| 测试方案 | 项目信息、测试内容、测试人员 | word | xx |
| 测试用例 | 项目用例 | word | x |
| 功能测试报告 | 用例执行情况，bug修复情况，测试通过率，参建各方确认 | word | x |
| 性能测试报告 | 用例执行情况，bug修复情况，测试通过率，参建各方确认 | word | x |
| 测试规范 | xx测试规范文档 | word | x |
十三、风险预估
| 风险分类 | 风险点 | 预设方案 | 备注 |
| 需求风险 | 移动端未确定是否要做，需求断续，不能一次确认，逻辑修改较频繁 | 实施跟进情况，预留了一定人力资源以备移动端的工作安排 | |
| 开发阶段风险 | 提测质量不达标 | xx月xx日进行冒烟测试，若不达标，返工直到通过方可正常进入测试工作 | |
| 研发并行开发其他项目 | 和研发协商进入测试阶段，中后期通过赶工期、加班，增加人员避免项目验收延期 | ||
| 延期提测 | 分批提测，但是不得超过一周还未提测完所有东西 | 后台主流程还未完成研发，xx日只提测了基本的字段配置，测试有延期风险 | |
| 文档风险 | 交付文档要求不确定 | 先按照word进行文档存档，测试后期排2天工期进行报告输出，测试前会跟进确定文档格式要求 | 已确定文档按xxx模板要求内容编写 |
| 人力资源风险 | 软件测试时间，成本风险造成的不能对软件进行较全面的测试，导致测试不完善 | 保障主流程和重点功能的前提下，通过预设回归时间和交叉测试进行尽可能覆盖 |