盧建軍，蘇 寧

LU Jian-jun1, SU Ning2

（1.西安郵電學(xué)院 通信學(xué)院，西安 710061；2.西安科技大學(xué) 通信學(xué)院，西安 710054）

0 引 言

隨著科技的進(jìn)步，手機(jī)與我們的關(guān)系已經(jīng)到了密不可分的地步，手機(jī)扮演著通訊工具、多媒體、網(wǎng)絡(luò)等多方面的角色。同時(shí)，用戶對(duì)手機(jī)軟件的質(zhì)量、性能也提出了更高的要求。在商業(yè)模式的驅(qū)動(dòng)下，手機(jī)的開(kāi)發(fā)周期不斷的縮短，更要確保手機(jī)軟件質(zhì)量。產(chǎn)品的軟件質(zhì)量與手機(jī)廠商的切身利益、市場(chǎng)競(jìng)爭(zhēng)力和信譽(yù)度息息相關(guān)[1]。目前我國(guó)的手機(jī)軟件測(cè)試的發(fā)展還處于剛剛起步的階段。國(guó)內(nèi)的手機(jī)廠商對(duì)手機(jī)軟件測(cè)試的理解不夠，在軟件測(cè)試上投入的精力不夠，因此不能制定出詳盡的手機(jī)軟件測(cè)試流程及測(cè)試策略來(lái)完成手機(jī)的軟件測(cè)試工作。本文針對(duì)這一現(xiàn)象結(jié)合作者的實(shí)際工作經(jīng)驗(yàn)，對(duì)手機(jī)軟件測(cè)試的流程和策略進(jìn)行的初步的探討。

1 手機(jī)軟件測(cè)試流程

1.1 手機(jī)軟件測(cè)試是迭代的過(guò)程

手機(jī)軟件測(cè)試是一個(gè)迭代的循環(huán)往復(fù)的過(guò)程。事實(shí)證明，測(cè)試工作的早期介入，可提早發(fā)現(xiàn)錯(cuò)誤，避免不必要的生產(chǎn)花費(fèi)和資源投入，因此手機(jī)軟件測(cè)試將會(huì)從開(kāi)發(fā)初期開(kāi)始伴隨整個(gè)手機(jī)軟件開(kāi)發(fā)的生命周期。手機(jī)軟件開(kāi)發(fā)采用的是面向?qū)ο蟮拈_(kāi)發(fā)方法，它的生命周期模型是迭代生命周期模型（Iterative Lifecycle Model）。

1.2 一個(gè)循環(huán)迭代

1.2.1 需求分析階段

測(cè)試人員與設(shè)計(jì)人員一起參加需求調(diào)研，編寫(xiě)軟件質(zhì)量需求，制定測(cè)試計(jì)劃，盡早發(fā)現(xiàn)軟件設(shè)計(jì)上存在的缺陷和任務(wù)書(shū)上不合邏輯的地方。

1.2.2 設(shè)計(jì)階段

與設(shè)計(jì)人員一起參加軟件結(jié)構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)，熟悉設(shè)計(jì)方案，制定測(cè)試方案。

1.2.3 實(shí)現(xiàn)階段

即是軟件編碼與單元模塊測(cè)試階段，對(duì)于手機(jī)測(cè)試而言，每個(gè)功能模塊即是軟件測(cè)試的最小單位劃分，測(cè)試人員編寫(xiě)測(cè)試用例對(duì)某一功能模塊進(jìn)行測(cè)試。

1.2.4 回顧階段

開(kāi)發(fā)人員同測(cè)試人員一起對(duì)該階段軟件進(jìn)行評(píng)估，回顧軟件需求、改變或增加新的需求說(shuō)明。自此，一個(gè)開(kāi)發(fā)測(cè)試迭代完成[2]。

1.3 循環(huán)迭代至系統(tǒng)穩(wěn)定

在完成兩到三個(gè)模塊的迭代及單元測(cè)試以后，將開(kāi)始集成測(cè)試。把各模塊集成在一起時(shí)，測(cè)試它們是否正常運(yùn)行。集成測(cè)試介于單元測(cè)試和系統(tǒng)測(cè)試之間，起到“橋梁作用”[3]。迭代次數(shù)增加，軟件逐步成熟的時(shí)候，測(cè)試將轉(zhuǎn)入系統(tǒng)測(cè)試。系統(tǒng)測(cè)試一般由獨(dú)立測(cè)試人員執(zhí)行，通常采用黑盒測(cè)試方式。粒度最大，主要測(cè)試系統(tǒng)是否符合“需求規(guī)格說(shuō)明書(shū)”[4]。循環(huán)到當(dāng)在一段時(shí)間內(nèi)測(cè)試出來(lái)的缺陷穩(wěn)定維持在一個(gè)較少的水平線上，且出現(xiàn)的問(wèn)題足以忽略時(shí)，可認(rèn)為系統(tǒng)已初步穩(wěn)定，即交付驗(yàn)收測(cè)試[5]。

2 手機(jī)軟件測(cè)試策略

2.1 測(cè)試用例設(shè)計(jì)、測(cè)試策略

在測(cè)試一款產(chǎn)品的時(shí)候編寫(xiě)的測(cè)試用例要緊扣需求上描述的基本功能，少量的涉及到使用頻率較高的功能交互，不涉及界面布局等GUI元素。這樣做的好處是測(cè)試用例沒(méi)有跟某一款產(chǎn)品的關(guān)聯(lián)太緊，支持在同一個(gè)系統(tǒng)平臺(tái)衍生出不同的很多款手機(jī)，完成同一系列的用例可以完全或部分復(fù)用于整個(gè)平臺(tái)的其他產(chǎn)品，從而減少勞動(dòng)力，縮短開(kāi)發(fā)周期，降低商業(yè)成本[6]。當(dāng)然，不同的硬件產(chǎn)品一定要有不同的測(cè)試側(cè)重點(diǎn)，由于硬件不同引起的問(wèn)題不同的例子也不在少數(shù)。

設(shè)計(jì)的所有用例將形成一個(gè)測(cè)試用例庫(kù)，在每個(gè)迭代開(kāi)始的時(shí)候，測(cè)試組長(zhǎng)都會(huì)選取一部分用例組成測(cè)試用例集進(jìn)行測(cè)試，選取的用例通常分兩部分：一部分是基本功能的用例，保證這次迭代的軟件能夠?qū)崿F(xiàn)最基本的功能；還有一部分是上次迭代時(shí)發(fā)現(xiàn)錯(cuò)誤比較多的模塊，在開(kāi)發(fā)人員修改以后做一次比較集中的回歸測(cè)試。

2.2 交互測(cè)試策略

手機(jī)軟件是一個(gè)比較復(fù)雜的系統(tǒng)，僅僅靠測(cè)試用例里針對(duì)基本功能的測(cè)試是遠(yuǎn)遠(yuǎn)不夠的，用戶經(jīng)常會(huì)在不知情或有需要的情況下打開(kāi)很多個(gè)應(yīng)用程序，或正在運(yùn)行某個(gè)應(yīng)用程序的時(shí)候有其他的手機(jī)跟他進(jìn)行交互，這就產(chǎn)生了交互測(cè)試。這部分測(cè)試主要是通過(guò)測(cè)試人員常年積累的測(cè)試經(jīng)驗(yàn)和對(duì)錯(cuò)誤的敏感度來(lái)發(fā)現(xiàn)錯(cuò)誤的。

2.3 錯(cuò)誤報(bào)告、追蹤策略

在測(cè)試中發(fā)現(xiàn)問(wèn)題固然重要，但是在發(fā)現(xiàn)之后編寫(xiě)錯(cuò)誤報(bào)告同樣不可忽視。一個(gè)好的錯(cuò)誤報(bào)告可以引導(dǎo)開(kāi)發(fā)人員找到問(wèn)題根源，及時(shí)解決問(wèn)題。編寫(xiě)錯(cuò)誤報(bào)告時(shí)一定要做到客觀，真實(shí)，詳細(xì)。詳細(xì)描述問(wèn)題發(fā)生的環(huán)境，步驟，版本，重現(xiàn)率，等等，并且只做到客觀的描述問(wèn)題現(xiàn)象，不做任何沒(méi)有根據(jù)的猜測(cè)，以免誤導(dǎo)開(kāi)發(fā)人員。在有能力的情況下，提供錯(cuò)誤記錄，協(xié)助開(kāi)發(fā)人員重現(xiàn)問(wèn)題，確定問(wèn)題本質(zhì)。

報(bào)告錯(cuò)誤以后要定期追蹤所報(bào)錯(cuò)誤狀態(tài)，與開(kāi)發(fā)人員溝通，確定錯(cuò)誤修改進(jìn)程。若錯(cuò)誤修正，及時(shí)在新版本上對(duì)錯(cuò)誤進(jìn)行回歸測(cè)試。

2.4 灰盒測(cè)試策略

在白盒測(cè)試中交叉使用黑盒測(cè)試，在黑盒測(cè)試中交叉使用白盒測(cè)試的方法稱為灰盒測(cè)試?；液袦y(cè)試就是介于白盒測(cè)試和黑盒測(cè)試之間的測(cè)試，最常見(jiàn)的灰盒測(cè)試是集成測(cè)試[7]。測(cè)試人員可以在既通過(guò)用戶界面測(cè)試又了解軟件功能的源代碼程序怎樣設(shè)計(jì)的情況下，有的放矢的進(jìn)行某種確定的條件/功能測(cè)試[8,9]。

2.5 臨界測(cè)試策略

當(dāng)手機(jī)的某些可用資源達(dá)到或者超過(guò)理論允許的極大值時(shí)，在手機(jī)上繼續(xù)進(jìn)行某種操作時(shí)候的測(cè)試，此時(shí)手機(jī)的行為應(yīng)該是友好的，可被用戶接受的。

2.6 自動(dòng)化測(cè)試策略

手機(jī)功能眾多，回歸測(cè)試工作量大，且測(cè)試中常碰到很多重復(fù)性高的工作，手動(dòng)執(zhí)行的話費(fèi)時(shí)費(fèi)力，也容易讓測(cè)試人員產(chǎn)生疲倦甚至是厭倦心理，很容易造成測(cè)試的遺漏。如果能有一套自動(dòng)執(zhí)行的機(jī)制，將能大大提高測(cè)試的效率。

2.7 性能測(cè)試策略

性能測(cè)試主要測(cè)試手機(jī)的反應(yīng)速度是否達(dá)到標(biāo)準(zhǔn)。它通過(guò)計(jì)算手機(jī)在完成一個(gè)操作所用的時(shí)間來(lái)衡量[10]。

3 手機(jī)軟件自動(dòng)化測(cè)試應(yīng)用舉例

3.1 自動(dòng)化測(cè)試工具簡(jiǎn)介

手機(jī)軟件自動(dòng)化測(cè)試工具Brat是一個(gè)手機(jī)自動(dòng)化測(cè)試的平臺(tái)，它通過(guò)手機(jī)驅(qū)動(dòng)端口連接手機(jī)與PC，由Tcl腳本語(yǔ)言搭載其中，完成測(cè)試化腳本的開(kāi)發(fā)。Brat具有腳本可視化顯示、控制腳本循環(huán)操作批量操作、判斷測(cè)試用例是否通過(guò)和產(chǎn)生運(yùn)行日志的功能。

3.2 例子

3.2.1 測(cè)試用例的編寫(xiě)、執(zhí)行

如表1測(cè)試用例。

表1 測(cè)試用例

3.2.2 測(cè)試結(jié)果

Brat運(yùn)行完發(fā)送短信500遍以后的結(jié)果如圖1所示，可見(jiàn)測(cè)試Pass。Brat還可提供運(yùn)行的日志記錄，以便在運(yùn)行Fail的時(shí)候查找問(wèn)題原因。

圖1 自動(dòng)化用例執(zhí)行結(jié)果

4 結(jié)論

本文通過(guò)對(duì)在實(shí)際工作中總結(jié)的手機(jī)軟件測(cè)試的流程和策略的探討，給予我國(guó)手機(jī)軟件測(cè)試流程和策略一定的參考，說(shuō)明了規(guī)范流程和拓展策略的重要性。并采用自動(dòng)化測(cè)試方法進(jìn)行了實(shí)測(cè)應(yīng)用，實(shí)踐證明基于自動(dòng)化測(cè)試工具的平臺(tái)，搭載開(kāi)發(fā)的測(cè)試腳本，并結(jié)合一定的測(cè)試經(jīng)驗(yàn)進(jìn)行的自動(dòng)化測(cè)試，完全可以達(dá)到軟件壓力測(cè)試標(biāo)準(zhǔn)，保證壓力測(cè)試質(zhì)量，縮短測(cè)試周期，提高測(cè)試效率。

[1] 秦?zé)?康偉,韓佳.淺談黑盒測(cè)試技術(shù)在手機(jī)軟件測(cè)試中的應(yīng)用[J].今日科苑, 2008.

[2] 趙會(huì)群.通信軟件測(cè)試技術(shù)基礎(chǔ)[M].人民郵電出版社,2004.

[3] 豐彥.軟件測(cè)試的系統(tǒng)測(cè)試方法[J].引進(jìn)與咨詢,2005.

[4] Grenford J.Myers The Art of Software Testing[M].機(jī)械工業(yè)出版社,2005.

[5] 林寧,孟慶余.軟件測(cè)試實(shí)用指南[M].清華大學(xué)出版社,2004.

[6] 劉海鵬.手機(jī)軟件測(cè)試簡(jiǎn)介[J].科技咨詢導(dǎo)報(bào),2007.

[7] 古樂(lè),史九林.軟件測(cè)試技術(shù)概論[M].清華大學(xué)出版社,2004.

[8] 路金良.手機(jī)軟件開(kāi)發(fā)的質(zhì)量控制[J].中國(guó)科技信息,2009.

[9] 葉振宇.智能手機(jī)軟件開(kāi)發(fā)中的質(zhì)量控制策略[J].紹興文理學(xué)院學(xué)報(bào),2005.

[10] William E.Perry Effective Methods for Software Testing[M].清華大學(xué)出版社,2008.