軍規(guī)十九 進(jìn)行自動化和探索性測試
在測試設(shè)計時最主要依據(jù)的就是測試金字塔的測試結(jié)構(gòu)。如果在項目臨近發(fā)布才開始測試并發(fā)現(xiàn)缺陷，這樣修復(fù)缺陷的成本就會很高，項目的進(jìn)度也會很不確定。所以慌洪，就開發(fā)階段來說，如果把測試分層凑保，在不同的開發(fā)階段都進(jìn)行測試冈爹，能很大程度上緩解這些問題。

測試分層的優(yōu)勢有以下幾點(diǎn)：
1欧引，測試的成本
單元測試的開發(fā)成本要遠(yuǎn)低于用戶界面測試频伤，如果在用戶界面的測試中發(fā)現(xiàn)缺陷，修復(fù)缺陷的成本也是遠(yuǎn)高于通過單元測試和組件測試的成本芝此。
這里的成本不單純是開發(fā)人員修復(fù)缺陷所需要的資源和時間憋肖，還包括缺陷修復(fù)后測試人員進(jìn)行回歸測試所需要的資源和時間，以及項目延期等其他項目成本婚苹。
2岸更，測試的效率
單元測試能很快地驗證很小的功能或者方法，且運(yùn)行時間短膊升，反饋更為及時怎炊。
3，缺陷定位的難易
單元測試失敗后用僧，測試人員能夠很容易知道是被測試的特定功能或者方法不正確结胀；而如果是用戶界面的缺陷赞咙，測試人員就需要花費(fèi)更多的時間來進(jìn)行排查责循，確定出現(xiàn)問題的功能模塊，最后再進(jìn)一步發(fā)現(xiàn)需要修復(fù)的功能和方法攀操。
4院仿，反映真實的業(yè)務(wù)需求
單元測試無法從全局觀的角度了解系統(tǒng)模塊之間的交互，也無法通過方法的組合幫助用戶完成業(yè)務(wù)目的速和；而由于用戶界面的測試描述的是從用戶角度出發(fā)的用戶使用場景歹垫，因此可以更容易地闡述用戶的行為和業(yè)務(wù)需求。
5颠放，更加接近業(yè)務(wù)
用戶界面測試描述測試的層級更高排惨，所以更接近業(yè)務(wù)；單元測試描述測試的層級更具體碰凶，所以更接近于實現(xiàn)暮芭。

從測試金字塔分層來看鹿驼，不同層級的測試都很有必要，而我們也需要根據(jù)不同測試所處的層級及其特點(diǎn)來設(shè)計測試辕宏。
另外畜晰，實際測試設(shè)計時采用的測試金字塔具有更多更細(xì)節(jié)的分層。高層級的測試和低級別的測試相比瑞筐，抽象程度更高凄鼻，測試運(yùn)行的時間更長，與更多的系統(tǒng)和模塊有交互聚假。反饋的周期更長块蚌，接近缺陷的成本也更高。

單元和組件測試的測試驅(qū)動開發(fā)TDD的基本循環(huán)步驟是：
1膘格，測試失斝僮印；
2闯袒，測試通過虎敦；
3，重構(gòu)政敢；
由于測試驅(qū)動開發(fā)是針對單元和組件測試所使用的開發(fā)技術(shù)其徙，所以在進(jìn)行單元和組件測試時，測試人員只需要了解并評審開發(fā)人員在單元和組件測試中覆蓋了哪些場景喷户，并不需要完成其實現(xiàn)唾那。

在單元測試和組件測試之上的是Mobile Service的API測試，這一類測試通常需要自動化實現(xiàn)褪尝，且通常需要開發(fā)人員和測試人員一起討論并實施闹获，因為開發(fā)人員更了解Mobile Service的API細(xì)節(jié)，而測試人員能夠更好地從用戶角度拍定API的優(yōu)先級和重要程度河哑，從而優(yōu)化API測試的投入產(chǎn)出比避诽。

測試金字塔中自動化部分的最高層級是用戶界面的自動化測試，它需要準(zhǔn)備的測試環(huán)境和測試數(shù)據(jù)更加復(fù)雜璃谨，運(yùn)行時間更長沙庐。在編寫用戶界面的自動化測試時，編寫的原則是盡可能編寫用戶旅程級別的測試用例佳吞，而不是針對某一特定的小功能和模塊進(jìn)行測試拱雏，而是重點(diǎn)測試的是正向測試路徑(Happy Path)；對于反向測試路徑(Sad Path)底扳，盡可能使用低層級的測試來進(jìn)行覆蓋。
用戶旅程是一個用戶體驗設(shè)計的術(shù)語菇爪，指的是為達(dá)到某種特定目的凳宙，用戶所執(zhí)行的一系列操作的集合。
可以幫助實現(xiàn)App上用戶界面的自動化測試的常見工具有Appium，Calabash饺汹，F(xiàn)rank兜辞，MonkeyTalk逸吵，iOS UIAutomation，Robotium，Android UIAutomator段多，iOS-driver，KeepItFunctional，Selendroid，Zucchini等缀程。

在測試金字塔的最高層級滤奈，是對于App的“探索性測試”(Exploratory Testing)。
1昭躺，探索性測試是針對于腳本測試提出的领炫，但是兩者并不是針鋒相對的，而是相輔相成的碟狞。探索性測試，腳本測試和自動化測試之間可以相互轉(zhuǎn)化脆淹，相輔相成盖溺。
2，探索性測試要求測試人員在執(zhí)行測試時，如同用戶旅程一樣哮内，首先設(shè)定好測試目標(biāo)纹因，然后規(guī)劃出一段時間，使用啟發(fā)式測試策略模型(Heuristic Test Strategy Model，HTSM)陕截，通過測試人員的創(chuàng)造性思維驻债，采取不同的測試路徑暮的，來達(dá)到測試目標(biāo)的測試方法。
啟發(fā)性測試策略模型的主要內(nèi)容是：測試人員使用質(zhì)量標(biāo)準(zhǔn)淌实，項目環(huán)境冻辩，產(chǎn)品元素，指導(dǎo)測試技術(shù)的選擇與應(yīng)用拆祈，并產(chǎn)生觀察到的質(zhì)量恨闪。
3，在探索性測試執(zhí)行中放坏，為了提高探索性測試的效率咙咽，并且能夠重現(xiàn)所發(fā)現(xiàn)的問題，可以采用基于測程的測試管理(Session-Based Test Management淤年，SBTM)钧敞。在App測試中也可以使用SBTM技巧進(jìn)行探索性測試。
4麸粮，針對App的探索性測試溉苛，測試人員需要測試在低層級測試中不能覆蓋的對于頁面跳轉(zhuǎn)和不同頁面間數(shù)據(jù)流動和展示等需要涉及到多個頁面的流程操作。
5豹休，當(dāng)進(jìn)行App的探索性測試時炊昆，選擇在真實設(shè)備上運(yùn)行可以提高測試的真實性和加深對于用戶使用場景的理解，從而不斷促進(jìn)探索性測試的發(fā)展和深入威根。

軍規(guī)二十 進(jìn)行性能和安全性測試
如何讓用戶感覺App運(yùn)行速度更快呢凤巨，這需要對App進(jìn)行性能測試。限制App性能的因素按照App的系統(tǒng)結(jié)構(gòu)分為App自身和App需要用到的后臺服務(wù)洛搀。
1敢茁，測試App連接網(wǎng)絡(luò)的速度
一般采用在模擬Mock環(huán)境下進(jìn)行測試，測試方法更多使用的是在App的log中添加時間戳的方式計算時間留美，例如使用Apple公司提供的iPhone Configuration Utility中Devices的Console查看App的log彰檬。
2，測試App在不同網(wǎng)絡(luò)速度下操作的流程程度
測試可以使用在App的log中添加時間戳方法驗證谎砾，也可以通過使用App的直觀感受來驗證App性能帶給用戶的體驗逢倍。
3，測試App對于前臺頁面渲染的性能
測試可以使用在App的log中添加時間戳方法驗證景图，也可以通過使用App的直觀感受來驗證App性能帶給用戶的體驗较雕。特殊的是，當(dāng)App中使用WebView挚币，測試人員可以快速地刷新當(dāng)前頁面或者在使用WebView的頁面間進(jìn)行切換亮蒋，來驗證App是否有性能問題甚至發(fā)生崩潰。
4妆毕，測試App操作數(shù)據(jù)庫的性能
iOS操作系統(tǒng)在設(shè)備本地存儲App數(shù)據(jù)時使用的是CoreData或者SQLite數(shù)據(jù)庫慎玖；Android操作系統(tǒng)在設(shè)備本地存儲App數(shù)據(jù)時使用SQLite數(shù)據(jù)庫。如果操作的數(shù)據(jù)量很大笛粘，便有可能出現(xiàn)App的性能問題趁怔，因此需要對數(shù)據(jù)庫操作的功能進(jìn)行大數(shù)據(jù)量的測試。測試人員也可以和開發(fā)人員一起薪前，遵照Web端數(shù)據(jù)庫優(yōu)化的一些原則润努，如數(shù)據(jù)庫啟用事務(wù)，使用索引序六，數(shù)據(jù)的批量操作等優(yōu)化方法任连，提高數(shù)據(jù)庫的性能。
5例诀，測試App用到的后臺服務(wù)Mobile Service的性能
舉例一些測試人員可以用來測試Web性能的測試工具随抠，如Apache Jmeter，Gatling繁涂，LoadRunner拱她，LoadUI和NewRelic等。
6扔罪，測試App是否保存了臨時數(shù)據(jù)或者已刪除的數(shù)據(jù)
可以通過文件管理App等第三方App來查看App是否保存了不該保存的文件秉沼，如cookie文件。
7，測試App的會話session是否有過期設(shè)置
對于App的會話session是否有過期設(shè)置的測試唬复，可以在App運(yùn)行中切換到別的App或者桌面一段時間矗积，然后再次進(jìn)入App，看App是否需要輸入密碼等驗證信息敞咧。值得注意的是不同App的合理session過期時間不一樣棘捣，測試人員需要和產(chǎn)品經(jīng)理、開發(fā)人員等確認(rèn)之后制定出合理的測試用例休建。
8乍恐，測試App請求中是否包含了明文的用戶信息
包含了明文的信息，如同App中標(biāo)示用戶應(yīng)該使用UUID或GUID等轉(zhuǎn)碼后的信息测砂，而不是直接的用戶電話號碼或賬戶信息茵烈，當(dāng)然更不應(yīng)該明文傳送這些信息。測試人員可以使用Apple的iPhone Configuration Utility砌些，Android SDK自帶的DDMS呜投，Charles和Fiddler這些工具來監(jiān)控App發(fā)送的請求。
9寄症，測試App的請求是否加密
一般App請求可以使用HTTP宙彪，但是關(guān)系到用戶敏感信息的請求，需要使用HTTPS等加密傳輸有巧。
10释漆，測試SQLite數(shù)據(jù)庫的存儲是否安全
測試人員可以通過ADB連接到root的Android蛇別，并使用SQLite來查看具體的數(shù)據(jù)庫保存的信息篮迎。顯然男图，把用戶實際的登錄信息明文存儲在數(shù)據(jù)庫文件中是不安全的，最好不要存儲甜橱，如果必須存儲逊笆，最好對這些信息加密后再存儲。
11岂傲，測試App使用WebView的安全性
由于WebView的請求和在Web端請求數(shù)據(jù)是一樣的难裆，所以任何適用于Web端的攻擊方式和漏洞對于WebView來說都是通用的。
12镊掖，測試App的后臺服務(wù)Mobile Service
測試人員可以采用與Web安全性測試通用的一些工具乃戈，如Zed Attack Proxy(ZAP)，Burp Suite亩进，Websecurify症虑，Wapiti和WebScarab等。

軍規(guī)二十一 使用log定位問題
測試人員發(fā)現(xiàn)一個App缺陷時归薛，通常會需要log文件來定位缺陷問題谍憔，尤其是在難以復(fù)現(xiàn)缺陷的時候匪蝙。使用log收集工具可以在測試中記錄和報告缺陷，給測試人員帶來很多便利习贫。常用的獲取App崩潰log的工具有Crashlytics逛球，Splunk MINT Express(之前稱之為Bugsense)，TestFlight和HockeyApp沈条。

軍規(guī)二十二 充分使用持續(xù)集成和持續(xù)部署
一方面為了解決App的穩(wěn)定性問題需忿，防止修復(fù)缺陷時引入新的缺陷诅炉，一方面為了讓測試人員不再懷疑自動化測試的覆蓋蜡歹，我們可以把在模擬器上運(yùn)行的App各級自動化測試加入持續(xù)集成(Continuous Lntegration，CI)的流程中涕烧。
持續(xù)部署比持續(xù)集成更進(jìn)一步月而，不僅覆蓋了App的開發(fā)階段，還包括App的自動部署议纯。這里的自動部署父款，不止包括App在測試環(huán)境中的自動部署，還包括了App部署到生產(chǎn)環(huán)境瞻凤；不僅需要部署App本事憨攒，還需要對App依賴的各種后臺服務(wù)和系統(tǒng)進(jìn)行測試環(huán)境以及生產(chǎn)環(huán)境的部署。另外阀参，持續(xù)部署還包括了生產(chǎn)環(huán)境中的監(jiān)控和分析肝集，以及對App的反饋及改進(jìn)整個流程。