張潔

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

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

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

0 引言

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

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

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

1 常用的軟件測(cè)試工具及軟件測(cè)試管理工具

1.1 功能測(cè)試工具

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 白盒測(cè)試工具

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

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

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

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

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

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

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

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

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

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

1.4 軟件測(cè)試管理工具

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

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

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

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

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

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

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

1.4.2 禪道測(cè)試管理軟件

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

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

2.1 80：20原則

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

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

80%的Bug是由20%的代碼造成的；90%的停機(jī)是由10%的缺陷造成的。Bug總是集中爆發(fā)在某幾部分代碼中，特別是嚴(yán)重的Bug；而大多數(shù)嚴(yán)重的問(wèn)題都是由少數(shù)幾個(gè)Bug導(dǎo)致的。Windows與Office中80%的錯(cuò)誤與崩潰是由檢測(cè)出的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í)間，不過(guò)在背后通常還會(huì)有大量工作要做，比如處理邊界情況、處理錯(cuò)誤，確保系統(tǒng)的性能與可伸縮性，尋找并修復(fù)各種Bug，部署前的各種調(diào)整等等。

2.1.4 80：20與軟件測(cè)試管理

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

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

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

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

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

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

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

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

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

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

2.3 軟件測(cè)試管理中的全程軟件測(cè)試[7]

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

2.3.1 需求階段測(cè)試

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

2.3.2 開發(fā)階段測(cè)試

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

2.3.3 發(fā)布階段測(cè)試

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

2.3.4 運(yùn)營(yíng)階段測(cè)試

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

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

3 結(jié)束語(yǔ)

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

參考文獻(xiàn)：

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

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

2012.

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

[4] 白盒測(cè)試工具大全.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] 趙震.軟件測(cè)試風(fēng)險(xiǎn)分析[J].科技信息，2012.16.

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

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

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

2011.

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

學(xué)，2013.

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

2007.