研发测试流程

开发工作

产品验收测试

钉钉申请自动部署上线

接口测试结果

N(上线前测试不通过)

会议

需求评审输出需求文档

开发修复Bug

开发已修复Bug且自测通过

概要设计制定开发排期

一次迭代开始

测试相关文档

UI/交互评审输出UI交互稿

Y测试通过

后端API

版本发布决策原则1．版本的发布，应开发／测试／产品三方达成共识，共同决策2．针对挂起的、有争议的bug，产品需要站在市场、用户、成本等角度中立客观的作出判断3．如三方中任何一方对版本发布存在强烈异议，则上升至部门层面讨论并最终决策

迭代/集成测试

UI走查

紧急修复

测试通过合入CI

N(冒烟测试不通过)提测打回

前/后端开发

Y测试环境验证通过

确认发布上线产品牵头三方决策

单元测试

Y验收通过

JIRA系统(Bug分配)

冒烟测试(快速验证)

单元测试标准（推荐）1.单元测试的基本目标：语句覆盖率达到80%2.核心模块的语句覆盖率和分支覆盖率都要达到100%3.编写单元测试代码遵循BCDE原则，以保证被测试模块的交付质量B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。C：Correct，正确的输入，并得到预期的结果。D：Design，与设计文档相结合，来编写单元测试。E：Error，强制错误信息输入（如：非法数据、异常流程、业务允许外等），并得到预期的结果。

软件版本发布标准1．没有遗留“致命”或＂严重”级别的Bug；2．没有遗留处理优先级为P0或P1的Bug；3．没有遗留明显影响用户体验的性能Bug；4．版本累计Bug总修复比例大于90％（除建议类Bug）即版本上线前累计Bug挂起率应小于10％（理论值非严格标准，视项目具体情况而定）；5．后台已部署真实数据，并且环境稳定。测试结论定义＊存在状态为【新创建／处理中／已解决】的（未处理）Bug＊存在挂起的【致命／严重】级别Bug＊Bug挂起率＞＝10％——符合以上任意条件，则测试结论为：【不通过】＊所有Bug均为关闭状态（无未处理的Bug）＊Bug挂起率＜10％，且仅存在【一般／提示／建议】级别的挂起Bug——符合以上所有条件，则测试结论为：【通过】

N

UI工作

UI交互设计

同步接口协议

上线前测试

N测试不通过

N(产品验收不通过)

上线后测试

N出现明显严重Bug

由测试统一提交到JIRA

N自测不通过

Y(冒烟测试通过)

N无变更

在测试环境对接口进行测试

完成

上线结束

产品验收标准1．已完成本次迭代计划的全部功能2．功能流程路径逻辑正确，符合需求设计3．用户体验良好，无明显Bug

完成联调完成自测

产品工作

提测标准1．本次迭代／集成的需求功能都开发完成2．测试所需的真实数据都准备好3．测试接到提测会进行一轮快速测试（2小时以内）：    -发现致命的BUG并阻碍测试进程，则将提测打回    -发现严重并紧急的Bug超过3个，则将提测打回    -发现部分需求功能未开发完成，则将提测打回    -发现部分功能实现与需求严重不符合的，则将提测打回

重新评估(延期/重做)

提取测试点需求澄清测试计划制定测试排期

接口协议编写

持续CI运行

回归测试(提测标准)

回归验证

Y快速验证通过(线上数据、程序运行稳定性等)

接口说明文档

企业微信通知

接口测试

Y

相关文档项目验收文件（测试方案/计划/报告/用例等）

产品确认迭代目标和需求

接口脚本编写

Y变更

接口协议评审输出接口文档

Bug修复

回归测试提测标准1．修复80％以上的Bug，才可以提交一轮回归测试2．Bug回归通过率低于60％，则该轮回归测试被打回3．回归测试中新引入严重并紧急的Bug超过3个，则该轮回归测试被打回4．回归测试中新引入致命Bug，则该轮回归测试被打回

提交Bug到JIRA

Y(回归测试通过)

接口是否变更

N(回归测试不通过)

测试工作

评审通过

N(后期优化)

Y(自测通过，达到提测标准)