目錄
一、客戶端
1.1 客戶端具體功能
一、如果用戶點擊微博的關注圖標但是app上面沒有反應 // 登錄的按鈕不能點擊，如何排查問題？
整體流程三部分，客戶端、中間數據流、服務端
二、有個用戶反饋上傳頭像失敗，分析原因？
三、10%的用戶反饋用不了功能，你將如何排查？
關鍵詞是 10%，說明只對部分用戶產生影響，考慮的思路有以下幾點：
1.2 客戶端異常
一、app閃退的原因？// 客戶端出現崩潰的常見類型
二、偶然閃退的排查？
-
要抓取日志具體分析。
1、查看 crash 日志。
// Android APP 可以用 adb 命令去查看：
adb logcat *:E | grep CRASH
// iOS 日志獲取方式：
參考：https://www.cnblogs.com/lesten/p/14295526.html
2、一般成熟的團隊都會有 crash 的監控平台，可以從 crash 平台上去查看 crash 發生位點。 -
日志獲取不到，要嘗試復現。
1、手工嘗試復現 crash，一般偶然的閃退，都不會特別容易復現，可能需要適當施加一些比較苛刻的條件（弱網、斷網、快速點擊、快速划動等等）。
2、執行 Monkey 或遍歷測試，暴力操作手機，嘗試復現 bug。
三、網頁卡頓的原因是什么？
| 原因 | 解決方案 |
|---|---|
| http 請求次數太多 | 規范接口設計，減少 http 請求次數。 |
| 接收數據時間過長，如下載資源過大 | 對 HTTP 傳輸進行壓縮，可采用 gzip 無損壓縮，壓縮效果最佳。 |
| JavaScript 腳本過大，阻塞了頁面的加載 | 將 JavaScript 腳本放在標簽前。script 沒有 async 和 defer 時，JS 文件將在下載后立即執行。這種情況下，script 放在頂部會阻塞頁面呈現，在網速慢的情況下會導致“白屏”，直到腳本下載完畢才繼續呈現頁面。因此，script 放在底部可以讓頁面盡快呈現。 |
| CSS、JavaScript、圖片等需要重復加載 | 靜態資源統一放在一個靜態域名上，減輕重復下載靜態資源的負擔。 |
| cookie 影響 | 減小 cookie 的影響 。去除沒有必要的 cookie，如果網頁不需要 cookie 就完全禁掉。此外，對 cookie 瘦身和設置合適的 cookie 過期時間，也能削弱 cookie 的影響。 |
| 網頁資源過多 | 使用 CDN 部署網絡以提高下載速度，可以先通過免費的 CDN 供應商來分發網頁資源。 |
四、APP 提示無法連接網絡，你會如何排查？
樣式和交互層面的 Bug，大概率都是前端的 Bug。
數據和文案相關的 Bug，大概率都是后端的 Bug。（測試時host配置也會影響）
拿移動端來說，最簡單但是又最實用的辦法是對比測試，即 Android 和 iOS 對比測試，
假如說 Android 和 iOS 都有問題，可能是后端 Bug；
假如說 Android 和 iOS 有一端有問題，則可能是 Andorid 或者 iOS 某一終端的 Bug，但也不一定絕對，也有可能是后端的 Bug。
二、其他問題
一、運營發現訪問量減少，如何排查？
1）通過日志收集平台或者后端訪問日志，收集功能的埋點信息，分析接口是否發送成功；是否消息丟失；是否用戶收到；
2）確認是否最近有相關模塊功能修改
3）是否受市場影響
4）是否之前有爬蟲造成訪問量大，現在變少
二、壓測的時候，QPS 一直上不去，你會怎么排查？
| 分類 | 原因 | 解決方案 |
|---|---|---|
| 被測服務器的性能 | 看是否資源被打滿，導致請求無法連接 | 被測服務器擴容。 |
| 被測接口 | 看接口是否出現報錯、響應時間是否變慢 | 接口性能優化 |
| 壓測機器的性能 | 是不是網絡 IO 占滿，並發數達不到 | 多台壓測機器並發 |
| 壓測工具 | 看壓測工具是否支持並發請求 | 采用多線程或協程的方式去並發請求 |
參考資料
部分內容參考：https://my.oschina.net/u/4575195/blog/4442751