APP效能測試是什麼
從網上查了一下，貌似也沒什麼特別的定義，我這邊根據自己的經驗給出一個自己的定義，如有巧合純屬雷同。
客戶端效能測試就是，從業務和使用者的角度出發，設計合理且有效的效能測試場景，制定各效能場景下的客戶端效能指標(記憶體、CPU、卡頓數、幀率、電量、載入時長等)，並制定規範化的執行流程，按照執行標準執行效能場景同時使用效能測試具收集效能資料，並對資料進行分析，如果有效能問題並對問題進行定位，配合開發進行修復驗證釋出，最後輸出完整的效能報告。
從上面的定義中，我們可以得出，在APP的效能測試需要關注以下幾方面，效能測試的場景的設計、效能指標的定義、規範化的執行流程、效能資料資料收集、效能資料分析、效能問題定位、效能測試報告。
效能測試並不是說我們上來找個工具，隨便跑個場景，拿到資料，輸出個報告，就可以了。每一步都應該做到有的放矢，從而體現出測試人員的專業性。
APP效能測試怎麼做
下面我們分別來看一下：
效能測試場景的設計
場景可能是一個操作的不斷重複，也可能是幾個操作的組合再重複，對於效能測試的場景來說，他一定有重複的操作或者持續的操作，目的是透過重複或者持續的操作，把效能問題放大到一定程度，能夠讓我們發現問題。
舉個例子：以B站推薦tab為例，想測試feed滑動情況下的效能表現，那效能場景可以設計成，feed滑動50次，每次滑動間隔2s。
效能指標的定義
常見的移動端效能指標有：記憶體、cpu、幀率、卡頓數、wakp up數、展示時長等，關注什麼效能指標是依託於我們的效能測試場景。
舉個例子：以B站推薦tab為例，當我們冷啟APP進入推薦tab的時候，更關注資料展示時長，滑動場景更關注卡頓數，為不同場景設計合理的效能指標也是我們需要認真考慮的。
規範化執行流程
場景和指標都定義好了以後，就要開始執行了，這裡要求要規範化執行，規範化執行不是簡單的按照場景的定義去執行就好，而是要有很多關注的點。
可以定義的規範有哪些：
- 場景開始執行前需要等待多少s
- 執行後需要等待多少s
- 每次測試需不需要冷啟或是必須重新安裝
- 安裝好需要等待多久才可以開始測試
- 測試賬號、測試資料、裝置、網路需不需要固定每一個點都可能影響的效能資料的準確性，必須要定義規範，每次都要按著規範去執行，而且這個規範是動態，隨著我們不斷的測試，會發現很多影響效能資料的問題，都必須定製規範，加以規避。同時好的規範能夠未我們後面進行效能資料分析打下基礎。
效能資料資料收集
效能資料收集可能是整個客戶端效能測試中最簡單的部分了，有成熟的工具perfdog可以使用，方便簡單，也可以使用商業化的perfdog service實現自動化的效能資料收集，就是需要花錢。
效能資料分析
在收集到效能資料之後，就要去分析資料，如何分析，下面我簡單說一下，後面會出文章專門說如何對效能資料進行分析
- 走勢圖，從走勢圖上我們大致可以看出該場景在當前版本的效能表現，可以得出以下結論：
- 和之前版本的走勢圖進行對比，效能指標的波動情況
- 效能指標峰值、場景的均值以及漲幅的變化
- 場景的起始值與之前版本的變化
- 場景結束後的值與之前版本的變化
效能問題定位
在進行完效能資料分析以後，如果有問題，就需要去定位問題是那一塊業務的問題或者是哪一個mr引起的問題，就需要回溯。
- 先找開發，和開發溝通一下，看能否根據問題表象確定問題，如果確認不了，就需要測試定位是哪個mr合入引起的
- 列出本次版本合入所有mr，篩選出那些mr是效能問題所在的業務
- 找mr合入前後的包重新跑，確認每個mr是否有影響
- 當確定是哪個mr合入引起的效能問題後，再次和開發溝通
效能測試報告
效能測試報告的目的是給出當前版本的效能表現情況，需要包含一些核心的模組
- 測試結論
- 效能問題歸因
- 各個場景的效能指標資料
- 測試環境以及方案
- 各個場景的效能指標走勢圖
以上我對app效能測試的一些粗淺理解和經驗，有問題可以留言，一起探討。。
最後感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，這些資料，對於【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，雖然不是什麼很值錢的東西，如果你用得到的話可以直接拿走：
