0、引言

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

詢問(wèn)一下 ChatGPT

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

1.1 社區(qū)端上功能

得物首頁(yè) 潛山網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。成都創(chuàng)新互聯(lián)公司成立與2013年到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)公司。	搜索、發(fā)布、關(guān)注流、推薦流、沉浸式單列流、活動(dòng) tab、其他二級(jí)頻道 tab
動(dòng)態(tài)詳情頁(yè)	圖文、視頻、專欄、點(diǎn)評(píng)
私域	個(gè)人/他人主頁(yè)、通訊錄好友、微博好友、好友推薦
創(chuàng)作者	創(chuàng)作者體系、poizon+、種草分傭、視頻分傭、成長(zhǎng)任務(wù)、創(chuàng)作靈感、創(chuàng)作學(xué)院
活動(dòng)	抽獎(jiǎng)玩法、新人池、樂(lè)高頁(yè)、年終總結(jié)、allstar全明星活動(dòng)、潮流教父藤原浩活動(dòng)
框架及創(chuàng)新	話題、圈子、ar、穿搭精選、曬單有禮、數(shù)字藏品、點(diǎn)評(píng)

    

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)用的開(kāi)發(fā)，Android 使用的語(yǔ)言通常是 Java、kotlin，iOS 使用的語(yǔ)言是 Objective-C、swift。通常來(lái)說(shuō)，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)，通過(guò)一個(gè)原生容器來(lái)展示 H5 頁(yè)面。更通俗的講法可以歸結(jié)為，在原生移動(dòng)應(yīng)用中嵌入了 Webview，然后通過(guò)該 Webview 來(lái)訪問(wèn)網(wǎng)頁(yè)。

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

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

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

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

2022 年用例數(shù)

2022 各端 bug 數(shù)

2022 夜航星記錄線上問(wèn)題

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ì)覺(jué)得這有啥可講的呢～，但很多我們覺(jué)得理所應(yīng)當(dāng)?shù)臏y(cè)試方法也恰恰是在一次又一次迭代中完善的。下面也是結(jié)合社區(qū)在端上測(cè)試實(shí)踐及具體案例來(lái)總結(jié)一下端上的測(cè)試方法。

2.1.1 測(cè)試方法

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

在測(cè)試分析、設(shè)計(jì)、自動(dòng)化測(cè)試中，會(huì)采用大量的測(cè)試方法和技術(shù)，但對(duì)于一個(gè)團(tuán)隊(duì)來(lái)說(shuō)不一定掌握足夠的測(cè)試方法和技術(shù)。另外，針對(duì)一個(gè)特定的項(xiàng)目或特定的功能，也不是把所有的測(cè)試方法都應(yīng)用一遍，而是根據(jù)問(wèn)題選擇合適的方法。所以，針對(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è)試等；方法論有基于需求的方法，它涵蓋了過(guò)去傳統(tǒng)的黑盒方法（等價(jià)類劃分、邊界值分析等），而結(jié)構(gòu)化方法涵蓋了過(guò)去傳統(tǒng)的白盒方法（語(yǔ)句覆蓋、判定覆蓋、條件覆蓋等），但這樣劃分，在項(xiàng)目中沒(méi)有多大的應(yīng)用價(jià)值，而是根據(jù)方法的應(yīng)用場(chǎng)景、技術(shù)特征來(lái)劃分對(duì)應(yīng)用者更有啟發(fā)，例如以下劃分。

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

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

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

• 案例 1

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

問(wèn)題：返回三個(gè)標(biāo)簽時(shí)，第三個(gè)標(biāo)簽在 iOS 端無(wú)法點(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í)在去年的一篇博客中我也舉過(guò)服務(wù)端的一個(gè)案例就是結(jié)合白盒去設(shè)計(jì)用例?？梢钥吹较旅?iOS 有問(wèn)題的這段代碼，就是行列的判斷錯(cuò)誤，導(dǎo)致在返回 3 個(gè)標(biāo)簽時(shí)，因?yàn)橥ㄟ^(guò) column 字段去判斷的話因?yàn)榈诙械诙袥](méi)數(shù)據(jù)，走到第一個(gè)判斷條件 cnotallow=itemY，就會(huì)導(dǎo)致無(wú)法點(diǎn)擊。

• 案例 2

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

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

排查下來(lái)發(fā)現(xiàn)是因?yàn)楸镜貢r(shí)間調(diào)快了 5 分鐘，落本地?cái)?shù)據(jù)庫(kù)時(shí)，自己發(fā)出去的消息對(duì)于接收到的消息來(lái)說(shuō)是晚于對(duì)方消息的，那么在消息中心露出最新一條消息時(shí)就不能按照時(shí)間戳了。一般在測(cè)試過(guò)程中時(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í)候無(wú)法窮舉所有的場(chǎng)景。

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

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

1. 傳統(tǒng)的用例設(shè)計(jì)方法，參考等價(jià)類劃分法、邊界值法、因果圖法、正交實(shí)驗(yàn)法等等
2. 結(jié)合白盒，通過(guò)熟悉了解客戶端代碼補(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)語(yǔ)言、不同的系統(tǒng)字體大小、系統(tǒng)權(quán)限等

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

在我們?nèi)粘y(cè)試過(guò)程中，大家肯定會(huì)有疑問(wèn)就是市面上有這么多品牌機(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è)試方案基本沒(méi)有更多的提效空間，通過(guò)工具平臺(tái)能力來(lá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í)可以引入支持圖像算法來(lái)判斷不同機(jī)型不同系統(tǒng)相同頁(yè)面的 UI 是否一致。

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

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

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

使用 testin 平臺(tái)去測(cè)試我們沒(méi)有的機(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í)探索開(kāi)發(fā)更多不同型態(tài)的測(cè)試方式，以便改善測(cè)試流程。當(dāng)軟件開(kāi)始測(cè)試流程后，一般測(cè)試者會(huì)使用預(yù)先設(shè)立好的測(cè)試案例來(lái)進(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í)來(lái)改善測(cè)試的規(guī)劃與測(cè)試的執(zhí)行，而在測(cè)試的過(guò)程中也會(huì)同時(shí)的改善專案達(dá)到相輔相成的效果。

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

探索性測(cè)試主張學(xué)習(xí)，強(qiáng)調(diào)同時(shí)展開(kāi)測(cè)試設(shè)計(jì)、執(zhí)行、并從結(jié)果中獲得反饋，從而持續(xù)優(yōu)化測(cè)試。這里在社區(qū)實(shí)踐過(guò)程中更是結(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)的遺漏。在過(guò)去一年的實(shí)踐中，我們也發(fā)現(xiàn)了很多有效 bug，在去年也是因此避免了一個(gè)線上資損問(wèn)題的擴(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)問(wèn)題我們?cè)?RDC 上有專門的任務(wù)看板來(lái)記錄跟進(jìn)優(yōu)化進(jìn)度，可以看到 Q1 提了 46 個(gè)體驗(yàn)問(wèn)題。

2.2.5 測(cè)試工具

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

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

常用的

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

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

（2）開(kāi)源主流工具

• 抓包代理類：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

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

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

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

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

2.2.6 問(wèn)題排查

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

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

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

排查過(guò)程：

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

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

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

2.2 UI 自動(dòng)化

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

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

	介紹	IDE	特點(diǎn)
Appium	Android 最底層實(shí)際上是基于 uiautomator2 iOS 基于 facebook-wda https://github.com/openatx/facebook-wda https://github.com/appium/appium		支持 iOS 平臺(tái)和 Android 平臺(tái)上的原生應(yīng)用，web 應(yīng)用和混合應(yīng)用 跨平臺(tái)跨語(yǔ)言，支持 MacOS、Linux 和 Windows，也支持 Java、Python、Ruby 和 PHP 等 使用 c/s 架構(gòu)模式，腳本可跑在服務(wù)，方便的遠(yuǎn)程控制本地機(jī)器 不支持跨應(yīng)用 本地機(jī)器需要起服務(wù)端，中文輸入支持不佳 對(duì)控件獲取較為麻煩（需要使用第三方工具）
uiautomator2	支持使用 Python 編寫腳本，直接在電腦上運(yùn)行控制手機(jī)。原理是在手機(jī)上運(yùn)行了一個(gè) http rpc 服務(wù)，將 uiautomator 中的功能開(kāi)放出來(lái)，然后再將這些 http 接口封裝成 Python 庫(kù)。uiautomator2 官方文檔->>	weditor 編輯器能夠提供輔助編寫腳本，查看組件信息，調(diào)試代碼等功能。 官方文檔：https://github.com/alibaba/web-editor 移動(dòng)設(shè)備安裝 atx server2 https://github.com/openatx/atxserver2	跨 app 僅針對(duì)原生 Android 應(yīng)用 無(wú)法錄制
Airtest	OpenCV（圖像識(shí)別）+ uiautomator 實(shí)現(xiàn) https://github.com/AirtestProject/Airtest	網(wǎng)易官方提供 AirtestIDE 是一個(gè)強(qiáng)大的 GUI 工具，可以幫助你錄制和調(diào)試測(cè)試腳本。AirtestIDE 提供了完整的自動(dòng)化工作流程支持：錄制腳本->真機(jī)回放->生成報(bào)告。	網(wǎng)易團(tuán)隊(duì)開(kāi)源，有獨(dú)立的 ide 支持 最突出的特點(diǎn)是圖像識(shí)別 支持 Android、iOS、Windows、Unity、Cocos2dx、白鷺引擎、微信小程序等平臺(tái)
poco	https://poco-chinese.readthedocs.io/zh_CN/latest/		網(wǎng)易團(tuán)隊(duì)開(kāi)源，有獨(dú)立的 ide 支持 基于 app 控件進(jìn)行自動(dòng)化操作的。與上面的 appium 和 uiautomator2 類似

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

社區(qū)也是從一開(kāi)始的 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í)行。目前使用下來(lái)的效果，通過(guò)自動(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、秒開(kāi)、視頻卡幀率、耗電、耗流等。因?yàn)楝F(xiàn)在手機(jī)的配置越來(lái)越高，性能一般都是過(guò)剩的，大家也許會(huì)慢慢的不太關(guān)注這些指標(biāo)。但在我們使用的過(guò)程中，是不是出現(xiàn)過(guò)在使用某個(gè) app 時(shí)出現(xiàn)手機(jī)發(fā)燙、滑動(dòng)某個(gè)頁(yè)面不流暢等問(wèn)題？其實(shí)這些都是性能問(wèn)題，CPU 占用過(guò)高會(huì)使手機(jī)發(fā)燙卡頓，緩存數(shù)據(jù)不及時(shí)釋放導(dǎo)致內(nèi)存占用升高，F(xiàn)PS 過(guò)低導(dǎo)致頁(yè)面滑動(dòng)流暢度低等都會(huì)極大影響用戶體驗(yàn)。性能測(cè)試一般都在功能測(cè)試驗(yàn)證完成后進(jìn)行，不然過(guò)早的介入性能測(cè)試意義不大。

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

工具	介紹	特點(diǎn)
Xcode Instrument	蘋果自帶的性能測(cè)試工具 參考文檔：Xcode Instruments usage to improve app performance，Instrument 工具使用	只支持 iOS
Emmagee	Emmagee 是一款實(shí)用、方便的性能測(cè)試工具，適用于指定的 Android 應(yīng)用程序，可以監(jiān)控 CPU、內(nèi)存、流量和電池狀態(tài)。 參考文檔：Emmagee github->>	只支持 Android
SoloPi	SoloPi 是一個(gè)無(wú)線化、非侵入式的 Android 自動(dòng)化工具，公測(cè)版擁有錄制回放、性能測(cè)試、一機(jī)多控三項(xiàng)主要功能，能為測(cè)試開(kāi)發(fā)人員節(jié)省寶貴時(shí)間。 參考文檔：SoloPi github->>	只支持 Android
PerfDog	支持所有 Android、iOS、H5、小程序、小游戲等應(yīng)用性能數(shù)據(jù)采集，收費(fèi)。	支持 iOS 和 Android
apm	客戶端性能監(jiān)控平臺(tái)，包括：內(nèi)存泄漏，卡頓監(jiān)控，ANR 監(jiān)控，F(xiàn)PS 監(jiān)控，啟動(dòng)監(jiān)控，CPU 監(jiān)控，內(nèi)存監(jiān)控，IO 監(jiān)控等 10 余項(xiàng)性能監(jiān)控指標(biāo)。	通過(guò) iOS 和安卓的埋點(diǎn)數(shù)據(jù)收集
TeslaLab 性能監(jiān)測(cè)	得物自研工具，支持 CPU、FPS、內(nèi)存等基礎(chǔ)性能數(shù)據(jù)	支持 iOS 和 Android

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

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

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

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

工具	介紹	特點(diǎn)
Monkey	Monkey 就是 SDK 中附帶的一個(gè)工具。Monkey 是 Android 中的一個(gè)命令行工具，可以運(yùn)行在模擬器里或?qū)嶋H設(shè)備中。它向系統(tǒng)發(fā)送偽隨機(jī)的用戶事件流（如按鍵輸入、觸摸屏輸入、手勢(shì)輸入等），實(shí)現(xiàn)對(duì)正在開(kāi)發(fā)的應(yīng)用程序進(jìn)行壓力測(cè)試。Monkey 測(cè)試是一種為了測(cè)試軟件的穩(wěn)定性、健壯性的快速有效的方法。	只支持 Android
Maxim	An efficient Android Monkey Tester， available for emulators and real devices 基于遍歷規(guī)則的高性能 Android Monkey，適用于真機(jī)/模擬器的 APP UI 壓力測(cè)試 參考文檔：Maxim	只支持 Android
AppCrawler	Appcrawler 是一個(gè)基于自動(dòng)遍歷的 App 爬蟲工具，支持 Android 和 IOS，支持真機(jī)和模擬器。最大的特點(diǎn)是靈活性高，可通過(guò)配置來(lái)設(shè)定遍歷的規(guī)則。 參考文檔：AppCrawler	支持 IOS 和 Android
fastbot	fastbot 是字節(jié)團(tuán)隊(duì)基于 monkey 的二次開(kāi)發(fā)的 app 穩(wěn)定性測(cè)試工具，目前已經(jīng)開(kāi)源，此工具有比較深入的算法探索，目前已經(jīng)更新了多個(gè)版本，相對(duì)穩(wěn)定的支持了移動(dòng)端 app、H5 頁(yè)面的自動(dòng)化遍歷，支持定制測(cè)試、當(dāng)發(fā)生 crash、anr 時(shí)會(huì)有比較全的 log 可導(dǎo)出供分析 參考文檔：Fastbot_Android，F(xiàn)astbot_iOS	支持 IOS 和 Android

2.5 安全性測(cè)試

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

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

3、總結(jié)與思考

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

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

本文名稱：走進(jìn)社區(qū)客戶端測(cè)試
網(wǎng)站URL：http://uogjgqi.cn/article/ccshhdh.html