介紹

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

一個簡單的例子

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

“start”和“l(fā)ength”定義了“value”的取值范圍。被測函數(shù)用來確定給定值是否在定義的范圍內(nèi)。規(guī)定范圍的上界不在范圍內(nèi)。所有數(shù)據(jù)類型都是整數(shù)。

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

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

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

邊界值，最小/最大值，極端值，違規(guī)值

? 邊界值

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

圖2 可能的實現(xiàn)以及哪些測試輸入能檢測缺陷

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

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

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

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

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

? 最小/最大值

將給定數(shù)據(jù)類型的最大和最?。醋钬摚┛赡艿妮斎胫底鳛檫吔缰档奶厥馇闆r。

圖3 函數(shù)abs_short（）存在一個在使用最大/最小值輸入時才會發(fā)現(xiàn)的問題

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

? 極端值

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

圖4minimum（）函數(shù)存在編程缺陷

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

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

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

? 違規(guī)值

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

ISO26262中的建議

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

圖6：ISO26262中設(shè)計測試用例的方法

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

? 錯誤猜測

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

可選方案

本節(jié)討論設(shè)計測試用例的其他可選方法。

? 來自源代碼的測試用例

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

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

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

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

? 自動生成的測試套件比人工創(chuàng)建的測試套件實現(xiàn)了更高的代碼覆蓋率。

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

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

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

變異測試（Mutation Testing）

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

小結(jié)

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