影響凡人生活的巨大體系必有弊端
----索福克勒斯
引言
在以往的測試中，產品形態、業務形態都比較單一，無論是對於功能測試、自動化測試來講，相對實現比較容易。顯而易見，單機系統、小型微服務又或者業務未解耦的系統通常測試壓力比較小，迴歸點比較容易梳理。
一句話來總結：業務形態比較簡單
但是當業務形態比較複雜的時候，單單靠人力來完成，那就會有加不完的班，做不完的迴歸測試。
技術服務於業務，技術在做解耦的同時，業務也在做解耦，終極目的都是讓產品多元化。
背景
近期我所在的業務線業務突然暴漲，需求源源不斷，這對我們來講是個究極考驗，尤其是在迴歸測試方面。
以最近做的業務爲例：
對接外部合作項目，產品形態非常多，有各種各樣的設備、各種各樣的小程序，H5
形態是一方面，重要的是對接外部合作項目比較特殊，各個渠道都會或多或少的有定製化操作，不侷限頁面或接口。
當然，在UI方面，個人認爲迴歸比較難。且自身團隊UI自動化實踐的比較淺。
反觀，如UI不可取，那麼只能去迴歸接口。
難點便在於接口，外部合作對接上層接口一般分爲2-3類，底層服務接口又有2類。且實現正式/預發回歸數據清理比較複雜，會產生一定的冗餘數據。
那麼迴歸只能靠點點點了？
這個時候可能只能靠接口迴歸去硬着頭皮上，但是日常工作便有很多需求，不能同時保證多線程工作（確實有那麼多工作。。。）
回到的最原始的話題：效率 or 質量？
效率爲王&質量爲王？
站在高層角度上看：效率和質量，都要
實踐
那麼，面對問題，我們先做如下實踐，是否有效果先打問號
具體如下：
·流程
·技術
·測開互動
a、流程
在流程上，應當樹立起技術方案實現碰頭會，開發須出技術實現方案文檔，同步測試人員且與之進行評審；
技術方案具體內容是在與增加、改動的接口，以及開發自行評估的改動影響範圍；
提測文件中須註明涉及影響面、梳理出詳細接口字段；以及自己評估出可能影響的業務；
測試審查單測、冒煙通過率，切記不能爲了通過而通過；
迴歸測試基線用例以及接口自動化一定保證通過。
b、技術
測試須梳理出整體業務的基線用例；
開發出具需求實現方案、涉及改動點以及影響範圍；
開發完成冒煙、單測，出具相關報告；
測試根據基線用例實現接口自動化用例；
接口自動化用例覆蓋單接口、場景；可集成Sonar;
codeReview循序漸進。
c、測開互動
評審需求的時候需要基於業務理解度提出影響面且羅列出來；
技術方案評審之時需要用基線用例去評估可能影響的面，與開發進行碰撞影響面的大小；
階段性共同覆盤，不侷限於項目、bug等。
尾聲
由於近期線上問題出現頻率較爲頻繁，執行如上舉措，嘗試能否改良。
