移動應用的測試策略與測試架構

今天我們來談談移動測試的測試策略與測試架構。

首先我們將移動應用的範圍限定在智慧移動作業系統（比如Android、iOS、WinPhone等）上，包括手機應用，智慧裝置應用等。

智慧手機和智慧裝置的普及需要大量的應用來支撐。隨著應用數量的增多，業務複雜度的提高，移動應用也越來越需要各種測試來保證應用以及裝置本身的正確和穩定執行。因此移動應用測試的需求也越來越大，大量關於移動應用測試的書籍應運而生，比如，、、、等。

這些書都介紹了大量的移動應用測試實踐，但是無論看多少本書，學習多少種測試方法、測試技術或者測試工具和框架，首先還是需要學習並使用測試策略與測試架構。如果沒有在一開始制定好的測試策略和測試架構，而是盲目進行各種測試，很有可能事倍功半。

image.png

對於移動應用，首先它本質上也是軟體系統，所以通用的軟體測試方法技術都可以使用。其次它又擁有嵌入式的特徵，比如開發需要交叉編譯、需要遠端除錯、硬體資源相對不足等。所以移動應用的測試也有其特殊之處，比如也需要交叉編譯、遠端測試以及各種硬體相關測試等。對應的移動應用的測試策略和測試架構也有其特殊性之處。

制定測試策略

我將移動測試分為三種型別，分別是基礎測試、進階測試和產品測試，其中基礎測試是產品能正確並快速交付的基本保障，擴充套件測試主要是為了增強軟體系統的健壯性，而產品測試主要是透過產品角度以及使用者角度去思考而進行的測試。下面分別列舉了常見的三種型別測試。

基礎測試

• (Function Test)[1] 。

• 整合測試（Integration Test ）

• 單元測試（Unit Test）

• 契約測試（Contract Test）[2]

進階測試

• 相容測試（Compatibility Test）

• UI視覺測試（UI Visual Test）

• 效能輪廓（Profiling）

• （Security Test）

• 異常測試（Exception Test）[3]

• 猴子測試（Monkey Test）

• 安裝、升級和解除安裝測試（Install、Upgrade and Uninstall Test）

• 耐久測試（Endurance Test）

• 耗電測試（Power Consumption Test）

• 流量測試（Network Traffic Test）

• 其他硬體功能專項測試[4]

產品測試

• 易用性測試（Usability Test）

• A/B測試（A/B Test）

• 產品線上測試（Product Verification Test or Product Online Test）

• 使用者測試（Customer Test）[5]

對於一箇中小型專案來講，很多時候資源都是十分有限的，很難做到全面型別的測試，大型專案更是如此，更難有足夠多的資源做所有型別的測試。而且可能還由於團隊人員的技術能力不足，或者所擁有的測試相關的技術棧的侷限，以及開發測試環境和軟體系統架構的限制，有些型別的測試是無法進行的。

所以，制定測試策略的關鍵點在於根據質量需求的優先順序，並參考團隊的各種限制來指定。

首先透過和PO、PM等進行討論得到產品質量需求的優先順序，然後根據優先順序指定相應型別的測試。再根據團隊的資源、專案週期、技術能力以及各種限制來制定相應的測試方法和測試技術，其中包括使用自動化測試還是手動測試、使用什麼測試工具和測試框架、測試的範圍和程度等。

下表是一個典型手機應用的測試策略表的樣例(這個只是一個模擬專案的樣表，真實專案中的各類資訊應該更多，並且可以根據具體情況新增新列。並且注意，這些測試並不一定由測試人員或者QA來做，應該由整個團隊一起協作完成)：

image.png

表中的質量需求優先順序的獲取是一個比較繁瑣的過程，需要和各個利益相關者一起討論並且協商獲得。

根據這個測試優先順序表，就知道應該把資源優先投入到高優先順序的測試中。等高優先順序的測試做到團隊可以接受的程度後，再按照優先順序做下一個型別的測試。這個表中的優先順序在開發過程中不是絕對不變的。如果PO、PM等利益相關者對於產品質量需求的優先順序發生了改變，在得到團隊同意後，還需要改變這個表中的測試優先順序。所以需要經常與團隊更新測試進度，並及時獲得團隊各個角色對於測試和產品質量需求的反饋與更新。

其次可以根據等模型來思考不同型別測試之間的關係和工作量，但是很多情況下也可以不用參考這些測試模型，因為移動應用的複雜度一般不會特別高，並且當前大多數情況下，移動應用中複雜的業務邏輯都會盡量在伺服器端進行處理，所以移動應用很多時候只是一個使用者互動系統，所以應該儘可能的完成會影響使用者使用的E2E流程測試，然後再繼續做其他型別的測試。

但是對於在移動應用中實現複雜業務的專案，測試策略還是應該儘量思考測試型別之間測試用例重複的問題，儘量避免重複的用例，降低測試成本。

制定測試架構

透過測試優先順序表，我們獲得了簡易版的測試策略，然後就應該制定了。由於嵌入式軟體的特殊性，其測試架構也與常規的桌面系統和伺服器系統有一定的區別。下圖為針對上面樣列測試策略相對應的架構：

image.png

圖中只針對進行了進一步的詳細架構設計，並沒有對其他測試比如整合測試、相容性測試和穩定測試等進行詳細架構設計，感興趣的讀者可以根據自己專案的實際情況自己嘗試一下。

透過這個架構圖，可以比較系統以及直觀的瞭解各種型別測試的分佈、關係和測試系統的架構等。

然後配合測試優先順序表就可以較好的指導團隊進行有效的測試，比如制定更好的測試計劃，制定更適合的自動化測試系統等。並且還可以更有效的評估產品質量，比如什麼型別的測試沒有做，那麼那些特定方面就存在較高的風險。

不過任何軟體系統都是存在缺陷和風險的，關鍵是看這些缺陷對於開發商和使用者產生的影響有多大，風險是不是在可控範圍內的。永遠不要嘗試去找到所有缺陷並消除，而是要從風險大小、影響程度等各方面綜合考慮，增加團隊對於產品質量的信心，並且不要對客戶產生嚴重的大範圍的影響。

注：

[1]. 後臺常住應用測試也屬於。

[2]. 單機應用可以不用考慮做契約測試。

[3]. 異常測試包括弱網測試，比如低速網路訊號、網路時斷時續，網路切換以及無網路等，突然斷電等。

[4]. 其他硬體功能專項測試包括硬體功能關閉，硬體功能異常等。

[5]. 使用者測試包括收集使用者使用資訊，並生成使用者真實使用的測試用例來對系統進行測試。

作者：ThoughtWorks中國
連結：