复杂业务形态回归测试思考

Posted 2021-07-03 紫陌花间客

影响凡人生活的巨大体系必有弊端

                                                                                                       ----索福克勒斯

引言

在以往的测试中，产品形态、业务形态都比较单一，无论是对于功能测试、自动化测试来讲，相对实现比较容易。显而易见，单机系统、小型微服务又或者业务未解耦的系统通常测试压力比较小，回归点比较容易梳理。

一句话来总结：业务形态比较简单

但是当业务形态比较复杂的时候，单单靠人力来完成，那就会有加不完的班，做不完的回归测试。

技术服务于业务，技术在做解耦的同时，业务也在做解耦，终极目的都是让产品多元化。

背景

近期我所在的业务线业务突然暴涨，需求源源不断，这对我们来讲是个究极考验，尤其是在回归测试方面。

以最近做的业务为例：

对接外部合作项目，产品形态非常多，有各种各样的设备、各种各样的小程序，H5

形态是一方面，重要的是对接外部合作项目比较特殊，各个渠道都会或多或少的有定制化操作，不局限页面或接口。

当然，在UI方面，个人认为回归比较难。且自身团队UI自动化实践的比较浅。

反观，如UI不可取，那么只能去回归接口。

难点便在于接口，外部合作对接上层接口一般分为2-3类，底层服务接口又有2类。且实现正式/预发回归数据清理比较复杂，会产生一定的冗余数据。

那么回归只能靠点点点了？

这个时候可能只能靠接口回归去硬着头皮上，但是日常工作便有很多需求，不能同时保证多线程工作（确实有那么多工作。。。）

回到的最原始的话题：效率 or 质量？

效率为王&质量为王？

 站在高层角度上看：效率和质量，都要

实践 

那么，面对问题，我们先做如下实践，是否有效果先打问号

具体如下：

·流程

·技术

·测开互动

a、流程

 在流程上，应当树立起技术方案实现碰头会，开发须出技术实现方案文档，同步测试人员且与之进行评审；

 技术方案具体内容是在与增加、改动的接口，以及开发自行评估的改动影响范围；

 提测文件中须注明涉及影响面、梳理出详细接口字段；以及自己评估出可能影响的业务；

 测试审查单测、冒烟通过率，切记不能为了通过而通过；

 回归测试基线用例以及接口自动化一定保证通过。

 

b、技术

 测试须梳理出整体业务的基线用例；

 开发出具需求实现方案、涉及改动点以及影响范围；

 开发完成冒烟、单测，出具相关报告；

 测试根据基线用例实现接口自动化用例；

 接口自动化用例覆盖单接口、场景；可集成Sonar;

 codeReview循序渐进。

 

c、测开互动

 评审需求的时候需要基于业务理解度提出影响面且罗列出来；

 技术方案评审之时需要用基线用例去评估可能影响的面，与开发进行碰撞影响面的大小；

 阶段性共同复盘，不局限于项目、bug等。

 

尾声

由于近期线上问题出现频率较为频繁，执行如上举措，尝试能否改良。