第1版

上线阶段

创建相应测试Job

遵守测试发包节奏

线上监控

Flow

每日汇总bug

按要求执行测试

UI图

创建测试Job

项目总结

开发

UCP

需求阶段

生成测试计划

测试执行阶段

自动化统计表格

产品/UI

测试

发布阶段

Job

复盘时间1、对本次需求进行梳理和总结，继续完善测试用例并归档，形成知识文档（业务知识建议放在自己部门下），定期进行分享2、上线T+1日完成本次项目复盘缺陷统计：1、遵守缺陷管理规范，可以使缺陷统计更加精确2、对Bug进行分类，多维度、多角度进行Bug的分析改进措施：1、针对复盘会上提出的问题，做出相应的改进措施并且落实2、在下一个复盘中，回顾改进措施的执行情况，进行适当调整

需求宣讲

测试准备阶段

参加概要设计

遵守测试发包规范

测试活动

参加开发详设

内部评审

维护OTP测试用例

线上验证

评审UI图

自动化脚本

开发详设

遵守bug提交规范

做好测试执行记录

参加/组织项目复盘

如果公司有采用灰度发布的话，才会有这个发布阶段线上监控：1、观察是否根据上线前制定的发布方案，正确的进行了发布，灰度范围是否正确2、其他同上线阶段的线上监控。收集反馈：1、收集业务方反馈的问题或者是优化点，针对这些与产品及开发确定排期是否可全部发布：1、根据发布方案，评估是否可以进行全部发布

内部评审测试用例

编写测试用例

提供账号知会UI

用例评审

冒烟测试：1、开发提测之后，测试人员可先进行冒烟测试，提前发现主流程问题，冒烟测试存在严重问题，可打回给开发，拒绝提测测试环境：1、原则上测试人员，须在上预生产之前完成所有用例，部分用例无法执行的可酌情在预生产环境中测试2、期间产生的Bug，根据Bug管理规范进行处理3、尽量实现自动化，后续也会对自动化覆盖率进行统计，帮助完善自动化测试用例测试执行：1、测试发包节奏，内部测试每工作日发包两次，     1）头天下班前(比如20点)发包，方便次日可以直接开始测试工作     2）14:00    若涉及外部上下游功能的部署，需在测试沟通群知会大家无异议后，再行部署发包2、测试发包规范：     1）出现阻塞性bug视为发包失败，修复后需立即进行发包     2）无阻塞性bug，待bug基本修复完成(比如80%)或一轮测试完毕，再进行统一发包3、记录要用到的SQL语句、调用的上下游接口、高频/线上bug测试/复现方法/产生原因/解决方案、高效好用的测试方法和技巧，可能的风险和遇到的问题，已知bug等（原则：让不熟悉本模块业务的测试人员可以快速上手，按质按量完成测试工作）4、在UCP对应模块建立任务，工时按实际耗时进行填写，如今天测试某模块耗时2小时，下班前要保证完成当天的测试执行任务5、测试环境，通常执行2轮测试     1）第1轮测试要求：冒烟测试通过、无阻塞bug，全用例执行完毕     2）第2轮验证第1轮测试的bug，全用例执行完成、兼容性测试、交叉测试，和进行探索性测试，第2轮测试无未解决bug，已知bug均记录妥善的应对方案，具备进入预生产环境的条件6、根据实际测试情况，维护OTP的测试用例沟通与协作：1、对于需求问题，积极与产品和开发进行沟通，及时报告进度，反馈风险2、推荐产品、开发、测试能够参加每日站会，及时反馈问题，暴露风险，每日16:45前汇总现有bug及对应的等级，要求开发做到日清，未能日清的bug需列出，并记录原因3、界面稳定后，提供测试账号给UI，验证UI保真等效果预生产环境：1、原则上测试人员，须在上线之前完成所有用例，部分用例无法执行的与产品及开发沟通解决方案，方案落实之后根据方案进行处理2、在时间允许的情况下开展探索性测试协助验收：1、协助产品进行验收测试，评估是否达到上线标准2、制定上线计划，上线计划应包含上线计划、发布计划、线上验证范围、应急处理方案、回退方案，尽量保证项目能够完美上线

复盘阶段

参加需求评审

概要设计

测试创建

Story

开发拆解

编写用例

线上验证：慎重！有条件的话，一般只会做一些简单的验证操作，禁止出现高危操作，对于未知的操作不盲目操作，必须保证对线上环境的0影响线上监控：通过公司的监控平台，观察系统是否运行稳定，一般会看下项目是否有报错，各项机器指标是否正常等线上问题处理：1、线上问题处理第一处理原则，将影响降到最低。对于没有把握的操作，及时请教相关人员2、根据验收标准，确定问题处理方式，一般有：终止上线回退版本、修复后再次上线、确定修复时间继续上线。

组织测试用例宣讲

需求前期：1、提前了解后续大致的需求内容，提出合理的见解及看法2、需求宣讲之前，先需求文档过一遍，了解需求背景，思考本次需求的必要性，列出疑问点，找出需求不合理或者遗漏的地方，会上进行讨论需求分析：1、检查需求文档 、原型图、 UI 图 ，宣讲时提出的问题是否已完善到需求文档中，是否还存在描述不清楚或者有矛盾的地方，找产品核实和确认，无法及时回复的记录下来持续跟踪。2、分析需求的合理性以及完整性， 针对需求提出自己的看法需求确定：跟踪以上提出的关于需求的问题，沟通需求内容，与产品、开发对本次的需求达成统一的认识

测试范围：1、整理测试思路，确定测试范围，包括本次需求覆盖的范围及本次需求可能影响到的范围2、选定测试策略，确定本次测试侧重点，评估工作量，评估大致时间节点，测试任务多时进行分工用例设计：1、根据需求和分工(若有)在OTP测试平台按规范编写测试用例，标注用例等级，根据测试范围和影响范围生成用例评审计划2、对于一些公共的测试元素，可以形成一些设计规范，也可以运用OTP的公共用例库，形成一些公共的用例模板用例评审：1、在正式用例评审前，须由组内测试人员(非编写用例者本人)进行内部评审，并请相关产品和开发对用例进行预先评审，拉会议商定用例宣讲时间，订会议室2、正式用例评审时，需做好会议记录，也可请其他人员(非测试用例宣讲者本人)，记录在评审中提出的问题，需要修改错误的用例、补充遗漏的用例、删除的多余用例3、梳理测试流程，强调重要测试场景，与开发和产品确定本次需求的验收标准完善用例：1、针对用例评审结果(会议记录内容)，修改用例，修改完成再次请相关人员进行评审，直至测试用例完整、理解无误，评审无疑问2、通过开发同学的设计文档、设计思路、开发框架了解开发实现，评估可测试性，补充测试点3、扩展思维，多角度（如：并发问题、性能、安全、审计等方面）思考，不断扩大测试范围测试计划：1、生成开发自测计划，一般涵盖的是主流程的测试用例和一些重要功能的用例2、生成冒烟测试计划，基本同开发自测计划3、生成常规测试计划，应包含本次测试范围+影响范围的所有测试用例4、生成预生产测试计划，应包含常规测试中一些重要的测试用例，和测试环境出现问题较多的模块5、生成验收测试计划，根据评审时确定的验收标准筛选的测试用例测试预热：1、准备测试数据、测试环境（配置中心值、基础数据等）、测试场景2、若被测系统与其他系统存在交互，则应该提前与其他系统测试人员进行沟通，确定系统间的测试职责划分，避免重复测试或者遗漏测试3、根据情况，可提前开始接口测试或者提前开始设计自动化测试脚本4、跟踪开发进度，保证在约定时间点提测，开发自测计划由开发执行，须在提测之前执行完成，在提测前一天，开发自测完毕，要预留时间给测试进行冒烟测试，以确保提测成功，不影响次日测试工作的开展

协助产品验收