到了新公司，由于是企业内部孵化的创业项目，各项流程不够完善，总架让我梳理下功能测试流程。
其实测试的工作是会贯穿于各个阶段的，所以一梳理，发现把整个流程都梳理出来了。由于现在还没有预发布/堡垒环境，项目要年后才会对外发布，所以只写到验收阶段。
因为一直使用的流程管理工具都是禅道，所以我们这边很多工作是围绕禅道的。
说得不好的地方欢迎各位大佬指正和各位同学给出更好的意见~
总流程图：

需求阶段：

需求设计阶段，需求设计出原型初稿；
需求评审阶段，前/后端开发负责人、测试负责人及相关人员参与评审，并给出评审意见；(尤其是那种只写一句话但涵盖很多内容的需求一定要打回去)
需求修改阶段，根据评审意见修改原型设计，并更新保真图；
需求拆分阶段，进行需求拆分，在禅道对应项目下建好任务；
ps:之前看 MSTC 大会 2019 的资料，其中科大讯飞的孙玉老师提到需求拆分最后应该是小而精，耦合度低且拆分到最基础的单位。
开发根据拆分的需求任务制定开发计划；
测试根据拆分的需求任务制定测试计划以及测试策略（走几轮测试？是否交叉测试？是否需要做专项测试？是否需要压测？）

设计阶段：

开发完成：程序设计、数据库设计等
测试开展工作：编写测试用例->用例评审->修改用例->用例终稿（在开发自测前完成）

开发阶段：

开发编码，根据禅道中指派的任务按时完成对应模块的编码任务；
开发联调，前/后端联调代码；
开发自测，根据测试给的用例进行自测，保证主流程正常；
当然有些做得好的公司还会搞 codereview、单元测试、代码扫描等保证编码质量；
最后，对应项目负责人在禅道建 “发布” 任务给测试，任务描述清晰描述所要发布内容（配置文件修改/数据库脚本），并指派相应测试人员；

测试阶段：

发布 test，根据开发禅道所建任务内容发布到 test 环境；
新功能测试，根据用例终稿，完成功能测试；
集成/回归/专项/兼容/性能测试（根据测试策略决定开展哪几项）：
集成测试基本上必走
回归测试的程度需要视项目的内容而定，多数情况下回归主流程和重点功能，但如果是程序底层优化改造或者是环境迁移那种，就需要全回归
专项测试，主要是 app 弱网测试、app 音/视频质量那些
兼容测试，移动端就是 IOS 版本、Android 版本和各种机型的兼容性，Web 端主要是浏览器兼容性，如果是那种后台系统且大家使用的浏览器比较统一，可以 不去关注兼容性
性能测试，尤其是一些针对促销的版本，必走性能，其他的根据项目特性再做评估

验收阶段：

测试环境测试完成达到验收标准/到了预定发 UAT 的日期 (某个项目验收周期比较长，test 环境的工作未完全收尾，节点日期先发布到 UAT 环境以保证进度)，进行 UAT 发版；
发布 UAT：会根据之前禅道创建的发 test 任务建一个发 UAT 的任务，进行发版；
测试会先在 UAT 环境上走一轮，以确保 UAT 发布的内容与 test 一致，如果有问题，UAT 环境重新发版；
若产品/用户验收时发现问题，直接提给测试；若测试判定为 bug，转给对应开发并在
测试环境验证通过后重新发版 UAT；若属于需求中未提及的内容，指给产品做需求变更；
若是用户操作错误、环境异常等引起的问题，测试直接关闭 bug。