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

標籤：類比   因此   最大   自己   需要   版本升級   模型   業務流   可見   

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

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

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

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

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

比如，對於功能自動化測試案例，執行一輪全迴歸測試需要 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 測試的優點是，能夠實際類比真實使用者的行為，直接驗證軟體的商業價值；缺點是執行的代價比較大，就算是採用 G使用者介面自動化測試技術，用例的維護和執行代價依然很大。所以，要儘可能地避免對 GUI 測試的過度依賴。

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

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

第一，GUI 測試

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

互連網產品的迭代周期，決定了留給開發 G使用者介面自動化測試案例的時間非常有限；

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

由此，互連網產品的 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.單元測試採用“分而治之”的思想，只對那些相對穩定並且核心的服務和模組開展全面的單元測試，而應用程式層或者上層業務只會做少量的單元測試。

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