介紹

在進行測試時，通常會花很多精力選擇“正確”的測試工具。這其實只是為了實現次要目標。當然，一個適合開發環境、項目和流程的工具是重要的。然而，對于良好測試而言，最重要的是測試用例的質量。只有“好”的測試用例才會發現軟件存在缺陷。

一個簡單的例子

如下是對一個簡單測試對象的說明：

“start”和“length”定義了“value”的取值范圍。被測函數用來確定給定值是否在定義的范圍內。規定范圍的上界不在范圍內。所有數據類型都是整數。

如下圖所示的三個測試用例都通過了測試，并且達到了100%的MC/DC覆蓋度。

圖1 這三個測試用例通過并達到了100%的覆蓋率

圖1測試用例都通過并已經達到了100%的覆蓋度，但沒有對所有的需求進行測試，即沒有使用邊界值進行測試。

邊界值，最小/最大值，極端值，違規值

? 邊界值

需要多少測試用例（以及哪些測試數據）才能充分對邊界值進行測試？下面使用一個“輸入值是否小于5”的函數來研究這個問題。

圖2 可能的實現以及哪些測試輸入能檢測缺陷

圖2表格第一列我“輸入值是否小于5”的可能缺陷（即錯誤實現）。其中（i！= 5）和（i <> 5）均為“不相等”，歸屬不同編程語言（“！=”屬于C / C ++，Java;“<>” 屬于Pascal，PHP，SQL，Excel）。

表2中第二列為缺陷的可能性組合。缺陷的可能性被認為與關系式中錯誤字符的數量和“外觀”上的差異有關（從正確的（i <5）需要更多的改變才能將正確的（i <5）變換為不正確的（i> = 5），也更容易在視覺上發現）。

表2中后三列為輸入值為4、5、6時的測試結果，粗體和紅色陰影表示測試失敗。輸入值4和5未檢測到（i！= 5）和（i <> 5），輸入值6（即第三測試用例）檢測到了。（i <> 5）的實現方式更有可能發生，但使用“<>”運算符的編程語言對于嵌入式系統并不常見。

（i == 4）無輸入值檢測到，需要額外輸入值檢測缺陷，需要四個測試用例（“內部”兩個值和“外部”兩個值）。這是René Tuinhout提出的黑盒邊界值分析（B3VA）。“小于5”的值范圍有更低邊界且可作輸入值，則不需要額外測試，下邊界可以檢測（i == 4）。

結論：嵌入式系統（使用“！=”作為關系運算符），進行代碼審查且目標是測試用例的數量較少，僅使用兩個測試用例就可以。但為了檢測一些缺陷，有時需要四個測試用例。

? 最小/最大值

將給定數據類型的最大和最小（即最負）可能的輸入值作為邊界值的特殊情況。

圖3 函數abs_short（）存在一個在使用最大/最小值輸入時才會發現的問題

圖3函數abs_short（）在輸入值為-5,0,5時，分別正確返回5,0,5，實現了100％的代碼覆蓋率。但輸入值是-32768時（帶符號的16位整數的最小（最負）值），預期結果為+32768。無法在給定的整數范圍內表示，返回值為-32768，不是預期值。（背景：-32768 = 0x8000.0x8000-1 = 0x7FFF。反轉值為0x8000，與開始時的值相同。）

? 極端值

極端（或特殊）輸入值不是直接取邊界或最小/最大值，是另一種特殊值。

圖4minimum（）函數存在編程缺陷

圖4是最小值函數。三個（無符號）整數（a，b和c）為輸入，返回輸入的最小值。

圖5：用于檢測最小值函數缺陷的測試用例

圖5，為該函數運行通過的測試用例。檢查每個位置是否能正確檢測到最小值（3），100％代碼覆蓋率，但沒有極端或特殊的輸入。對此函數，特殊的輸入可以是三個相同正值，如輸入（3,3,3），結果為0（不是預期結果3），表示最小值功能的實現存在缺陷。

? 違規值

圖3函數“所有數據類型都是整數”。適用length的取值范圍，故長度可能是負的。輸入5，-2為長度，查看4是否被認為在范圍之內。用（可能的）無效輸入構建測試用例。

ISO26262中的建議

ISO 26262：2011在第6部分第9節中列出軟件單元測試的測試用例的設計方法。

圖6：ISO26262中設計測試用例的方法

圖6為建議取決于汽車安全完整性等級（ASIL）。ASIL的范圍從A到D，D最高級別。“強烈推薦”雙加號（“++”）; “推薦”單個加號（“+”）。1a，1b，1c，...是替代條目; 1,2,3，...是連續的條目。替代條目，應根據ASIL應用適當的方法組合；連續條目，應按照ASIL進行應用。1a要求軟件單元測試的測試用例來自需求；1b要求使用等價類的生成和分析來導出測試用例；1c要求分析邊界值以導出測試用例。方法1a，1b和1c已在本文前面的部分中討論過。1d要求錯誤猜測來導出測試用例。

? 錯誤猜測

錯誤猜測需要經驗豐富的測試人員，從過往的經驗中找到敏感的測試用例。它是一種非系統的方法。例如，被測系統有兩個按鈕，假設一次只按下其中一個按鈕：如果同時按下兩個按鈕會發生什么？這是錯誤猜測的示例。

可選方案

本節討論設計測試用例的其他可選方法。

? 來自源代碼的測試用例

使用工具從源代碼自動生成測試用例。一些開源和商業工具都實現了一些技術方法（例如遺傳算法或回溯），可以利用生成測試用例。源代碼生成測試用例要注意：

? 遺漏：將無法發現代碼中的遺漏。如要求“第一個參數等于第二個參數，則返回錯誤”若缺少這項檢查的實現：由源代碼生成的測試用例不會檢測到此問題。

? 準確度：無法從代碼中判斷它是否正確。如無法判斷（i <5）或（i <= 5）是否實現了代碼的預期行為。

可以讓工具生成測試用例并將其和需求進行比對，如果不符合要求再對其進行相應的拓展或改變。近期有研究人員對此進行了研究，其主要觀點如下：

? 自動生成的測試套件比人工創建的測試套件實現了更高的代碼覆蓋率。

? 使用自動生成的測試套件無法檢測到更多缺陷。

? 自動生成的測試用例會對捕獲預期的類行為產生負面影響。

這項研究表明，自動化測試用例生成沒有為測試帶來優勢，但它也沒有缺點。雖有很多討論的研究條件（編程語言，編程技巧等），但結果依然是令人驚訝的。

變異測試（Mutation Testing）

評定測試用例質量的一種可行方法是變異測試（在IEC 61508標準中也被稱為“錯誤播種”（error seeding））。有運行通過的測試用例時，可以“變異”代碼。如，將判斷（i<5）改成（i<=5），在計算結果上加1，把“&&”改為“||”，注釋掉部分代碼等。代碼進行變異之后，重新運行測試用例。若所有測試用例能夠通過，測試用例質量就比較低。至少一項測試用例應該會由于進行了變異而無法驗證通過。

小結

100%的代碼覆蓋率并不意味著“好”的測試用例。然而，在執行測試的過程中為了能夠檢測出軟件的缺陷，需要高質量的用例。這項任務需要仔細而富有經驗的人力工作才能達成，對于自動化生成的測試用例，應該持保留態度。