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

首先我們將移動應用的范圍限定在智能移動操作系統(比如Android、iOS、WinPhone等)上，包括手機應用，智能設備應用等。

智能手機和智能設備的普及需要大量的應用來支撐。隨著應用數量的增多，業務復雜度的提高，移動應用也越來越需要各種測試來保證應用以及設備本身的正確和穩定運行。因此移動應用測試的需求也越來越大，大量關于移動應用測試的書籍應運而生，比如 《Android移動性能實戰》 ， 《騰訊iOS測試實踐》 、 《移動APP性能評測與優化》 、 《深入理解Android自動化測試》 、 《精通移動App測試實戰：技術、工具和案例》 等。

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

[[216573]]

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

制訂測試策略

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

基礎測試

• 功能測試 (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來做，應該由整個團隊一起協作完成)：

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

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

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

但是對于在移動應用中實現復雜業務的項目，測試策略還是應該盡量思考測試類型之間測試用例重復的問題，盡量避免重復的用例，降低測試成本。

制定測試架構

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

圖中只針對功能測試進行了進一步的詳細架構設計，并沒有對其他測試比如集成測試、兼容性測試和穩定測試等進行詳細架構設計，感興趣的讀者可以根據自己項目的實際情況自己嘗試一下。

通過這個架構圖，可以比較系統以及直觀的了解各種類型測試的分布、關系和測試系統的架構等。

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

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

注：

• [1]. 后臺常住應用測試也屬于功能測試。
• [2]. 單機應用可以不用考慮做契約測試。
• [3]. 異常測試包括弱網測試，比如低速網絡信號、網絡時斷時續，網絡切換以及無網絡等，突然斷電等。
• [4]. 其他硬件功能專項測試包括硬件功能關閉，硬件功能異常等。
• [5]. 用戶測試包括收集用戶使用信息，并生成用戶真實使用的測試用例來對系統進行測試。