數據驅動測試(2)

　　因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

　　利用因果圖生成測試用例的基本步驟:

　　(1) 分析軟件規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 并給每個原因和結果賦予一個標識符.

　　(2) 分析軟件規格說明描述中的語義.找出原因與結果之間, 原因與原因之間對應的關系. 根據這些關系,畫出因果圖.

　　(3) 由于語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不不可能出現. 為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件.

　　(4) 把因果圖轉換為判定表.

　　(5) 把判定表的每一列拿出來作為依據,設計測試用例.

　　從因果圖生成的測試用例(局部,組合關系下的)包括了所有輸入數據的取TRUE與取FALSE的情況,構成的測試用例數目達到最少,且測試用例數目隨輸入數據數目的增加而線性地增加.

　　前面因果圖方法中已經用到了判定表.判定表(Decision Table)是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發展的初期,判定表就已被當作編寫程序的輔助工具了.由于它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確.

　　判定表通常由四個部分組成.

　　條件樁(Condition Stub):列出了問題得所有條件.通常認為列出得條件的次序無關緊要.

　　動作樁(Action Stub):列出了問題規定可能采取的操作.這些操作的排列順序沒有約束.

　　條件項(Condition Entry):列出針對它左列條件的取值.在所有可能情況下的真假值.

　　動作項(Action Entry):列出在條件項的各種取值情況下應該采取的動作.

　　規則:任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列.

　　判定表的建立步驟:(根據軟件規格說明)

　?、俅_定規則的個數.假如有n個條件.每個條件有兩個取值(0,1),故有 種規則.

　?、诹谐鏊械臈l件樁和動作樁.

　?、厶钊霔l件項.

　?、芴钊雱幼黜?等到初始判定表.

　?、莺喕?合并相似規則(相同動作).

　　B. Beizer 指出了適合使用判定表設計測試用例的條件:

　?、僖幐裾f明以判定表形式給出,或很容易轉換成判定表.

　?、跅l件的排列順序不會也不影響執行哪些操作.

　?、垡巹t的排列順序不會也不影響執行哪些操作.

　?、苊慨斈骋灰巹t的條件已經滿足,并確定要執行的操作后,不必檢驗別的規則.

　?、萑绻骋灰巹t得到滿足要執行多個操作,這些操作的執行順序無關緊要.

　　黑盒測試的優點

　　1. 基本上不用人管著，如果程序停止運行了一般就是被測試程序crash了

　　2. 設計完測試例之后，下來的工作就是爽了，當然更苦悶的是確定crash原因

　　黑盒測試的缺點

　　1. 結果取決于測試例的設計，測試例的設計部分來勢來源于經驗，OUSPG的東西很值得借鑒

　　2. 沒有狀態轉換的概念，目前一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀態轉換來作

　　3. 就沒有狀態概念的測試來說，尋找和確定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。

　　黑盒測試(功能測試)工具的選擇

　　那么，如何高效地完成功能測試?選擇一款合適的功能測試工具并培訓一支高素質的工具使用隊伍無疑是至關重要的。盡管現階段存在少數不采用任何功能測試工具，從事功能測試外包項目的軟件服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟件服務企業取代。

　　目前，用于功能測試的工具軟件有很多，針對不同架構軟件的工具也不斷推陳出新。這里重點介紹的是其中一個較為典型自動化測試工具，即Mercury公司的WinRunner。

　　WinRunner是一種用于檢驗應用程序能否如期運行的企業級軟件功能測試工具。通過自動捕獲、檢測和模擬用戶交互操作，WinRunner能識別出絕大多數軟件功能缺陷，從而確保那些跨越了多個功能點和數據庫的應用程序在發布時盡量不出現功能性故障。

　　WinRunner的特點在于: 與傳統的手工測試相比，它能快速、批量地完成功能點測試; 能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差; 此外，它還能重復執行相同動作，測試工作中最枯燥的部分可交由機器完成; 它支持程序風格的測試腳本，一個高素質的測試工程師能借助它完成流程極為復雜的測試，通過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用; 它針對于大多數編程語言和Windows技術，提供了較好的集成、支持環境，這對基于Windows平臺的應用程序實施功能測試而言帶來了極大的便利。

　　WinRunner的工作流程大致可以分為以下六個步驟:

　　1.識別應用程序的GUI

　　在WinRunner中，我們可以使用GUI Spy來識別各種GUI對象，識別后，WinRunner會將其存儲到GUI Map File中。它提供兩種GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大區別是后者對每個測試腳本產生一個GUI文件，它能自動建立、存儲、加載，推薦初學者選用這種模式。但是，這種模式不易于描述對象的改變，其效率比較低，因此對于一個有經驗的測試人員來說前者不失為一種更好的選擇，它只產生一個共享的GUI文件，這使得測試腳本更容易維護，且效率更高。

　　2.建立測試腳本

　　在建立測試腳本時，一般先進行錄制，然后在錄制形成的腳本中手工加入需要的TSL(與C語言類似的測試腳本語言)。錄制腳本有兩種模式: Context Sensitive和Analog，選擇依據主要在于是否對鼠標軌跡進行模擬，在需要回放時一般選用Analog。在錄制過程中這兩種模式可以通過F2鍵相互切換。

原文轉自：http://www.anti-gravitydesign.com