陳夢(mèng)珂 戴平

摘 要 近年來，App發(fā)展已進(jìn)入競(jìng)爭(zhēng)日趨激烈階段，由最初級(jí)的簡(jiǎn)易型應(yīng)用程序發(fā)展到現(xiàn)在復(fù)雜多樣化。目前App開發(fā)大多采用迭代開發(fā)模式，版本更新速度快，測(cè)試周期短，測(cè)試工作難。文章從測(cè)試流程方面進(jìn)行闡述移動(dòng)App測(cè)試過程及主要測(cè)試活動(dòng)。

關(guān)鍵字 移動(dòng)App 測(cè)試流程 探索測(cè)試

中圖分類號(hào) TP3 文獻(xiàn)標(biāo)識(shí)碼 A 文章編號(hào) 1674-6708（2018）209-0145-02

隨著科技的進(jìn)一步發(fā)展，智能手機(jī)已經(jīng)成為個(gè)人通信、網(wǎng)絡(luò)、生產(chǎn)力和企業(yè)盈利的新標(biāo)準(zhǔn)和必備產(chǎn)品。如果一款新研發(fā)的產(chǎn)品不經(jīng)過測(cè)試就急于上市，不僅是發(fā)生信息安全問題，就連相對(duì)而言較輕的閃退、卡死卡頓、黑屏白屏等兼容性問題，給產(chǎn)品帶來的影響也是極大的。因此測(cè)試的工作在App運(yùn)營(yíng)過程中必須得到進(jìn)一步的重視。文通過文獻(xiàn)分析法及多年App測(cè)試工作經(jīng)驗(yàn)，對(duì)實(shí)際工作中移動(dòng)App的測(cè)試流程工作進(jìn)行梳理和總結(jié)如下。

1 App測(cè)試流程

手機(jī)上的App分為基于HTML5的App（類似于b/S架構(gòu)）和本地App（類似于C/S架構(gòu)）所以測(cè)試上我們也可以充分吸收Web的b/s和c/s測(cè)試經(jīng)驗(yàn)。但是不同于PC上的應(yīng)用測(cè)試，手機(jī)上的測(cè)試有其獨(dú)特性。常見的移動(dòng)App測(cè)試流程如圖1。

1.1 測(cè)試計(jì)劃制訂

測(cè)試計(jì)劃階段處于測(cè)試的先期準(zhǔn)備工作階段，在該階段中主要對(duì)測(cè)試工作做出整體計(jì)劃安排，在此之前需要進(jìn)行需求分析，對(duì)產(chǎn)品需求規(guī)格進(jìn)行需求測(cè)試，將要測(cè)試的產(chǎn)品分解成可獨(dú)立測(cè)試的單元，為每個(gè)測(cè)試單元確定采用的測(cè)試技術(shù)。然后明確測(cè)試目的，設(shè)定測(cè)試范圍、安排測(cè)試進(jìn)度、制定測(cè)試策略，準(zhǔn)備測(cè)試資源、預(yù)測(cè)項(xiàng)目風(fēng)險(xiǎn)等。在制定項(xiàng)目計(jì)劃時(shí)，應(yīng)參照項(xiàng)目交付的進(jìn)度，客觀分析個(gè)模塊的工作量，以保證計(jì)劃質(zhì)量。該階段的產(chǎn)物是《測(cè)試計(jì)劃》文檔一般由測(cè)試經(jīng)理完成，文檔經(jīng)過項(xiàng)目組成員評(píng)審后定稿，作為測(cè)試工作開展的指導(dǎo)綱領(lǐng)，也是評(píng)估測(cè)試工作成果的主要依據(jù)。

1.2 測(cè)試設(shè)計(jì)階段

測(cè)試設(shè)計(jì)階段主要工作是把用戶需求轉(zhuǎn)化成測(cè)試需求，并通過黑盒測(cè)試方法如等價(jià)類邊界值、因果圖判定表、場(chǎng)景法、錯(cuò)誤推斷法等，設(shè)計(jì)詳細(xì)測(cè)試策略，確定測(cè)試類型，App常見測(cè)試類型包括：功能測(cè)試、安裝卸載測(cè)試、兼容測(cè)試、性能測(cè)試等，每一種測(cè)試類型都需要制定詳細(xì)測(cè)試策略及準(zhǔn)備測(cè)試工具和測(cè)試資源，最后編寫測(cè)試框架或者測(cè)試用例。

由于App開發(fā)周期短，版本迭代快，一般采用測(cè)試思維導(dǎo)圖或feature lis形式羅列測(cè)試點(diǎn)，詳細(xì)地描述每個(gè)單元的測(cè)試方法。測(cè)試設(shè)計(jì)階段是測(cè)試工作的靈魂，需要對(duì)該階段產(chǎn)物測(cè)試用例進(jìn)行詳細(xì)評(píng)審，評(píng)審維度包括：用例描述是否清晰，內(nèi)容是否完整，是否包含用例各個(gè)要素（輸入輸出），是否覆蓋需求中所有場(chǎng)景，邏輯分支及限定條件等，是否考慮到測(cè)試用例的執(zhí)行效率及可執(zhí)行率等；測(cè)試用例在項(xiàng)目組評(píng)審?fù)ㄟ^后才能進(jìn)行測(cè)試實(shí)施工作。測(cè)試用例是測(cè)試執(zhí)行的依據(jù)。測(cè)試用例一般由測(cè)試組長(zhǎng)編寫，并分配給測(cè)試組員進(jìn)行測(cè)試執(zhí)行工作。

1.3 測(cè)試執(zhí)行階段

在App的整個(gè)生命周期中，不同的階段對(duì)Bug有效性的定義完全不同，找到App有效Bug的手段有很多種，基于產(chǎn)品設(shè)計(jì)文檔進(jìn)行功能用例編寫，然后進(jìn)行逐一驗(yàn)證，是最系統(tǒng)有效的方式。它可以精準(zhǔn)地發(fā)現(xiàn)App在核心業(yè)務(wù)上存在的缺陷。測(cè)試執(zhí)行階段，主要活動(dòng)有，準(zhǔn)備并確認(rèn)測(cè)試環(huán)境，構(gòu)建和冒煙測(cè)試、實(shí)施測(cè)試，缺陷跟蹤，每日匯報(bào)測(cè)試結(jié)果。

和傳統(tǒng)的軟件測(cè)試類似，我們可以把App的測(cè)試實(shí)施行分為：冒煙測(cè)試，專項(xiàng)測(cè)試，Bug探索測(cè)試，回歸測(cè)試。

1.3.1 冒煙測(cè)試

冒煙測(cè)試是版本構(gòu)建完成后的第一步，冒煙測(cè)試也稱基本功能測(cè)試，主要驗(yàn)證App基本流程是否完整，基本功能是否實(shí)現(xiàn)（如基本注冊(cè)登錄退出功能），是否存在嚴(yán)重程度為致命的Bug。冒煙測(cè)試成功才能繼續(xù)開展測(cè)試工作，如果冒煙測(cè)試失敗，需要開發(fā)人員緊急修復(fù)重新構(gòu)建版本。

1.3.2 專項(xiàng)測(cè)試

專項(xiàng)測(cè)試建立在冒煙測(cè)試成功之后，依據(jù)測(cè)試計(jì)劃和測(cè)試用例全面的進(jìn)行功能及非功能測(cè)試。功能測(cè)試一般采用黑盒測(cè)試方法，運(yùn)行App，檢查實(shí)際運(yùn)行結(jié)果和預(yù)期結(jié)果是否一致，可以采用手工測(cè)試和自動(dòng)化測(cè)試，根據(jù)項(xiàng)目組的人力資源合理安排，目前主流的自動(dòng)化測(cè)試工具也比較多，現(xiàn)如Robotium、MonkeyRunner、Appium等。根據(jù)開發(fā)策略和結(jié)構(gòu)，找出最適合他們環(huán)境的自動(dòng)化工具。

非功能測(cè)試包括傳統(tǒng)的性能測(cè)試、兼容性測(cè)試、安全性測(cè)試、安裝卸載測(cè)試，App特有測(cè)試有：交叉事件測(cè)試、前后臺(tái)切換測(cè)試、PUSH測(cè)試、硬件環(huán)境測(cè)試等。

1.3.3 Bug探索測(cè)試

Bug探索式測(cè)試，目前最流行的是以眾測(cè)模式，跳開“用例測(cè)試”對(duì)測(cè)試路徑的規(guī)劃和結(jié)果的預(yù)期，尋找更多隨機(jī)甚至是小概率的可能性。相對(duì)于標(biāo)準(zhǔn)測(cè)試，Bug探索更需要的是“打破常規(guī)”，模擬真實(shí)用戶角度，結(jié)合團(tuán)隊(duì)測(cè)試經(jīng)驗(yàn)，最大限度探索用戶使用習(xí)慣和路徑，探索復(fù)雜操作流程；真實(shí)模擬異常應(yīng)用場(chǎng)景及系統(tǒng)特有功能，確保主要功能使用流暢，避免影響用戶體驗(yàn)的問題，發(fā)現(xiàn)研發(fā)人員不易發(fā)覺的Bug。采用等價(jià)類測(cè)試方法、邊界值測(cè)試方法、錯(cuò)誤推測(cè)法、取消測(cè)試方法、逆向測(cè)試方法、錯(cuò)序測(cè)試法等測(cè)試方法。一般探索測(cè)試開展是在專項(xiàng)測(cè)試之后，發(fā)布眾測(cè)平臺(tái)，或者直接在公司內(nèi)測(cè)，收集更加全面的測(cè)試反饋，達(dá)到更好的易用性體驗(yàn)測(cè)試效果。

1.3.4 回歸測(cè)試

由于Bug的集群效應(yīng)，一般情況下，開發(fā)人員每修復(fù)一個(gè)Bug，就會(huì)產(chǎn)生3～4個(gè)新Bug，發(fā)現(xiàn)Bug越多的模塊，其隱藏的Bug也越多。所以在每次版本更新的時(shí)候，都要進(jìn)行一輪回歸測(cè)試，保障所有的Bug都已經(jīng)修復(fù)，并且沒有產(chǎn)生新的Bug。在版本迭代周期中，回歸測(cè)試至少執(zhí)行2輪以上，一般采取自動(dòng)化工具或者腳本進(jìn)行回歸。

1.3.5 上線測(cè)試

App在經(jīng)過幾輪回歸測(cè)試之后，如果沒有新的Bug產(chǎn)生，并且用戶體驗(yàn)測(cè)試反饋較好，就可以考慮上線準(zhǔn)備了，上線測(cè)試是指發(fā)布上線后，對(duì)整個(gè)項(xiàng)目再次進(jìn)行一次完整的系統(tǒng)測(cè)試。需要檢查產(chǎn)品框架，每個(gè)模塊的功能是否有缺失或錯(cuò)誤，用戶核心場(chǎng)景是否有邏輯問題等，驗(yàn)收產(chǎn)品交互、驗(yàn)收視覺樣式等。App上線之后需要測(cè)試人員繼續(xù)跟蹤，及時(shí)收集用戶使用反饋，不斷定位Bug，由開發(fā)人員進(jìn)行優(yōu)化升級(jí)。

1.4 測(cè)試評(píng)估階段

測(cè)試評(píng)估階段的目標(biāo)是正確評(píng)估App產(chǎn)品的質(zhì)量，確定App產(chǎn)品是否達(dá)到發(fā)布標(biāo)準(zhǔn)，并形成測(cè)試報(bào)告，參與發(fā)布工作。

測(cè)試評(píng)估階段的測(cè)試報(bào)告包括：每日測(cè)試報(bào)告、版本測(cè)試報(bào)告，階段測(cè)試報(bào)告及上線測(cè)試報(bào)告等。測(cè)試評(píng)估貫穿整個(gè)測(cè)試周期，在測(cè)試執(zhí)行結(jié)束后需要及時(shí)提交測(cè)試結(jié)果，通過測(cè)試用例執(zhí)行情況、測(cè)試點(diǎn)覆蓋情況Bug優(yōu)先級(jí)分布圖，Bug數(shù)量趨勢(shì)圖、缺陷模塊圖等維度，對(duì)當(dāng)前測(cè)試版本進(jìn)行綜合評(píng)價(jià)。測(cè)試報(bào)告需要說明清楚測(cè)試覆蓋的情況，對(duì)產(chǎn)品質(zhì)量要進(jìn)行全面的評(píng)估，數(shù)據(jù)要量化，說明遺漏缺陷對(duì)系統(tǒng)質(zhì)量的影響，表明對(duì)發(fā)布的認(rèn)可或拒絕，并提出后續(xù)改進(jìn)的建議等。

到此整個(gè)移動(dòng)App測(cè)試工具基本結(jié)束，后續(xù)的版本升級(jí)和維護(hù)工作依然延續(xù)此測(cè)試流程。

2 結(jié)論

移動(dòng)App市場(chǎng)在蓬勃發(fā)展的同時(shí)，用戶對(duì)App的期望也越來越高，對(duì)產(chǎn)品的質(zhì)量要求也越來越高，目前App應(yīng)用市場(chǎng)良莠不齊，許多App都存在各種安全漏洞和內(nèi)測(cè)泄露，這對(duì)App測(cè)試技術(shù)的要求也越來越高。App測(cè)試未來的發(fā)展應(yīng)該以最省成本投入，最專業(yè)測(cè)試分析方法，最敏捷的測(cè)試流程，全方面模擬不同場(chǎng)景去探索、運(yùn)行程序以保證程序質(zhì)量。

參考文獻(xiàn)

[1]中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心.中國(guó)互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告[EB/OL].[2017-1].http：//www.cnnic.net.cn/ hlwfzyj/hlwxzbg/hl‐wtjbg/201701/P0201701233646 72657408.pdf.

[2]葉強(qiáng).基于無(wú)縫移動(dòng)引擎（SME）的手機(jī)自動(dòng)測(cè)試接口技術(shù)的研究與實(shí)現(xiàn)[D].北京：北京交通大學(xué)，2007.

[3]盧建軍，蘇寧.淺談收集軟件測(cè)試流程與策略[J].制造業(yè)自動(dòng)化，2010（12）：21-23.