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

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

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

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

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

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

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

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

1 隱含需求分析的重要性

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

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

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

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

③ 有效避免測(cè)試遺漏。

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

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

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

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

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

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

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

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

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

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

3.1 概述

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

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

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

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

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

3.2 需求顆粒度分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5 小結(jié)

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

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

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

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

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

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

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

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

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

4.1 接口隱含需求

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

4.2 可靠性安全性隱含需求

航天嵌入式軟件通常都會(huì)適度開展可靠性安全性設(shè)計(jì)。可靠性安全性典型的隱含需求及其首要分析方法如表2所示。

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

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

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

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

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

4.4 性能隱含需求

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

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

4.5 功能隱含需求

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

5 結(jié)束語

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

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