测试流程规范
1、前言
1.1、编写目的
规范迭代过程中测试工作流，明确测试的准入准出以及各相关具体活动执行规则；本着测试驱动开发的思想，规范测试上下游的活动，有效的保证产品质量。
1.2、适用范围
参与软件产品测试的各测试工程师。
2、测试模型
2.1、适用软件生命周期模型
适用于敏捷，融合瀑布，瀑布等多种模型。
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，解决的是提供更有价值的业务、提升交付速度，目标是提高开发效率和响应能力，是目前市场上使用最为广泛的一种模型。
2.2、测试方法
迭代增量开发强调的是按照用户故事的优先级进行软件的小功能经常交付，因为迭代时间比较短，所以测试与开发并行，测试时间很短，常用的是功能测试+系统测试+探索性测试、补充测试。
3、流程规范
3.1、流程图
3.2、迭代开始前
3.2.1、需求评审
3.2.1.1、输入
产品经理需要提前输出《需求规格说明书》或需求原型，拒绝一句话需求或者口头需求。
3.2.1.2、具体工作
TIP
1.测试工程师在需求评审之前需要提前熟悉需求；
2.参与迭代需求评审，及时指出需求不明确之处；
3.2.1.3、准出准则
无
3.2.1.4、输出
要求：
输出文档：《xmind 测试点》，或其他思维导图；
输出时间：需求评审后一天内；
3.2.2、评估测试工作量
3.2.2.1、输入
《xmind 测试点》，或其他思维导图；
3.2.2.2、具体工作
TIP
1.测试根据产品经理讲解需求以及输出的测试点，评估此次版本测试所需工作量；
2.根据《测试计划》模板，估算此次测试各项活动的时间节点以及工作量；
3.测试人员根据负责的功能模块给出对应功能点的测试时间；
4.测试负责人收集各个功能点的测试时间，确认预估工作量的准确性和合理性。
3.2.2.3、准出准则
TIP
- 工作量估算公式：按照 1 天执行 50 条测试用例，1 天 8h 计算，即平均 1h 执行 6 条工作量进行估算；
- 每个功能点测试用例数量：（比如新增、编辑等细化的功能点）测试用例数量不得低于10 条；
- 第一轮测试工作量：按照 1 天执行 50 条测试用例的工作量进行时间估算；
- 第二轮测试工作量：为第一轮测试时间的 70%；
- 回归测试工作量：按照整体测试工作量的 50% 进行估算。
3.2.2.4、输出
要求：
输出文档：《xx 项目*版本名称*测试计划》；
输出时间：需求评审后一天内。
3.2.2.5、模板链接
测试计划【跳转候补】
3.2.2.6、度量数据项
转测时间：监控是否按时提测，记录进度偏差；
3.3、迭代开启
3.3.1 编制测试用例
3.3.1.1 输入
评审通过的《需求规格说明书》、原型；
整理的 xmind 测试点。
3.3.1.2、具体工作
按照场景描述法，在测试点基础上编制本迭代需求对应测试用例，包括测试前置条件，测试步骤，期望结果，优先级等；
🔔
测试用例数量要求（目前仅仅包含功能测试）：
1）测试计划中测试执行工作量要匹配：即工作量估算 1 天，则对应的测试用例数量为 50 条；
2）每个功能点（比如细化到新增、编辑层面的功能点）测试用例数量不得低于 10 条；
3.3.1.3、准出准则
TIP
（1）对应测试用例数量和工作量匹配，避免不一致；
（2）按照对应模板进行输出。
3.3.1.4、输出
要求：
输出文档：xmind及测试用例； 输出时间：开发发迭代周期的三分之二，比如开发周期为 6 天，则测试用例最迟需在第 4 天编制完成；
3.3.1.5、模板链接
见用例设计标准化，【候补】
3.3.1.6、度量数据项
测试用例数量：判断需求覆盖面以及衡量工作量。
3.3.2、评审测试用例
3.3.2.1、输入
xmind 及版本测试用例。
3.3.2.2、具体工作
测试人员组织召开测试用例评审。
| 用例评审 | 说明 |
|---|---|
| 时间 | 研发迭代周期的三分之二，比如开发周期为 6 天，则测试用例评审时间为第 4 天 |
| 资料 | 测试用例 |
| 目的 | 就本迭代测试范围、需求内容、测试覆盖、冒烟测试用例数量和开发、产品达成一致 |
| 人员 | 项目经理、项目组研发 owner、产品经理 |
| 责任人 | 产品经理 |
| 结论 | 通过 ? 修改后通过 ? 修改后评审 ? 不通过 |
评审结论：👀
评审通过：需求理解到位，迭代需求、相关功能影响点、异常场景均覆盖，用例覆盖 90% 以上，且用例描述清晰；
修改后通过：测试用例覆盖率达到 80%，编写的内容虽然有些时候通不过但是总体上处于可以接受的程度，存在部分功能修改；
修改后评审：测试用例覆盖率达到 70%，存在比较多的问题，需要进行较多修改；
不通过：存在较多的偏离需求，测试用例覆盖率低于 70%，很多细节都没描述到，需修改多次；
评审完毕，按照评审结果同步更新用例，输出完整的 excel 测试用例以及《自测清单》并上传至禅道。
3.3.2.3、 准出准则
测试用例评审通过。
3.3.2.4、输出
要求：
输出文档：《测试用例》、《自测清单》；
输出时间：评审后 1 天内。
3.3.2.5、模板链接
《xx 项目*测试用例》 全量测试用例 《xx 项目*自测清单》 开发冒烟测试用例 【候补】
3.3.2.6、度量数据项
用例评审通过次数：用于判断测试用例编写质量。
3.3.3、冒烟后转测
3.3.3.1 输入
《xx 项目_自测清单》 【候补】
具体工作
TIP
（1）研发人员：按照测试人员提供的《自测清单》转测前进行自测并更新测试结果；
（2）转测条件：冒烟用例通过率达到 95%才可转测；
（3）showcase 完成，无基本重大问题。
提测，内容如下：
| 项目名 | 版本号 | 内容 | 影响范围 | jenins 打包步骤 | 配置变更说明 | 负责人 |
|---|---|---|---|---|---|---|
🔔 注意：当对应服务无法通过 jenkins 打包的，需研发自行打包并提供压缩包；
3.3.3.3、准出准则
无
3.3.3.4 输出
要求：
输出文档：《xx 项目\_转测文件》；
输出时间：提测时提供。
3.3.3.5、模板链接
《xx 项目\_转测文件》 【候补】
执行测试
3.3.4.1、输入
《xx 项目\_提测文件》
3.3.4.2、具体工作
TIP
1、转测验证
项目测试负责人收到转测信息后，验证转测内容的完整性和规范性，即，是否包含转测文件所需内容；若未按照规范转测，可直接打回；
2、测试环境部署验证
- 测试人员按照研发提供的安装部署步骤在在 jenkins 上构建，并下载包，上传到服务器上按照研发提供的部署顺序和步骤进行安装部署，更新数据库 sql 脚本、资源替换、文件启停等；
- 部署过程中有问题的及时与研发沟通解决，并且将对应修改内容更新到转测文件中，以便保证后续上线部署时的完整性。
3、执行冒烟用例
- 开发提测，测试环境部署成功后，测试人员对照冒烟用例开始冒烟，并记录冒烟成功率以及转测是否失败（转测是否失败取决于冒烟用例是否 95% 通过）；
- 若转测失败，测试人员需要记录失败的原因以及对应测试数据。
4、功能测试
- 测试人员进行第一轮全量用例测试，记录测试结果，以及第一轮全量用例通过率；
- 测试进行第二轮全量用例测试，记录测试结果，以及第二轮全量用例通过率；
- BUG 录入时问题描述要清晰，步骤要具体，要选择问题出现的端和功能模块，有接口报错的记得贴接口、请求、返回、后台日志，前端问题要截图标注；
- bug 录入规范：
bug 录入规范
● 提单前针对需求确认好是否是问题，避免需求理解不正确导致的无效问题单；
● 问题描述要清晰，步骤要具体，要选择问题出现的产品、功能模块、影响版本，有接口报错的记得贴接口、请求、返回、后台日志，前端问题要截图标注；
5、BUG 回归测试
TIP
- 回归问题单前要构建后台环境，重新打包，前端要清缓存确认是否要重新打包；
- 有争议的问题要尽快拉上产品一起讨论；
- 研发暂不修复的需备注清楚不修复的原因；
- 回归测试穿插在两轮测试中进行（第一轮测试后 bug 回归测试依旧算第一轮，不算第二轮，第一轮 bug 修复回归完成后再开展第二轮测试）。
6、产品验收
TIP
- 第一轮测试完成后开始第二轮测试前，测试人员通知产品经理、UI 分别进行进行业务验收和 UI 验收 ；
- 产品经理和 UI 人员在原邮件基础上回复验收结论；
- 测试报告中记录产品和 UI 验收是否通过的结论。
:::
3.3.4.3、准出准则
要求：
1.产品验收通过；
2.UI 验收通过；
3.测试用例执行完毕；
4.禅道上项目 bug100%关闭；
3.3.4.4、输出
要求：
- 输出文件：邮件回复测试结果；
- 输出时间：测试结束。
.3.4.5、模板链接
无
3.3.4.6、度量数据项
TIP
- 冒烟用例个数、冒烟通过率；
- 第一轮开发质量：第一轮 bug 数量/第一轮测试用例数量；
- 第二轮开发质量：第二轮 bug 数量/第二轮测试用例数量；
- 整体开发质量：总 bug 数量/总用例数量。
3.3.5、封版
3.3.5.1、输入
测试结束且结果通过、产品验收通过。
3.3.5.2、具体工作
TIP
（1）项目测试负责人：测试通过后通知本迭代研发负责人提交上线申请；
（2）上线前：测试人员按照模板编制《测试报告》、《上线验证点》。
3.3.5.3、准出准则
按照模板编制，且《上线验证点》和研发、产品确认无误。
3.3.5.4、输出
TIP
输出文档：《测试报告》、《上线验证点》；
输出时间：完成测试封版后上线前。
3.3.5.5、模板链接
《测试报告》、《上线验证点》 【候补】
3.3.6、上线
3.3.6.1、输入
测试结束且结果通过、产品验收通过。
3.3.6.2、具体工作
TIP
（1）项目测试负责人审核上线流程：
确认上线范围、上线版本、部署步骤、打包顺序等内容是否和转测信息一致，且是否测试通过：
● 若不通过或不符合，打回；
● 若通过，则更新对应确认结果，并更新《xxx 版本上线流程》中测试部分以及上线部分内容。
（2）附件上传： 测试人员信息确认无误后，上传此次上线所需文件（脚本、配置文件等）、包（手动打包的情况）、《测试报告》、《上线验证点》。
（3）运维部署放量： 运维在预约上线时间内按照上线步骤等内容部署上线并开始放量。
（4）线上验证：
● 运维人员放量完成后通知测试人员，测试人员按照确认后的《上线验证点》、此次版本优化功能、此次上线版本影响点，进行线上主流程测试；
● 线上验证时间不超过 1.5h。
（5）通知线上验证结果完成上线： 测试人员线上验证完成后，通知运维、项目中成员线上测试结论，内容包含：线上验证是否通过，是否存在问题和风险，若存在需列出具体问题以及确认是否继续上线；
上线完成后需同步更新《项目测试进度计划表》中项目的状态和实际上线实际、测试时间。
3.3.6.3、准出准则
确认生产部署的服务、版本、脚本、配置文件、部署步骤和测试部署环境时一致；
完成线上测试。
🔔 注意： 线上验证时的测试数据在完成测试后及时删除。
3.3.6.4、输出
要求：
输出文档：《xxx 版本上线流程》、通知上线测试结果，更新《项目测试进度计划表》； 输出时间：上线测试完成后。
3.3.6.5、模板链接
《xxx 版本上线流程》，《项目测试进度计划表》 【候补】
3.3.6.6、度量数据项
以实际要求上线时间为准。
3.4、迭代结束
3.4.1、编制用户操作手册
3.4.1.1、输入
产品完成上线。
3.4.1.2、具体工作
TIP
（1）上线后 1 天内测试人员需要按照模板编制此次上线需求的《用户操作说明》；
（2）编制完成后发送给项目组成员和运维人员；
（3）文档上传至项目文档目录中。
3.4.1.3、准出准则
1.按照对应模板进行输出；
2.用户操作手册中避免关键信息、隐私数据的泄露；用户手册截图中对应数据，在造数据时按照实际业务走，避免不规范的测试数据。
3.4.1.4、输出
要求：
输出文档：《用户操作说明》； 输出时间：上线后2天内；
3.4.1.5、模板链接
《用户操作说明》 【候补】