基于H模型的軟件測試管理應(yīng)用模型

由安博測試空間技術(shù)中心/提供1軟件測試管理模型近年來，隨著對軟件測試的不斷深入，對于各個(gè)測試階段的理解加深，軟件測試管理模型不斷地發(fā)生演化，其中最具有代表性的測試管理模型有三種：V模型、W模型和H模型。V模型的特點(diǎn)就是根據(jù)瀑布模型的階段劃分，對于沒一個(gè)階段進(jìn)行針對性的測試，這種劃分很簡單，也容易進(jìn)行管理，如圖一所示。V模型揭示了軟件測試活動(dòng)的分層和分階段的本質(zhì)特性。但也存在一些問題，容易讓人行程“測試是開發(fā)之后的一個(gè)階段”，“測試的對象就是程序”等誤解。實(shí)際應(yīng)用上，也容易導(dǎo)致需求階段隱藏的錯(cuò)誤一直到最后的驗(yàn)收測試才被發(fā)現(xiàn)，這可能導(dǎo)致軟件開發(fā)的不可控。W模型是V模型自然而然的發(fā)展，他強(qiáng)調(diào)：測試伴隨著整個(gè)開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測試，如圖2所示。這樣，只要相應(yīng)的開發(fā)活動(dòng)完成，我們就可以開始執(zhí)行測試，可以說，測試與開發(fā)時(shí)同步進(jìn)行的，從而有利于盡早的發(fā)現(xiàn)問題。以需求為例，需求分析一完成，我們就可以對需求進(jìn)行測試，而不必等到最后猜猜進(jìn)行針對需求的驗(yàn)收測試。然而，無論是V模型還是W模型，都存在不妥之處。他們都把軟件的開發(fā)視為需求、設(shè)計(jì)和編碼等一系列的串行活動(dòng)。事實(shí)上，雖然這些活動(dòng)之間存在著互相牽連的關(guān)系，但在大部分時(shí)間，它們都是互相獨(dú)立的，但是可以并發(fā)進(jìn)行的。雖然軟件開發(fā)期望有清晰的需求、設(shè)計(jì)和編碼等階段，但實(shí)踐告訴我們，嚴(yán)格的階段之分只是一種理想的狀況。所以相應(yīng)的測試也不存在嚴(yán)格的先后次序，只要測試條件滿足，就可以（或需要）進(jìn)行測試。H模型則有所不同，如圖3所示。它僅僅演示了在整個(gè)測試周期中，某個(gè)層次上的一次測試“微循環(huán)”。圖中的其他流程可以是任何開發(fā)流程，例如設(shè)計(jì)流程和編碼流程，也可以是其他非開發(fā)的流程，例如SQA流程，甚至是測試流程自身。向上的箭頭表示，在某個(gè)時(shí)間點(diǎn)，由于“其他流程”的進(jìn)展而引發(fā)或者出發(fā)了測試就緒點(diǎn)，這個(gè)時(shí)候，只要測試準(zhǔn)備活動(dòng)完成，測試執(zhí)行活動(dòng)就可以或需要進(jìn)行了。概括的說嗎，在H模型中，軟件測試是一個(gè)獨(dú)立于其他流程，貫穿于整個(gè)產(chǎn)品生命周期，與其他流程并發(fā)的進(jìn)行，當(dāng)某個(gè)測試事件點(diǎn)就緒時(shí)，軟件測試即從測試準(zhǔn)備階段進(jìn)入測試執(zhí)行階段。H模型兼顧效率和靈活性，可以被應(yīng)用到各種規(guī)模、各種類型的軟件項(xiàng)目上。2基于H模型的軟件測試管理應(yīng)用模型基于H模型雖然兼顧效率和靈活性，但他沒有提出具體的應(yīng)用模型，基于這個(gè)理論基礎(chǔ)我們根據(jù)WfMC所定義的工作流的概念預(yù)定義，將工作流引入到H模型中，并構(gòu)造出一個(gè)以人物分配為驅(qū)動(dòng)的軟件測試管理應(yīng)用模型。工作流工作流執(zhí)行服務(wù)是工作流管理系統(tǒng)的核心，工作流執(zhí)行服務(wù)提供了一個(gè)運(yùn)行環(huán)境，在這個(gè)環(huán)境中，利用一個(gè)或多個(gè)工作流管理引擎進(jìn)行過程實(shí)例化或激活，通過與必要的外部資源進(jìn)行交互負(fù)責(zé)解釋和激活部分或全部過程定義。它由一個(gè)或多個(gè)創(chuàng)建、管理和執(zhí)行工作流程實(shí)例化的工作流引擎組成，應(yīng)用程序通過工作流應(yīng)用程序接口來訪問這種服務(wù)。工作流引擎：工作流引擎負(fù)責(zé)工作流執(zhí)行服務(wù)中的部分或全部運(yùn)行控制環(huán)境，它為工作流實(shí)例提供運(yùn)行環(huán)境。過程與活動(dòng)的狀態(tài)變遷：工作流執(zhí)行服務(wù)可以被看做一臺(tái)狀態(tài)轉(zhuǎn)換自動(dòng)機(jī)，它的過程或活動(dòng)實(shí)例根據(jù)外部事件或工作流引擎的特定控制決定來改變狀態(tài)。軟件測試管理應(yīng)用模型根據(jù)當(dāng)今軟件企業(yè)普遍采用的開發(fā)模式，結(jié)合可行性和易用性，我們可以圍繞H模型為基礎(chǔ)并結(jié)合W模型，針對實(shí)際工作情況，建立如圖4所示軟件測試管理應(yīng)用模型。測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進(jìn)行安裝，安裝代碼提供安裝一些程序能夠運(yùn)行的基礎(chǔ)數(shù)據(jù)。白盒測試-結(jié)構(gòu)測試-邏輯驅(qū)動(dòng)測試白盒測試，英文是WhiteBoxTesting。又稱結(jié)構(gòu)測試或者邏輯驅(qū)動(dòng)測試。白盒測試是把測試對象看作一個(gè)打開的盒子。利用白盒測試法進(jìn)行動(dòng)態(tài)測試時(shí)，需要測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程，不需測試軟件產(chǎn)品的功能。白盒測試法的覆蓋標(biāo)準(zhǔn)有邏輯覆蓋、循環(huán)覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。白盒測試是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動(dòng)、基路測試等，主要用于軟件驗(yàn)證。白盒測試常用工具有：Jtest、VcSmith、Jcontract、C++Test、CodeWizard、logiscope。黑盒測試-功能測試-數(shù)據(jù)驅(qū)動(dòng)測試黑盒測試，英文是BlackBoxTesting。又稱功能測試或者數(shù)據(jù)驅(qū)動(dòng)測試。黑盒測試是根據(jù)軟件的規(guī)格對軟件進(jìn)行的測試，這類測試不考慮軟件內(nèi)部的運(yùn)作原理，因此軟件對用戶來說就像一個(gè)黑盒子。軟件測試人員以用戶的角度，通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件存在的缺陷，而不關(guān)心程序具體如何實(shí)現(xiàn)的一種軟件測試方法。黑盒測試常用工具有：AutoRunner、winrunner、loadrunner。自動(dòng)化測試自動(dòng)化測試，英文是AutomatedTesting。使用自動(dòng)化測試工具來進(jìn)行測試，這類測試一般不需要人干預(yù)，通常在GUI、性能等測試和功能測試中用得較多。通過錄制測試腳本，然后執(zhí)行這個(gè)測試腳本來實(shí)現(xiàn)測試過程的自動(dòng)化。國內(nèi)領(lǐng)先的自動(dòng)化測試服務(wù)提供商是澤眾軟件。自動(dòng)化測試工具有AutoRunner和TAR等。回歸測試回歸測試，英文是Regressiontesting?；貧w測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。理論上，軟件產(chǎn)生新版本，都需要進(jìn)行回歸測試，驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯(cuò)誤是否在新軟件版本上再次出現(xiàn)。根據(jù)修復(fù)好了的缺陷再重新進(jìn)行測試?；貧w測試的目的在于驗(yàn)證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時(shí)的步驟重新測試。通常確定所需的再測試的范圍時(shí)是比較困難的，特別當(dāng)臨近產(chǎn)品發(fā)布日期時(shí)。因?yàn)闉榱诵拚橙毕輹r(shí)必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗(yàn)證修好的缺陷時(shí)不僅要服從缺陷原來出現(xiàn)時(shí)的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應(yīng)當(dāng)鼓勵(lì)對所有回歸測試用例進(jìn)行自動(dòng)化測試。驗(yàn)收測試驗(yàn)收測試，英文是Acceptancetesting。驗(yàn)收測試是指系統(tǒng)開發(fā)生命周期方法論的一個(gè)階段，這時(shí)相關(guān)的用戶或獨(dú)立測試人員根據(jù)測試計(jì)劃和結(jié)果對系統(tǒng)進(jìn)行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項(xiàng)確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試。驗(yàn)收測試一般有三種策略：正式驗(yàn)收、非正式驗(yàn)收活A(yù)lpha測試、Beta測試。動(dòng)態(tài)測試動(dòng)態(tài)測試，英文是MomentTesting。動(dòng)態(tài)測試是指通過運(yùn)行軟件來檢驗(yàn)軟件的動(dòng)態(tài)行為和運(yùn)行結(jié)果的正確性。根據(jù)動(dòng)態(tài)測試在軟件開發(fā)過程中所處的階段和作用，動(dòng)態(tài)測試可分為如下幾個(gè)步驟：1、單元測試2、集成測試3、系統(tǒng)測試4、驗(yàn)收測試5、回歸測試探索測試探索測試，英文是ExploratoryTesting。探索測試是指通常用于沒有產(chǎn)品說明書的測試，這需要把軟件當(dāng)作產(chǎn)品說明書來看待，分步驟逐項(xiàng)探索軟件特性，記錄軟件執(zhí)行情況，詳細(xì)描述功能，綜合利用靜態(tài)和動(dòng)態(tài)技術(shù)來進(jìn)行測試。探索測試人員只靠智能、洞察力和經(jīng)驗(yàn)來對bug的位置進(jìn)行判斷,所以探索測試又被稱為自由形式測試。單元測試單元測試，英文是UnitTesting。單元測試是最微小規(guī)模的測試;以測試某個(gè)功能或代碼塊。典型地由程序員而非測試員來做，因?yàn)樗枰纼?nèi)部程序設(shè)計(jì)和編碼的細(xì)節(jié)知識(shí)。這個(gè)工作不容易做好，除非應(yīng)用系統(tǒng)有一個(gè)設(shè)計(jì)很好的體系結(jié)構(gòu);還可能需要開發(fā)測試驅(qū)動(dòng)器模塊或測試套具。集成測試集成測試，英文是IntegrationTesting。集成測試是指一個(gè)應(yīng)用系統(tǒng)的各個(gè)部件的聯(lián)合測試，以決定他們能否在一起共同工作并沒有沖突。部件可以是代碼塊、獨(dú)立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序。這種類型的測試尤其與客戶服務(wù)器和分布式系統(tǒng)有關(guān)。一般集成測試以前，單元測試需要完成。集成測試是單元測試的邏輯擴(kuò)展。它的最簡單的形式是：兩個(gè)已經(jīng)測試過的單元組合成一個(gè)組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個(gè)單元的集成聚合。在現(xiàn)實(shí)方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。此外，如果程序由多個(gè)進(jìn)程組成，應(yīng)該成對測試它們，而不是同時(shí)測試所有進(jìn)程。集成測試識(shí)別組合單元時(shí)出現(xiàn)的問題。通過使用要求在組合單元前測試每個(gè)單元，并確保每個(gè)單元的生存能力的測試計(jì)劃，可以知道在組合單元時(shí)所發(fā)現(xiàn)的任何錯(cuò)誤很可能與單元之間的接口有關(guān)。這種方法將可能發(fā)生的情況數(shù)量減少到更簡單的分析級(jí)別系統(tǒng)測試系統(tǒng)測試，英文是SystemTesting。系統(tǒng)測試是基于系統(tǒng)整體需求說明書的黑盒類測試，應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。系統(tǒng)測試是針對整個(gè)產(chǎn)品系統(tǒng)進(jìn)行的測試，目的是驗(yàn)證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不相符合或與之矛盾的地方。系統(tǒng)測試的對象不僅僅包括需要測試的產(chǎn)品系統(tǒng)的軟件，還要包含軟件所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。因此，必須將系統(tǒng)中的軟件與各種依賴的資源結(jié)合起來，在系統(tǒng)實(shí)際運(yùn)行環(huán)境下來進(jìn)行測試。端到端測試端到端測試，英文是EndtoEndTesting。端到端測試類似于系統(tǒng)測試，測試級(jí)的“宏大”的端點(diǎn)，涉及整個(gè)應(yīng)用系統(tǒng)環(huán)境在一個(gè)現(xiàn)實(shí)世界使用時(shí)的模擬情形的所有測試。例如與數(shù)據(jù)庫對話，用網(wǎng)絡(luò)通訊，或與外部硬件、應(yīng)用系統(tǒng)或適當(dāng)?shù)南到y(tǒng)對話。端到端架構(gòu)測試包含所有訪問點(diǎn)的功能測試及性能測試。端到端架構(gòu)測試實(shí)質(zhì)上是一種"灰盒"測試，一種集合了白盒測試和黑盒測試的優(yōu)點(diǎn)的測試方法。健全測試健全測試，英文是Sanitytesting。健全測試是指一個(gè)初始化的測試工作，以決定一個(gè)新的軟件版本測試是否足以執(zhí)行下一步大的測試努力。例如，如果一個(gè)新版軟件每5分鐘與系統(tǒng)沖突，使系統(tǒng)陷于泥潭，說明該軟件不夠“健全”，目前不具備進(jìn)一步測試的條件。衰竭測試衰竭測試，英文是FailureTesting。衰竭測試是指軟件或環(huán)境的修復(fù)或更正后的“再測試”?？赡芎茈y確定需要多少遍再次測試。尤其在接近開發(fā)周期結(jié)束時(shí)。自動(dòng)測試工具對這類測試尤其有用。接受測試接受測試，英文是AcceptTesting。接受測試是基于客戶或最終用戶的規(guī)格書的最終測試，或基于用戶一段時(shí)間的使用后，看軟件是否滿足客戶要求。一般從功能、用戶界面、性能、業(yè)務(wù)關(guān)聯(lián)性進(jìn)行測試。負(fù)載測試負(fù)載測試，英文是Loadtesting。負(fù)載測試是測試一個(gè)應(yīng)用在重負(fù)荷下的表現(xiàn)。例如測試一個(gè)Web站點(diǎn)在大量的負(fù)荷下，何時(shí)系統(tǒng)的響應(yīng)會(huì)退化或失敗，以發(fā)現(xiàn)設(shè)計(jì)上的錯(cuò)誤或驗(yàn)證系統(tǒng)的負(fù)載能力。在這種測試中，將使測試對象承擔(dān)不同的工作量，以評(píng)測和評(píng)估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運(yùn)行的能力。負(fù)載測試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外，負(fù)載測試還要評(píng)估性能特征，例如，響應(yīng)時(shí)間、事務(wù)處理速率和其他與時(shí)間相關(guān)的方面。強(qiáng)迫測試強(qiáng)迫測試，英文是ForceTesting。強(qiáng)迫測試是在交替進(jìn)行負(fù)荷和性能測試時(shí)常用的術(shù)語。也用于描述象在異乎尋常的重載下的系統(tǒng)功能測試之類的測試，如某個(gè)動(dòng)作或輸入大量的重復(fù)，大量數(shù)據(jù)的輸入，對一個(gè)數(shù)據(jù)庫系統(tǒng)大量的復(fù)雜查詢等。壓力測試壓力測試，英文是StressTesting。和負(fù)載測試差不多。壓力測試是一種基本的質(zhì)量保證行為，它是每個(gè)重要軟件測試工作的一部分。壓力測試的基本思路很簡單：不是在常規(guī)條件下運(yùn)行手動(dòng)或自動(dòng)測試，而是在計(jì)算機(jī)數(shù)量較少或系統(tǒng)資源匱乏的條件下運(yùn)行測試。通常要進(jìn)行壓力測試的資源包括內(nèi)部內(nèi)存、CPU可用性、磁盤空間和網(wǎng)絡(luò)帶寬等。一般用并發(fā)來做壓力測試。性能測試性能測試，英文是PerformanceTesting。性能測試是在交替進(jìn)行負(fù)荷和強(qiáng)迫測試時(shí)常用的術(shù)語。理想的“性能測試”(和其他類型的測試)應(yīng)在需求文檔或質(zhì)量保證、測試計(jì)劃中定義。性能測試一般包括負(fù)載測試和壓力測試。通常驗(yàn)證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標(biāo)。或者執(zhí)行同樣任務(wù)時(shí)新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運(yùn)行程序時(shí)會(huì)不會(huì)流失(memoryleak)。比如，驗(yàn)證程序保存一個(gè)巨大的文件新版本不比舊版本慢?？捎眯詼y試可用性測試，英文是PracticalUsabilityTesting?？捎眯詼y試是對“用戶友好性”的測試。顯然這是主觀的，且將取決于目標(biāo)最終用戶或客戶。用戶面談、調(diào)查、用戶對話的錄象和其他一些技術(shù)都可使用。程序員和測試員通常都不宜作可用性測試員。卸載測試卸載測試，英文是UninstallTesting。卸載測試是對軟件的全部、部分或升級(jí)卸載處理過程的測試。主要是測試軟件能否卸載，卸載是否干凈，對系統(tǒng)有無更改，在系統(tǒng)中的殘留與后來的生成文件如何處理等。還有原來更改的系統(tǒng)值是否修改回去恢復(fù)測試恢復(fù)測試，英文是Recoverytesting?；謴?fù)測試是測試一個(gè)系統(tǒng)從如下災(zāi)難中能否很好地恢復(fù)，如遇到系統(tǒng)崩潰、硬件損壞或其他災(zāi)難性問題?；謴?fù)測試指通過人為的讓軟件（或者硬件）出現(xiàn)故障來檢測系統(tǒng)是否能正確的恢復(fù)，通常關(guān)注恢復(fù)所需的時(shí)間以及恢復(fù)的程度?；謴?fù)測試主要檢查系統(tǒng)的容錯(cuò)能力。當(dāng)系統(tǒng)出錯(cuò)時(shí)，能否在指定時(shí)間間隔內(nèi)修正錯(cuò)誤并重新啟動(dòng)系統(tǒng)?；謴?fù)測試首先要采用各種辦法強(qiáng)迫系統(tǒng)失敗，然后驗(yàn)證系統(tǒng)是否能盡快恢復(fù)。對于自動(dòng)恢復(fù)需驗(yàn)證重新初始化（reinitialization）、檢查點(diǎn)(checkpointingmechanisms)、數(shù)據(jù)恢復(fù)(datarecovery)和重新啟動(dòng)(restart)等機(jī)制的正確性；對于人工干預(yù)的恢復(fù)系統(tǒng)，還需估測平均修復(fù)時(shí)間，確定其是否在可接受的范圍內(nèi)。安全測試安全測試，英文是SecurityTesting。安全測試是測試系統(tǒng)在防止非授權(quán)的內(nèi)部或外部用戶的訪問或故意破壞等情況時(shí)怎么樣。這可能需要復(fù)雜的測試技術(shù)。安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如：①想方設(shè)法截取或破譯口令；②專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制；③故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；④試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時(shí)間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是，使非法侵入的代價(jià)超過被保護(hù)信息的價(jià)值。此時(shí)非法侵入者已無利可圖。兼容性測試兼容測試，英文是CompatibilityTesting。兼容測試是測試軟件在一個(gè)特定的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)等環(huán)境下的性能如何。向上兼容向下兼容，軟件兼容硬件兼容。軟件的兼容性有很多需要考慮的地方。比較測試比較測試，英文是CompareTesting。比較測試是指與競爭伙伴的產(chǎn)品的比較測試，如軟件的弱點(diǎn)、優(yōu)點(diǎn)或?qū)嵙?。來取長補(bǔ)短，以增強(qiáng)產(chǎn)品的競爭力。可接受性測試可接受性測試，英文是AcceptabilityTesting?？山邮苄詼y試是在把測試的版本交付測試部門大范圍測試以前進(jìn)行的對最基本功能的簡單測試。因?yàn)樵诎褱y試的版本交付測試部門大范圍測試以前應(yīng)該先驗(yàn)證該版本對于所測試的功能基本上比較穩(wěn)定。必須滿足一些最低要求。比如不會(huì)很容易程序就掛起或崩潰。如果一個(gè)新版本沒通過可測試性的驗(yàn)證，就應(yīng)該阻攔測試部門花時(shí)間在該測試版本上測試。同時(shí)還要找到造成該版本不穩(wěn)定的主要缺陷并督促盡快加以修正邊界條件測試邊界條件測試，英文是BoudaryTesting。又稱邊界值測試。一種黑盒測試方法，適度等價(jià)類分析方法的一種補(bǔ)充,由長期的測試工作經(jīng)驗(yàn)得知，大量的錯(cuò)誤是發(fā)生在輸入或輸出的邊界上。因此針對各種邊界情況設(shè)計(jì)測試用例，可以查出更多的錯(cuò)誤。邊界條件測試是環(huán)繞邊界值的測試。通常意味著測試軟件各功能是否能正確處理最大值，最小值或者所設(shè)計(jì)軟件能夠處理的最長的字符串等等。強(qiáng)力測試強(qiáng)力測試，英文是MightinessTesting。強(qiáng)力測試通常驗(yàn)證軟件的性能在各種極端的環(huán)境和系統(tǒng)條件下是否還能正常工作?；蛘哒f是驗(yàn)證軟件的性能在各種極端環(huán)境和系統(tǒng)條件下的承受能力。比如，在最低的硬盤驅(qū)動(dòng)器空間或系統(tǒng)記憶容量條件下，驗(yàn)證程序重復(fù)執(zhí)行打開和保存一個(gè)巨大的文件1000次后也不會(huì)崩潰或死機(jī)。裝配/安裝/配置測試裝配/安裝/配置測試是驗(yàn)證軟件程序在不同廠家的硬件上，所支持的不同語言的新舊版本平臺(tái)上，和不同方式安裝的軟件都能夠如預(yù)期的那樣正確運(yùn)行。比如，把英文版的MicrosoftOffice2003安裝在韓文版的WindowsMe上，再驗(yàn)證所有功能都正常運(yùn)行。靜態(tài)測試靜態(tài)測試，英文是StaticTesting。靜態(tài)測試指測試不運(yùn)行的部分，例如測試產(chǎn)品說明書，對此進(jìn)行檢查和審閱.。靜態(tài)方法是指不運(yùn)行被測程序本身，僅通過分析或檢查源程序的文法、結(jié)構(gòu)、過程、接口等來檢查程序的正確性。靜態(tài)方法通過程序靜態(tài)特性的分析，找出欠缺和可疑之處，例如不匹配的參數(shù)、不適當(dāng)?shù)难h(huán)嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計(jì)算等。靜態(tài)測試結(jié)果可用于進(jìn)一步的查錯(cuò)，并為測試用例選取提供指導(dǎo)。靜態(tài)測試常用工具有：Logiscope、PRQA；隱藏?cái)?shù)據(jù)測試隱藏?cái)?shù)據(jù)測試在軟件驗(yàn)收和確認(rèn)階段是十分必要和重要的一部分。程序的質(zhì)量不僅僅通過用戶界面的可視化數(shù)據(jù)來驗(yàn)證，而且必須包括遍歷系統(tǒng)的所有數(shù)據(jù)。假設(shè)一個(gè)應(yīng)用程序要求用戶兩條信息-----用戶名和密碼來創(chuàng)建帳戶。這個(gè)用戶輸入這兩條數(shù)據(jù)后保存。最后，一個(gè)確認(rèn)窗口將通過數(shù)據(jù)庫中找到這條數(shù)據(jù)來顯示用戶名和密碼給用戶。為了驗(yàn)證所有的數(shù)據(jù)保存是否正確，一個(gè)QA測試人員會(huì)在這個(gè)確認(rèn)窗口簡單的查看下用戶名和密碼。如果他們成功了？假設(shè)數(shù)據(jù)庫記錄了第三條信息----創(chuàng)建日期，它可能不會(huì)出現(xiàn)在確認(rèn)窗口，而只在存檔中才出現(xiàn)。如果創(chuàng)建日期保留的不正確，而QA測試人員只驗(yàn)證屏幕上的數(shù)據(jù)，那么這個(gè)問題就不可能被發(fā)現(xiàn)。創(chuàng)建日期可能就是一個(gè)bug，由于一個(gè)用戶帳戶保存了一個(gè)錯(cuò)誤的日期到數(shù)據(jù)庫中，這個(gè)問題也不可能會(huì)被引起注意，因?yàn)樗挥脩艚缑嫠[藏。這只是一個(gè)簡單的例子，但是它卻演化出了一點(diǎn)：隱藏?cái)?shù)據(jù)測試的重要性。等價(jià)劃分測試等價(jià)劃分測試的英文是equivalencepartitiontesting。等價(jià)劃分測試是根據(jù)等價(jià)類設(shè)計(jì)測試用例的一種技術(shù)。是黑盒測試的典型方法之一，通過把被測試程序所有可能的輸入數(shù)據(jù)域劃分成若干部分。從每一部分中選取少數(shù)有代表性的數(shù)據(jù)作為測試用例，可有效減少測試次數(shù)，極大提高軟件測試效率，縮短軟件開發(fā)周期．等價(jià)類劃分測試的目的就是為了在有限的測試資源的情況下，用少量有代表性的數(shù)據(jù)得到比較好的測試效果。有效等價(jià)類盒無效等價(jià)類。有效等價(jià)類中的數(shù)據(jù)代表的是一組符合需求文檔的正確的有意義數(shù)據(jù)。無效等價(jià)類則正相反。判定表判定表的英文是decisiontable，是指一個(gè)表格，用于顯示條件和條件導(dǎo)致動(dòng)作的集合。定義：判定表是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的情況的工具。判定表的優(yōu)點(diǎn)：能夠?qū)?fù)雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用判定表能夠設(shè)計(jì)出完整的測試用例集合。在一些數(shù)據(jù)處理問題當(dāng)中，某些操作的實(shí)施依賴于多個(gè)邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執(zhí)行不同的操作。判定表很適合于處理這類問題深度測試深度測試的英文Depthtest，是指執(zhí)行一個(gè)產(chǎn)品的一個(gè)特性的所有細(xì)節(jié)，但不測試所有特性。當(dāng)比較函數(shù)返回真的時(shí)候才顯示出效果來。必須啟用“#深度測試”，才能執(zhí)行測試。不使用的時(shí)候需要關(guān)閉?；谠O(shè)計(jì)的測試基于設(shè)計(jì)的測試的英文是design-basedtesting，是根據(jù)軟件的構(gòu)架或詳細(xì)設(shè)計(jì)引出測試用例的一種方法。一種基于設(shè)計(jì)模型的測試方法(ModelBasedTestIngSystem,MATIS).該方法利用用戶界面自動(dòng)生成方法,把設(shè)計(jì)模型中的類屬性定義和實(shí)現(xiàn)中的控件屬性組織在一起,構(gòu)建描述界面的邏輯對照表,輔助測試腳本引擎執(zhí)行自動(dòng)測試腳本.借助設(shè)計(jì)模型中擴(kuò)展的類定義,MATIS方法可以自動(dòng)生成測試用例和測試數(shù)據(jù)。文檔測試文檔測試的英文是documentationtesting，測試關(guān)注于文檔的正確性。文檔測試有三大類分別是開發(fā)文件、用戶文件、管理文件。1.開發(fā)文件：可行性研究報(bào)告、軟件需求說明書、數(shù)據(jù)要求說明書、概要設(shè)計(jì)說明書、詳細(xì)設(shè)計(jì)說明書、數(shù)據(jù)庫設(shè)計(jì)說明書、模塊開發(fā)卷宗。2.用戶文件：用戶手冊、操作手冊。3.管理文件：項(xiàng)目開發(fā)計(jì)劃、測試計(jì)劃、測試分析報(bào)告、開發(fā)進(jìn)度月報(bào)、項(xiàng)目開發(fā)總結(jié)報(bào)告。軟件測試中的文檔測試主要是對相關(guān)的設(shè)計(jì)報(bào)告和用戶使用說明進(jìn)行測試，對于設(shè)計(jì)報(bào)告主要是測試程序與設(shè)計(jì)報(bào)告中的設(shè)計(jì)思想是否一致；對于用戶使用說明進(jìn)行測試時(shí)，主要是測試用戶使用說明書中對程序操作方法的描述是否正確，重點(diǎn)是用戶使用說明中提到的操作例子要進(jìn)行測試，保證采用的例子能夠在程序中正確完成操作。域測試域測試的英文是domaintesting，定義參考等價(jià)劃分測試（equivalencepartitiontesting）；一般分為單域測試和多域測試，其中單域測試包括設(shè)備測試和業(yè)務(wù)測試，設(shè)備測試包括測試某個(gè)系統(tǒng)的軟交換設(shè)備、中繼媒體網(wǎng)關(guān)設(shè)備、信令網(wǎng)關(guān)設(shè)備、接入媒體網(wǎng)關(guān)和IAD等設(shè)備。等價(jià)類劃分有兩種不同的情況：有效等價(jià)類和無效等價(jià)類。設(shè)計(jì)時(shí)要同時(shí)考慮這兩種等價(jià)類，因?yàn)檐浖粌H要能接收合理的數(shù)據(jù)，也要能經(jīng)受意外的考驗(yàn)。一有效等價(jià)類：是指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用有效等價(jià)類可檢驗(yàn)程序是否實(shí)現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。二無效等價(jià)類：與有效等價(jià)類的定義恰巧相反。接口測試接口測試的英文是interfacetesting，接口測試測試系統(tǒng)組件間接口的一種測試。接口測試的好處：由于接口測試代碼本身就是用junit（當(dāng)然接口的類型不同，不一定是Junit來實(shí)現(xiàn)）來實(shí)現(xiàn)的，是屬于自動(dòng)化測試的范疇，因此必定也包含自動(dòng)化測試所固有的優(yōu)勢。1）提高測試質(zhì)量軟件開發(fā)的過程是一個(gè)持續(xù)集成和改進(jìn)的過程，而每一次的改進(jìn)都可能引進(jìn)新bug,因此當(dāng)軟件的一部，或者全部修改時(shí)，都需要對軟件產(chǎn)品重新進(jìn)行測試。其目的是要驗(yàn)證修改后的產(chǎn)品是符合需求的，而當(dāng)沒有自動(dòng)化測試代碼時(shí)，往往會(huì)由于各種各樣的原因，回歸不充分，導(dǎo)致bug遺漏。2）提高測試效率軟件系統(tǒng)的規(guī)模越來越大，功能點(diǎn)越來越多，開發(fā)人員的自測或者測試人員的人工測試非常耗時(shí)和繁瑣，勢必導(dǎo)致測試效率的低下，而自動(dòng)化測試正好解決這些耗時(shí)繁瑣的任務(wù)，在對外接口功能不變的情況下，達(dá)到了一次編寫，永久使用的效果。3）提高測試覆蓋通過手工測試很難測試到一些更深層次的異常和安全的問題，