張潔

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

關鍵詞： 軟件測試； 測試管理； 風險； 全程軟件測試

中圖分類號：TP311.5 文獻標志碼：A 文章編號：1006-8228（2014）06-50-03

0 引言

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

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

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

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

1.1 功能測試工具

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

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

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

⑷ AdventNet QEngine是一個應用廣泛且獨立于平臺的自動化軟件測試工具，可用于Web功能測試、web性能測試、Java應用功能測試、Java API測試、SOAP測試、回歸測試和Java應用性能測試。

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

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

⑺ Test Partner是一個自動化的功能測試工具，它專為測試基于微軟、Java和Web技術的復雜應用而設計。

1.2 性能自動化測試工具

1.2.1 主流負載性能測試工具

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

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

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

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

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

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

1.3 白盒測試工具

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

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

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

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

⑷ CodeWizard：代碼靜態(tài)分析工具，先進的C/C++源代碼分析工具，使用超過500 個編碼規(guī)范自動化地標明危險的，但是編譯器不能檢查到的代碼結構。

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

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

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

⑻ CodeReview：是最好的自動源代碼分析工具。

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

1.4 軟件測試管理工具

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

1.4.1 當前流行的測試管理工具[8]

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

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

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

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

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

1.4.2 禪道測試管理軟件

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

2 軟件測試管理應注意的幾個問題

2.1 80：20原則

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

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

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

2.1.2 80：20與修改頻率

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

2.1.3 80：20與編程時間

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

2.1.4 80：20與軟件測試管理

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

2.2 軟件測試管理中的風險管理

2.2.1 風險

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

2.2.2 風險管理

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

2.2.3 風險識別

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

2.2.4 風險評估

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

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

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

2.3.1 需求階段測試

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

2.3.2 開發(fā)階段測試

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

2.3.3 發(fā)布階段測試

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

2.3.4 運營階段測試

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

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

3 結束語

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

參考文獻：

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

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

2012.

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

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

html.2008

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

20131120/336423.html.2013

[6] 趙震.軟件測試風險分析[J].科技信息，2012.16.

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

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

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

2011.

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

學，2013.

[11] 邱彥卿.軟件測試自動化技術及其應用研究[D].華中科技大學，

2007.