功能測試層面經過兩年多的踩坑和總結，測試思路基本穩定下來了。工作一年的時候有過一次測試方法和測試思路的總結，本篇正是在這篇基礎上的擴充完善，基礎思路就這麼多，剩下的只是根據項目變化，所以命名爲2.0的總結 :)
每一個優秀的測試人員都會在工作中形成自己測試方法—我剛畢業的時候一個大牛和我說的一句話，影響至今
測試模式？建模！
在編程中我們把一類問題的解決方法抽象成設計模式，那麼測試也是一樣的，可以抽象成測試模式，初期的想法是把一類問題的思考點抽象出來，形成測試思路，但是後來發現抽象的高度拿捏不準，代碼是非常自由的，需求也是非常靈活的，導致某些固定的模式是浪費時間，所以只能往更高的方面去抽象，是的也就是思想層面，測試分析方面。建模這個詞最早出現在騰訊的tmq小組，發現思想還是相近的，所以，測試的設計模式就是建模。
階梯分析
上面畫了一幅圖，說明的是測試成本的趨勢，越往下成本越大，對產品質量的要求就越高。
有：有是什麼，需要迅速佔領市場，時間就是生命，初期創業團隊模式，或是隻有一兩個功能測試人員幫助開發分擔測試任務
優：當具有一定規模，已經有一定用戶量，更多考慮的是如何更好地留住用戶，普通的功能測試已經滿足不了產品需求，更多的是關注產品的內在，而不是亂加新功能。這時，項目更多關心的是效率問題，也會開發出各種工具提高效率(平臺建設，自動化等等)，並且已經意識到，質量不僅僅是測試人員的事，整個產品的人員都是測試人員(google例子)。
測試思路：
下面的測試方法和上面的階梯其實想對應，在有的階段，功能測試爲主，你只要掌握場景分析和元素分析就完成了，因爲項目根本不會給你時間也沒有機會讓你接觸數據測試更別說性能自動化了;在一定量的項目下，數據的深入測試和性能和自動化就會被引入，更多的是技術型驗證替代手工驗證，功能測試人員全部轉爲外包形式。
思路 && 方法
場景和元素分析建模
這個分析方法是根據流程走，根據流程裏面的元素逐一驗證。比如air/nano的拍照界面,應該這樣思考：
1.從哪裏進入
2.幹了什麼事
3.乾的事界面有什麼元素，每個元素影響的東西是什麼
4.幹完這件事怎麼出去，怎麼結束
5… …
那麼再加上一些需求特性，比如:GPS開關、插不插入相機硬件、電量充不充足、有沒有自動旋轉等，就可以形成覆蓋率比較高的用例了:
比如：
例子1) 本地應用：
先來上例子，測試一下播號頁面：
步驟一：場景建模
輸入號碼—撥號—掛斷
步驟二：組合用例
1.撥號面板輸入正常號碼正常點擊撥號後掛斷
2.撥號面板輸入異常號碼正常點擊撥號後掛斷
3.撥號面板輸入空號碼正常點擊撥號後掛斷
4…. …
步驟三：完善
在這一步，是對上兩部的擴充，往往不易發現的bug都出現在破壞性實驗上，所以這裏擴展的基礎是探索性測試，這裏只列出來我自己用的比較多的方法，更多方法可以網絡獲取
指南法
地標測試法
取消法
測一贈一法
懶漢法
極限法
反叛法
那麼根據這些方法，我們可以這麼幹：
1.不輸入文本播放
2.輸入超長文本播放
3.撥號後馬上取消，重複
4.不停旋轉屏幕，撥號
5…. …
數據流分析
對於網絡性應用，跟隨的是數據流過程，這類應用無外乎都是這樣一個流程：
首先，服務器暴露給客戶端的接口只有一個json文件，客戶端通過http|s請求，拿到響應後解析json文件裏面的不同字段，按需求封裝成不同類型的數據，加載各種顯示控件，並把數據賦值給UI控件，最後對重要的數據做內存緩存和磁盤緩存，以便下次不重複加載。
上面這是一句很簡單的流程，但是實現起來卻不簡單，我們每一句話來分析：
客戶端通過http|s請求：什麼時候請求、請求的頻率是否合理、數據是否過多、是否重複拉取、無網絡還會拉取嗎、弱網會怎麼樣、對各種響應碼是否正常處理、服務器端有沒有對不常刷新的數據做緩存、這個接口性能怎麼樣…
拿到響應後解析json文件裏面的不同字段：json字段的容錯性、客戶端使用裏面的哪裏字段來展示、數據刷新後是否成功替換UI數據…
加載各種顯示控件，並把數據賦值給UI控件：控件是否及時加載、加載的數據符不符合需求、有沒有默認圖…
對重要的數據做內存緩存和磁盤緩存：存儲在哪裏、什麼時候會存、存儲的數據格式是什麼、清緩存重裝對數據的影響、誤刪部分數據是否正常生成、存儲目錄合不合理(避免使用系統目錄)、是否針對低內存做限制…
擴展閱讀：通過codereview方法跟蹤數據流和分析(還沒有寫)
例子2)
我們以某項目的精選頁面爲例來進行講解
在上圖中建立起了接口–數據的一一對應關係，有助於我們理解數據走向。
有了對應關係，我們測試就變得非常簡單了：
入口：需要驗證各個啓動方式進入精選頁是否刷新
數據拉取：驗證各個網絡情況下數據拉取
數據展示：驗證各個字段在控件內的展示(過長、爲空、刷新等)、數據刷新、對應需求正確性
數據存儲：做緩存
其他：不同機型分辨率的兼容性、新安裝和覆蓋安裝數據展示等
性能自動化分析(進階)
前者是爲了更好的體驗，增加用戶粘度，後者節省手工人力成本，提高精確度節省開銷。我們直接看例子1和例子2能做什麼樣的測試。
例子1是一個撥號應用，所以對耗時比較看重；撥號設計到硬件底層的調用，如果代碼不夠健壯可能會存在內存泄漏。綜上，會有如下的性能測試點：
1.新開機打開撥號面板耗時
2.後臺留有進程打開撥號面板
3.輸入號碼點擊撥打到呼叫等待頁面時間
4.我掛斷/對方掛斷到回到撥號面板的時間
5.多次撥打接通並掛斷，查看內存
對於自動化，覆蓋也是比較好覆蓋的，各個按鈕的點擊、撥打和掛斷都可以形成多次有效的用例
例子2是一個數據展示需求，負責數據拉取和展示，可以進行流量和內存的測試，對於自動化，可以在用例解析json文件來對應到對應的界面展示，剩下的都是一些需求特性了。另外對於拉取接口的數據，更具要求還會進行多併發測試和接口測試。
