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

一個(gè)簡單的例子

        如下是對一個(gè)簡單測試對象的說明：

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

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

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

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

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

· 邊界值

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

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

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

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

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

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

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

· 最小/最大值

        將給定數(shù)據(jù)類型的最大和最?。醋钬?fù)）可能的輸入值作為邊界值的特殊情況。

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

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

·  極端值

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

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

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

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

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

 · 違規(guī)值

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

ISO26262中的建議

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

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

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

· 錯(cuò)誤猜測

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

可選方案

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

· 來自源代碼的測試用例

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

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

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

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

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

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

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

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

變異測試（Mutation Testing）

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

小結(jié)

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