互聯網產品
一個字：快！
通常情況下，互聯網產品要求全回歸測試的執行時間不能超過 4 小時
如何在保證測試質量和測試覆蓋率前提下，有效縮短測試執行時間呢？這就是今天的主題啦！
傳統軟件產品的測試策略設計
單元測試
一般是白盒測試，由開發工程自己完成
API測試
主要針對的是各模塊暴露的接口，通常采用 灰盒測試 方法。
灰盒測試：是介於白盒測試和黑盒測試之間的一種測試技術，其核心思想是利用測試執行的代碼覆蓋率來指導測試用例的設計。
以 API 接口測試為例，首先以黑盒方式設計如何調用 API 的測試用例，同時在測試執行過程中統計代碼覆蓋率，然后根據代碼覆蓋率情況來補充更多、更有針對性的測試用例。
GUI測試
最接近軟件真實用戶使用行為的測試類型。通常是模擬真實用戶使用軟件的行為，並驗證這些操作對應的結果是否正確
優點：實際模擬真實用戶的行為
缺點：執行代價比加大
互聯網產品的測試策略
重量級API測試，輕量級GUI測試，輕量級單元測試
- 以中間層的 API 測試為重點做全面的測試
- 輕量級的 GUI 測試，只覆蓋最核心直接影響主營業務流程的 E2E 場景
- 最上層的 GUI 測試通常利用探索式測試思維，以人工測試的方式發現盡可能多的潛在問題
- 單元測試采用“分而治之”的思想，只對那些相對穩定並且核心的服務和模塊開展全面的單元測試，而應用層或者上層業務只會做少量的單元測試
GUI測試
開發GUI自動化測試用例的時間非常有限
需求和客戶端界面頻繁的變化，導致GUI自動化測試效率會非常低
所以，互聯網產品的GUI測試通常采用“手工為主，自動化為輔”的測試策略，手工測試往往利用探索性測試思維，針對新開發或者新修改的界面功能進行測試。
API測試
對於互聯網產品來說，測試重點放在API測試才是最明智的選擇，為啥呢？以下原因
- API 測試用例的開發與調試效率比 GUI 測試要高得多，而且測試用例的代碼實現比較規范，通常就是准備測試數據，發起 request，驗證 response 這幾個標准步驟。【開發調試效率高】
- API 測試用例的執行穩定性遠遠高於 GUI 測試。 GUI 測試執行的穩定性始終是難題；API 測試天生就沒有執行穩定性的問題，因為測試執行過程不依賴於任何界面上的操作，而是直接調用后端 API，且調用過程比較標准【穩定性高，獨立性強，規范性好】
- 單個 API 測試用例的執行時間往往要比 GUI 測試短很多。當有大量 API 測試需要執行時，API 測試可以很方便地以並發的方式執行【執行時間短】
- 現在很多互聯網產品采用了微服務架構，而對微服務的測試，本質上就是對不同的 Web Service 的測試，也就是 API 測試。【微服務測試即API測試】
- API 接口的改動一般比較少，即使有改動，絕大多數情況下也需要保證后向兼容性（Backward Compatibility），即保證原本的 API 調用方式維持不變。【改動效，后向兼容】
單元測試
互聯網產品的全面單元測試只會應用在那些相對穩定和最核心的模塊和服務上，而應用層或者上層業務服務很少會大規模開展單元測試。