1. 程式人生 > >06-軟體測試計劃及測試說明

06-軟體測試計劃及測試說明

1  範  圍

1.1  定  義

1.1.1  系統標識

包含該文件所適用的軟體標識號、標題和版本號。

1.1.2  測試用例標識

“用例標識”:規定為:系統代號_分系統代號_軟體識別符號 _測試型別_用例名簡稱;例如XXX系統代號為“ABC”的軟體功能測試標識為:_ABC_ GN_001。

“系統代號”、“分系統代號”、“軟體識別符號”取值參見E.7節“文件編寫要求”。

“測試型別”:取值範圍為功能測試(GN)、效能測試(XN)、介面測試(JK)。

“用例名簡稱”:取值為用例名簡稱或者序號,序號為三位,從001起編。

1.1.3  術  語

列出本文件適用的術語及其定義。如軟體配置項、計算機軟體部件、計算機軟體單元等。

1.1.4  錯誤等級

測試的軟體缺陷分為四級:

a)致命錯誤

導致下述後果之一的軟體缺陷,視為致命錯誤:軟體宕機;軟體崩潰;軟體異常退出;資料丟失,且很難恢復。

b)嚴重錯誤

導致下述後果之一的軟體缺陷,視為嚴重錯誤:沒有實現軟體需求,對軟體功能有較大影響;沒有正確實現軟體需求,導致軟體不能正常使用;資料丟失,但較容易恢復。

c)一般錯誤

導致下述後果之一的軟體缺陷,視為一般錯誤:沒有實現軟體需求,對軟體功能影響較小;沒有正確實現軟體需求,但對正確使用軟體其他功能沒有影響或影響較小;軟體操作與軟體使用說明不符。

d)建議改進

對於已經實現軟體需求,但使用不方便的軟體功能提出改進建議。

1.2  系統概述

簡述文件所適用的系統和軟體的用途。應描述系統和軟體的一般特性;概述系統開發、執行和維護的歷史(若有);標識專案的需方、使用者、開發方和保障機構;標識當前的和計劃的執行現場;列出其它相關文件。

1.3  文件概述

概述文件的用途(包括其來源、作用、是編寫哪些文件的依據等)和主要內容,並描述與其使用有關的保密性要求。

1.4  與其它計劃的關係

說明本軟體測試計劃與其它專案管理計劃的關係(若有)。否則,用“不適用”註明。

2  引用文件

列出該文件中引用到的所有文件的編號、標題、修訂版及日期。引用檔案按照國家標準、國家軍用標準、行業標準、檔案的順序排列。

3  軟體測試環境

注:視需要劃分為若干節來描述每一個預期的測試現場的軟體測試環境。

3.x (測試現場名)

注:標識用於測試的一個或多個測試現場,應劃分為以下幾個子節來描述每一個現場的軟體測試環境。如果所有測試都在同一個現場進行,本節及其下面的子節只出現一次。如果多個測試現場使用相同的或類似的軟體測試環境,可以一起介紹。後面可以引用前面的說明,這樣能減少測試現場說明中的重複資訊。

3.x.1  軟體項

通常應通過名稱、編號和版本來標識在測試現場為實現計劃中的測試活動所需要的軟體項(例如,作業系統、編譯器、通訊軟體、相關的應用軟體、資料庫、輸入檔案、程式碼審計程式、動態路徑分析程式、測試驅動程式、預處理程式、測試資料生成程式、測試控制軟體、其它專用測試軟體、後處理程式)。還應描述每一個軟體項的用途,說明它的介質(磁帶、磁碟等),指明哪些是要由該現場負責提供的,還應指明與這些軟體項有關的任何保密措施或其它保密性、私密性問題。

3.x.2  硬體項

通常應通過名稱、編號和版本來標識在測試現場的軟體測試環境中要使用的計算機硬體,介面裝置,通訊裝置等。本節應描述每一項的用途,說明每一項所需要的使用週期和數量,指明哪些是要由該現場負責提供的,還應指明與這些項有關的任何保密措施或其它保密性、私密性問題。

3.x.3  其它材料

標識並描述在測試現場進行測試所需的其它材料。這些材料可能包括手冊、軟體清單、包含著被測軟體的介質、包含著測試用資料的介質、輸出樣板,以及其它表格和指導材料。本節應標識將交付給該現場的和希望由該現場提供的那些項。本說明通常應包括的這些材料的型別、佈局和數量。本節還應指明與這些項有關的任何保密措施或其它保密性、私密性問題。

3.x.4  安裝、測試和控制

標識開發方執行下列每項工作的計劃,這些工作可能需要測試現場的人員給予配合:

a. 獲取或開發軟體測試環境中用到的每一個要素

b. 在使用之前,安裝並測試軟體測試環境中的每一項

c. 控制並維護軟體測試環境的每一項

3.x.5  參測單位

本節應標識參加測試現場測試工作的單位以及它們的作用和職責。

3.x.6  人  員

標識在測試現場測試期間所需要人員的數量、型別和技能水平,需要他們的日期和時間,以及任何特殊的需要,例如,為保證大規模測試工作的連續性和一致性,需要輪班操作並始終保持關鍵技能。

3.x.7  定向計劃

描述在測試前和測試中要進行的任何定向和培訓。此資訊與3.1.x.6中給出的人員需求有關。培訓可包括使用者指導、操作員指導、維護和控制組指導以及對全體人員分工定位的簡述。如果預計有大範圍培訓的話,可單獨制定一個計劃,而在這兒引用之。

3.x.8  要執行的測試

通過引用第3.2章來標識將在測試現場執行的測試。

4  測試標識

注:劃分為以下幾節來標識和描述本測試計劃所適用的每一個測試。

4.1  一般資訊

劃分為若干子節來提供適用於所要執行的整個測試的一般性資訊。

4.1.1  測試級別

描述測試將在哪些級別上執行,例如,CSCI級或系統級。

4.1.2  測試類別

描述將要執行的測試的型別或類別(例如,定時測試,錯誤輸入測試,最大能力測試)。

4.1.3  測試條件

本節應描述適用於所有測試或一組測試的條件。

a)系統的每個特性應至少被一個正常測試用例和一個被認可的異常測試用例覆蓋;

b)測試用例的輸入應至少包括有效等價類值、無效等價類值和邊界資料值;

c)應逐項測試系統/子系統設計說明規定的系統的功能、效能等特性;

d)應測試軟體配置項之間、軟體配置項和硬體之間的所有介面;

e)應測試系統的輸出及其格式;

f)應測試執行條件在邊界狀態和異常狀態下,或在人為設定的狀態下,系統的功能和效能;

g)應測試系統訪問和資料全性;

h)應測試系統的全部儲存量、輸入/輸出通道和處理時間的餘量;

i)應按照系統/子系統設計文件的要求,對系統的功能、效能進行強度測試;

j)應測試設計中用於提高系統安全性、可靠性的結構、演算法、容錯、冗餘、中斷處理等方案;

k)對安全性關鍵的系統,應對其進行安全性分析,明確每一個危險狀態和導致危險的可能原因,並對此進行鍼對性的測試;

l)對有恢復和重置功能需求的系統,應測試其恢復或重置功能和平均恢復時間,並且對每一類導致恢復或重置的情況進行測試;

m)對不同的實際問題應外加相應的專門測試。

對具體的系統,可根據軟體測試任務書(合同或專案計劃)及系統的重要性、安全關鍵等級等要求對上述內容進行裁減。

4.1.4  測試方法

系統測試一般採用黑盒測試。通常採用的方法主要有a)功能分解:針對軟體主要功能;b)等價類劃分:劃分為有效等價類和無效等價類;c)邊界值分析:針對軟體邊界進行測試用例設計;d)判定表:針對有多個條件的情況設計測試用例;e)因果圖:主要針對有因果關係的功能點。

4.2  計劃執行的測試

劃分為以下幾個子節來完整地描述所計劃的全部測試。

4.2.x (一個待測試項)

注:通過名字和專案唯一識別符號來標識一個CSCI、子系統、系統或其它實體,並劃分為以下幾個子節來描述針對各個項計劃要作的測試。(注:本計劃中“測試”一詞是指測試用例之集合。)

4.2.x.y (一個測試的專案唯一識別符號)

通過專案唯一識別符號來標識一個測試,併為該測試提供下面指定的資訊。可視需要引用4.1節中的一般資訊。

a. 測試物件

b. 測試級別

c. 測試型別或類別

d. 需求規格說明中指定的合格性方法

e. 該測試所涉及的CSCI需求以及軟體系統需求的識別符號;(另一種辦法是在第6章中提供這一資訊。)

f. 特殊需求(例如,48小時連續工作,武器模擬,測試程度,使用一種特殊的輸入或使用資料庫)

g. 應記錄的資料的型別

h. 應採用的資料記錄/簡約/分析的型別

i. 假設和約束,例如預期由於系統或測試條件-時限、介面、裝置、人員、資料庫等原因導致測試的侷限性;

J. 與該測試有關的安全性、保密性及私密性考慮。

表F-1 (被測試項名稱)計劃進行的測試

序號

測試點

測試用例

用例名稱

用例標識

測試型別

用例描述

備註

注:

a)“測試點”:參考軟體需求規格說明的系統需求節,取為名詞片語或者編號;

b)“用例名稱”:參考軟體需求規格說明的系統需求節,取為名詞片語;

c)“用例標識”:參見1.1.2 ;

d)“測試型別”:“功能測試”、“效能測試”或“介面測試”;

e)“用例描述”:參考軟體需求規格說明的系統需求節撰寫;

f)“備註”可包括:假設與約束,如由於系統或測試條件、時間、介面、裝置、人員、資料庫等的原因而對測試產生的預期限制;與測試有關的安全性、保密性要求;被呼叫的測試過程名稱;特殊需求(如:裝置連續工作48h、特殊輸入或資料庫的使用)等。

5  測試進度

包含或引用實施本計劃所標識測試的時程。它應包括:

a. 用圖表來描述安排進行測試的現場以及進行測試的時間區間。

b. 針對每個測試現場,分別說明下列活動和事件的進度。通常按時間排序並附帶必要的解釋:

    現場測試的週期和分配給該測試的主要部分的週期;

    現場測試前用於建立軟體測試環境及其它裝置、進行系統除錯、定向和熟悉測試事宜所需要的時間;

    該測試所需要的資料庫/資料檔案值,輸入值,及其它操作資料的收集;

    實施測試,包括計劃中的再測試;

    軟體測試報告的準備、評審和批准。

表F-2  測試進度表

被測試項名稱

測試現場名稱

現場完備時間

資料庫/資料準完備時間

實施測試時間

迴歸測試時間

備  注

6  需求可追蹤性

包含:

a. 從本計劃中標識的每一個測試,到它所涉及的CSCI需求以及軟體系統需求的可追蹤性。

b. 從本測試計劃所覆蓋的每一個CSCI需求以及每一個軟體系統需求,到針對它的測試的可追蹤性。這種可追蹤性應覆蓋所有適用的《軟體需求規格說明》中的CSCI需求。

7  測試說明

分小節用名字/專案唯一識別符號描述被測系統(軟體)的每個被測試項的有關資訊。

7.x (一個測試的專案唯一識別符號)

注:通過專案唯一識別符號來標識一個測試,應劃分為以下幾個子節。當所需資訊與前面為另一個測試所指出的資訊重複時,可引用之而無需重複。

7.x.y (一個測試用例的專案唯一識別符號)

注:通過專案唯一識別符號來標識一個測試用例,說明其目的並提供簡要的說明。由下列幾個子節來提供該測試用例的詳細說明。

表F-3  測試說明用表

用例名稱

用例標識

測試需求標識

軟體名稱

關聯的配置項

軟體作者:

測試人員:

監測人員:

測試日期:

測試型別

功能測試     □

效能測試     □

介面測試     □

測試描述

簡要描述測試過程和目的。

測試過程

測試

步驟

前提和約束

測試目的

測試輸入

預期結果

測試結果

相關推薦

06-軟體測試計劃測試說明

1  範  圍 1.1  定  義 1.1.1  系統標識 包含該文件所適用的軟體標識號、標題和版本號。 1.1.2  測試用例標識 “用例標識”:規定為:系統代號_分系統代號_軟體識別符號 _測試型別_用例名簡稱;例如XXX系統代號為“ABC”的軟體功能測試標識為:_AB

軟體工程之軟體測試⑤,軟體維護⑥(測試計劃測試分析報告)

      在軟體開發過程中,特別是在開發大型軟體系統的過程中,面對的問題是極其複雜的, 因此,在軟體生命週期的每個階段就不可避免地會產生差錯。應該在每個階段結束之前通過嚴格的技術審查,儘可能早地發現並糾正差錯。但是,審查並不能發現所有錯誤,此外在編碼過程中還不可避免地

軟體測試分類測試中三個主要概念

軟體測試分類: 按測試技術,軟體測試可分為:黑盒測試、白盒測試、灰盒測試 黑盒測試:在程式介面進行測試,它只是檢查程式功能是否按照規格說明書的規定正常使用。也被稱為功能測試或者資料驅動測試。 白盒測試:要完全瞭解程式結構和處理過程,它按照程式內部邏輯測試程式,檢驗程式中每條

軟體各種環境測試階段

軟體各種環境 開發環境:開發環境是程式猿們專門用於開發的伺服器,配置可以比較隨意, 為了開發除錯方便,一般開啟全部錯誤報告。 測試環境:一般是克隆一份生產環境的配置,一個程式在測試環境工作不正常,

軟體測試計劃測試方案區別

測試方案軟體過程:測試計劃評審通過—>設計測試方案—>測試方案評審通過—>依據測試方案設計測試用例—>測試用例評審通過—>依據測試方案搭建測試環境。   五、文件內容   測試計劃和測試方案的本質區別是內容不同。   測試計劃的核心內容

日程管理APP的測試計劃測試矩陣

集成 說明 計劃 idt 無線 roi ble -c nbsp 測試計劃:(完成整個APP時間:2周) 編號 測試時間 測試內容 1 第2天 在需求設計階段,檢查產品說明文檔及設計文檔 2 第3~9天 在編碼階段,編寫測試用例 3 第10~11天 集成測試

學生管理App測試計劃測試矩陣

andro 管理員 屏幕分辨率 分辨率 ios 4.4 開始 ble 學生 學生管理測試計劃: 裏程碑項目 開始時間 結束時間 測試規劃 2017.4.1 2017.4.2 測試設計 2017.4.2 2017.4.3 測試設計實施 2017.4.4 20

日程管理的測試計劃測試矩陣

矩陣 ima ont -s pan size alt 計劃 技術分享 一、測試計劃 二、測試矩陣 日程管理的測試計劃和測試矩陣

關於測試策略,測試方針,測試計劃測試方案的理解

技術 就會 什麽 ali 是否有效 軟件 是否 width 計劃 一.什麽是測試策略  簡單來說就是,測什麽,怎麽測。 一般可以歸納為6個問題   1)測試的對象和範圍是什麽?   2)測試的目標是什麽?   3)測試的深度到哪裏,廣度又到哪裏?   4)測試的重點

App測試流程測試點(個人整理版)

1 APP測試基本流程 1.1流程圖 1.2測試周期 測試周期可按專案的開發週期來確定測試時間,一般測試時間為兩三週(即15個工作日),根據專案情況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管確認專案排期。 1.3測試資源 測試任務開始前,檢查各項測

移動網際網路APP測試流程測試點(轉載) (二)

2.1安全測試 2.1.1軟體許可權 1)扣費風險:包括髮送簡訊、撥打電話、連線網路等 2)隱私洩露風險:包括訪問手機資訊、訪問聯絡人資訊等 3)對App的輸入有效性校驗、認證、授權、敏感資料儲存、資料加密等方面進行檢測 4)限制/允許使用手

測試計劃測試方案區別

        關於測試計劃和測試方案的區別,這裡主要從編寫目的、定義和層次、編寫時間和依據、軟體過程、文件內容這五方面來說明,具體內容如下: 一、編寫目的 制定測試計劃目的:按照所制定的測試計劃可以有效的計劃、執行、跟蹤、組織和管理測試專案。具體從一下三方面來說: 1

測試經驗測試方法

提出問題,分析問題,總結問題,改進問題產出  產出  產出!!! 一,測試型別 1.功能測試:最基礎的測試型別,主要對產品的各個功能進行驗證,檢查是否滿足產品需求。 1.1 測試用例設計:

線上考試系統——測試計劃 詳細測試報告——testlink

TestLink Community [configure $tlCfg->document_generator->company_name] 線上考試系統1 線上考試系統——測試計劃 詳細測試報告 專案: 線上考試系統1 專案 範圍:  線上考試與查詢的系

App測試流程測試點(個人整理版)-轉

單純從功能測試的層面上來講的話,APP 測試、web 測試 在流程和功能測試上是沒有區別的。 系統架構方面: web專案,一般都是b/s架構,基於瀏覽器的 app專案,則是c/s的,必須要有客戶端,使用者需要安裝客戶端。 web測試只要更新了伺服

做好測試計劃測試用例工作的關鍵!!!

本週51testing每週一問的這個問題很精彩,於是我做了如下回答。 問題如下: 測試的流程中,測試計劃是對整個測試活動的安排,而測試用例則是測試執行的指導,但是,現在仍然有很多的測試人員沒有認識到測試計劃和測試用例的重要性,在專案時間比較緊張的情況下,計劃和用例往往

資料庫測試目標測試方法概述。

資料庫測試的主要目標是:確保資料庫訪問方法和程序正常執行,資料不會遭到損壞。 測試方法: ?? 分別測試記錄的新增、修改、刪除等操作,以驗證前臺與後臺資料的一致性為主。 ?? 測試記錄的查詢功能,檢查返回的資料是否正確,並測試相關功能。 ?? 測試資料的不同顯示方式。 ??

UML軟體測試 計劃 設計和執行: 解空間測試常見錯誤糾正方法

軟體測試 計劃 設計和執行 ◾計劃和組織軟體專案中的測試 ◾欣賞不同的測試方法 ◾建立與包相對應的測試設計 ◾為類測試建立測試工具 ◾為用例測試建立功能測試用例 ◾使用等價分割槽和邊界值建立樣本測試資料 ◾記錄執行測試用例和整理結果的步驟 ◾規劃執行測試(例如

符合 ISO26262 規範的軟體開發測試諮詢服務

概述 隨著汽車電子系統的普及性和複雜性不斷地提高,汽車電子產品的系統失效、部件失效等安全問題日益嚴峻。恆潤科技從 2008 年起開始研究 ISO-26262 功能安全相關標準和技術 , 2012 年恆潤參與國標委組織的功能安全標準的討論會,併成為功能安全標準制定小組的成員。 經過多年的研究和

軟體測試流程規範(參考大華為的規範)

軟體測試流程及規範(參考大華為的規範) 參考某大佬(窩真不知道是哪位大佬)總結的測試流程並結合在華為做測試學到的規範,整理的我們公司的測試流程,分享是一種美德,so開始你的閱讀吧~ 軟體測試流程及規範 一、目標 制定完整且具體的測試路線和流程,為快速、高效和高質量的軟體測試提供基礎流