馬雪懷

摘要：在日益廣泛應用的嵌入式系統(tǒng)中，軟件測試因為系統(tǒng)平臺局限性需要重復下裝，耗費較大的測試資源與時間成本。文章根據(jù)嵌入式系統(tǒng)軟件的特性，結(jié)合實際案例智能樓宇對講系統(tǒng)DH-T90，從測試環(huán)境描述、測試用例篩選、回歸策略選擇等一系列方法步驟，較系統(tǒng)的說明一種制定智能樓宇對講系統(tǒng)接口測試的規(guī)劃策略，從而優(yōu)化嵌入式系統(tǒng)的接口測試，規(guī)范了測試風險，并提升了測試效率。

關(guān)鍵詞：軟件工程；嵌入式；測試方法；測試用例；回歸測試

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2015）09-0065-04

Abstract： In these days， embedded system is widely used in our life.Software testing needs a high test resources and time consuming.It needs to be repeated loading because of limitations of system platform. According to the characteristics of embedded system software， combined with the actual case of intelligent building intercom system DH-T90. There is a series of method description， includes test environment， test cases and regression strategy.It systematically provides a set of test planning strategy to intelligent building intercom system interface.So as to optimize the test interface of the embedded system， standardize the testing risk， and improve test efficiency。

Key words： software engineering，embedded； test method； test cases； regression test

隨著手機、平板電腦等便攜電子設備的廣泛應用，集成化的嵌入式系統(tǒng)已經(jīng)成為智慧城市的重要應用。作為系統(tǒng)的開發(fā)者，應該如何對嵌入式軟件系統(tǒng)中模塊進行接口測試？顯然，如果原封不動的套用我們很熟悉的通用平臺上應用軟件的集成測試方法，在一些關(guān)鍵環(huán)節(jié)無法實現(xiàn)對嵌入式軟件的接口測試。文章根據(jù)嵌入式系統(tǒng)軟件的特性，結(jié)合實際案例智能樓宇對講系統(tǒng)DH-T90，從測試環(huán)境、測試模型、測試用例等方面描述如何制定智能樓宇對講系統(tǒng)的接口測試策略。

1 嵌入式軟件測試環(huán)境

軟件工程意義上的軟件測試環(huán)境是指為了完成軟件測試工作所必需的硬件、軟件、外設、歷史數(shù)據(jù)的總稱。一般說來，良好的測試環(huán)境需要具備三大要素：優(yōu)化的測試模型、多樣化的系統(tǒng)配置以及熟練使用工具的測試員。

在規(guī)劃測試策略與計劃時，測試環(huán)境的建設是測試實施的一個重要階段，測試環(huán)境的適合與否會嚴重影響測試結(jié)果的真實性與準確性。在智能樓宇對講系統(tǒng)中，由于軟件是燒寫在硬件芯片方案中直接執(zhí)行的（就是所謂“嵌入式”），所以最可靠的測試環(huán)境，就是將待測軟件燒錄后再執(zhí)行測試，但是這種模式下，有多少次回歸就要進行多少次燒錄芯片的操作，無疑增大了測試資源的投入，也限制了軟件系統(tǒng)的快速迭代。目前業(yè)界比較通行的方式是采用虛擬機（或者模擬器）的方式，在可接受的擬真度情況下，應用虛擬機對嵌入式軟件進行模擬燒錄、回歸測試并最后下裝驗證。在DH-T90智能樓宇對講系統(tǒng)中，應用軟件以APP文件燒錄在芯片中，因此，我們在模擬測試環(huán)境下執(zhí)行功能模塊的接口測試。

2 嵌入式系統(tǒng)的軟件架構(gòu)與模塊

一般的，在進行軟件模塊接口測試中，首先需要了解軟件總體架構(gòu)與模塊劃分的邏輯關(guān)系，理解并掌握模塊間的接口定義，在此基礎上才能構(gòu)建測試模型與設計測試方法。

2.1 DH-T90的軟件架構(gòu)

從概要設計書中，我們了解了DH-T90的軟件總體架構(gòu)：

1）表現(xiàn)層（ui）：主要是用戶界面這一塊。

2）業(yè)務邏輯層（logic）：具體的業(yè)務邏輯這塊，和問題領(lǐng)域相關(guān)。

3）系統(tǒng)平臺層（system）：內(nèi)核、各種驅(qū)動、c庫等等。

并且在架構(gòu)中制定了模塊依賴規(guī)則：同層次的模塊相互依賴，不允許下層模塊依賴與上層模塊。

2.2軟件模塊間的依賴性

了解了軟件的總體架構(gòu)后，需要根據(jù)測試需求明確DH-T90的測試范圍我們限定于APP子系統(tǒng)中，而我們的接口測試對象就聚焦于“UI”、“Logic”層所包含的各模塊間接口。

接下來就需要充分理解并掌握“UI”、“Logic”層所包含各模塊的依賴關(guān)系。通過圖1的方式，可以對模塊劃分類別，并清晰的勾勒出測試模塊間的依賴關(guān)系：

1）實體類、Widget：是完成一個模塊的基本單位，和別的模塊基本是不相關(guān)的，獨立性高；

2）控制類、表現(xiàn)層：主要是其協(xié)調(diào)、控制控制這些基本組件的功能，和很多的模塊相互關(guān)聯(lián)；

3）其中的單向箭頭說明的模塊依賴關(guān)系。

圖1 UI、Logic的模塊依賴

根據(jù)模塊分類及相互間的依賴關(guān)系，我們需要對測試范圍內(nèi)的模塊進行梳理。表1列舉了DH-T90系統(tǒng)中部分模塊間的相互依賴關(guān)系。

表1 模塊依賴關(guān)系列表

[模塊編號＼&模塊名稱＼&模塊類別＼&模塊功能＼&依賴于模塊＼&C001＼&CM_keyboard＼&控制類＼&物理按鍵輸入響應＼&Logic層Common＼&C002＼&CM_touchpanel＼&控制類＼&觸摸屏輸入響應＼&Logic層Common＼&C003＼&CM_orange＼&控制類＼&多圖層操作＼&Logic層Common＼&C004＼&CM_cedar＼&控制類＼&視頻解碼，視頻播放＼&Logic層Common＼&C005＼&CM_audio＼&控制類＼&音頻解碼＼&Logic層Common＼&C006＼&CM_FTK＼&控制類＼&ui框架＼&Logic層Common＼&U001＼&UI_Config＼&表現(xiàn)層＼&工程設置界面＼&C001、C002、C006＼&U002＼&UI_AddrSetting＼&表現(xiàn)層＼&網(wǎng)絡地址設置界面＼&C001、C002、C006、U001＼&U003＼&UI_PwdSetting＼&表現(xiàn)層＼&密碼設置界面＼&C001、C002、C006、U001＼&U004＼&UI_VolSetting＼&表現(xiàn)層＼&音量設置界面＼&C001、C005、C006、U001＼&U005＼&UI_VideoAdujst＼&表現(xiàn)層＼&視頻角度設置界面＼&C001、C003、C004、U001＼&]

2.3軟件模塊間的接口定義

按照表1中模塊依賴關(guān)系，我們能夠較明確的了解到被依賴較多的模塊有哪些，比如：CM_keyboard、CM_FTK、UI_Config等。針對這些模塊，我們需要掌握模塊接口參數(shù)說明，因為在后續(xù)制定測試模型時，模塊依賴關(guān)系的強弱將作為計算測試優(yōu)先級的因素。

從軟件概要設計中明確CM_keyboard、CM_FTK、UI_Config的模塊接口參數(shù)如下：

typedef struct

{

char compile_date[20]； /* 軟件編譯時間. */

char compile_time[20]；

int key_enable； /* 控制mainwin消息中的按鍵處理，按鍵是否禁用，呼叫，響玲，通話過程中，禁用按鍵跳轉(zhuǎn)到其它界面（安防，中心，呼叫，監(jiān)視）. */

int key_enable_call； /* 控制mainwin消息中的按鍵處理時是否處理 DVP_VKEY_CALL 消息. */

int status_enable； /*狀態(tài)欄按鈕是否被禁用*/

int becall_enable； /*被叫是否禁用，正在報警和布防延時過程中，進入來電呼入 */

int cur_rec； /*正在錄音*/

int server_time； /*登錄后，獲取的服務器時間*/

int city； /*天氣城市*/

int weather； /*天氣狀況，（0-6）*/

int temperature； /*溫度，weather>0時顯示溫度*/

int msg_sync_time； /*最新消息時間*/

int is_register；

int is_login； /*登錄標識*/

int server_sync_time； /* 設備與服務器狀態(tài)同步時間 */

int sync_server_time_enable； /*是否同步服務器時間*/

Z_SLIST dev2ip_list； /*設備編號與IP對應表（DEV2IP_ITEM）*/

Z_SLIST auth_lock_list； /*授權(quán)限制碼*/

Z_SLIST auth_unlock_list； /*授權(quán)解鎖碼*/

int user_change_addr； /*用戶修改了地址（IP或房號）*/

char photo_dir[100]； /*圖片目錄. SD卡或udisk目錄*/

char udp_key_data[1024]； /*udp數(shù)據(jù)加密key，最大1K*/

int udp_key_len； /*upd數(shù)據(jù)加密key，輸入字符長度*/

int udp_key_enable； /*upd數(shù)據(jù)加密key有效狀態(tài) */

DVP_MOUDLE_STATE moudle； /*系統(tǒng)模塊狀態(tài)*/

int off_call_moudle； /*是否關(guān)閉電話模塊*/

int off_screen_save； /*是否關(guān)閉屏保，進入工程設置需要關(guān)閉屏保*/

int off_alarm_moudle； /*是否關(guān)閉報警，進入工程設置需要關(guān)閉屏保*/

int rec_usr_operation； /*錄制用戶操作*/

char test_server_ip[16]； /*測試服務器地址，如果沒有設置則使用中心服務器地址*/

char alarm_recvlist[16 * 20]； /*ip，ip，... 20個，接收報警設備列表，目前為所有中心機（最多20個）. 為什么不定義char alarm_recvlist[20][16]；因為報警很少，在用它時再解析，可以減少cpu操作*/

int monitor_ret_state； /*梯口應答監(jiān)視狀態(tài)，室內(nèi)機使用此變量*/

int lcdpanel_on； /*指示LCD是否開啟，在X227出現(xiàn)黑屏界面被其它界面蓋住后無法點亮及按開鎖鍵無法點高問題*/

} DVP_SYS_STATE；

3 測試策略與測試方法

3.1建立接口測試策略

所謂測試策略就是對于一系列待測試模塊，我們需要考慮該如何安排測試序列，優(yōu)先測試哪些模塊才能使投入的測試資源更高效。根據(jù)歷史測試經(jīng)驗，一般定義的模塊測試策略公式：優(yōu)先級數(shù)值=模塊依賴系數(shù)×模塊功能系數(shù)。然后根據(jù)計算出的每個模塊的優(yōu)先級數(shù)值來安排測試序列。

根據(jù)表1中模塊依賴關(guān)系，按照被依賴越多的模塊，依賴系數(shù)越高的原則，制定每個模塊的依賴系數(shù)。同時根據(jù)各模塊實現(xiàn)功能重要性，列舉模塊功能系數(shù)。最后按照測試策略公式計算出的優(yōu)先級系數(shù)值，如下表2。

表2 模塊依賴系數(shù)、功能系數(shù)與優(yōu)先級系數(shù)

[模塊編號＼&模塊名稱＼&依賴于模塊＼&依賴系數(shù)＼&模塊功能＼&功能系數(shù)＼&優(yōu)先級數(shù)值＼&C001＼&CM_keyboard＼&Logic層Common＼&5＼&物理按鍵輸入響應＼&3＼&15＼&C002＼&CM_touchpanel＼&Logic層Common＼&3＼&觸摸屏輸入響應＼&3＼&9＼&C003＼&CM_orange＼&Logic層Common＼&1＼&多圖層操作＼&2＼&2＼&C004＼&CM_cedar＼&Logic層Common＼&1＼&視頻解碼，視頻播放＼&3＼&3＼&C005＼&CM_audio＼&Logic層Common＼&1＼&音頻解碼＼&3＼&3＼&C006＼&CM_FTK＼&Logic層Common＼&4＼&ui框架＼&2＼&8＼&U001＼&UI_Config＼&C001、C002、C006＼&4＼&工程設置界面＼&2＼&8＼&U002＼&UI_AddrSetting＼&C001、C002、C006、U001＼&1＼&網(wǎng)絡地址設置界面＼&2＼&2＼&U003＼&UI_PwdSetting＼&C001、C002、C006、U001＼&1＼&密碼設置界面＼&1＼&1＼&U004＼&UI_VolSetting＼&C001、C005、C006、U001＼&1＼&音量設置界面＼&1＼&1＼&U005＼&UI_VideoAdujst＼&C001、C003、C004、U001＼&1＼&視頻角度設置界面＼&1＼&1＼&]

最后，根據(jù)模塊優(yōu)先級數(shù)值表（表2），在測試策略中明確出各模塊測試序列。

3.2設計接口測試方法

3.2.1評估測試方法

確定模塊優(yōu)先級后，不是一個一個的順序?qū)δK接口進行測試，而是采用對兩個或者三個模塊進行組合測試的方法，組合策略的選擇是一個比較嚴謹?shù)脑u估過程。

不同組合，對于測試用例的要求不盡相同?；跇藴式M合定義為：CA=Nt，其中CA為組合用例數(shù)，N為模塊接口輸入用例范圍（也就是所謂的組合模式中的“水平”），t為模塊依賴系數(shù)（也就是所謂的組合模式中的“因子”）。因此如果按照完全覆蓋標準組合測試來設計兩兩模塊組合測試用例，將需要比較龐大的測試用例集。而對于實用樓宇對講系統(tǒng)的模塊測試經(jīng)驗數(shù)據(jù)庫，我們可以選擇變強度組合測試的方法來設計測試用例，以期達到在保持充分質(zhì)量水平的情況下，減少測試用例覆蓋，縮短測試周期，提高項目整體效率。

3.2.2設計高效的測試用例

所謂強度組合測試，指在完全覆蓋的標準組合測試用例范圍內(nèi)，根據(jù)模塊接口測試經(jīng)驗數(shù)據(jù)庫進行一定程度的比對，在保證一定覆蓋度比例與重點歷史權(quán)限全關(guān)聯(lián)的情況下，篩選出較少的必要測試用例集。一般的，我們在測試檢驗數(shù)據(jù)庫比對中采用正交表模式，設計篩選公式自動完成測試用例集的生成。正交表應用與測試經(jīng)驗數(shù)據(jù)庫的實例如表3。

表3 測試用例正交表

[用例編碼＼&經(jīng)驗數(shù)據(jù)庫分類＼&模塊編號＼&模塊名稱＼&CA=Nt＼&選取標志＼&001＼&SY001＼&C001＼&CM_keyboard＼&CA=32=9

＼&T＼&002＼&SY001＼&C001＼&CM_keyboard＼&F＼&003＼&SY002＼&C001＼&CM_keyboard＼&T＼&...＼&...＼&...＼&...＼&...＼&003＼&SY002＼&U001＼&UI_Config＼&CA=57=78125＼&T＼&004＼&SY002＼&U001＼&UI_Config＼&F＼&005＼&SY003＼&U001＼&UI_Config＼&T＼&006＼&SY004＼&U001＼&UI_Config＼&T＼&007＼&SY005＼&U001＼&UI_Config＼&T＼&...＼&...＼&...＼&...＼&...＼&]

從以上表3看到，對于編號為“C006”與“U001”的模塊間的測試用例由于其“依賴系數(shù)”較高，所以在測試經(jīng)驗庫比對中有高比例的測試用例數(shù)進入用例集。

4 有效的迭代與回歸策略

4.1有效樁的設計

由于嵌入式系統(tǒng)的模塊集成受限于平臺編譯與下裝，所以一般我們在進行模塊間接口測試時，采用樁來替代已完整通過功能測試的（單元）模塊。不同模塊間的接口測試，需要考慮的因素有很多，根據(jù)測試策略，采用樁的目的就是進行自動化的性能測試，也就是采用自動化腳本，對耦合最緊密的接口參數(shù)進行輸入輸出封裝，并驗證軟件長穩(wěn)性能。

在本文的接口測試例子中，我們設計的樁用于替代應用頻度最高（依賴系數(shù)最高）的模塊C001：CM_keyboard，也就是設計S001：STUB_keyboard，對應于CM_keyboard封裝的輸入輸出參數(shù)，例如：“int key_enable_call”等上文說明的編號C001模塊中定義的參數(shù)，從而實現(xiàn)對應于相關(guān)聯(lián)模塊接口的樁測試。

有效樁的設計關(guān)系到整體接口測試效率與可靠的性能測試，自動化性能測試一般采用指令腳本的方式執(zhí)行。

4.2 接口測試的迭代版本控制

在完成接口測試樁設計后，更進一步就要進行迭代版本的控制。因為接口測試中用樁替代功能模塊進行接口參數(shù)驗證是有較高代價的，在測試的任何一個階段，如果待測接口關(guān)聯(lián)的模塊功能發(fā)生改變，那么意味著樁就需重新設計。所以模塊內(nèi)任何的改變情況下，繼續(xù)用繼承樁進行測試，就可能會遺漏對模塊修改引發(fā)錯誤的發(fā)現(xiàn)。

制定迭代版本控制的原則，關(guān)鍵就是堅持在模塊功能完整測試通過后，進行接口樁設計與自動化性能測試，而版本迭代就要求集中在性能測試階段，迭代重點就應該是樁的接口參數(shù)封裝是否完整以及自動化測試腳本更新，盡量減少功能模塊的變更。

4.3 回歸測試度量

在嵌入式系統(tǒng)中，從測試用例庫抽取的用例集也可能變得相當大，如果每次回歸測試都需要重新運行完整的測試流程，那么測試的時間與資源開銷就很大?；貧w測試的價值在于它是一個能夠檢測到回歸錯誤的受控實驗。選擇回歸測試策略應該兼顧效率和有效性兩個方面。當然“再測試全部用例”仍然是所有策略中安全性和覆蓋性最高的一種。但由于嵌入式系統(tǒng)對于時間與資源等測試開銷的限制，一般不允許選擇“再測試全部用例”的回歸測試策略。

在本文的接口測試案例中，我們選擇三種方式相結(jié)合進行回歸測試，包括：

1）基于風險選擇測試

可以基于一定的風險標準來從基線測試用例集中選擇部分用例用于回歸測試。首先運行最重要的、關(guān)鍵的和可疑的測試，而跳過那些非關(guān)鍵的、優(yōu)先級別低的或者高穩(wěn)定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也較低。一般而言，測試選擇從主要特征到次要特征。

2）基于操作剖面選擇測試

繼承上文提到的針對性測試策略，用更精簡測試用例的分布情況來反映系統(tǒng)的實際使用情況?；貧w測試所使用的測試用例個數(shù)可以由測試預算確定，即回歸測試可以優(yōu)先選擇那些對最重要或最頻繁使用功能模塊的測試用例，釋放和緩解最高級別的風險，有助于盡早發(fā)現(xiàn)那些對接口可靠性有最大影響的故障。

3）再測試修改的部分

當我們對修改后提交的模塊代碼有足夠的信心時，就通過關(guān)聯(lián)性分析模塊修改情況與修改的影響，將回歸測試局限于被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及一個新的、修改的或刪除的代碼農(nóng)而不再擴散到接口相關(guān)聯(lián)的模塊。

5 結(jié)束語

對于嵌入式系統(tǒng)的接口測試策略，需要時間和人力來計劃、實施和管理。在給定的進度下，盡可能實現(xiàn)有效率的模塊關(guān)系模式計算和樁設計，需要對測試用例集進行優(yōu)化篩選并且選擇相應的回歸測試方法。當一系列都成為規(guī)范時候，系統(tǒng)接口測試就能夠保證足夠的效率與可控的風險。

參考文獻：

[1] Ian Sommerville. 軟件工程（英文版）[M]. 9版. 北京： 機械工業(yè)出版社， 2011.

[2] 陳云川. 嵌入式軟件調(diào)試技術(shù)[M]. 北京： 電子工業(yè)出版社， 2009.

[3] 劉利枚， 汪文勇， 唐科. 嵌入式軟件測試方法與技術(shù)[J]. 計算機與現(xiàn)代化， 2005（4）： 123-126.

[8] Dr Ingrid B.Ottevanger，賈國瑩， 譯. 基于風險的測試策略. 51測試天地[EB/OL].www.51testing.com.