前陣子一直在研究效能測試，但是困難挺大的，公司也主要是功能測試為主，也沒有大神帶帶我這個小白…於是自己一個人滾滾爬爬一直停在指標啊，工具的學習上面，網上的文章也都是介紹某個效能工具的使用，就沒有一個介紹測試人員該怎麼去做專項測試，流程是什麼，然後突然靈感一發，就有了這篇文章

後續會逐漸豐滿這個流程的，加油吧！

來個圖圖：

業務場景的確立，用例的設計
這一階段要做的就是要確認應用內那些場景需要覆蓋到所要的效能指標，尤其是對重要場景的覆蓋要全，比方說記憶體，就需要覆蓋到各個需要跳轉的重要頁面，多圖片載入的頁面，頻繁讀寫資料的介面。設計各個場景的測試點，形成測試用例，後續工作將會圍繞這些用例進行專項測試，所以這裡設計的覆蓋還是蠻重要的。

效能指標的確立
說實話，前陣子研究效能測試都是圍繞工具的使用上了，完全沒想到定個標準神馬的，唯一進步是想到要和競品對比，那麼這裡我自己總結下，還是要有一套針對某個應用的效能指標，這個指標的浮動參考來源於競品分析，以及實際程式碼實現的微調。對於android的標準後面再慢慢定了，不過實際上已經拿到了一套相對完整的指標，改良後再放出來吧。

測試工具的原理和選擇
確立了場景用例和指標後就是效能工具的選擇了，主要還是分為兩個吧，第一種是adb直接讀取相關資料(我喜歡封裝成python來用哈)，第二種是呼叫相關api來用，比如一些第三方工具，比如嵌入一些效能api到開發的程式碼中。當然還有就類似android studio提供的monitor可以直觀看到資料，不過原理都是基於adb的，所以歸類還是兩類工具。

缺陷原因分析和規避
其實這一步是後來加上的，一開始想測試出來哪裡出問題就好了，剩下的給開發解決吧，但是突然想到，思考問題要有高度，有深度，於是我就加上了，恩，瞬間高大上有木有。當問題測試出來可以嘗試定位到對應程式碼，分析產生問題的根源，不懂就問開發咯。當知道產生的原理後就開始思考怎麼避免，有沒有更好的工具實現自動化去避免，然後去設計這類工具，測試開發是不是幹這個的啊？我沒做過開發這個真不知道。如果這個地方影響比較大的話考慮和leader商量定個開發自測的規矩過去…差不多就是這樣了 :)

測試報告輸出
測試完成一般都會整理成world文件發出去，也是對上面的總結，有可能的話整理成ppt進行組內分享吧。