軟件測試第八章-測試計劃與測試文檔_第1頁
軟件測試第八章-測試計劃與測試文檔_第2頁
軟件測試第八章-測試計劃與測試文檔_第3頁
軟件測試第八章-測試計劃與測試文檔_第4頁
軟件測試第八章-測試計劃與測試文檔_第5頁
已閱讀5頁,還剩44頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

第8章測試計劃與測試文檔

高效率的測試是經過計劃的。成功的測試需要有一定的方法。利用組織良好的測試計劃、測試用例和測試報告,正確交流和制訂測試工作是測試人員達到目標的保障。本章主要討論與每一測試活動有關的具體任務和可交付文檔。本章重點:

測試計劃

驗證測試計劃

確認測試計劃

軟件測試文檔高效率的測試是經過計劃的。成功的測試需要有一定的方法,包括條例、結構、分析和度量。

8.1測試計劃好的測試計劃應該包括以下幾方面的內容:●

目的●測試策略

●資源配置●

任務明確●進度安排●風險分析●停止測試的標準●測試用例庫●組裝方式●記錄手段●工具●回歸測試8.2軟件測試文檔軟件測試文檔用來描述要執行的軟件測試及測試的結果。測試文檔的編制是測試工作規范化的一個重要組成部分。包括以下幾個內容:●

測試計劃:該計劃描述測試活動的范圍、方法、資源和進度,其中規定了被測試的對象,被測試的特性、應完成的測試任務、人員職責及風險等。●

測試設計規格說明:該說明詳細描述測試方法,測試用例以及測試停止的準則等。●

測試用例規格說明:該說明描述測試用例涉及的輸入、輸出,對環境的要求,對測試規程的要求等。

測試步驟規格說明:該說明規定了實施測試的具體步驟。●

測試日志:該日志是測試小組對測試過程所作的記錄。●

測試事件報告:該報告說明測試中發生的一些重要事件。●

測試總結報告:對測試活動所作的總結和結論。

8.2軟件測試文檔測試文檔的類型8.2

測試文檔驗證需求的正確性檢驗測試資源明確任務的風險開發測試用例評價測試結果回歸測試確定測試的有效性測試文檔的重要性表現在以下幾個方面:8.3

主測試計劃制定主測試計劃的目標是:規定測試活動的范圍、方法、資源和進度;明確正在測試的項目、要執行的主要測試任務、每個任務的負責人,以及與計劃相關的風險。制定主測試計劃是要在上層文檔中弄清全貌,要進行什么類型的測試,有多少驗證測試工作,進行什么樣的確認測試,需要什么樣的整體策略等。(1)目標8.3

主測試計劃

風險是指任何威脅到項目目標成功實現的因素。測試的一個基本的原則是對項目中最具風險的部分進行詳細的測試,以確保最具破壞性的故障能夠被發現。在測試的每個層次上確定基于風險的優先級問題非常重要。主測試計劃風險管理要考慮的問題包括:

●軟件的大小和復雜性;●軟件的關鍵性;●軟件開發過程成熟度;●測試形式,進行全面測試還是部分測試;●人員、經驗和組織等。(2)風險分析8.3

主測試計劃主測試計劃可交付的文檔之一是軟件驗證測試計劃和確認測試計劃。按照IEEE/ANSI標準,軟件驗證和確認測試計劃大綱包括以下幾方面的內容:

目的●參考文件●定義●驗證和確認測試概要●生存周期的驗證和確認測試任務●軟件驗證和確認測試報告●驗證和確認測試管理(3)驗證和確認測試計劃大綱8.4

驗證測試計劃驗證測試活動包括:需求驗證功能設計驗證詳細設計驗證代碼驗證驗證任務包括對各個驗證活動制定測試計劃并執行測試。8.4.1

制定驗證測試計劃(1)制定驗證測試考慮的問題:

要進行的驗證活動(需求驗證、功能設計驗證、詳細設計驗證、代碼驗證);●采用的方法(審查、走查等);●軟件需要或不需要進行驗證測試的區域;●不對軟件某些區域進行驗證測試的風險;●所需的資源、進度、設備、工具、責任等。8.4.1

制定驗證測試計劃(2)驗證測試計劃大綱

驗證測試計劃大綱包括以下幾方面的內容:

測試計劃標識●驗證活動●要驗證和不要驗證的區域●任務●責任●人員配備和培訓●進度安排●風險和意外事故●審批8.4.2驗證執行驗證執行可采用審查、走查、伙伴檢查等方式進行。(1)審查報告

每次驗證執行后應提交一份相應的審查報告。審查報告(大綱)可包括如下幾方面的內容:

審查報告標識●測試項目和版本●參審人員●被審查材料的規模●審查小組的準備時間●返工的工作量及返工結束的預期日期●故障清單●故障概要(分類整理的故障數量)8.4.2驗證執行(2)驗證測試報告驗證測試報告是對驗證活動的概要說明。驗證的目標是對所有與軟件有關的文檔進行驗證測試,但最終驗證了多少?出現了哪些需要解決的內部問題?哪些已經完成?哪些還沒有完成?可以把驗證測試報告當作一種執行概要,用于提高管理層對測試過程的認識,引起他們對有關問題的注意。每一驗證活動都應有一個驗證測試報告,目的是對這一驗證活動的所有驗證進行概括總結。8.5確認測試計劃確認測試活動包括:

單元測試和集成測試●可用性測試●功能測試●系統測試●驗收測試確認測試任務

●將所有確認測試活動看作一個整體,制定主確認測試計劃●以確認測試活動為單位制定詳細測試計劃,開發測試用例,執行測試,評估測試,維護測試。8.5.1制定確認測試計劃(1)制定確認測試計劃時應考慮的幾個問題:

確認測試采用的方法●測試執行所需的設備●測試工具和支撐軟件●測試配置管理●風險分析、預算、資源要求、進度安排、人員配備等。8.5.1制定確認測試計劃(2)主確認測試計劃大綱主確認測試計劃是為整個確認測試工作制定的,是對整個確認測試工作的概括,即確定具體的確認測試活動、每一確認測試活動大致需要的資源、粗略的進度安排、總的培訓要求和風險等,但不涉及具體的細節。主確認測試計劃包括目的和大綱兩方面的內容。8.5.1制定確認測試計劃(2)主確認測試計劃大綱目的:規定測試活動的范圍、方法、資源要求和進度安排等。大綱包含以下一些內容:

●測試計劃標識●測試概述●測試項目●要測試的特征●不要測試的特征●測試方法●測試任務●測試環境要求●進度安排●項目通過/不通過的標準●測試停止標準●測試可交付文檔●風險和偶然事件●人員配備和培訓要求●審批8.5.2測試結構設計每個重要的軟件產品都有并且只有一個測試結構規格說明,用來說明測試是如何組織的,它們是基于需求還是基于功能還是基于內部結構的測試?如何將它們進行分類?如何構建測試用例庫等?測試結構設計需要考慮幾方面的內容:●測試基礎(基于需求、功能、還是內部結構);●測試的分類和分類規則;●測試用例庫的結構和命名則等。8.5.3詳細測試設計

詳細測試設計是指定測試方法并確定測試用例的過程,包括確定測試的目標,哪些方面要優先考慮,對于相關的測試項目組,任何集中高層測設計,但詳細測試設計不給出具體的測試用例或者執行測試的步驟。(1)詳細測試設計考慮的問題:

測試目標;●測試結構;●設計測試用例等。8.5.3詳細測試設計(2)詳細測試設計的基本步驟確定要測試的目標;以風險為基礎確定哪些項目要優先測試;針對相關測試項目組,開發高層測試設計;根據高層測試設計,設計測試用例。8.5.3詳細測試設計(3)測試目標確定測試目標確定是指確定所有要測試項目的目標,即對需求和功能設計規格說明進行仔細研究、分解和分析,為基于功能的測試開發出測試目標清單。對測試目標清單進行提煉時可采取以下幾步:如果基于需求和基于功能的測試目標清單是獨立開發出來的,則對兩份清單進行比較,刪除多余的測試目標。以進度安排、資源要求和不測試各項的風險為基礎,對各測試目標進行低、中、高優先級篩選。對于每一目標清單,生成一個覆蓋矩陣,用以說明測試目標和測試用例之間的關系,即哪些測試用例覆蓋了哪些測試目標。對于關鍵軟件,生成一個需求跟蹤矩陣。

一個需求跟蹤矩陣示范。

8.5.3詳細測試設計8.5.3詳細測試設計(4)測試設計規格說明測試設計規格說明是一種概括性文檔,其目的是組織和描述針對具體特征需要進行的測試,以幫助確定測試用例。按照IEEE/ANSI標準829/1983,測試設計規格說明包括:目的:指出測試方法的改進之處,確定設計和相關測試所覆蓋的特征,確定測試用例和測試步驟,并指定特征通過/不通過標準。大綱:

●測試設計規格說明標識●要測試的特征●方法●確定測試用例●特征通過/不通過規則8.5.3詳細測試設計(5)測試用例規格說明一個測試用例可以通過多個測試設計規格說明確定,每一個測試設計規格說明又有一個或多個測試用例規格說明。按照IEEE/ANSI標準829/1983,測試用例規格說明包括:目的:定義測試設計規格說明確定的測試用例。大綱:

●測試用例規格說明標識●測試項●輸入要求●輸出要求●環境要求●特殊要求●測試用例之間的依賴關系有條不紊地仔細計劃測試用例,是達到測試目標的必由之路,因為:●

組織性。正確地計劃和組織測試用例,有助于測試人員和其他項目小組成員有效地審查和使用它們。●

重復性。項目期間會多次執行同樣的測試,以尋找新的軟件故障,保證老的軟件故障得以修復。●

跟蹤。計劃執行了多少個測試用例,在軟件最終版本上執行了多少個測試用例,多少個測試失敗?是否有忽略的測試用例,如果測試用例沒有計劃,就不能回答這些問題。●

測試證實。在少數高風險行業中,軟件測試小組必須證明確實執行了計劃執行的測試。發布忽略某些測試用例的軟件實際上是不合法和危險的。8.5.3詳細測試設計8.5.3詳細測試設計(6)測試實施

實施是將每一測試用例規格說明翻譯成可執行測試用例的過程。測試實施可交付的文檔包括:

●測試用例●測試步驟規格說明●己完成的功能覆蓋矩陣●己完成的需求覆蓋矩陣●對于關鍵軟件,己完成的需求跟蹤矩陣8.5.3詳細測試設計(7)測試步驟規格說明測試步驟規格說明一步一步解釋如何進行測試設置,如何開始測試,如何監視測試運行,以及測試停止后如何重新開始測試。測試步驟規格說明包括:目的:確定進行測試需要的所有步驟。大綱:

測試步驟規格說明標識●特殊要求●啟動測試的步驟●判斷測試結果的標準●偶然事件處理步驟

●測試執行步驟8.5.3詳細測試設計上面介紹的幾種測試計劃規格說明關系如圖8-1所示。

8.5.4測試執行和事故報告1.測試執行測試執行是執行所有或挑選的測試用例并對結果進行觀察的過程。包括:

測試用例選擇●執行前設置、執行后分析●記錄活動、結果和事件●判斷故障是由軟件錯誤還是由測試本身的錯誤引起的●測量內部邏輯覆蓋測試執行的主要可交付文檔包括測試記錄、測試事故報告和邏輯覆蓋報告。8.5.4測試執行和事故報告2.測試記錄

測試記錄保留了測試執行的有關細節。按照IEEE/ANSI標準829-1983,測試記錄包括:目的:按時間順序記錄測試執行的有關細節。大綱:

●測試記錄標識●測試描述●事件記錄8.5.4測試執行和事故報告3.事故報告

事故報告是軟件故障(即問題、缺陷、錯誤)報告的別名,其中最重要的部分是事故描述,這一部分不僅要描述出現的情況,還應該將預期結果與實際結果進行比較。報告軟件故障的基本原則是:

●盡快報告軟件故障。●有效描述軟件故障。●報告軟件故障時不做評價,只針對產品,陳述事實。●完善軟件故障報告,保證軟件故障被正確報告。小軟件故障嚴重軟件故障項目開始

時間

項目結束可能修復的軟件故障圖8-2時間和故障修復之間的關系8.5.4測試執行和事故報告時間和故障修復之間的關系軟件故障的嚴重性和優先級

任何軟件故障報告都必須由提供者注明故障的嚴重性和優先級別。嚴重性表示軟件故障的惡劣程度,反映其對產品和用戶的影響。優先級表示修復故障的重要程度和應該何時進行修復。嚴重性:系統崩潰、數據毀壞、數據丟失。遺漏功能、操作性錯誤、錯誤的結果。小問題、用戶邊面布局問題、罕見故障、錯別字。建議。優先級:停止進一步測試,立即修復。在產品發布之前必須修復。如果時間允許,應該修復。可能會修復,但也可能發布。8.5.4測試執行和事故報告按照IEEE/ANSI標準829/1983,軟件故障報告包括:目的:記錄需要進一步調查的測試執行事件。大綱:

●軟件故障報告標識●概述●軟件故障描述●軟件故障影響軟件故障報告8.6測試評估(1)測試評估的內容

測試評估包括以下幾個方面:●測試覆蓋評估測試覆蓋評估是對軟件測試用例集合進行的全面性評價,并決定是否需要補充測試用例。

●軟件故障評估軟件故障評估則根據測試的執行對軟件質量進行評價,并決定是否需要開發補充測試用例。

●測試有效性評估測試有效性評估是對照測試停止標準,對當前測試工作的整體有效性進行評價,以及決定是停止測試還是增加測試用例并繼續測試的過程。

測試有效性評估8.6測試評估主要考慮的問題有:●決定停止測試還是繼續測試。●如果決定繼續測試,則需要補充哪些測試測試。●如果決定停止測試,如何撰寫測試概要報告。8.6測試評估(2)測試總結報告最終文檔是測試總結報告,對確認測試活動的結果作出概述。按照IEEE/ANSI標準829/1983,測試總結報告包括以下幾方面的內容:目的:總結與一個或多個測試設計規格說明相關的測試活動結果并提供基于這些結果的評估。大綱:●測試總結報告標識●測試概要●測試活動概述●測試綜合評價●測試結果概述●測試評估●測試審批8.7用戶手冊用戶手冊是事關產品成敗的主要因素之一,其重要性決不低于代碼本身。在開發過程中必須檢查文檔草稿以確保文檔的正確性、可理解性和完整性,必須將手冊當作產品的重要部分來對待,必須采用驗證測試(包括計劃和報告)的概念和方法對手冊進行綜合測試,其主要目標是找出功能設計規格說明和用戶手冊之間的差異。手冊中的范例都應該作為手冊測試的一部分接受測試,以判斷它們運行起來是否與描述的一樣。8.8IEEE/ANSI測試文檔概述(1)測試計劃和規格說明的文檔結構SQAP:軟件質量保證計劃,每個軟件測試產品一個。SVVP:軟件驗證和確認測試計劃,每SQAP一個。VTP:驗證測試計劃:每個驗證活動一個。MTP:主確認測試計劃,每個SVVP一個。DTP:詳細確認測試計劃,每個活動一個或多個。TDS:測試設計規格說明,每個DTP一個或多個。TPS:測試步驟規格說明,每個TDS一個或多個。TCS:測試用例規格說明,每個TDS/TPS一個或多個。TC:

測試用例。每個TCS有一個TC。8.8IEEE/ANSI測試文檔概述SQAPVTPVTPVTPSVVPMTPDTPDTPDTPDTPDTPDTPTDSTDSTDSTDSTCSTCSTCSTPSTPSTCTCTC每確認活動一個或多個圖8-3測試計劃和規格說明的文檔結構8.8IEEE/ANSI測試文檔概述(2)測試報告的文檔結構VTR:驗證測試報告。每個驗證活動一個。TPS:測試步驟規格說明。TL:測試記錄。每個測試執行一份。TIR:測試事故報告。每個事故一個。TSR:測試總結報告。8.9軟件生存周期各階段

的測試任務與可交付的文檔

軟件生存周期按瀑布模型可分為:需求、功能設計、詳細設計、編碼、測試和運行維護六個階段,不同階段可能在一定程度上有重復,但階段結束必須按一定順序進行,比如提交可交付文檔、審批、簽字等。8.9.1需求階段(1)測試輸入:

軟件質量保證計劃(任選)●需求(來自開發)(2)測試任務:

●制定驗證和確認測試計劃●對需求進行分析●對需求進行審核●分析并設計基于需求的測試,構造相應的需求覆蓋或跟蹤矩陣.(3)可交付的文檔:

軟件驗證測試計劃●驗證測試計劃(針對需求)●驗證測試報告(針對需求)8.9.2功能設計階段(1)測試輸入:功能設計規格說明(來自開發)(2)測試任務:

●功能設計驗證和確認測試計劃●分析功能設計規格說明●審核功能設計規格說明●設計可用性測試●分析并設計基于功能的測試,構造相應的功能覆蓋矩陣●實施基于需求和基于功能的測試(3)可交付的文檔:

●(主確認)測試計劃●驗證測試計劃(針對功能設計)●驗證測試報告(針對功能設計)8.9.3詳細設計階段(1)測試輸入:詳細設計規格說明(來自開發)(2)測試任務:

詳細設計驗證測試計劃●分析詳細設計規格說明●審核詳細設計規格說明●分析并設計基于內部的測試(3)可交付的文檔:

詳細確認測試計劃●驗證測試計劃(針對內部設計)●驗證測試報告(針對內部設計)●測試設計規格說明

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論