嵌入式系統(tǒng)中軟件的測試用例生成研究

(廣東威靈電機(jī)制造有限公司 電機(jī)開發(fā)研究院，順德 528311)

嵌入式系統(tǒng)中軟件的測試用例生成研究

付彥超

(廣東威靈電機(jī)制造有限公司 電機(jī)開發(fā)研究院，順德 528311)

探討了軟件測試中常見的幾大誤區(qū)，并利用黑盒測試和白盒測試相結(jié)合的測試策略，針對嵌入式系統(tǒng)中電機(jī)矢量控制方法中的空間矢量脈寬調(diào)制(SVPWM)算法進(jìn)行測試，詳述了各個(gè)測試方法的原理及其對應(yīng)測試用例的設(shè)計(jì)過程。

軟件測試；黑盒測試；白盒測試；SVPWM；測試用例

引 言

微電子技術(shù)的發(fā)展日新月異，使得嵌入式系統(tǒng)在醫(yī)療電子、智能家居、電力控制等領(lǐng)域得到廣泛的應(yīng)用。嵌入式系統(tǒng)的功耗、性能及可靠性與嵌入式軟件的質(zhì)量息息相關(guān)，而軟件測試又是軟件開發(fā)的核心環(huán)節(jié)，是在軟件投入使用之前，對軟件需求規(guī)格說明、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是確保軟件質(zhì)量、提高軟件可靠性的關(guān)鍵步驟[1]。

本文首先針對軟件測試存在的一些思維誤區(qū)進(jìn)行探討，隨后以電機(jī)驅(qū)動(dòng)控制中常用的空間矢量脈寬調(diào)制(SVPWM)算法軟件為例，介紹了一種黑盒測試和白盒測試相結(jié)合的軟件測試方法，詳述了測試原理及相應(yīng)的測試用例設(shè)計(jì)過程。

1 軟件測試領(lǐng)域中常見的思維誤區(qū)

隨著嵌入式系統(tǒng)的大量應(yīng)用，已經(jīng)有許多企業(yè)相繼組建了自己的軟件測試部門或團(tuán)隊(duì)，對于大型軟件系統(tǒng)，很多企業(yè)甚至還引入了第三方評(píng)測機(jī)構(gòu)。盡管如此，很多是軟件測試人員對于軟件測試領(lǐng)域的認(rèn)知還存在許多誤區(qū)[2]。下面對一些常見的思維誤區(qū)進(jìn)行探討。

1.1 誤區(qū)一：對軟件測試目的的認(rèn)識(shí)本末倒置

軟件測試的效果不盡如人意，很大原因是由于測試人員對軟件測試目的認(rèn)識(shí)錯(cuò)誤造成的。有相當(dāng)數(shù)量的軟件測試人員會(huì)認(rèn)為：軟件測試就是證明軟件不存在錯(cuò)誤的過程；軟件測試的目的在于證明軟件能夠正確完成其預(yù)定的功能。這些對軟件測試的理解是本末倒置的。

首先，進(jìn)行軟件測試的最終目的是為了提高軟件的質(zhì)量；其次，預(yù)設(shè)的目標(biāo)會(huì)對人的行為產(chǎn)生重要的心理影響。具體而言，如果進(jìn)行測試的目的是為了驗(yàn)證軟件的正確性，那么測試人員在潛意識(shí)中會(huì)更傾向于實(shí)現(xiàn)這個(gè)目標(biāo)，也就是說， 測試人員會(huì)傾向于設(shè)計(jì)出較少導(dǎo)致被測軟件失效的測試用例。如果進(jìn)行測試的目的是為了發(fā)現(xiàn)軟件中隱藏的錯(cuò)誤，那么測試人員會(huì)傾向于設(shè)計(jì)出更多發(fā)現(xiàn)問題的測試用例。顯然，后者更有助于提高軟件的質(zhì)量。

因此，對軟件測試更為合理的理解應(yīng)該是：軟件測試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程[3]。

1.2 誤區(qū)二：軟件測試可以完全通過自動(dòng)化測試工具進(jìn)行

部分軟件測試人員，甚至項(xiàng)目經(jīng)理也會(huì)認(rèn)為，有了自動(dòng)化測試工具，便可以完成全部的軟件測試，可以完全取代諸如代碼檢測、走查與評(píng)審等人工測試過程。

這是一種片面的理解，原因有二。其一，根據(jù)大量實(shí)踐證明，人工測試可以發(fā)現(xiàn)很多自動(dòng)化測試工具無法識(shí)別的錯(cuò)誤。這些錯(cuò)誤的典型特點(diǎn)是既不違反代碼編寫規(guī)范，又未出現(xiàn)任何邏輯錯(cuò)誤，甚至可以執(zhí)行出一個(gè)貌似正確的結(jié)果使程序跑下去。比如，絕大多數(shù)軟件工程師在使用C語言進(jìn)行編碼時(shí)，都犯過錯(cuò)用“=”和“==”的錯(cuò)誤，但這個(gè)錯(cuò)誤難以被自動(dòng)化測試工具識(shí)別，最多只能給出一個(gè)警告(warning)。其二，許多軟件語言在最初的設(shè)計(jì)上并不完美。以目前嵌入式軟件中流行的C語言為例，正如在Kernighan和Ritchie合著的C語言經(jīng)典著作《The C Programming Language》中所述：“有些運(yùn)算符的優(yōu)先級(jí)是錯(cuò)誤的！”盡管如此，ANSI C在修改C語言運(yùn)算符優(yōu)先級(jí)方面并沒有采取什么修正措施，這也毫不奇怪，因?yàn)槿绻麑\(yùn)算符的優(yōu)先級(jí)做了修改，大量現(xiàn)有的代碼就會(huì)出現(xiàn)問題[4]。

1.3 誤區(qū)三：軟件測試人員只是執(zhí)行測試用例，并將執(zhí)行結(jié)果與預(yù)期結(jié)果進(jìn)行比較

這種觀點(diǎn)把測試看作是一種簡單的比較活動(dòng)，并沒有看到軟件測試人員必須設(shè)計(jì)測試用例，并確定預(yù)期輸出結(jié)果。實(shí)際上，測試一個(gè)軟件所需要的創(chuàng)造性很可能超過了開發(fā)該軟件所需要的創(chuàng)造性[3]。大多數(shù)的測試設(shè)計(jì)都是基于探索式推斷[5]，這意味著要以一種不能事先預(yù)測的方式，通過一種思想引出另一種思想，然后再引出下一種思想[6]。軟件的編寫可以按照設(shè)計(jì)階段制定的功能需求或者說明書進(jìn)行開發(fā)，然而軟件的測試卻并沒有明確的功能說明書用于參考。

1.4 誤區(qū)四：軟件測試是在代碼發(fā)布后進(jìn)行的

圖1 瀑布模式開發(fā)流程圖

許多軟件開發(fā)小組習(xí)慣于采用瀑布模式作為軟件開發(fā)模式。在瀑布模式中，每一個(gè)階段的結(jié)束同時(shí)也是下一個(gè)階段的開始，工作流程按照指定的順序進(jìn)行。工作的實(shí)現(xiàn)從一個(gè)階段“流動(dòng)”到另一個(gè)階段，就像瀑布從山上流下，如圖1所示。

這個(gè)模式的好處是，當(dāng)軟件工程師開始一個(gè)新的階段時(shí)，前一階段的所有工作都已完成。另一個(gè)潛在好處是它能夠強(qiáng)制軟件工程師在動(dòng)手編寫代碼前盡可能多地進(jìn)行思考和設(shè)計(jì)。然而，這個(gè)模式的最大缺點(diǎn)是不靈活。比如，在測試階段發(fā)現(xiàn)了一個(gè)由于設(shè)計(jì)缺陷而導(dǎo)致的錯(cuò)誤，修正起來會(huì)非常困難，因?yàn)樵O(shè)計(jì)階段已經(jīng)結(jié)束了。而事實(shí)上，瀑布模式的設(shè)計(jì)者Winston Royce的本意，是要將其設(shè)計(jì)成一種迭代的過程[7]。

和瀑布模式相比，V字模型模式更適合軟件開發(fā)[8]。具體而言，軟件測試應(yīng)該在編程的最開始就進(jìn)行，這樣做最大的優(yōu)點(diǎn)是可以降低修正錯(cuò)誤的成本。這并不難理解，試想，如果是在代碼已經(jīng)發(fā)布(接近開發(fā)完成)的情況下再進(jìn)行軟件測試，為了糾正在測試中發(fā)現(xiàn)的錯(cuò)誤，可能需要返回到很早的時(shí)間(甚至是軟件開發(fā)時(shí)的需求定義階段)，這樣越到后來，往前返工需要重做的事情就越多。所以，修改后期的錯(cuò)誤所做的工作量要比修改前期的錯(cuò)誤多得多。錯(cuò)誤的發(fā)現(xiàn)和解決處理得越遲，其帶來的成本就越高[9]。Boehm在《軟件工程經(jīng)濟(jì)》一書中表示：平均而言，如果在需求階段修正一個(gè)錯(cuò)誤的代價(jià)是1，那么，在設(shè)計(jì)階段發(fā)現(xiàn)并修正該錯(cuò)誤的代價(jià)將是3～6倍，在編程階段才發(fā)現(xiàn)該錯(cuò)誤的代價(jià)是10倍，在內(nèi)部測試階段則會(huì)變成20～40倍，在外部測試階段則是它的30～70倍，而到了產(chǎn)品發(fā)布出去時(shí)，這個(gè)數(shù)字就會(huì)高達(dá)40～1000倍。修正錯(cuò)誤的代價(jià)不是隨時(shí)間線性增長，而幾乎是呈指數(shù)級(jí)增長的。

1.5 誤區(qū)五：軟件可以被完全測試

很多軟件開發(fā)小組成員、項(xiàng)目經(jīng)理、甚至是公司都希望能對開發(fā)的軟件進(jìn)行全面的測試，并借此來發(fā)現(xiàn)所有隱藏的錯(cuò)誤，進(jìn)而完善軟件的質(zhì)量。然而，針對一套軟件進(jìn)行完全測試是不可能的。因?yàn)檐浖妮斎敕秶?，不可能對其進(jìn)行窮盡測試。同時(shí)，程序中可能的運(yùn)行路徑太多，也不可能窮盡測試。

Myers為了說明這個(gè)問題，在1979年編寫了一個(gè)簡單的程序，僅有一個(gè)loop循環(huán)和一些if語句，如果使用C語言編寫，可以將這段程序控制在20行以內(nèi)。這組程序有1018條不同的路徑，Myers提醒人們宇宙的壽命也不過4×1017秒而已[10]。

2 軟件測試的執(zhí)行

Myers已經(jīng)證明了窮舉的黑盒和白盒測試通常是不可能的，但同時(shí)也建議將這兩種測試的要素組合起來可以得到一種更加合理的測試策略,因?yàn)槟撤N方法遺漏掉的錯(cuò)誤，用其他的方法就可能找出來。

下面將分別針對人工測試技術(shù)、黑盒測試中的邊界值分析法和等價(jià)類劃分法、白盒測試中的判定覆蓋法的原理進(jìn)行闡述，并詳述基于以上方法如何進(jìn)行測試用例的設(shè)計(jì)。

2.1 代碼檢查和走查

大多數(shù)人認(rèn)為，因?yàn)槌绦蜃罱K是為了提供給機(jī)器執(zhí)行而編寫的，那么也應(yīng)該由機(jī)器來對程序進(jìn)行測試。實(shí)際上，這種想法是有問題的。人工測試方法在暴露錯(cuò)誤方面同樣是很有成效的。

代碼檢查和走查是兩種主要的人工測試方法，都要求一個(gè)小組來閱讀特定的程序代碼，在類似于一種頭腦風(fēng)暴會(huì)的評(píng)審會(huì)議中，盡可能多地發(fā)現(xiàn)軟件中的錯(cuò)誤。

檢測小組一般由3～4位工程師組成，其中一位是代碼的作者，負(fù)責(zé)講解代碼；一位是稱職的軟件工程師，但不是代碼的作者，負(fù)責(zé)協(xié)調(diào)整個(gè)會(huì)議，包含會(huì)議進(jìn)程的安排、會(huì)議評(píng)審資料的準(zhǔn)備、記錄發(fā)現(xiàn)的所有錯(cuò)誤、在會(huì)議后確保所有的錯(cuò)誤都已經(jīng)予以糾正；其余1～2位是稱職的軟件工程師(其中一人最好是其他項(xiàng)目里的軟件工程師)，但同樣不是代碼的作者，并且熟悉常見的編碼錯(cuò)誤，在會(huì)議中負(fù)責(zé)傾聽與提問。

在評(píng)審會(huì)議中，由代碼的作者逐條語句講述程序的邏輯結(jié)構(gòu)。在講述的過程中，小組的其他成員應(yīng)根據(jù)自己的理解提出問題，判斷是否存在錯(cuò)誤。在實(shí)際應(yīng)用中，常常遇到的情況是代碼的作者在講述的過程中自己發(fā)現(xiàn)了大部分的錯(cuò)誤。評(píng)審會(huì)議的節(jié)奏由協(xié)調(diào)人負(fù)責(zé)把握，確保大家的注意力全部集中在更多地發(fā)現(xiàn)錯(cuò)誤上，而不是在發(fā)現(xiàn)錯(cuò)誤后討論如何修正這個(gè)錯(cuò)誤。同時(shí)，詳細(xì)記錄會(huì)議中發(fā)現(xiàn)的每一個(gè)錯(cuò)誤。這樣，評(píng)審會(huì)議結(jié)束后，小組會(huì)得到一份錯(cuò)誤清單。如果錯(cuò)誤清單上的錯(cuò)誤數(shù)較多，需要對該清單的內(nèi)容進(jìn)行歸納、總結(jié)，以提高日后的代碼檢查效率。評(píng)審會(huì)議可以培養(yǎng)團(tuán)隊(duì)內(nèi)良性競爭的氣氛，因?yàn)榻M員喜歡通過發(fā)現(xiàn)問題來展示自己的能力。

代碼檢查和走查與自動(dòng)化測試是互補(bǔ)的，缺少其中任何一種，錯(cuò)誤檢查的效率都會(huì)降低。

代碼檢查和走查不僅對于測試新開發(fā)的程序有著不可估量的作用，而且對于測試更改后的程序依然具有相同的作用，甚至更大。根據(jù)測試經(jīng)驗(yàn)，修改一個(gè)現(xiàn)存的程序比編寫一個(gè)新程序更容易產(chǎn)生錯(cuò)誤。因此，除了回歸測試方法之外，更改后的程序還要進(jìn)行這些人工方法的測試。

2.2 測試用例的設(shè)計(jì)

2.2.1 SVPWM原理簡述

SVPWM的原理及其工程實(shí)現(xiàn)方法在此不做贅述，詳細(xì)內(nèi)容參閱參考文獻(xiàn)[11]，本文只對SVPWM軟件模塊的規(guī)格說明進(jìn)行描述。SVPWM軟件模塊框圖如圖2所示。

圖2 SVPWM軟件模塊框圖

它包括：

① 雙輸入(Uα和Uβ)，三輸出(Ta、Tb、Tc)。

② 輸入變量已標(biāo)幺化，其取值范圍為[0,1]。

③ 標(biāo)幺化后的輸入變量又被Q格式化，且為Q14格式，則其取值范圍為Uα、Uβ∈[0,214]。

④ 兩個(gè)輸入變量彼此正交。

⑤ 兩個(gè)輸入變量最終合成一個(gè)電壓矢量Uout，且滿足關(guān)系式(1)：

式中，T為PWM中斷周期，T1和T2分別為基礎(chǔ)相量U0和U60的加載時(shí)間。

⑥ 輸出變量Ta、Tb、Tc的取值如表1所列。

表1 Ta、Tb、Tc在不同矢量區(qū)間中的取值

在表1中，taon、tbon、tcon按照式(2)求?。?/p>

式中，t1、t2的取值如表2所列。

表2 t1、t2在不同矢量區(qū)間中的取值

在表2中，X、Y、Z按照式(3)求?。?/p>

2.2.2 根據(jù)邊界值分析法確定測試用例

經(jīng)驗(yàn)證明，考慮了邊界條件的測試用例與其他沒有考慮邊界條件的測試用例相比，具有更高的測試回報(bào)率。所謂邊界條件，是指輸入和輸出等價(jià)類中那些恰好處于邊界、或超過邊界、或在邊界以下的狀態(tài)。

按照如上原則，生成的測試用例有：

a. 輸入為空；

b. 輸入變量Uβ為0；

c. 輸入變量Uβ為1638(即_IQ14(0.1))；

d. 輸入變量Uβ為14745(即_IQ14(0.9))；

e. 輸入變量Uβ為16384(即_IQ14(1))；

f. 輸入變量Uβ為18022(即_IQ14(1.1))；

g. 輸入變量Uα為0；

h. 輸入變量Uα為1638(即_IQ14(0.1))；

i. 輸入變量Uα為25395(即_IQ14(1.55))；

j. 輸入變量Uα為27033(即_IQ14(1.65))；

k. 輸入變量Uα為27197(即_IQ14(1.66))。

2.2.3 根據(jù)等價(jià)類劃分法確定測試用例

等價(jià)類劃分測試的思想是，將程序輸入范圍進(jìn)行劃分，將其劃分為有限數(shù)量的等價(jià)類，如果等價(jià)類的某個(gè)測試用例發(fā)現(xiàn)了某個(gè)錯(cuò)誤，則該等價(jià)類的其他用例也應(yīng)該能發(fā)現(xiàn)同樣的錯(cuò)誤。這種思想可以確保采用較少的測試用例子集發(fā)現(xiàn)較多的錯(cuò)誤子集。

下面根據(jù)等價(jià)類劃分法確定測試用例，其過程如下：

① 為每個(gè)等價(jià)類設(shè)置一個(gè)不同的編號(hào)。

② 設(shè)計(jì)測試用例，盡可能多地覆蓋那些尚未被涵蓋的有效等價(jià)類，直到包含所有的有效等價(jià)類。

③ 設(shè)計(jì)新的測試用例，覆蓋一個(gè)且僅一個(gè)尚未被涵蓋的無效等價(jià)類，直到包含所有的無效等價(jià)類。

以上步驟都以表格形式記錄在表3中，括號(hào)中的數(shù)字代表不同等價(jià)類的標(biāo)識(shí)符。

表3 等價(jià)類列舉表

按照表3設(shè)計(jì)一系列測試用例，用以涵蓋一個(gè)或多個(gè)有效等價(jià)類，如:

涵蓋了表3中第(1)、(4)、(7)等價(jià)類。而無效等價(jià)類及其測試用例如下所示：

(2) Uα或Uβ=4096，即_IQ13(0.5)

(3) Uα或Uβ=16384，即_IQ15(0.5)

(5) Uα或Uβ=0xDFFF，即_IQ14(-0.5)

(6) Uα或Uβ=18022，即_IQ14(1.1)

此時(shí)，所有的等價(jià)類都被以上7個(gè)測試用例全部覆蓋了。

2.2.4 根據(jù)判定覆蓋法確定測試用例

判定覆蓋法要求每個(gè)判斷都必須有“是”和“否”的結(jié)果，并且每條語句都至少被執(zhí)行一次。換言之，即每個(gè)判斷都必須有“是”和“否”的結(jié)果，而且每個(gè)入口點(diǎn)都必須至少被調(diào)用一次。SVPWM程序的流程圖如圖3所示。

圖3 SVPWM程序流程圖

根據(jù)判定覆蓋法的原則，設(shè)計(jì)測試用例如表4所列。

表4 根據(jù)判定覆蓋法設(shè)計(jì)的測試用例集

結(jié) 語

[1] Perry William E.軟件測試的有效方法[M].蘭雨晴，等譯.北京:機(jī)械工業(yè)出版社,2004.

[2] 喬勇誠.探討軟件測試誤區(qū)[J].通信技術(shù),2011(8):149-151.

[3] Glenford J Myers.軟件測試的藝術(shù)[M].張曉明，等譯.北京:機(jī)械工業(yè)出版社,2016.

[4] Peter Van Der Linden.C專家編程[M].徐波，譯.北京:人民郵電出版社,2008.

[5] Lakatos.證明與反駁:數(shù)學(xué)發(fā)現(xiàn)的邏輯[M].方剛，等譯.上海:上海譯文出版社,1987.

[6] Cem Kaner.軟件測試經(jīng)驗(yàn)與教訓(xùn)[M].韓柯，等譯.北京:機(jī)械工業(yè)出版社,2004.

[7] Winston Royce.Managing the Development of Large Software Systems[C]//Proceedings of IEEE WESCON 26,1970.

[8] Alan Page.微軟的軟件測試之道[M].張爽，等譯.北京:機(jī)械工業(yè)出版社,2009.

[9] 朱少民.全程軟件測試[M].北京:電子工業(yè)出版社,2007.

[10] Cem Kaner.計(jì)算機(jī)軟件測試[M].王峰，等譯.北京:機(jī)械工業(yè)出版社,2004.

[11] Erwan Simon.Implementation of a Speed Field Oriented Control of 3-phase PMSM MotorUsing TMS320F240[C]//Application Report SPRA588,1999.

付彥超(碩士研究生)，主要研究方向?yàn)殡姍C(jī)驅(qū)動(dòng)控制。

ResearchonTestCasesGenerationofSoftwareinEmbeddedSystem

FuYanchao

(Motor Development Research Institute,Guangdong Weiling Motor Manufacturing Co.,Ltd.,Shunde 528311,China)

In the paper,several misunderstandings of the software testing are discussed,and a method that combines black-box testing and white-box testing is used to test the SVPWM algorithm which is widely applied in motor drive system.The design principles and design process of test cases are also explored in this paper.

software testing;black-box testing;white-box testing; SVPWM;test case

TP311

A

2017-07-07)