一名测试工程师的学习之路，所有博客链接已存放在该链接下：一个Tester

一、评审阶段

1.1 需求评审

    一般在需求评审阶段中，参与者至少会有产品经理、开发、测试。如果项目需求比较大、还会有PMO、业务方、UI设计师等参与到需求评审中。作为测试而言，在需求评审中，最需要做两件事。

• 理解需求：对于测试而言，我们需要在需求评审会议上理解需求，不要出现会上无问题，会后三连问的情况，这样也比较耽误产品的时间。
• 提出疑问：因为产品的需求也不一定合理，我们要带着问题参与到评审中。而且如果是新进入一个公司，对于公司的业务不太熟悉的时候，需求评审也是一个熟悉业务的好机会。

    需求评审阶段，我们需要关注以下相关问题。

• 交付目标：该需求面向的人群是谁？是外部用户、供应商？还是公司内部商务、运营、客服使用。
• 交付计划：需求的上线计划，验收计划，是否灰度，以及测试工作量的评估。
• 业务流程：本次是新增的功能或流程？还是原有业务流程增加新的节点或是修改节点逻辑。
  

1.2 设计评审

    设计评审：就是开发在听完产品的需求后，先编写好开发设计文档。然后根据项目的大小决定是否需要进行设计评审，如果只是小的优化或功能，一般就不会进行设计评审，而对于比较大的项目，就会拉上产品、测试进行设计的评审。在设计评审中，常常会发现开发对需求的理解与产品是不一致的。而作为测试而言，参与设计评审一是为了加深需求的理解，二是理解开发的设计，也要注意开发的设计是否合理。

    在设计评审中，测试一般需要关注以下相关的问题(不一定全面，可能会存在相关差异)。

• 流程设计图：开发设计的流程图是否能达到产品需求的流程？
• 数据库表设计：是否新增表？是否需要分库分表？如何保证唯一性？表字段默认值？是否需要添加索引？
• 接口：接口层面分为本系统和上下游系统。本系统：新增接口的调用方是谁？原有接口修改后是否影响上下游业务？上下游系统：调用其他系统接口或者被其他系统调用的接口，是否有对接？需要评估是否对接口负载有影响？一般核心域的核心接口，在有新增入参的情况下，也会根据线上情况进行不同入参下的性能测试，评估接口QPS是否能达到预期，防止上线后出现性能问题。
• 组件变更：是否有配置变更，配置的默认值是否合理？是否有环境变量变更？相关组件是否有变更？
• 灰度：是否有开关？灰度方案是什么？是根据用户灰度还是？
• 回滚：如果出现问题，回滚方案是什么？回滚时相关域的回滚顺序是怎么样的？
  

1.3 用例评审

1.3.1 功能用例评审

    功能用例评审：测试人员在编写好用例后，可以通过邮件的形式将发送给对应开发和产品，查看用例场景是否有遗漏。一般开发和产品不怎么看这个邮件的话，就可以抽了十多分钟，拉上会议，进行一个当面的用例评审。
    如果是新入职的新人，一般是编写好用例后，先发送邮件给产品、开发，抄送给本组的测试同事，然后再拉上产品、开发进行一个当面的沟通。

1.3.2 联调用例评审

    联调用例评审：如果需求涉及到多个系统的话，一般是需要进行一个联调用例评审。评审前一般是会先确定好本次需求的主测试，然后主测会编写好联调文档。

    联调用例评审会上会有以下几件事需要做：

• 宣讲用例：主测宣讲联调的用例，各系统的测试查看是否有场景遗漏，并进行补充。
• 确定分工：相关基础数据的准备交给对应系统。确定是否有本次需求系统无需变更，但是要协助联调的系统，确定跟进人。
• 问题记录：对于联调评审中无法确定的问题，进行记录，后续跟进解决。
  

二、测试阶段

2.1 冒烟测试

    冒烟测试：在开发提测后，就进入测试阶段。首先进行冒烟测试，冒烟测试一般需要注意相关问题：

• 静态代码扫描：进行静态代码扫描，是否有blocker、critical的代码。
• 代码编译 & 服务部署：测试分支进行开发代码编译和部署，查看是否能编译和部署成功。且部署成功后，一般会查看环境中服务的日志，查看有无明显的报错日志。
• 冒烟测试用例：首先执行冒烟的自动化Case,然后根据自己设计的冒烟阶段的用例，执行用例并测试。

    关于静态代码扫描、代码编译等，需要看所在公司对于相关测试平台的建设。例如我现在所在的公司，就是可以创建一个流水线，其中可以配置下面这些功能：代码编译、单元测试、单元测试覆盖率、静态代码检查、项目打包，镜像烘焙、部署、系统测试(自动化代码执行)。所以一般开发提测后，就是执行一下对应的流水线，查看代码是否能编译通过，静态代码扫描是否有问题，原先的自动化Case中的冒烟Case是否能通过等

    在冒烟测试过程中，我们需要有以下记录：

• 用例上传及执行：上传冒烟测试用例，并在执行用例后，记录为用例已执行。
• BUG记录：如果冒烟Case不通过，提冒烟Bug给开发。
• 工时记录：记录冒烟测试阶段的使用工时。
• 补充冒烟自动化Case：如果是接口域，根据情况看是否需要补充冒烟的自动化AT，有则补充自动化AT，分组设置为冒烟。

2.2 功能测试

    功能测试：在冒烟测试通过后，进行到功能测试。功能测试与冒烟测试的不同在于，冒烟测试只是先将主流程走了一遍，而功能测试需要考虑常规情况和异常情况下的所有情况。在功能测试阶段需要注意以下问题：

• 前置准备：准备好基础的测试数据，相关变更需要在测试环境中执行等。
• 用例执行：根据用例设计执行功能测试部分的用例。一般而言，在功能测试阶段，需要调用外部系统服务的话，采用Mock的方式，Mock外部系统的返回，除去Mock外部系统的正常返回，还要Mock超时，抛出异常等异常情况。
• 预期结果：测试用例执行的结果是否符合预期结果。

    在功能测试过程中，我们需要有以下记录：

• 用例上传及执行：上传功能测试用例，并在执行用例后，记录为用例已执行。
• BUG记录：如果功能Case不通过，提功能测试阶段Bug给开发。
• 工时记录：记录功能测试阶段的使用工时。
• 补充自动化Case：补充本次需求的自动化Case。
• 功能测试报告：发送功能测试报告，内容包括是否通过？遗留问题及风险点。
  

2.3 联调测试

    联调测试：一般只有当需求涉及到多个系统的变更的时候，才需要进行联调测试。而联调测试一般就是各系统将各自的服务部署再Staging联调环境中后，模拟生产一样，按照联调用例走一趟实际的流程。

    在联调测试中，需要关注以下的点：

• 真实数据：联调的数据要是真实的数据，一定不能Mock数据！！！。而且不要直接修改数据库、Redis中的数据
• 核心流程回归：对于原有的核心的流程，也要做到一定程度的回归，防止对原有流程有影响。
• 联调日报：主测需要通过邮件的形式汇报整体联调的进度，以及联调进度的风险、联调发现的问题等。
  

2.4 回归测试

    回归测试：在测试分支进行完功能测试后，在发布上线前，开发合并代码到dev、master分支后，分别进行一次回归测试。回归测试一般需要注意相关问题：

• 回归时间：一般而言，当有一个域需要在明天发布，会在确定今天这个域没有发布、或这个域今天需要发布上线的需要已经上线后，才让开发合并代码到dev分支或者master分支，待合并代码后再进行回归。
• 静态代码扫描：代码依次合并到dev、master分支后，进行静态代码扫描，确保没有blocker、critical。
• SDK升级：本域服务和依赖的外部服务需要升级为正式版，不使用SNAPSHOT版。
• 全量AT回归：针对接口域，会进行全量接口自动化AT的回归，确保自动化Case没有失败的情况下才会进行下一步。

    在回归测试过程中，我们需要有以下记录：

• 用例上传及执行：上传回归测试用例，并在执行用例后，记录为用例已执行。
• BUG记录：如果回归时Case不通过，提回归测试阶段Bug给开发。
• 工时记录：记录回归测试阶段的使用工时。

三、发布上线（预发布->生产）

    `预发布环境连接的是真实生产的数据库，所以回归测试完成后，一般会先发布到预发布环境。待开发、产品验收无问题后，才会发布到生产环境。在这个过程中，需要注意以下几方面。

• 依赖变更：确定相关组件、配置、环境变量是否做了变更。在很多情况下，有些DB变更需要提前做，因为可能有的DB变更需要长达几个小时，如果等到要发布的时候，才想到要变更，可能今天就发布不了了。
• 验收：一般而言，是先发布到预发布环境，待产品、开发验收无问题，才会进行生产发布。如果有问题，重新修改代码再推预发布再验收。生产发布完成后，产品也需要再进行一遍验收。
• 发布顺序：检查发布域的版本号是否为正式版，且要按照顺序发布。发布系统可以做到模块关联，设置某一个域发布完成之后，另一个域才能发布。
• 发布时间间隔：根据域的重要性不同，生产服务器机器数量也不同，所以发布的时候会设置批次。而每个批次的发布之间，最好进行一定时间的间隔。
• 日志监控：在生产发布的过程中，需要通过日志系统查看有无异常日志，如果出现预期外的异常日志，需要和开发沟通后判断是否需要回滚。
• 告警监控：通过发布系统查看是否有本域告警和上下游告警，如果有，也需要找开发确认是否有影响，再决定是否回滚。
• 回滚：如果出现核心流程的告警，或者不能确定的告警和异常情况下，一般会先直接进行回滚操作。需要注意的是，需要注意回滚的顺序。如果由于回滚前，造成相关异常数据，在回滚后，还需要进行异常数据的处理。

写在最后：以上就是一个大概的测试流程的总结，其中肯定也会有一些遗漏，各公司之间的测试流程也会有差异。所以觉得总结的还可以的，请一键三连！觉得还有要补充的，可以在下方留言！