0、引言

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

詢問一下 ChatGPT

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

1.1 社區(qū)端上功能

1.2 客戶端技術(shù)棧

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

• Web 應(yīng)用

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

• 原生應(yīng)用

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

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

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

• 混合應(yīng)用

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

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

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

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

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

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

2022 年用例數(shù)

2022 各端 bug 數(shù)

2022 夜航星記錄線上問題

2、端上測(cè)試實(shí)踐

2.1 功能測(cè)試

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

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

2.1.1 測(cè)試方法

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

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

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

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

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

在移動(dòng)端的測(cè)試過程中，我們會(huì)發(fā)現(xiàn)它的復(fù)雜性越來越高，測(cè)試效率要比服務(wù)端低的多。因?yàn)槭侵苯用嫦蛴脩舨僮鳎敲淳蜁?huì)涉及到不同機(jī)型不同系統(tǒng)，甚至是各種不同的操作手勢(shì)和無法預(yù)知的用戶行為，都會(huì)難以避免的出現(xiàn)測(cè)試遺漏。在這個(gè)過程中我們通過積累經(jīng)驗(yàn)豐富我們的測(cè)試場(chǎng)景，結(jié)合線上監(jiān)控盡可能的去發(fā)現(xiàn)并解決無法預(yù)知的問題。

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

• 案例 1

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

問題：返回三個(gè)標(biāo)簽時(shí)，第三個(gè)標(biāo)簽在 iOS 端無法點(diǎn)擊。其余場(chǎng)景都正常。

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

• 案例 2

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

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

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

• 改進(jìn)及后續(xù) action

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

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

我們可以從三個(gè)大方向入手來補(bǔ)充我們的 case：

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

2.2.2 兼容性測(cè)試

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

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

（1）社區(qū)實(shí)踐

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

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

（2）兼容提效

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

• 智能推薦

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

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

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

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

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

（3）第三方平臺(tái)

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

2.2.3 探索性測(cè)試

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

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

（1）社區(qū)實(shí)踐

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

2.2.4 用戶體驗(yàn)

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

2.2.5 測(cè)試工具

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

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

常用的

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

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

（2）開源主流工具

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

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

• 安卓 adb  官方文檔->>

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

• ideviceinstaller 官方文檔->>

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

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

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

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

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

2.2.6 問題排查

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

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

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

排查過程：

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

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

因?yàn)榭蛻舳说亩鄻有裕o開發(fā)測(cè)試排查問題造成了很大的困難，當(dāng)遇到難以復(fù)現(xiàn)的問題時(shí)，盡可能的還原用戶一樣的環(huán)境和用戶行為，因?yàn)榇蠹叶济靼姿^的非必現(xiàn) bug 其實(shí)只是我們沒有找到必現(xiàn)路徑而已。比如之前還有遇到過因?yàn)橛脩糸_啟了省電模式而引發(fā)的 h5 渲染加載問題，這個(gè)問題我們?cè)诟鞣N設(shè)備上怎么也復(fù)現(xiàn)不出來，但只要打開了省電模式就很容易復(fù)現(xiàn)出來。

2.2 UI 自動(dòng)化

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

（1）自動(dòng)化框架

（2）社區(qū)實(shí)踐

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

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

2.3 性能測(cè)試

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

（1）常用的性能測(cè)試工具

（2）社區(qū)實(shí)踐

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

2.4 穩(wěn)定性測(cè)試

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

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

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

2.5 安全性測(cè)試

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

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

3、總結(jié)與思考

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

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