信息系統(tǒng)測試的設(shè)計、組織和實施課件

信息系統(tǒng)測試

的設(shè)計、組織和實施

5.1測試的計劃5.2測試的設(shè)計5.3測試的執(zhí)行5.4測試的總結(jié)

信息系統(tǒng)測試

的設(shè)計、組織和實施5.1測試的計劃1軟件測試實施過程

測試計劃測試設(shè)計測試執(zhí)行測試總結(jié)軟件測試實施過程測試計劃測試設(shè)計測試執(zhí)行測試總結(jié)25.1測試的計劃5.1.1測試類型的選擇 有各種各樣不同的測試類型，在測試計劃階段，要根據(jù)系統(tǒng)的功能和特性、經(jīng)費和時間等諸多方面因素，選擇不同的測試方案，進而選擇不同的測試類型。5.1測試的計劃5.1.1測試類型的選擇322種測試類型（1）黑盒測試：不基于程序內(nèi)部設(shè)計和代碼的任何知識，而是基于系統(tǒng)需求和功能。（2）白盒測試：基于一個應(yīng)用代碼的內(nèi)部邏輯結(jié)構(gòu)，測試是基于覆蓋全部代碼、分支、路徑、條件。22種測試類型（1）黑盒測試：422種測試類型（3）單元測試：測試功能模塊。典型的單元測試是由程序員而非測試員來做，因為它需要知道內(nèi)部程序設(shè)計和編碼的細節(jié)知識。這個工作不容易作好，除非應(yīng)用系統(tǒng)有一個設(shè)計很好的體系結(jié)構(gòu)，還可能需要開發(fā)測試驅(qū)動器模塊。22種測試類型（3）單元測試：522種測試類型（4）增量測試：當(dāng)一個新功能增加后，對應(yīng)用系統(tǒng)所做的連續(xù)測試。它要求應(yīng)用系統(tǒng)的不同形態(tài)的功能部件能夠足夠獨立，以便可以在全部系統(tǒng)完成之前各部件能夠分別工作。這種測試可由程序員或測試員來做。22種測試類型（4）增量測試：622種測試類型（5）集成測試：一個應(yīng)用系統(tǒng)的各個部件的聯(lián)合測試，以決定他們能否在一起共同工作。部件可以是代碼塊、獨立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序。這種類型的測試尤其與客戶/服務(wù)器和分布式系統(tǒng)有關(guān)。22種測試類型（5）集成測試：722種測試類型（6）功能測試：用于測試應(yīng)用系統(tǒng)的功能需求的黑盒測試方法。這類測試應(yīng)由測試員做，這并不意味著程序員在發(fā)布前不必檢查他們的代碼能否工作，所以功能測試能用于測試的各個階段。22種測試類型（6）功能測試：822種測試類型（7）系統(tǒng)測試： 基于系統(tǒng)整體需求說明書的測試；應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。22種測試類型（7）系統(tǒng)測試：922種測試類型（8）端到端測試： 類似于系統(tǒng)測試；涉及整個應(yīng)用系統(tǒng)環(huán)境在一個現(xiàn)實世界使用時的模擬情形的所有測試。例如與數(shù)據(jù)庫對話、與網(wǎng)絡(luò)通訊，或與外部硬件、應(yīng)用系統(tǒng)或適當(dāng)?shù)南到y(tǒng)對話。22種測試類型（8）端到端測試：1022種測試類型（9）健全測試： 典型地是指一個初始化的測試工作，以決定一個新的軟件版本測試是否足以執(zhí)行下一步大的測試努力。例如，如果一個新版軟件每5分鐘經(jīng)常與系統(tǒng)發(fā)生沖突，使系統(tǒng)陷于癱瘓，說明該軟件不夠“健全”，說明該軟件現(xiàn)在還不具備進一步測試的條件。22種測試類型（9）健全測試：1122種測試類型（10）回歸測試： 軟件或環(huán)境的修復(fù)或更正后的“再測試”?？赡芎茈y確定需要多少遍再次測試。尤其在接近開發(fā)周期結(jié)束時更需要衰竭測試。因為自動測試工具一般都具有錄制和回放功能，并且可以利用腳本語言編寫測試程序，所以自動測試工具對這類測試尤其有用。22種測試類型（10）回歸測試：1222種測試類型（11）接受測試：

基于客戶或最終用戶的規(guī)格說明書的最終測試，或基于用戶一段時間的使用后，看軟件是否滿足客戶要求。22種測試類型（11）接受測試：1322種測試類型（12）負載測試：

測試一個應(yīng)用在重負載下的表現(xiàn)，例如測試一個Web站點在大量的負載下，系統(tǒng)的響應(yīng)何時會退化或失敗。22種測試類型（12）負載測試：1422種測試類型（13）壓力測試： 在交替進行負載和性能測試時常用的術(shù)語。也用于描述在異乎尋常的重載下的系統(tǒng)功能測試之類的測試，如某個動作或輸入大量的重復(fù)，大量數(shù)據(jù)的輸入，對一個數(shù)據(jù)庫系統(tǒng)大量的復(fù)雜查詢等。22種測試類型（13）壓力測試：1522種測試類型（14）性能測試：

在交替進行負在和壓力測試時常用的術(shù)語。理想的“性能測試”(或其他類型的測試)應(yīng)在需求文檔、質(zhì)量保證文檔或測試計劃中定義。22種測試類型（14）性能測試：1622種測試類型（15）可用性測試： 對“用戶友好性”的測試。顯然這是主觀的，測試標準將取決于目標最終用戶或客戶。用戶面談、調(diào)查、用戶對話的錄像和其他一些技術(shù)都可使用。程序員和測試員通常都不宜作可用性測試員。22種測試類型（15）可用性測試：1722種測試類型（16）安裝/卸載測試： 對軟件的全部、部分或升級版本進行安裝/卸載處理過程的測試。22種測試類型（16）安裝/卸載測試：1822種測試類型（17）恢復(fù)測試： 測試一個系統(tǒng)從災(zāi)難中能否很好地恢復(fù)，如遇到系統(tǒng)崩潰、硬件損壞或其他災(zāi)難性問題。22種測試類型（17）恢復(fù)測試：1922種測試類型（18）安全測試： 測試系統(tǒng)在防止非授權(quán)的內(nèi)部或外部用戶的訪問或故意破壞等情況時如何保證系統(tǒng)正常工作。這可能需要復(fù)雜的測試技術(shù)。22種測試類型（18）安全測試：2022種測試類型（19）兼容測試： 測試該軟件在一組不同類型的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)等環(huán)境下的性能。22種測試類型（19）兼容測試：2122種測試類型（20）比較測試：

與競爭伙伴的產(chǎn)品的比較測試，如軟件的優(yōu)點、缺點或?qū)嵙Α?2種測試類型（20）比較測試：2222種測試類型（21）Alpha測試： 在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試；測試后，仍然會有少量的設(shè)計變更。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。22種測試類型（21）Alpha測試：2322種測試類型（22）Beta測試： 當(dāng)開發(fā)和測試小組已經(jīng)基本完成所要求的測試后，需要通過Beta測試在軟件最終發(fā)行前去發(fā)現(xiàn)一些錯誤和問題。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。22種測試類型（22）Beta測試：245.1.2測試策略的制定

測試策略描述測試小組用于測試整體和每個階段的方法。 測試策略的制定是一項復(fù)雜的工作，需要由經(jīng)驗豐富的測試員來做，因為這將決定測試工作的成敗。

5.1.2測試策略的制定 測試策略描述測試小組用于測試整體25問題的提出

是使用黑盒測試方法，還是使用白盒測試方法？如果決定綜合使用這兩種方法，那么在軟件的哪些部分，什么時候分別運用它們呢？問題的提出是使用黑盒測試方法，還是使用白盒測試方法？26問題的提出是使用手工測試？還是需要用測試工具和自動化測試？如果要使用工具，那么是否需要開發(fā)，或者購買已有的商用測試工具？如果購買商用測試工具，選購哪一種工具？問題的提出是使用手工測試？還是需要用測試工具和自動化測試？27問題的提出是開發(fā)單位自己測試？還是請專業(yè)的測試公司測試？如果請專業(yè)的測試公司測試，只要派出相應(yīng)的質(zhì)量保證人員監(jiān)督他們的工作即可。問題的提出是開發(fā)單位自己測試？還是請專業(yè)的測試公司測試？28制定測試策略的目的 測試策略描述測試過程的總體方法和目標，描述目前在進行哪一階段的測試（單元測試、集成測試、系統(tǒng)測試）以及每個階段內(nèi)在進行的測試種類（功能測試、性能測試、覆蓋測試等）。制定測試策略的目的 測試策略描述測試過程的總體方法和目標，描29（1）一般的測試策略

測試開始于單元級，然后“延伸”到整個系統(tǒng)中。不同的測試技術(shù)適用于不同的時間點。測試是由軟件的開發(fā)人員和獨立測試組織來管理的。（1）一般的測試策略測試開始于單元級，然后“延伸”到整個系30（2）黑盒測試的測試策略1．用邊界值分析法和（或）等價類劃分法提出基本的測試用例；

2．用錯誤猜測法補充新的測試用例；

3．如果在程序的功能說明中含有輸入條件的組合，則在測試一開始時就使用因果圖法，然后再按以上1、2兩種步驟進行。（2）黑盒測試的測試策略1．用邊界值分析法和（或）等價類劃分31（3）單元測試的測試策略1．首先用黑盒測試方法，設(shè)計一組基本測試用例進行測試。如果發(fā)現(xiàn)未能滿足覆蓋標準，就用白盒測試法補充新的測試用例2．首先用白盒測試法分析模塊的邏輯結(jié)構(gòu)，設(shè)計一批測試用例進行測試。如果發(fā)現(xiàn)未能滿足覆蓋標準，根據(jù)模塊的功能用黑盒測試法進行補充。（3）單元測試的測試策略1．首先用黑盒測試方法，設(shè)計一組基本325.1.3成立測試組織

為了盡可能多地找出程序中的錯誤，生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，加強對測試工作的組織和管理就顯得尤為重要。

5.1.3成立測試組織 為了盡可能多地找出程序中的錯誤，生產(chǎn)33對軟件測試管理的要求l

測試必須是有計劃的。l

測試必須是有組織的。l

測試必須是有準備的。l

測試必須是可管理的。l

測試必須是可記錄的。l

測試必須是可追蹤的。對軟件測試管理的要求l

測試必須是有計劃的。34軟件項目的組織和任務(wù)如何有效地管理和實施一個軟件項目?在早期軟件開發(fā)中，沒有專門的軟件測試部門和測試人員。軟件測試工作通常是由開發(fā)人員自己來完成的。隨著軟件開發(fā)規(guī)模的不斷增大，軟件開發(fā)和軟件測試逐步分離為兩個獨立的部門。為了管理軟件項目，還必須有一個軟件項目管理部門。軟件項目的組織和任務(wù)如何有效地管理和實施一個軟件項目?35軟件項目開發(fā)過程

定義：

一個軟件項目的開發(fā)過程，實際上就是一個在軟件項目管理部門的控制之下、在一定的時間和財政預(yù)算范圍內(nèi)、由軟件開發(fā)部門和軟件測試部門協(xié)同工作完成的從項目立項直到軟件產(chǎn)品發(fā)布的全過程。

軟件項目開發(fā)過程定義： 361.測試組織結(jié)構(gòu)

（1）管理部門

（2）開發(fā)部門（3）測試部門

1.測試組織結(jié)構(gòu)（1）管理部門37測試組織各部門的職責(zé)管理部門：負責(zé)整個軟件項目的計劃、實施、進度調(diào)整，以及產(chǎn)品的發(fā)布等工作。開發(fā)部門：專職于程序編碼、系統(tǒng)集成和軟件問題修復(fù)等開發(fā)工作。測試部門：專職于測試準備、測試實施、編寫軟件問題報告等測試工作。

測試組織各部門的職責(zé)管理部門：負責(zé)整個軟件項目的計劃、實施、38(1)管理部門的組成和任務(wù)管理部門的組成：軟件項目經(jīng)理軟件開發(fā)部經(jīng)理軟件測試部經(jīng)理若干關(guān)鍵技術(shù)人員(1)管理部門的組成和任務(wù)管理部門的組成：39(1)管理部門的組成和任務(wù)軟件項目管理部門的任務(wù)：(1)制定或修改軟件開發(fā)計劃和測試計劃。(2)對整個軟件項目的進度進行評估。(3)對一些重大問題進行決策，確保軟件開發(fā)項目按計劃保質(zhì)量地完成。(4)決定每周要完成的開發(fā)和測試任務(wù)。(5)協(xié)調(diào)和解決各個部門之間發(fā)生的問題。(6)決定提前或推后發(fā)布軟件。(1)管理部門的組成和任務(wù)軟件項目管理部門的任務(wù)：40(2)開發(fā)部門的組成和任務(wù)開發(fā)部門的組成：軟件開發(fā)部經(jīng)理若干軟件開發(fā)工程師(2)開發(fā)部門的組成和任務(wù)開發(fā)部門的組成：41(2)開發(fā)部門的組成和任務(wù)開發(fā)部門的任務(wù)：(1)按照軟件開發(fā)計劃及開發(fā)時間進度表，編寫和集成程序代碼。(2)對測試部門發(fā)現(xiàn)的軟件問題進行分析，確定修改的優(yōu)先級。(3)修復(fù)軟件問題并進行軟件系統(tǒng)集成，生產(chǎn)新的測試版本，在提交給測試部門之前進行基線檢查。(4)將新的軟件測試版本提交給測試部門進行驗證。(2)開發(fā)部門的組成和任務(wù)開發(fā)部門的任務(wù)：42(3)測試部門的組成和任務(wù)測試部門的組成：軟件測試部門經(jīng)理若干質(zhì)量保證人員若干軟件測試工程師(3)測試部門的組成和任務(wù)測試部門的組成：43(3)測試部門的組成和任務(wù)測試部門的任務(wù)：(1)在軟件測試工作開始之前，編寫測試計劃和測試用例。(2)按照軟件測試計劃、測試用例及時間進度表，進行軟件測試。(3)對發(fā)現(xiàn)的軟件問題編寫軟件問題報告，并及時提交給軟件開發(fā)部門。(4)在開發(fā)部門提供的新測試版本上，對修復(fù)的軟件問題進行驗證。(5)在新測試版本上，開始新一輪測試或繼續(xù)前一階段測試，并報告軟件問題。(3)測試部門的組成和任務(wù)測試部門的任務(wù)：442.測試部門和開發(fā)部門的關(guān)系基本原則:避免一個組織測試自已編寫的程序，原因是開發(fā)組織很難客觀地測試自己的程序。成立獨立的軟件測試機構(gòu)進行軟件測試。測試組織與開發(fā)組織之間的關(guān)系越遠越好。優(yōu)點： 發(fā)現(xiàn)錯誤效率高，測試組織與開發(fā)組織之間有正常的競爭。2.測試部門和開發(fā)部門的關(guān)系基本原則:45測試組織與開發(fā)組織的耦合程度l

測試組織與開發(fā)組織屬于不同公司、不同城市、甚至不同國家；l

測試組織與開發(fā)組織屬于同一公司不同部門；l

測試組織與開發(fā)組織屬于同一公司同一部門，但不在同一小組；l

測試組織與開發(fā)組織屬于同一公司同一部門同一小組內(nèi)，但測試人員與開發(fā)人員為不同人員；l

測試組織與開發(fā)組織為同一公司同一部門同一小組，并且測試人員與開發(fā)人員為同一組人員。測試組織與開發(fā)組織的耦合程度l測試組織與開發(fā)組織屬于不同463.測試人員的素質(zhì)（1）溝通能力（2）技術(shù)能力（3）自信心（4）外交能力（5）幽默感（6）很強的記憶力（7）懷疑精神（8）自我督促（9）洞察力3.測試人員的素質(zhì)（1）溝通能力475.1.4建立測試配置1．測試配置的內(nèi)容人員：人數(shù)、經(jīng)驗和專長，全職、兼職或?qū)W生。設(shè)備：計算機，打印機等。測試環(huán)境：硬件、軟件環(huán)境。測試工具：黑盒或白盒測試工具。辦公室或?qū)嶒炇遥旱攸c，大小等。專業(yè)測試公司：是否需要，費用如何。其他需求：移動存儲器，電話，通訊等。5.1.4建立測試配置1．測試配置的內(nèi)容485.1.4建立測試配置2．測試環(huán)境配置主測試環(huán)境配置輔測試環(huán)境配置5.1.4建立測試配置2．測試環(huán)境配置49主測試環(huán)境配置（1）符合軟件運行的最低要求。測試環(huán)境首先要保證能支撐軟件正常運行。（2）選用比較普及的操作系統(tǒng)和軟件平臺。例如，一個軟件若聲稱支持“Windows9X/ME/NT/2000professional”和“MSOffice97/2000/XP”，一般我們會采用如“Windows2000professional+MSOffice2000”的流行環(huán)境。（3）營造相對簡單、獨立的測試環(huán)境。除了操作系統(tǒng)，測試機上只安裝軟件運行和測試必需的軟件，以免不相關(guān)的軟件影響測試實施。（4）無毒的環(huán)境。利用有效的正版殺毒軟件檢測軟件環(huán)境，保證測試環(huán)境中沒有病毒。主測試環(huán)境配置（1）符合軟件運行的最低要求。測試環(huán)境首先要保50輔助測試環(huán)境配置（1）兼容性測試：在滿足軟件運行要求的范圍內(nèi)，可選擇一些典型的操作系統(tǒng)和常用應(yīng)用軟件對其安裝卸載和主要功能進行驗證。（2）模擬真實環(huán)境測試：有些軟件，特別是面向大眾的商品化軟件，在測試時常常需要考察在真實環(huán)境中的表現(xiàn)。如測試殺毒軟件的掃描速度時，硬盤上布置的不同類型文件的比例要盡量接近真實環(huán)境，這樣測試出來的數(shù)據(jù)才有實際意義。（3）橫向?qū)Ρ葴y試：利用輔測試環(huán)境“克隆”出完全一致的測試環(huán)境，從而保證各個被測軟件平等對比。輔助測試環(huán)境配置（1）兼容性測試：在滿足軟件運行要求的范圍內(nèi)515.1.5制定測試計劃 測試計劃是對測試工作的總體描述。5.1.5制定測試計劃 測試計劃是對測試工作的總體描述。521．測試計劃的重要性有條不紊地仔細制定測試計劃，是達成測試目標的必由之路。一個良好的、完善的測試計劃是進行成功測試的基礎(chǔ)。必須要制定一個能夠起到總體框架作用的測試計劃。測試的計劃應(yīng)該作為測試的起始步驟和重要環(huán)節(jié)。1．測試計劃的重要性有條不紊地仔細制定測試計劃，是達成測試目53制定測試計劃的重要性和必要性組織性： 即使在小型軟件測試項目上，也可能有數(shù)千個測試用例。建立測試用例可能需要一些測試員經(jīng)過幾個月甚至幾年的時間。正確的計劃會組織好測試用例，以便全體測試員和其他項目小組成員有效地審查和使用。制定測試計劃的重要性和必要性組織性：54制定測試計劃的重要性和必要性重復(fù)性：

在項目開發(fā)期間內(nèi)有必要多次執(zhí)行同樣的測試，以尋找新的系統(tǒng)缺陷，保證老的缺陷得以修復(fù)。假如沒有正確的測試計劃，就不可能知道最后執(zhí)行哪些測試用例及其執(zhí)行情況，以便重復(fù)原有的測試。制定測試計劃的重要性和必要性重復(fù)性：55制定測試計劃的重要性和必要性測試跟蹤： 在整個項目開發(fā)期間，計劃執(zhí)行多少個測試用例？在系統(tǒng)最終版本上執(zhí)行多少個測試用例？多少個通過，多少個失?。坑袩o忽略的測試用例？等等。如果沒有測試計劃，就不能回答這些問題。制定測試計劃的重要性和必要性測試跟蹤：56制定測試計劃的重要性和必要性測試驗證：

在少數(shù)高風(fēng)險行業(yè)中，測試小組必須證明確實執(zhí)行了計劃執(zhí)行的測試。發(fā)布忽略某些測試用例的系統(tǒng)實際上是不合法和危險的。正確的測試計劃和測試跟蹤提供了一種驗證手段。制定測試計劃的重要性和必要性測試驗證：572．測試計劃的內(nèi)容包括：產(chǎn)品調(diào)研；測試需求說明；測試策略；測試記錄；測試資源配置；計劃時間表；軟件問題報告跟蹤；計劃評審。2．測試計劃的內(nèi)容包括：58（1）產(chǎn)品調(diào)研這部分應(yīng)包括產(chǎn)品的一些基本情況介紹。目的變更信息軟件結(jié)構(gòu)及技術(shù)軟件產(chǎn)品規(guī)格測試范圍項目信息（1）產(chǎn)品調(diào)研這部分應(yīng)包括產(chǎn)品的一些基本情況介紹。59目的： 重點描述如何使測試建立在客觀的基礎(chǔ)上，定義測試的策略，測試的配置，粗略的估計測試大致需要的周期和最終測試報告遞交的時間。目的： 重點描述如何使測試建立在客觀的基礎(chǔ)上，定義測試的策略60變更信息： 說明有可能會導(dǎo)致測試計劃變更的事件。包括測試工具改進了，測試的環(huán)境改變了，或者是添加了新的功能。變更信息： 說明有可能會導(dǎo)致測試計劃變更的事件。包括測試工具61軟件結(jié)構(gòu)及技術(shù)：

將被測軟件劃分成幾個組成部分，規(guī)劃成一個適用于測試的完整的系統(tǒng)，包括數(shù)據(jù)是如何存儲的，如何傳遞的（數(shù)據(jù)流圖），每一個部分的測試是要達到什么樣的目的。每一個部分是怎么實現(xiàn)數(shù)據(jù)更新的。還有一些常規(guī)性的技術(shù)要求，比如運行平臺、需要什么樣的數(shù)據(jù)庫等等。軟件結(jié)構(gòu)及技術(shù)： 將被測軟件劃分成幾個組成部分，規(guī)劃成一個適62軟件產(chǎn)品規(guī)格： 就是制造商和產(chǎn)品版本號的說明，還可以包括關(guān)于被測系統(tǒng)的重要說明，如版權(quán)，日期等。

軟件產(chǎn)品規(guī)格： 就是制造商和產(chǎn)品版本號的說明，還可以包括關(guān)于63測試范圍：

簡單的描述如何搭建測試平臺以及測試的潛在的風(fēng)險等。

測試范圍： 簡單的描述如何搭建測試平臺以及測試的潛在的風(fēng)險等64項目信息： 說明要測試的項目的相關(guān)資料，如：用戶文檔、產(chǎn)品描述、主要功能的舉例說明。項目信息： 說明要測試的項目的相關(guān)資料，如：用戶文檔、產(chǎn)品描65（2）測試需求說明 列出所有要測試的功能項（測試項）。凡是沒有出現(xiàn)在這個清單里的功能項都排除在測試的范圍之外。功能的測試設(shè)計的測試整體考慮（2）測試需求說明 列出所有要測試的功能項（測試項）。凡是沒66功能的測試： 從理論上講，測試要覆蓋所有的功能項，劃分功能項將會是一個浩大的工程，但是有利于測試的完整性。 例如：在數(shù)據(jù)庫中添加、編輯、刪除記錄等。功能的測試： 從理論上講，測試要覆蓋所有的功能項，劃分功能項67設(shè)計的測試： 對于一些用戶界面、菜單的結(jié)構(gòu)還有窗體的設(shè)計是否合理等的測試。這里的合理性包括美觀性、可用性、易用性等方面。系統(tǒng)的外觀是很重要的，它要求有盡可能好的合理性。設(shè)計的測試： 對于一些用戶界面、菜單的結(jié)構(gòu)還有窗體的設(shè)計是否68整體考慮： 這部分測試需求要考慮到數(shù)據(jù)流從軟件中的一個模塊流到另一個模塊過程中的正確性。保證上述正確性是保證信息系統(tǒng)正確的前提。

例如，我們要保證一個計算器程序中的數(shù)據(jù)在運算模塊和輸入輸出模塊之間的一致性，否則程序?qū)⒊霈F(xiàn)錯誤。整體考慮： 這部分測試需求要考慮到數(shù)據(jù)流從軟件中的一個模塊流69（3）測試策略 描述如何公正客觀地開展測試。要考慮模塊、功能、集成、系統(tǒng)、版本、壓力、性能、配置和安裝等各個因素的影響。（3）測試策略 描述如何公正客觀地開展測試。要考慮模塊、功能70一般的測試策略

測試開始于單元級，然后“延伸”到整個系統(tǒng)中。不同的測試技術(shù)適用于不同的時間點。測試是由軟件的開發(fā)人員和獨立測試組織來管理的。一般的測試策略測試開始于單元級，然后“延伸”到整個系統(tǒng)中。71黑盒測試的測試策略1．用邊界值分析法和（或）等價類劃分法提出基本的測試用例；

2．用錯誤猜測法補充新的測試用例；

3．如果在程序的功能說明中含有輸入條件的組合，則在測試一開始時就使用因果圖法，然后再按以上1、2兩種步驟進行。黑盒測試的測試策略1．用邊界值分析法和（或）等價類劃分法提出72單元測試的測試策略1．首先用黑盒測試方法，設(shè)計一組基本測試用例進行測試。如果發(fā)現(xiàn)未能滿足覆蓋標準，就用白盒測試法補充新的測試用例2．首先用白盒測試法分析模塊的邏輯結(jié)構(gòu)，設(shè)計一批測試用例進行測試。如果發(fā)現(xiàn)未能滿足覆蓋標準，根據(jù)模塊的功能用黑盒測試法進行補充。單元測試的測試策略1．首先用黑盒測試方法，設(shè)計一組基本測試用73（4）測試記錄描述公正性說明： 要對測試的公正性、依照的標準做一個說明，證明測試是客觀的。在整體上，軟件功能要滿足需求、實現(xiàn)正確、和用戶文檔的描述保持一致。要保證測試的客觀，就要保證測試人員能客觀的完成測試任務(wù)。（4）測試記錄描述公正性說明：74測試用例：

描述測試用例模板，管理測試用例采用了什么工具，工具的來源是什么，如何執(zhí)行的，用了什么樣的數(shù)據(jù)。測試用例記錄中要為將來的回歸測試留有余地。測試用例： 描述測試用例模板，管理測試用例采用了什么工具，工75軟件問題報告：

在測試的計劃階段，應(yīng)該明確建立一個軟件問題報告的方法和工具。工具的來源是什么，如何執(zhí)行的，用了什么樣的數(shù)據(jù)。軟件問題報告： 在測試的計劃階段，應(yīng)該明確建立一個軟件問題報76特殊考慮： 針對一些外界環(huán)境的影響，要對軟件進行一些特殊方面的測試。 例如，對于一些用于高尖端產(chǎn)品的信息系統(tǒng)，如水下機器人、太空探測器等，測試者應(yīng)給予某些特殊的測試，使它們能在惡劣的環(huán)境下有著較高的可靠性和適應(yīng)性。特殊考慮： 針對一些外界環(huán)境的影響，要對軟件進行一些特殊方面77經(jīng)驗判斷： 對以往的測試中經(jīng)常出現(xiàn)的問題加以考慮。 例如對于數(shù)據(jù)庫系統(tǒng)，數(shù)據(jù)的操作（存取，刪除，修改等）是其基本功能，同時也是經(jīng)常出現(xiàn)問題（如數(shù)據(jù)冗余、死鎖等）的地方。經(jīng)驗判斷就是針對系統(tǒng)運行或測試中經(jīng)常出現(xiàn)的問題仔細研究考慮，使之發(fā)生率盡量的小。經(jīng)驗判斷： 對以往的測試中經(jīng)常出現(xiàn)的問題加以考慮。78（5）測試資源配置 制定一個資源配置計劃，包含每一個階段的任務(wù)、所需要的資源，當(dāng)發(fā)生類似到了使用期限或者資源共享的事情的時候，要更新這個計劃。（5）測試資源配置 制定一個資源配置計劃，包含每一個階段的任79（6）計劃時間表 測試的計劃表可以做成多個項目通用的形式，根據(jù)大致的時間估計來制作，操作流程要以軟件測試的常規(guī)周期作為參考，也可以是根據(jù)什么時候應(yīng)該測試哪一個模塊來制定。（6）計劃時間表 測試的計劃表可以做成多個項目通用的形式，根80（7）軟件問題報告跟蹤

在測試的計劃階段，應(yīng)該明確建立一個軟件問題報告的方法和工具，以及要明確如何界定一個問題的性質(zhì)，對軟件問題的描述盡可能是定量的，軟件問題報告要包括問題的發(fā)現(xiàn)者和修改者、問題發(fā)生的頻率、測出該問題所使用的測試用例，以及明確問題產(chǎn)生時的測試環(huán)境等。（7）軟件問題報告跟蹤 在測試的計劃階段，應(yīng)該明確建立一個軟81定義軟件問題級別根據(jù)其嚴重程度分為3級：第1級嚴重問題系統(tǒng)功能不能完成，或者是權(quán)限限制方面的失誤等，也可能是某個部分的改變造成了別的部分的問題。第2級一般問題系統(tǒng)功能沒有按設(shè)計要求實現(xiàn)或者是一些界面交互的實現(xiàn)不正確。第3級建議問題功能運行得不像要求的那么快，或者不符合某些約定俗成的習(xí)慣，但不影響系統(tǒng)的性能，如界面使用不方便，系統(tǒng)中信息格式不對，提示信息含義模糊混淆等。定義軟件問題級別根據(jù)其嚴重程度分為3級：82（8）計劃評審 在測試真正實施開展之前必須要認真負責(zé)的對測試計劃檢查一遍，并獲得整個測試部門人員的認同，包括部門的負責(zé)人的同意和簽字。（8）計劃評審 在測試真正實施開展之前必須要認真負責(zé)的對測試833．測試計劃的層次

一般而言，測試計劃可分為3個層次。概要測試計劃詳細測試計劃測試實施計劃3．測試計劃的層次一般而言，測試計劃可分為3個層次。84概要測試計劃

概要測試計劃是軟件項目實施計劃中的一項重要內(nèi)容，應(yīng)當(dāng)在軟件開發(fā)初期，即需求分析階段制定。概要測試計劃 概要測試計劃是軟件項目實施計劃中的一項重要內(nèi)85概要測試計劃內(nèi)容：定義測試對象和測試目標；確定測試階段和測試周期的劃分；制定測試人員、軟硬件資源和測試進度等方面的計劃；規(guī)定軟件測試方法、測試標準以及支持環(huán)境和測試工具。概要測試計劃內(nèi)容：定義測試對象和測試目標；86概要測試計劃內(nèi)容： 例如，被測試程序的語句覆蓋率要達到95%，第3級以上的錯誤修復(fù)率需要達到95%，所有決定不修復(fù)的“輕微”錯誤都必須經(jīng)過專門的質(zhì)量評審委員會同意等測試衡量標準。概要測試計劃內(nèi)容： 例如，被測試程序的語句覆蓋率要達到95%87詳細測試計劃 詳細測試計劃是針對子系統(tǒng)在特定的測試階段所要進行的測試工作制定的詳細計劃。詳細測試計劃 詳細測試計劃是針對子系統(tǒng)在特定的測試階段所要88詳細測試計劃內(nèi)容： 詳細規(guī)定了測試小組的各項測試任務(wù)、測試策略、任務(wù)分配和進度安排等。詳細測試計劃內(nèi)容： 詳細規(guī)定了測試小組的各項測試任務(wù)、測試策89測試實施計劃 測試實施計劃是根據(jù)詳細測試計劃制定的測試者的測試具體實施計劃。測試實施計劃是整個軟件測試計劃的組成部分，是檢查測試實際執(zhí)行情況的重要依據(jù)。測試實施計劃 測試實施計劃是根據(jù)詳細測試計劃制定的測試者的90測試實施計劃的內(nèi)容:

測試實施計劃規(guī)定了測試人員在每一輪測試中負責(zé)測試的內(nèi)容、測試強度和工作進度等。測試實施計劃的內(nèi)容: 測試實施計劃規(guī)定了測試人員在每一輪測91軟件測試計劃實例軟件測試計劃實例92軟件測試計劃實例軟件測試計劃實例935.2測試的設(shè)計5.2.1測試設(shè)計概念5.2.2測試方案設(shè)計5.2.3測試用例設(shè)計5.2測試的設(shè)計5.2.1測試設(shè)計概念945.2.1測試設(shè)計概念測試設(shè)計：是系統(tǒng)測試工程中的一個重要問題，也是一種特殊的軟件系統(tǒng)的設(shè)計和實現(xiàn)，即通過設(shè)計一個以發(fā)現(xiàn)錯誤為目標的系統(tǒng)來完成測試。重要性：如果不進行測試設(shè)計，要想徹底的測試一個龐大而又復(fù)雜的信息系統(tǒng)是不可能的。5.2.1測試設(shè)計概念測試設(shè)計：是系統(tǒng)測試工程中的一個重要問955.2.1測試設(shè)計概念測試設(shè)計的原則：測試設(shè)計必須依據(jù)一定的模型和原則，類似于一個應(yīng)用系統(tǒng)的分析、設(shè)計以及編程中遇到的問題。設(shè)計的測試必須是可執(zhí)行的、具體的。5.2.1測試設(shè)計概念測試設(shè)計的原則：965.2.1測試設(shè)計概念

測試設(shè)計的步驟：識別和分析被測軟件有意義的測試功能點;對這些測試點進行組織或?qū)哟蝿澐郑y試模型;為測試模型中的每個測試功能點設(shè)計測試用例。5.2.1測試設(shè)計概念 測試設(shè)計的步驟：975.2.2測試設(shè)計類型基于功能的測試設(shè)計;基于實現(xiàn)的測試設(shè)計;混合類型的測試設(shè)計;基于故障的測試設(shè)計。5.2.2測試設(shè)計類型基于功能的測試設(shè)計;98測試設(shè)計類型基于功能的測試設(shè)計: 根據(jù)一個單元、子系統(tǒng)或系統(tǒng)指定的或預(yù)期的功能來設(shè)計測試需求和測試用例，即黑盒測試設(shè)計。測試設(shè)計類型基于功能的測試設(shè)計:99測試設(shè)計類型基于實現(xiàn)的測試設(shè)計: 根據(jù)對系統(tǒng)內(nèi)部結(jié)構(gòu)或源代碼的分析設(shè)計測試需求和測試用例，即白盒測試設(shè)計。測試設(shè)計類型基于實現(xiàn)的測試設(shè)計:100測試設(shè)計類型混合類型的測試設(shè)計: 將基于功能的和基于實現(xiàn)的測試設(shè)計方法結(jié)合在一起，設(shè)計測試需求和測試用例，稱為灰盒測試。測試設(shè)計類型混合類型的測試設(shè)計:101測試設(shè)計類型基于故障的測試設(shè)計: 有目的的設(shè)計一些故障并引入代碼，以便察看被測軟件是否可以揭示這些故障。測試設(shè)計類型基于故障的測試設(shè)計:1025.2.3測試用例設(shè)計1．測試用例的概念

測試用例實際上是對軟件運行過程中所有可能存在的目標、運動、行動、環(huán)境和結(jié)果的描述，是對客觀世界的一種抽象。5.2.3測試用例設(shè)計1．測試用例的概念1031．測試用例的概念測試用例設(shè)計應(yīng)該體現(xiàn)軟件工程的思想和原則。測試用例的選擇既要有一般情況，也應(yīng)有極限情況以及最大和最小的邊界值情況。在設(shè)計選取測試用例和數(shù)據(jù)時要考慮那些易于發(fā)現(xiàn)缺陷的測試用例和數(shù)據(jù)，結(jié)合復(fù)雜的運行環(huán)境，在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查應(yīng)用軟件是否都能產(chǎn)生正確的輸出。1．測試用例的概念測試用例設(shè)計應(yīng)該體現(xiàn)軟件工程的思想和原則1041．測試用例的概念測試用例的定義： 測試用例，就是以發(fā)現(xiàn)錯誤為目的而精心設(shè)計的一組測試輸入數(shù)據(jù)、執(zhí)行步驟和預(yù)期結(jié)果的集合。測試用例={輸入數(shù)據(jù)+執(zhí)行步驟+預(yù)期結(jié)果}1．測試用例的概念測試用例的定義：1052.測試用例的類型

需求測試用例設(shè)計測試用例代碼測試用例2.測試用例的類型1062.測試用例的類型需求測試用例：目的是測試是否符合需求規(guī)范；需求測試用例通常是按照需求執(zhí)行的功能逐條地編寫輸入數(shù)據(jù)和期望輸出。一個好的需求測試用例是可以用少量的測試用例就能夠覆蓋所有的程序功能。2.測試用例的類型需求測試用例：1072.測試用例的類型

設(shè)計測試用例：目的是測試是否符合系統(tǒng)邏輯結(jié)構(gòu)；設(shè)計測試用例檢測的是代碼和設(shè)計是否完全相符,是對底層設(shè)計和基本結(jié)構(gòu)上的測試。設(shè)計測試用例可以涉及到需求測試用例沒有覆蓋到的代碼空間（例如界面的設(shè)計）。2.測試用例的類型1082.測試用例的類型代碼測試用例：目的是測試代碼的邏輯結(jié)構(gòu)和使用的數(shù)據(jù)。代碼測試用例是基于運行軟件和數(shù)據(jù)結(jié)構(gòu)設(shè)計的,它要保證可以覆蓋所有的程序分支、最小的語句和輸出。2.測試用例的類型代碼測試用例：1093．測試用例設(shè)計的原則設(shè)計測試用例基本的原則是：（1）一個好的測試用例在于能夠發(fā)現(xiàn)至今沒有發(fā)現(xiàn)的錯誤；（2）測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成；（3）在測試用例設(shè)計時，應(yīng)當(dāng)包含合理的輸入條件和不合理的輸入條件。3．測試用例設(shè)計的原則設(shè)計測試用例基本的原則是：1104．測試用例的內(nèi)容一個典型的測試用例應(yīng)該包括下列詳細信息：（1）測試目標；（2）待測試的功能；（3）測試環(huán)境及條件；（4）測試日期；（5）測試輸入；（6）測試步驟；（7）預(yù)期的輸出；（8）評價輸出結(jié)果的準則。4．測試用例的內(nèi)容一個典型的測試用例應(yīng)該包括下列詳細信息：1115.3測試的執(zhí)行

軟件測試部門的主要工作之一是按照軟件測試計劃、測試大綱及項目進度表，執(zhí)行軟件測試。5.3測試的執(zhí)行 軟件測試部門的主要工作之一是按照軟件測試112典型的測試執(zhí)行步驟：建立一組被測軟件各個功能的測試用例集（測試任務(wù)）。執(zhí)行測試任務(wù)，記錄每個測試用例的執(zhí)行結(jié)果。評價執(zhí)行測試任務(wù)的結(jié)果，是否達到功能覆蓋或代碼覆蓋要求。如果不滿足覆蓋要求，則需要進一步開發(fā)更多的測試用例，建立新的測試任務(wù)，對未被覆蓋的功能或代碼進行測試。只有當(dāng)滿足覆蓋目標，并且所有測試均已通過，才可以停止測試。典型的測試執(zhí)行步驟：建立一組被測軟件各個功能的測試用例集（測1135.3.1創(chuàng)建測試任務(wù)什么是測試任務(wù)？ 測試任務(wù)是在某一測試階段（系統(tǒng)測試，回歸測試，功能確認性測試）計劃執(zhí)行的測試用例的一個集合。5.3.1創(chuàng)建測試任務(wù)什么是測試任務(wù)？114創(chuàng)建測試任務(wù)的目的：通過將整個測試過程劃分為不同的測試任務(wù)可以滿足不同測試階段的不同的測試需求。跟蹤不同階段測試用例的執(zhí)行情況。決定測試的執(zhí)行狀態(tài)同一個測試用例在不同的測試任務(wù)中會產(chǎn)生分開的執(zhí)行報告，各自帶有獨立的測試執(zhí)行的歷史信息。測試完成后，在任務(wù)中所有執(zhí)行報告都會被歸檔。創(chuàng)建測試任務(wù)的目的：通過將整個測試過程劃分為不同的測試任務(wù)可1155.3.2執(zhí)行測試任務(wù)測試任務(wù)執(zhí)行方式：一個測試任務(wù)；多個串行的測試任務(wù)；多個并行的測試任務(wù)；多個串行和多個并行的測試任務(wù)。5.3.2執(zhí)行測試任務(wù)測試任務(wù)執(zhí)行方式：116測試任務(wù)執(zhí)行結(jié)果：計劃執(zhí)行多少測試用例？實際執(zhí)行多少測試用例？執(zhí)行用了多少時間？記錄每個測試用例執(zhí)行結(jié)果（通過或失?。?？記錄測試用例執(zhí)行通過的百分比？測試任務(wù)執(zhí)行結(jié)果：計劃執(zhí)行多少測試用例？1175.3.3處理軟件問題報告1．軟件問題報告概念軟件問題報告的作用：記錄測試中發(fā)現(xiàn)的軟件缺陷。開發(fā)部門和測試部門對SPR進行協(xié)同處理。管理部門根據(jù)SPR狀態(tài)了解測試進度和質(zhì)量。5.3.3處理軟件問題報告1．軟件問題報告概念118編號：是每個軟件問題報告的唯一標識。作者：軟件問題報告作者名稱。標題：是對軟件問題的簡要描述。狀態(tài)：軟件問題報告狀態(tài)。被測項目名：標識被測試的軟件項目名稱。被測軟件版本號：標識被測試的軟件版本編號。軟件問題嚴重程度：對軟件問題進行分級。修改優(yōu)先級：定義修改次序和時間。操作系統(tǒng)平臺和支持軟件：對軟件問題發(fā)現(xiàn)時的軟件環(huán)境進行描述，以便開發(fā)部門再現(xiàn)該軟件問題。網(wǎng)絡(luò)環(huán)境：對軟件問題發(fā)現(xiàn)時的網(wǎng)絡(luò)環(huán)境進行描述，以便開發(fā)部門再現(xiàn)該軟件問題。軟件問題再現(xiàn)詳細步驟：對軟件問題發(fā)現(xiàn)的步驟進行詳細描述。軟件問題變通和繞過方法：描述變通和繞過該軟件問題的步驟。2.軟件問題報告的內(nèi)容編號：是每個軟件問題報告的唯一標識。2.軟件問題報告的內(nèi)容119什么是軟件問題報告的生命周期?

所謂軟件問題報告的生命周期就是指軟件問題從開始提出到最后完全解決，并通過復(fù)查的過程。3．軟件問題報告的生命周期

什么是軟件問題報告的生命周期?3．軟件問題報告的生命周期120在這個生命周期中，軟件問題報告的狀態(tài)不斷發(fā)生著變化，記錄著軟件問題的處理進程。在這個生命周期中，各類人員對每個軟件問題報告所負的責(zé)任不同，擁有的處理權(quán)限也不同，體現(xiàn)了協(xié)同工作的特點。SPR生命周期的作用：在這個生命周期中，軟件問題報告的狀態(tài)不斷發(fā)生著變化，記錄著軟121SPR生命周期中的五個狀態(tài)：新建狀態(tài)：SPR初始狀態(tài)打開狀態(tài)：經(jīng)過校驗的SPR狀態(tài)待驗狀態(tài)：SPR被修復(fù)后的狀態(tài)解決狀態(tài)：修復(fù)SPR被驗證后的狀態(tài)關(guān)閉狀態(tài)：廢棄的SPR狀態(tài)SPR生命周期五種狀態(tài)及轉(zhuǎn)換SPR生命周期中的五個狀態(tài)：SPR生命周期五種狀態(tài)及轉(zhuǎn)換122SPR生命周期五種狀態(tài)及轉(zhuǎn)換SPR生命周期五種狀態(tài)及轉(zhuǎn)換123(1)測試人員在依據(jù)測試計劃和測試用例進行測試的過程中，將發(fā)現(xiàn)的問題通過創(chuàng)建一個新的軟件問題報告提交給軟件問題報告庫，同時將軟件問題報告的狀態(tài)設(shè)為“新建”狀態(tài)。SPR生命周期五種狀態(tài)及轉(zhuǎn)換(1)測試人員在依據(jù)測試計劃和測試用例進行測試的過程中，將發(fā)124(2)負責(zé)該測試域的質(zhì)量保證人員要對該軟件問題進行校驗。如果確認這個問題存在，那么就將軟件問題報告的狀態(tài)設(shè)為“打開/再現(xiàn)”。然后將該軟件問題報告轉(zhuǎn)給負責(zé)該功能的開發(fā)人員；如果認為這個問題不是一個需要修復(fù)的問題，就將該軟件問題報告的狀態(tài)設(shè)為“關(guān)閉/不是問題”。SPR生命周期五種狀態(tài)及轉(zhuǎn)換(2)負責(zé)該測試域的質(zhì)量保證人員要對該軟件問題進行校驗。SP125(3)開發(fā)人員要及時對其負責(zé)功能域的軟件問題報告進行審查。如果發(fā)現(xiàn)該問題是其它功能域的問題，則將報告轉(zhuǎn)發(fā)給相應(yīng)的人員或部門；對軟件問題進行修復(fù)，修復(fù)完畢后要在軟件問題報告中填寫處理意見，并將軟件問題報告狀態(tài)設(shè)為“修復(fù)/待驗”，并轉(zhuǎn)給相應(yīng)的質(zhì)量保證人員進行復(fù)查；SPR生命周期五種狀態(tài)及轉(zhuǎn)換(3)開發(fā)人員要及時對其負責(zé)功能域的軟件問題報告進行審查。S126(4)質(zhì)量保證人員對“修復(fù)/待驗”狀態(tài)軟件問題報告進行驗證。如果質(zhì)量保證人員對開發(fā)人員的處理不滿意（如問題仍然再現(xiàn)或修復(fù)失敗），則將軟件問題報告重新打開，狀態(tài)設(shè)為“打開/修復(fù)失敗”，轉(zhuǎn)回開發(fā)人員重新處理；如果質(zhì)量保證人員經(jīng)過驗證，確認問題已經(jīng)修復(fù)，則將軟件問題報告狀態(tài)設(shè)為最終的“解決/修復(fù)”狀態(tài)。SPR生命周期五種狀態(tài)及轉(zhuǎn)換(4)質(zhì)量保證人員對“修復(fù)/待驗”狀態(tài)軟件問題報告進行驗證。127(5)對于“關(guān)閉/不是問題”的軟件問題報告，還可以轉(zhuǎn)為“打開/再現(xiàn)”狀態(tài)，轉(zhuǎn)移的條件就是經(jīng)過質(zhì)量保證人員的復(fù)查，確認該問題需要開發(fā)人員來解決。SPR生命周期五種狀態(tài)及轉(zhuǎn)換(5)對于“關(guān)閉/不是問題”的軟件問題報告，還可以轉(zhuǎn)為“打開1285.4.1確定測試完成標準5.4.2測試結(jié)果統(tǒng)計5.4.3測試結(jié)果分析5.4.4測試總結(jié)報告5.4測試的總結(jié)5.4.1確定測試完成標準5.4測試的總結(jié)1295.4.1確定測試完成標準

一個軟件的測試項目除了通過測試計劃、測試用例以及軟件問題報告來進行有效的管理外，如何決定什么時候停止測試是一個非常困難的問題。原因：測試不可能找出程序中的所有錯誤；限于某些條件的限制（如時間和經(jīng)費），測試不能無限期進行。5.4.1確定測試完成標準 一個軟件的測試項目除了通過130不正確的完成標準

在實際工作中，有一些常用的典型標準完全沒有意義，也毫無益處。兩個最常見的標準是：(1)測試超過了預(yù)定的時間表，則停止測試。(2)執(zhí)行了所有測試用例但沒有發(fā)現(xiàn)錯誤，則停止測試。不正確的完成標準 在實際工作中，有一些常用的典型標準完全沒131一些可參考的完成標準(1)把執(zhí)行了所有使用規(guī)范的設(shè)計方法建立的測試用例，作為判斷完成測試的基礎(chǔ)。測試用例設(shè)計方法包括：等價類劃分；邊界值分析；錯誤推測法；因果圖。一些可參考的完成標準(1)把執(zhí)行了所有使用規(guī)范的設(shè)計方法建立132一些可參考的完成標準(2)明確的指出了完成測試的要求，如直接指出要查出的錯誤數(shù)（如千行代碼錯誤數(shù)）。使用該方法要求：估計程序中錯誤的總數(shù)；估計這些錯誤中通過測試，有多少可以很容易地查出來；估計哪些錯誤產(chǎn)生于某些特定的設(shè)計過程，并且估計這些錯誤將在測試的哪個階段被查出。

一些可參考的完成標準(2)明確的指出了完成測試的要求，如直接133一些可參考的完成標準(3)

指出在某個測試階段中，單位時間內(nèi)查出錯誤的數(shù)量。 通過對這些數(shù)據(jù)的分析，一般可以確定應(yīng)該繼續(xù)測試，或是結(jié)束這一階段測試，開始下一測試分階段。

一些可參考的完成標準(3)

指出在某個測試階段中，單位時間內(nèi)134一些可參考的完成標準(4)根據(jù)各個測試階段中發(fā)現(xiàn)和修復(fù)軟件問題的趨勢曲線,作為判斷完成測試的基礎(chǔ)。 通過對這種曲線的分析，一般可以確定軟件開發(fā)和測試是否按照一個正確的方向進行。

一些可參考的完成標準(4)根據(jù)各個測試階段中發(fā)現(xiàn)和修復(fù)軟件問135測試周期與錯誤數(shù)目的關(guān)系初測期細測期回歸測試期錯誤數(shù)量時間測試周期與錯誤數(shù)目的關(guān)系初測期細測期回歸測試期錯誤數(shù)量時間136軟件問題密度分布

: 在該結(jié)果報告中，給出軟件問題相對軟件問題所在的區(qū)域、軟件問題產(chǎn)生的過程階段的分布情況。相對問題區(qū)域的分布可以幫助管理人員檢驗80/20規(guī)律（80%的問題分布在20%的區(qū)域）在該項目的具體表現(xiàn)，制訂有針對性的修改措施和質(zhì)量保證措施。相對軟件過程階段的分布是反映當(dāng)前項目還存在的軟件問題，以及軟件問題在整個項目過程中的發(fā)展趨勢。5.4.2測試結(jié)果統(tǒng)計軟件問題密度分布:5.4.2測試結(jié)果統(tǒng)計137軟件問題修改率: 修改率是對問題修改過程的工作效率的一個反映，同時指出當(dāng)前還有多少問題未得到解決或處理。5.4.2測試結(jié)果統(tǒng)計軟件問題修改率:5.4.2測試結(jié)果統(tǒng)計138軟件問題周發(fā)現(xiàn)率

: 發(fā)現(xiàn)率是對發(fā)現(xiàn)問題過程的效率的反映。該結(jié)果中按照質(zhì)量保證手段列出軟件問題周發(fā)現(xiàn)率，幫助項目管理評價哪種質(zhì)量保證措施更有效。5.4.2測試結(jié)果統(tǒng)計軟件問題周發(fā)現(xiàn)率:5.4.2測試結(jié)果統(tǒng)計139按周列出延期修復(fù)的軟件問題

:

該結(jié)果報告幫助項目管理人員在組織實行產(chǎn)品驗證和產(chǎn)品確認時，明確需求規(guī)格說明中的需求滿足情況。5.4.2測試結(jié)果統(tǒng)計按周列出延期修復(fù)的軟件問題:5.4.2測試結(jié)果統(tǒng)計140嚴重問題的生命周期分析

: 該結(jié)果是對項目過程中“解決問題”子過程的能力的反映，同時為項目管理人員的決策提供及時的警告信息。如果嚴重問題的生命周期很長，那么在一定程度上說明嚴重的問題在項目過程中未引起足夠的重視，或者因為處理問題過于困難需要更多的投入來解決問題。5.4.2測試結(jié)果統(tǒng)計嚴重問題的生命周期分析:5.4.2測試結(jié)果統(tǒng)計141測試結(jié)束后，必須編寫《測試分析報告》，對測試結(jié)果加以總結(jié)歸納。

（1）產(chǎn)品標識；

（2）使用的配置；

（3）使用的文檔；

（4）產(chǎn)品說明、用戶文檔、程序和數(shù)據(jù)的測試結(jié)果分析；

（5）與需求不相符的功能項列表；

（6）測試的最終日期。5.4.3測試結(jié)果分析測試結(jié)束后，必須編寫《測試分析報告》，對測試結(jié)果加以總結(jié)歸納142從四個方面對測試結(jié)果進行分析：能力缺陷和限制建議評價5.4.3測試結(jié)果分析從四個方面對測試結(jié)果進行分析：5.4.3測試結(jié)果分析143能力：

論述經(jīng)測試證實了的本軟件的能力。如果所進行的測試是為了驗證一項或幾項特定性能要求的實現(xiàn)，應(yīng)提供這方面的測試結(jié)果與要求之間的比較，并確定測試環(huán)境與實際運行環(huán)境之間可能存在的差異對能力的測試所帶來的影響。5.4.3測試結(jié)果分析能力：5.4.3測試結(jié)果分析144缺陷和限制：

論述經(jīng)測試證實的軟件缺陷和限制，說明每項缺陷和限制對軟件性能的影響，并說明全部測得的性能缺陷的累積影響和總影響。5.4.3測試結(jié)果分析缺陷和限制：5.4.3測試結(jié)果分析145建議：

對每項缺陷提出改進建議，如：

（1）各項修改可采用的方法

（2）各項修改的緊迫程度

（3）各項修改預(yù)計的工作量

（4）各項修改的負責(zé)人5.4.3測試結(jié)果分析建議：5.4.3測試結(jié)果分析146評價：

說明該項軟件的開發(fā)是否已達到預(yù)定目標，能否交付使用。5.4.3測試結(jié)果分析評價：5.4.3測試結(jié)果分析147

在測試完成之后，需要編寫測試總結(jié)報告。測試總結(jié)報告是把測試的過程和結(jié)果寫成文檔，并對發(fā)現(xiàn)的問題和缺陷進行分析，為糾正軟件的存在的質(zhì)量問題提供依據(jù)，同時為軟件驗收和交付打下基礎(chǔ)。5.4.4測試總結(jié)報告 在測試完成之后，需要編寫測試總結(jié)報告。測試總結(jié)報告是把測148

測試總結(jié)報告的內(nèi)容 測試總結(jié)報告是測試階段最后的文檔產(chǎn)出物，優(yōu)秀的測試經(jīng)理應(yīng)該具備良好的文檔編寫能力，一份詳細的測試總結(jié)報告包含足夠的信息，包括產(chǎn)品質(zhì)量和測試過程的評價，測試報告基于測試中的數(shù)據(jù)采集以及對最終的測試結(jié)果分析。 測試總結(jié)報告的內(nèi)容 測試總結(jié)報告是測試階段最后的文檔產(chǎn)出149測試總結(jié)報告模板測試總結(jié)報告模板150

測試總結(jié)報告模板 測試總結(jié)報告模板151

測試總結(jié)報告模板 測試總結(jié)報告模板152

測試總結(jié)報告模板 測試總結(jié)報告模板153

測試總結(jié)報告模板 測試總結(jié)報告模板154

測試總結(jié)報告模板 測試總結(jié)報告模板155

測試總結(jié)報告模板 測試總結(jié)報告模板156

測試總結(jié)報告模板 測試總結(jié)報告模板157

測試總結(jié)報告模板 測試總結(jié)報告模板158信息系統(tǒng)測試

的設(shè)計、組織和實施

5.1測試的計劃5.2測試的設(shè)計5.3測試的執(zhí)行5.4測試的總結(jié)

信息系統(tǒng)測試

的設(shè)計、組織和實施5.1測試的計劃159軟件測試實施過程

測試計劃測試設(shè)計測試執(zhí)行測試總結(jié)軟件測試實施過程測試計劃測試設(shè)計測試執(zhí)行測試總結(jié)1605.1測試的計劃5.1.1測試類型的選擇 有各種各樣不同的測試類型，在測試計劃階段，要根據(jù)系統(tǒng)的功能和特性、經(jīng)費和時間等諸多方面因素，選擇不同的測試方案，進而選擇不同的測試類型。5.1測試的計劃5.1.1測試類型的選擇16122種測試類型（1）黑盒測試：不基于程序內(nèi)部設(shè)計和代碼的任何知識，而是基于系統(tǒng)需求和功能。（2）白盒測試：基于一個應(yīng)用代碼的內(nèi)部邏輯結(jié)構(gòu)，測試是基于覆蓋全部代碼、分支、路徑、條件。22種測試類型（1）黑盒測試：16222種測試類型（3）單元測試：測試功能模塊。典型的單元測試是由程序員而非測試員來做，因為它需要知道內(nèi)部程序設(shè)計和編碼的細節(jié)知識。這個工作不容易作好，除非應(yīng)用系統(tǒng)有一個設(shè)計很好的體系結(jié)構(gòu)，還可能需要開發(fā)測試驅(qū)動器模塊。22種測試類型（3）單元測試：16322種測試類型（4）增量測試：當(dāng)一個新功能增加后，對應(yīng)用系統(tǒng)所做的連續(xù)測試。它要求應(yīng)用系統(tǒng)的不同形態(tài)的功能部件能夠足夠獨立，以便可以在全部系統(tǒng)完成之前各部件能夠分別工作。這種測試可由程序員或測試員來做。22種測試類型（4）增量測試：16422種測試類型（5）集成測試：一個應(yīng)用系統(tǒng)的各個部件的聯(lián)合測試，以決定他們能否在一起共同工作。部件可以是代碼塊、獨立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序。這種類型的測試尤其與客戶/服務(wù)器和分布式系統(tǒng)有關(guān)。22種測試類型（5）集成測試：16522種測試類型（6）功能測試：用于測試應(yīng)用系統(tǒng)的功能需求的黑盒測試方法。這類測試應(yīng)由測試員做，這并不意味著程序員在發(fā)布前不必檢查他們的代碼能否工作，所以功能測試能用于測試的各個階段。22種測試類型（6）功能測試：16622種測試類型（7）系統(tǒng)測試： 基于系統(tǒng)整體需求說明書的測試；應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。22種測試類型（7）系統(tǒng)測試：16722種測試類型（8）端到端測試： 類似于系統(tǒng)測試；涉及整個應(yīng)用系統(tǒng)環(huán)境在一個現(xiàn)實世界使用時的模擬情形的所有測試。例如與數(shù)據(jù)庫對話、與網(wǎng)絡(luò)通訊，或與外部硬件、應(yīng)用系統(tǒng)或適當(dāng)?shù)南到y(tǒng)對話。22種測試類型（8）端到端測試：16822種測試類型（9）健全測試： 典型地是指一個初始化的測試工作，以決定一個新的軟件版本測試是否足以執(zhí)行下一步大的測試努力。例如，如果一個新版軟件每5分鐘經(jīng)常與系統(tǒng)發(fā)生沖突，使系統(tǒng)陷于癱瘓，說明該軟件不夠“健全”，說明該軟件現(xiàn)在還不具備進一步測試的條件。22種測試類型（9）健全測試：16922種測試類型（10）回歸測試： 軟件或環(huán)境的修復(fù)或更正后的“再測試”?？赡芎茈y確定需要多少遍再次測試。尤其在接近開發(fā)周期結(jié)束時更需要衰竭測試。因為自動測試工具一般都具有錄制和回放功能，并且可以利用腳本語言編寫測試程序，所以自動測試工具對這類測試尤其有用。22種測試類型（10）回歸測試：17022種測試類型（11）接受測試：

基于客戶或最終用戶的規(guī)格說明書的最終測試，或基于用戶一段時間的使用后，看軟件是否滿足客戶要求。22種測試類型（11）接受測試：17122種測試類型（12）負載測試：

測試一個應(yīng)用在重負載下的表現(xiàn)，例如測試一個Web站點在大量的負載下，系統(tǒng)的響應(yīng)何時會退化或失敗。22種測試類型（12）負載測試：17222種測試類型（13）壓力測試： 在交替進行負載和性能測試時常用的術(shù)語。也用于描述在異乎尋常的重載下的系統(tǒng)功能測試之類的測試，如某個動作或輸入大量的重復(fù)，大量數(shù)據(jù)的輸入，對一個數(shù)據(jù)庫系統(tǒng)大量的復(fù)雜查詢等。22種測試類型（13）壓力測試：17322種測試類型（14）性能測試：

在交替進行負在和壓力測試時常用的術(shù)語。理想的“性能測試”(或其他類型的測試)應(yīng)在需求文檔、質(zhì)量保證文檔或測試計劃中定義。22種測試類型（14）性能測試：17422種測試類型（15）可用性測試： 對“用戶友好性”的測試。顯然這是主觀的，測試標準將取決于目標最終用戶或客戶。用戶面談、調(diào)查、用戶對話的錄像和其他一些技術(shù)都可使用。程序員和測試員通常都不宜作可用性測試員。22種測試類型（15）可用性測試：17522種測試類型（16）安裝/卸載測試： 對軟件的全部、部分或升級版本進行安裝/卸載處理過程的測試。22種測試類型（16）安裝/卸載測試：17622種測試類型（17）恢復(fù)測試： 測試一個系統(tǒng)從災(zāi)難中能否很好地恢復(fù)，如遇到系統(tǒng)崩潰、硬件損壞或其他災(zāi)難性問題。22種測試類型（17）恢復(fù)測試：17722種測試類型（18）安全測試： 測試系統(tǒng)在防止非授權(quán)的內(nèi)部或外部用戶的訪問或故意破壞等情況時如何保證系統(tǒng)正常工作。這可能需要復(fù)雜的測試技術(shù)。22種測試類型（18）安全測試：17822種測試類型（19）兼容測試： 測試該軟件在一組不同類型的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)等環(huán)境下的性能。22種測試類型（19）兼容測試：17922種測試類型（20）比較測試：

與競爭伙伴的產(chǎn)品的比較測試，如軟件的優(yōu)點、缺點或?qū)嵙Α?2種測試類型（20）比較測試：18022種測試類型（21）Alpha測試： 在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試；測試后，仍然會有少量的設(shè)計變更。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。22種測試類型（21）Alpha測試：18122種測試類型（22）Beta測試： 當(dāng)開發(fā)和測試小組已經(jīng)基本完成所要求的測試后，需要通過Beta測試在軟件最終發(fā)行前去發(fā)現(xiàn)一些錯誤和問題。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。22種測試類型（22）Beta測試：1825.1.2測試策略的制定

測試策略描述測試小組用于測試整體和每個階段的方法。 測試策略的制定是一項復(fù)雜的工作，需要由經(jīng)驗豐富的測試員來做，因為這將決定測試工作的成敗。

5.1.2測試策略的制定 測試策略描述測試小組用于測試整體183問題的提出

是使用黑盒測試方法，還是使用白盒測試方法？如果決定綜合使用這兩種方法，那么在軟件的哪些部分，什么時候分別運用它們呢？問題的提出是使用黑盒測試方法，還是使用白盒測試方法？184問題的提出是使用手工測試？還是需要用測試工具和自動化測試？如果要使用工具，那么是否需要開發(fā)，或者購買已有的商用測試工具？如果購買商用測試工具，選購哪一種工具？問題的提出是使用手工測試？還是需要用測試工具和自動化測試？185問題的提出是開發(fā)單位自己測試？還是請專業(yè)的測試公司測試？如果請專業(yè)的測試公司測試，只要派出相應(yīng)的質(zhì)量保證人員監(jiān)督他們的工作即可。問題的提出是開發(fā)單位自己測試？還是請專業(yè)的測試公司測試？186制定測試策略的目的 測試策略描述測試過程的總體方法和目標，描述目前在進行哪一階段的測試（單元測試、集成測試、系統(tǒng)測試）以及每個階段內(nèi)在進行的測試種類（功能測試、性能測試、覆蓋測試等）。制定測試策略的目的 測試策略描述測試過程的總體方法和目標，描187（1）一般的測試策略

測試開始于單元級，然后“延伸”到整個系統(tǒng)中。不同的測試技術(shù)適用于不同的時間點。測試是由軟件的開發(fā)人員和獨立測試組織來管理的。（1）一般的測試策略測試開始于單元級，然后“延伸”到整個系188（2）黑盒測試的測試策略1．用邊界值分析法和（或）等價類劃分法提出基本的測試用例；

2．用錯誤猜測法補充新的測試用例；

3．如果在程序的功能說明中含有輸入條件的組合，則在測試一開始時就使用因果圖法，然后再按以上1、2兩種步驟進行。（2）黑盒測試的測試策略1．用邊界值分析法和（或）等價類劃分189（3）單元測試的測試策略1．首先用黑盒測試方法，設(shè)計一組基本測試用例進行測試。如果發(fā)現(xiàn)未能滿足覆蓋標準，就用白盒測試法補充新的測試用例2．首先用白盒測試法分析模塊的邏輯結(jié)構(gòu)，設(shè)計一批測試用例進行測試。如果發(fā)現(xiàn)未能滿足覆蓋標準，根據(jù)模塊的功能用黑盒測試法進行補充。（3）單元測試的測試策略1．首先用黑盒測試方法，設(shè)計一組基本1905.1.3成立測試組織

為了盡可能多地找出程序中的錯誤，生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，加強對測試工作的組織和管理就顯得尤為重要。

5.1.3成立測試組織 為了盡可能多地找出程序中的錯誤，生產(chǎn)191對軟件測試管理的要求l

測試必須是有計劃的。l

測試必須是有組織的。l

測試必須是有準備的。l

測試必須是可管理的。l

測試必須是可記錄的。l

測試必須是可追蹤的。對軟件測試管理的要求l

測試必須是有計劃的。192軟件項目的組織和任務(wù)如何有效地管理和實施一個軟件項目?在早期軟件開發(fā)中，沒有專門的軟件測試部門和測試人員。軟件測試工作通常是由開發(fā)人員自己來完成的。隨著軟件開發(fā)規(guī)模的不斷增大，軟件開發(fā)和軟件測試逐步分離為兩個獨立的部門。為了管理軟件項目，還必須有一個軟件項目管理部門。軟件項目的組織和任務(wù)如何有效地管理和實施一個軟件項目?193軟件項目開發(fā)過程

定義：

一個軟件項目的開發(fā)過程，實際上就是一個在軟件項目管理部門的控制之下、在一定的時間和財政預(yù)算范圍內(nèi)、由軟件開發(fā)部門和軟件測試部門協(xié)同工作完成的從項目立項直到軟件產(chǎn)品發(fā)布的全過程。

軟件項目開發(fā)過程定義： 1941.測試組織結(jié)構(gòu)

（1）管理部門

（2）開發(fā)部門（3）測試部門

1.測試組織結(jié)構(gòu)（1）管理部門195測試組織各部門的職責(zé)管理部門：負責(zé)整個軟件項目的計劃、實施、進度調(diào)整，以及產(chǎn)品的發(fā)布等工作。開發(fā)部門：專職于程序編碼、系統(tǒng)集成和軟件問題修復(fù)等開發(fā)工作。測試部門：專職于測試準備、測試實施、編寫軟件問題報告等測試工作。

測試組織各部門的職責(zé)管理部門：負責(zé)整個軟件項目的計劃、實施、196(1)管理部門的組成和任務(wù)管理部門的組成：軟件項目經(jīng)理軟件開發(fā)部經(jīng)理軟件測試部經(jīng)理若干關(guān)鍵技術(shù)人員(1)管理部門的組成和任務(wù)管理部門的組成：197(1)管理部門的組成和任務(wù)軟件項目管理部門的任務(wù)：(1)制定或修改軟件開發(fā)計劃和測試計劃。(2)對整個軟件項目的進度進行評估。(3)對一些重大問題進行決策，確保軟件開發(fā)項目按計劃保質(zhì)量地完成。(4)決定每周要完成的開發(fā)和測試任務(wù)。(5)協(xié)調(diào)和解決各個部門之間發(fā)生的問題。(6)決定提前或推后發(fā)布軟件。(1)管理部門的組成和任務(wù)軟件項目管理部門的任務(wù)：198(2)開發(fā)部門的組成和任務(wù)開發(fā)部門的組成：軟件開發(fā)部經(jīng)理若干軟件開發(fā)工程師(2)開發(fā)部門的組成和任務(wù)開發(fā)部門的組成：199(2)開發(fā)部門的組成和任務(wù)開發(fā)部門的任務(wù)：(1)按照軟件開發(fā)計劃及開發(fā)時間進度表，編寫和集成程序代碼。(2)對測試部門發(fā)現(xiàn)的軟件問題進行分析，確定修改的優(yōu)先級。(3)修復(fù)軟件問題并進行軟件系統(tǒng)集成，生產(chǎn)新的測試版本，在提交給測試部門之前進行基線檢查。(4)將新的軟件測試版本提交給測試部門進行驗證。(2)開發(fā)部門的組成和任務(wù)開發(fā)部門的任務(wù)：200(3)測試部門的組成和任務(wù)測試部門的組成：軟件測試部門經(jīng)理若干質(zhì)量保證人員若干軟件測試工程師(3)測試部門的組成和任務(wù)測試部門的組成：201(3)測試部門的組成和任務(wù)測試部門的任務(wù)：(1)在軟件測試工作開始之前，編寫測試計劃和測試用例。(2)按照軟件測試計劃、測試用例及時間進度表，進行軟件測試。(3)對發(fā)現(xiàn)的軟件問題編寫軟件問題報告，并及時提交給軟件開發(fā)部門。(4)在開發(fā)部門提供的新測試版本上，對修復(fù)的軟件問題進行驗證。(5)在新測試版本上，開始新一輪測試或繼續(xù)前一階段測試，并報告軟件問題。(3)測試部門的組成和任務(wù)測試部門的任務(wù)：2022.測試部門和開發(fā)部門的關(guān)系基本原則:避免一個組織測試自已編寫的程序，原因是開發(fā)組織很難客觀地測試自己的程序。成立獨立的軟件測試機構(gòu)進行軟件測試。測試組織與開發(fā)組織之間的關(guān)系越遠越好。優(yōu)點： 發(fā)現(xiàn)錯誤效率高，測試組織與開發(fā)組織之間有正常的競爭。2.測試部門和開發(fā)部門的關(guān)系基本原則:203測試組織與開發(fā)組織的耦合程度l

測試組織與開發(fā)組織屬于不同公司、不同城市、甚至不同國家；l

測試組織與開發(fā)組織屬于同一公司不同部門；l

測試組織與開發(fā)組織屬于同一公司同一部門，但不在同一小組；l

測試組織與開發(fā)組織屬于同一公司同一部門同一小組內(nèi)，但測試人員與開發(fā)人員為不同人員；l

測試組織與開發(fā)組織為同一公司同一部門同一小組，并且測試人員與開發(fā)人員為同一組人員。測試組織與開發(fā)組織的耦合程度l測試組織與開發(fā)組織屬于不同2043.測試人員的素質(zhì)（1）溝通能力（2）技術(shù)能力（3）自信心（4）外交能力（5）幽默感（6）很強的記憶力（7）懷疑精神（8）自我督促（9）洞察力3.測試人員的素質(zhì)（1）溝通能力2055.1.4建立測試配置1．測試配置的內(nèi)容人員：人數(shù)、經(jīng)驗和專長，全職、兼職或?qū)W生。設(shè)備：計算機，打印機等。測試環(huán)境：硬件、軟件環(huán)境。測試工具：黑盒或白盒測試工具。辦公室或?qū)嶒炇遥旱攸c，大小等。專業(yè)測試公司：是否需要，費用如何。其他需求：移動存儲器，電話，通訊等。5.1.4建立測試配置1．測試配置的內(nèi)容2065.1.4建立測試配置2．測試環(huán)境配置主測試環(huán)境配置輔測試環(huán)境配置5.1.4建立測試配置2．測試環(huán)境配置207主測試環(huán)境配置（1）符合軟件運行的最低要求。測試環(huán)境首先要保證能支撐軟件正常運行。（2）選用比較普及的操作系統(tǒng)和軟件平臺。例如，一個軟件若聲稱支持“Windows9X/ME/NT/2000professional”和“MSOffice97/2000/XP”，一般我們會采用如“Windows2000professional+MSOffice2000”的流行環(huán)境。（3）營造相對簡單、獨立的測試環(huán)境。除了操作系統(tǒng)，測試機上只安裝軟件運行和測試必需的軟件，以免不相關(guān)的軟件影響測試實施。（4）無毒的環(huán)境。利用有效的正版殺毒軟件檢測軟件環(huán)境，保證測試環(huán)境中沒有病毒。主測試環(huán)境配置（1）符合軟件運行的最低要求。測試環(huán)境首先要保208輔助測試環(huán)境配置（1）兼容性測試：在滿足軟件運行要求的范圍內(nèi)，可選擇一些典型的操作系統(tǒng)和常用應(yīng)用軟件對其安裝卸載和主要功能進行驗證。（2）模擬真實環(huán)境測試：有些軟件，特別是面向大眾的商品化軟件，在測試時常常需要考察在真實環(huán)境中的表現(xiàn)。如測試殺毒軟件的掃描速度時，硬盤上布置的不同類型文件的比例要盡量接近真實環(huán)境，這樣測試出來的數(shù)據(jù)才有實際意義。（3）橫向?qū)Ρ葴y試：利用輔測試環(huán)境“克隆”出完全一致的測試環(huán)境，從而保證各個被測軟件平等對比。輔助測試環(huán)境配置（1）兼容性測試：在滿足軟件運行要求的范圍內(nèi)2095.1.5制定測試計劃 測試計劃是對測試工作的總體描述。5.1.5制定測試計劃 測試計劃是對測試工作的總體描述。2101．測試計劃的重要性有條不紊地仔細制定測試計劃，是達成測試目標的必由之路。一個良好的、完善的測試計劃是進行成功測試的基礎(chǔ)。必須要制定一個能夠起到總體框架作用的測試計劃。測試的計劃應(yīng)該作為測試的起始步驟和重要環(huán)節(jié)。1．測試計劃的重要性有條不紊地仔細制定測試計劃，是達成測試目211制定測試計劃的重要性和必要性組織性： 即使在小型軟件測試項目上，也可能有數(shù)千個測試用例。建立測試用例可能需要一些測試員經(jīng)過幾個月甚至幾年的時間。正確的計劃會組織好測試用例，以便全體測試員和其他項目小組成員有效地審查和使用。制定測試計劃的重要性和必要性組織性：212制定測試計劃的重要性和必要性重復(fù)性：

在項目開發(fā)期間內(nèi)有必要多次執(zhí)行同樣的測試，以尋找新的系統(tǒng)缺陷，保證老的缺陷得以修復(fù)。假如沒有正確的測試計劃，就不可能知道最后執(zhí)行哪些測試用例及其執(zhí)行情況，以便重復(fù)原有的測試。制定測試計劃的重要性和必要性重復(fù)性：213制定測試計劃的重要性和必要性測試跟蹤： 在整個項目開發(fā)期間，計劃執(zhí)行多少個測試用例？在系統(tǒng)最終版本上執(zhí)行多少個測試用例？多少個通過，多少個失敗？有無忽略的測試用例？等等。如果沒有測試計劃，就不能回答這些問題。制定測試計劃的重要性和必要性測試跟蹤：214制定測試計劃的重要性和必要性測試驗證：

在少數(shù)高風(fēng)險行業(yè)中，測試小組必須證明確實執(zhí)行了計劃執(zhí)行的測試。發(fā)布忽略某些測試用例的系統(tǒng)實際上是不合法和危險的。正確的測試計劃和測試跟蹤提供了一種驗證手段。制定測試計劃的重要性和必要性測試驗證：2152．測試計劃的內(nèi)容包括：產(chǎn)品調(diào)研；測試需求說明；測試策略；測試記錄；測試資源配置；計劃時間表；軟件問題報告跟蹤；計劃評審。2．測試計劃的內(nèi)容包括：216（1）產(chǎn)品調(diào)研這部分應(yīng)包括產(chǎn)品的一些基本情況介紹。目的變更信息軟件結(jié)構(gòu)及技術(shù)軟件產(chǎn)品規(guī)格測試范圍項目信息（1）產(chǎn)品調(diào)研這部分應(yīng)包括產(chǎn)品的一些基本情況介紹。217目的： 重點描述如何使測試建立在客觀的基礎(chǔ)上，定義測試的策略，測試的配置，粗略的估計測試大致需要的周期和最終測試報告遞交的時間。目的： 重點描述如何使測試建立在客觀的基礎(chǔ)上，定義測試的策略218變更信息： 說明有可能會導(dǎo)致測試計劃變更的事件。包括測試工具改進了，測試的環(huán)境改變了，或者是添加了新的功能。變更信息： 說明有可能會導(dǎo)致測試計劃變更的事件。包括測試工具219軟件結(jié)構(gòu)及技術(shù)：

將被測軟件劃分成幾個組成部分，規(guī)劃成一個適用于測試的完整的系統(tǒng)，包括數(shù)據(jù)是如何存儲的，如何傳遞的（數(shù)據(jù)流圖），每一個部分的測試是要達到什么樣的目的。每一個部分是怎么實現(xiàn)數(shù)據(jù)更新的。還有一些常規(guī)性的技術(shù)要求，比如運行平臺、需要什么樣的數(shù)據(jù)庫等等。軟件結(jié)構(gòu)及技術(shù)： 將被測軟件劃分成幾個組成部分，規(guī)劃成一個適220軟件產(chǎn)品規(guī)格： 就是制造商和產(chǎn)品版本號的說明，還可以包括關(guān)于被測系統(tǒng)的重要說明，如版權(quán)，日期等。

軟件產(chǎn)品規(guī)格： 就是制造商和產(chǎn)品版本號的說明，還可以包括關(guān)于221