0、引言

社區 C 端質量體系建設思考？

詢問一下 ChatGPT

1、關于社區客戶端

1.1 社區端上功能

1.2 客戶端技術棧

移動端應用可以分為三大類：Web 應用（Web App）、原生應用（NativeApp）、混合應用（Hybrid App）。

• Web 應用

這里的 web 應用指的是移動端的 web 瀏覽器，和 PC 端的差別就是在移動端依附的操作系統是 iOS 和 Android 系統。一般采用的技術棧就是傳統的 HTML、JS、CSS 等，包括這些年流行的 H5，但本質上還是個 web 網頁，所以自然支持了跨平臺。在社區這邊主要用的是 nextjs11。

• 原生應用

原生應用指的是移動端的原生應用，對于 Android 是 apk，對于 iOS 就是 ipa。Native App 是一種基于手機操作系統（iOS 和 Android），并使用原生程序編寫運行的第三方應用程序，補充一下還有鴻蒙系統。

原生應用的開發，Android 使用的語言通常是 Java、kotlin，iOS 使用的語言是 Objective-C、swift。通常來說，Native App 可以提供比較好的用戶體驗以及性能，而且可以方便地操作手機本地資源。

得物 App，安卓主要是用的 kotlin，iOS 用的是 swift。

• 混合應用

混合應用是介于 Web 應用和原生應用兩者之間的一種應用形式。

混合應用利用了 Web 應用和原生應用的優點，通過一個原生容器來展示 H5 頁面。更通俗的講法可以歸結為，在原生移動應用中嵌入了 Webview，然后通過該 Webview 來訪問網頁。

混合應用具有維護更新簡單，用戶體驗優異以及較好的跨平臺特性，是目前主流的移動應用開發模式。

基本了解一下端上技術棧也能幫我們在測試過程中有針對性的測試，同時為后續參與客戶端 cr 做好準備 ，下面的具體案例中也能體現出來。

1.3 端上相關數據

通過質量大盤，用例平臺和夜航星平臺拉取的 2022 年社區的用例數，線下 bug 數、線上問題反饋數，這些數據能給我們在建設端上質量體系帶來一定的參考價值。根據圖中用例的占比和 bug 占比的趨勢看，服務端用例發現 bug 率略低于客戶端，分析發現服務端 bug 偏重邏輯，客戶端一大部分都是 UI 交互相關，在提 bug 的顆粒度上有所區別。安卓端的 bug 數明顯高于了 iOS 端，是不是說明了安卓端的質量要略差于 iOS 呢，因為受限于整年數據的無法精準下鉆，只能在后續的版本迭代中觀察注意。從反饋的線上問題來看，除了功能性 bug 以外，還有一部分是體驗和兼容性問題很值得我們關注。iOS 的反饋問題數高于安卓，分析下來應該是線上問題反饋有一部分是內部反饋，因為內部同學使用 iOS 居多。

2022 年用例數

2022 各端 bug 數

2022 夜航星記錄線上問題

2、端上測試實踐

2.1 功能測試

如圖是一個產品質量模型，基于這些屬性，結合用戶、業務和產品特點等進行更深入的分析，以了解對質量的具體要求，哪些質量特性需要優先關注。例如社區的推薦流，屬于內容消費類的功能，那么首先考慮的肯定是功能性可用，然后就是易用性（好不好用美不美觀直接影響到了用戶體驗），接著就是要考慮兼容性、效率及性能等等。

最原始最有效的測試手段毋庸置疑到目前為止還是功能測試。作為專業的測試從業者都會有一套扎實的測試理論基礎，也許會覺得這有啥可講的呢～，但很多我們覺得理所應當的測試方法也恰恰是在一次又一次迭代中完善的。下面也是結合社區在端上測試實踐及具體案例來總結一下端上的測試方法。

2.1.1 測試方法

這里引用一下朱少民老師在《全程軟件測試》中對測試方法的總結：

在測試分析、設計、自動化測試中，會采用大量的測試方法和技術，但對于一個團隊來說不一定掌握足夠的測試方法和技術。另外，針對一個特定的項目或特定的功能，也不是把所有的測試方法都應用一遍，而是根據問題選擇合適的方法。所以，針對測試方法和技術，也要做到知己知彼。

• 團隊或團隊成員目前掌握了哪些測試方法和技術？
• 當前項目采用什么樣的測試方法和技術是更加合適的？

可以從不同層次、不同維度或角度去看。從高層次看，測試方法體現了方法論或流派。流派有基于邏輯分析的測試方法、基于上下文驅動的測試等；方法論有基于需求的方法，它涵蓋了過去傳統的黑盒方法（等價類劃分、邊界值分析等），而結構化方法涵蓋了過去傳統的白盒方法（語句覆蓋、判定覆蓋、條件覆蓋等），但這樣劃分，在項目中沒有多大的應用價值，而是根據方法的應用場景、技術特征來劃分對應用者更有啟發，例如以下劃分。

• 基于直覺和經驗的方法。
• 基于輸入域的方法。
• 組合測試方法。
• 基于邏輯覆蓋的方法。
• 基本路徑測試方法。
• 基于故障模式的測試方法。
• 基于模型的測試方法。
• 模糊測試方法。
• 基于場景的測試方法。

在移動端的測試過程中，我們會發現它的復雜性越來越高，測試效率要比服務端低的多。因為是直接面向用戶操作，那么就會涉及到不同機型不同系統，甚至是各種不同的操作手勢和無法預知的用戶行為，都會難以避免的出現測試遺漏。在這個過程中我們通過積累經驗豐富我們的測試場景，結合線上監控盡可能的去發現并解決無法預知的問題。

那么具體會怎么去做呢？比如你拿到一個需求。需求分析 -> 用例設計 -> 測試 -> 驗收（只列測試行為相關的），具體的用例設計方法就不列了，學過軟工的都清楚。下面通過兩個案例來講一下。

• 案例 1

功能：優化負反饋選項，新增二三級類目

問題：返回三個標簽時，第三個標簽在 iOS 端無法點擊。其余場景都正常。

拿到這個需求去測時，按照我們的經驗，標簽返回數 2、3、4 都會去測，然后大概率就是每個標簽數中隨機點擊一兩個測試一下接口傳參及客戶端功能。作為一個在原有功能基礎上優化的小需求很容易忽視不會更詳細的去測。很簡單的一個全排列組合的算術，負反饋「不感興趣」下全部點一遍就是（2+3+4）*2=18 次。那么當我們純黑盒去測時，這個還屬于有限可接受的數量級去全排列組合測，當遇到指數級的場景呢？這時候我們想到的是結合白盒，這個其實在去年的一篇博客中我也舉過服務端的一個案例就是結合白盒去設計用例。可以看到下面 iOS 有問題的這段代碼，就是行列的判斷錯誤，導致在返回 3 個標簽時，因為通過 column 字段去判斷的話因為第二行第二列沒數據，走到第一個判斷條件 cnotallow=itemY，就會導致無法點擊。

• 案例 2

功能：社區用戶私信

問題：消息列表露出的不是收到的最新消息，而是自己發的最新消息

排查下來發現是因為本地時間調快了 5 分鐘，落本地數據庫時，自己發出去的消息對于接收到的消息來說是晚于對方消息的，那么在消息中心露出最新一條消息時就不能按照時間戳了。一般在測試過程中時我們設計的各種 case 邏輯基本都是基于正常時間的狀態下測試的。但遇到這種和時間有關聯的功能時，我們是很有必要去考慮本地時間不準的場景。

• 改進及后續 action

案例一，有限集的場景盡可能的多覆蓋，可以像服務端一樣去多了解客戶端代碼邏輯，嘗試去 CR 客戶端代碼，同時更應該多體驗多探索。這就是客戶端和服務端比較大的一個區別，很多時候無法窮舉所有的場景。

案例二，一些非平常用戶習慣的場景很容易引發各種問題，對于我們排查問題也是帶來了很大的困擾。通過這個案例也可以看出客戶端的場景復雜度，或者在用例設計時比較依賴于測試、產品、開發的經驗。

我們可以從三個大方向入手來補充我們的 case：

1. 傳統的用例設計方法，參考等價類劃分法、邊界值法、因果圖法、正交實驗法等等
2. 結合白盒，通過熟悉了解客戶端代碼補充用例
3. 積累了解不同的用戶習慣，根據不同的業務特點考慮其他可能影響因素

2.2.2 兼容性測試

關于得物 App 的兼容性測試，主要測試軟件（APK、IPA）。所謂兼容性測試就是保證 App 在各種不同的手機品牌型號和各種不同的操作系統上能正常運行使用。也同時包括屏幕的分辨率、不同的網絡環境。一般需要覆蓋以下這些場景：

• 不同的操作系統，主流的 Android 和 ios 系統，包括華為的鴻蒙系統
• 各種系統版本
• 不同的手機品牌
• 各種手機分辨率
• 網絡環境：WiFi、5G、4G、甚至是弱網環境
• 更細節點還可以測試不同的系統語言、不同的系統字體大小、系統權限等

（1）社區實踐

在我們日常測試過程中，大家肯定會有疑問就是市面上有這么多品牌機型和系統，我們怎么在這快節奏的迭代中去挑選覆蓋。這里我們使用得物 App 的手機品牌占比、系統占比以 DPM 線上監控數據為依據。

比如在社區我們會在每個版本提供當前線上占比高的機型和系統，UI 改動大的需求都會要求去測兼容性，其余場景自己酌情考慮。

（2）兼容提效

手工的兼容性測試方案基本沒有更多的提效空間，通過工具平臺能力來提效的思路有以下幾個方向。

• 智能推薦

占比高的設備及系統可以接入 DPM 平臺做智能推薦達到支持實時更新（目前社區算是實現了第一版，直接給出 top10 的，后續可以結合云真機平臺使用）。

• 得物云真機 - 效能組實現

可以搭建 top5 的設備及系統支持同步執行同一套 UI 自動化腳本，同時可以引入支持圖像算法來判斷不同機型不同系統相同頁面的 UI 是否一致。

得物云真機可以支持測試使用，同時可以考慮支持同步操作多態機器來測試兼容性。

• 引入 AI 測試，簡單了解了下市面上的 AI 測試框架，目前看來真要落地使用還是有段距離。

（3）第三方平臺

使用 testin 平臺去測試我們沒有的機型 or 系統，提供 testin 兼容性測試用例，讓第三方測試團隊幫忙覆蓋更多的機型系統。

2.2.3 探索性測試

探索性測試（Exploratory Testing）是軟件測試方法的一種，它的特點為在進行測試時，同時探索開發更多不同型態的測試方式，以便改善測試流程。當軟件開始測試流程后，一般測試者會使用預先設立好的測試案例來進行程式測試，而探索性測試就是為了彌補傳統的案例測試的缺點而產生。

探索性測試這個詞是由 Cem Kaner 在 1983 年提出。他將探索性測試定義為：一種強調個人自由與責任的測試方法，讓獨立的測試者可以借由不斷的學習來改善測試的規劃與測試的執行，而在測試的過程中也會同時的改善專案達到相輔相成的效果。

（1）社區實踐

探索性測試主張學習，強調同時展開測試設計、執行、并從結果中獲得反饋，從而持續優化測試。這里在社區實踐過程中更是結合了集思廣益，大家扮演不同的用戶角色去體驗探索自己不熟悉的功能。功能的負責人會簡單介紹一下功能的特性，下面就是靠大家快速學習該功能、即興發揮、動態調整測試策略，去發現一些因被思維固化或者數據差別等各種原因出現的遺漏。在過去一年的實踐中，我們也發現了很多有效 bug，在去年也是因此避免了一個線上資損問題的擴大。

2.2.4 用戶體驗

在社區是會鼓勵大家多體驗得物 App，包括在 OKR 中也是會制定對應的目標，白冰冰的凝視也會每天提醒大家前一天的社區使用時長。體驗問題我們在 RDC 上有專門的任務看板來記錄跟進優化進度，可以看到 Q1 提了 46 個體驗問題。

2.2.5 測試工具

端上測試也會用到很多輔助工具來幫助我們更有效的去測試，比如常用的抓包工具，adb 命令，ideviceinstaller 命令，安卓調試工具 Flipper，iOS 視圖工具 Lookin 等。這節不介紹 UI 自動化和性能工具，只介紹一些社區在功能測試中使用到的工具。

（1）內部開發者工具

常用的

• 環境切換
• ab 值修改，這里介紹下 ab 一鍵改為所有實驗或者對照組的功能，可以一定程度上的測試到遺漏的實驗或者交叉實驗的功能影響
• 緩存修改，這個功能可以方便大家不用一直去卸載重裝去測緩存類的功能

1. 安卓，開發者工具 -> 交易 go -> MMKV
2. iOS，開發者工具 -> 沙盒 -> Library -> Preferences -> com.siwuai.duapp.plist

（2）開源主流工具

• 抓包代理類：Charles、fiddler、wireshark 等

1. 可以查看接口請求參數
2. mock 接口
3. 弱網模擬等

• 安卓 adb  官方文檔->>

Android 調試橋 （adb） 是一種功能多樣的命令行工具，可讓您與設備進行通信。adb 命令可用于執行各種設備操作，例如安裝和調試應用。

• ideviceinstaller 官方文檔->>

1. 常用于 iOS 的快速裝包 ideviceinstaller --install <file>

• 安卓調試工具 Filpper

1. 涉及到客戶端數據庫相關的可以使用該工具來輔助驗證。
2. 還有緩存修改、日志查看、路由跳轉、圖像等詳細功能查看之前寫的博客。

• iOS 視圖工具 Lookin 官方文檔->>

Lookin 可以查看與修改 iOS App 里的 UI 對象，類似于 Xcode 自帶的 UI Inspector 工具，或另一款叫做 Reveal 的軟件。

2.2.6 問題排查

客戶端出現了問題，排查的思路和服務端有所區別。因為考慮到一些交互場景會和手機型號、系統等影響，一般都需要清晰了解到反饋問題用戶的客戶端版本、手機設備及系統相關信息。這里一般的排查思路：首先是按照用戶描述的問題，查看該功能是否是必現問題，如果不是然后再去盡可能的使用和用戶一樣的手機及系統去操作。無法復現的問題，這時候我們也可以通過 DPM 去查看用戶的行為路徑（有點類似于服務端的 trace2.0）。

這里舉個通過用戶行為路徑定位到問題的案例

問題：收到關注的人更新內容 push，點進去后 landing 到了推薦流。（功能應該是 landing 關注流并且把更新的動態內容強插到第一位）

排查過程：

• 查看是否是必現的普遍性問題及功能 bug - 不是
• 查看是否為兼容性問題，使用對應的客戶端版本及手機系統 - 未復現
• 查看日志，確認實驗組和對應時間的 push 記錄，確保用戶反饋問題的真實性，結果發現實驗是對的，push 記錄也有，但從日志分析的確是沒有調用關注流接口  - 未復現
• 查看用戶在該時間段內的操作路徑，試著按照同樣的操作去復現 - 成功復現

如截圖從行為路徑可以看出，用戶先是冷啟 app，在 lauch 頁面直接壓后臺，然后過了段時間后通過 push 喚起 app。試著復現，經過反復測試驗證，發現在冷啟后出現廣告頁時馬上壓后臺，然后再點擊收到的個性化推薦 push，就能穩定復現該問題。排查下來因為這時候 app 需要把上次未執行完的冷啟動代碼執行完，導致推送的跳轉邏輯不執行。

因為客戶端的多樣性，給開發測試排查問題造成了很大的困難，當遇到難以復現的問題時，盡可能的還原用戶一樣的環境和用戶行為，因為大家都明白所謂的非必現 bug 其實只是我們沒有找到必現路徑而已。比如之前還有遇到過因為用戶開啟了省電模式而引發的 h5 渲染加載問題，這個問題我們在各種設備上怎么也復現不出來，但只要打開了省電模式就很容易復現出來。

2.2 UI 自動化

說到 UI 自動化框架，大家多多少少都了解使用過一些，這里簡單列幾個相對比較流行的開源框架，做簡單的對比介紹。同時也介紹一下社區現在使用的和目前在社區 UI 自動化的開展情況。

（1）自動化框架

（2）社區實踐

社區也是從一開始的 appiumn 、airtest到如今統一使用內部自研的UI自動化平臺 Teslalab 平臺。

在社區，目前會按照各自負責的業務模塊劃分去編寫 UI 自動化腳本，并綁定對應的 BVT case。每個版本綁定轉測單，會統一在提測后+預發線上回歸兩個時間段去執行。目前使用下來的效果，通過自動化發現的bug主要集中在提測后的冒煙階段，相當于代替手工提前做了核心功能的回歸。

2.3 性能測試

客戶端的性能和服務端的性能還是有很大的區別，從性能指標出發就有很大的不同。服務端基礎指標：QPS、RT、CPU、內存等；客戶端性能基礎指標通常會關注：CPU、內存、FPS、秒開、視頻卡幀率、耗電、耗流等。因為現在手機的配置越來越高，性能一般都是過剩的，大家也許會慢慢的不太關注這些指標。但在我們使用的過程中，是不是出現過在使用某個 app 時出現手機發燙、滑動某個頁面不流暢等問題？其實這些都是性能問題，CPU 占用過高會使手機發燙卡頓，緩存數據不及時釋放導致內存占用升高，FPS 過低導致頁面滑動流暢度低等都會極大影響用戶體驗。性能測試一般都在功能測試驗證完成后進行，不然過早的介入性能測試意義不大。

（1）常用的性能測試工具

（2）社區實踐

按照統一要求 iOS 和 Android 分別使用了中端手機作為基線測試機，使用 TeslaLab 作為性能測試工具，每個版本迭代都會去執行 PV 較高的功能性能指標，確保性能數據沒有劣化。如圖516版本的安卓端性能數據，通過和歷史版本性能數據對比發現性能沒有明顯的下降，但發現了兩個內存泄漏問題，也是規避了這兩問題帶到線上影響用戶體驗。

2.4 穩定性測試

一款軟件的好不好用，最基本的要求應該就屬于穩定性。試想一下，當你在一款 app 上操作時，某些有流程性的用戶行為，比如你要下單買東西，或者實名認證操作，進行到一半， app 突然 crash 了，這時候你的心情。根據業界的統計，app 閃退率越高，活躍用戶下降趨勢越明顯，所以對于 app 進行穩定性測試至關重要。

說到穩定性測試，大家比較熟悉的就是 Monkey，常被用來做安卓端的隨機壓力測試。但考慮它不支持 iOS，還有就是會出現意想不到的跳出 app 的問題，在實踐中放棄。在社區我們通過深度遍歷的方式來測試穩定性，目前也是在實踐過程中遇到了比如各種彈窗的干擾等，也是不斷的優化改進中，包括在未來我們希望能做成一套通用的工具，支持在平常的業務測試過程中，只針對于自己負責的模塊業務相關的頁面去做一些隨機性的交互測試。

（1）常用的穩定性測試工具

2.5 安全性測試

在移動互聯網時代，智能機的普及使得 app 被廣泛使用，應用的安全問題直接關系到公司和用戶的切身利益。列舉一些 App 容易出現的安全問題：

• 接口的明文通信，通過抓包工具可以直接獲取到接口返回的敏感信息
• 沒有接口驗簽或者驗簽被破解，造成接口攔截后數據篡改
• 用戶隱私，登錄密碼，支付密碼等敏感信息的明文保存或者展示
• app 所在的文件權限是否允許被其他 app 的讀取
• apk 的逆向破解等

3、總結與思考

對于端上的質量體系建設，我們整個團隊包括開發產品一起在做不斷的努力。我們在滿足于基礎功能的測試同時，也是在不斷的探索實踐，通過各種工具手段，不同的測試思路來盡可能的保障 app 質量，并且也是不斷的注重用戶體驗。有些已經起步做起來了，也是有了明顯的收益比如兼容性測試、探索性測試、端上體驗等；也有些做起來了，但目前還沒有很明顯的收益比如穩定性測試、UI 自動化；還有沒有開始的安全性測試也是未來的考慮方向。

端上的測試遠遠不止于此，該篇文章也是結合社區現在端上測試現狀做的經驗總結分享，上述無論是哪一塊內容都可以單獨拎出來做一個專題去討論，也是歡迎大家一起交流學習，可以直接在評論區留言，促進互相學習。