測試用例質(zhì)量的重要性

介紹

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

一個(gè)簡(jiǎn)單的例子

        如下是對一個(gè)簡(jiǎn)單測試對象的說(shuō)明：

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

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

圖1 這三個(gè)測試用例通過(guò)并達到了100%的覆蓋率

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

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

?  邊界值

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

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

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

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

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

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

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

?  最小/最大值

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

圖3 函數abs_short（）存在一個(gè)在使用最大/最小值輸入時(shí)才會(huì )發(fā)現的問(wèn)題

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

?  極端值

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

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

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

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

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

?  違規值

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

ISO26262中的建議

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

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

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

?  錯誤猜測

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

可選方案

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

?  來(lái)自源代碼的測試用例

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

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

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

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

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

    ?  使用自動(dòng)生成的測試套件無(wú)法檢測到更多缺陷。

    ?  自動(dòng)生成的測試用例會(huì )對捕獲預期的類(lèi)行為產(chǎn)生負面影響。

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

變異測試（Mutation Testing）

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

小結

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