第一篇：軟件測試項目化教學實例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ù)轉換測試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)測試是對已經集成好的軟件系統(tǒng)進行徹底的測試，以驗證軟件系統(tǒng)的正確性和性能等滿足其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確并非一項簡單的任務，它 16

軟件測試技術概論

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

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

第二篇：軟件測試項目化教學實例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ī)檢視。盡管同行評審可以適用于任何工作產品，可以在開發(fā)階段的任何一個時間點進行，但是還有一個成本的問題。不同的同行評審類型，根據(jù)其過程的嚴格程度，其成本是不同的。走讀形式最自由，因此需要的成本也最低；其次是技術評審。正規(guī)檢視是成本最高的，因此它應當被用到最值得付出的產品項上。一般正規(guī)檢視在需求，設計文檔上面應用的比較多一些，而走讀可以應用到各種產品項上（包括文檔和代碼）。技術評審一般是在階段點上進行，以確認某個階段的工作已經完成，并且達到一定的技術要求，可以進入到下一個階段。

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

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

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

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

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

軟件測試技術概論

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

軟件測試技術概論

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

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

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

軟件測試技術概論

第15章 設計測試

15.1設計測試概述

15.1.1什么是設計 15.1.2軟件構架設計

1.軟件構架視圖

圖15-1功能視圖例子

圖15-2代碼視圖例子

軟件測試技術概論

圖15-3開發(fā)視圖例子

圖15-4并發(fā)視圖例子

軟件測試技術概論

圖15-5物理視圖例子

2.場景

軟件測試技術概論

15.1.3概要設計和詳細設計

15.2設計的評審

15.2.1設計查檢表

軟件測試技術概論 6

軟件測試技術概論

軟件測試技術概論 8

軟件測試技術概論

軟件測試技術概論

軟件測試技術概論

15.2.2構架設計評審方法

1.軟件構架分析方法

圖15-6 SAAM分析的活動及依賴關系

2.表面的軟件構架分析方法

圖15-7 ASSAM分析的活動和依賴關系

軟件測試技術概論 3.構架均衡分析方法

15.2.3軟件構架評價最佳工業(yè)實踐

1.成本和受益 2.評價技術的分類

3.建議的最佳實踐 4.建議總結

軟件測試技術概論

15.3 SDL及相關測試

15.3.1 SDL介紹 15.3.2 SDL基本概念

1.系統(tǒng) 2.環(huán)境 3.功能塊 4.信道 5.信號 6.信號路由 7.進程 8.過程 9.定時器 10.服務

15.3.3 SDL結構

軟件測試技術概論

圖15-8 SDL框架示意圖

圖15-9 SDL系統(tǒng)圖

圖15-10 SDL功能塊圖

軟件測試技術概論

圖15-11 SDL進程圖（含服務）

圖15-12 SDL服務圖

軟件測試技術概論

圖15-13 SDL過程圖

15.3.4 SDL測試

1.SDL Simulator

圖15-14 Simulator界面

2.SDL Validator

軟件測試技術概論

圖15-15 SDL Validator界面

圖15-16 SDL Validator統(tǒng)計信息

軟件測試技術概論

圖15-17 Navigator 3.TTCN

圖15-18 TTCN-SDL測試關系

15.4本章小結

設計是一個承上啟下的過程，它把抽象的用戶需求轉換成具體的可實現(xiàn)的系統(tǒng)結構，這是一個需要創(chuàng)意的過程，有人把它理解成一種藝術。正因為如此，這個過程也是最易于產生風險的過程。如何把握好設計的質量成為軟件工程領域內的一項課題，本章在這方面做了一些探索，總結了業(yè)界在該領域的一些經驗，提出從靜態(tài)的評審到動態(tài)的測試等多種手段。

目前業(yè)界在構架設計評審方面使用最多的是基于場景的評審方法，最基本的方法是 18

軟件測試技術概論

SAAM。在該方法的基礎上可擴展出很多新的方法，例如本章中介紹的ASAAM以及ATAM。

SDL是一種基于結構化設計的設計描述語言，主要應用在嵌入式領域。目前關于SDL驗證方面有許多可以應用的工具，包括Telelogic的Simulator、Validator以及ITEX。TTCN作為一種ITU-T推薦的協(xié)議一致性測試方法，可以和SDL進行無縫連接。因此，對于SDL設計的系統(tǒng)，使用TTCN作為測試描述語言是非常好的。