航天嵌入式軟件代碼邏輯分析①

左萬(wàn)娟,董 燕,黃 晨,王小麗

1(北京控制工程研究所,北京 100190)

2(北京軒宇信息技術(shù)有限公司,北京 100190)

航天嵌入式軟件,因其自主處理能力強(qiáng)、運(yùn)行實(shí)時(shí)性要求高、故障診斷與處理手段多、在軌運(yùn)行時(shí)間長(zhǎng)以及在軌運(yùn)行環(huán)境復(fù)雜等特點(diǎn),導(dǎo)致其部分運(yùn)行場(chǎng)景很難在地面實(shí)現(xiàn)真實(shí)狀態(tài)下的動(dòng)態(tài)驗(yàn)證.因此,在地面所開展的動(dòng)態(tài)測(cè)試往往會(huì)存在這樣或那樣的測(cè)試缺口,導(dǎo)致了某些軟件問(wèn)題的在軌發(fā)生,這對(duì)于有著高可信高可靠高自主要求的航天嵌入式軟件而言,是難以接受的.同時(shí),隨著軟件定義衛(wèi)星設(shè)計(jì)理念的提出,軟件規(guī)模和復(fù)雜度的不斷攀升,也導(dǎo)致軟件潛在缺陷越來(lái)越多[1,2].因此,研究軟件測(cè)試方法,進(jìn)一步提升軟件測(cè)試質(zhì)量勢(shì)在必行.

軟件測(cè)試,根據(jù)是否運(yùn)行軟件,一般分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試,其中,針對(duì)靜態(tài)測(cè)試,一般采用基于工具的靜態(tài)分析、和基于人工的代碼審查等測(cè)試手段.根據(jù)目前的工程實(shí)踐,對(duì)于有著高可信高可靠要求的航天嵌入式軟件而言,基于工具的靜態(tài)分析手段仍然無(wú)法取代人工代碼審查,只能作為人工代碼審查的補(bǔ)充手段.因此,在現(xiàn)有條件下,對(duì)于航天嵌入式軟件的質(zhì)量保證而言,人工代碼審查仍然是不可或缺的一種重要技術(shù)手段.

自從1976年首次提出代碼審查(code inspection)以來(lái),代碼審查一直被認(rèn)為是一種重要而且有效的改進(jìn)軟件質(zhì)量的方法[3,4].經(jīng)驗(yàn)表明,組織良好的代碼審查,可以發(fā)現(xiàn)程序中30%～70%的編碼和邏輯設(shè)計(jì)錯(cuò)誤[5].高質(zhì)量的代碼審查能夠發(fā)現(xiàn)60%以上的軟件問(wèn)題,而且往往能夠發(fā)現(xiàn)很多通過(guò)工具和動(dòng)態(tài)測(cè)試無(wú)法發(fā)現(xiàn)的深層次代碼問(wèn)題,如算法實(shí)現(xiàn)問(wèn)題、軟件架構(gòu)問(wèn)題、時(shí)序邏輯問(wèn)題等[6].代碼審查可以比動(dòng)態(tài)測(cè)試更有效地發(fā)現(xiàn)某些特定類型的缺陷,且實(shí)施時(shí)無(wú)需特別條件,成本較低[7].眾多研究成果表明,相比動(dòng)態(tài)測(cè)試,代碼審查更為高效、靈活且發(fā)現(xiàn)問(wèn)題能力強(qiáng).

但是,由于代碼審查本質(zhì)上仍然屬于一種既費(fèi)時(shí)又費(fèi)力的技術(shù)手段,且測(cè)試結(jié)果嚴(yán)重依賴于人的能力,因此,雖然是目前工程實(shí)踐中的一種主要技術(shù)手段、但是針對(duì)性的研究并不多.當(dāng)前軟件測(cè)試的研究熱點(diǎn)更多地集中在工具、自動(dòng)化和人工智能等方面[8-12].有限的針對(duì)基于人工代碼審查所開展的研究多著眼于檢查項(xiàng)(即檢查內(nèi)容)的研究與總結(jié)[13-16],對(duì)方法的研究與總結(jié)則很少,尤其在基于人工的代碼邏輯分析方面,尚無(wú)相關(guān)研究成果發(fā)表.而基于檢查項(xiàng)的代碼審查方法,屬于片段式檢查,缺乏對(duì)代碼的整體邏輯分析,不利于發(fā)現(xiàn)代碼中潛藏的深層次復(fù)雜邏輯問(wèn)題.

本文針對(duì)代碼審查重點(diǎn)內(nèi)容之一的代碼邏輯分析開展研究,提出了場(chǎng)景分析法、時(shí)序分析法、假想故障追源法等10 種主要的代碼邏輯分析方法,并開展了工程應(yīng)用分析.

1 分析方法

“分析”,通俗來(lái)說(shuō),是以某種方式將復(fù)雜對(duì)象分解為更小的部分,以更好地理解該對(duì)象的過(guò)程[17].

通過(guò)對(duì)近10年來(lái)航天型號(hào)軟件在軌、在研以及第三方評(píng)測(cè)中軟件缺陷的機(jī)理、缺陷查找過(guò)程、缺陷暴露過(guò)程以及缺陷引發(fā)后果的研究,提出了場(chǎng)景分析法、時(shí)序分析法、假想故障追源法、答疑解惑分析法等十種主要的代碼邏輯分析方法,分別予以闡述.

1.1 場(chǎng)景分析法

軟件系統(tǒng)的執(zhí)行過(guò)程可看作是大量場(chǎng)景的有序序列[18].

針對(duì)特定的軟件功能,結(jié)合軟件的運(yùn)行時(shí)序及運(yùn)行狀態(tài),構(gòu)造不同的軟件運(yùn)行場(chǎng)景,進(jìn)行針對(duì)特定場(chǎng)景的軟件運(yùn)行狀態(tài)與邏輯分析.

通過(guò)此法,重點(diǎn)確認(rèn)針對(duì)各種可能的運(yùn)行場(chǎng)景,軟件是否均能達(dá)到設(shè)計(jì)預(yù)期;針對(duì)特定場(chǎng)景,是否存在設(shè)計(jì)失效、甚至進(jìn)而引發(fā)嚴(yán)重的不良后果.

實(shí)例說(shuō)明如下:

某單機(jī)采用雙機(jī)冷備份,設(shè)計(jì)了如下自主故障診斷及處理策略:

如果診斷到主份連續(xù)故障20 s,則臨時(shí)切換至備份(主份斷電、備份加電),2 s 后再切換回主份(主份加電、備份斷電).

切換回主份后,如果診斷到主份設(shè)備仍然故障,則當(dāng)連續(xù)故障達(dá)到100 s 則永久切換至備份.

針對(duì)上述設(shè)計(jì),需要構(gòu)造如下場(chǎng)景,并對(duì)相關(guān)代碼邏輯進(jìn)行分析:

場(chǎng)景1.臨時(shí)主備切換之后,主份恢復(fù)正常(默認(rèn)備份正常).

場(chǎng)景2.臨時(shí)主備切換之后,主份仍然故障(默認(rèn)備份正常).

經(jīng)場(chǎng)景2 分析發(fā)現(xiàn),由于主備故障診斷共用了一個(gè)連續(xù)故障計(jì)時(shí)變量,當(dāng)主份故障20 s 臨時(shí)切換至備份期間,由于備份正常,導(dǎo)致連續(xù)故障計(jì)時(shí)變量被清零,則切換回主份后,20 s 后會(huì)再次執(zhí)行臨時(shí)切換備份處理.即,在場(chǎng)景2 下,軟件會(huì)周期性地執(zhí)行主備切換,這顯然違背了設(shè)計(jì)預(yù)期.按照設(shè)計(jì)預(yù)期,如果主份持續(xù)故障,則100 s 后應(yīng)執(zhí)行永久切備份處理.

上述設(shè)計(jì)缺陷,如果僅做場(chǎng)景一分析,是無(wú)法檢出的;如果分析過(guò)程中,未考慮備份狀態(tài)對(duì)軟件運(yùn)行狀態(tài)的影響,也無(wú)法檢出.

1.2 時(shí)序分析法

航天器實(shí)際上是一個(gè)分布的、網(wǎng)絡(luò)化的嵌入式系統(tǒng),在這個(gè)系統(tǒng)中各個(gè)單機(jī)采用相同或不同的中央處理單元(CPU)及編程語(yǔ)言,彼此之間通過(guò)各種串口、并口或總線,采用中斷或查詢方式進(jìn)行通訊[19],這就要求彼此之間的通訊時(shí)序必須匹配良好,否則將導(dǎo)致通訊失敗,影響航天器的正常運(yùn)行.

時(shí)序分析法,重點(diǎn)針對(duì)航天器系統(tǒng)中各個(gè)單機(jī)之間的通訊時(shí)序匹配性開展分析.至于單機(jī)內(nèi)部的運(yùn)行時(shí)序,一般可以通過(guò)變量分析以及代碼邏輯分析中的場(chǎng)景分析法等來(lái)確認(rèn).

實(shí)例說(shuō)明如下:

軟件通過(guò)422 串口與上位機(jī)通訊,接收上位機(jī)指令,并回復(fù)應(yīng)答數(shù)據(jù).

為確認(rèn)軟件設(shè)計(jì)是否滿足上述通訊需求,應(yīng)重點(diǎn)做如下時(shí)序分析:

(1)接收時(shí)序分析:接收的及時(shí)性必須保證,否則導(dǎo)致接收丟字符.

(2)應(yīng)答時(shí)序分析:應(yīng)答的及時(shí)性必須保證,否則影響上位機(jī)軟件接收應(yīng)答數(shù)據(jù).

根據(jù)上述分析,代碼審查時(shí)重點(diǎn)關(guān)注如下時(shí)序相關(guān)設(shè)計(jì):

(1)串口中斷的處理時(shí)間:如果一個(gè)字符的接收/發(fā)送觸發(fā)一次串口中斷,則串口中斷的設(shè)計(jì)必須簡(jiǎn)捷,即,中斷處理時(shí)間不能過(guò)長(zhǎng),否則,將不能及時(shí)接收/發(fā)送下一個(gè)字符.

(2)高優(yōu)先級(jí)中斷的處理時(shí)間:如果有比串口中斷更高優(yōu)先級(jí)的中斷,則高優(yōu)先級(jí)中斷的處理時(shí)間必須嚴(yán)格控制,避免影響串口中斷響應(yīng)及處理的及時(shí)性.

(3)關(guān)中斷時(shí)間:如果軟件中采取了關(guān)中斷保護(hù)設(shè)計(jì),則關(guān)中斷的時(shí)間必須嚴(yán)格控制,避免影響串口中斷響應(yīng)及處理的及時(shí)性.

1.3 假想故障追源法

針對(duì)軟件中的某些特定設(shè)計(jì),需要建立假想故障,并追蹤溯源,分析代碼設(shè)計(jì)是否存在觸發(fā)假想故障的源頭,如果存在,則為潛在設(shè)計(jì)缺陷.

以常見的while 循環(huán)設(shè)計(jì)為例,建立假想故障為while 死循環(huán),分析代碼設(shè)計(jì)上是否存在觸發(fā)while 死循環(huán)故障的源頭.此類缺陷較多,實(shí)例說(shuō)明如下:

實(shí)例1.當(dāng)軟件依賴于特定的硬件狀態(tài)條件退出while 循環(huán)時(shí),如果硬件狀態(tài)始終不具備,則導(dǎo)致while死循環(huán).

實(shí)例2.依賴于計(jì)數(shù)條件退出while 循環(huán)時(shí),如果計(jì)數(shù)條件被破壞導(dǎo)致計(jì)數(shù)無(wú)法累加,則因計(jì)數(shù)條件始終不滿足而導(dǎo)致while 死循環(huán).

1.4 答疑解惑分析法

代碼中總是會(huì)或多或少地存在一些令人困惑的設(shè)計(jì)細(xì)節(jié),這通常是由于需求描述的顆粒度限制所導(dǎo)致的,這些令人困惑的設(shè)計(jì)細(xì)節(jié)就是答疑解惑分析法的分析對(duì)象,分析目標(biāo)就是實(shí)現(xiàn)對(duì)這些設(shè)計(jì)細(xì)節(jié)的答疑解惑,即,理清代碼設(shè)計(jì)的理由和依據(jù),以確認(rèn)代碼設(shè)計(jì)的正確性.如果通過(guò)分析無(wú)法解除疑惑,則通常在這些設(shè)計(jì)細(xì)節(jié)中是存在潛在的設(shè)計(jì)缺陷的.

實(shí)例說(shuō)明如下:

軟件每秒給下位機(jī)軟件發(fā)同步校時(shí)指令,針對(duì)指令中的同步校時(shí)時(shí)間Time.sync,代碼設(shè)計(jì)如下:

Time.sync=Time.Star_Orbit- 0.02+(Time.DeltaT*1.0e-6);

針對(duì)同步校時(shí)時(shí)間Time.sync,需求中并未明確說(shuō)明其計(jì)算方法.通過(guò)代碼分析發(fā)現(xiàn),Time.Star_Orbit是當(dāng)前控制周期起始時(shí)刻,操作“Time.Star_Orbit-0.02”,將時(shí)間校正到上一控制周期TCTM 任務(wù)起始時(shí)刻.而操作“+(Time.DeltaT* 1.0e-6)”中,變量Time.DeltaT是上一次(也就是上一秒)同步校時(shí)指令發(fā)出時(shí)刻相對(duì)于指令發(fā)出所在控制周期的TCTM 任務(wù)起始時(shí)刻的時(shí)間偏差.綜上,這是一個(gè)很令人困惑的設(shè)計(jì),困惑點(diǎn)如下:

(1)參與Time.sync計(jì)算的Time.Star_Orbit-0.02與Time.DeltaT* 1.0e-6的時(shí)間基準(zhǔn)不同,導(dǎo)致計(jì)算結(jié)果的物理意義不明確.

(2)為什么不是將Time.sync調(diào)整到同步校時(shí)指令發(fā)出時(shí)刻呢?

經(jīng)與開發(fā)方溝通反饋,代碼修改如下:

Time.sync=Time.Star_Orbit+0.65;

修改后的代碼中,0.65是根據(jù)任務(wù)調(diào)度時(shí)序計(jì)算得到的同步校時(shí)指令發(fā)出時(shí)刻相對(duì)于當(dāng)前控制周期起始時(shí)刻的時(shí)間偏差,即,Time.sync為同步校時(shí)指令發(fā)出時(shí)刻.至此,疑惑解除,分析通過(guò).

1.5 類似設(shè)計(jì)對(duì)比法

代碼中經(jīng)常會(huì)存在一些類似設(shè)計(jì),比如,針對(duì)同類多個(gè)單機(jī)的操作、不同場(chǎng)景下的同類處理,等.針對(duì)此類設(shè)計(jì),開發(fā)人員通常采用代碼克隆的方式實(shí)現(xiàn).

所謂代碼克隆,是指軟件開發(fā)中由于復(fù)制、粘貼引起的重復(fù)代碼現(xiàn)象.研究指出,一般商業(yè)軟件中存在5%～20%的重復(fù)代碼[20].

針對(duì)代碼中的類似設(shè)計(jì),可采用類似設(shè)計(jì)對(duì)比法開展分析.即,針對(duì)類似設(shè)計(jì)代碼進(jìn)行比對(duì),查看類似設(shè)計(jì)之間是否存在差異,分析差異之處的設(shè)計(jì)正確性.

通常,通過(guò)簡(jiǎn)單的比對(duì),可以找出因代碼克隆時(shí)的疏忽而導(dǎo)致的設(shè)計(jì)缺陷.但是,也有些較深層次的設(shè)計(jì)缺陷,需要通過(guò)更審慎的分析才可發(fā)現(xiàn).

實(shí)例說(shuō)明如下:

軟件在task4中根據(jù)標(biāo)志hk6start啟動(dòng)HK6 相關(guān)處理,正常結(jié)束HK6 處理時(shí),會(huì)清標(biāo)志hk6start、并發(fā)TC_HK6 指令停止HK6 處理.但是,軟件在處理某故障時(shí)存在僅清標(biāo)志hk6start、未發(fā)TC_HK6 指令的設(shè)計(jì),與正常結(jié)束HK6 處理的流程不一致.

類似設(shè)計(jì)對(duì)比法的應(yīng)用,主要有如下兩個(gè)方面:

(1)通過(guò)比對(duì)發(fā)現(xiàn)類似設(shè)計(jì)上的差異,通過(guò)差異分析查找缺陷.

(2)某處類似設(shè)計(jì)中檢出缺陷后,應(yīng)繼續(xù)分析其它類似設(shè)計(jì)處是否存在類似缺陷.

1.6 相關(guān)性(影響域)分析法

有些情況下,軟件的各個(gè)功能之間存在一定的相關(guān)性,即,某一功能的實(shí)現(xiàn)方式可能會(huì)影響另一功能的實(shí)現(xiàn)結(jié)果.因此,需要開展相關(guān)性(影響域)分析.

實(shí)例說(shuō)明如下:

需求要求以變量形式定義某S 存儲(chǔ)區(qū)的地址空間,以便在軌重新分配地址空間.

軟件實(shí)現(xiàn)時(shí),以變量形式定義了S 存儲(chǔ)區(qū)的地址空間,并在實(shí)施S 區(qū)存儲(chǔ)時(shí)以變量形式訪問(wèn)地址,滿足需求.但是,在S 存儲(chǔ)區(qū)數(shù)據(jù)下卸指令處理中,軟件按照初始設(shè)置的S 存儲(chǔ)區(qū)的起始/結(jié)束(固定)地址來(lái)進(jìn)行指令參數(shù)合法性判斷,顯然,該合法性判斷設(shè)計(jì)與“在軌重新分配S 區(qū)地址空間”的需求是不符的.

1.7 星地控制匹配分析法

衛(wèi)星在軌運(yùn)行具有高度自主性,同時(shí)以遙測(cè)的形式,將其在軌運(yùn)行狀態(tài)打包發(fā)回地面,供地面監(jiān)控,必要時(shí),地面通過(guò)遙控指令等方式對(duì)衛(wèi)星實(shí)施控制.但是,從在軌數(shù)據(jù)打包、到數(shù)據(jù)發(fā)回地面、至地面完成解析與數(shù)據(jù)判讀,總是會(huì)有或多或少的時(shí)延,這也就導(dǎo)致地面可能在并未實(shí)時(shí)獲知衛(wèi)星在軌運(yùn)行狀態(tài)的情況下對(duì)衛(wèi)星進(jìn)行了遙控控制,從而可能導(dǎo)致衛(wèi)星自主控制與地面遙控控制之間發(fā)生相互間的干擾、覆蓋等不匹配行為.

星地控制匹配分析法,針對(duì)星地控制的匹配性開展分析,其分析對(duì)象一般是星上自主和地面遙控兩種手段均可控制的功能,分析兩種控制手段之間是否存在相互干擾、覆蓋等不匹配行為并造成了不良后果.

目前,針對(duì)同時(shí)具備星地兩種控制手段的功能,通常的設(shè)計(jì)準(zhǔn)則是地面優(yōu)先,即,地面遙控可以覆蓋星上自主控制,反之不行.但是,也存在個(gè)例.比如模式轉(zhuǎn)換,如果在星上自主轉(zhuǎn)模式M 之后,地面再次發(fā)遙控指令轉(zhuǎn)模式M,則星上軟件一般應(yīng)屏蔽地面發(fā)的遙控轉(zhuǎn)模式M 指令,否則,轉(zhuǎn)模式時(shí)的初始化操作會(huì)干擾星上正常的自主模式控制過(guò)程.

實(shí)例說(shuō)明如下:

某部件控制指令,有星上自主發(fā)出和地面遙控發(fā)出兩種手段.

軟件在task1中根據(jù)當(dāng)前運(yùn)行狀態(tài)自主設(shè)定控制參數(shù)、并發(fā)送該指令.

軟件在task2中接收地面遙控指令,其中的控制參數(shù)由地面設(shè)定.

根據(jù)上述設(shè)計(jì),軟件形成如下運(yùn)行時(shí)序:task2 接收遙控指令→;task1 自主設(shè)置指令→;task1 發(fā)送指令.可見,遙控指令必定被自主指令所覆蓋,從而導(dǎo)致遙控失效.

1.8 接口軟件狀態(tài)分析法

有些情況下,被測(cè)軟件會(huì)采集與其接口的軟件狀態(tài),并將該狀態(tài)作為特定處理的判定條件,即,接口軟件的狀態(tài)會(huì)影響被測(cè)軟件的運(yùn)行狀態(tài),而這通常是軟件設(shè)計(jì)師容易忽視的地方.測(cè)試過(guò)程中,忽略接口軟件狀態(tài)對(duì)被測(cè)軟件狀態(tài)的影響,或者對(duì)接口軟件狀態(tài)未仔細(xì)探究而采取了想當(dāng)然的心態(tài),都容易導(dǎo)致被測(cè)軟件相關(guān)設(shè)計(jì)缺陷被遺漏.

當(dāng)接口軟件狀態(tài)影響到被測(cè)軟件的運(yùn)行狀態(tài)時(shí),需要分析各種可能的接口軟件狀態(tài)對(duì)被測(cè)軟件的影響,以確認(rèn)被測(cè)軟件在相關(guān)設(shè)計(jì)上的正確性.

實(shí)例說(shuō)明如下:

某故障處理策略:陀螺連續(xù)故障計(jì)數(shù)達(dá)到100,則給陀螺斷電10 個(gè)控制周期,然后再給陀螺加電.

但是,由于陀螺斷電期間,被測(cè)軟件采集到的陀螺通訊狀態(tài)為異常,導(dǎo)致連續(xù)故障計(jì)數(shù)不變(注:通訊正常情況下,才進(jìn)行診斷并操作連續(xù)故障計(jì)數(shù)),從而導(dǎo)致軟件重復(fù)執(zhí)行連續(xù)故障計(jì)數(shù)100的處理分支,與設(shè)計(jì)預(yù)期不符.

1.9 隱含需求分析法

隱含需求通常指那些必須要實(shí)現(xiàn)、但是需求分析人員又沒(méi)有意識(shí)到需要把它們?cè)谛枨笠?guī)格說(shuō)明中清晰描述出來(lái)的需求.這些需求,一旦未予實(shí)現(xiàn),通常會(huì)引發(fā)一定的不良后果.

實(shí)例說(shuō)明如下:

故障診斷及處理功能中,如果采取了故障后給設(shè)備斷電、再加電的處理策略,則需要考慮持續(xù)故障情況下,是否會(huì)導(dǎo)致設(shè)備重復(fù)斷電、加電,這種持續(xù)故障情況下的設(shè)備重復(fù)斷電加電通常是設(shè)計(jì)上所不期望的.但是,通常的需求規(guī)格說(shuō)明中僅會(huì)提出故障后給設(shè)備斷電再加電的需求,而不會(huì)明確說(shuō)明持續(xù)故障后的處理需求.因此,持續(xù)故障情況下的處理策略就屬于隱含需求,需要明確需求后對(duì)相關(guān)處理開展分析檢查.

隱含需求通常涉及如下方面:

(1)遵循的標(biāo)準(zhǔn)、芯片手冊(cè):比如,標(biāo)準(zhǔn)及芯片手冊(cè)中的操作規(guī)范、時(shí)序要求等.

(2)軟件接口交互需求:比如,交互雙方的接收與應(yīng)答響應(yīng)等.

(3)硬件接口交互需求:比如,查詢、等待硬件狀態(tài)的延時(shí)涉及等.

(4)可靠性安全性需求:比如,指令合法性校驗(yàn)、重要數(shù)據(jù)三取二等.

(5)功能級(jí)需求:最為復(fù)雜的一類隱含需求,需要結(jié)合具體功能做具體分析.

1.10 需求/設(shè)計(jì)合理性分析法

在代碼審查過(guò)程中,針對(duì)需求和設(shè)計(jì),都需要做合理性分析,避免盲從.

有許多需求/設(shè)計(jì)不合理的實(shí)例:

實(shí)例1.參數(shù)(變量)有初值,同時(shí)支持上注修改.但是,在上注異常時(shí)軟件將參數(shù)清零、而非恢復(fù)為初值或保留之前的上注值.——設(shè)計(jì)不合理.

實(shí)例2.協(xié)議規(guī)定遙測(cè)中的CAN 重新初始化標(biāo)志占用1 bit,A、B 總線共用,發(fā)生一次CANA 或CANB重新初始化,則遙測(cè)位翻轉(zhuǎn)一次.如果在1 個(gè)遙測(cè)輪詢周期內(nèi)A、B 總線均重新初始化,則遙測(cè)結(jié)果與A、B 總線均未重新初始化的遙測(cè)結(jié)果是一樣的,導(dǎo)致遙測(cè)設(shè)計(jì)失效.——需求不合理.

實(shí)例3.AD 采集過(guò)程中,如果軟件采用了連續(xù)采集多次取均值的設(shè)計(jì),則連續(xù)采集過(guò)程中,每次采集均應(yīng)重新啟動(dòng)AD 轉(zhuǎn)換,否則會(huì)導(dǎo)致連續(xù)采集設(shè)計(jì)無(wú)意義.——設(shè)計(jì)不合理.

2 應(yīng)用分析

2.1 應(yīng)用說(shuō)明

作為代碼審查的重點(diǎn)內(nèi)容之一,代碼邏輯分析側(cè)重于功能級(jí)的代碼邏輯的分析與確認(rèn).工程應(yīng)用中,應(yīng)針對(duì)代碼邏輯分析與檢查單、變量分析[21,22]、中斷訪問(wèn)沖突分析[23,24]等其它代碼審查重點(diǎn)內(nèi)容開展綜合性分析與確認(rèn),以期達(dá)到最佳的工程應(yīng)用效果.

2.2 應(yīng)用數(shù)據(jù)分析

根據(jù)中國(guó)空間技術(shù)研究院軟件產(chǎn)品保證中心的統(tǒng)計(jì)數(shù)據(jù),近半年內(nèi),開展代碼邏輯分析所檢測(cè)出的缺陷占比為23%.

選取近期結(jié)束的5 個(gè)項(xiàng)目,對(duì)綜合開展代碼邏輯分析、檢查單確認(rèn)、變量分析、中斷訪問(wèn)沖突分析后的代碼審查發(fā)現(xiàn)缺陷占比進(jìn)行統(tǒng)計(jì),數(shù)據(jù)如表1.

表1 綜合應(yīng)用數(shù)據(jù)統(tǒng)計(jì)

數(shù)據(jù)來(lái)源說(shuō)明:

(1)統(tǒng)計(jì)數(shù)據(jù)取自中國(guó)空間技術(shù)研究院軟件產(chǎn)保中心第三方評(píng)測(cè)數(shù)據(jù)庫(kù).

(2)所選項(xiàng)目均為星載嵌入式軟件第三方評(píng)測(cè)項(xiàng)目、且提交第三方評(píng)測(cè)之前均已完成開發(fā)方自測(cè)試.

(3)僅統(tǒng)計(jì)已做修改程序處理的缺陷數(shù).

(4)統(tǒng)計(jì)數(shù)據(jù)不含注釋錯(cuò)誤、多余物等低級(jí)缺陷.

通過(guò)應(yīng)用數(shù)據(jù)可以看出,綜合開展代碼邏輯分析、檢查單確認(rèn)、變量分析、中斷訪問(wèn)沖突分析后,代碼審查發(fā)現(xiàn)缺陷占比明顯高于業(yè)界公認(rèn)的30～70%,應(yīng)用效果良好.

2.3 應(yīng)用意義分析

依托具體方法,開展綜合性代碼審查,產(chǎn)生的意義如下:

(1)使代碼審查過(guò)程有法可依、有章可循,有助于提升人的能力,縮小人與人之間測(cè)試質(zhì)量的差異,實(shí)現(xiàn)整體測(cè)試能力的提升.

(2)為代碼設(shè)計(jì)提供參考,編碼階段借鑒這些方法,有助于及早規(guī)避軟件缺陷,實(shí)現(xiàn)缺陷早期預(yù)防.

(3)為測(cè)試設(shè)計(jì)提供參考,有利于提高動(dòng)態(tài)測(cè)試的充分性.

(4)為缺陷自動(dòng)化檢測(cè)工具研發(fā)提供參考,有助于促進(jìn)工具能力的提升.

(5)為缺陷自動(dòng)化檢測(cè)工具的推廣應(yīng)用提供了參照目標(biāo),工具的能力必須超越人,才能真正取代人.

2.4 不同測(cè)試手段的對(duì)比分析

結(jié)合多年的軟件測(cè)試工程實(shí)踐,開展了靜態(tài)分析工具、人工代碼審查、動(dòng)態(tài)測(cè)試手段的對(duì)比分析如表2.

表2 不同測(cè)試手段對(duì)比分析

綜上,各種測(cè)試手段各有千秋,在工程上,尤其是對(duì)于高可信高可靠航天嵌入式軟件而言,應(yīng)該多種手段并舉,充分發(fā)揮各自的優(yōu)勢(shì),形成優(yōu)勢(shì)互補(bǔ),共同促進(jìn)軟件質(zhì)量的提升.

2.5 工程適用性說(shuō)明

綜合以上分析結(jié)果,總結(jié)代碼審查的工程適用性如下:

(1)在測(cè)試環(huán)境受限、測(cè)試工期有限等不適宜開展動(dòng)態(tài)測(cè)試的情況下,由中-高級(jí)測(cè)試人員開展代碼審查.比如,型號(hào)軟件的初樣研制階段.

(2)在具有高可信高可靠要求、且規(guī)模允許的軟件測(cè)試中,必須開展代碼審查.

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

隨著自動(dòng)化測(cè)試以及工具檢測(cè)相關(guān)研究的熱度的提升,基于人工的代碼審查技術(shù)的研究及其在工程實(shí)踐中的推廣應(yīng)用都陷入了瓶頸.但是,在當(dāng)前自動(dòng)化測(cè)試以及工具檢測(cè)能力都不足以保證航天嵌入式軟件質(zhì)量的前提下,研究并應(yīng)用人工代碼審查方法仍然是必要的.而且,無(wú)論是工具的研發(fā),還是工具能力的提升,都需要一定的出發(fā)點(diǎn)和參照點(diǎn),而人的分析方法、分析范圍以及分析能力的提升,都為工具研發(fā)及能力提升提供了一個(gè)很好的參照,這也是當(dāng)前條件下,堅(jiān)持人工代碼審查方法研究及方法推廣的意義所在.

隨著軟件在航天器中的作用和地位越來(lái)越突出,軟件的可信性直接關(guān)系到航天任務(wù)的成敗,不存在一種單獨(dú)的方法能夠完全保證軟件可信[19].NASA 從多年的軟件工程中吸取的一個(gè)重要教訓(xùn)是沒(méi)有一個(gè)單一的解決方法能夠解決所有問(wèn)題[25].因此,為滿足航天嵌入式軟件的可信性要求,需要廣大的工程技術(shù)人員在軟件研制各階段綜合采用各種技術(shù)和方法.只有這樣,才能將各種技術(shù)和方法的研究與應(yīng)用不斷地推向新的高度.

本文的研究成果對(duì)于軟件研制、動(dòng)態(tài)測(cè)試、測(cè)試工具研發(fā)均有一定的參考價(jià)值.后續(xù)將重點(diǎn)研究如何將研究成果推廣至工具研發(fā),以期最大限度地提升缺陷自動(dòng)化檢測(cè)能力,促進(jìn)多種測(cè)試手段的互補(bǔ)與并舉.