第一篇：軟件測試項目化教學實例ZW1

軟件測試技術概論

第1章 概述

在學習本章時，可以從以下幾個問題進行考慮：

1.什么是軟件測試？

2.軟件測試是怎么發(fā)展起來的？ 3.為什么要進行軟件測試？ 4.軟件測試的目的是什么？ 5.常見的軟件測試誤區(qū)有哪些？

1.1回顧測試的發(fā)展

圖1-1缺陷修改成本趨勢圖

軟件測試技術概論

圖1-2缺陷放大模型圖

圖1-3測試V模型

軟件測試技術概論 1.2什么是軟件測試

1.2.1 IEEE的定義

1.2.2測試在軟件開發(fā)中的角色

1.3為什么要進行軟件測試 1.4測試的目的

圖1-4測試目的的演進

軟件測試技術概論

1.4.1證明 1.4.2檢測 1.4.3預防

1.5業(yè)界的軟件測試現(xiàn)狀

圖1-5測試標準/過程調(diào)查結果

圖1-6過程改進計劃調(diào)查結果

軟件測試技術概論

圖1-7測試硬件平臺調(diào)查結果

圖1-8測試活動調(diào)查結果

圖1-9測試產(chǎn)品調(diào)查結果

軟件測試技術概論

圖1-10靜態(tài)測試調(diào)查結果

圖1-11動態(tài)測試調(diào)查結果

圖1-12系統(tǒng)產(chǎn)品準備度調(diào)查結果

軟件測試技術概論

圖1-13缺陷信息收集調(diào)查結果

圖1-14測試狀態(tài)報告調(diào)查結果

1.6軟件測試中的誤區(qū) 1.7本章小結

軟件測試是伴隨著軟件和硬件的發(fā)展而逐步發(fā)展起來的，并且從最初的Adhoc測試發(fā)展到現(xiàn)在的全面測試理念。軟件測試是一種檢測手段，目的是為了尋找軟件系統(tǒng)中的缺陷。在業(yè)界已經(jīng)有越來越多的公司意識到了軟件測試的重要性，并且在測試方面加大了投入。軟件測試有很多誤區(qū)，只有認識到了這些誤區(qū)才能真正理解測試本身的含義，才能以正確的態(tài)度看待測試。

第二篇：軟件測試項目化教學實例ZW8

軟件測試技術概論

第8章 系統(tǒng)測試

8.1系統(tǒng)測試概念 8.2系統(tǒng)測試方法

8.2.1功能測試

1.基本概念 2.分析方法 3.用例設計

8.2.2協(xié)議一致性測試

1.基本概念 2.分析技術

圖8-1協(xié)議一致性測試過程

3.用例設計

軟件測試技術概論

8.2.3性能測試

1.基本概念 2.分析技術 3.用例設計

8.2.4壓力測試

1.基本概念 2.分析技術 3.用例設計

8.2.5容量測試

1.基本概念 2.分析方法 3.用例設計

8.2.6安全性測試

1.基本概念 2.分析方法 3.用例設計

8.2.7恢復性測試

1.基本概念 2.分析技術 3.用例設計

8.2.8備份測試

軟件測試技術概論 1.基本概念 2.分析技術 3.用例設計

8.2.9 GUI測試

1.基本概念 2.分析技術 3.用例設計

8.2.10健壯性測試

1.基本概念 2.分析技術

軟件測試技術概論

軟件測試技術概論

3.用例設計

軟件測試技術概論

8.2.11兼容性測試

1.基本概念 2.分析技術 3.用例設計

8.2.12可用性測試

1.基本概念 2.分析技術 3.用例設計

8.2.13可安裝性測試

1.基本概念 2.分析技術

圖8-2一般安裝程序流程圖

軟件測試技術概論

圖8-3對安裝程序使用自動測試的流程圖

軟件測試技術概論

圖8-4使用自動測試測試安裝空間流程圖

3.用例設計

8.2.14文檔測試

1.基本概念 2.分析技術 3.用例設計

8.2.15在線幫助測試1.基本概念 2.分析技術 3.用例設計

8.2.16數(shù)據(jù)轉(zhuǎn)換測試1.基本概念 2.分析技術 3.用例設計

8.3系統(tǒng)測試過程

軟件測試技術概論

圖8-5 PDCA循環(huán)

軟件測試技術概論

圖8-6系統(tǒng)測試過程

軟件測試技術概論 8.3.1完成系統(tǒng)測試計劃

1.決定系統(tǒng)測試類型 2.確定系統(tǒng)測試進度

軟件測試技術概論

軟件測試技術概論

3.組織系統(tǒng)測試小組 4.建立系統(tǒng)測試環(huán)境 5.安裝系統(tǒng)測試工具

軟件測試技術概論

8.3.2完成系統(tǒng)測試用例 8.3.3評審/審批系統(tǒng)測試計劃

1.安排/進行評審 2.獲得批準

8.3.4執(zhí)行系統(tǒng)測試

1.回歸測試

軟件測試技術概論

2.執(zhí)行新的系統(tǒng)測試 3.文檔化系統(tǒng)缺陷

8.4本章小結

系統(tǒng)測試是對已經(jīng)集成好的軟件系統(tǒng)進行徹底的測試，以驗證軟件系統(tǒng)的正確性和性能等滿足其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確并非一項簡單的任務，它 16

軟件測試技術概論

被稱為測試的“先知者問題”。因此，系統(tǒng)測試應該按照測試計劃進行，其輸入、輸出和其他動態(tài)運行行為應該與軟件規(guī)約進行對比。軟件系統(tǒng)測試方法很多，主要有功能測試、性能測試、壓力測試、容量測試等。為了進行全面的系統(tǒng)驗證，一般需要綜合多種測試方法結合進行測試。具體測試內(nèi)容的選擇需要根據(jù)業(yè)務的特點、進度、成本和質(zhì)量等多個維度進行考慮。在本章我們介紹了16種系統(tǒng)測試的方法，其實在實際系統(tǒng)測試過程中還有一些別的測試方法，有些方法我們將在第9章和第10章有所介紹，有些方法由于只適用于某些業(yè)務領域，因此在這里就不涉及了，還有一些測試基本可以融入到上面介紹的16種測試方法中，例如數(shù)據(jù)庫測試可以在功能測試、性能測試、壓力測試、容量測試等多個領域內(nèi)分別進行。同時在上面介紹的多種系統(tǒng)測試方法中，彼此之間也并不是完全沒有關聯(lián)的，例如功能測試和協(xié)議測試經(jīng)常會在一起進行，壓力測試、容量測試以及性能測試也經(jīng)?；旌显谝黄疬M行。具體如何做需要根據(jù)實際來判斷。

系統(tǒng)測試不是一個突發(fā)性的測試，必須經(jīng)過一個從計劃到實現(xiàn)的過程。本章介紹的基于PDCA模型的測試過程體系必須被理解，同時結合前面單元測試過程、集成測試過程，讀者應當對測試過程方面有一個比較全面的認識。有關全面介紹測試過程方面的內(nèi)容可以參考筆者即將出版的《軟件測試過程》一書。

第三篇：軟件測試項目化教學實例ZW16

軟件測試技術概論

第16章 同行評審

16.1基本概念

軟件測試技術概論

16.2同行評審的一般過程

圖16-1 同行評審過程

軟件測試技術概論 16.2.1計劃階段

1.分配角色和職責 2.進行計劃活動 3.選擇同行評審類型

軟件測試技術概論

16.2.2實施被選擇的同行評審過程 16.2.3同行評審過程度量 16.2.4同行評審的評審/審計

16.3走讀

16.3.1過程目標 16.3.2特定的角色和職責 16.3.3輸入 16.3.4入口標準 16.3.5過程 16.3.6出口標準 16.3.7輸出

16.4技術評審

16.4.1過程目標 16.4.2特定的角色和職責 16.4.3輸入

軟件測試技術概論 16.4.4入口標準 16.4.5過程 16.4.6出口標準 16.4.7輸出

16.5正規(guī)檢視

16.5.1正規(guī)檢視小組

1.成員角色和職責 2.角色兼職原則

16.5.2正規(guī)檢視過程

圖16-2正規(guī)檢視流程定義

1.計劃階段 2.介紹會議 3.會議準備 4.檢視會議 5.第 3小時會議 6.修改錯誤 7.問題跟蹤 8.重新正規(guī)檢視

軟件測試技術概論

16.5.3正規(guī)檢視常用表格

軟件測試技術概論

軟件測試技術概論

軟件測試技術概論

軟件測試技術概論

軟件測試技術概論

軟件測試技術概論

16.6本章小結

本章介紹了同行評審的概念以及同行評審的3種形式——走讀、技術評審和正規(guī)檢視。盡管同行評審可以適用于任何工作產(chǎn)品，可以在開發(fā)階段的任何一個時間點進行，但是還有一個成本的問題。不同的同行評審類型，根據(jù)其過程的嚴格程度，其成本是不同的。走讀形式最自由，因此需要的成本也最低；其次是技術評審。正規(guī)檢視是成本最高的，因此它應當被用到最值得付出的產(chǎn)品項上。一般正規(guī)檢視在需求，設計文檔上面應用的比較多一些，而走讀可以應用到各種產(chǎn)品項上（包括文檔和代碼）。技術評審一般是在階段點上進行，以確認某個階段的工作已經(jīng)完成，并且達到一定的技術要求，可以進入到下一個階段。

根據(jù)經(jīng)驗，在開發(fā)過程中可以按照下面的方法安排各類同行評審：

方法一在某個產(chǎn)品項（包括文檔和代碼）的開發(fā)過程中，可以進行多次走讀，像在印度一些CMM5級的公司經(jīng)常進行每日走讀的方式，例如：在編碼時，員工在一天8小時的工作中，把7個小時左右的時間放在編碼上，再利用其余的1個小時進行交叉走讀。這種方式是一個非常好的實踐，能夠有效地減少低級錯誤，并提高產(chǎn)品質(zhì)量。

方法二在某個產(chǎn)品項已經(jīng)完成（包括文檔和代碼），完成的概念是指已經(jīng)經(jīng)過多次走讀，并且可以準備提交進入基線了。這時，對于一些關鍵性文檔或代碼進行一次或多次的正規(guī)檢視，次數(shù)的多少需要看檢視對象的規(guī)模大小。這個過程如果組織得好，是非常高效的。

方法三在一個開發(fā)階段結束，并且目標里程碑中所包含的所有產(chǎn)品項（包括文檔和代碼）都已經(jīng)完成，且都已經(jīng)被基線化了。這時可以進行一個技術評審，該評審確認任務的完成情況和完成質(zhì)量，并結束當前階段，開始啟動下一個階段。

正規(guī)檢視的次數(shù)安排不能太多，一般一個人一周最多只能參加1次正規(guī)檢視，否則會導致人員疲憊，影響檢視效率。同時檢視的效率還與員工花在檢視準備和執(zhí)行上面的時間和工作量有關。例如，IBM發(fā)現(xiàn)當檢視速率超過一定值時檢視效率會成倍下降。適當?shù)臋z視速率取決于被檢視的產(chǎn)品的類型和參加檢視人員的經(jīng)驗。對設計和代碼檢視來說，表 16-8顯示了一些可用的檢視速率的數(shù)據(jù)，從中我們可以看到，COBOL應用程序的檢視速率是一般系統(tǒng)程序檢視速率的6～8倍，是性能敏感系統(tǒng)程序的15倍。組織確定自己檢視速率的最好的方式是收集自己的數(shù)據(jù)并得出適合自己的標準值。

軟件測試技術概論

隨著組織經(jīng)驗的積累，同行評審（尤其是正規(guī)檢視）效率也越來越高。通過提高檢視效率，組織能夠在軟件交付前發(fā)現(xiàn)大部分的錯誤（表 16-9給出了一個IBM統(tǒng)計的實例）。另一方面，檢視所花費的時間也有很明顯的變化：如1000行源代碼所花費的時間增加了1.68倍（概要設計檢視）和7.00倍（詳細設計檢視）。盡管在前期設計檢視上面花費了額外的時間，但在代碼檢視階段每千行源代碼的檢視時間卻減少到原來的76%，而每小時檢視發(fā)現(xiàn)的問題數(shù)更是增加到原來的3倍。這些改進一方面是由于產(chǎn)品程序員們對產(chǎn)品的了解更加深入所致，另一方面則是因為檢視是一種可以學習的技能，可以通過經(jīng)驗的積累而得到明顯的改善。

軟件測試技術概論

其中：KCSI：千行變更的源指令 I0：概要設計檢視 I1：詳細設計檢視 I2：代碼檢視

檢視效率=檢視發(fā)現(xiàn)缺陷數(shù)檢視和測試發(fā)現(xiàn)的總?cè)毕輸?shù) 質(zhì)量索引=試用期間發(fā)現(xiàn)的缺陷數(shù)開發(fā)期間發(fā)現(xiàn)的總?cè)毕輸?shù)

第四篇：軟件測試項目化教學實例ZW10

軟件測試技術概論

第10章 其他專項性測試

10.1可接受性測試 10.2 Alpha測試 10.3 Beta測試 10.4標桿測試 10.5配置測試

軟件測試技術概論

軟件測試技術概論 10.6外場測試 10.7 SQL測試 10.8 2000年測試

軟件測試技術概論

10.9回歸測試 10.10本章小結

本章介紹了一些特定的測試方法。這些方法可以作為前幾章的補充或延伸。這里，并沒有詳細說明這些測試如何使用，僅做了一些簡單的介紹。讀者若感興趣，可以參考相關文獻。

第五篇：軟件測試項目化教學實例ZW14

軟件測試技術概論

第14章 需求測試

14.1需求測試概述

14.1.1什么是需求

1.需求的層次

圖14-1軟件需求各層次關系

2.FURPS+模型 3.可能的需求風險 4.好的需求應具有的特點

軟件測試技術概論

14.1.2測試需求

14.2通過評審來測試需求

14.2.1需求評審中的常見風險 14.2.2需求評審檢查表

軟件測試技術概論 4

軟件測試技術概論

軟件測試技術概論 6

軟件測試技術概論

軟件測試技術概論 14.3通過用例設計來測試需求

圖14-2化學制品請求對話圖

軟件測試技術概論

圖14-3測試路徑圖

軟件測試技術概論

14.4需求建模測試

14.4.1統(tǒng)一建模語言

1.Use Case圖

軟件測試技術概論 圖14-4 Use Case圖例

2.Use Case 測試

14.4.2消息順序圖（MSC）

圖14-5 MSC圖示例

軟件測試技術概論

圖14-6 HMSC示例

軟件測試技術概論

14.4.3分析建模工具介紹

軟件測試技術概論

14.4.4需求的形式化描述

圖14-7需求的形式化表示樣例

軟件測試技術概論

14.5基于原型的測試

14.5.1原型的目的 14.5.2原型的種類 14.5.3原型的測試方法

14.6本章小結

需求是一個軟件開發(fā)項目的靈魂所在，有著至關重要的位置。保證需求的質(zhì)量是一個項目成敗的關鍵。本章，我們從需求評審、用例測試、建模測試和原型測試等多個角度探索對需求的驗證，其最終的目的是希望盡可能地使需求穩(wěn)定，減少項目開發(fā)過程中的需求變化，從而加快項目的開發(fā)進度，降低項目的開發(fā)成本，提高最終軟件產(chǎn)品的質(zhì)量。收集需求并編寫需求文檔是軟件項目設計成功的很好起點。但還需要保證需求的正確性，使需求能體現(xiàn)出良好需求說明的全部特性。如果能把早期的黑盒子測試設計、非正式需求評審、軟件需求規(guī)格說明書檢視和其他需求驗證技術相結合，你將花比以前更少的時間、更低的費用來構造質(zhì)量更高的系統(tǒng)。