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

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

付彥超

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

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

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

引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

很多軟件開發(fā)小組成員、項目經(jīng)理、甚至是公司都希望能對開發(fā)的軟件進行全面的測試，并借此來發(fā)現(xiàn)所有隱藏的錯誤，進而完善軟件的質(zhì)量。然而，針對一套軟件進行完全測試是不可能的。因為軟件的輸入范圍太大，不可能對其進行窮盡測試。同時，程序中可能的運行路徑太多，也不可能窮盡測試。

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

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

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

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

2.1 代碼檢查和走查

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

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

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

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

代碼檢查和走查與自動化測試是互補的，缺少其中任何一種，錯誤檢查的效率都會降低。

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

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

2.2.1 SVPWM原理簡述

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

圖2 SVPWM軟件模塊框圖

它包括：

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

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

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

④ 兩個輸入變量彼此正交。

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

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

⑥ 輸出變量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)驗證明，考慮了邊界條件的測試用例與其他沒有考慮邊界條件的測試用例相比，具有更高的測試回報率。所謂邊界條件，是指輸入和輸出等價類中那些恰好處于邊界、或超過邊界、或在邊界以下的狀態(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ù)等價類劃分法確定測試用例

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

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

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

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

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

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

表3 等價類列舉表

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

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

(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)

此時，所有的等價類都被以上7個測試用例全部覆蓋了。

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

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

圖3 SVPWM程序流程圖

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

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

結(jié) 語

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

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

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

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

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

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

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

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

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

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

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

付彥超(碩士研究生)，主要研究方向為電機驅(qū)動控制。

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)