方案：軟體質量保證

軟體質量保證

測試計劃

編者說明：

    要想系統性地完成一件事，首先要做好計劃，測試工作是十分重要的，因此測試計劃也是十分必要的。該文件適用於整合測試、系統測試、驗收測試的計劃制訂，並不適用於單元測試計劃。

第1章    引言

1.1   綜述

1.2   參考文獻

第2章    測試項

2.1   測試項

2.2   不測試的軟體項

第3章    被測試的特性

第4章    不被測試的特性

第5章    方法

5.1   <方法名稱>

5.2   <方法名稱>

第6章    項通過準則

第7章    暫停標準和再啟動要求

7.1   暫停標準

7.2   再啟動要求

第8章    應提供的測試文件

第9章    測試任務

第10章  環境要求

10.1 硬體

10.2 軟體

10.3 安全性

10.4 工具

10.5 文件

第11章  職責

11.1 測試組

11.2 開發組

11.3 ……

第12章  人員和培訓要求

12.1 人員

12.1.1      測試組

12.2 培訓

第13章  進度

13.1 進度

13.2 測試資源使用期限

第14章  風險和應急

測試日誌

編者說明：

    測試都有一個結果，而這些結果對於軟體質量保證活動來說是十分重要的，因此應該將這些結果有序地記錄下來，這就是測試日誌模板所要解決的問題。

第1章    描述

1.1   測試項

1.2   測試的環境

1.2.1        硬體

1.2.2        軟體

第2章    活動和事件條目

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   引用文件

第2章    輸入說明

第3章    輸出說明

第4章    環境要求

4.1   硬體

4.2   軟體

4.3   其它

第5章    特殊的規程要求

第6章    用例間的依賴關係

6.1   所依賴的用例

6.2   依賴關係的性質

整合測試計劃(ISO標準)

編者說明：

    前面的測試計劃模板是一個通用性的，也可以是用於制定所有測試活動的計劃，而本模組則是用來指導編寫整合測試計劃的。

1.引言

1.1編寫目的

        [說明編寫這份測試計劃目的，指出預期的讀者。]

1.2背景

a.      待開發系統的名稱；

b.     列出本專案的任務提出者、開發者、使用者。

1.3定義

        [列出本檔案中用到的專門術語的定義和外文首字母組詞的原片語。]

1.4參考資料

        [列出有關的參考資料。]

2．計劃

2.1系統說明

[提供一份圖表，並逐項說明被測系統的功能、輸入、輸出等質量指標，作為敘述測試計劃的提綱。]

2.2測試內容

[列出整合測試和確認測試中的每一項測試內容的名稱識別符號、這些測試的進度安排以及這些測試的內容和目的。]

2.3測試1（識別符號）

        [給出這項測試內容的參與單位及被測試的部位。]

2.3.1進度安排

            [給出對這項測試的進度安排，包括進行測試的日期和工作內容。]

2.3.2條件

    [陳述本項測試工作對資源的要求。包括：]

a.      硬體

b.     軟體

c.      人員

2.3.3測試資料

    [列出本項測試所需的資料。]

2.3.4測試培訓

[說明或引用資料說明為被測系統的使用提供培訓的計劃。規定培訓的內容、受訓的人員及從事培訓的工作人員。]

2.4測試2（識別符號）

[用與本測試計劃2。3條相類似的方式說明用於另一項及其後各項測試內容的測試工作計劃。]

   [……]

3．測試設計說明

3.1測試1（識別符號）

        [說明對第一項測試內容的測試設計考慮。]

3.1.1控制

    [說明本測試的控制方式。]

3.1.2輸入

    [說明本項測試中所使用的輸入資料及選擇這些輸入資料的策略。]

3.1.3輸出

    [說明預期的輸出資料。]

3.1.4過程

    [說明完成此項測試的一個個步驟和控制命令。]

3.2測試2（識別符號）

[用與本測試計劃3。1條相類似的方式說明第2項及其後各項測試工作的設計考慮。]

    [……]

4．評價準則

4.1範圍

        [說明所選擇的測試用例能夠檢查的範圍及其侷限性。]

4.2資料整理

[陳述為了把測試資料加工成便於評價的適當形式，使得測試結果可以同已知結果進行比較而要用到的轉換處理技術；如果是用自動方式整理資料，還要說明為進行處理而要用到的硬體、軟體資源。]

4.3尺度

[說明用來判斷測試工作是否能通過的評價尺度，如合理和輸出結果的型別、測試輸出結果與預期輸出之間的容許偏離範圍、允許中斷或停機的最大數。]

軟體整合測試工作流程指南

編者說明：

    嚴格地說，該文件不屬於文件模板，它只是一個工作指南。要想更好地完成整合測試工作，你就需要為團隊制定一個工作指南。你可以根據該文件，結合實際進行修改。

1. 簡介

1.1 目的

本文詳細闡述了整合測試流程，指導專案開發人員如何開展軟體整合測試。

1.2 範圍

此指南可運用於使用RUP 的任一軟體專案的整合測試。

1.3 參考檔案

Software Test Process

Rational Unified Process

1.4 定義與縮寫

RUP：統一開發過程

SIT：軟體整合測試

SEPG：軟體工程過程小組

SQA：軟體質量保證

2. 整合測試指南

2.1 簡介

整合測試的目的是確保各單元組合在一起後能夠按既定意圖協作執行，並確保增量的行為正確。它所測試的內容包括單元間的介面以及整合後的功能。使用黑盒測試方法測試整合的功能。並且對以前的整合進行迴歸測試。

2.2 單元測試工作內容及其流程

2.3 整合測試需求獲取

整合測試需求所確定的是對某一整合工作版本的測試的內容，即測試的具體物件。整合測試需求主要來源於設計模型（Design Model ）和整合構件計劃（Integration Build Plan ）。

整合測試著重於整合版本的外部介面的行為。因此，測試需求須具有可觀測、可測評性。

1.整合工作版本應分析其類協作與訊息序列，從而找出該工作版本的外部介面。

2.由整合工作版本的外部介面確定整合測試用例。

3.測試用例應覆蓋工作版本每一外部介面的所有訊息流序列。

注意：一個外部介面和測試用例的關係是多對多，部分整合工作版本的測試需求可對映到系統測試需求，因此對這些整合測試用例可採用重用系統測試用例技術。

2.4 整合測試工作機制

軟體整合測試工作由產品評測部擔任。需要專案組相關角色配合完成。如圖示：

軟體評測部：

軟體專案組：

整合測試工作內容及其流程工作流程：

2.5 整合測試產生的工件清單

1、軟體整合測試計劃

2、整合測試用例

3、測試過程

4、測試指令碼

5、測試日誌

6、測試評估摘要

軟體系統測試工作指南

編者說明：

    這是一個系統測試的工作指南。你可以根據該文件，結合實際進行修改。

1. 簡介

1.1 目的

本文詳細闡述了系統測試的型別以及各個型別的基本測試方法，指導專案開發人員進行軟體系統測試。

1.2 範圍

本文適用於使用RUP 的所有軟體專案的系統測試工作。

1.3 文件結構

第一部分：簡介，介紹軟體系統測試指南的目的，本指南的適用範圍，以及在本文件中使用的術語的解釋。

第二部分：描述系統測試指南。包括系統測試流程、系統測試需求的獲取、系統測試側策略選擇、系統測試技術和方法等。

第三部分：列出本指南使用的參考文獻。

1.4 詞彙表

系統測試（System Testing）：系統測試是通過與系統的需求規格作比較，發現軟體與系統需求規格不相符合或與之矛盾的地方。它將通過確認測試的軟體，作為整個基於計算機系統的一個元素，與計算機硬體、外設、某些支援軟體、資料和人員等其他系統元素結合起來，在實際執行（使用）環境下，對計算機系統進行的測試。

黑盒測試（Black-Box Testing）：黑盒測試是基於系統需求規格，在不知道系統或元件的內部結構的情況下進行的測試。通常又將黑盒測試叫做：基於規格的測試（Specification-Based Testing ）、輸入輸出測試（Input/Output Testing ）、功能測試（Functional Testing ）。

2. 系統測試指南

2.1 系統測試過程

    2.2 系統測試需求獲取

系統測試需求所確定的是測試的內容，即測試的具體物件。系統測試需求主要來源於需求工件集，它可能是一個需求規格說明書，或是由前景、用例、用例模型、詞彙表、補充規約組成的一個集合。

在分析測試需求時，可應用以下幾條一般規則：

1. 測試需求必須是可觀測、可測評的行為。如果不能觀測或測評的測試需求，就無法對其進行評估，以確定需求是否已經滿足。
2. 在每個用例或系統的補充需求與測試需求之間不存在一對一的關係。用例通常具有多個測試需求；有些補充需求將派生一個或多個測試需求，而其他補充需求（如市場需求或包裝需求）將不派生任何測試需求。
3. 在需求規格說明書中每一個功能描述將派生一個或多個測試需求，效能描述、安全性描述等也將派生出一個或多個測試需求。

1. 功能性測試需求

功能性測試需求來自於測試物件的功能性說明。每個用例至少會派生一個測試需求。對於每個用例事件流，測試需求的詳細列表至少會包括一個測試需求。對於需求規格說明書中的功能描述，將至少派生一個測試需求。

2. 效能測試需求

效能測試需求來自於測試物件的指定效能行為。效能通常被描述為對響應時間和資源使用率的某種評測。效能需要在各種條件下進行評測，這些條件包括：

1）不同的工作量和/或系統條件

2）不同的用例/功能

3）不同的配置

4）效能需求在補充規格或需求規格說明書中的效能描述部分中說明。

對包括以下內容的語句要特別注意：

1）時間語句，如響應時間或定時情況

2）指出在規定時間內必須出現的事件數或用例數的語句

3）將某一項效能的行為與另一項效能的行為進行比較的語句

4）將某一配置下的應用程式行為與另一配置下的應用程式行為進行比較的語句

5）一段時間內的操作可靠性（平均故障時間或 MTTF ）

6）配置或約束

應該為規格中反映以上資訊的每個語句生成至少一個測試需求。

3. 其它測試需求

其它測試需求包括配置測試、安全性測試、容量測試、強度測試、故障恢復測試、負載測試等測試需求可以從非功能性需求中發現與其對應的描述。每一個描述資訊可以生成至少一個測試需求。

2.3 系統測試策略

測試策略用於說明某項特定測試工作的一般方法和目標。系統測試策略主要針對系統測試需求確定測試型別及如何實施測試的方法和技術。

一個好的測試策略應該包括要實施的測試型別和測試的目標、所採用的技術、用於評估測試結果和測試是否完成的標準、對測試策略所述的測試工作存在影響的特殊事項等內容。

2.3.1 系統測試型別和目標

確定系統測試策略首先應清楚地說明所實施系統測試的型別和測試的目標。清楚地說明這些資訊有助於儘量避免混淆和誤解（尤其是由於有些型別測試看起來非常類似，如強度測試和容量測試）。測試目標應該表明執行測試的原因。

系統測試的測試型別一般包括：功能測試（Functional Testing）、效能測試（Performance Testing）負載測試（Load Testing）、強度測試（Stress Testing）、容量測試（Volume Testing）、安全性測試（Security Testing）、配置測試（Configuration Testing）、故障恢復測試（Recovery Testing）、安裝測試（Installation Testing）、文件測試（Documentation Testing）、使用者介面測試（GUI Testing）等等。

其中，功能測試、配置測試、安裝測試等在一般情況下是必需的。而其它的測試型別則需要根據軟體專案的具體要求進行裁剪。

2.3.2 採用的測試技術

系統測試主要採用黑盒測試技術設計測試用例來確認軟體滿足需求規格說明書的要求。

2.4 系統測試的工作機制

1）專案組為每一個軟體專案成立測試組，確定測試經理（通常由測試設計員擔任）一名，測試設計員和測試員若干。

2）專案組需要提供系統測試需要的輸入，建立測試環境，以及對測試工件進行配置管理。

2.5 系統測試產生的工件清單

1）軟體系統測試計劃

2）系統測試用例

3）系統測試過程

4）測試指令碼（可選）

5）測試結果

6）測試分析報告

測試分析報告(GB標準)

編者說明：

    測試完成後，將會形成一些測試日誌，對於每個測試用例也有了一個反饋的結果，那麼從這個資料中看出問題、找到問題以及尋找解決問題的方法，那就是測試分析報告所要完成的事了。

1.引言

  1.1 編寫目的

    [說明這份測試分析報告的具體編寫目的，指出預期的閱讀範圍。]

  1.2 背景

    [說明：]

    [ a. 被測試軟體系統的名稱；]

[ b. 該軟體的任務提出者、開發者、使用者及安裝此軟體的計算中心，指出測試環境與實際執行環境之間可能存在的差異以及這些差異對測試結果的影響。]

  1.3 定義

    [列出本檔案中用到的專問術語的定義和外文首字母組詞的原片語。]

  1.4 參考資料

    [列出要用到的參考資料，如：]

    [ a. 本專案的經核准的計劃任務書或合同、上級機關的批文；]

        [ b. 屬於本專案的其他已發表的檔案；]

  [ c. 本檔案中各處引用的檔案、資料，包括所要用到的軟體開發標準。]

[列出這些檔案的標題、檔案編號、發表日期和出版單位，說明能夠得到這些檔案資料的來源。]

2.測試概要

    [用表格的形式列出每一項測試的識別符號及其測試內容，並指明實際進行的測試工作內容與測試計劃中預先設計的內容之間的差別，說明作出這種改變的原因。]

3.測試結果及發現

   3.1  測試1（識別符號）

[把本項測試中實際得到的動態輸出（包括內部生成資料輸出）結果同對於動態輸出的要求進行比較，陳述其中的各項發現。]

  3.2 測試2（識別符號）

    [用類似本報告 3.1 條的方式給出第 2項及其後各項測試內容的測試結果和發現。]

4.對軟體功能的結論

4.1功能1（識別符號）

    4.1.1 能力

[簡述該項功能，說明為滿足此項功能而設計的軟體能力以及經過一項或多項測試已證實的能力。]

    4.1.2 限制

[說明測試資料值的範圍（包括動態資料和靜態資料），列出就這項功能而言，測試期間在該軟體中查出的缺陷、侷限性。]

  4.2 功能2（識別符號）

    [用類似本報告4.l的方式給出第2項及其後各項功能的測試結論。]

   ......

5 分析摘要

5.1 能力

[陳述經測試證實了的本軟體的能力。如果所進行的測試是為了驗證一項或幾項特定效能要求的實現，應提供這方面的測試結果與要求之間的比較，並確定測試環境與實際執行環境之間可能存在的差異對能力的測試所帶來的影響。]

5.2 缺陷和限制

[陳述經測試證實的軟體缺陷和限制，說明每項缺陷和限制對軟體效能的影響，並說明全部測得的效能缺陷的累積影響和總影響。]

  5.3 建議

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

    [ a. 各項修改可採用的修改方法；]

    [ b. 各項修改的緊迫程度；]

    [ c. 各項修改預計的工作量；]

    [ d. 各項修改的負責人。]

5.4 評價

        [說明該項軟體的開發是否已達到預定目標，能否交付使用。]

6 測試資源消耗

[總結測試工作的資源消耗資料，如工作人員的水平級別數量、機時消耗等。]

測試規程說明

編者說明：

    軟體測試就像生產線上的產品測試一樣，需要專業的技能與工作方法，而測試規程則是確保每次測試動作高度統一。

第1章    目的

1.1   一般目的

1.2   執行的測試用例

第2章    特殊要求

2.1   前繼規程

    2.2   專門技能

2.3   特殊環境

2.4   其它

第3章    規程步驟

3.1   日誌

3.2   準備

3.3   啟動

3.4   處理

3.5   度量

3.6   暫停

3.7   再啟動

3.8   停止

3.9   清除

3.10 應急

計算機軟體測試檔案編制規範

編者說明：

    測試是一個複雜、系統化的工作，也是一個內容廣泛的課題，其間將產生大量的文件。本文件就是一個指導所有這些文件編寫的規範。你可以根據自己的實際，對其修改，以適用於你的開發團隊。

1.引言

1.1 目的和作用

本規範規定一組軟體測試檔案。測試是軟體生存週期中一個獨立的、關鍵的階段，也是保證軟體質量的重要手段。為了提高檢測出錯誤的機率，使測試能有計劃地、有條不紊地進行地進行，就必須要編制測試檔案。而標準化的測試檔案就如同一種通用的參照體系，可達到便於交流的目的。檔案中所規定的內容可以作為對測試過程完備性的對照檢查表，故採用這些檔案將會提高測試過程的每個階段的能見度，極大地提高測試工作的可管理性。

1.2 適用物件及範圍

本規範是為軟體管理人員、軟體開發人員和軟體維護人員、軟體質量保證人員、審計人員、客戶及使用者制定的。

本規範用於描述一組測試檔案，這些測試檔案描述測試行為。本規範定義每一種基本檔案的目的、格式和內容。所描述的檔案著重於動態測試過程，但有些檔案仍適用其它種類的測試活動。

本規範可應用於數字計算機上執行的軟體。它的應用範圍不受軟體大小、複雜度或重要性的限制，本規範既適用於初始開發的軟體測試檔案編制，也適用於其後的軟體產品更新版本的測試檔案編制。

本規範並不要求採用特定的測試方法學、技術及裝置或工具。對檔案控制、配置管理或質量保證既不指明也不強制特定的方法學。根據所用的方法學，可能需要增加別的檔案（如“質量保證計劃”）。

本規範既適用於紙張上的檔案，也適用於其它媒體上的檔案。如果電子檔案編制系統不具有安全的批准序號產生器制，則批准簽字的檔案必須使用紙張。

2.引用標準

GB/T 11457 軟體工程術語

GB 8566 計算機軟體開發規範

GB 8567 計算機軟體產品開發檔案編制指南

3.定義

本章定義本規範中使用的關鍵術語。

3.1 設計層 design level

軟體項的設計分解（如系統、子系統、程式或模組）。

3.2 通過準則 pass criteria

判斷一個軟體項或軟體特性的測試是否通過的判別依據。

3.3 軟體特性 software feature

軟體項的顯著特性。（如功能、效能或可移植性等）。

3.4 軟體項 software item

原始碼、目的碼、作業控制程式碼、控制資料或這些項的集合。

3.5 測試項 test item

作為測試物件的軟體項。

4.概述

4.1 主要內容

本規範確定了各個測試檔案的格式和內容，所提出的檔案型別包括測試計劃、測試說明和測試報告。

測試計劃描述測試活動的範圍、方法、資源和進度。它規定被測試的項、被測試的特性、應完成的測試任務、擔任各項工作的人員職責及與本計劃有關的風險等。

測試說明包括三類檔案：

（1）測試設計說明：詳細描述測試方法，規定該設計及其有關測試所包括的特性，還規定完成測試所需的測試用例和測試規程，並規定特性的通過準則。

（2）測試用例說明：列出用於輸入的具體值以及預期的輸出結果，並規定在使用具體測試用例時，對測試規程的各種限制。將測試用例與測試設計分開，可以使它們用於多個設計並能在其它情形下重複使用。

（3）測試規程說明：規定對於執行系統和執行指定的測試用例來實現有關測試設計所要求的所有步驟。

測試報告包括四類檔案：

（1）測試項傳遞報告：指明在開發組和測試組獨立工作的情況下或者在希望正式開始測試的情況下為進行測試而被傳遞的測試項。

（2）測試日誌：測試組用於記錄測試執行過程中發生的情況。

（3）測試事件報告：描述在測試執行期間發生並需進一步調查的一切事件。

（4）測試7總結報告：總結與測試設計說明有關的測試活動。

這些檔案同其它檔案在編制方面的關係以及同測試過程的對應關係如圖1所示。

4.2 實施靈活性

在GB 8567中，涉及軟體測試的檔案有“測試計劃”及“測試分析報告”。本規範中的八個測試檔案是上述二個檔案的補充和細化，這樣可使檔案的書定更具體、更有參照性，其中測試計劃可細化為本規範的測試計劃、測試設計說明、測試用例說明及測試規程說明，測試分析報告可細化為本規範的測試項傳遞報告、測試日誌、測試事件報告及測試總結報告。

使用本規範的每個單位，要規定測試階段所應有的特定檔案，並在測試計劃中規定測試完成後所能提交的全部檔案。對於不同的設計層或不同規模的軟體，所選檔案的種類也可有所不同。

在所提供的每個標準檔案中，每一章的內容對於具體的應用和特定的測試階段可以有所增減。不僅可以調整內容，還可以在基本檔案集中增加另外的檔案。任何一個檔案都可以增加新的內容，並且某章若無可寫的內容，則可不寫，但須保留該章的編號。使用本規範的每個單位應該補充規定對內容的要求和約定，以便反映自己在測試、檔案控制、配置管理和質量保證方面所用的特定方法、裝置和工具。

附錄A（參考件）中，將敘述檔案編制實施及使用指南。

4.3 總體要求

以下將敘述各個測試檔案的書寫格式及內容。對於每一個檔案而言各章應按指定的次序排列，補充的章可以放在最後或放在“批准”一章的前面（如果該檔案最後一章是“批准”的話）。如果某章的部分或全部內容在另一檔案中，則應在相應的內容位置上列出所引用的材料，引用的材料必須附在該檔案後面或交給檔案的使用者。

5.內容要求

5.1 測試計劃

測試計劃結構如下圖所示。

下面給出每一章的詳細內容：

5.1.1 測試計劃名稱（本計劃的第1章）

為本測試計劃取現代戰爭專用的名稱。

5.1.2 引言（本計劃的第2章）

歸納所要求測試的軟體項和軟體特性，可以包括系統目標、背景、範圍及引用材料等。

在最高層測試計劃中，如果存在下述檔案，則需要引用它們：專案計劃、質量保證計劃、有關的政策、有關的標準等。

5.1.3 測試項（本計劃的第3章）

描述被測試的物件，包括其版本、修訂級別，並指出在測試開始之前對邏輯或物理變換的要求。

5.1.4 被測試的特性（本計劃的第4章）

指明所有要被測試的軟體特性及其組合，指明每個特性或特性組合有關的測試設計說明。

5.1.5 不被測試的特性（本計劃的第5章）

指出不被測試的所有特性和特性的有意義的組合及其理由。

5.1.6 方法（本計劃的第6章）

描述測試的總體方法，規定測試指定特性組志需的主要活動、、技術和工具，應詳盡地描述方法，以便列出主要的測試任務，並估計執行各項任務所需的時間。規定所希望的電低程度的測試徹底性，指明用於判斷測試徹底性的技術（如：檢查哪些語句至少執行過一次）。指出對測試的主要限制，例如：測試項可用性、測試資源的可用性和測試截止期限等。

5.1.7 項通過準則（本計劃的第7章）

規定各測試項通過測試的標準。

5.1.8 暫停標準和再啟動要求（本計劃第8章）

規定用於暫停全部或部分與本計劃有關的測試項的測試活動的標準。規定當測試再啟動時必須重複的測試活動。

5.1.9 應提供的測試檔案（本計劃的第9章）

規定測試完成後所應遞交的檔案，這些檔案可以是前述八個檔案的全部或者部分。

5.1.10 測試任務（本計劃的第10章）

指明執行測試所需的任務集合，指出任務音的一切依賴關係和所需的一切特殊技能。

5.1.11 環境要求（本計劃的第11章）

規定測試環境所必備的和希望的的性質。包括：硬體、通訊和系統軟體的物理特徵、使用方式以及任何其它支撐測試所需的軟體或裝置，指出所需的特殊測試工具及其它測試要求（如出版物或辦公場地等）。指出測試組目前還不能得到的所有要求的來源。

5.1.12 職責（本計劃的第12章）

指出負責管理、設計、準備、執行、監督、檢查和仲裁的小組。另外指出負責提供

5.1.3 中指出的測試項和在5.1.11中指出的環境要求的小組。

這些小組可以包括開發人員、測試人員、操作員、使用者代表、資料管理員和質量保證人員。

5.1.13 人員和訓練要求（本計劃的第13章）

指明測試人員應有的水平以及為掌握必要技能可供選擇的訓練科目。

5.1.14 進度（本計劃的第14章）

包括在軟體專案進度中規定的測試里程碑以及所有測試項傳遞時間。

定義所需的新的測試里程碑，估計完成每項測試任務所需的時間，為每項測試任務和測試里程碑規定進度，對每項測試資源規定使用期限。

5.1.15 風險和應急（本計劃的第15章）

預測測試計劃中的風險，規定對各種風險的應急措施（如：延期傳遞的測試項可能需要加夜班來趕上規定的進度。）

5.1.16 批准（本計劃的第16章）

規定本計劃必須由哪些人（姓名和職務）審批。為簽名和填寫日期留出位置。

5.2 測試設計說明

測試設計說明如下圖所示。

1 測試設計說明名稱

2 被測試的特性

3 方法詳述

4 測試用例名稱

5 特性通過準則

下面給出本說明每一章的詳細內容。

5.2.1 測試設計說明名稱（本說明第1章）

給每一個測試設計說明取一個專用名稱。如果存在的話，也可引用有關的測試計劃中給出的名稱。

5.2.2 被測試的特性（本說明的第2章）

規定測試項，描述作為本設計測試目標的特性和特性的組合，其它特性可以論及，但不必測試。

5.2.3 方法詳述（本說明的第3章）

將測試計劃中規定的方法進行細化，包括要用的具體測試技術，規定分析測試結果的方法（如比較程式或人工觀察）。

規定為選擇測試用例提供合理依據的一切分析結果。例如：可以說明容錯的條例（如：區別有效輸入和無效輸入的條件）。

歸納所有測試用例的共同屬性，可以包括輸入約束條件，共享環境的要求，對共享的特殊規程的要求及任何共享的測試用例間的依賴關係。

5.2.4 測試例名稱（本說明的第4章）

列出與本設計有關的每一測試用例的名稱和簡要說明。某個特定的測試用例可能在多個測試設計說明中出現，列出與本測試設計說明有關的規程及其簡要說明。

5.2.5 特性通過準則（本說明的第5章）

規定用於判別特性和特性組合是否通過測試的準。

5.3 測試用例說明

測試用例說明結構如下圖所示。

1 測試用例說明名稱

2 測試項

3 輸入說明

4 輸出說明

5 環境要求

6 特殊的規程說明

7 用例間的依賴關係

由於測試用例可能被由多個小組長期使用的多個測試設計說明引用，所以在測試用例說明中必須包含足夠具體的資訊以便重複使用。

下面給出本說明每一章的詳細內容。

5.3.1 測試用例說明名稱（本說明的第1章）

給本測試用例說明取一個專用名稱

5.3.2 測試項（本說明的第2章）

規定並簡要說明本測試用例所要涉及的項和特性、對於每一項、可考慮引用以下檔案：需求說明書、設計說明書、使用者手冊、操作手冊。

5.3.3 輸入說明（本說明的第3章）

規定執行測試用例所需的各個輸入。有些輸入可以用值（允許適當的誤差）來規定。而另一些輸入，如常數表或事務檔案可以用名來規定。規定所有合適的資料庫、檔案、終端資訊、記憶體常駐區域和由作業系統傳送的值。規定各輸入間所需的所有關係（如時序關係等）。

5.3.4 輸出說明（本說明的第4章）

規定測試項的所有輸出和特性（如：響應時間）。提供各個輸出或特性的正確值（在適當的誤差範圍內）。

5.3.5 環境要求（本說明的第5章）

5.3.5.1 硬體

規定執行本測試用例所需的硬體特徵和配置（如：80字元×24行的顯示終端）。

5.3.5.2 軟體

規定執行本測試用例所需的系統軟體和應用軟體。系統軟體可以包括作業系統、編譯程式、模擬程式和測試工具等。

5.3.5.3 其它

說明所有其它的要求，如特種設施要求或經過專門訓練的人員等。

5.3.6 特殊的規程要求（本說明的第6章）

描述對執行本測試用例的測試規程的一切特殊限制。這些限制可以包括特定的準備、操作人員干預、確定特殊的輸出和清除過程。

5.3.7 用例間的依賴關係（本說明的第7章）

列出必須在本測試用例之前執行的測試用例名稱，歸納依賴性質。

5.4 測試規程說明

測試規程說明結構如下圖表示

1 測試規程說明名稱

2 目的

3 特殊要求

4 規程步驟

下面給出本說明每一章的詳細內容。

5.4.1 測試規程說明名稱（本說明的第1章）

給每個測試規程說明取一個專用名稱，給出對有關測試設計說明的引用。

5.4.2 目的（本說明的第2章）

描述本規程的目的。如果本規程執行測試用例，則引用各有關的測試用例說明。

5.4.3 特殊要求（本說明的第3章）

指出執行本規程所需的所有特殊要求，包括作為先決條件的規程、專門技能要求和特殊環境要求。

5.4.4 規程步驟（本說明的第4章）

5.4.4.1 日誌

說明用來記錄測試的執行結果、觀察到的事件和其它與測試有關事件（見5.6條測試日誌和5.7條測試事件報告）的所有特殊方法或格式。

5.4.4.2 準備

描述新任務執行規程所必需的動作序列。

5.4.4.3 啟動

描述開始執行規程所必需的動作。

5.4.4.4 處理

描述在規程執行過程中所必需的動作。

5.4.4.5 度量

描述如何進行測試度量（如描述如何用網路模擬程式來充其量遠端終端的響應時間）。

5.4.4.6 暫停

描述因發生意外事件暫停測試所必需的動作。

5.4.4.7 再啟動

規定所有再撥動點和在啟動點上重新啟動規程所必需的動作。

5.4.4.8 停止

描述正常停止執行時所必需的動作。

5.4.4.9 清除

描述恢復環境所必需的動作。

5.4.4.10 應急

描述處理執行過程中可能發生的異常事件所必需的動作。

5.5 測試項傳遞報告

測試項傳遞報告結構如下圖所示。

1 傳遞報告名稱

2 傳遞項

3 位置

4 狀態

5 批准

下面給出本報告每一章的詳細內容。

5.5.1 傳遞報告名稱（本報告的第1章）

為本測試項傳遞報告取一個專用名稱。

5.5.2 傳遞項（本報告的第2章）

規定被傳遞的項及其版本/修訂級別。提供與傳遞項有關的項檔案和測試計劃的相關資訊，指出對該傳遞項負責的人員。

5.5.3 位置（本報告的第3章）

規定傳遞項的位置及其所在媒體。

5.5.4 狀態（本報告的第4章）

描述被傳遞的測試項的狀態，包括其與項檔案、這些項的以往傳遞以及測試計劃的差別。列出希望由被傳遞項解決的事件報告。

5.5.5 批准（本報告的第5章）

規定本傳遞報告必須由哪些人（姓名和職務）審批，併為簽名和日期留出位置。

5.6 測試日誌

測試日誌結構如下圖所示。

1 測試日誌名稱

2 描述

3 活動和事件條目

 下面給出本報告每一章的詳細內容。

5.6.1 測試日誌名稱（本日誌的第1章）

為本測試日誌取一專用的名稱。

5.6.2 描述（本日誌的第2章）

除了在日誌條目中特別註明的以外，用於日誌中所有條目的資訊都包括在本章中。應該考慮有以下資訊：

（1）規定被測試項及其版本/修訂級別。如果存在的話，引用各項的傳遞報告。

（2）規定完成測試的環境屬性，包括裝置說明、所用的硬體、所用的系統軟體及可用儲存容量等可用資源。

5.6.3 活動和事件條目（本日誌的第3章）

對每個事件（包括事件的開始和結束），記錄發生的日期和時間，並說明記錄者。應考慮以下各項資訊。

5.6.3.1 執行描述

記錄所執行的測試規程的名稱，並引用該測試規程說明。記錄執行時在場人員，包括：測試者、操作員和觀察員，還要說明每個人的作用。

5.6.3.2 測試結果

對每次執行，記錄人工可觀察到的結果（如：產生的錯誤資訊、異常中止和對操作員動作的請求等），還要記錄所有輸出的位置（如磁帶號碼），記錄測試的執行是否成功。

5.6.3.3 環境資訊

記錄本條目的的一切特殊的環境條件。

5.6.3.4 意外事件

記錄意外事件及其發生前後的情況（如請求顯示總計，螢幕顯示正常，但響應時間似乎異常長，重複執行時響應時間也同樣過長）。記錄無法開始執行測試或無法結束測試的周圍環境（如電源故障或系統軟體問題）。

5.6.3.5 事件報告名稱

每產生一個測試事件報告時，記錄其名稱。

5.7 測試事件報告

測試事件報告結構如下圖所示。

1 測試事件報告名稱

2 摘要

3 事件描述

4 影響

 下面給出本報告每一章的詳細內容。

5.7.1 測試事件報告名稱（本報告的第1章）

為本測試事件報告取一個專用名稱。

5.7.2 摘要（本報告的第2章）

簡述事件，指出有關測試項及其版本/修訂級別。引用有關的測試規程說明、測試用例說明及測試日誌。

5.7.3 事件描述（本報告的第3章）

對事件進行描述。該描述應包括以下各項：

輸入

預期結果

實際結果

異常現象

日期和時間

規程步驟

環境

重複執行的意圖

測試者

觀察者

該描述應該包括有助於確定事件發生原因及改正其中錯誤的有關浩劫及觀察。例如，描述可能對此事件有影響的所有測試用例執行情況，描述與已公佈的測試規程之間的一切差異等。

5.7.4 影響（本報告的第4章）

在所知道的範圍內指出本事件對測試計劃、測試設計說明、測試規程說明或測試用例說明所產生的影響。

5.8 測試總結報告

規定本報告必須由哪些人（姓名和職務）審批，併為簽名和日期留出位置。

單元測試報告

編者說明：

    單元測試是每一個開發人員都必須去做的事，它將採用白盒方法來進行，為了跟蹤單元測試的效果，對開發人員進行督促，對於一些重要的模組進行測試是很必要的。該表格就是用來讓開發人員填寫單元測試的結果的文件。

填表日期：                                   編號：

五、其它類模組開發說明(ISO標準)

程式設計說明：

    該文件將與模組開發卷宗結合使用，卷宗是對整個系統進行整理，而模組開發說明則是對具體的模組進行說明，其作用於歸檔階段。

1．標題

[系統名稱和識別符號]

[模組名稱和識別符號]

[程式編制員簽名]

[卷宗的修改文字序號]

[修改完成日期]

[卷宗序號]

[編排日期]

2．模組開發情況表

3．功能說明

    [扼要說明本模組的功能,主要是輸入、要求的處理、輸出。可以從系統設計說明書中摘錄。同時列出在需求說明書中對這些功能的說明的章、條、款。]

4．設計說明

    [說明本模組的設計考慮]

5．硬體部分的設計結果

1）  經專案組除錯通過的硬體成品1件

2）設計檔案：

《原理圖》

《PCB圖》

《BOM清單》

《可程式設計器件及燒錄進位制檔案》

《必要測試點波形圖或硬體指標評細說明》

《原理詳細說明》

《與系統內其他部分介面軟硬體詳細說明》

   這些檔案可以附件的形式列後。

6．軟體的設計結果

    [要給出所產生的本模組的第一份無語法錯的原始碼清單以及已通過全部測試的當前有效的源程式程式碼。]

7．測試說明

    [說明直接要經過本模組的每一項測試，包括這些測試各自的識別符號和編號、進行這些測試的目的、所用的配置和輸入、預期的輸出及實際的輸出。]

8．複審的結論

    [把實際測試的結果，同需求說明書、系統設計說明書中規定的要求進行比較和給出結論。]