项目测试流程规范
1.需求阶段
1.1 需求粗评
确认需求
创建需求目录
1.2 需求细评
提出需求建议和问题
熟悉需求内容
评估工作量
2.技术设计阶段
技术评审会议
根据需求和技术方案，梳理测试方案要点
跟RD拉起技术排期
实际评估工作量
排期时间包括：
线下测试、线下联动调试、pre回归测试、线上联动调试、线上回归测试、路测/灰度测试
排期时间包括：
线下测试、线下联动调试、pre回归测试、线上联动调试、线上回归测试、路测/灰度测试
灰度测试：
用于在软件正式发布前进行小范围的尝试。灰度测试通过逐步扩大试用者数量，发现和纠正新功能或重大改版中可能存在的问题，以提高软件质量。灰度测试结合了黑盒测试和白盒测试的特点，测试人员对系统的内部结构、设计和实现有一定的了解，但不完全了解所有的细节。这种方法可以帮助团队及早发现并修复系统的缺陷、性能瓶颈和潜在的安全漏洞，提供有关系统质量和稳定性的重要信息，以便优化系统
3.测试准备阶段（开发阶段）
输出测试方案
输出测试用例： 全量用例、准入用例、联调测试用例、端到端的用例
输出路测方案
测试数据准备
准入Case定义：
准入Case，官方理解为冒烟Case，旨在快速验证软件的主要功能是否正常工作。用于筛选出潜在的重大缺陷，并确保软件的基本功能能够正常运行。
准入case的基本原则：
包含需求的主要流程用例
包含业务域内主流程用例
4.测试评审阶段（开发阶段）
评审： 测试方案、测试用例、路测方案
修订评审过的测试方案、路测方案
修订评审过的用例
上传定稿到oe
创建测试任务 ： RD联调准入计划、QA准入计划、sim计划、预发计划、线上计划
全量用例、准入测试计划链接、归档测试方案、用例、准入测试任务、路测方案发群
路测方案给运营
sim环境：高仿真环境
5.研发联调
协助RD构造测试数据
关注联调测试进度
6.代码CR阶段
CR会议
按照CR需要关注的规范点，提出相应问题
QA加签
CR需要关注的主要内容：业务实现、代码性能、扩展和复用、编码风格
- 业务实现
代码是否完全实现了设计文档中提出的功能需求
代码是否已创建了功能需要的数据库、缓存等，包括正确的初始化数据
代码中是否存在任何没有定义或没有引用到的变量、常量或数据类型
代码的逻辑是否符合需求
所有的变量都被正确定义和使用
代码中是否存在硬编码 - 代码性能
代码中是否存在死循环
代码是否避免了无穷递归
代码是否采取了措施避免运行时错误，如边界溢出、被0除、值越界、堆栈溢出等 - 扩展和复用
代码应该具有可扩展性、且可以复用
减少冗余代码，预见后期代码的可扩展需求
程序的每个功能是否都作为一个可辨识的代码块存在 - 编码风格
代码中使用的格式、符号、结构等风格是否保持一致
代码是否符合制定的标准
所有的注释都准确
7.提测阶段
关注研发是否按时提测
检查提测内容
8.测试阶段
8.1 准入测试
执行准入测试计划
准入测试通过，接受提测单，否则打回提测单
测试账号归档
oe上发测试日报
8.2 线下详细测试
执行线下sim环境测试计划
提报bug
测试账号归档
cooper和oe上发记录
线下联调测试
通知产品验收测试
通知UI验收测试
8.3 pre回归测试
执行预发测试计划
提报bug
测试账号归档
oe上发测试日报
pre环境联调测试
通知产品验收测试
通知local文案验收测试
确认项目bug全部修复
oe发准出
8.4 QAshowcase阶段
showcase执行
8.5 线上回归测试
执行线上测试计划
提报bug
测试账号归档
oe、群同步测试进度
9. 准出阶段
9.1 线下测试准出
确认线下bug状态均已完成
9.2 pre测试准出
oe上发准出
9.3 线上测试准出
发线上回归测试回执
