因果圖4.因果圖法設計測試用例步驟
判定表小結：黑盒測試的優點和缺點
現在的軟體幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟體設計方面的思想也可以引入到軟體測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。
基本流和備選流：如下圖所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的色彩表示，乙個備選流可能從基本流開始，在某個特定條件下執行，然後重新加入基本流中（如備選流1和3）；也可能起源於另乙個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。
確定基本流和備選流並設計場景
採用決策表來確定測試用例表
選取實際的資料設定測試用例
因果圖是一種利用**法分析輸入的各種組合情況，從而設計測試用例的方法，它適合於檢查程式輸入條件的各種組合情況。通常在輸入與輸出邏輯關係比較複雜的時候常用。
等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關係。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。
如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮採用一種適合於描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。
4種符號分別表示了規格說明中向4種因果關係。
因果圖中使用了簡單的邏輯符號，以直線聯接左右結點。左結點表示輸入狀態（或稱原因），右結點表示輸出狀態（或稱結果）。
ci表示原因，通常置於圖的左部；ei表示結果，通常在圖的右部。ci和ei均可取值0或1，0表示某狀態不出現，1表示某狀態出現。
關係：①恒等：若ci是1，則ei也是1；否則ei為0。
②非：若ci是1，則ei是0；否則ei是1。
③或：若c1或c2或c3是1，則ei是1；否則ei為0。「或」可有任意個輸入。
④與：若c1和c2都是1，則ei為1；否則ei為0。「與」也可有任意個輸入。
輸入狀態相互之間還可能存在某些依賴關係，稱為約束。例如, 某些輸入條件本身不可能同時出現。輸出狀態之間也往往存在約束。在因果圖中，用特定的符號標明這些約束。
輸入條件的約束有以下4類：
①e約束（異）：a和b中至多有乙個可能為1，即a和b不能同時為1。
②i約束（或）：a、b和c中至少有乙個必須是1，即 a、b 和c不能同時為0。
③o約束（唯一）：a和b必須有乙個，且僅有1個為1。
④r約束（要求）：a是1時，b必須是1，即不可能a是1時b是0。
輸出條件約束型別
輸出條件的約束只有m約束（強制）：若結果a是1，則結果b強制為0。
分析軟體規格說明描述中，那些是原因(即輸入條件或輸入條件的等價類)，那些是結果(即輸出條件)，並給每個原因和結果賦予乙個識別符號。
分析軟體規格說明描述中的語義，找出原因與結果之間， 原因與原因之間對應的關係，根據這些關係，畫出因果圖。
由於語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現，為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。
把因果圖轉換為判定表。
把判定表的每一列拿出來作為依據，設計測試用例。
判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。
能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。
在一些資料處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合於處理這類問題。
也就是之前指出的，輸入之間如果存在關聯的話，判定表很適合用來分析這類問題。
條件樁（condition stub）：列出了問題得所有條件。通常認為列出的條件的次序無關緊要。如上表中的問題三行。
動作樁（action stub）：列出了問題規定可能採取的操作。這些操作的排列順序沒有約束。如上表中的建議四行。
條件項（condition entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。如上表中問題三行中的標號為1-8的列。
動作項（action entry）：列出在條件項的各種取值情況下應該採取的動作。如上表中的建議四行中標號為1-8的列。
規則：任何乙個條件組合的特定取值及其相應要執行的操作稱為規則。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然，判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列。
化簡：就是規則合併有兩條或多條規則具有相同的動作，並且其條件項之間存在著極為相似的關係。
確定規則的個數。假如有n個條件，每個條件有兩個取值（0,1），則有2n種規則。
列出所有的條件樁和動作樁。
填入條件項。
填入動作項。得到初始判定表。
簡化、合併相似規則（相同動作）。
測試方法簡單，無需了解內部實現。
測試與軟體內部實現無關。
從使用者出發，很容易知道使用者會用哪些功能，遇到哪些問題，貼合需求。
基於軟體開發文件，很容易知道軟體實現了文件中的哪些功能。
自動化測試時方便。
不可能覆蓋所有的**，**覆蓋率較低，大概只佔總**量的30%。
自動化測試指令碼復用性較低。
軟體測試 黑盒測試
1.黑盒測試概述 黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用。在測試時，把程式看作乙個不能開啟的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能...
軟體測試 黑盒測試
白盒測試計畫書著重測試軟體的源 黑盒技術著重測試軟體功能。因此，設計測試用例時，需要研究需求說明和總體設計說明中的相關程式功能或輸入，輸出之間的關係等資訊，從而與測試後的結果進行分析比較。在實際測試中，常常把黑盒測試常常與白盒測試聯合使用，它是與白盒測試互補的測試方法。它很可能發現白盒測試不易發現的...
軟體測試學習筆記三 黑盒測試
1 黑盒測試的基本觀點 任何程式都可看做式從輸入定義與對映到輸出值域的函式過程，被測程式被認為是乙個打不開的黑盒子，黑盒子中有什麼不需要知道，只要知道這個盒子有什麼功能。發現以下幾類錯誤 1 功能是否正確和完備 2 輸入是否被接受，輸出是否正確 3 效能是否滿足要求 1 等價類劃分法 1 定義 將不...