0、引言

社區(qū) C 端質(zhì)量體系建設(shè)思考？

詢問一下 ChatGPT

1、關(guān)于社區(qū)客戶端

1.1 社區(qū)端上功能

1.2 客戶端技術(shù)棧

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

• Web 應(yīng)用

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

• 原生應(yīng)用

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

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

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

• 混合應(yīng)用

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

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

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

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

1.3 端上相關(guān)數(shù)據(jù)

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

2022 年用例數(shù)

2022 各端 bug 數(shù)

2022 夜航星記錄線上問題

2、端上測試實踐

2.1 功能測試

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

最原始最有效的測試手段毋庸置疑到目前為止還是功能測試。作為專業(yè)的測試從業(yè)者都會有一套扎實的測試?yán)碚摶A(chǔ)，也許會覺得這有啥可講的呢～，但很多我們覺得理所應(yīng)當(dāng)?shù)臏y試方法也恰恰是在一次又一次迭代中完善的。下面也是結(jié)合社區(qū)在端上測試實踐及具體案例來總結(jié)一下端上的測試方法。

2.1.1 測試方法

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

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

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

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

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

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

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

• 案例 1

功能：優(yōu)化負(fù)反饋選項，新增二三級類目

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

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

• 案例 2

功能：社區(qū)用戶私信

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

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

• 改進及后續(xù) action

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

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

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

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

2.2.2 兼容性測試

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

• 不同的操作系統(tǒng)，主流的 Android 和 ios 系統(tǒng)，包括華為的鴻蒙系統(tǒng)
• 各種系統(tǒng)版本
• 不同的手機品牌
• 各種手機分辨率
• 網(wǎng)絡(luò)環(huán)境：WiFi、5G、4G、甚至是弱網(wǎng)環(huán)境
• 更細(xì)節(jié)點還可以測試不同的系統(tǒng)語言、不同的系統(tǒng)字體大小、系統(tǒng)權(quán)限等

（1）社區(qū)實踐

在我們?nèi)粘y試過程中，大家肯定會有疑問就是市面上有這么多品牌機型和系統(tǒng)，我們怎么在這快節(jié)奏的迭代中去挑選覆蓋。這里我們使用得物 App 的手機品牌占比、系統(tǒng)占比以 DPM 線上監(jiān)控數(shù)據(jù)為依據(jù)。

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

（2）兼容提效

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

• 智能推薦

占比高的設(shè)備及系統(tǒng)可以接入 DPM 平臺做智能推薦達到支持實時更新（目前社區(qū)算是實現(xiàn)了第一版，直接給出 top10 的，后續(xù)可以結(jié)合云真機平臺使用）。

• 得物云真機 - 效能組實現(xiàn)

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

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

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

（3）第三方平臺

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

2.2.3 探索性測試

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

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

（1）社區(qū)實踐

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

2.2.4 用戶體驗

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

2.2.5 測試工具

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

（1）內(nèi)部開發(fā)者工具

常用的

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

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

（2）開源主流工具

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

1. 可以查看接口請求參數(shù)
2. mock 接口
3. 弱網(wǎng)模擬等

• 安卓 adb  官方文檔->>

Android 調(diào)試橋 （adb） 是一種功能多樣的命令行工具，可讓您與設(shè)備進行通信。adb 命令可用于執(zhí)行各種設(shè)備操作，例如安裝和調(diào)試應(yīng)用。

• ideviceinstaller 官方文檔->>

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

• 安卓調(diào)試工具 Filpper

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

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

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

2.2.6 問題排查

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

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

問題：收到關(guān)注的人更新內(nèi)容 push，點進去后 landing 到了推薦流。（功能應(yīng)該是 landing 關(guān)注流并且把更新的動態(tài)內(nèi)容強插到第一位）

排查過程：

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

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

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

2.2 UI 自動化

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

（1）自動化框架

（2）社區(qū)實踐

社區(qū)也是從一開始的 appiumn 、airtest到如今統(tǒng)一使用內(nèi)部自研的UI自動化平臺 Teslalab 平臺。

在社區(qū)，目前會按照各自負(fù)責(zé)的業(yè)務(wù)模塊劃分去編寫 UI 自動化腳本，并綁定對應(yīng)的 BVT case。每個版本綁定轉(zhuǎn)測單，會統(tǒng)一在提測后+預(yù)發(fā)線上回歸兩個時間段去執(zhí)行。目前使用下來的效果，通過自動化發(fā)現(xiàn)的bug主要集中在提測后的冒煙階段，相當(dāng)于代替手工提前做了核心功能的回歸。

2.3 性能測試

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

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

（2）社區(qū)實踐

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

2.4 穩(wěn)定性測試

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

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

（1）常用的穩(wěn)定性測試工具

2.5 安全性測試

在移動互聯(lián)網(wǎng)時代，智能機的普及使得 app 被廣泛使用，應(yīng)用的安全問題直接關(guān)系到公司和用戶的切身利益。列舉一些 App 容易出現(xiàn)的安全問題：

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

3、總結(jié)與思考

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

端上的測試遠(yuǎn)遠(yuǎn)不止于此，該篇文章也是結(jié)合社區(qū)現(xiàn)在端上測試現(xiàn)狀做的經(jīng)驗總結(jié)分享，上述無論是哪一塊內(nèi)容都可以單獨拎出來做一個專題去討論，也是歡迎大家一起交流學(xué)習(xí)，可以直接在評論區(qū)留言，促進互相學(xué)習(xí)。