影响凡人生活的巨大体系必有弊端
----索福克勒斯
引言
在以往的测试中，产品形态、业务形态都比较单一，无论是对于功能测试、自动化测试来讲，相对实现比较容易。显而易见，单机系统、小型微服务又或者业务未解耦的系统通常测试压力比较小，回归点比较容易梳理。
一句话来总结：业务形态比较简单
但是当业务形态比较复杂的时候，单单靠人力来完成，那就会有加不完的班，做不完的回归测试。
技术服务于业务，技术在做解耦的同时，业务也在做解耦，终极目的都是让产品多元化。
背景
近期我所在的业务线业务突然暴涨，需求源源不断，这对我们来讲是个究极考验，尤其是在回归测试方面。
以最近做的业务为例：
对接外部合作项目，产品形态非常多，有各种各样的设备、各种各样的小程序，H5
形态是一方面，重要的是对接外部合作项目比较特殊，各个渠道都会或多或少的有定制化操作，不局限页面或接口。
当然，在UI方面，个人认为回归比较难。且自身团队UI自动化实践的比较浅。
反观，如UI不可取，那么只能去回归接口。
难点便在于接口，外部合作对接上层接口一般分为2-3类，底层服务接口又有2类。且实现正式/预发回归数据清理比较复杂，会产生一定的冗余数据。
那么回归只能靠点点点了？
这个时候可能只能靠接口回归去硬着头皮上，但是日常工作便有很多需求，不能同时保证多线程工作（确实有那么多工作。。。）
回到的最原始的话题：效率 or 质量？
效率为王&质量为王？
站在高层角度上看：效率和质量，都要
实践
那么，面对问题，我们先做如下实践，是否有效果先打问号
具体如下：
·流程
·技术
·测开互动
a、流程
在流程上，应当树立起技术方案实现碰头会，开发须出技术实现方案文档，同步测试人员且与之进行评审；
技术方案具体内容是在与增加、改动的接口，以及开发自行评估的改动影响范围；
提测文件中须注明涉及影响面、梳理出详细接口字段；以及自己评估出可能影响的业务；
测试审查单测、冒烟通过率，切记不能为了通过而通过；
回归测试基线用例以及接口自动化一定保证通过。
b、技术
测试须梳理出整体业务的基线用例；
开发出具需求实现方案、涉及改动点以及影响范围；
开发完成冒烟、单测，出具相关报告；
测试根据基线用例实现接口自动化用例；
接口自动化用例覆盖单接口、场景；可集成Sonar;
codeReview循序渐进。
c、测开互动
评审需求的时候需要基于业务理解度提出影响面且罗列出来；
技术方案评审之时需要用基线用例去评估可能影响的面，与开发进行碰撞影响面的大小；
阶段性共同覆盘，不局限于项目、bug等。
尾声
由于近期线上问题出现频率较为频繁，执行如上举措，尝试能否改良。
