1、百度測(cè)試秘籍全解析伴隨移動(dòng)互聯(lián)網(wǎng)轉(zhuǎn)型，百度的測(cè)試工程師也在實(shí)際工作中，快速跟進(jìn)技術(shù)更迭、不斷地改善測(cè)試方法和技術(shù)。本章將我們的一些優(yōu)秀實(shí)踐分享給讀者。3.1自動(dòng)化測(cè)試測(cè)試環(huán)節(jié)在整個(gè)產(chǎn)品周期中對(duì)產(chǎn)品的質(zhì)量起到關(guān)鍵的作用。 測(cè)試人員在進(jìn)行功能測(cè)試時(shí)，首先想到的就是如何擺脫一些純手工測(cè)試，將精力放入更加復(fù)雜的測(cè)試上，自動(dòng)化測(cè)試永遠(yuǎn)是最受測(cè)試人員關(guān)注的一個(gè)話題。Baidu的自動(dòng)化測(cè)試經(jīng)過(guò)10幾年的積累，小有成果。接下來(lái)以百度地圖客戶端的自動(dòng)化為實(shí)例，介紹baidu質(zhì)量部在自動(dòng)化測(cè)試上的實(shí)踐和獲益。3.1.1概述客戶端測(cè)試包括很多工作，測(cè)試工作有功能測(cè)試、穩(wěn)定性測(cè)試、代碼靜態(tài)檢查、性能測(cè)試、兼容性測(cè)試和

2、安全測(cè)試等，輔助工作有用例管理、設(shè)備管理、項(xiàng)目管理等，還有很多其他工作。工程師們往往花了很多時(shí)間在做一些重復(fù)性工作，沒(méi)有過(guò)多的精力投入到產(chǎn)品質(zhì)量的深挖上去。地圖客戶端測(cè)試效率提升思路是不定期的組織版本耗時(shí)分析，將耗時(shí)較長(zhǎng)工作縮短、將耗時(shí)少工作變?yōu)榱愫臅r(shí)，從而釋放人力做更多探索測(cè)試。比如：事例1：設(shè)備管理這塊，沒(méi)有一個(gè)公共的地方記錄設(shè)備在哪位工程師手上，工程師借出還入操作比較繁瑣，導(dǎo)致在設(shè)備調(diào)度這塊耗時(shí)很長(zhǎng)。解決方式：開(kāi)發(fā)一個(gè)設(shè)備管理app，工程師只需要打開(kāi)設(shè)備做借入還出操作；搭建設(shè)備管理平臺(tái)，用于方便查看設(shè)備是否空閑以及歸屬。事例2：地圖客戶端大框檢索業(yè)務(wù)邏輯復(fù)雜，用例繁多，耗時(shí)很長(zhǎng)（預(yù)計(jì)11

3、5分鐘）解決方式：高工對(duì)大框檢索業(yè)務(wù)進(jìn)行代碼解讀。通過(guò)業(yè)務(wù)分享、用例梳理，用例自動(dòng)化轉(zhuǎn)化等方式，最終該業(yè)務(wù)測(cè)試用例執(zhí)行耗時(shí)降低86%，預(yù)計(jì)15分鐘完成。地圖客戶端通過(guò)對(duì)測(cè)試效率得不斷迭代，得到明顯的效果也積累了一些經(jīng)驗(yàn)值：l 監(jiān)控開(kāi)發(fā)工程師每次提交代碼質(zhì)量，觸發(fā)核心功能自動(dòng)化驗(yàn)證。l 功能自動(dòng)化率最高時(shí)達(dá)到40%，集成測(cè)試一輪時(shí)間從22小時(shí)縮短至6小時(shí)。l 基于自動(dòng)化持續(xù)集成的前提，集成測(cè)試階段Android地圖客戶端做到daily灰度，保證代碼時(shí)刻處于可發(fā)布狀態(tài)。接下來(lái)，主要介紹地圖客戶端自動(dòng)化是如何構(gòu)建的。3.1.2基礎(chǔ)準(zhǔn)備用例調(diào)整很多團(tuán)隊(duì)做自動(dòng)化之前，都可能碰上這樣的問(wèn)題，測(cè)試開(kāi)發(fā)人員將

4、框架等都搭建完畢后，轉(zhuǎn)化手工用例時(shí)，發(fā)現(xiàn)手工用例無(wú)法轉(zhuǎn)化，導(dǎo)致自動(dòng)化工作開(kāi)展緩慢，且效果不好量化。地圖在前期自動(dòng)化方案也碰到這樣的問(wèn)題，產(chǎn)生的場(chǎng)景就是用例編寫(xiě)人員按照自己的理解編寫(xiě)自動(dòng)化用例步驟，而實(shí)際驗(yàn)證點(diǎn)與期望驗(yàn)證點(diǎn)相差甚遠(yuǎn)。自動(dòng)化工作開(kāi)展前，務(wù)必保證現(xiàn)有的用例可自動(dòng)化，便于后續(xù)用例自動(dòng)化轉(zhuǎn)化和自動(dòng)化效果考量。用例的要求有三點(diǎn)：l 用例目的要明確l 一個(gè)用例只有一個(gè)驗(yàn)證點(diǎn) （沒(méi)有主觀體驗(yàn)） 給出一個(gè)GOOD Case：測(cè)試目的：起點(diǎn)或終點(diǎn)以我的位置發(fā)起搜索測(cè)試步驟：1. 點(diǎn)擊路線按鈕2. 起點(diǎn)為“我的位置”3. 終點(diǎn)為“西直門”4. 點(diǎn)擊所搜按鈕期望結(jié)果：進(jìn)入公交方案列表頁(yè)自動(dòng)化工具地圖客

5、戶端分為Android和iPhone兩個(gè)端，這兩個(gè)開(kāi)發(fā)平臺(tái)的自動(dòng)化測(cè)試工具有很多，結(jié)合地圖客戶端的特點(diǎn)，我們對(duì)工具的選型如下：Android 端l 自動(dòng)化事件管理工具：Robotiuml 管理用例執(zhí)行：adb + batl 代碼語(yǔ)言：javaiPhone 端：l 自動(dòng)化事件管理工具：UIAutomation （地圖是多團(tuán)隊(duì)并行開(kāi)發(fā)，組件以庫(kù)形式提交，所以選擇非注入式框架）l 管理用例執(zhí)行：tuneup-js + shelll 處理崩潰信息：MobileDevicel 代碼語(yǔ)言：javascript自動(dòng)化框架前面提到自動(dòng)化工具選型，關(guān)于UI元素定位、事件觸發(fā)等都是基礎(chǔ)library，自動(dòng)化用例腳

6、本的落地形式很重要。就腳本可讀性和后期維護(hù)性而言，地圖最終選擇的腳本形式是關(guān)鍵字驅(qū)動(dòng)型，代碼形式如下：#import ./importall.jstest(baidumap_ios_3114747_G0,function(target, app) writeLog(回地圖主頁(yè)面); clickToBackHomePageInitializePage(); writeLog(點(diǎn)擊路線面板); clickRouteButtonHomePage(); writeLog(點(diǎn)擊公交tab圖標(biāo)); clickBusTabRouteBusPage(); writeLog(點(diǎn)擊起點(diǎn)輸入框); clickSta

7、rtBoxRouteBusPage(); writeLog(點(diǎn)擊我的位置作為起點(diǎn)/終點(diǎn)); clickLocationStartEndPage(); writeLog(點(diǎn)擊終點(diǎn)輸入框); clickEndBoxRouteBusPage(); writeLog(輸入起點(diǎn)/終點(diǎn)query+test3114747_input1); inputQueryStartEndPage(test3114747_input1); writeLog(點(diǎn)擊搜索按鈕，輸入起終點(diǎn)后，就會(huì)顯示搜索); clickConfirmButtonStartEndPage(); writeLog(檢查當(dāng)前頁(yè)面是公交方案列表頁(yè)+te

8、st3114747_check1); checkBusListPageBusListPage(test3114747_check1););我們的腳本最終落地是純業(yè)務(wù)化的，數(shù)據(jù)和用例是分開(kāi)管理。l 接口業(yè)務(wù)化的好處是即使后續(xù)替換底層事件管理工具，我們僅重新實(shí)現(xiàn)業(yè)務(wù)化接口，自動(dòng)化腳本可以復(fù)用。地圖是針對(duì)所有可自動(dòng)化的功能系統(tǒng)做業(yè)務(wù)接口拆分，作為自動(dòng)化接口暴露出去，手工用例自動(dòng)化轉(zhuǎn)化時(shí)使用這些業(yè)務(wù)接口拼裝用例。l 數(shù)據(jù)和用例分離的好處是我們可以定義多套數(shù)據(jù)對(duì)應(yīng)一個(gè)用例和便于數(shù)據(jù)的更新。地圖這邊核心功能是POI檢索、路線檢索，接口均由服務(wù)端返回，多次請(qǐng)求可能返回結(jié)果不同，為了保證用例的穩(wěn)定性，我們給每

9、個(gè)用例配3套數(shù)據(jù)。我們的自動(dòng)化框架結(jié)構(gòu)Android 和iPhone兩個(gè)平臺(tái)基本類似，只是在framework層封裝不同?？蚣芙貓D如下：圖1報(bào)告呈現(xiàn)：圖23.1.3如何實(shí)施用例管理平臺(tái)在自動(dòng)化框架部分提到地圖自動(dòng)化腳本采取關(guān)鍵字驅(qū)動(dòng)架構(gòu)，對(duì)于用例的規(guī)范性已經(jīng)有很強(qiáng)的約束性，但兩個(gè)端自動(dòng)化依然是兩套代碼，腳本編寫(xiě)和維護(hù)依然有不同步的現(xiàn)象。為了方便接口和用例維護(hù)，我們搭建了用例管理平臺(tái)，平臺(tái)上一次錄入，自動(dòng)生成雙平臺(tái)自動(dòng)化用例，測(cè)試工程師可以輕松地新增維護(hù)自動(dòng)化用例。用例呈現(xiàn)狀態(tài)：圖3用例編輯狀態(tài)：圖4持續(xù)集成各方面專項(xiàng)自動(dòng)化能力有了，需要和項(xiàng)目有效結(jié)合起來(lái)，利器就是持續(xù)集成。持續(xù)集成是什么？也就

10、是每天軟件的代碼更新都會(huì)對(duì)該軟件的功能進(jìn)行集成驗(yàn)證一次，這樣保證迭代的功能的正確性，及時(shí)暴露迭代過(guò)程中的問(wèn)題。人工方法進(jìn)行持續(xù)集成的打包和驗(yàn)證顯然行不通，這樣會(huì)耗費(fèi)大量的人力和資源，因此自動(dòng)化就成為進(jìn)行持續(xù)集成的基礎(chǔ)。地圖組的持續(xù)集成測(cè)試如圖包含這樣幾類：自動(dòng)化打包、準(zhǔn)入測(cè)試、Daily自動(dòng)化、安全測(cè)試等。定時(shí)觸發(fā)RD代碼提交觸發(fā)mapmo_android_checkin代碼checkin時(shí)長(zhǎng)：3mincoretest測(cè)試包產(chǎn)出mapmo_android_checkin_CoreTest核心功能驗(yàn)證時(shí)長(zhǎng)：3min測(cè)試結(jié)果mmapmo_android_autotest_push_testui補(bǔ)充

11、推送相關(guān)的測(cè)試時(shí)長(zhǎng)：12min測(cè)試結(jié)果自動(dòng)觸發(fā)mapmo_mapclient_android_baseline拉取時(shí)長(zhǎng)：4minrelease包mapmo_android_autotest_functionUI功能自動(dòng)化定時(shí)觸發(fā)時(shí)長(zhǎng)：4Hmapmo_android_autotest_securitytestH5頁(yè)面安全測(cè)試時(shí)長(zhǎng)：7min測(cè)試結(jié)果測(cè)試結(jié)果daily測(cè)試包mapmo_android_compile_debug打包供測(cè)試時(shí)長(zhǎng)：4min定時(shí)自動(dòng)觸發(fā)圖5百度地圖持續(xù)集成統(tǒng)一采用Jenkins持續(xù)集成系統(tǒng)，自動(dòng)化持續(xù)的構(gòu)建和測(cè)試。自動(dòng)化打包：打測(cè)試包是自動(dòng)化測(cè)試的基礎(chǔ)，打包分成兩類：一類是

12、被測(cè)的地圖apk，一類是測(cè)試apk，通過(guò)gradle腳本指令進(jìn)行apk自動(dòng)編譯。其中被測(cè)的地圖apk打包的方式是：每三分鐘監(jiān)控一次svn的變化，如果地圖包的svn有任何代碼的變動(dòng)就會(huì)觸發(fā)自動(dòng)打包編譯，產(chǎn)出地圖的包供測(cè)試使用。準(zhǔn)入測(cè)試：作為RD提交代碼的第一道關(guān)卡，將重要問(wèn)題卡在最前端。供測(cè)試用的地圖包一旦產(chǎn)出就會(huì)觸發(fā)準(zhǔn)入測(cè)試的job，準(zhǔn)入測(cè)試的job一共做了兩件事：第一件事是產(chǎn)出測(cè)試apk，也就是將準(zhǔn)入測(cè)試的自動(dòng)化case打包成測(cè)試apk并安裝進(jìn)手機(jī)里，第二件事是運(yùn)行準(zhǔn)入的自動(dòng)化用例，如果自動(dòng)化用例運(yùn)行失敗則立刻觸發(fā)報(bào)警，提示RD及時(shí)糾正錯(cuò)誤的代碼，有效的保障了地圖apk包的準(zhǔn)入質(zhì)量。Dail

13、y自動(dòng)化：按天運(yùn)行的集成自動(dòng)化用例，包含集成測(cè)試中所有的自動(dòng)化用例，用例量大，運(yùn)行時(shí)間久，因此每天運(yùn)行一次，并將結(jié)果自動(dòng)整理發(fā)送郵件周知給項(xiàng)目負(fù)責(zé)人，由項(xiàng)目負(fù)責(zé)人分析失敗的用例，將集成測(cè)試才會(huì)集中暴露問(wèn)題的風(fēng)險(xiǎn)提前。安全測(cè)試：用于定時(shí)掃描app中的安全漏洞，提早發(fā)現(xiàn)app的安全問(wèn)題。百度地圖通過(guò)這幾種持續(xù)集成的自動(dòng)化測(cè)試方法形成了一套完整的線下測(cè)試持續(xù)集成方案，有效的保障了地圖app持續(xù)集成的穩(wěn)定性，將質(zhì)量風(fēng)險(xiǎn)盡可能前置。用戶體驗(yàn)館用戶體驗(yàn)館是手機(jī)地圖實(shí)施自動(dòng)化的另一個(gè)成功案例。簡(jiǎn)而言之，用戶體驗(yàn)館為核心用戶群提供一站式服務(wù)的移動(dòng)測(cè)試平臺(tái)，包含為核心用戶提供app測(cè)試包下載、自動(dòng)化測(cè)試插件下載

14、和用戶中心功能，其中自動(dòng)化測(cè)試插件提供了一種新的自動(dòng)化運(yùn)行模式，它以插件的形式嵌入地圖體驗(yàn)館中，可以隨時(shí)云端進(jìn)行更新和下載自動(dòng)化用例，用戶只需根據(jù)提示下載最新的自動(dòng)化用例，手工操作運(yùn)行即可，運(yùn)行結(jié)果將在聯(lián)網(wǎng)的情況下自動(dòng)回傳給云端進(jìn)行整合分析。通過(guò)用戶體驗(yàn)館的實(shí)施解決了測(cè)試中用戶體驗(yàn)反饋少、UI兼容性測(cè)試缺失、新功能用戶測(cè)驗(yàn)證不足和運(yùn)營(yíng)成本高的問(wèn)題，補(bǔ)充了整體的測(cè)試方案。4.2穩(wěn)定性測(cè)試穩(wěn)定的產(chǎn)品質(zhì)量是留住用戶的第一道閥門，所以穩(wěn)定性測(cè)試是常規(guī)測(cè)試中必不可少的。下面介紹百度應(yīng)用比較廣泛的兩款穩(wěn)定性工具：系統(tǒng)級(jí)穩(wěn)定性測(cè)試工具 smartmonkey 和可定制模塊級(jí)別的內(nèi)核穩(wěn)定性工具。3.2.1系統(tǒng)

15、穩(wěn)定性測(cè)試smartmonkeyAndroid自動(dòng)化測(cè)試中，monkey是系統(tǒng)自帶的一款穩(wěn)定性和壓力測(cè)試工具。它可以隨機(jī)產(chǎn)生事件，不帶任何主觀性，并且使用方便。但是，正是由于這種隨機(jī)性，使得傳統(tǒng)的monkey測(cè)試只能作為穩(wěn)定性測(cè)試工具，在其上進(jìn)行功能擴(kuò)展較為不易。在monkey測(cè)試中，由于事件的隨機(jī)性，使得monkey容易卡在某些簡(jiǎn)單頁(yè)面，比如登陸頁(yè)面這種可操作內(nèi)容很少的頁(yè)面。針對(duì)這些問(wèn)題，我們基于Robotium自動(dòng)測(cè)試框架，開(kāi)發(fā)了SmartMonkey工具。SmartMonkey其本質(zhì)上是深度遍歷activity和操作節(jié)點(diǎn)的一個(gè)大型的robotium test case，它具有以下這些特點(diǎn)

16、：1 準(zhǔn)確識(shí)別頁(yè)面上的操作，避免無(wú)效點(diǎn)擊2 支持關(guān)鍵路徑配置，使測(cè)試范圍可控3 操作優(yōu)先級(jí)動(dòng)態(tài)變化，覆蓋更多功能和頁(yè)面4 多進(jìn)程基礎(chǔ)性能信息自動(dòng)采集5 支持Checklist配置，提供簡(jiǎn)單的功能驗(yàn)證6 結(jié)合性能專項(xiàng)工具，進(jìn)一步挖掘性能隱患在穩(wěn)定性測(cè)試過(guò)程中同步挖掘性能隱患是SmartMonkey工具的一個(gè)亮點(diǎn)，在接下來(lái)的3.性能測(cè)試章節(jié)會(huì)對(duì)SmartMonkey提供的性能專項(xiàng)工具做進(jìn)一步介紹。如何使用smartmonkey1 建立一個(gè)Android Test Project工程2 修改AndroidManifest.xml文件修改instrumentation TAG中的name和target

17、Package字段內(nèi)容如下。3 導(dǎo)入SmartMonkey所需的lib圖64 在測(cè)試工程的src文件中，新建JUnit Test Case 該類需繼承LynQ基礎(chǔ)類。圖75 在新建的Case中添加以下code其中LAUNCHER_ACTIVITY_FULL_CLASSNAME為被測(cè)APP的launcher activity，TARGET_PACKAGE為被測(cè)包的包名。private static final String LAUNCHER_ACTIVITY_FULL_CLASSNAME = com.example.android.apis.ApiDemos;private static fin

18、al String TARGET_PACKAGE = com.example.android.apis;public Test() throws ClassNotFoundExceptionsuper(TARGET_PACKAGE, Class.forName(LAUNCHER_ACTIVITY_FULL_CLASSNAME);/* * Smart monkey 示例 */public void test_sample() throws ClassNotFoundException mSolo.sleep(10000);mSolo.analysis();6 添加配置項(xiàng)在項(xiàng)目中新建assets文

19、件夾，添加AdvancedCperties和perties文件。在perties文件中添加配置項(xiàng)：# report path. MUST BE absolute path.mReportPath = /mnt/sdcard/lynq-report# login switch. value:true, false# true - automatic login when ENTER the LOGIN PAGE.# login page MUST be baidu pass. mLoginSwitch = true# username.

20、using in login functionmUsername = USERNAME# password. using in login functionmPassword = PASSWORD其中mReportPath是設(shè)置輸出報(bào)告的位置， 默認(rèn)為/mnt/sdcard/lynq-report/目錄，mLoginSwitch是自動(dòng)登錄開(kāi)關(guān)，當(dāng)前僅限baidu passport SDK自動(dòng)登錄。mUsername和mPassword分別為自動(dòng)登錄時(shí)輸入的用戶名和密碼。在AdvancedCperties文件中添加配置項(xiàng)：# time slot of performance c

21、ollector. unit: ms. value: intmTimeSlot = 10000# This is performance report type.value:int0,1 defualt is 0,report is html file. when value equels 1,the report is xml file.mPerformanceReportType = 0# sleep time. interval between two action. unit: ms. value: intmSleepTime = 1000# default text for edit

22、view. value: string# NEVER enter any: commenting this config item OR make it emptymDefaultText = default text IN smart monkey# text for special EditText. split by |, format: viewID1,content1|viewID2,content2# viewID: EditTexts id, content: text for this EditText mSpInputText = 1234,special text for

23、editText with id 1234|123,special text for editText with id 123# view never click. split by |mNeverClick = u9000u51FAu767Bu5F55|button_settings_logout# view must click. split by |mMustClick = positiveButton|u53D6u6D88# max operation running time. working in mode1 & mode2.# value: StringmMaxRunningTi

24、me = 08:00:00其中，mTimeSlot是性能數(shù)據(jù)采集的間隔，mPerformanceReportType是設(shè)置性能報(bào)告輸出樣式，1為xml樣式，0為html樣式。mSleepTime是兩次事件的執(zhí)行間隔，mDefaultText是默認(rèn)的SmartMonkey在EditText中輸入的內(nèi)容。mSpInputText中可以配置在某些輸入框中特殊輸入的內(nèi)容用豎線分割，比如，”1234,special text for editText with id 1234”，表示在id為1234的view中，輸入”special text for editText with id 1234”內(nèi)容。m

25、NeverClick和mMustClick用來(lái)表示關(guān)鍵路徑，分別為避免點(diǎn)擊的view和必點(diǎn)的view。View可以用文字或十進(jìn)制id或id string來(lái)表示。例如下圖中右下角OK按鈕，在R文件中是“public static final int btn_ok=0x7f09001d;”，所以，這個(gè)view可以用其上文字“OK”來(lái)表示，也可以用id string “btn_ok”或十進(jìn)制id“2131296285”來(lái)表示。圖8mMaxRunningTime是SmartMonkey的最大執(zhí)行時(shí)間，用時(shí)分秒來(lái)表示。7 執(zhí)行通過(guò)Run as Android Junit Test方式執(zhí)行。查看smart

26、monkey的輸出報(bào)告1 crash信息SmartMonkey會(huì)自動(dòng)記錄被測(cè)APP的crash棧信息，以及native crash信息。Crash信息會(huì)輸出在你配置的目錄中，以stack為開(kāi)頭的txt文件。每個(gè)crash單獨(dú)輸出一個(gè)文件。Native crash信息記錄在以dmp開(kāi)頭的文件中，可以通過(guò)google-breakpad進(jìn)行查看。2 基礎(chǔ)性能報(bào)告根據(jù)配置項(xiàng)，SmartMonkey會(huì)輸出性能報(bào)告到輸出報(bào)告目錄中。性能報(bào)告是以performance開(kāi)頭的html或xml文件。Html格式的性能報(bào)告中，首先會(huì)列出被測(cè)app的相關(guān)信息，包括包名、uid和同uid下的每一個(gè)進(jìn)程的pid和進(jìn)程名

27、等。隨后列出CPU、內(nèi)存、流量的圖表。CPU圖表中記錄了每一個(gè)進(jìn)程的CPU占用率，內(nèi)存圖表中記錄了每個(gè)進(jìn)程PSS和USS的占用情況，流量圖表中記錄了流量總使用情況和兩個(gè)采集點(diǎn)之間的流量差值。在每個(gè)圖表上，用node記錄了這個(gè)節(jié)點(diǎn)上SmartMonkey執(zhí)行的事件，可以用來(lái)輔助定位造成曲線波動(dòng)的操作。圖9圖10Xml格式的性能報(bào)告中，每個(gè)operation為一個(gè)采集點(diǎn)，其中記錄了時(shí)間戳、測(cè)試手機(jī)總CPU占用率、流量差值、流量總和、節(jié)點(diǎn)上的事件，以及每個(gè)進(jìn)程的pid、CPU占用率、PSS、USS等。3.2.2 可定制模塊級(jí)的內(nèi)核穩(wěn)定性工具無(wú)論原生monkey,還是智能優(yōu)化后的UI遍歷的smartm

28、onkey測(cè)試,都是一種系統(tǒng)集成級(jí)別的穩(wěn)定性測(cè)試, 下面介紹一種模塊級(jí)別的穩(wěn)定性測(cè)試方法。背景介紹穩(wěn)定性測(cè)試是移動(dòng)端產(chǎn)品專線測(cè)試中的重要一項(xiàng)測(cè)試，是移動(dòng)端產(chǎn)品保證穩(wěn)定性的重要手段，也是移動(dòng)端產(chǎn)品發(fā)版上線的一個(gè)重要質(zhì)量標(biāo)準(zhǔn)。Android系統(tǒng)一般使用系統(tǒng)自帶的monkey工具來(lái)做穩(wěn)定性測(cè)試。原生monkey工具是一種隨機(jī)UI事件流，用來(lái)測(cè)試長(zhǎng)時(shí)間隨機(jī)操作是否會(huì)導(dǎo)致應(yīng)用出現(xiàn)異常。因?yàn)樵鷐onkey操作的隨機(jī)性，所以在實(shí)際使用過(guò)程中，原生monkey會(huì)暴露出以下一些缺點(diǎn)：1) 原生monkey的測(cè)試對(duì)象是針對(duì)整個(gè)android系統(tǒng)或者某個(gè)應(yīng)用，但是無(wú)法針對(duì)應(yīng)用里的某個(gè)模塊或者界面。這樣在產(chǎn)品迭代過(guò)

29、程中存在的一個(gè)局限是：每個(gè)迭代時(shí)做的穩(wěn)定性測(cè)試都重新做一遍，而無(wú)法針對(duì)該迭代新增的功能模塊做單獨(dú)的穩(wěn)定性測(cè)試（或者叫做增量穩(wěn)定性測(cè)試）。以百度云這個(gè)應(yīng)用為例，在某個(gè)迭代中集成了“百度錢包”這個(gè)新模塊，使用原生的monkey工具可能出現(xiàn)的現(xiàn)象是大部分操作可能都落在了百度云的其他模塊，而沒(méi)有操作到“百度錢包”這個(gè)模塊。所以，我們期望的穩(wěn)定性測(cè)試能夠從系統(tǒng)和應(yīng)用級(jí)范圍轉(zhuǎn)移到模塊或者activity級(jí)別的范圍。圖112) 原生monkey工具的操作是隨機(jī)的，這樣可能導(dǎo)致一些用戶路徑操作不到或者操作時(shí)間過(guò)短；以百度直達(dá)號(hào)的支付業(yè)務(wù)為例，所有的支付操作必須是基于百度賬號(hào)登錄的前提下才能進(jìn)行，這樣在支付時(shí)就

30、必須經(jīng)歷登錄百度賬號(hào)這個(gè)用戶路徑。那么問(wèn)題來(lái)了，原生monkey因?yàn)槭请S機(jī)的，無(wú)法輸入指定的用戶名/密碼來(lái)登錄百度賬戶。實(shí)現(xiàn)業(yè)務(wù)化配置支持特定模塊或者Activity實(shí)現(xiàn)思路一般進(jìn)入一個(gè)模塊會(huì)有一個(gè)固定的入口，而退出這個(gè)模塊，也會(huì)退回到這個(gè)固定入口界面。在使用時(shí)，每次操作之后都去檢查當(dāng)前的界面是否為該界面，如果是，則去點(diǎn)擊這個(gè)入口控件，就回到了這個(gè)模塊，繼續(xù)測(cè)試；這樣即可保證穩(wěn)定性測(cè)試一直保持在這個(gè)模塊中進(jìn)行。 檢測(cè)到當(dāng)前界面為關(guān)注的activity時(shí)，通過(guò)與手機(jī)上的ViewServer通信，獲取該activiy的控件信息，得到指定的控件的坐標(biāo)信息；再對(duì)這個(gè)坐標(biāo)做一個(gè)點(diǎn)擊的操作，即回到了指定的

31、模塊界面。使用方法在執(zhí)行monkey命令時(shí)擴(kuò)展一個(gè)sa參數(shù)，參數(shù)格式是package/activity/item，通過(guò)該參數(shù)可指定入口界面元素；同時(shí)再擴(kuò)展一個(gè)ea參數(shù)，參數(shù)格式也是package/activity/item，通過(guò)該參數(shù)指定出口界面元素，當(dāng)碰到出口界面元素時(shí)再次主動(dòng)進(jìn)入入口界面配置業(yè)務(wù)操作及比例實(shí)現(xiàn)思路大家知道，執(zhí)行monkey命令時(shí)需要配置各個(gè)事件的比例，而該優(yōu)化點(diǎn)的思路就是將業(yè)務(wù)操作寫(xiě)成自動(dòng)化腳本，然后將該腳本抽象成一個(gè)monkey事件，并且可以配置執(zhí)行比例。使用方法在執(zhí)行monkey命令時(shí)擴(kuò)展一個(gè)m參數(shù)，參數(shù)格式是 腳本路徑 -pct-custom 業(yè)務(wù)比例例如，測(cè)試百度瀏

32、覽器時(shí)定期去打開(kāi)百度首頁(yè)：l 將腳本browser_test.sh push 到/data/local/tmp/目錄下(需要保證browser_test.sh有可執(zhí)行權(quán)限)l monkey命令參數(shù)配置 -m /data/local/tmp/browser_test.sh -pct-custom 5工具使用環(huán)境配置從以上介紹可知，原生monkey測(cè)試技術(shù)的改進(jìn)需要擴(kuò)展monkey命令參數(shù)，為了實(shí)現(xiàn)這點(diǎn)，需要對(duì)android官方自帶的monkey.jar包進(jìn)行源碼修改，然后重新編譯生成一個(gè)新的monkey jar包。下面的介紹是針對(duì)新monkey jar生成以后用戶的配置步驟，而對(duì)于android

33、各平臺(tái)的monkey jar的下載地址可參考附錄。a) 根據(jù)android平臺(tái)版本，將對(duì)應(yīng)平臺(tái)的monkey.jar push到/data/local/tmp/monkey.jarb) 生成以下可執(zhí)行文件/data/local/tmp/monkey# Script to start monkey on the device, which has a very rudimentary# shell.#base=/data/local/tmpexport CLASSPATH=$base/monkey.jartrap HUPexec app_process /system/bin mands.mon

34、key.Monkey $*c) 對(duì)data/local/tmp/monkey增加執(zhí)行權(quán)限d) 使用該擴(kuò)展功能的monkey 運(yùn)行命令類似：adb -d shell /data/local/tmp/monkey -s 0 -p packagename -throttle 2000 -pct-touch 15 -kill-process-after-error -pct-nav 25 -pct-majornav 15 -pct-appswitch 2 -pct-anyevent 16 -monitor-native-crashes -a package/activity/itemname/inde

35、x -v -v 100-a 參數(shù)即指定需要關(guān)注的activity，以及入口控件名稱，格式為：-a package/activity/itemname/index其中，package/activity可通過(guò)Hierarchy Viewer來(lái)查看，如下圖itemname也可通過(guò)Hierarchy Viewer來(lái)查看，如下圖圖12index是指這個(gè)item名稱在這個(gè)界面上出現(xiàn)的位置，使用hierarchyviewer從上面開(kāi)始數(shù)從左到右，從上到下。例如，關(guān)注的item名稱為TextView，需要從hierarchyviewer上看，從左到右，從上到下數(shù)所有出現(xiàn)的TextView，找到關(guān)注的TextV

36、iew的index。Index是一個(gè)可選字段，如果不填則默認(rèn)為0，index用于在同一個(gè)activity上有多個(gè)相同名稱的item時(shí)，指定特定的item。使用備注android出于安全考慮，當(dāng)系統(tǒng)屬性ro.secure=0 且ro.debuggable=1時(shí)才允許開(kāi)啟viewServer服務(wù)，所以只有滿足這個(gè)條件的手機(jī)才能使用本文所述的-a參數(shù)擴(kuò)展功能。如果需要更改系統(tǒng)屬性ro.secure=0 且ro.debuggable=1，可以通過(guò)先root手機(jī)，再修改boot.img的方法來(lái)實(shí)現(xiàn)。3.3性能測(cè)試一直以來(lái)，性能測(cè)試是被一部分人遺忘，又讓另一部分人無(wú)可奈何的東西。在絕大部分的創(chuàng)業(yè)公司，性能

37、測(cè)試基本上都是被遺忘的，他們認(rèn)為功能測(cè)試和穩(wěn)定性測(cè)試才是重點(diǎn)，而在中等規(guī)模的公司中一部分測(cè)試人員考慮進(jìn)行性能測(cè)試，卻無(wú)從下手。下面，從百度測(cè)試工程師的工作實(shí)踐出發(fā)，介紹移動(dòng)端性能測(cè)試的通用方法和結(jié)合產(chǎn)品特點(diǎn)的不同側(cè)重。3.3.1 百度瀏覽器性能測(cè)試本小節(jié)以百度瀏覽器為例介紹一下iOS平臺(tái)的性能測(cè)試實(shí)踐。 雖然iPhone的性能越來(lái)越好，但app的功能也越來(lái)越復(fù)雜，性能從來(lái)都是移動(dòng)開(kāi)發(fā)的核心關(guān)注點(diǎn)之一。我們說(shuō)一個(gè)app性能好，不是簡(jiǎn)單指感覺(jué)運(yùn)行速度快，而應(yīng)該是指應(yīng)用啟動(dòng)快速、UI反饋?lái)憫?yīng)及時(shí)、列表滾動(dòng)操作流暢、內(nèi)存使用合理，當(dāng)然更不能出現(xiàn)簡(jiǎn)單的crash了。那么iOS的性能測(cè)試是什么?資源消耗內(nèi)

38、存泄漏流量消耗耗電功率渲染效果加載時(shí)間。以下將結(jié)合百度瀏覽器iphone版從啟動(dòng)時(shí)間、加載時(shí)間、內(nèi)存占用、CPU和流暢度等維度介紹如何完成一個(gè)iOS app的性能測(cè)試。其中會(huì)用到Apple的性能分析神器”Instruments”。一、啟動(dòng)時(shí)間移動(dòng)應(yīng)用的啟動(dòng)時(shí)間是用戶體驗(yàn)的一個(gè)重要方面，蘋果一直建議盡可能的縮短啟動(dòng)時(shí)間，防止用戶不愿意使用它們。對(duì)于瀏覽器而言，由于程序啟動(dòng)時(shí)還會(huì)有教育頁(yè)和閃屏的下發(fā)，因此啟動(dòng)時(shí)間的獲取顯得尤為重要。啟動(dòng)時(shí)間分為冷啟動(dòng)時(shí)間和熱啟動(dòng)時(shí)間，所謂的“冷啟動(dòng)”，就是一個(gè)完全沒(méi)有運(yùn)行的應(yīng)用的啟動(dòng)時(shí)間，與熱啟動(dòng)（應(yīng)用已經(jīng)在后臺(tái)運(yùn)行，某個(gè)事件將其帶至前臺(tái)）相比，由于此時(shí)系統(tǒng)尚未建

39、立緩存，因此冷啟動(dòng)往往要較平時(shí)（熱啟動(dòng)）耗費(fèi)更長(zhǎng)的時(shí)間。要獲取準(zhǔn)確的app啟動(dòng)所需時(shí)間，最簡(jiǎn)單的就是通過(guò)性能打點(diǎn)的方法。首先在main.c中添加如下代碼：CFTimeInterval startTimeLog;int main(int argc, char *argv) startTimeLog = CACurrentMediaTime();然后在AppDelegate的回調(diào)方法application:didFinishLaunchingWithOptions中添加：dispatch_async(dispatch_get_main_queue(), CGFloat launchTime = C

40、ACurrentMediaTime() - startTimeLog;NSLog(launch: %f, launchTime););可能你會(huì)疑問(wèn)為什么這樣可以獲得系統(tǒng)啟動(dòng)的時(shí)間，因?yàn)檫@個(gè)dispatch_async中提交的工作會(huì)在app主線程啟動(dòng)后的下一個(gè)runloop中運(yùn)行，此時(shí)app已經(jīng)完成了載入并且將要顯示第一幀畫(huà)面，也就是系統(tǒng)會(huì)運(yùn)行到-UIApplication _reportAppLaunchFinished之前。下圖是用Instruments工具Time Profiler跑的調(diào)用棧信息。圖13所以使用Time Profiler同樣可以查看app的啟動(dòng)時(shí)間，具體方法如下：1. In

41、struments-Time Profiler2. Profiler你的app3. 切換到CPU strategy view，找到你的app啟動(dòng)的第一幀4. 搜索-UIApplication _reportAppLaunchFinished的最后一幀，即可算出啟動(dòng)時(shí)間（圖中為_(kāi)reportMainScreenUpdateFinished:） 為了拿到真實(shí)的用戶數(shù)據(jù)，追蹤版本之間的數(shù)據(jù)變化，目前瀏覽器線上版本中啟動(dòng)時(shí)間已作為性能埋點(diǎn)上傳，這樣我們就可以計(jì)算出每日不同機(jī)型不同OS的平均啟動(dòng)時(shí)間，以幫助更加實(shí)時(shí)有效的監(jiān)控線上的性能質(zhì)量數(shù)據(jù)。二、網(wǎng)頁(yè)加載時(shí)間據(jù)Google Analytics數(shù)據(jù)，目前

42、移動(dòng)網(wǎng)頁(yè)平均加載時(shí)間至少需要7秒，Google的目標(biāo)是把這個(gè)時(shí)間降至1秒，因?yàn)閰⒖糔ielsan Norman Group 的調(diào)查研究結(jié)果：如果移動(dòng)網(wǎng)頁(yè)加載時(shí)間超過(guò) 1 秒，用戶就不愿停留在頁(yè)面上了。在目前的技術(shù)基礎(chǔ)上，在幾百毫秒內(nèi)加載數(shù)個(gè)網(wǎng)頁(yè)幾乎是不可能實(shí)現(xiàn)的，但在1秒內(nèi)完成移動(dòng)網(wǎng)頁(yè)首頁(yè)內(nèi)容加載是有可能的，而剩余內(nèi)容則慢慢加載。因此網(wǎng)頁(yè)加載首屏展現(xiàn)時(shí)間成為了衡量手機(jī)瀏覽器的一個(gè)重要性能指標(biāo)，計(jì)算方法為從開(kāi)始加載網(wǎng)頁(yè)到首屏內(nèi)容全部展現(xiàn)所用的時(shí)間。網(wǎng)頁(yè)加載時(shí)間同樣可以基于打點(diǎn)的方法獲得。移動(dòng)網(wǎng)頁(yè)的加載都是從Webview的url請(qǐng)求開(kāi)始的，webview的操作都會(huì)有UIWebviewDelega

43、te的方法代理完成，因此通過(guò)對(duì)webview代理方法的研究（見(jiàn)下圖），選取正確的方法作為開(kāi)始時(shí)間和結(jié)束時(shí)間，即可獲取網(wǎng)頁(yè)的首屏加載展現(xiàn)時(shí)間和網(wǎng)頁(yè)加載完成時(shí)間。圖14對(duì)于競(jìng)品，我們則可以在越獄機(jī)型上通過(guò)動(dòng)態(tài)庫(kù)hook的方法進(jìn)行加載時(shí)間的計(jì)算，簡(jiǎn)單介紹如下：1. class-dump-z命令獲得應(yīng)用程序的類信息a) 導(dǎo)出設(shè)備上預(yù)裝應(yīng)用的類信息（/Applications）b) 導(dǎo)出從AppStore下載的app的類信息，需要clutch命令破解（/var/mobile/Applications）2. 用GDB或Cycript進(jìn)行運(yùn)行時(shí)分析（Cycript是一個(gè)理解Objective-C語(yǔ)法的jav

44、ascript解釋器），hook當(dāng)前運(yùn)行的進(jìn)程，打印當(dāng)前運(yùn)行的viewcontroller及對(duì)應(yīng)的方法名；3. 動(dòng)態(tài)庫(kù)注入，執(zhí)行method swizzling，在對(duì)應(yīng)的方法中打印時(shí)間日志關(guān)于如何使用運(yùn)行時(shí)分析及動(dòng)態(tài)庫(kù)注入，這里就不詳細(xì)說(shuō)明了。當(dāng)然，加載時(shí)間的查看也可以借助于Apple的性能分析神器Instruments。當(dāng)我們發(fā)現(xiàn)App有點(diǎn)卡的時(shí)候，就可以通過(guò)Time Profiler來(lái)查看耗時(shí)在哪里，如圖突出的范圍就是步驟消耗的時(shí)間。圖15在這里同時(shí)分享一個(gè)基于攝像+分析的快速進(jìn)行啟動(dòng)時(shí)間和加載時(shí)間計(jì)算的方法。當(dāng)前手機(jī)的攝像頭基本上都支持高FPS的拍攝，拍下來(lái)的MP4文件可以通過(guò)免費(fèi)的Av

45、idemux工具來(lái)看具體的幀信息，也可以看到幀的時(shí)間戳，根據(jù)拍攝的格式，目前我測(cè)試的視頻可以達(dá)到30毫秒級(jí)別，完全滿足性能測(cè)試的需求。三、內(nèi)存測(cè)試iOS系統(tǒng)中內(nèi)存限制是較為嚴(yán)格的，因此內(nèi)存優(yōu)化也就成了iOS app一直以來(lái)的難題。關(guān)于內(nèi)存測(cè)試的方法有很多，可以直接用Xcode真機(jī)Debug查看，也可以通過(guò)Instruments中內(nèi)存相關(guān)的模板Activity Monitor獲得。圖16 Xcode調(diào)試查看內(nèi)存圖17 Activity Monitor查看內(nèi)存在實(shí)際性能測(cè)試中，內(nèi)存測(cè)試往往會(huì)分場(chǎng)景進(jìn)行，通過(guò)腳本模擬用戶常用場(chǎng)景操作，分析該場(chǎng)景下的內(nèi)存占用情況。1. 指定run.js腳本測(cè)試$ in

46、struments -w $UDID -t $template $APP -e UIASCRIPT $script .input.log2. 解析ActivityMonitor模板的trace文件，生成對(duì)應(yīng)的json格式數(shù)據(jù)$ instruments_parser -p process_name -i result.trace其中一個(gè)json塊數(shù)據(jù)格式參照如下： Threads : 12, UnixSyscalls : 14314, Command : com.baidu. , VirtualSize : 718213120, ContextSwitches : 5774, Ports : 1

47、66, PageIns : 4881, Shared : 12976128, PPID : 1, CPUUsage : 0, UID : 501, TotalMicroSeconds : 307788, Timestamp : 1421818303.125269, VPrivate : 29028352, Date : 2015-01-21 13:31:43:125, MessagesSent : 4042, PID : 721, TotalSeconds : 1, Private : 9338880, PGID : 721, MachSyscalls : 7186, ResidentSize

48、 : 39362560, Architecture : 16777228, Faults : 19274, MessagesReceived : 1709 3. 統(tǒng)計(jì)ResidentSize、VirtualSize字段，使用python的matplotlib圖形庫(kù)生成內(nèi)存變化圖表。然而對(duì)于內(nèi)存測(cè)試，如果你覺(jué)得只是需要跟蹤app的內(nèi)存使用情況，那么你就錯(cuò)了。一套完整的內(nèi)存管理測(cè)試方案需要關(guān)注的點(diǎn)其實(shí)還有很多，比如使用Leaks分析內(nèi)存泄漏，使用Allocations分析內(nèi)存浪費(fèi)，使用Zombie分析野指針，使用VMTracker測(cè)試虛擬內(nèi)存，代碼中是否仍使用ARC機(jī)制等等。其中關(guān)于虛擬內(nèi)存的測(cè)試

49、或許是最容易被忽略的，瀏覽器就曾經(jīng)發(fā)現(xiàn)過(guò)實(shí)際內(nèi)存占用不高，但虛擬內(nèi)存上漲很快，從而導(dǎo)致app因?yàn)閮?nèi)存不足被系統(tǒng)kill的問(wèn)題。那么如何分析app的虛擬內(nèi)存呢？我們可以通過(guò)Instruments的VM Tracker進(jìn)行查看。VM Tracker主要用于記錄app的虛擬內(nèi)存分配，該模板會(huì)顯示app中分配了多大的虛擬內(nèi)存空間，其中多少是Dirty的內(nèi)存，有多少是被映射到實(shí)際物理內(nèi)存中，并且可以顯示詳細(xì)的虛擬內(nèi)存分配情況。圖18 VM Tracker查看虛擬內(nèi)存關(guān)于上圖中的dirty size，這里介紹一下dirty & clean的概念。在程序使用的內(nèi)存page中，iOS區(qū)分兩種內(nèi)存，一種為cle

50、an，一種為dirty。clean page的概念為所有可以被廢棄并且重新生成的page，例如二進(jìn)制代碼等從磁盤讀取的文件，例如未曾讀寫(xiě)過(guò)的page，或者被標(biāo)識(shí)為可擦除的內(nèi)存等。dirty page的概念為無(wú)法重新生成的page，即app生成的，并且已經(jīng)寫(xiě)入過(guò)的page，例如使用malloc分配的heap內(nèi)存，全局變量，stack內(nèi)存等。當(dāng)系統(tǒng)發(fā)現(xiàn)可用內(nèi)存較少時(shí)，會(huì)將resident中的clean page進(jìn)行清除，當(dāng)有需要使用時(shí)直接從磁盤讀取就行。系統(tǒng)不能卸載掉dirty memory，因?yàn)閕OS是沒(méi)有內(nèi)存置換機(jī)制的。當(dāng)dirty memory達(dá)到一個(gè)上限時(shí)，應(yīng)用會(huì)被kill，由系統(tǒng)回收內(nèi)存

51、。說(shuō)到上限，這里可能有人會(huì)問(wèn)，在iOS設(shè)備中打開(kāi)很多app后，打開(kāi)被測(cè)app，該app占用內(nèi)存的上限能達(dá)到多少呢？我們可以通過(guò)demo app，手動(dòng)malloc內(nèi)存，也可以通過(guò)instruments查看，觀察內(nèi)存警告時(shí)，App被kill時(shí)的日志輸出。下表列出了對(duì)各種設(shè)備進(jìn)行測(cè)試后得到的數(shù)值，供大家參考。圖19 不同設(shè)備內(nèi)存占用限制四、CPU測(cè)試CPU測(cè)試的方法和內(nèi)存較為類似，可以通過(guò)Instruments中的Activity Monitor模板查看，也可以通過(guò)客戶端打點(diǎn)的方法獲取。在瀏覽器性能測(cè)試中，重點(diǎn)模塊的CPU測(cè)試還需要針對(duì)不同機(jī)型不同Architecture指令集進(jìn)行兼容。例如在iPh

52、one瀏覽器播放內(nèi)核庫(kù)的測(cè)試中就需要兼容armv7、armv7s、arm64、i386、x86-64五種CPU上都經(jīng)過(guò)測(cè)試。在線播放&本地播放 MonkeyArmv7Armv7sArm64i386X86-64五、流暢度對(duì)于瀏覽器而言，會(huì)存在著較多網(wǎng)頁(yè)瀏覽、動(dòng)畫(huà)顯示等操作，這時(shí)是否存在卡頓對(duì)于用戶體驗(yàn)就顯得較為重要。關(guān)于流暢度的測(cè)試我們可以通過(guò)使用instruments的core animation工具，瀏覽網(wǎng)頁(yè)或加載動(dòng)畫(huà)，查看fps的幀數(shù)。一般而言，當(dāng)用戶操作時(shí)，如果fps幀數(shù)小于40，則說(shuō)明存在卡頓的情形。圖20 Core Animation查看fps幀數(shù)3.3.2 百度視頻性能隨著流量費(fèi)用

53、的降低，越來(lái)越多的人開(kāi)始在公交地鐵等移動(dòng)場(chǎng)景使用視頻應(yīng)用。視頻類的應(yīng)用會(huì)更多關(guān)注播放流暢度、下載等性能指標(biāo)，下面介紹的是百度視頻的性能測(cè)試方法。百度視頻是第三方視頻資源聚合類產(chǎn)品，主要提供用戶在線播放、離線下載各種視頻服務(wù)，提供pc、android、IOS三端入口，用戶體驗(yàn)、流暢度、下載速度、檢索視頻資源等是目前產(chǎn)品線最關(guān)注的層面。一款優(yōu)秀的娛樂(lè)類應(yīng)用，必須具有卓越的性能，超越同類競(jìng)品，同時(shí)兼具良好的用戶體驗(yàn)。app性能維度分析App類型眾多，根據(jù)具體類型劃分，性能指標(biāo)的維度和優(yōu)先級(jí)各不相同。視頻類app歸屬于娛樂(lè)游戲型的app，因此性能測(cè)試維度優(yōu)先級(jí)排序?yàn)椋毫鲿扯?、crash、內(nèi)存、流量、響

54、應(yīng)時(shí)長(zhǎng)、功耗、cpu。表征不同維度指標(biāo)的量化單位如圖21所示。比如流暢度是FPS（幀率），內(nèi)存是兆比等等。圖21 不同維度指標(biāo)的量化單位因?yàn)閍ndroid平臺(tái)底層是由linux系統(tǒng)改良而來(lái)，不同維度的指標(biāo)絕大部分都可以通過(guò)命令來(lái)取不同的指標(biāo)（具體方法可以參加后面工具）在ios平臺(tái)上，性能的獲取，必須使用Xcode里面instruments下的相應(yīng)組件，不像開(kāi)源的android那樣靈活，但技術(shù)上是可以做到各平臺(tái)的性能指標(biāo)獲取測(cè)試。app性能測(cè)試落地性能測(cè)試開(kāi)展主要分線下測(cè)試和線上性能監(jiān)控測(cè)試兩大類。線下app性能測(cè)試主要是傳統(tǒng)測(cè)試手段和方法，比如PM和QA發(fā)起做一個(gè)性能和競(jìng)品對(duì)比性能測(cè)試，或者版

55、本大改動(dòng)、框架遷移，都需要重新進(jìn)行app性能測(cè)試。線下測(cè)試我們可以用一些比較靠譜的平臺(tái)和工具就足以應(yīng)付，產(chǎn)品接入即可收集性能指標(biāo)。線上監(jiān)控測(cè)試主要是針對(duì)一些動(dòng)態(tài)變化的情況，因?yàn)閍pp測(cè)試非常關(guān)鍵的一點(diǎn)是場(chǎng)景化測(cè)試，即app必須在特定場(chǎng)合，特別條件才觸發(fā)某類問(wèn)題。這時(shí)候比較E2E場(chǎng)景case指標(biāo)功能，才能精準(zhǔn)衡量產(chǎn)品核心性能的能力。比如：我們?cè)诙€城市特定的網(wǎng)絡(luò)下，觀看某一部特定片源（百度愛(ài)奇藝視頻源），并且離線緩存，這時(shí)候用到了不同地域網(wǎng)絡(luò)，和調(diào)用了愛(ài)奇藝在那個(gè)城市的server。這是在北京家里沒(méi)法做到的場(chǎng)景，但可以借助vpn模擬異地場(chǎng)景測(cè)試。然而實(shí)際上效果并不良好，因?yàn)槟M取決于北京的網(wǎng)絡(luò)情況，還有vpn不能模擬動(dòng)態(tài)變化網(wǎng)絡(luò)切換的場(chǎng)景。針對(duì)線上性能的監(jiān)控，百度國(guó)際化團(tuán)隊(duì)還做了個(gè)場(chǎng)測(cè)助手，是一款方便收集性能，定位bug一體化的工具。在7.2章節(jié)會(huì)有詳細(xì)介紹。app性能指標(biāo)獲取手段Android系統(tǒng)指標(biāo)獲取l CpuCPU的測(cè)試方法分為幾類a.使用android提供的方法adbshell dumpsys cpuinfo |grep packagename /address/cpu.txt來(lái)獲取 b.使用top命令adbshell top |grep packagename/address/cpu.txt來(lái)獲取 l 內(nèi)存內(nèi)存消耗，這個(gè)測(cè)試節(jié)點(diǎn)