軟件測試工具分析及其應(yīng)用探討

張潔

摘 要： 結(jié)合實(shí)踐探討了在現(xiàn)有生產(chǎn)軟件的中小型企業(yè)中，如何將軟件測試與軟件開發(fā)相結(jié)合，使軟件測試管理的質(zhì)量得以提升。介紹了一些目前常用的軟件測試工具及測試管理工具，對軟件測試管理中應(yīng)注意到的80：20問題進(jìn)行闡述分析，提出對測試管理中可能存在的風(fēng)險(xiǎn)可采取一些方法來應(yīng)對。實(shí)踐證明，使用全程軟件測試管理對解決測試管理工作中存在的問題有很大幫助。

關(guān)鍵詞： 軟件測試； 測試管理； 風(fēng)險(xiǎn)； 全程軟件測試

中圖分類號：TP311.5 文獻(xiàn)標(biāo)志碼：A 文章編號：1006-8228（2014）06-50-03

0 引言

隨著計(jì)算機(jī)硬件成本的不斷下降，軟件在整個(gè)計(jì)算機(jī)系統(tǒng)的成本中占有越來越高的比例，如何提高軟件質(zhì)量是整個(gè)計(jì)算機(jī)軟件行業(yè)的重大課題。軟件測試作為軟件開發(fā)的一個(gè)重要環(huán)節(jié)，日益受到人們的重視。軟件測試是為了盡可能多地找出程序中的錯(cuò)誤，保證軟件產(chǎn)品的高質(zhì)量和可靠性，在分析、設(shè)計(jì)等各個(gè)開發(fā)階段結(jié)束前，對客戶的軟件產(chǎn)品進(jìn)行嚴(yán)謹(jǐn)?shù)募夹g(shù)評審，因此，加強(qiáng)測試工作的組織和管理尤為重要。

大量統(tǒng)計(jì)資料表明，軟件測試的工作量往往占軟件開發(fā)總工作量的40%以上，對于一些特殊的軟件研發(fā)費(fèi)的成本可能是該軟件其他開發(fā)階段成本的三倍甚至更多。僅就軟件測試而言，它的目標(biāo)是發(fā)現(xiàn)軟件中的錯(cuò)誤，但是，發(fā)現(xiàn)錯(cuò)誤不是軟件工程的最終目標(biāo)，而是要開發(fā)出符合用戶需要的軟件。因此在軟件測試中，從開發(fā)者的角度出發(fā)，就希望該軟件產(chǎn)品不存在什么錯(cuò)誤，通過測試已經(jīng)表明可以滿足用戶的需求，但是從用戶的角度的出發(fā)，則希望軟件測試中發(fā)現(xiàn)更多隱藏的缺陷和錯(cuò)誤。所以對于軟件測試的工作人員來說，就應(yīng)把著眼點(diǎn)放在如何盡可能地發(fā)現(xiàn)軟件錯(cuò)誤這個(gè)基礎(chǔ)上，不讓這些問題遺留到用戶的使用階段中去。因此對于測試，筆者認(rèn)為更為合適的定義應(yīng)該是：測試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。它揭示了軟件測試是一個(gè)破壞性的過程，甚至是一個(gè)“瘋狂找茬”的過程，這就說明為什么大多數(shù)人都覺得它很難。

至今軟件測試還是一項(xiàng)讓人捉摸不透的事情。為確保測試工作的順利進(jìn)行，就要對其進(jìn)行有效管理。在一個(gè)軟件工程項(xiàng)目中，不同的管理者對軟件測試管理有不同的理解，但無論怎樣，軟件測試管理[1]都要求管理者掌握軟件測試的多種技術(shù)和方法，它是提高軟件質(zhì)量的一種重要手段。一些企業(yè)開發(fā)的軟件，質(zhì)量總是在較低水平徘徊，這些企業(yè)也試圖提高軟件質(zhì)量，但總是不得要領(lǐng)，不知如何建立測試管理體系，設(shè)置了人員崗位，但不知如何明確職責(zé)，明確了職責(zé)但不知如何建立測試流程，建立了流程但不知如何與研發(fā)團(tuán)隊(duì)合作進(jìn)行測試等等，問題層出不窮。

1 常用的軟件測試工具及軟件測試管理工具

1.1 功能測試工具

⑴ QTP是HP QuickTest Professional的簡稱[2]，是一種自動(dòng)化功能測試工具。側(cè)重于功能的回歸自動(dòng)化測試，針對的是GUI應(yīng)用程序，包括傳統(tǒng)的Windows應(yīng)用程序，以及現(xiàn)在越來越流行的Web應(yīng)用。

⑵ WinRunner是一種企業(yè)級的功能測試工具，用于檢測應(yīng)用程序是否能夠達(dá)到預(yù)期的功能及正常運(yùn)行。

⑶ Rational Robot集成在測試人員的桌面IBM Rational Test Manager上，在這里測試人員可以計(jì)劃、組織、執(zhí)行、管理和報(bào)告所有測試活動(dòng)，包括手動(dòng)測試報(bào)告。

⑷ AdventNet QEngine是一個(gè)應(yīng)用廣泛且獨(dú)立于平臺(tái)的自動(dòng)化軟件測試工具，可用于Web功能測試、web性能測試、Java應(yīng)用功能測試、Java API測試、SOAP測試、回歸測試和Java應(yīng)用性能測試。

⑸ SilkTest是業(yè)界領(lǐng)先的、用于對企業(yè)應(yīng)用進(jìn)行功能測試的產(chǎn)品，可用于測試Web、Java或是傳統(tǒng)的C/S結(jié)構(gòu)。

⑹ QA Run的測試實(shí)現(xiàn)方式是通過鼠標(biāo)移動(dòng)、鍵盤點(diǎn)擊操作被測應(yīng)用，即而得到相應(yīng)的測試腳本，對該腳本可以進(jìn)行編輯和調(diào)試。

⑺ Test Partner是一個(gè)自動(dòng)化的功能測試工具，它專為測試基于微軟、Java和Web技術(shù)的復(fù)雜應(yīng)用而設(shè)計(jì)。

1.2 性能自動(dòng)化測試工具

1.2.1 主流負(fù)載性能測試工具

⑴ QA Load：Compuware公司的QALoad是客戶/服務(wù)器系統(tǒng)、企業(yè)資源配置（ERP）和電子商務(wù)應(yīng)用的自動(dòng)化負(fù)載測試工具。

⑵ SilkPerformer：一種在工業(yè)領(lǐng)域最高級的企業(yè)級負(fù)載測試工具。它可以模仿成千上萬的用戶在多協(xié)議和多計(jì)算的環(huán)境下工作。

⑶ LoadRunner：一種較高規(guī)模適應(yīng)性的，自動(dòng)負(fù)載測試工具，它能預(yù)測系統(tǒng)行為，優(yōu)化性能。

⑷ WebRunner：是RadView公司推出的一個(gè)性能測試和分析工具，它讓web應(yīng)用程序開發(fā)者自動(dòng)執(zhí)行壓力測試。

1.2.2 資源監(jiān)控工具[3]

資源監(jiān)控作為系統(tǒng)壓力測試過程中的一個(gè)重要環(huán)節(jié)，在相關(guān)的測試工具中基本上都有很多的集成，比如Loadrunner具體包括用戶執(zhí)行情況、場景狀態(tài)、事務(wù)響應(yīng)時(shí)間、TPS、Load、CPU分析圖表等。另一種性能測試監(jiān)控工具Nmon是一種在AIX與各種Linux操作系統(tǒng)上被廣泛使用的監(jiān)控與分析工具，相對于其他一些系統(tǒng)資源監(jiān)控工具來說，Nmon所記錄的信息是比較全面的，它能在系統(tǒng)運(yùn)行過程中實(shí)時(shí)地捕捉系統(tǒng)資源的使用情況，并且能輸出結(jié)果到文件中，然后通過Nmon_Analyzer工具產(chǎn)生數(shù)據(jù)文件與圖形化結(jié)果。

1.3 白盒測試工具

白盒測試工具[4]一般是針對代碼進(jìn)行測試，測試中發(fā)現(xiàn)的缺陷可以定位到代碼級，根據(jù)測試工具原理的不同，可分為靜態(tài)測試工具和動(dòng)態(tài)測試工具。白盒測試工具的選擇在于對開發(fā)語言的支持、代碼覆蓋的深度、嵌入式軟件的測試、測試的可視化等。目前測試工具主要支持的開發(fā)語言包括：標(biāo)準(zhǔn)C、C++、Visual C++、Java、Visual J+等。常用白盒測試工具有以下。

⑴ Jtest：是一個(gè)代碼分析和動(dòng)態(tài)類、組件測試工具，是一個(gè)集成的、易于使用和自動(dòng)化的Java單元測試工具。它增強(qiáng)代碼的穩(wěn)定性，防止軟件錯(cuò)誤。

⑵ Jcontract：在系統(tǒng)級驗(yàn)證類/部件是否正確工作并被正確使用。Jcontract 是個(gè)獨(dú)立工具，在功能上是Jtest 的補(bǔ)充。

⑶ C++ Test：自動(dòng)測試C和C++類、函數(shù)或組件，而無需編寫單個(gè)測試實(shí)例、測試驅(qū)動(dòng)程序或樁調(diào)用。

⑷ CodeWizard：代碼靜態(tài)分析工具，先進(jìn)的C/C++源代碼分析工具，使用超過500 個(gè)編碼規(guī)范自動(dòng)化地標(biāo)明危險(xiǎn)的，但是編譯器不能檢查到的代碼結(jié)構(gòu)。

⑸ Jcheck：通過監(jiān)視和分析當(dāng)前內(nèi)存中所有線程的運(yùn)行狀況，找到出錯(cuò)的根源，并且可以定位到具體是程序中的哪個(gè)方法出錯(cuò)，錯(cuò)誤位于程序的哪一行。

⑹ .TEST是專為.NET開發(fā)而推出的使用方便的自動(dòng)化單元級測試與靜態(tài)分析工具。

⑺ BoundsChecker：Visual C++ Edition 是針對Visual C++開發(fā)人員的首選的運(yùn)行時(shí)的錯(cuò)誤檢測和調(diào)試工具。

⑻ CodeReview：是最好的自動(dòng)源代碼分析工具。

⑼ FailSafe：是Visual Basic語言環(huán)境下的自動(dòng)錯(cuò)誤處理和恢復(fù)工具。

1.4 軟件測試管理工具

測試管理包含的內(nèi)容有：測試框架、測試計(jì)劃與組織、測試過程管理、測試分析與缺陷管理。測試管理工具是指用工具對軟件的整個(gè)測試輸入、執(zhí)行過程和測試結(jié)果進(jìn)行管理的過程?？梢蕴岣呋貧w測試的效率、大幅提升測試時(shí)間、測試質(zhì)量、用例復(fù)用、需求覆蓋等。

1.4.1 當(dāng)前流行的測試管理工具[8]

⑴ TD TestDirector是全球最大的軟件測試工具提供商Mercury Interactive公司生產(chǎn)的企業(yè)級測試管理工具，也是業(yè)界第一個(gè)基于Web的測試管理系統(tǒng)，它可以在您公司內(nèi)部或外部進(jìn)行全球范圍內(nèi)測試的管理。

⑵ QC HP-Mercury Quality Center是一個(gè)基于Web的測試管理工具，可以組織和管理應(yīng)用程序測試流程的所有階段，包括指定測試需求、計(jì)劃測試、執(zhí)行測試和跟蹤缺陷。此外，通過Quality Center還可以創(chuàng)建報(bào)告和圖來監(jiān)控測試流程。

⑶ TestCenter是一款功能強(qiáng)大的測試管理工具，實(shí)現(xiàn)測試用例的過程管理，對測試需求過程、測試用例設(shè)計(jì)過程、業(yè)務(wù)組件設(shè)計(jì)實(shí)現(xiàn)過程等整個(gè)測試過程進(jìn)行管理。

⑷ IBM Rational TestManager 是原Rational 產(chǎn)品中專業(yè)對軟件測試資源進(jìn)行管理的強(qiáng)大工具。包括測試用例管理、測試執(zhí)行管理、測試腳本和報(bào)告管理等。另外，可與Robot結(jié)合做性能測試，更可以和RFT、RFP、CC、CQ等集成使用。

⑸ TestLink是sourceforge的開放源代碼項(xiàng)目之一。作為基于Web的測試管理系統(tǒng)，TestLink的主要功能包括：測試需求管理、測試用例管理、測試用例對測試需求的覆蓋管理、測試計(jì)劃的制定、測試用例的執(zhí)行、大量測試數(shù)據(jù)的度量和統(tǒng)計(jì)功能。

1.4.2 禪道測試管理軟件

禪道是第一款國產(chǎn)的優(yōu)秀開源項(xiàng)目管理軟件。它集產(chǎn)品管理、項(xiàng)目管理、質(zhì)量管理、文檔管理、組織管理和事務(wù)管理于一體，是一款功能完備的項(xiàng)目管理軟件，完美地覆蓋了項(xiàng)目管理的核心流程。禪道在基于SCRUM管理方式基礎(chǔ)上，又融入了國內(nèi)研發(fā)現(xiàn)狀的很多需求，比如Bug管理，測試用例管理，發(fā)布管理，文檔管理等。因此禪道不僅僅是一款項(xiàng)目管理工具，更是一款完備的項(xiàng)目管理軟件。

2 軟件測試管理應(yīng)注意的幾個(gè)問題

2.1 80：20原則

首先談一下軟件開發(fā)中眾所周知的80：20原則[5]，就是80%的用戶只使用了20%的特性。這來自于Standish Group在2002年的一項(xiàng)研究成果，那么這與測試管理有什么聯(lián)系呢？實(shí)際經(jīng)驗(yàn)表明，80：20原則與軟件測試有著許多聯(lián)系。

2.1.1 80：20與代碼質(zhì)量、Bug&軟件測試

80%的Bug是由20%的代碼造成的；90%的停機(jī)是由10%的缺陷造成的。Bug總是集中爆發(fā)在某幾部分代碼中，特別是嚴(yán)重的Bug；而大多數(shù)嚴(yán)重的問題都是由少數(shù)幾個(gè)Bug導(dǎo)致的。Windows與Office中80%的錯(cuò)誤與崩潰是由檢測出的20%的Bug造成的。

2.1.2 80：20與修改頻率

哪些代碼被修改了，修改的頻率是多少。Michael Feathers發(fā)現(xiàn)80：20原則也適用于代碼隨時(shí)間變化的頻率：80%的修改發(fā)生在20%的代碼上，很多代碼一旦寫完之后就再也不會(huì)被修改了。還有些代碼一直都在發(fā)生著變化：20%的特性花了80%的時(shí)間，他們經(jīng)常會(huì)根據(jù)需求的變化而發(fā)生變化。

2.1.3 80：20與編程時(shí)間

前80%的代碼只花了20%的時(shí)間，而剩下的20%的代碼則花了其余的80%的時(shí)間。完成某個(gè)功能通常并不會(huì)花太多時(shí)間，不過在背后通常還會(huì)有大量工作要做，比如處理邊界情況、處理錯(cuò)誤，確保系統(tǒng)的性能與可伸縮性，尋找并修復(fù)各種Bug，部署前的各種調(diào)整等等。

2.1.4 80：20與軟件測試管理

時(shí)刻謹(jǐn)記80：20原則可以節(jié)省大量的金錢與時(shí)間，將精力集中于重要的事情上可以增加成功性。比如重要的特性及大多數(shù)嚴(yán)重的Bug出現(xiàn)的代碼區(qū)域，經(jīng)常會(huì)發(fā)生變化的代碼。這在整個(gè)軟件測試階段都是管理者和測試人員要充分注意并考慮到的問題。

2.2 軟件測試管理中的風(fēng)險(xiǎn)管理

2.2.1 風(fēng)險(xiǎn)

風(fēng)險(xiǎn)[6]是一種不確定的事件或條件，一旦發(fā)生，會(huì)對至少一個(gè)項(xiàng)目目標(biāo)造成影響。引起風(fēng)險(xiǎn)的原因有很多，要根據(jù)不同的類型來確定最佳的方法以解決風(fēng)險(xiǎn)造成的不良影響。

2.2.2 風(fēng)險(xiǎn)管理

風(fēng)險(xiǎn)管理包括風(fēng)險(xiǎn)管理規(guī)劃、風(fēng)險(xiǎn)識別、風(fēng)險(xiǎn)分析、風(fēng)險(xiǎn)應(yīng)對規(guī)劃和風(fēng)險(xiǎn)監(jiān)控等各個(gè)過程。項(xiàng)目風(fēng)險(xiǎn)管理的目標(biāo)在于提高項(xiàng)目積極事件的概率和影響，降低項(xiàng)目消極事件的概率和影響。對于已識別出的風(fēng)險(xiǎn)，需要分析其發(fā)生概率和影響程度，并進(jìn)行優(yōu)先級排序，優(yōu)先處理高概率和高影響風(fēng)險(xiǎn)。

2.2.3 風(fēng)險(xiǎn)識別

風(fēng)險(xiǎn)識別是系統(tǒng)化地識別已知的和可預(yù)測的風(fēng)險(xiǎn)，才能提前采取措施，盡可能避免這些風(fēng)險(xiǎn)的發(fā)生，最重要的是降低風(fēng)險(xiǎn)可能造成損失的程度。

2.2.4 風(fēng)險(xiǎn)評估

風(fēng)險(xiǎn)評估是對已識別風(fēng)險(xiǎn)的影響和可能性大小的分析過程。從經(jīng)驗(yàn)來看，許多最終導(dǎo)致項(xiàng)目失敗、延期、客戶投訴的風(fēng)險(xiǎn)，都是從不起眼的小風(fēng)險(xiǎn)開始，由于這些小風(fēng)險(xiǎn)長時(shí)間得不到重視和解決，最終導(dǎo)致了項(xiàng)目的交付。

2.3 軟件測試管理中的全程軟件測試[7]

按傳統(tǒng)的軟件測試，開發(fā)人員完成開發(fā)工作之后，交付給測試人員，這種模式下，測試人員不能及早發(fā)現(xiàn)需求階段的缺陷，同時(shí)測試工作的開展也滯后了，產(chǎn)品質(zhì)量得不到有效的過程控制和分析，最終造成項(xiàng)目拖延。如采用全程軟件測試，測試人員貫穿需求階段、開發(fā)階段、發(fā)布階段和運(yùn)營階段這四個(gè)階段，開展測試活動(dòng)。

2.3.1 需求階段測試

在需求階段，開發(fā)人員對用戶的需求進(jìn)行分析、整理、估時(shí)，測試人員應(yīng)參與其中，檢查功能性需求和非功能性需求是否描述清晰，其中可以將非功能性需求作為驗(yàn)收要點(diǎn)，測試人員要發(fā)揮作用，減少含混性需求留到開發(fā)階段，同時(shí)協(xié)助開發(fā)人員做好時(shí)間估算。

2.3.2 開發(fā)階段測試

在此階段，開發(fā)人員要進(jìn)行架構(gòu)評審、功能要點(diǎn)確認(rèn)、編碼開發(fā)、單元測試、開發(fā)自測、Bug Fix等工作，而作為測試人員通常要先進(jìn)行功能確認(rèn)，即在開發(fā)人員進(jìn)行編碼前，針對需求處理的用戶需求，與開發(fā)人員進(jìn)行確認(rèn)，修正理解偏差，確保需求理解一致。接下來進(jìn)行測試用例設(shè)計(jì)、用例評審、測試探索（包括功能測試、Bug Tracking、回歸測試、系統(tǒng)測試、驗(yàn)收測試），另外，測試人員應(yīng)每天發(fā)布時(shí)間進(jìn)度表，讓團(tuán)隊(duì)了解當(dāng)前進(jìn)度情況，總結(jié)問題，尋求耗時(shí)超過預(yù)期時(shí)間任務(wù)的解決辦法。每個(gè)項(xiàng)目在開發(fā)/測試階段中，最好能構(gòu)建缺陷經(jīng)驗(yàn)庫，避免多走彎路，測試人員還可提供相關(guān)checklist幫助開發(fā)人員在編碼過程中關(guān)注開發(fā)自測的要點(diǎn)，從而提升質(zhì)量。

2.3.3 發(fā)布階段測試

當(dāng)一個(gè)項(xiàng)目處于發(fā)布階段，開發(fā)人員進(jìn)行上線申請、上線部署、服務(wù)監(jiān)控時(shí)，作為測試人員應(yīng)完成驗(yàn)收測試，提供測試報(bào)告，給出測試數(shù)據(jù)度量。另外，測試人員還有一項(xiàng)重要工作，就是對當(dāng)前版本的缺陷進(jìn)行統(tǒng)計(jì)分析?？傊疁y試人員在此階段應(yīng)當(dāng)持續(xù)反饋、改進(jìn)、總結(jié)每個(gè)版本發(fā)生的問題，并對缺陷進(jìn)行分析，總結(jié)出一些規(guī)律，幫助開發(fā)人員建立良好的習(xí)慣，改進(jìn)代碼的質(zhì)量。

2.3.4 運(yùn)營階段測試

運(yùn)營階段并不是終止階段，此時(shí)開發(fā)人員進(jìn)行故障登記，而測試人員則要進(jìn)行版本問題反饋和改進(jìn)提議——對軟件運(yùn)營發(fā)生的問題，總結(jié)反饋，提出改進(jìn)建議，并且跟蹤實(shí)施；生產(chǎn)故障分析——協(xié)助開發(fā)排查生產(chǎn)故障，避免測試場景的遺漏。

全程軟件測試實(shí)踐，強(qiáng)調(diào)的是貫穿每個(gè)階段的測試活動(dòng)，不論是開發(fā)、還是測試，要理解雙方的活動(dòng)價(jià)值，什么時(shí)候該做什么事情，什么事情該做到什么程度才算好，保證每個(gè)環(huán)節(jié)的質(zhì)量，才能夠保證產(chǎn)品的全程質(zhì)量。另外產(chǎn)品質(zhì)量不是測試出來的，而是構(gòu)建過程中沉淀下來的，開發(fā)人員的素養(yǎng)、測試人員的素養(yǎng)，以及團(tuán)隊(duì)對開發(fā)測試過程的重視程度，決定了產(chǎn)品質(zhì)量。

3 結(jié)束語

軟件測試囊括了軟件開發(fā)領(lǐng)域，軟件測試并不是保證產(chǎn)品質(zhì)量的最后一道防線，測試人員應(yīng)更全局地看待整個(gè)軟件項(xiàng)目，全面地掌控整個(gè)產(chǎn)品。測試人員做的應(yīng)該是從最終用戶角度考慮的測試，使用合適的軟件測試工具和不斷提高管理水平，構(gòu)建一套適合本企業(yè)研發(fā)人員的測試體系，幫助測試人員確保所有的測試和底層測試框架都被正確有效地使用并保證整個(gè)軟件產(chǎn)品交付使用。

參考文獻(xiàn)：

[1] 鄭文強(qiáng)，馬均飛.軟件測試管理[M].電子工業(yè)出版社，2010.

[2] 杜麗潔.基于QTP自動(dòng)化測試框架的開發(fā)與應(yīng)用[D].武漢理工大學(xué)，

2012.

[3] 資源監(jiān)測工具.http：//www.oschina.net/p/glances，2014.

[4] 白盒測試工具大全.http：//www.ltesting.net/html/05/n-155905.

html.2008

[5] 在軟件開發(fā)中應(yīng)用80：20原則.http：//www.kuqin.com/shuoit/

20131120/336423.html.2013

[6] 趙震.軟件測試風(fēng)險(xiǎn)分析[J].科技信息，2012.16.

[7] 朱少民.全程軟件測試[M].電子工業(yè)出版社，2007.

[8] http：//www.spasvo.com/

[9] 王立新.軟件測試數(shù)據(jù)的高效生成及測試方法研究[D].東華大學(xué)，

2011.

[10] 劉冰川.軟件缺陷分析與管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].哈爾濱工業(yè)大

學(xué)，2013.

[11] 邱彥卿.軟件測試自動(dòng)化技術(shù)及其應(yīng)用研究[D].華中科技大學(xué)，

2007.