淺談手機(jī)軟件測試的流程與策略

黃平鳳

摘要：隨著技術(shù)的進(jìn)步和手機(jī)的普及，人們對移動(dòng)軟件的性能和質(zhì)量要求越來越高，這使得移動(dòng)軟件的測試變得更加重要。本文介紹了手機(jī)軟件測試具體過程的發(fā)展現(xiàn)狀，結(jié)合國內(nèi)手機(jī)軟件測試實(shí)際工作，作者以從事手機(jī)軟件測試的經(jīng)驗(yàn)，給出了手機(jī)軟件測試策略的一系列不同策略，最后以手機(jī)軟件自動(dòng)化測試為例進(jìn)行說明。介紹了測試自動(dòng)化工具，論證使用自動(dòng)化測試工具的測試用例將大大提高測試效率并縮短測試周期。

關(guān)鍵詞：手機(jī)；軟件測試；流程；策略

前言：

隨著技術(shù)的進(jìn)步，手機(jī)與我們之間的關(guān)系變得密不可分。手機(jī)起著通信工具，多媒體，網(wǎng)絡(luò)等方面的作用。同時(shí)，用戶對手機(jī)的質(zhì)量和性能提出了更高的要求。在商業(yè)模式的驅(qū)動(dòng)下，手機(jī)的開發(fā)周期不斷縮短，手機(jī)軟件的質(zhì)量也需要得到應(yīng)有的保障。軟件質(zhì)量與手機(jī)制造商的重要利益及市場競爭力和聲譽(yù)密切相關(guān)。在此基礎(chǔ)上，結(jié)合作者的實(shí)際工作經(jīng)驗(yàn)，研究了軟件測試的過程和策略。

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

1.1手機(jī)軟件測試

迭代過程移動(dòng)軟件測試是一個(gè)迭代和循環(huán)的過程。事實(shí)證明，早期參與全面測試可以更早發(fā)現(xiàn)錯(cuò)誤，避免不必要的生產(chǎn)成本和資源浪費(fèi)。因此，移動(dòng)軟件測試將從移動(dòng)軟件開發(fā)的整個(gè)生命周期的起點(diǎn)開始。移動(dòng)軟件開發(fā)采用面向?qū)ο蟮拈_發(fā)方法，其生命周期模型是迭代生命周期模型。

1.2 循環(huán)迭代流程

1.2.1 需求分析階段

測試人員和設(shè)計(jì)人員盡早參與需求分析，編寫軟件質(zhì)量要求，制定測試計(jì)劃，并確定任務(wù)手冊中的軟件設(shè)計(jì)缺陷和不合邏輯的部分。

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

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

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

它是軟件編碼和單元模塊的測試階段。對于手機(jī)測試，每個(gè)功能模塊是最小的軟件測試單元。

1.2.4 回顧階段

開發(fā)人員與測試人員需要一起評估軟件，審查軟件需求，在此階段更改或添加新需求。從那時(shí)起，開發(fā)測試迭代已經(jīng)完成。

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

完成2到3個(gè)模塊的迭代和單元測試后，將開始集成測試。就是將這些模塊集成在一起，測試它們是否有效。集成測試是單元測試和系統(tǒng)測試之間的橋梁。迭代次數(shù)增加，軟件成熟后，測試將進(jìn)入系統(tǒng)測試階段。系統(tǒng)測試以需求規(guī)范為依據(jù)，通常由獨(dú)立的測試人員按黑盒方式執(zhí)行。循環(huán)一直持續(xù)到在一段時(shí)間內(nèi)測試的缺陷保持在相對較低的水平，并且出現(xiàn)的問題可能會(huì)被忽略，并且要進(jìn)行系統(tǒng)初穩(wěn)驗(yàn)收測試。

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

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

在測試產(chǎn)品時(shí)編寫的測試用例遵循軟件需求說明書中的設(shè)計(jì)要求中描述的基本功能。功能交互性并不涉及GUI元素，如界面布局等元素。這樣做的優(yōu)點(diǎn)是測試用例與產(chǎn)品關(guān)系不是太緊密。它支持在同一系統(tǒng)平臺(tái)上創(chuàng)建生成許多不同的手機(jī)軟件，同一系列的用例可以全部或部分應(yīng)用于整個(gè)平臺(tái)的其他產(chǎn)品，減少勞動(dòng)力損耗，縮短開發(fā)周期，并降低業(yè)務(wù)成本。當(dāng)然，每種硬件產(chǎn)品的測試順序不一定相同，并且存在許多由不同硬件引起的問題的示例。所有設(shè)計(jì)用例都構(gòu)成了一個(gè)測試用例庫。在每次迭代開始時(shí)，測試團(tuán)隊(duì)負(fù)責(zé)人選擇用例的一部分并創(chuàng)建測試用例集。另一部分是在最后一次迭代中檢測到許多錯(cuò)誤的模塊，以及在開發(fā)人員更改后進(jìn)行的密集回歸測試。

2.2交互測試策略

手機(jī)軟件是一個(gè)復(fù)雜的系統(tǒng)。只采用基本的功能測試用例是不夠的。用戶經(jīng)常有意無意地打開應(yīng)用程序進(jìn)行復(fù)雜操作，不可避免地需要與其他應(yīng)用程序進(jìn)行交互，這就需要?jiǎng)?chuàng)建交互式測試用例。這部分測試主要是通過多年積累的測試經(jīng)驗(yàn)和對錯(cuò)誤的敏感性來發(fā)現(xiàn)錯(cuò)誤。

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

在測試中找到問題很重要，但在找到問題后編寫錯(cuò)誤報(bào)告也很重要。一個(gè)好的錯(cuò)誤報(bào)告可以指導(dǎo)開發(fā)人員找到解決問題的根本原因并及時(shí)修復(fù)。編寫錯(cuò)誤報(bào)告時(shí)詳細(xì)說明，詳細(xì)描述問題的環(huán)境，步驟，版本，再現(xiàn)性等因素，客觀地描述問題而不做任何不知情的猜測，以免誤導(dǎo)開發(fā)人員。在可用的情況下，提供錯(cuò)誤日志記錄以幫助開發(fā)人員重現(xiàn)問題并確定問題的性質(zhì)。報(bào)告錯(cuò)誤后，定期跟蹤報(bào)告的錯(cuò)誤狀態(tài)并與開發(fā)人員溝通以確定糾錯(cuò)過程。如果錯(cuò)誤得到糾正，對新版本執(zhí)行回歸測試。

2.4 灰盒測試策略

在用例測試中，常用的是黑盒測試、白盒測試?；液袦y試是白盒測試和黑盒測試之間的測試。最常見的灰盒測試是集成測試?；液袦y試不僅關(guān)注用例執(zhí)行結(jié)果，還要關(guān)注軟件運(yùn)行時(shí)，消息流、數(shù)據(jù)在模塊間的交互應(yīng)答和時(shí)序關(guān)系。這要求測試人員不斷總結(jié)測試執(zhí)行過程并依靠測試工具設(shè)置特定策略，從測試輸出信息中提取所需信息加以判斷。

2.5 臨界測試策略

當(dāng)手機(jī)的某些可用資源達(dá)到或超過允許的理論最大值時(shí)，手機(jī)將繼續(xù)執(zhí)行某些相關(guān)操作。此時(shí)，手機(jī)的行為應(yīng)該是友好的并且是用戶可接受的。

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

手機(jī)功能很多，自動(dòng)化測試的數(shù)量會(huì)很多，測試中經(jīng)常會(huì)遇到很多重復(fù)的任務(wù)。手動(dòng)執(zhí)行非常費(fèi)時(shí)費(fèi)力，很容易導(dǎo)致測試人員疲勞甚至無聊，容易導(dǎo)致測試遺漏。如果有一套自動(dòng)執(zhí)行機(jī)制，它將大大提高測試的效率。

2.7 性能測試策略

性能測試是為了測試軟件運(yùn)行是否達(dá)到手機(jī)標(biāo)準(zhǔn)的響應(yīng)時(shí)間。它可以測定手機(jī)完成軟件操作所需的時(shí)間。

3.系統(tǒng)的功能需求

3.1測試用例管理

測試用例管理包括添加新的測試用例，刪除過時(shí)的測試用例，修改測試用例，有條件地查詢測試用例以及執(zhí)行測試用例。系統(tǒng)管理員可以執(zhí)行操作，添加新的測試用例，當(dāng)需要測試新的手機(jī)產(chǎn)品時(shí)，制造商將提供手機(jī)功能手冊。測試工程師將根據(jù)手冊測試相應(yīng)的功能，并將這些測試用例寫入系統(tǒng)。刪除過期的測試用例，在手機(jī)測試中，手機(jī)會(huì)根據(jù)測試報(bào)告進(jìn)行一些功能變化，并且可以根據(jù)各方面的分析刪除一些功能，因此相應(yīng)功能的測試用例需要?jiǎng)h除，具有刪除權(quán)限的測試工程師可以刪除這些測試用例。修改測試用例，當(dāng)測試期間更改了手機(jī)的某些方面的設(shè)置時(shí)，需要修改相應(yīng)的測試用例，具有修改權(quán)限的測試工程師可以修改這些測試用例。

3.2用戶管理

軟件客戶端的新用戶注冊：與其他電腦系統(tǒng)不同，手機(jī)軟件的安全級別更高，所以測試的手機(jī)軟件版本和其他傳統(tǒng)版本不可用，這要求測試產(chǎn)品在測試過程中確保機(jī)密性。創(chuàng)建新用戶需要系統(tǒng)管理員執(zhí)行系統(tǒng)管理員將帳號(hào)和密碼發(fā)送給測試工程師?；拘畔⑿薷模河脩舻卿浐罂梢孕薷囊恍┗拘畔?。密碼更改：登錄成功后，用戶進(jìn)入密碼修改頁面，可以重置登錄密碼。

3.3權(quán)限控制

只有管理員才具有此權(quán)限。管理員進(jìn)入權(quán)限管理頁面并為不同的角色分配不同的權(quán)限。權(quán)限分為每個(gè)功能點(diǎn)。設(shè)置角色權(quán)限后，管理員可以為不同的用戶分配不同的角色。

4.系統(tǒng)與數(shù)據(jù)庫數(shù)據(jù)交互使用存儲(chǔ)過程

存儲(chǔ)過程是由用戶命名并編譯到SQL Server數(shù)據(jù)庫中以執(zhí)行特定功能的SQL語句的集合。同時(shí)，用戶可以指定存儲(chǔ)過程的名稱和參數(shù)來執(zhí)行它?？梢栽诖鎯?chǔ)過程中驗(yàn)證數(shù)據(jù)，并且可以將執(zhí)行結(jié)果返回給用戶。

5.功能分析

軟件系統(tǒng)功能包括：登錄模塊，測試用例管理模塊，測試用例執(zhí)行模塊，用戶權(quán)限模塊等。登錄模塊：主要提供用戶登錄系統(tǒng)。測試用例管理模塊：之后成功登錄后，用戶將查看測試用例以操作測試用例。測試用例執(zhí)行模塊：用戶可以在登錄后執(zhí)行必要的操作。用戶角色管理模塊：用戶可以修改和管理他們的角色。用戶權(quán)限模塊：此權(quán)限僅適用于用戶本身，具有完全獨(dú)立性。

結(jié)束語

通過對實(shí)際工作中總結(jié)的手機(jī)軟件測試過程和策略的討論，討論了業(yè)界主流手機(jī)軟件測試的過程和策略，闡述了標(biāo)準(zhǔn)過程和擴(kuò)展策略的重要性。以及實(shí)際應(yīng)用的自動(dòng)測試方法，實(shí)踐證明，基于自動(dòng)化測試工具平臺(tái)，測試腳本開發(fā)，結(jié)合具體的測試自動(dòng)化經(jīng)驗(yàn)，可以完全滿足軟件壓力測試標(biāo)準(zhǔn)，保證壓力測試質(zhì)量，縮短測試周期，提高測試效率。

參考文獻(xiàn)：

[1]巫紅霞.關(guān)系數(shù)據(jù)庫中查詢優(yōu)化方法的探討[J].鎮(zhèn)江高專學(xué)報(bào)，2007.

[2]張能立.ASP.NET在網(wǎng)站開發(fā)中的應(yīng)用[J].計(jì)算機(jī)與數(shù)字工程，2005.

[3]邵良珊.ASP.NET（C#）實(shí)踐教程.清華大學(xué)出版社[J]，2007.

[4]陳冠軍.精通ASP.NET 2.0典型模塊設(shè)計(jì)與實(shí)現(xiàn).人民郵電出版社[J]，2007年.