大厂的测试流程是什么样的?一篇文章告诉你!

大厂测试流程是什么样的?这篇文章告诉你!


一、评审阶段

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变更需要长达几个小时,如果等到要发布的时候,才想到要变更,可能今天就发布不了了。

验收:一般而言,是先发布到预发布环境,待产品、开发验收无问题,才会进行生产发布。如果有问题,重新修改代码再推预发布再验收。生产发布完成后,产品也需要再进行一遍验收。

发布顺序:检查发布域的版本号是否为正式版,且要按照顺序发布。发布系统可以做到模块关联,设置某一个域发布完成之后,另一个域才能发布。

发布时间间隔:根据域的重要性不同,生产服务器机器数量也不同,所以发布的时候会设置批次。而每个批次的发布之间,最好进行一定时间的间隔。

日志监控:在生产发布的过程中,需要通过日志系统查看有无异常日志,如果出现预期外的异常日志,需要和开发沟通后判断是否需要回滚。

告警监控:通过发布系统查看是否有本域告警和上下游告警,如果有,也需要找开发确认是否有影响,再决定是否回滚。

回滚:如果出现核心流程的告警,或者不能确定的告警和异常情况下,一般会先直接进行回滚操作。需要注意的是,需要注意回滚的顺序。如果由于回滚前,造成相关异常数据,在回滚后,还需要进行异常数据的处理。


你可能感兴趣的:(大厂的测试流程是什么样的?一篇文章告诉你!)