軟件集成測試工作流程及其系統(tǒng)測試工作手冊

1、57/57模版集萃(軟件質(zhì)量保證類)綜述：在程序員的日常工作中，除了編寫代碼之外，還免不了需要編寫各種技術文檔。一個編寫良好的技術文檔在項目中能夠?qū)ｉT好地建立溝通與協(xié)作，起到專門積極的作用。因此，編寫技術文檔也就成為了程序員技能提升的專門重要的一面。為此，我們專門收集了一些在項目開發(fā)過程中經(jīng)常用到的文檔模板，這些模板包括格式和簡單的寫作講明，相信能夠關心大伙兒編寫出更加高效、有用的技術文檔。在收集過程中，我們十分注重事實上用性，以確保每個模板的價值，而且關于一些重要的文檔提供了多個模板。為了方便大伙兒查找，我們將收錄的57模板分為以下幾類：項目及開發(fā)治理類：包括立項前的分析，立項后的打算、以及

2、進度跟蹤、風險操縱方面的文檔模板，共計16個；需求分析類：明確清晰的需求，是項目成功的基礎，在此收集了在需求分析過程中所將使用到的文檔模板，共計14個；系統(tǒng)分析與設計類：包括體系結(jié)構(gòu)設計、高層設計、詳細設計、數(shù)據(jù)庫設計等6個相關文檔模板；軟件質(zhì)量保證類：軟件測試是質(zhì)量保證的關鍵活動，在此收集了軟件測試相關的11個文檔模板；其它類：除此之外，還收集了關于用戶手冊、軟件維護等方面的10個文檔模板，其中還有一個軟件過程規(guī)范的示例。另外，值得講明的是，文檔模板只是為文檔的編寫提供一個基礎，在實際的編寫過程中，你能夠依照自己的需要進行必要的剪裁和增補。測試打算編者講明： 要想系統(tǒng)性地完成一件事，首先要做

3、好打算，測試工作是十分重要的，因此測試打算也是十分必要的。該文檔適用于集成測試、系統(tǒng)測試、驗收測試的打算制訂，并不適用于單元測試打算。第1章引言1.1綜述1.2參考文獻序號名稱文件標識/版本出版單位出版日期第2章測試項2.1測試項測試項名稱測試項標識介質(zhì)特性變換要求相關引用材料2.2不測試的軟件項軟件項名稱軟件項標識未測試緣故相關引用材料第3章被測試的特性特性或組合名稱測試設計講明編號第4章不被測試的特性特性或組合名稱測試設計講明編號第5章方法5.15.2第6章項通過準則第7章暫停標準和再啟動要求7.1暫停標準7.2再啟動要求第8章應提供的測試文檔文檔名稱標識符第9章測試任務序號任務前期任務專

4、門技能責任人工作量（天）完成日期第10章環(huán)境要求10.1硬件10.2軟件10.3安全性10.4工具10.5文檔第11章職責11.1測試組11.2開發(fā)組11.3第12章人員和培訓要求12.1人員12.1.1測試組12.2培訓第13章進度13.1進度序號測試任務名稱工作量開始日期完成日期13.2測試資源使用期限第14章風險和應急測試日志編者講明： 測試都有一個結(jié)果，而這些結(jié)果關于軟件質(zhì)量保證活動來講是十分重要的，因此應該將這些結(jié)果有序地記錄下來，這確實是測試日志模板所要解決的問題。第1章描述1.1測試項序號測試項名稱標識符版本相關傳遞報告1.2測試的環(huán)境1.2.1硬件1.2.2軟件第2章活動和事件

5、條目2.1時刻活動描述事件2.2測試設計講明編者講明： 假如講測試打算是對測試的活動、人員進行安排，那么測試設計則是對測試方法、測試技術的講明。第1章被測試的特性1.1單項特性1.2組合特性1.3引用文檔第2章方法詳述2.1方法描述2.2測試評價標準2.3測試用例選擇原則2.4測試用例的共同屬性和依靠關系測試用例講明編者講明： 測試打算解決的是如何安排測試活動，測試設計講明是如何測試，那么測試用例講明確實是測試什么，也確實是列出具體的測試項目，以使得測試有目的、有打算。第1章測試項1.1測試項名稱測試項名稱標識符講明1.2引用文檔編號文檔名稱章節(jié)名第2章輸入講明序號名稱值類型同意誤差輸入方式第

6、3章輸出講明序號名稱值類型同意誤差輸出方式第4章環(huán)境要求4.1硬件4.2軟件4.3其它第5章專門的規(guī)程要求第6章用例間的依靠關系6.1所依靠的用例序號用例名稱或標識6.2依靠關系的性質(zhì)集成測試打算(ISO標準)編者講明： 前面的測試打算模板是一個通用性的，也能夠是用于制定所有測試活動的打算，而本模塊則是用來指導編寫集成測試打算的。1.引言1.1編寫目的 講明編寫這份測試打算目的，指出預期的讀者。1.2背景a.待開發(fā)系統(tǒng)的名稱；b.列出本項目的任務提出者、開發(fā)者、用戶。1.3定義 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4參考資料 列出有關的參考資料。2打算2.1系統(tǒng)講明提

7、供一份圖表，并逐項講明被測系統(tǒng)的功能、輸入、輸出等質(zhì)量指標，作為敘述測試打算的提綱。2.2測試內(nèi)容列出集成測試和確認測試中的每一項測試內(nèi)容的名稱標識符、這些測試的進度安排以及這些測試的內(nèi)容和目的。2.3測試1（標識符） 給出這項測試內(nèi)容的參與單位及被測試的部位。2.3.1進度安排 給出對這項測試的進度安排，包括進行測試的日期和工作內(nèi)容。2.3.2條件 陳述本項測試工作對資源的要求。包括：a.硬件b.軟件c.人員2.3.3測試資料 列出本項測試所需的資料。2.3.4測試培訓講明或引用資料講明為被測系統(tǒng)的使用提供培訓的打算。規(guī)定培訓的內(nèi)容、受訓的人員及從事培訓的工作人員。2.4測試2（標識符）用與

8、本測試打算2。3條相類似的方式講明用于另一項及其后各項測試內(nèi)容的測試工作打算。 3測試設計講明3.1測試1（標識符） 講明對第一項測試內(nèi)容的測試設計考慮。3.1.1操縱 講明本測試的操縱方式。3.1.2輸入 講明本項測試中所使用的輸入數(shù)據(jù)及選擇這些輸入數(shù)據(jù)的策略。3.1.3輸出 講明預期的輸出數(shù)據(jù)。3.1.4過程 講明完成此項測試的一個個步驟和操縱命令。3.2測試2（標識符）用與本測試打算3。1條相類似的方式講明第2項及其后各項測試工作的設計考慮。 4評價準則4.1范圍 講明所選擇的測試用例能夠檢查的范圍及其局限性。4.2數(shù)據(jù)整理陳述為了把測試數(shù)據(jù)加工成便于評價的適當形式，使得測試結(jié)果能夠同已

9、知結(jié)果進行比較而要用到的轉(zhuǎn)換處理技術；假如是用自動方式整理數(shù)據(jù)，還要講明為進行處理而要用到的硬件、軟件資源。4.3尺度講明用來推斷測試工作是否能通過的評價尺度，如合理和輸出結(jié)果的類型、測試輸出結(jié)果與預期輸出之間的容許偏離范圍、同意中斷或停機的最大數(shù)。軟件集成測試工作流程指南編者講明： 嚴格地講，該文檔不屬于文檔模板，它只是一個工作指南。要想更好地完成集成測試工作，你就需要為團隊制定一個工作指南。你能夠依照該文檔，結(jié)合實際進行修改。1. 簡介1.1 目的本文詳細闡述了集成測試流程，指導項目開發(fā)人員如何開展軟件集成測試。1.2 范圍此指南可運用于使用RUP 的任一軟件項目的集成測試。1.3 參考文

10、件Software Test ProcessRational Unified Process1.4 定義與縮寫RUP：統(tǒng)一開發(fā)過程SIT：軟件集成測試SEPG：軟件工程過程小組SQA：軟件質(zhì)量保證2. 集成測試指南2.1 簡介集成測試的目的是確保各單元組合在一起后能夠按既定意圖協(xié)作運行，并確保增量的行為正確。它所測試的內(nèi)容包括單元間的接口以及集成后的功能。使用黑盒測試方法測試集成的功能。同時對往常的集成進行回歸測試。2.2 單元測試工作內(nèi)容及其流程活動輸入工件輸出工件參與角色和職責制定集成測試打算設計模型集成構(gòu)建打算集成測試打算測試設計員負責制定集成測試打算設計集成測試集成測試打算設計模型集成

11、測試用例測試過程測試設計員負責設計集成測試用例和測試過程。實施集成測試集成測試用例測試過程工作版本測試腳本（可選）測試過程（更新）測試設計員負責編制測試腳本（可選），更新測試過程。驅(qū)動程序或穩(wěn)定樁設計員負責設計驅(qū)動程序和樁，實施員負責實施驅(qū)動程序和樁。執(zhí)行集成測試測試腳本（可選）工作版本測試結(jié)果測試員負責執(zhí)行測試并記錄測試結(jié)果評估集成測試集成測試打算測試結(jié)果測試評估摘要測試設計員負責會同集成員、編碼員、設計員等有關人員（具體化）評估此次測試，并生成測試評估摘要。2.3 集成測試需求獵取集成測試需求所確定的是對某一集成工作版本的測試的內(nèi)容，即測試的具體對象。集成測試需求要緊來源于設計模型（Des

12、ign Model ）和集成構(gòu)件打算（Integration Build Plan ）。集成測試著重于集成版本的外部接口的行為。因此，測試需求須具有可觀測、可測評性。1.集成工作版本應分析其類協(xié)作與消息序列，從而找出該工作版本的外部接口。2.由集成工作版本的外部接口確定集成測試用例。3.測試用例應覆蓋工作版本每一外部接口的所有消息流序列。注意：一個外部接口和測試用例的關系是多對多，部分集成工作版本的測試需求可映射到系統(tǒng)測試需求，因此對這些集成測試用例可采納重用系統(tǒng)測試用例技術。2.4 集成測試工作機制軟件集成測試工作由產(chǎn)品評測部擔任。需要項目組相關角色配合完成。如圖示：軟件評測部：角色職責測試

13、設計員負責制定集成測試打算、設計集成測試、實施集成測試、評估集成測試。測試員執(zhí)行集成測試，記錄測試結(jié)果。軟件項目組：角色職責實施員負責實施類（包括驅(qū)動程序和樁），并對其進行單元測試。依照集成測試發(fā)覺的缺陷提出變更申請。配置治理員負責對測試工件進行配置治理。設計員負責設計測試驅(qū)動程序和樁。依照集成測試發(fā)覺的缺陷提出變更申請。集成測試工作內(nèi)容及其流程工作流程：Desinger：開發(fā)設計模型Desinger：開發(fā)設計模型Integrator：制定集成打算Implementer ：實施類，進行單元測試Test Designer ：制定集成測試打算，設計集成測試用例、測試過程、測試腳本Tester ：執(zhí)

14、行集成測試，生成測試日志Designer & Implementer ：提出變更請求變更流程Test Designer ：評估集成測試，生成評估摘要缺陷2.5 集成測試產(chǎn)生的工件清單1、軟件集成測試打算2、集成測試用例3、測試過程4、測試腳本5、測試日志6、測試評估摘要軟件系統(tǒng)測試工作指南編者講明： 這是一個系統(tǒng)測試的工作指南。你能夠依照該文檔，結(jié)合實際進行修改。1. 簡介1.1 目的本文詳細闡述了系統(tǒng)測試的類型以及各個類型的差不多測試方法，指導項目開發(fā)人員進行軟件系統(tǒng)測試。1.2 范圍本文適用于使用RUP 的所有軟件項目的系統(tǒng)測試工作。1.3 文檔結(jié)構(gòu)第一部分：簡介，介紹軟件系統(tǒng)測試指南的目

15、的，本指南的適用范圍，以及在本文檔中使用的術語的解釋。第二部分：描述系統(tǒng)測試指南。包括系統(tǒng)測試流程、系統(tǒng)測試需求的獵取、系統(tǒng)測試側(cè)策略選擇、系統(tǒng)測試技術和方法等。第三部分：列出本指南使用的參考文獻。1.4 詞匯表系統(tǒng)測試（System Testing）：系統(tǒng)測試是通過與系統(tǒng)的需求規(guī)格作比較，發(fā)覺軟件與系統(tǒng)需求規(guī)格不相符合或與之矛盾的地點。它將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合起來，在實際運行（使用）環(huán)境下，對計算機系統(tǒng)進行的測試。黑盒測試（Black-Box Testing）：黑盒測試是基于系統(tǒng)需求規(guī)格，在不明白

16、系統(tǒng)或組件的內(nèi)部結(jié)構(gòu)的情況下進行的測試。通常又將黑盒測試叫做：基于規(guī)格的測試（Specification-Based Testing ）、輸入輸出測試（Input/Output Testing ）、功能測試（Functional Testing ）。2. 系統(tǒng)測試指南2.1 系統(tǒng)測試過程活動名稱輸入工件輸出工件參與角色制定系統(tǒng)測試打算軟件需求工件軟件項目打算系統(tǒng)測試打算測試設計員設計系統(tǒng)測試系統(tǒng)測試打算軟件需求工件系統(tǒng)測試用例系統(tǒng)測試過程測試設計員實施系統(tǒng)測試系統(tǒng)測試打算工作版本系統(tǒng)測試腳本測試設計員執(zhí)行系統(tǒng)測試系統(tǒng)測試打算系統(tǒng)測試用例系統(tǒng)測試過程系統(tǒng)測試腳本測試結(jié)果測試員評估系統(tǒng)測試測試結(jié)果

17、 測試分析報告變更請求測試設計員相關組 2.2 系統(tǒng)測試需求獵取系統(tǒng)測試需求所確定的是測試的內(nèi)容，即測試的具體對象。系統(tǒng)測試需求要緊來源于需求工件集，它可能是一個需求規(guī)格講明書，或是由前景、用例、用例模型、詞匯表、補充規(guī)約組成的一個集合。在分析測試需求時，可應用以下幾條一般規(guī)則：測試需求必須是可觀測、可測評的行為。假如不能觀測或測評的測試需求，就無法對其進行評估，以確定需求是否差不多滿足。在每個用例或系統(tǒng)的補充需求與測試需求之間不存在一對一的關系。用例通常具有多個測試需求；有些補充需求將派生一個或多個測試需求，而其他補充需求（如市場需求或包裝需求）將不派生任何測試需求。在需求規(guī)格講明書中每一個

18、功能描述將派生一個或多個測試需求，性能描述、安全性描述等也將派生出一個或多個測試需求。1. 功能性測試需求功能性測試需求來自于測試對象的功能性講明。每個用例至少會派生一個測試需求。關于每個用例事件流，測試需求的詳細列表至少會包括一個測試需求。關于需求規(guī)格講明書中的功能描述，將至少派生一個測試需求。2. 性能測試需求性能測試需求來自于測試對象的指定性能行為。性能通常被描述為對響應時刻和資源使用率的某種評測。性能需要在各種條件下進行評測，這些條件包括：1）不同的工作量和/或系統(tǒng)條件2）不同的用例/功能3）不同的配置4）性能需求在補充規(guī)格或需求規(guī)格講明書中的性能描述部分中講明。對包括以下內(nèi)容的語句要

19、特不注意：1）時刻語句，如響應時刻或定時情況2）指出在規(guī)定時刻內(nèi)必須出現(xiàn)的事件數(shù)或用例數(shù)的語句3）將某一項性能的行為與另一項性能的行為進行比較的語句4）將某一配置下的應用程序行為與另一配置下的應用程序行為進行比較的語句5）一段時刻內(nèi)的操作可靠性（平均故障時刻或 MTTF ）6）配置或約束應該為規(guī)格中反映以上信息的每個語句生成至少一個測試需求。3. 其它測試需求其它測試需求包括配置測試、安全性測試、容量測試、強度測試、故障恢復測試、負載測試等測試需求能夠從非功能性需求中發(fā)覺與其對應的描述。每一個描述信息能夠生成至少一個測試需求。2.3 系統(tǒng)測試策略測試策略用于講明某項特定測試工作的一般方法和目標

20、。系統(tǒng)測試策略要緊針對系統(tǒng)測試需求確定測試類型及如何實施測試的方法和技術。一個好的測試策略應該包括要實施的測試類型和測試的目標、所采納的技術、用于評估測試結(jié)果和測試是否完成的標準、對測試策略所述的測試工作存在阻礙的專門事項等內(nèi)容。2.3.1 系統(tǒng)測試類型和目標確定系統(tǒng)測試策略首先應清晰地講明所實施系統(tǒng)測試的類型和測試的目標。清晰地講明這些信息有助于盡量幸免混淆和誤解（尤其是由于有些類型測試看起來特不類似，如強度測試和容量測試）。測試目標應該表明執(zhí)行測試的緣故。系統(tǒng)測試的測試類型一般包括：功能測試（Functional Testing）、性能測試（Performance Testing）負載測試

21、（Load Testing）、強度測試（Stress Testing）、容量測試（Volume Testing）、安全性測試（Security Testing）、配置測試（Configuration Testing）、故障恢復測試（Recovery Testing）、安裝測試（Installation Testing）、文檔測試（Documentation Testing）、用戶界面測試（GUI Testing）等等。其中，功能測試、配置測試、安裝測試等在一般情況下是必需的。而其它的測試類型則需要依照軟件項目的具體要求進行裁剪。2.3.2 采納的測試技術系統(tǒng)測試要緊采納黑盒測試技術設計測試用例

22、來確認軟件滿足需求規(guī)格講明書的要求。2.4 系統(tǒng)測試的工作機制1）項目組為每一個軟件項目成立測試組，確定測試經(jīng)理（通常由測試設計員擔任）一名，測試設計員和測試員若干。角色職責測試設計員制定系統(tǒng)測試打算、設計系統(tǒng)測試、實施系統(tǒng)測試以及評估系統(tǒng)測試測試員執(zhí)行系統(tǒng)測試2）項目組需要提供系統(tǒng)測試需要的輸入，建立測試環(huán)境，以及對測試工件進行配置治理。角色職責系統(tǒng)分析員生成需求工件集，治理需求。為測試設計員提供測試需求。配置治理員對測試工件進行配置治理軟件需求講明書軟件需求講明書測試需求測試需求測試需求測試用例測試用例測試用例測試過程測試過程測試過程測試過程測試過程測試分析報告軟件配置管理系統(tǒng)分析員測試設

23、計員測試設計員測試設計員測試設計員測試員2.5 系統(tǒng)測試產(chǎn)生的工件清單1）軟件系統(tǒng)測試打算2）系統(tǒng)測試用例3）系統(tǒng)測試過程4）測試腳本（可選）5）測試結(jié)果6）測試分析報告測試分析報告(GB標準)編者講明： 測試完成后，將會形成一些測試日志，關于每個測試用例也有了一個反饋的結(jié)果，那么從那個數(shù)據(jù)中看出問題、找到問題以及查找解決問題的方法，那確實是測試分析報告所要完成的事了。1.引言 1.1 編寫目的 講明這份測試分析報告的具體編寫目的，指出預期的閱讀范圍。 1.2 背景 講明： a. 被測試軟件系統(tǒng)的名稱； b. 該軟件的任務提出者、開發(fā)者、用戶及安裝此軟件的計算中心，指出測試環(huán)境與實際運行環(huán)境之

24、間可能存在的差異以及這些差異對測試結(jié)果的阻礙。 1.3 定義 列出本文件中用到的專問術語的定義和外文首字母組詞的原詞組。 1.4 參考資料 列出要用到的參考資料，如： a. 本項目的經(jīng)核準的打算任務書或合同、上級機關的批文； b. 屬于本項目的其他已發(fā)表的文件； c. 本文件中各處引用的文件、資料，包括所要用到的軟件開發(fā)標準。列出這些文件的標題、文件編號、發(fā)表日期和出版單位，講明能夠得到這些文件資料的來源。2.測試概要 用表格的形式列出每一項測試的標識符及其測試內(nèi)容，并指明實際進行的測試工作內(nèi)容與測試打算中預先設計的內(nèi)容之間的差不，講明作出這種改變的緣故。3.測試結(jié)果及發(fā)覺 3.1 測試1（標

25、識符）把本項測試中實際得到的動態(tài)輸出（包括內(nèi)部生成數(shù)據(jù)輸出）結(jié)果同關于動態(tài)輸出的要求進行比較，陳述其中的各項發(fā)覺。 3.2 測試2（標識符） 用類似本報告 3.1 條的方式給出第 2項及其后各項測試內(nèi)容的測試結(jié)果和發(fā)覺。4.對軟件功能的結(jié)論 4.1功能1（標識符） 4.1.1 能力簡述該項功能，講明為滿足此項功能而設計的軟件能力以及通過一項或多項測試已證實的能力。 4.1.2 限制講明測試數(shù)據(jù)值的范圍（包括動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)），列出就這項功能而言，測試期間在該軟件中查出的缺陷、局限性。 4.2 功能2（標識符） 用類似本報告4.l的方式給出第2項及其后各項功能的測試結(jié)論。 5 分析摘要 5.1

26、 能力陳述經(jīng)測試證實了的本軟件的能力。假如所進行的測試是為了驗證一項或幾項特定性能要求的實現(xiàn)，應提供這方面的測試結(jié)果與要求之間的比較，并確定測試環(huán)境與實際運行環(huán)境之間可能存在的差異對能力的測試所帶來的阻礙。5.2 缺陷和限制陳述經(jīng)測試證實的軟件缺陷和限制，講明每項缺陷和限制對軟件性能的阻礙，并講明全部測得的性能缺陷的累積阻礙和總阻礙。 5.3 建議 對每項缺陷提出改進建議，如： a. 各項修改可采納的修改方法； b. 各項修改的緊迫程度； c. 各項修改可能的工作量； d. 各項修改的負責人。5.4 評價 講明該項軟件的開發(fā)是否已達到預定目標，能否交付使用。6 測試資源消耗 總結(jié)測試工作的資源

27、消耗數(shù)據(jù)，如工作人員的水平級不數(shù)量、機時消耗等。測試規(guī)程講明編者講明： 軟件測試就像生產(chǎn)線上的產(chǎn)品測試一樣，需要專業(yè)的技能與工作方法，而測試規(guī)程則是確保每次測試動作高度統(tǒng)一。第1章目的1.1一般目的1.2執(zhí)行的測試用例 序號測試用例名稱或標識符第2章專門要求2.1前繼規(guī)程 序號前繼規(guī)程的名稱或標識符 2.2專門技能2.3專門環(huán)境2.4其它第3章規(guī)程步驟3.1日志3.2預備3.3啟動3.4處理3.5度量3.6暫停3.7再啟動3.8停止3.9清除3.10應急計算機軟件測試文件編制規(guī)范編者講明： 測試是一個復雜、系統(tǒng)化的工作，也是一個內(nèi)容廣泛的課題，其間將產(chǎn)生大量的文檔。本文檔確實是一個指導所有這些

28、文檔編寫的規(guī)范。你能夠依照自己的實際，對其修改，以適用于你的開發(fā)團隊。1.引言 1.1 目的和作用 本規(guī)范規(guī)定一組軟件測試文件。測試是軟件生存周期中一個獨立的、關鍵的時期，也是保證軟件質(zhì)量的重要手段。為了提高檢測出錯誤的幾率，使測試能有打算地、有條不紊地進行地進行，就必須要編制測試文件。而標準化的測試文件就如同一種通用的參照體系，可達到便于交流的目的。文件中所規(guī)定的內(nèi)容能夠作為對測試過程完備性的對比檢查表，故采納這些文件將會提高測試過程的每個時期的能見度，極大地提高測試工作的可治理性。 1.2 適用對象及范圍 本規(guī)范是為軟件治理人員、軟件開發(fā)人員和軟件維護人員、軟件質(zhì)量保證人員、審計人員、客戶

29、及用戶制定的。 本規(guī)范用于描述一組測試文件，這些測試文件描述測試行為。本規(guī)范定義每一種差不多文件的目的、格式和內(nèi)容。所描述的文件著重于動態(tài)測試過程，但有些文件仍適用其它種類的測試活動。 本規(guī)范可應用于數(shù)字計算機上運行的軟件。它的應用范圍不受軟件大小、復雜度或重要性的限制，本規(guī)范既適用于初始開發(fā)的軟件測試文件編制，也適用于其后的軟件產(chǎn)品更新版本的測試文件編制。 本規(guī)范并不要求采納特定的測試方法學、技術及設備或工具。對文件操縱、配置治理或質(zhì)量保證既不指明也不強制特定的方法學。依照所用的方法學，可能需要增加不的文件（如“質(zhì)量保證打算”）。 本規(guī)范既適用于紙張上的文件，也適用于其它媒體上的文件。假如電

30、子文件編制系統(tǒng)不具有安全的批準注冊機制，則批準簽字的文件必須使用紙張。 2.引用標準 GB/T 11457 軟件工程術語 GB 8566 計算機軟件開發(fā)規(guī)范 GB 8567 計算機軟件產(chǎn)品開發(fā)文件編制指南 3.定義 本章定義本規(guī)范中使用的關鍵術語。 3.1 設計層 design level 軟件項的設計分解（如系統(tǒng)、子系統(tǒng)、程序或模塊）。 3.2 通過準則 pass criteria 推斷一個軟件項或軟件特性的測試是否通過的判不依據(jù)。 3.3 軟件特性 software feature 軟件項的顯著特性。（如功能、性能或可移植性等）。 3.4 軟件項 software item 源代碼、目標代

31、碼、作業(yè)操縱代碼、操縱數(shù)據(jù)或這些項的集合。 3.5 測試項 test item 作為測試對象的軟件項。 4.概述 4.1 要緊內(nèi)容 本規(guī)范確定了各個測試文件的格式和內(nèi)容，所提出的文件類型包括測試打算、測試講明和測試報告。 測試打算描述測試活動的范圍、方法、資源和進度。它規(guī)定被測試的項、被測試的特性、應完成的測試任務、擔任各項工作的人員職責及與本打算有關的風險等。 測試講明包括三類文件： （1）測試設計講明：詳細描述測試方法，規(guī)定該設計及其有關測試所包括的特性，還規(guī)定完成測試所需的測試用例和測試規(guī)程，并規(guī)定特性的通過準則。 （2）測試用例講明：列出用于輸入的具體值以及預期的輸出結(jié)果，并規(guī)定在使用

32、具體測試用例時，對測試規(guī)程的各種限制。將測試用例與測試設計分開，能夠使它們用于多個設計并能在其它情形下重復使用。 （3）測試規(guī)程講明：規(guī)定關于運行系統(tǒng)和執(zhí)行指定的測試用例來實現(xiàn)有關測試設計所要求的所有步驟。 測試報告包括四類文件： （1）測試項傳遞報告：指明在開發(fā)組和測試組獨立工作的情況下或者在希望正式開始測試的情況下為進行測試而被傳遞的測試項。 （2）測試日志：測試組用于記錄測試執(zhí)行過程中發(fā)生的情況。 （3）測試事件報告：描述在測試執(zhí)行期間發(fā)生并需進一步調(diào)查的一切事件。 （4）測試7總結(jié)報告：總結(jié)與測試設計講明有關的測試活動。 這些文件同其它文件在編制方面的關系以及同測試過程的對應關系如圖1

33、所示。 4.2 實施靈活性 在GB 8567中，涉及軟件測試的文件有“測試打算”及“測試分析報告”。本規(guī)范中的八個測試文件是上述二個文件的補充和細化，如此可使文件的書定更具體、更有參照性，其中測試打算可細化為本規(guī)范的測試打算、測試設計講明、測試用例講明及測試規(guī)程講明，測試分析報告可細化為本規(guī)范的測試項傳遞報告、測試日志、測試事件報告及測試總結(jié)報告。 使用本規(guī)范的每個單位，要規(guī)定測試時期所應有的特定文件，并在測試打算中規(guī)定測試完成后所能提交的全部文件。關于不同的設計層或不同規(guī)模的軟件，所選文件的種類也可有所不同。 在所提供的每個標準文件中，每一章的內(nèi)容關于具體的應用和特定的測試時期能夠有所增減。

34、不僅能夠調(diào)整內(nèi)容，還能夠在差不多文件集中增加另外的文件。任何一個文件都能夠增加新的內(nèi)容，同時某章若無可寫的內(nèi)容，則可不寫，但須保留該章的編號。使用本規(guī)范的每個單位應該補充規(guī)定對內(nèi)容的要求和約定，以便反映自己在測試、文件操縱、配置治理和質(zhì)量保證方面所用的特定方法、設備和工具。 附錄A（參考件）中，將敘述文件編制實施及使用指南。 4.3 總體要求 以下將敘述各個測試文件的書寫格式及內(nèi)容。關于每一個文件而言各章應按指定的次序排列，補充的章能夠放在最后或放在“批準”一章的前面（假如該文件最后一章是“批準”的話）。假如某章的部分或全部內(nèi)容在另一文件中，則應在相應的內(nèi)容位置上列出所引用的材料，引用的材料必

35、須附在該文件后面或交給文件的使用者。 5.內(nèi)容要求 5.1 測試打算 測試打算結(jié)構(gòu)如下圖所示。 1 測試打算名稱1 測試打算名稱2 引言3 測試項4 被測試的特性5 不被測試的特性6 方法7 項通過準則8 暫停標準和再啟動要求9 應提供的測試文件10 測試任務11 環(huán)境要求12 職責 13 人員和訓練要求 14 進度 15 風險和應急 16 批準 下面給出每一章的詳細內(nèi)容： 5.1.1 測試打算名稱（本打算的第1章） 為本測試打算取現(xiàn)代戰(zhàn)爭專用的名稱。 5.1.2 引言（本打算的第2章） 歸納所要求測試的軟件項和軟件特性，能夠包括系統(tǒng)目標、背景、范圍及引用材料等。 在最高層測試打算中，假如存在

36、下述文件，則需要引用它們：項目打算、質(zhì)量保證打算、有關的政策、有關的標準等。 5.1.3 測試項（本打算的第3章） 描述被測試的對象，包括其版本、修訂級不，并指出在測試開始之前對邏輯或物理變換的要求。 5.1.4 被測試的特性（本打算的第4章） 指明所有要被測試的軟件特性及其組合，指明每個特性或特性組合有關的測試設計講明。 5.1.5 不被測試的特性（本打算的第5章） 指出不被測試的所有特性和特性的有意義的組合及其理由。 5.1.6 方法（本打算的第6章） 描述測試的總體方法，規(guī)定測試指定特性組志需的要緊活動、技術和工具，應詳盡地描述方法，以便列出要緊的測試任務，并可能執(zhí)行各項任務所需的時刻。

37、規(guī)定所希望的電低程度的測試完全性，指明用于推斷測試完全性的技術（如：檢查哪些語句至少執(zhí)行過一次）。指出對測試的要緊限制，例如：測試項可用性、測試資源的可用性和測試截止期限等。 5.1.7 項通過準則（本打算的第7章） 規(guī)定各測試項通過測試的標準。 5.1.8 暫停標準和再啟動要求（本打算第8章） 規(guī)定用于暫停全部或部分與本打算有關的測試項的測試活動的標準。規(guī)定當測試再啟動時必須重復的測試活動。 5.1.9 應提供的測試文件（本打算的第9章） 規(guī)定測試完成后所應遞交的文件，這些文件能夠是前述八個文件的全部或者部分。 5.1.10 測試任務（本打算的第10章） 指明執(zhí)行測試所需的任務集合，指出任務

38、音的一切依靠關系和所需的一切專門技能。 5.1.11 環(huán)境要求（本打算的第11章） 規(guī)定測試環(huán)境所必備的和希望的的性質(zhì)。包括：硬件、通信和系統(tǒng)軟件的物理特征、使用方式以及任何其它支撐測試所需的軟件或設備，指出所需的專門測試工具及其它測試要求（如出版物或辦公場地等）。指出測試組目前還不能得到的所有要求的來源。 5.1.12 職責（本打算的第12章） 指出負責治理、設計、預備、執(zhí)行、監(jiān)督、檢查和仲裁的小組。另外指出負責提供5.1.3 中指出的測試項和在5.1.11中指出的環(huán)境要求的小組。 這些小組能夠包括開發(fā)人員、測試人員、操作員、用戶代表、數(shù)據(jù)治理員和質(zhì)量保證人員。 5.1.13 人員和訓練要求

39、（本打算的第13章） 指明測試人員應有的水平以及為掌握必要技能可供選擇的訓練科目。 5.1.14 進度（本打算的第14章） 包括在軟件項目進度中規(guī)定的測試里程碑以及所有測試項傳遞時刻。 定義所需的新的測試里程碑，可能完成每項測試任務所需的時刻，為每項測試任務和測試里程碑規(guī)定進度，對每項測試資源規(guī)定使用期限。 5.1.15 風險和應急（本打算的第15章） 預測測試打算中的風險，規(guī)定對各種風險的應急措施（如：延期傳遞的測試項可能需要加夜班來趕上規(guī)定的進度。） 5.1.16 批準（本打算的第16章） 規(guī)定本打算必須由哪些人（姓名和職務）審批。為簽名和填寫日期留出位置。 5.2 測試設計講明 測試設計

40、講明如下圖所示。 1 測試設計講明名稱 2 被測試的特性 3 方法詳述 4 測試用例名稱 5 特性通過準則 下面給出本講明每一章的詳細內(nèi)容。 5.2.1 測試設計講明名稱（本講明第1章） 給每一個測試設計講明取一個專用名稱。假如存在的話，也可引用有關的測試打算中給出的名稱。 5.2.2 被測試的特性（本講明的第2章） 規(guī)定測試項，描述作為本設計測試目標的特性和特性的組合，其它特性能夠論及，但不必測試。 5.2.3 方法詳述（本講明的第3章） 將測試打算中規(guī)定的方法進行細化，包括要用的具體測試技術，規(guī)定分析測試結(jié)果的方法（如比較程序或人工觀看）。 規(guī)定為選擇測試用例提供合理依據(jù)的一切分析結(jié)果。例

41、如：能夠講明容錯的條例（如：區(qū)不有效輸入和無效輸入的條件）。 歸納所有測試用例的共同屬性，能夠包括輸入約束條件，共享環(huán)境的要求，對共享的專門規(guī)程的要求及任何共享的測試用例間的依靠關系。 5.2.4 測試例名稱（本講明的第4章） 列出與本設計有關的每一測試用例的名稱和簡要講明。某個特定的測試用例可能在多個測試設計講明中出現(xiàn)，列出與本測試設計講明有關的規(guī)程及其簡要講明。 5.2.5 特性通過準則（本講明的第5章） 規(guī)定用于判不特性和特性組合是否通過測試的準。5.3 測試用例講明 測試用例講明結(jié)構(gòu)如下圖所示。 1 測試用例講明名稱 2 測試項 3 輸入講明 4 輸出講明 5 環(huán)境要求 6 專門的規(guī)程

42、講明 7 用例間的依靠關系 由于測試用例可能被由多個小組長期使用的多個測試設計講明引用，因此在測試用例講明中必須包含足夠具體的信息以便重復使用。 下面給出本講明每一章的詳細內(nèi)容。 5.3.1 測試用例講明名稱（本講明的第1章） 給本測試用例講明取一個專用名稱 5.3.2 測試項（本講明的第2章） 規(guī)定并簡要講明本測試用例所要涉及的項和特性、關于每一項、可考慮引用以下文件：需求講明書、設計講明書、用戶手冊、操作手冊。 5.3.3 輸入講明（本講明的第3章） 規(guī)定執(zhí)行測試用例所需的各個輸入。有些輸入能夠用值（同意適當?shù)恼`差）來規(guī)定。而另一些輸入，如常數(shù)表或事務文件能夠用名來規(guī)定。規(guī)定所有合適的數(shù)據(jù)

43、庫、文件、終端信息、內(nèi)存常駐區(qū)域和由操作系統(tǒng)傳送的值。規(guī)定各輸入間所需的所有關系（如時序關系等）。 5.3.4 輸出講明（本講明的第4章） 規(guī)定測試項的所有輸出和特性（如：響應時刻）。提供各個輸出或特性的正確值（在適當?shù)恼`差范圍內(nèi)）。 5.3.5 環(huán)境要求（本講明的第5章） 5.3.5.1 硬件 規(guī)定執(zhí)行本測試用例所需的硬件特征和配置（如：80字符24行的顯示終端）。 5.3.5.2 軟件 規(guī)定執(zhí)行本測試用例所需的系統(tǒng)軟件和應用軟件。系統(tǒng)軟件能夠包括操作系統(tǒng)、編譯程序、模擬程序和測試工具等。 5.3.5.3 其它 講明所有其它的要求，如特種設施要求或通過專門訓練的人員等。 5.3.6 專門的規(guī)

44、程要求（本講明的第6章） 描述對執(zhí)行本測試用例的測試規(guī)程的一切專門限制。這些限制能夠包括特定的預備、操作人員干預、確定專門的輸出和清除過程。 5.3.7 用例間的依靠關系（本講明的第7章） 列出必須在本測試用例之前執(zhí)行的測試用例名稱，歸納依靠性質(zhì)。 5.4 測試規(guī)程講明 測試規(guī)程講明結(jié)構(gòu)如下圖表示 1 測試規(guī)程講明名稱 2 目的 3 專門要求 4 規(guī)程步驟 下面給出本講明每一章的詳細內(nèi)容。 5.4.1 測試規(guī)程講明名稱（本講明的第1章） 給每個測試規(guī)程講明取一個專用名稱，給出對有關測試設計講明的引用。 5.4.2 目的（本講明的第2章） 描述本規(guī)程的目的。假如本規(guī)程執(zhí)行測試用例，則引用各有關的

45、測試用例講明。 5.4.3 專門要求（本講明的第3章） 指出執(zhí)行本規(guī)程所需的所有專門要求，包括作為先決條件的規(guī)程、專門技能要求和專門環(huán)境要求。 5.4.4 規(guī)程步驟（本講明的第4章） 5.4.4.1 日志 講明用來記錄測試的執(zhí)行結(jié)果、觀看到的事件和其它與測試有關事件（見5.6條測試日志和5.7條測試事件報告）的所有專門方法或格式。 5.4.4.2 預備 描述新任務執(zhí)行規(guī)程所必需的動作序列。 5.4.4.3 啟動 描述開始執(zhí)行規(guī)程所必需的動作。 5.4.4.4 處理 描述在規(guī)程執(zhí)行過程中所必需的動作。 5.4.4.5 度量 描述如何進行測試度量（如描述如何用網(wǎng)絡模擬程序來充其量遠程終端的響應時刻

46、）。 5.4.4.6 暫停 描述因發(fā)生意外事件暫停測試所必需的動作。 5.4.4.7 再啟動 規(guī)定所有再撥動點和在啟動點上重新啟動規(guī)程所必需的動作。 5.4.4.8 停止 描述正常停止執(zhí)行時所必需的動作。 5.4.4.9 清除 描述恢復環(huán)境所必需的動作。 5.4.4.10 應急 描述處理執(zhí)行過程中可能發(fā)生的異常事件所必需的動作。 5.5 測試項傳遞報告 測試項傳遞報告結(jié)構(gòu)如下圖所示。 1 傳遞報告名稱 2 傳遞項 3 位置 4 狀態(tài) 5 批準 下面給出本報告每一章的詳細內(nèi)容。 5.5.1 傳遞報告名稱（本報告的第1章） 為本測試項傳遞報告取一個專用名稱。 5.5.2 傳遞項（本報告的第2章） 規(guī)定被傳遞的項及其版本/修訂級不。提供與傳遞項有關的項文件和測試打算的相關信息，指出對該傳遞項負責的人員。 5.5.3 位置（本報告的第3章） 規(guī)定傳遞項的