航天嵌入式軟件隱含需求分析與實(shí)踐

左萬娟,王小麗,黃 晨,董 燕

(1.北京軒宇信息技術(shù)有限公司 軟件測試部,北京 100190; 2.北京控制工程研究所 軟件檢測站,北京 100190)

隨著軟件定義衛(wèi)星設(shè)計理念的提出,航天軟件的規(guī)模日趨壯大,軟件在航天器中所承載的作用愈顯突出。然而,航天器在軌運(yùn)行期間的軟件問題也不斷顯現(xiàn),究其根源,由需求分析缺陷所導(dǎo)致的軟件缺陷不容忽視。

根據(jù)中國空間技術(shù)研究院軟件產(chǎn)品保證中心的統(tǒng)計數(shù)據(jù),航天器軟件第三方評測階段所發(fā)現(xiàn)的軟件缺陷中,與需求缺陷緊密相關(guān)的缺陷占比達(dá)50%以上,其余缺陷也均與需求缺陷存在或多或少的關(guān)聯(lián)。

著名航天軟件專家Nancy Leveson總結(jié)軟件在航天任務(wù)事故中的作用時曾言:“幾乎與軟件相關(guān)的航空航天事故都與軟件需求缺陷以及對軟件需求的錯誤理解有關(guān)?！盵1]有40%的軟件項目的失敗來自于軟件需求的模糊[2]。

無論是軟件需求缺陷還是對軟件需求的錯誤理解,其根源都在于需求分析。如何把軟件需求分析切實(shí)做到位,業(yè)內(nèi)開展了很多研究。但是,大多數(shù)的研究都基于項目開發(fā)的角度,著眼于軟件開發(fā)需求的分析[2-7],基于測試角度的需求分析研究則較少。

開發(fā)需求分析重點(diǎn)解決的是需求從無到有的問題。而基于測試角度的需求分析,則是在已有的顯式需求和代碼基礎(chǔ)上,通過隱含需求分析,實(shí)現(xiàn)對顯式需求和代碼的完善與修正。

本文基于軟件測試的角度,聚焦隱含需求分析研究,著重從白盒測試的角度,開展航天嵌入式軟件隱含需求分析研究,其研究成果不僅適用于軟件測試方,而且對軟件項目相關(guān)方同樣具有參考價值,有利于在軟件研制的早期階段規(guī)避因需求缺陷而引入的不良后果。

1 隱含需求分析的重要性

隱含需求,又稱隱式需求,指未予以明確說明的軟件必須實(shí)現(xiàn)的需求。這部分需求一旦未予實(shí)現(xiàn)或?qū)崿F(xiàn)錯誤,通常都會帶來嚴(yán)重的不良后果,導(dǎo)致軟件的某些特性不滿足用戶要求,甚至軟件無法正常運(yùn)行,進(jìn)而引發(fā)客戶的強(qiáng)烈不滿。隱含需求是培養(yǎng)客戶忠誠度的關(guān)鍵內(nèi)容[8]。無論是軟件項目研制相關(guān)方還是軟件測試方,均應(yīng)對這些潛在的需求予以分析。工程上,測試方可以對項目研制相關(guān)方的需求分析缺陷給予有效的完善與更正,規(guī)避因隱含需求未實(shí)現(xiàn)或?qū)崿F(xiàn)錯誤而引入的不良后果,確保軟件質(zhì)量。

隱含需求分析的目的是將隱含需求顯性化。隱含需求顯性化可以帶來以下好處:

① 接受專家評審,對相關(guān)需求合理性做出判定,規(guī)避不合理需求。

② 正確指導(dǎo)編碼和測試。

③ 有效避免測試遺漏。

2 隱含需求產(chǎn)生原因及常見分析方法

通過工程實(shí)踐分析與總結(jié),綜合已有研究成果,隱含需求產(chǎn)生的原因主要有:

① 用戶需求不明確,用戶對自身需求比較模糊[9]。

② 分析疏漏,需求分析工作不夠完善[10]。

③ 分析能力不足,需求分析人員對系統(tǒng)缺乏全面認(rèn)識[10],或?qū)π录夹g(shù)缺乏全面了解[11]。

④ 心理默認(rèn),心理假設(shè)該需求為默認(rèn)需求,認(rèn)為無須明確說明。

⑤ 顆粒度不當(dāng),需求分解和細(xì)化程度不夠。

業(yè)內(nèi)針對隱含需求分析方法也進(jìn)行了大量研究,提出的隱含需求分析方法包括但不限于:用戶訪談[5]、情節(jié)串聯(lián)[5]、用戶故事[6]、問題驅(qū)動的需求誘導(dǎo)[7]、實(shí)地觀察[12]、情景調(diào)查[12]等。從適用性角度而言,這些方法更適用于非嵌入式軟件研發(fā)過程及其黑盒測試場景。

3 航天嵌入式軟件隱含需求分析方法

基于對已有研究成果的理解與思考,結(jié)合多年的航天工程實(shí)踐,從測試角度出發(fā),對航天嵌入式軟件的隱含需求分析開展了有針對性的研究與總結(jié),提出了新的分析方法和思路。

3.1 概述

白盒測試是航天嵌入式軟件的主要測試技術(shù)手段之一,靜態(tài)測試階段要對代碼進(jìn)行逐行的人工審查、分析和確認(rèn)。借助白盒測試過程中對代碼設(shè)計的充分理解與分析,結(jié)合多年工程實(shí)踐,研究構(gòu)建了航天嵌入式軟件隱含需求分析框圖,如圖1所示。

圖1 航天嵌入式軟件隱含需求分析框圖

如圖1所示,針對航天嵌入式軟件,從軟件測試方的角度出發(fā),以需求和代碼為輸入,隱含需求分析著重于3個方面:需求顆粒度分析、代碼設(shè)計無依據(jù)分析和引申推導(dǎo)分析。

通過分析所得到的隱含需求,經(jīng)過同行專家和項目總體的評審[13]之后,一方面用于完善當(dāng)前項目的需求、編碼及測試,另一方面可將其納入隱含需求庫,用于指導(dǎo)后續(xù)項目的相關(guān)工作。

為方便后續(xù)管理及應(yīng)用,建議從測試類型[13]角度對納入隱含需求庫的隱含需求進(jìn)行分類、收集和整理。

3.2 需求顆粒度分析

結(jié)合代碼設(shè)計,對比分析顯式需求中的需求描述顆粒度是否過于粗大或是否存在疏漏,疏漏部分即為隱含需求,與項目相關(guān)方溝通確認(rèn)后,應(yīng)在測試需求中予以明確,并由項目相關(guān)方完善需求,必要時應(yīng)完善代碼設(shè)計。

以航天軟件常見的三取二需求為例,對需求顆粒度分析過程的說明如下。

首先,分析顯式需求。發(fā)現(xiàn)顯式需求中僅規(guī)定對某些重要參數(shù)做三取二處理,但是未規(guī)定具體處理策略。

然后,分析代碼設(shè)計。確認(rèn)代碼實(shí)現(xiàn)策略為:任意兩區(qū)相等時,取相等兩區(qū)的數(shù)據(jù)作為三取二結(jié)果;三區(qū)均不等時,取一區(qū)的數(shù)據(jù)作為三取二結(jié)果。

進(jìn)一步分析代碼實(shí)現(xiàn)策略的合理性,發(fā)現(xiàn)“三區(qū)均不等時取一區(qū)數(shù)據(jù)”的策略不合理,因?yàn)槿齾^(qū)均不等狀態(tài)下,無法確認(rèn)一區(qū)數(shù)據(jù)是否有效。

針對上述分析結(jié)果,與項目相關(guān)方進(jìn)行溝通,最終確定處理策略為:任意兩區(qū)相等時,取相等兩區(qū)的數(shù)據(jù);三區(qū)均不等時,進(jìn)行三區(qū)數(shù)據(jù)按位三取二。

處理策略確認(rèn)之后,項目相關(guān)方負(fù)責(zé)完善需求、修正代碼設(shè)計,測試方負(fù)責(zé)按照既定需求完成相關(guān)測試。

3.3 代碼設(shè)計無依據(jù)分析

通過對代碼的逐行分析與確認(rèn),對比顯式需求,識別代碼中的無依據(jù)設(shè)計。首先分析無依據(jù)設(shè)計的實(shí)現(xiàn)結(jié)果。然后與項目相關(guān)方溝通該部分設(shè)計的合理性和必要性,確認(rèn)無依據(jù)設(shè)計是屬于需求描述遺漏還是屬于代碼多余設(shè)計問題,如屬于需求遺漏,則歸為隱含需求,在測試需求中予以明確,并由項目相關(guān)方修改需求;如屬于多余設(shè)計,則由項目相關(guān)方修改代碼、刪除多余設(shè)計;如經(jīng)溝通后確認(rèn)無依據(jù)設(shè)計必要但存在不合理性,則歸為隱含需求,由項目相關(guān)方修改需求和代碼。代碼設(shè)計無依據(jù)分析示意圖如圖2所示。

圖2 代碼設(shè)計無依據(jù)分析示意圖

其中,分析無依據(jù)設(shè)計的實(shí)現(xiàn)結(jié)果是非常有必要的,這可以避免測試方在與項目相關(guān)方溝通過程中的盲目遵從性,避免單純依賴于項目相關(guān)方獲取無依據(jù)設(shè)計屬性(需求描述遺漏、代碼多余設(shè)計)的判定結(jié)果,從而充分發(fā)揮白盒測試優(yōu)勢、獲得最優(yōu)的分析結(jié)果。

以某指令處理為例,對代碼設(shè)計無依據(jù)分析過程的說明如下。

在代碼的逐行分析與確認(rèn)中,通過與顯式需求的對比,發(fā)現(xiàn)代碼中存在無依據(jù)的控制指令輸出,即控制指令輸出相關(guān)的代碼沒有對應(yīng)的需求。

與項目相關(guān)方溝通上述無依據(jù)設(shè)計的屬性(需求描述遺漏、代碼多余設(shè)計),由項目相關(guān)方確認(rèn),由于項目研發(fā)過程中的需求更正,這部分代碼對應(yīng)了新增需求,但是新增需求未及時補(bǔ)充至顯式需求,導(dǎo)致出現(xiàn)無依據(jù)代碼。

需求確認(rèn)后,由項目相關(guān)方負(fù)責(zé)修正需求,測試方負(fù)責(zé)按照既定需求完成相關(guān)測試。

3.4 引申推導(dǎo)分析

以顯式需求和代碼設(shè)計為出發(fā)點(diǎn),通過對代碼的逐行分析與確認(rèn),理解代碼設(shè)計,結(jié)合軟件應(yīng)用背景,分析需求及代碼設(shè)計的合理性、全面性,引申推導(dǎo)出可能的隱含需求。這種引申推導(dǎo)出的隱含需求可能是對某一顯式需求的更正與完善,也可能是為支持某顯式需求而必然存在的需求。引申推導(dǎo)分析示意圖如圖3所示。

圖3 引申推導(dǎo)分析示意圖

引申推導(dǎo)分析是在顯式需求和代碼設(shè)計基礎(chǔ)上的更進(jìn)一步的合理性和全面性分析,通過分析現(xiàn)有需求和代碼引申得出的隱含需求主要有2類,即完善性隱含需求和支持性隱含需求。

需要注意的是,這種引申出來的需求,可能會與原有的顯式需求自相矛盾,因此需要開展需求匹配性分析,并在必要時加以修正。

對于主備單機(jī)+冷備份的硬件架構(gòu),針對主份故障后斷電再加電(即主份斷電備份加電、一定時間后再備份斷電主份加電)的顯式需求,引申出可能存在的主份持續(xù)故障狀態(tài),需要溝通確認(rèn)主份持續(xù)故障的處理策略,并完善需求。針對此類極端故障,通常要首先確保不會發(fā)生持續(xù)反復(fù)的主份斷電再加電,其次要明確永久切備份的時機(jī)和條件。由此引申出的需求屬于完善性隱含需求。

對于主循環(huán)+中斷的軟件架構(gòu),如果主循環(huán)或中斷的處理時間過長,可能會影響到某些處理的及時性,從而需要結(jié)合相關(guān)處理的及時性要求,引申推導(dǎo)出對主循環(huán)及中斷處理時間的限制性隱含需求,并溝通確認(rèn)相應(yīng)的性能指標(biāo)。由此引申出的需求是為支持其他需求而必然存在的需求,屬于支持性隱含需求。

下面以航天軟件中常見的指令重發(fā)機(jī)制為例,對引申推導(dǎo)分析過程進(jìn)行說明。

① 需求規(guī)定:指令發(fā)出后,未收到正確反饋,則重發(fā)指令。

② 代碼實(shí)現(xiàn):每發(fā)出一條指令,都要查收反饋,未收到正確反饋,則重發(fā)指令。

分析需求的合理性和全面性,引申出針對指令重發(fā)后仍然得不到正確反饋的情況,缺乏明確需求。

分析代碼設(shè)計的合理性和全面性,引申出針對指令重發(fā)后仍然未得到正確反饋的情況,代碼實(shí)現(xiàn)為繼續(xù)執(zhí)行指令重發(fā),即針對指令發(fā)出后始終得不到正確反饋的情況,代碼會不停地執(zhí)行指令重發(fā)。

與項目相關(guān)方溝通上述分析結(jié)果,最終確認(rèn)需求為:指令發(fā)出后,未收到正確反饋,則重發(fā)指令。上述指令重發(fā)機(jī)制僅執(zhí)行一次。經(jīng)確認(rèn),上述需求與原需求之間不存在矛盾之處。

需求確認(rèn)后,由項目相關(guān)方負(fù)責(zé)完善需求并修正代碼,測試方負(fù)責(zé)按照既定需求完成相關(guān)測試。

3.5 小結(jié)

與非嵌入式軟件不同,航天嵌入式軟件很少具備人機(jī)界面,因此與人機(jī)界面相關(guān)的隱含需求分析方法未予闡述。

重點(diǎn)關(guān)注的3種分析方法中,需求顆粒度分析和代碼設(shè)計無依據(jù)分析的隱含需求來源相對固定,分析難度相對較小;引申推導(dǎo)分析的隱含需求來源龐雜,更依賴于人的邏輯思維能力以及領(lǐng)域知識和經(jīng)驗(yàn),分析難度相對較大。但是通過這種方法分析得出的隱含需求對軟件質(zhì)量和客戶滿意度的提升效能也最大。

在工程實(shí)踐中,3種分析方法通常并不孤立,需要結(jié)合應(yīng)用。在工程應(yīng)用中,3種分析方法都需要同時關(guān)注需求和代碼設(shè)計的合理性,這也是航天嵌入式軟件靜態(tài)測試中充分發(fā)揮人的主觀能動性的一個顯著特征。

應(yīng)充分應(yīng)用通過分析所獲取的隱含需求,具體應(yīng)用如下:

① 指導(dǎo)完善當(dāng)前項目的需求和編碼。

② 與顯式需求一起作為軟件測試設(shè)計的輸入。

③ 充實(shí)隱含需求庫,用于指導(dǎo)后續(xù)項目的需求、編碼和隱含需求分析。

4 航天嵌入式軟件典型隱含需求

隱含需求來源龐雜,需要具體問題具體分析。在多年的航天器軟件第三方評測工程實(shí)踐活動中,通過開展需求顆粒度分析、代碼設(shè)計無依據(jù)分析、引申推導(dǎo)分析,在隱含需求分析方面已經(jīng)積累了大量的成果。下面從接口、可靠性安全性、恢復(fù)性、性能、功能等不同測試類型[13]角度,給出航天嵌入式軟件的若干典型隱含需求及其相應(yīng)的分析方法。若能在研發(fā)過程的初期關(guān)注并明確相關(guān)隱含需求,不僅有利于軟件的全方位協(xié)同設(shè)計,而且也能為軟件測試設(shè)計提供指導(dǎo)。

4.1 接口隱含需求

顯式需求中,針對接口,通常能夠明確接口地址、接口方式、通信格式和內(nèi)容。但是,一些典型的接口隱含需求容易被忽略,具體說明如表1所示。

4.2 可靠性安全性隱含需求

航天嵌入式軟件通常都會適度開展可靠性安全性設(shè)計?？煽啃园踩缘湫偷碾[含需求及其首要分析方法如表2所示。

表2 可靠性安全性典型隱含需求及其首要分析方法

其中,輸入合法性校驗(yàn)相關(guān)的隱含需求分析重點(diǎn)在于校驗(yàn)的全面性;抗單粒子翻轉(zhuǎn)相關(guān)的隱含需求分析重點(diǎn)在于明確保護(hù)對象和處理策略;極端故障處理相關(guān)的隱含需求,通常是由于項目相關(guān)方未考慮到相應(yīng)的極端故障工況而導(dǎo)致的顯式需求的缺失,其分析重點(diǎn)在于明確極端故障工況及其處理策略。

4.3 恢復(fù)性隱含需求

考慮到在軌運(yùn)行環(huán)境的復(fù)雜性和軟件在軌運(yùn)行的高度自主性,通常會對航天嵌入式軟件進(jìn)行適度的恢復(fù)性設(shè)計。但是,在此過程中,經(jīng)常會因顯式需求遺漏導(dǎo)致出現(xiàn)隱含需求。恢復(fù)性典型隱含需求及其首要分析方法如表3所示。

表3 恢復(fù)性典型隱含需求及其首要分析方法

4.4 性能隱含需求

航天嵌入式軟件通常采用主循環(huán)+中斷或者多任務(wù)+中斷的軟件架構(gòu)。其中,任務(wù)處理時間通常在顯式需求中會予以明確,但是針對主循環(huán)和中斷的處理時間鮮有說明。性能典型及其首要分析方法隱含需求如表4所示。

表4 性能典型隱含需求及其首要分析方法

4.5 功能隱含需求

功能隱含需求需要結(jié)合具體功能進(jìn)行具體分析。表5給出2個典型實(shí)例的具體說明。

5 結(jié)束語

本文從軟件測試的視角,借助全代碼人工審查的白盒測試實(shí)踐,重點(diǎn)闡述了航天嵌入式軟件隱含需求分析的3種主要方法,這3種方法有助于提高測試過程中隱含需求分析的效能,既能彌補(bǔ)研發(fā)過程的不足,又能充分指導(dǎo)測試。

但是,隱含需求是客觀存在的,隱含需求分析始終是工程上的難點(diǎn),目前還沒有徹底的解決方法,需要相關(guān)科研人員在軟件研發(fā)、測試等各個環(huán)節(jié),通過隱含需求顯式化不斷地加以完善。從工程角度而言,建立行業(yè)性、領(lǐng)域性的隱含需求庫是一個值得推薦的方法,后續(xù)還可以借助人工智能手段實(shí)現(xiàn)包含隱含需求庫、共性需求庫、共性用例庫等在內(nèi)的知識庫系統(tǒng)的智能化管理與應(yīng)用,從而有效彌補(bǔ)人員的領(lǐng)域知識和經(jīng)驗(yàn)不足的問題。