【文章內容簡介】 定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類 。 ? 例如，在 Pascal語言中對變量標識符規(guī)定為“以字母打頭的 ……串”。那么所有以字母打頭的構成有效等價類，而不在此集合內（不以字母打頭）的歸于無效等價類。 (3) 如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。 (4) 如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為 每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。 ? 例如，在教師上崗方案中規(guī)定對教授、副教授、講師和助教分別計算分數(shù)，做相應的處理。因此可以確定 4個有效等價類為教授、副教授、講師和助教，一個無效等價類，它是所有不符合以上身分的人員的輸入值的集合。 (5) 如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從 不同角度 違反規(guī)則）。 ? 例如， Pascal語言規(guī)定 “一個語句必須以分號‘ ?！Y束”。這時，可以確定一個有效等價類 “以‘ 。’結束”，若干個無效等價類 “以‘ :’結束”、“以‘ ,’結束”、“以‘ ’結束”、“以 LF結束”等。 ? 確立測試用例 在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。 ? 再從劃分出的等價類中按以下原則選擇測試用例： (1) 為每一個等價類規(guī)定一個唯一編號； (2) 設計一個新的測試用例，使其 盡可能多地覆蓋尚未被覆蓋的有效等價類 ，重復這一步，直到所有的有效等價類都被覆蓋為止； （ 3）設計一個新的測試用例，使其 僅覆蓋一個尚未被覆蓋的無效等價類 ，重復這一步，直到所有的無效等價類都被覆蓋為止 。 ? 用等價類劃分法設計測試用例的實例 在某一 PASCAL語言版本中規(guī)定：“ 標識符是由字母開頭 ， 后跟字母或數(shù)字的任意組合構成 。 有效字符數(shù)為 8個 ， 最大字符數(shù)為 80個 ?！? 并且規(guī)定：“ 標識符必須先說明 ，再使用 ?！? “ 在同一說明語句中 ，標識符至少必須有一個 ?！? 用等價類劃分的方法，建立輸入等價類表 : ? 下面選取了 9個測試用例，它們覆蓋了所有的等價類。 ① VAR x， T1234567： REAL； BEGIN x := ； T1234567 := ； ...… (1), (2), (4), (8), (9), (12), (14) ② VAR ： REAL； (3) ③ VAR x，： REAL。 (5) ④ VAR T12345678： REAL； (6) ⑤ VAR T12345......： REAL； (7) 多于 80個字符 ⑥ VAR T$： CHAR； (10) ⑦ VAR GOTO： INTEGER； (11) ⑧ VAR 2T： REAL； (13) ⑨ VAR PAR： REAL； (15) BEGIN ...... PAP := SIN ( * ) / 6； 邊界值分析 ? 邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。 ? 人們從長期的測試工作經驗得知， 大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部 。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤 。 ? 比如，在做三角形計算時，要輸入三角形的三個邊長： A、 B和 C。 我們應注意到這三個數(shù)值應當滿足 A＞ 0、 B＞ 0、 C＞ 0、 A＋ B＞ C、 A＋ C＞ B、 B＋ C＞ A，才能構成三角形。但如果把六個不等式中的任何一個大于號“＞”錯寫成大于等于號“ ≥”，那就不能構成三角形。問題恰出現(xiàn)在容易被疏忽的邊界附近。 ? 這里所說的邊界是指，相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況。 ? 使用邊界值分析方法設計測試用例，首先應確定邊界情況。 應當選取正好等于，剛剛大于，或剛剛小于邊界的值做為測試數(shù)據(jù) ，而不是選取等價類中的典型值或任意值做為測試數(shù)據(jù)。 錯誤推測法 ?人們也可以靠 經驗和直覺 推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。 ?錯誤推測法的基本想法是： 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試用例 。 因果圖 ? 因果圖的適用范圍 如果在測試時必須考慮 輸入條件的各種組合 ，可使用一種適合于描述對于多種條件的組合，相應產生多個動作的形式來設計測試用例，這就需要利用因果圖。 因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。 ? 用因果圖生成測試用例的基本步驟 (1) 分析軟件規(guī)格說明描述中，哪些是原因 (即輸入條件或輸入條件的等價類 )，哪些是結果 (即輸出條件 )，并給每個原因和結果賦予一個標識符。 (2) 分析軟件規(guī)格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系 ? 根據(jù)這些關系，畫出因果圖。 (3) 由于語法或環(huán)境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。 (4) 把因果圖轉換成判定表。 (5) 把判定表的每一列拿出來作為依據(jù)，設計測試用例。 ? 在因果圖中出現(xiàn)的基本符號 通常在因果圖中用 Ci表示原因，用 Ei表示結果，各結點表示狀態(tài)，可取值“ 0”或“ 1”?！?0”表示某狀態(tài)不出現(xiàn)，“ 1”表示某狀態(tài)出現(xiàn)。 ? 主要的原因和結果之間的關系有 : ? 表示約束條件的符號 為了表示原因與原因之間，結果與結果之間可能存在的約束條件，在因果圖中可以附加一些表示約束條件的符號。 ? 例如，有一個處理單價為 5角錢的飲料的自動售貨機軟件測試用例的設計。其規(guī)格說明如下： 若 投入 5角錢或 1元錢的硬幣 ， 押下 〖 橙汁 〗 或 〖 啤酒 〗 的按鈕，則相應的飲料就送出來。若售貨機 沒有零錢找 ，則一個顯示〖零錢找完〗的紅燈亮，這時在投入 1元硬幣并押下按鈕后，飲料不送出來而且 1元硬幣也退出來；若 有零錢找 ，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時退還 5角硬幣。” (1) 分析這一段說明，列出原因和結果 原因 : 1. 售貨機有零錢找 2. 投入 1元硬幣 3. 投入 5角硬幣 4. 押下橙汁按鈕 5. 押下啤酒按鈕 建立中間結點，表示處理中間狀態(tài) 11. 投入 1元硬幣且押下飲料按鈕 12. 押下〖橙汁〗或〖啤酒〗的按鈕 13. 應當找 5角零錢并且售貨機有零錢找 14. 錢已付清 結果： 21. 售貨機〖零錢找完〗燈亮 22. 退還 1元硬幣 23. 退還 5角硬幣 24. 送出橙汁飲料 25. 送出啤酒飲料 (2) 畫出因果圖。所有原因結點列在左 邊，所有結果結點列在右邊。 (3) 由于 2 與 3 ， 4 與 5 不能同時發(fā)生， 分別加上約束條件 E。 (4) 因果圖 ? (5) 轉換成判定表 軟件測試的策略 ? 測試過程按 4個步驟進行，即 單元測試 、 組裝測試 、 確認測試和 系統(tǒng)測試 。 ? 開始是 單元測試 ，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。 ? 組裝測試 把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結構的構造進行測試。 ? 確認測試 則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。 ? 系統(tǒng)測試 把已經經過確認的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成分組合在一起進行測試。 單元測試 (Unit Testing) ? 單元測試又稱模塊測試， 是針對軟件設計的最小單位 ─ 程序模塊 ， 進行正確性檢驗 的測試工作。其目的在于發(fā)現(xiàn)各模塊內部可能存在的各種差錯。 ? 單元測試需要 從程序的內部結構出發(fā)設計測試用例 。多個模塊可以平行地獨立進行單元測試。 1. 單元測試的內容 ?在單元測試時，測試者需要依據(jù)詳細設計說明書和源程序清單，了解該模塊的 I/O條件和模塊的邏輯結構，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。 (1) 模塊接口測試 ? 在單元測試的開始，應對 通過被測模塊的數(shù)據(jù)流 進行測試。測試項目包括： – 調用本模塊的輸入?yún)?shù)是否正確； – 本模塊調用子模塊時輸入給子模塊的參數(shù)是否正確； – 全局量的定義在各模塊中是否一致； ? 在做 內外存交換 時要考慮： – 文件屬性是否正確； – OPEN與 CLOSE語句是否正確； – 緩沖區(qū)容量與記錄長度是否匹配； – 在進行讀寫操作之前是否打開了文件； – 在結束文件處理時是否關閉了文件； – 正文書寫／輸入錯誤， – I／ O錯誤是否檢查并做了處理。 (2) 局部數(shù)據(jù)結構測試 ? 不正確或不一致的數(shù)據(jù)類型說明 ? 使用尚未賦值或尚未初始化的變量 ? 錯誤的初始值或錯誤的缺省值 ? 變量名拼寫錯或書寫錯 ? 不一致的數(shù)據(jù)類型 ? 全局數(shù)據(jù)對模塊的影響 (3) 路徑測試 ? 選擇適當?shù)臏y試用例，對模塊中 重要的執(zhí)行路徑 進行測試。 ? 應當設計測試用例查找由于 錯誤的計算 、 不正確的比較 或 不正常的控制流 而導致的錯誤。 ? 對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。 (4) 錯誤處理測試 ? 出錯的描述是否難以理解 ? 出錯的描述是否能夠對錯誤定位 ? 顯示的錯誤與實際的錯誤是否相符