在開始今天的話題之前，請你先思考一下為什麽我會把互聯網產品的測試策略單獨拿出來討論，互聯網產品的測試策略和傳統軟件產品的測試策略到底有哪些不同？

研發流程的不同決定了測試策略的不同
如果直接回答互聯網產品和傳統軟件產品的測試策略有何不同，你會有些摸不著頭腦，那麽按照我一直在強調的知其然知其所以然的原則，你可以先去總結這兩類產品的研發本身最大的不同是什麽？

那就是，互聯網產品的“快”。

前面的文章中，已經提到了互聯網產品的上線周期通常是以“天”甚至是以“小時”為單位，而傳統軟件產品的周期多以“月”，甚至以“年”為單位。

發布周期的巨大差異決定了，傳統軟件產品的測試策略必然不適用於互聯網產品的測試，二者的測試策略必然在測試執行時間和測試執行環境上有巨大差異。

比如，對於功能自動化測試用例，執行一輪全回歸測試需要 12 小時，對傳統軟件來說這根本不是問題，因為發布周期很長，留給測試的時間也會很充裕。

不要說全回歸測試執行時間需要 12 小時，哪怕是需要幾天幾夜也沒有任何問題，就像我以前在思科（Cisco）做傳統軟件測試時，一輪完整的全回歸測試的 GUI 測試用例數接近 3000 個，API 測試用例數更是接近 25000 個，跑完全部用例需要將近 60 小時。

但對互聯網產品來說，通常 24 小時就會有一到兩次的發布，發布流程通常包含了代碼靜態掃描、單元測試、編譯、打包、上傳、下載、部署和測試的全流程。顯然留給測試執行的時間就非常有限，傳統軟件動輒十幾個小時的測試執行時間，在互聯網產品的測試上，根本行不通。

通常情況下，互聯網產品要求全回歸測試的執行時間不能超過 4 小時。

那麽，如何在保證測試質量和測試覆蓋率的前提下，有效縮短測試執行時間呢？

首先，你可以引入測試的並發執行機制，用包含大量測試執行節點的測試執行集群來並發執行測試用例。
測試執行集群，你可以簡單理解為是一批專門用來並發執行測試用例的機器。常見的測試執行集群，由一個主節點（Master）和若幹個子節點（Node）組成。其中，主節點用來分發測試用例到各個子節點，而各個子節點用來具體執行測試用例。
目前，很多互聯網企業都建立了自己的測試執行集群。

其次，你必須從測試策略上找到突破口，這也是我今天跟你分享的主題。
接下來，我會先簡單為你介紹一下傳統軟件產品的測試策略設計，然後再給你分享互聯網產品的測試策略，這樣可以通過對傳統軟件產品測試策略的回顧，加深你對互聯網產品測試策略的認識。

傳統軟件產品的測試策略設計
傳統軟件產品的測試策略，通常采用如圖 1 所示的金字塔模型。該金字塔模型是邁克 · 科恩（Mike Cohn）提出的，在很長一段時間內都被認為是測試策略設計的最佳實踐。

圖 1 傳統軟件產品的金字塔測試策略
第一，單元測試

金字塔最底部是單元測試，屬於白盒測試的範疇，通常由開發工程師自己完成，由於越早發現缺陷其修復成本越低，所以傳統軟件產品的測試策略提倡對單元測試的高投入，單元測試這一層通常都會做得比較“厚”。

另外，傳統軟件產品，生命周期都比較長，通常會有多個版本持續發布，為了在後期的版本升級過程中能夠盡早發現並快速定位問題，每次 build 過程中都會多次反復執行單元測試，這也從另一個角度反映出單元測試的重要性。

第二，API 測試

金字塔中間部分是 API 測試，主要針對的是各模塊暴露的接口，通常采用灰盒測試方法。灰盒測試方法是介於白盒測試和黑盒測試之間的一種測試技術，其核心思想是利用測試執行的代碼覆蓋率來指導測試用例的設計。

以 API 接口測試為例，首先以黑盒方式設計如何調用 API 的測試用例，同時在測試執行過程中統計代碼覆蓋率，然後根據代碼覆蓋率情況來補充更多、更有針對性的測試用例。

總體來看，API 測試用例的數量會少於單元測試，但多於上層的 GUI 測試。

第三，GUI 測試

金字塔最上層的是 GUI 測試，也稱為端到端（E2E，End-to-end）測試，是最接近軟件真實用戶使用行為的測試類型。通常是模擬真實用戶使用軟件的行為，即模擬用戶在軟件界面上的各種操作，並驗證這些操作對應的結果是否正確。

GUI 測試的優點是，能夠實際模擬真實用戶的行為，直接驗證軟件的商業價值；缺點是執行的代價比較大，就算是采用 GUI 自動化測試技術，用例的維護和執行代價依然很大。所以，要盡可能地避免對 GUI 測試的過度依賴。

另外，GUI 測試的穩定性問題，是長期以來阻礙 GUI 測試發展的重要原因。即使你采用了很多諸如 retry 機制以及異常場景恢復機制等方式，GUI 測試的隨機失敗率依舊高居不下。

互聯網產品的測試策略設計
對於互聯網產品來說，邁克的金字塔模型已經不再適用，我會通過 GUI 測試、API 測試、單元測試這三個方面，來跟你聊聊互聯網產品的測試策略有哪些變化，應該如何設計。

第一，GUI 測試

互聯網產品的上線周期，決定了 GUI 測試不可能大範圍開展。

互聯網產品的叠代周期，決定了留給開發 GUI 自動化測試用例的時間非常有限；

互聯網產品客戶端界面的頻繁變化，決定了開展 GUI 自動化測試的效率會非常低，這也是最糟糕的。
因為敏捷模式下的快速反饋，在下一個叠代（sprint）可能就需要根據反饋來做修改和調整客戶端界面，那麽剛開發完，甚至是還沒開發完的 GUI 自動化測試用例就要跟著一起修改。
這種頻繁地修改，對開發 GUI 自動化測試是非常不利的。因為，剛開發完的自動化用例只跑了一次，甚至是一次還沒來得及跑就需要更新了，導致 GUI 自動化測試還不如手工測試的效率高。

由此，互聯網產品的 GUI 測試通常采用“手工為主，自動化為輔”的測試策略，手工測試往往利用探索性測試思想，針對新開發或者新修改的界面功能進行測試，而自動化測試的關註點主要放在相對穩定且核心業務的基本功能驗證上。所以，GUI 的自動化測試往往只覆蓋最核心且直接影響主營業務流程的 E2E 場景。

另外，從 GUI 測試用例的數量來看，傳統軟件的 GUI 測試屬於重量級的，動不動就有上千個用例，因為傳統軟件的測試周期很長，測試用例可以輪流排隊慢慢執行，時間長點也沒關系。

而互聯網產品要求 GUI 測試是輕量級的，你見過或者聽過有哪個互聯網產品設計了上千個 GUI 測試用例嗎？互聯網產品的上線周期，直接決定了不允許你去執行大量的用例。

第二，API 測試

你現在可能要問，既然互聯網產品不適宜做重量級的 GUI 測試，那麽怎樣才能保證其質量呢？

其實，對於互聯網產品來說，把測試重點放在 API 測試上，才是最明智的選擇。為什麽呢？我給你總結了以下五條原因。

API 測試用例的開發與調試效率比 GUI 測試要高得多，而且測試用例的代碼實現比較規範，通常就是準備測試數據，發起 request，驗證 response 這幾個標準步驟。

API 測試用例的執行穩定性遠遠高於 GUI 測試。 GUI 測試執行的穩定性始終是難題，即使你采用了很多技術手段（這些具體的技術手段，我會在講解 GUI 測試時再詳細展開），它也無法做到 100% 的穩定。
而 API 測試天生就沒有執行穩定性的問題，因為測試執行過程不依賴於任何界面上的操作，而是直接調用後端 API，且調用過程比較標準。

單個 API 測試用例的執行時間往往要比 GUI 測試短很多。當有大量 API 測試需要執行時，API 測試可以很方便地以並發的方式執行，所以可以在短時間內完成大批量 API 測試用例的執行。

現在很多互聯網產品采用了微服務架構，而對微服務的測試，本質上就是對不同的 Web Service 的測試，也就是 API 測試。
在微服務架構下，客戶端應用的實現都是基於對後端微服務的調用，如果做好了每個後端服務的測試，你就會對應用的整體質量有充分的信心。所以，互聯網產品的 API 測試非常重要。

API 接口的改動一般比較少，即使有改動，絕大多數情況下也需要保證後向兼容性（Backward Compatibility）。所謂後向兼容性，最基本的要求就是保證原本的 API 調用方式維持不變。
顯然，如果調用方式沒有發生變化，那麽原本的 API 測試用例也就不需要做大的改動，這樣用例的可重用性就很高，進而可以保證較高的投入產出比

可見，互聯網產品的這些特性決定了，API 測試可以實現良好的投入產出比，因此應該成為互聯網產品的測試重點。這也就是為什麽互聯網產品的測試策略更像是個菱形結構的原因。

如圖 2 所示就是這個菱形的測試策略，遵循“重量級 API 測試，輕量級 GUI 測試，輕量級單元測試”的原則。

圖 2 互聯網產品的菱形測試策略
第三，單元測試

了解了“重量級 API 測試”和“輕量級 GUI 測試”，接下來，我就跟你說說為什麽是“輕量級單元測試”。

從理論上講，無論是傳統軟件產品還是互聯網產品，單元測試都是從源頭保證軟件質量的重要手段，因此都非常重要。但現實是，互聯網產品真正能全面開展單元測試，並嚴格控制代碼覆蓋率的企業還是鳳毛麟角。

但凡存在的都會有其合理性，我認為最主要的原因還是在於互聯網產品的“快”，快速實現功能，快速尋求用戶反饋，快速試錯，快速叠代更新。

在這樣的模式下，互聯網產品追求的是最快速的功能實現並上線，基本不會給你時間去做全面的單元測試。即使給你預留了單元測試的時間，頻繁的叠代也會讓單元測試處於不斷重寫的狀態。因此，單元測試原本的價值，很難在實際操作層面得到體現。

那麽，互聯網產品真的可以不用做單元測試麽？答案是否定的，只不是這裏的單元測試策略要采用“分而治之”的思想。

互聯網產品通常會分為應用層和後端服務，後端服務又可以進一步細分為應用服務和基礎服務。

後端基礎服務和一些公共應用服務相對穩定，而且對於系統全局來說是“牽一發而動全身”，所以後端服務很有必要開展全面的單元測試；而對於變動非常頻繁的客戶端應用和非公用的後端應用服務，一般很少會去做單元測試。

另外，對於一些核心算法和關鍵應用，比如銀行網關接口，第三方支付集成接口等，也要做比較全面的單元測試。

總結來講，互聯網產品的全面單元測試只會應用在那些相對穩定和最核心的模塊和服務上，而應用層或者上層業務服務很少會大規模開展單元測試。

總結
傳統軟件通常采用金字塔模型的測試策略，而現今的互聯網產品往往采用菱形模型。菱形模型有以下四個關鍵點：

1.以中間層的 API 測試為重點做全面的測試。
2.輕量級的 GUI 測試，只覆蓋最核心直接影響主營業務流程的 E2E 場景。
3.最上層的 GUI 測試通常利用探索式測試思維，以人工測試的方式發現盡可能多的潛在問題。
4.單元測試采用“分而治之”的思想，只對那些相對穩定並且核心的服務和模塊開展全面的單元測試，而應用層或者上層業務只會做少量的單元測試。

互聯網產品的測試策略應該如何設計-------打卡第十一天