不久前和某公司的測試同學做交流時，被問及了這樣一個問題 -- 我們這邊系統很龐大，每次感覺改的東西不是很多，但是怕出問題都得整體功能都過一遍，因為是金融系統，一次測試要做兩周，有什么辦法能降低我們的人力投入么。
挺有意思的一個提問，這里面能看到很多幽幽的怨念。
- 研發他們都是增量開發，之后為什么要全量測試
- 研發信誓旦旦的說只是改了一部分功能的代碼，但還是擔心牽一發動全身的事情發生。說句“測試同學，你們簡單測試一下”，但是還是多數測試同學不敢簡單測試一下，然后硬著頭皮把核心起碼過一遍。
首先說一下，測試周期和測試投入是不是一回事兒。可以測試周期不變，但是投入變了，也可以測試投入變了，但是周期不變。當然我們通常希望的是投入和周期都能有所下降。
在這里，我個人認為可以有三個改善方向可以思考。當然了，我的強調一下，不代表就沒有別的思路，也不代表我的思路就是最好的，我們是來做交流的，我負責拋磚，你們引玉。
第一個方向自然是做自動化測試。在代替人上，自動化是你應該首個就應該考慮的解決方案。雖然這位同學的潛意識是想問我如何減少測試用例，但是我不得不說，如果你的自動化替代率很高的前提下，你可以暫時不care是不是把5000條用例能減少到1000條，因為機器畢竟是人類速度的N個數量級倍，如果能足夠快的速度執行完大量的自動化測試回歸，那做精簡這件事兒可能是不那么劃算的。能交給機器做的事兒，作為人你不要去搶。
這位同學的背景是一個比較龐大且穩定的老系統，每次回歸手工可能要兩個人執行一周時間。在這類型的項目里，很顯然自動化的施展余地會大很多，且收益也會大很多。一些新項目的自動化投入大產出大，通常原因是因為項目變更過快，老的接口設計動輒就廢棄，或者動輒就做升級，自動化測試投入很難收回成本。而這種已經比較穩定的大型項目，接口設計還需要盡量遵循以前的規范（也可能沒有什么規范，但是已經被系統之間的引用約束了），所以如果這種做一點升級優化就需要大面積回歸的場景，配合高比例的自動化回歸和輔之以一定規模的人工測試回歸還是效果不錯的。
那是不是新的、迭代比較快的項目就不可以快速引入自動化提升回歸效率和降低投入了。答案當然是可以的，這就看你的自動化用例本身如何維護的了。如果你能利用文檔做到參數的結構化，那么你可以利用文檔自動轉化和update測試用例，這對你的維護成本和撰寫成本降低都會有很大的幫助。一旦這件事兒評估的結論是 -- 在開發測試階段，投入的維護成本會小于執行使用成本，那你大膽的開展這部分工作吧。
第二個改善的思路，我個人的建議是做灰度測試。尤其是這種已經有較大體量的項目，我個人認為灰度測試是一個不錯的選擇。
灰度發布（又名金絲雀發布）是指在黑與白之間，能夠平滑過渡的一種發布方式。在其上可以進行A/B testing，即讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
還是說下這位同學所說的項目背景，大型項目，做優化之后兩個人測試一周多。既然我們的研發和測試同學都知道只是改了不多的內容，那是不是可以考慮做基本功能的確認之后，就發起灰度測試，利用小流量控制，將生產流量倒流給一部分用戶，根據這部分用戶的使用狀況來評估。這樣如果運行一周如果不出問題，那顯然功能是好的，如果確實發現一些問題，那本身因為流量控制不會影響很多用戶，通過問題反饋激勵的方式也可以增加用戶的參與感（其實更多的時候是讓用戶發現問題之后意識到是挖到了寶，而不是擦到了雷）。
在這一周的時間里，周期雖然沒有下降，但是測試人員的人力投入會大幅度下降，測試人力的投入可能從一個ST（系統測試）級別的測試下降到一個SNT（準入）級別的測試，之后投入零碎時間關注問題反饋。這種方法使用于還有一個相對較長的驗證周期，而且有足夠量級的用戶支撐你的灰度測試發布。
這里又有人問呢，如果版本用戶數很少呢？敢不敢發灰度，我只能說，你想發當然也可以，但是效果不好。另外，如果用戶還沒有那么多的時候，老板非要小步快跑上線，那你就犧牲一些質量好啦。不要死腦筋，上線出錯對用戶如果沒有那么大，你是可以適當放棄質量上線觀察的。關于測試經濟學的概念，列為自行百度吧，我摘一段供大家了解。
隨著信息技術的飛速發展，軟件產業在國名經濟中扮演著越來越重要的角色，各行各業對軟件質量要求也越來越高，那么軟件企業是不是為了保證產品的質量，測試人員就需要無限期的對軟件產品測試下去呢？答案是否定的，從經濟學的角度考慮就是確定需要完成多少測試，以及進行什么類型的測試。經濟學所做的判斷，確定了軟件存在的缺陷是否可以接受，是否符合企業產品定義的質量標準。“太少的測試是犯罪，而太多的測試是浪費。”對風險測試的過少，會造成軟件的缺陷和系統的癱瘓；而對風險測試的過多，就會使本來沒有缺陷的系統進行沒有必要的測試，或者是對輕微缺陷的系統所花費的測試費用遠遠大于他們給系統造成的損失。
測試費用的有效性，可以用測試費用的質量曲線來，表示隨著測試費用的增多，發現的去缺陷也會越多，兩線先交的的地方是過多測試開始的地方，這時，發現缺陷的測試用超過了缺陷給系統造成的損失費用。
由于市場和軟件研發成本的影響，軟件測試不可能無限期的測試下去，軟件測試最佳的發布日期通常是測試多倫后，在較長的時期發現不了缺陷或者發現和少的缺陷，但是該階段消耗的研發成本日益增長的時候終止。
還有一個改善方向是做精準測試。精準測試現在業界有兩個意思，一種指的是14年業界提出的“穿線測試”，大概思路是如果通過降低白盒測試投入的同時又提升代碼測試覆蓋率,一些簡單介紹如下。
黑盒和白盒各有優劣，采用二者相結合的方法，穿線測試實際上屬于創新型的系統級白盒測試工具，是軟件測試領域里面全新的學術流派。它先通過傳統黑盒測試把基本的功能都測試一輪，覆蓋率達到70%，同時這個過程受到穿線測試工具的監控，并獲取該階段的測試結果數據；第二步，通過穿線測試得到的白盒結果，快速定位剩下30%的代碼，進行針對性地增加測試用例，最終達到終極目標。經過很多客戶的實踐經驗，這種方法對于覆蓋率測試是最有效的，且測試時間最短。
對穿線測試基本概念想了解的，可以讀一下：http://www.51testing.com/html/29/n-3641529.html
這里我們要提的是另外一層概念，是基于增量測試思路演變來的精準測試。主要目的是針對變更內容做評估，可以有針對性的對變更內容和關聯內容展開測試，而不在沒有影響的功能上做無畏的投入。
即便還比較粗獷的團隊，可以將你們的代碼-業務模塊-用例設計一個映射關系，然后每次在修改內容之后 針對代碼變更范圍確定回歸范圍，這樣不會每次都回歸很多內容。
利用工具，能正反推模塊和用例關系。正推模塊變更需要關聯的用例，反推可以通過用例評估對模塊的覆蓋。最開始可以基于人工基于經驗做這個映射關系，更長遠的還是需要上一些工具的。通過工具能評估組件和組件、模塊和模塊之前的引用關系，以及在用例執行時基于代碼覆蓋工具積累和模塊的關聯關系，在發起新的變更做測試時，能基于已經建立的映射關系給出參考回歸的范圍，并給出關聯的測試用例，這里要強調下，要盡可能的利用工具在執行的時候反觀對功能和代碼的覆蓋，比如你的用例雖然關聯的新變更的模塊，但是發現在用例執行的時候該模塊有大量新代碼沒有被測試執行時覆蓋，那要再有針對性的跟進該部分內容了。
以上，是我個人的建議的一些思路，具體如何實施就不長篇大論去寫了，大家自行百度吧。
