今天我們來談?wù)勔苿訙y試的測試策略與測試架構(gòu)。
首先我們將移動應(yīng)用的范圍限定在智能移動操作系統(tǒng)（比如Android、iOS蜗侈、WinPhone等）上，包括手機應(yīng)用睡蟋，智能設(shè)備應(yīng)用等踏幻。
智能手機和智能設(shè)備的普及需要大量的應(yīng)用來支撐。隨著應(yīng)用數(shù)量的增多戳杀，業(yè)務(wù)復(fù)雜度的提高该面，移動應(yīng)用也越來越需要各種測試來保證應(yīng)用以及設(shè)備本身的正確和穩(wěn)定運行。因此移動應(yīng)用測試的需求也越來越大信卡，大量關(guān)于移動應(yīng)用測試的書籍應(yīng)運而生隔缀，比如《Android移動性能實戰(zhàn)》，《騰訊iOS測試實踐》傍菇、《移動APP性能評測與優(yōu)化》猾瘸、《深入理解Android自動化測試》、《精通移動App測試實戰(zhàn)：技術(shù)丢习、工具和案例》等牵触。
這些書都介紹了大量的移動應(yīng)用測試實踐，但是無論看多少本書咐低，學(xué)習(xí)多少種測試方法揽思、測試技術(shù)或者測試工具和框架，首先還是需要學(xué)習(xí)并使用測試策略與測試架構(gòu)见擦。如果沒有在一開始制定好的測試策略和測試架構(gòu)钉汗，而是盲目進行各種測試，很有可能事倍功半鲤屡。
對于移動應(yīng)用损痰，首先它本質(zhì)上也是軟件系統(tǒng)，所以通用的軟件測試方法技術(shù)都可以使用酒来。其次它又擁有嵌入式的特征卢未，比如開發(fā)需要交叉編譯、需要遠程調(diào)試役首、硬件資源相對不足等尝丐。所以移動應(yīng)用的測試也有其特殊之處，比如也需要交叉編譯衡奥、遠程測試以及各種硬件相關(guān)測試等爹袁。對應(yīng)的移動應(yīng)用的測試策略和測試架構(gòu)也有其特殊性之處。
制定測試策略
我將移動測試分為三種類型矮固，分別是基礎(chǔ)測試失息、進階測試和產(chǎn)品測試譬淳，其中基礎(chǔ)測試是產(chǎn)品能正確并快速交付的基本保障，擴展測試主要是為了增強軟件系統(tǒng)的健壯性盹兢，而產(chǎn)品測試主要是通過產(chǎn)品角度以及用戶角度去思考而進行的測試邻梆。下面分別列舉了常見的三種類型測試。
基礎(chǔ)測試
- 功能測試 (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]
產(chǎn)品測試
- 易用性測試（Usability Test）
- A/B測試（A/B Test）
- 產(chǎn)品在線測試（Product Verification Test or Product Online Test）
- 用戶測試（Customer Test）[5]
對于一個中小型項目來講见芹，很多時候資源都是十分有限的剂娄，很難做到全面類型的測試，大型項目更是如此玄呛，更難有足夠多的資源做所有類型的測試阅懦。而且可能還由于團隊人員的技術(shù)能力不足，或者所擁有的測試相關(guān)的技術(shù)棧的局限徘铝，以及開發(fā)測試環(huán)境和軟件系統(tǒng)架構(gòu)的限制耳胎，有些類型的測試是無法進行的。
所以惕它，制定測試策略的關(guān)鍵點在于根據(jù)質(zhì)量需求的優(yōu)先級怕午，并參考團隊的各種限制來指定。
首先通過和PO怠缸、PM等進行討論得到產(chǎn)品質(zhì)量需求的優(yōu)先級诗轻，然后根據(jù)優(yōu)先級指定相應(yīng)類型的測試钳宪。再根據(jù)團隊的資源揭北、項目周期、技術(shù)能力以及各種限制來制定相應(yīng)的測試方法和測試技術(shù)吏颖，其中包括使用自動化測試還是手動測試搔体、使用什么測試工具和測試框架、測試的范圍和程度等半醉。
下表是一個典型手機應(yīng)用的測試策略表的樣例(這個只是一個模擬項目的樣表疚俱，真實項目中的各類信息應(yīng)該更多，并且可以根據(jù)具體情況添加新列缩多。并且注意呆奕，這些測試并不一定由測試人員或者QA來做，應(yīng)該由整個團隊一起協(xié)作完成)：
表中的質(zhì)量需求優(yōu)先級的獲取是一個比較繁瑣的過程衬吆，需要和各個利益相關(guān)者一起討論并且協(xié)商獲得梁钾。
根據(jù)這個測試優(yōu)先級表，就知道應(yīng)該把資源優(yōu)先投入到高優(yōu)先級的測試中逊抡。等高優(yōu)先級的測試做到團隊可以接受的程度后姆泻，再按照優(yōu)先級做下一個類型的測試。這個表中的優(yōu)先級在開發(fā)過程中不是絕對不變的。如果PO拇勃、PM等利益相關(guān)者對于產(chǎn)品質(zhì)量需求的優(yōu)先級發(fā)生了改變四苇，在得到團隊同意后，還需要改變這個表中的測試優(yōu)先級方咆。所以需要經(jīng)常與團隊更新測試進度月腋，并及時獲得團隊各個角色對于測試和產(chǎn)品質(zhì)量需求的反饋與更新。
其次可以根據(jù)測試金字塔等模型來思考不同類型測試之間的關(guān)系和工作量瓣赂，但是很多情況下也可以不用參考這些測試模型罗售，因為移動應(yīng)用的復(fù)雜度一般不會特別高，并且當前大多數(shù)情況下钩述，移動應(yīng)用中復(fù)雜的業(yè)務(wù)邏輯都會盡量在服務(wù)器端進行處理寨躁，所以移動應(yīng)用很多時候只是一個用戶交互系統(tǒng)，所以應(yīng)該盡可能的完成會影響用戶使用的E2E流程測試牙勘，然后再繼續(xù)做其他類型的測試职恳。
但是對于在移動應(yīng)用中實現(xiàn)復(fù)雜業(yè)務(wù)的項目，測試策略還是應(yīng)該盡量思考測試類型之間測試用例重復(fù)的問題方面，盡量避免重復(fù)的用例放钦，降低測試成本。
制定測試架構(gòu)
通過測試優(yōu)先級表恭金，我們獲得了簡易版的測試策略操禀，然后就應(yīng)該制定測試架構(gòu)了。由于嵌入式軟件的特殊性横腿，其測試架構(gòu)也與常規(guī)的桌面系統(tǒng)和服務(wù)器系統(tǒng)有一定的區(qū)別颓屑。下圖為針對上面樣列測試策略相對應(yīng)的功能測試架構(gòu)：
圖中只針對功能測試進行了進一步的詳細架構(gòu)設(shè)計，并沒有對其他測試比如集成測試耿焊、兼容性測試和穩(wěn)定測試等進行詳細架構(gòu)設(shè)計揪惦，感興趣的讀者可以根據(jù)自己項目的實際情況自己嘗試一下。
通過這個架構(gòu)圖罗侯，可以比較系統(tǒng)以及直觀的了解各種類型測試的分布器腋、關(guān)系和測試系統(tǒng)的架構(gòu)等。
然后配合測試優(yōu)先級表就可以較好的指導(dǎo)團隊進行有效的測試钩杰，比如制定更好的測試計劃纫塌，制定更適合的自動化測試系統(tǒng)等。并且還可以更有效的評估產(chǎn)品質(zhì)量讲弄，比如什么類型的測試沒有做措左，那么那些特定方面就存在較高的風險。
不過任何軟件系統(tǒng)都是存在缺陷和風險的垂睬，關(guān)鍵是看這些缺陷對于開發(fā)商和用戶產(chǎn)生的影響有多大媳荒，風險是不是在可控范圍內(nèi)的抗悍。永遠不要嘗試去找到所有缺陷并消除，而是要從風險大小钳枕、影響程度等各方面綜合考慮缴渊，增加團隊對于產(chǎn)品質(zhì)量的信心，并且不要對客戶產(chǎn)生嚴重的大范圍的影響鱼炒。
注：
[1]. 后臺常住應(yīng)用測試也屬于功能測試衔沼。
[2]. 單機應(yīng)用可以不用考慮做契約測試。
[3]. 異常測試包括弱網(wǎng)測試昔瞧，比如低速網(wǎng)絡(luò)信號指蚁、網(wǎng)絡(luò)時斷時續(xù)，網(wǎng)絡(luò)切換以及無網(wǎng)絡(luò)等自晰，突然斷電等凝化。
[4]. 其他硬件功能專項測試包括硬件功能關(guān)閉，硬件功能異常等酬荞。
[5]. 用戶測試包括收集用戶使用信息搓劫，并生成用戶真實使用的測試用例來對系統(tǒng)進行測試。
