通用测试流程

一、需求阶段

1.产品提供相关需求功能文档及原型

2.产品/开发/测试需进行需求评审，产品针对需求评审中的意见修改需求文档并以文档或邮件的形式及时更新同步给项目相关开发测试人员

二、研发阶段、测试准备阶段

研发阶段

1.开发提供开发设计方案

2.开发设计评审

（1）产品/开发测试参与，针对需求开发讲解代码如何实现，实现过程中有无遗漏有无异常场景

（2）开发提测前自测

    自测包括静态代码扫描、单元测试自测通过后方可提测，提测时需发提测邮件（提测邮件模板）

    提测标准：自测后，提交测试时，无阻碍性bug，保证功能基本可用（阻塞bug需要低于多少，Bug数量需要低于多少，BugReopen率应该低于对少）

测试准备阶段

（1）根据需求功能文档，判断使用哪种测试方案（接口测试/功能测试）进行测试

（2）根据需求文档及开发设计文档编写测试用例，

  (3)  测试用例评审（邮件/会议：目的对需求进行剖析细化，发现需求遗漏）

（4）准备项目需要的测试环境

（5）时间要求

　　测试人员：测试方案完成时间，测试用例提供时间，测试人员投入时间，测试计划完成时间
　　产品开发：需求确定评审时间，项目提测时间，交付时间

三、测试阶段

（1）冒烟测试：保证提测的功能可用且不阻碍流程，若阻碍主流程则冒烟测试不通过

（2）功能测试：执行每条测试用例，保证需求功能文档中的功能点都实现了且对已有功能无影响

（3）回归测试：保证提测的功能可用，且系统的主流程没有问题，测试报告发送之后才能上线

回归测试上线项目代码需合master，在master分支进行回归测试，若有bug需修改，需提交bug后才能往master上提交代码

测试报告包括：测试过程中发现的问题及上线以后可能会出的质量问题，已知风险的沟通解决方案，项目上线建议等。

如：单元测试100%，接口测试100%，UI测试30%

如：研发修改代码后，执行相应的单元测试、接口测试应该全部通过才可合并代码

如：每天晚上定时部署后，结果应该高于哪个指标之上
如：日构建，每天提交的版本一定是无阻塞性问题的
如：Bug日清，规定6点前测试提出的bug必须解决

四、上线阶段

开发、测试、产品未上线时需做对应的上线准备（如：代码的合并/db变更/配置变更/权限申请等）

上线前，开发/测试/运维需确认当前版本是否符合上线条件，符合方可上线

上线方案：是否先上预发布，批量上线，验证一小部分服务器功能正常方可继续上线，否则进行回滚代码

上线后需监控线上环境看日志是否有报错，验收线上功能是否实现，是否有影响到未改动的功能

如：上线后的质量应该达到什么程度，若有问题相应速度应该达到什么标准。