馬雪懷

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

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

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：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

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

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

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

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

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

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

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

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

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

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

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

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

2.2軟件模塊間的依賴性

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

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

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

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

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

圖1 UI、Logic的模塊依賴

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

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

[模塊編號(hào)＼&模塊名稱＼&模塊類別＼&模塊功能＼&依賴于模塊＼&C001＼&CM_keyboard＼&控制類＼&物理按鍵輸入響應(yīng)＼&Logic層Common＼&C002＼&CM_touchpanel＼&控制類＼&觸摸屏輸入響應(yīng)＼&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)層＼&工程設(shè)置界面＼&C001、C002、C006＼&U002＼&UI_AddrSetting＼&表現(xiàn)層＼&網(wǎng)絡(luò)地址設(shè)置界面＼&C001、C002、C006、U001＼&U003＼&UI_PwdSetting＼&表現(xiàn)層＼&密碼設(shè)置界面＼&C001、C002、C006、U001＼&U004＼&UI_VolSetting＼&表現(xiàn)層＼&音量設(shè)置界面＼&C001、C005、C006、U001＼&U005＼&UI_VideoAdujst＼&表現(xiàn)層＼&視頻角度設(shè)置界面＼&C001、C003、C004、U001＼&]

2.3軟件模塊間的接口定義

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

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

typedef struct

{

char compile_date[20]； /* 軟件編譯時(shí)間. */

char compile_time[20]；

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

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

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

int becall_enable； /*被叫是否禁用，正在報(bào)警和布防延時(shí)過(guò)程中，進(jìn)入來(lái)電呼入 */

int cur_rec； /*正在錄音*/

int server_time； /*登錄后，獲取的服務(wù)器時(shí)間*/

int city； /*天氣城市*/

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

int temperature； /*溫度，weather>0時(shí)顯示溫度*/

int msg_sync_time； /*最新消息時(shí)間*/

int is_register；

int is_login； /*登錄標(biāo)識(shí)*/

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

int sync_server_time_enable； /*是否同步服務(wù)器時(shí)間*/

Z_SLIST dev2ip_list； /*設(shè)備編號(hào)與IP對(duì)應(yīng)表（DEV2IP_ITEM）*/

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

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

int user_change_addr； /*用戶修改了地址（IP或房號(hào)）*/

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

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

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

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)閉屏保，進(jìn)入工程設(shè)置需要關(guān)閉屏保*/

int off_alarm_moudle； /*是否關(guān)閉報(bào)警，進(jìn)入工程設(shè)置需要關(guān)閉屏保*/

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

char test_server_ip[16]； /*測(cè)試服務(wù)器地址，如果沒有設(shè)置則使用中心服務(wù)器地址*/

char alarm_recvlist[16 * 20]； /*ip，ip，... 20個(gè)，接收?qǐng)?bào)警設(shè)備列表，目前為所有中心機(jī)（最多20個(gè)）. 為什么不定義char alarm_recvlist[20][16]；因?yàn)閳?bào)警很少，在用它時(shí)再解析，可以減少cpu操作*/

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

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

} DVP_SYS_STATE；

3 測(cè)試策略與測(cè)試方法

3.1建立接口測(cè)試策略

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

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

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

[模塊編號(hào)＼&模塊名稱＼&依賴于模塊＼&依賴系數(shù)＼&模塊功能＼&功能系數(shù)＼&優(yōu)先級(jí)數(shù)值＼&C001＼&CM_keyboard＼&Logic層Common＼&5＼&物理按鍵輸入響應(yīng)＼&3＼&15＼&C002＼&CM_touchpanel＼&Logic層Common＼&3＼&觸摸屏輸入響應(yīng)＼&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＼&工程設(shè)置界面＼&2＼&8＼&U002＼&UI_AddrSetting＼&C001、C002、C006、U001＼&1＼&網(wǎng)絡(luò)地址設(shè)置界面＼&2＼&2＼&U003＼&UI_PwdSetting＼&C001、C002、C006、U001＼&1＼&密碼設(shè)置界面＼&1＼&1＼&U004＼&UI_VolSetting＼&C001、C005、C006、U001＼&1＼&音量設(shè)置界面＼&1＼&1＼&U005＼&UI_VideoAdujst＼&C001、C003、C004、U001＼&1＼&視頻角度設(shè)置界面＼&1＼&1＼&]

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

3.2設(shè)計(jì)接口測(cè)試方法

3.2.1評(píng)估測(cè)試方法

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

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

3.2.2設(shè)計(jì)高效的測(cè)試用例

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

表3 測(cè)試用例正交表

[用例編碼＼&經(jīng)驗(yàn)數(shù)據(jù)庫(kù)分類＼&模塊編號(hào)＼&模塊名稱＼&CA=Nt＼&選取標(biāo)志＼&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看到，對(duì)于編號(hào)為“C006”與“U001”的模塊間的測(cè)試用例由于其“依賴系數(shù)”較高，所以在測(cè)試經(jīng)驗(yàn)庫(kù)比對(duì)中有高比例的測(cè)試用例數(shù)進(jìn)入用例集。

4 有效的迭代與回歸策略

4.1有效樁的設(shè)計(jì)

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

在本文的接口測(cè)試?yán)又校覀冊(cè)O(shè)計(jì)的樁用于替代應(yīng)用頻度最高（依賴系數(shù)最高）的模塊C001：CM_keyboard，也就是設(shè)計(jì)S001：STUB_keyboard，對(duì)應(yīng)于CM_keyboard封裝的輸入輸出參數(shù)，例如：“int key_enable_call”等上文說(shuō)明的編號(hào)C001模塊中定義的參數(shù)，從而實(shí)現(xiàn)對(duì)應(yīng)于相關(guān)聯(lián)模塊接口的樁測(cè)試。

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

4.2 接口測(cè)試的迭代版本控制

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

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

4.3 回歸測(cè)試度量

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

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

1）基于風(fēng)險(xiǎn)選擇測(cè)試

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

2）基于操作剖面選擇測(cè)試

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

3）再測(cè)試修改的部分

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

5 結(jié)束語(yǔ)

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

參考文獻(xiàn)：

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

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

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

[8] Dr Ingrid B.Ottevanger，賈國(guó)瑩， 譯. 基于風(fēng)險(xiǎn)的測(cè)試策略. 51測(cè)試天地[EB/OL].www.51testing.com.