一、测试流程
关键事项说明：
1、在【需求评审会】上，产品标注需求优先级，确定技术Owner和测试Owner。技术Owenr预估【技术评审会】时间，技术评审包括接口设计、数据库设计、中间件设计、缓存设计等；测试Owner需要在技术评审前熟悉需求，并预估测试人力。
2、在【技术评审会】上，进行任务拆分，并确定前端、后端、QA的最终参与人员。
3、在【项目排期会】上，确定整体的迭代计划，包括前端开发时间、后端开发时间、联调时间、提测时间、用例编写时间、用例评审时间、测试截止时间、产品验收时间、发布上线时间。当需求较大时，不建议按照细分的开发任务进行提测（时间不好把控），可以按照需求优先级分两批进行提测，两批提测的需求和各时间点也要在排期会上确定好。
4、QA需要组织【用例评审会】，一般要在联调开始前进行，并在会议结束后给到最终版本的测试用例，相关产品和主要研发人员预留好时间，最好都能参与。
5、QA需要在开始联调前将冒烟用例提供给研发人员（必须通知到技术Owner），技术Owner在联调过程中负责安排相关研发同学执行冒烟用例，并在TB里将状态改为【联调中】，在执行冒烟用例的过程当中，有疑问及时联系产品、QA。同时QA需要在前端和后端研发联调时，关注联调进展，如果联调不顺利，需要提前介入，并及时上报风险至项目干系人，push问题解决。
6、联调完成后，技术Owner负责发送提测申请（邮件或者钉钉群），包括提测需求列表、测试环境、配置地址、代码分支关键信息等，并在TB里将状态改为【待提测】
7、提测后，QA在1-3小时内，完成冒烟用例的执行，冒烟测试不通过，QA回复提测申请确认拒测（实际上继续在测试可测部分），并记录拒测次数，在测试报告和项目复盘时体现；冒烟通过，QA回复提测申请确认通过，并在TB里将状态改为【测试中】，并进行后续测试。如果测试人力是大于等于3人力，QA需要每日在项目群里发送每日进度报告，同步进度和风险。
8、进入测试阶段后，QA视测试进展，提前预约产品和设计同学进行产品体验和视觉还原的时间（一般在测试环节的中后期），产品体验和视觉还原发现的问题，汇总问题list并发到项目群里，测试Owner负责跟进问题的解决进度，待全部问题解决并测试通过后，在TB里将状态改为【验收】，通知产品和设计同学进行最终的验收工作，产品和设计同学验收通过后，发送验收通过结论。
9、测试完成后，QA需要发送测试报告，包括但不限于：测试结论、缺陷分析、上线步骤、舆情风险等
10、技术Owner收到测试报告后，在TB里将状态改为【已完成】，上线前在产品研发群里预告，确保通知到项目干系人，研发确认发布完成后，及时通知QA进行线上验证。
11、QA进行线上验证，验证完成后，同步结论到项目群里。
12、项目复盘，准备复盘材料，包括各个时间节点是否延期、需求变更次数、技术变更次数、缺陷分析
二、缺陷相关
缺陷来源：前端、后端、产品、设计
缺陷类型：界面错误、跳转错误、兼容问题、代码错误、需求缺失、需求歧义、配置相关、环境问题、安全相关、性能问题、其他
缺陷状态：待处理、处理中、已解决、已关闭、已拒绝、重新打开、延期处理
缺陷概率：必现、偶现
三、用例设计
1、功能测试用例包括冒烟用例和全量用例，冒烟用例包括主流程、主功能。全量用例包括本次迭代的功能，主要从以下方面进行设计：页面元素、交互体验；核心功能、主要逻辑；异常逻辑、校验规则；关联影响，兼容回归等。
2、QA在用例编写完成后，需要标注P0级用例（即冒烟用例），在用例评审完成后，将P0级用例（即冒烟用例）单独拆开，并提供给研发同学。
3、客户端属性多点的用例主要是交互和操作为主、服务端属性多点的用例主要以数据落库、缓存信息、配置修改等为主。
用例demo：
四、测试报告
1、测试报告包括冒烟报告、测试完成报告、每日进度报告
2、冒烟报告在冒烟完成后发送，包括测试结论、未通过用例、限时修改时间等信息
3、测试完成报告在整个测试结束后发送，包括但不限于：测试结论、缺陷分析（总数量、有效缺陷数、无效缺陷数、已解决数、未解决数、严重等级、缺陷根源、缺陷类型等）、上线checklist（技术Owner提供）、上线影响、舆情风险（产品同学通知到运营老师和客服同学准备相应安抚话术）。
4、每日进度报告在当日测试结束后发送，测试进度包括：总体进度、模块进度、风险点、未解决的缺陷list
五、线上事故
1、线上事故登记，包括事故定级、事故影响、事故回顾、事故原因及责任、临时处理方案、长效处理方案、事故通报等
2、确定是bug的线上问题，需要组织CaseStudy，分析问题产生原因、预防方法，并监督落地
3、线上问题响应率—— 已响应数/周反馈总数
线上问题解决率——（已解决数+无法定位数）/周反馈总数
线上问题响应时长——响应时长= 解决问题的时间-反馈问题的时间
4、线上监控建设：业务指标监控、业务接口监控、服务健康监控（待建设）
附件一：模板
模板一
提测申请单
【提测人】
【版本名称】
【提测需求】
【环境信息】测试环境、配置地址、代码分支
【自测结果】通过（问题说明）
------------------------------------------------------------------------------------------
模板二
冒烟测试报告
【时间】xxxx/xx/xx
【版本名称】绘本馆2.5
【冒烟结果】通过/不通过
【问题列表】不通过时填写 @对应研发
------------------------------------------------------------------------------------------
模板三
每日进度报告
【整体进度】30%
【缺陷情况】总数量、已解决、未解决
【功能详情】
1、需求1 20%
2、需求2 40%
3、需求3 未开始
4、需求4 未开始
…
【风险同步】
1、环境问题导致功能不能测试 @对应处理人
2、冒烟不通过，测试需要顺延0.5d 测试时间 @对应处理人
…
【缺陷地址】未解决的缺陷地址 @技术Owner跟进解决
------------------------------------------------------------------------------------------
模板四
测试报告
【版本】xxxxx
【测试结论】测试通过/不通过
【缺陷情况】总数量、已解决、延期处理、缺陷根源、缺陷类型
【功能详情】
1、需求1 100%
2、需求2 100%
3、需求3 100%
4、需求4 延期 @相应研发
…
【注意事项】
1、上线配置
2、上线步骤
------------------------------------------------------------------------------------------
模板五
版本质量报告
【版本名称】
【参与人员】
【变更次数】
1、需求变更（影响工时）
2、技术变更（影响工时）
【缺陷分析】
1、缺陷数量
2、缺陷质量（有效缺陷、无效缺陷）
3、严重等级（致命、严重、一般、建议）
4、缺陷根源（产品、前端、后端）
5、缺陷类型
【提测质量】拒测次数
----------------------------------------------------------------------------------------
模板六
验收问题清单
可以分别列出来，或者贴上问题清单的链接
------------------------------------------------------------------------------------------
模板七
验收报告
【验收结果】
1、需求1 验收通过/验收不通过
2、需求2 验收通过/验收不通过
...
------------------------------------------------------------------------------------------
