| 周期/时间 | 发起人 | 参与人 | 形式 | 产出标准 | ||
|---|---|---|---|---|---|---|
| 需求评审 | 两周一次/周二下午四点 | 项管 | 产品、研发、测试、项管理 | 会议 | 在周一分配每个需求到对应的测试人员后，对应人员在需求评审前熟悉需求。标注不需要技术评审的需求，每周三（需求评审后一天）下班前给出排期；如果需要技术评审的需求，待技术评审会议结束后，当天跟开发一起给出排期。 | 输出测试计划 |
| 技术评审 | 需求评审结束后/视具体需求排期 | 开发 | 产品、研发、测试 | 会议 | 技术评审后，需要梳理改动范围，需要回归的范围，并合理规划测试排期。 | |
| 用例设计 | 技术评审结束后/视具体需求排期 | 测试 | 测试 | xmind思维导图/Excel文档 | 输出xmind编写的思维导图，对应需求的tapd链接上传Excel形式的测试用例。 | |
| 脚本设计 | 接口文档给出后 | 测试 | 测试 | python框架编写/自动化测试平台编写 | 针对改动和涉及范围的接口编写测试脚本，校验入参和出参等 | |
| 用例评审 | 测试用例编写完成之后 | 测试 | 测试、研发、产品 | 会议/测试工位处讨论 | 评估测试方案是否覆盖全面，修改并确定上传tapd | |
| 需求提测 | 研发开发完成后 | 研发 | 研发、测试 | jenkins部署后，更改需求状态 | 开发人员在功能开发完毕后，首先要进行自测，自测通过后，再提交测试代码 | |
| 测试环境 | 研发提测后 | 测试 | 测试 | 手动测试、自动化测试 | 测试人员测试完毕后，通知产品进行验收测试，并记录测试结果及问题，交由相关开发人员进行再次迭代 | |
| 预发环境 | 常规版本每周三 | 研发、运维 | 测试、研发、产品、运维 | 测试和产品在预发环境进行验收 | 通过测试环境的测试后，研发人员撰写上线方案。（上线方案须包括：应用部署顺序及应用关联性、是否关闭其他应用服务、定时服务、数据库脚本，涉及的服务影响范围以及上线失败的回滚步骤。） | |
| 生产环境 | 常规版本每周四 | 研发、运维 | 测试、研发、产品、运维 | 测试和产品在生产环境进行验收 | 发布完成后，运维人员通知测试人员、产品、及研发进行线上测试，输出测试结果及问题。如出现问题，在计划时间内解决，执行回滚方案，并进行重新发布测试和预发环境。不影响功能的bug，留到下个版本解决。测试通过后，测试人员回复测试通过邮件，发布结束。 | |
| 阶段 | 测试工作 | 异常处理 |
|---|---|---|
| 需求预评审会（测试组长） | 1、从产品设计、开发技术实现层面提出质疑或漏洞 2、了解需求背景，在测试角度审视是否有更方面快捷的办法可以实现（运营测/封控测/业务技术实现测/产品交互测） | |
| 需求正式评审会 | 1、梳理清楚产品需求，初步了解技术实现，关注是否有相关人员（封控）未知晓等 2、记录会上存在争议的问题，会后与产品、技术确认 | |
| 技术评审 | 1、参加技术评审，理清技术实现以寻找漏洞 2、在对应TAPD上创建测试任务以及排期（大概时间） | |
| Coding | 1、设计测试用例，需在提出日期前两天进行用例评审 2、用例评审会邀请具体产品、开发、测试负责人参加即可 2、用例评审完成后，上传终稿至TAPD并关联到该需求下 | |
| Code done | 1、收到提测通知后，进行冒烟测试 2、冒烟通过后正式开始测试工作（并更新TAPD测试状态以及确切测试完成时间），同步产品及项管 3、如冒烟不通过则驳回开发，并同步到测试负责人 | |
| Testing | 1、测试进度如不可控及时同步测试负责人（质量失控/员工休假/其他模块冲突/项目组依赖等） 2、测试完成70%或，即通知UI设计师验收（如有） 3、距离上线3天开始与开发沟通以下事宜： a、上线部署顺序（前端/客户端/后台/封控/爬虫等），如果所有方案都不能兼顾，则需要选出影响最小的方案并报备测试负责人 b、生产测试账号准备，如测试账号不足则通知测试负责人调配资源 | |
| Test done | 1、通知产品验收，以及通知产品与各内外协作方沟通上线事宜 2、TAPD状态更新 | |
| 发布预发/生产 | 1、发布完成后，测试人员开始验收预发环境有无问题 2、确认预发环境无误，测试发版主导人回复邮件测试结果 3、运维发布生产 4、测试人员确认生产环境无误，通知测试发版主导人 5、测试发版主导人回复测试结果 6、发布结束 | |
| 设计思路 | 用例分层 | 用户场景 | 用户路径，包含正常及异常场景 | |
|---|---|---|---|---|
| 系统分层 | 1、前端/移动端交互（包括页面渲染、交互逻辑） 2、后端逻辑（包括接口功能、数据库表、中间件） 3、端到端集成（前端&前端，前端&后端，后端&后端） | |||
| 集成专项 | 性能、稳定性 | |||
| 兼容性： 1、移动端系统版本兼容 2、新老数据兼容 3、新老用户兼容 | ||||
| 测试点覆盖 | 1、涉及到哪些端合作（风控，爬虫，客户端，其他项目组等），早了解早准备 2、涉及到哪些模块改动 3、需求针对单渠道还是多渠道 4、需求针对单产品还是多产品
| |||
| 技术优化类需求 | 1、为解决什么问题而优化？ 2、换成什么技术？这个技术的优点是什么？缺点是什么？ 3、中间处理逻辑的各个分支的正常、异常情况测试 4、业务影响面评估覆盖测试改动的模块、关联改动模块（对内和对外） | |||
| 用例评审规范 | 1、提前把测试用例发给参会人员查看 2、开场简述需求背景、技术实现、测试思路 3、演说顺序遵循用例优先级推进，解说干支，再到分支，以此类推 4、每个场景测试点需含预期结果 5、优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过 6、针对有疑问的点罗列出来，会后确定结果后，完善补全 7、超过5分钟无法确定结果的问题，留作会后讨论跟进 | |||
对外协作测试职责划分：
1、涉及业务交互，上游协助下游中间交互区域，主需求方统筹联调测试，要求协助方协助验证全链路，要求协助方保证其负责的链路段验收通过。
2、测试人员负责我方产品模块测试，严格区分。特殊情况特殊处理，但需TAPD文字说明。
3、我方理论上不承接合作方测试范围的任务，如为支援，仅作为测试执行角色。
4、全新的业务，优先由有相关测试经验的人员一方担任主测方。
5、我方服务沿用合作方服务时，只需关注合作方接口入参和出参，如出现接口逻辑错误，通知合作方修改即可，仅提供有限时间协助找出根源。
6、需求评审每个涉及到跨组的需求，组长均需评估。
1668
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
