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

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

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

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

根據中國空間技術研究院軟件產品保證中心的統計數據,航天器軟件第三方評測階段所發現的軟件缺陷中,與需求缺陷緊密相關的缺陷占比達50%以上,其余缺陷也均與需求缺陷存在或多或少的關聯。

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

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

開發需求分析重點解決的是需求從無到有的問題。而基于測試角度的需求分析,則是在已有的顯式需求和代碼基礎上,通過隱含需求分析,實現對顯式需求和代碼的完善與修正。

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

1 隱含需求分析的重要性

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

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

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

② 正確指導編碼和測試。

③ 有效避免測試遺漏。

2 隱含需求產生原因及常見分析方法

通過工程實踐分析與總結,綜合已有研究成果,隱含需求產生的原因主要有:

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

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

③ 分析能力不足,需求分析人員對系統缺乏全面認識[10],或對新技術缺乏全面了解[11]。

④ 心理默認,心理假設該需求為默認需求,認為無須明確說明。

⑤ 顆粒度不當,需求分解和細化程度不夠。

業內針對隱含需求分析方法也進行了大量研究,提出的隱含需求分析方法包括但不限于:用戶訪談[5]、情節串聯[5]、用戶故事[6]、問題驅動的需求誘導[7]、實地觀察[12]、情景調查[12]等。從適用性角度而言,這些方法更適用于非嵌入式軟件研發過程及其黑盒測試場景。

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

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

3.1 概述

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

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

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

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

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

3.2 需求顆粒度分析

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

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

首先,分析顯式需求。發現顯式需求中僅規定對某些重要參數做三取二處理,但是未規定具體處理策略。

然后,分析代碼設計。確認代碼實現策略為:任意兩區相等時,取相等兩區的數據作為三取二結果;三區均不等時,取一區的數據作為三取二結果。

進一步分析代碼實現策略的合理性,發現“三區均不等時取一區數據”的策略不合理,因為三區均不等狀態下,無法確認一區數據是否有效。

針對上述分析結果,與項目相關方進行溝通,最終確定處理策略為:任意兩區相等時,取相等兩區的數據;三區均不等時,進行三區數據按位三取二。

處理策略確認之后,項目相關方負責完善需求、修正代碼設計,測試方負責按照既定需求完成相關測試。

3.3 代碼設計無依據分析

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

圖2 代碼設計無依據分析示意圖

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

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

在代碼的逐行分析與確認中,通過與顯式需求的對比,發現代碼中存在無依據的控制指令輸出,即控制指令輸出相關的代碼沒有對應的需求。

與項目相關方溝通上述無依據設計的屬性(需求描述遺漏、代碼多余設計),由項目相關方確認,由于項目研發過程中的需求更正,這部分代碼對應了新增需求,但是新增需求未及時補充至顯式需求,導致出現無依據代碼。

需求確認后,由項目相關方負責修正需求,測試方負責按照既定需求完成相關測試。

3.4 引申推導分析

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

圖3 引申推導分析示意圖

引申推導分析是在顯式需求和代碼設計基礎上的更進一步的合理性和全面性分析,通過分析現有需求和代碼引申得出的隱含需求主要有2類,即完善性隱含需求和支持性隱含需求。

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

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

對于主循環+中斷的軟件架構,如果主循環或中斷的處理時間過長,可能會影響到某些處理的及時性,從而需要結合相關處理的及時性要求,引申推導出對主循環及中斷處理時間的限制性隱含需求,并溝通確認相應的性能指標。由此引申出的需求是為支持其他需求而必然存在的需求,屬于支持性隱含需求。

下面以航天軟件中常見的指令重發機制為例,對引申推導分析過程進行說明。

① 需求規定:指令發出后,未收到正確反饋,則重發指令。

② 代碼實現:每發出一條指令,都要查收反饋,未收到正確反饋,則重發指令。

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

分析代碼設計的合理性和全面性,引申出針對指令重發后仍然未得到正確反饋的情況,代碼實現為繼續執行指令重發,即針對指令發出后始終得不到正確反饋的情況,代碼會不停地執行指令重發。

與項目相關方溝通上述分析結果,最終確認需求為:指令發出后,未收到正確反饋,則重發指令。上述指令重發機制僅執行一次。經確認,上述需求與原需求之間不存在矛盾之處。

需求確認后,由項目相關方負責完善需求并修正代碼,測試方負責按照既定需求完成相關測試。

3.5 小結

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

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

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

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

① 指導完善當前項目的需求和編碼。

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

③ 充實隱含需求庫,用于指導后續項目的需求、編碼和隱含需求分析。

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

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

4.1 接口隱含需求

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

4.2 可靠性安全性隱含需求

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

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

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

4.3 恢復性隱含需求

考慮到在軌運行環境的復雜性和軟件在軌運行的高度自主性,通常會對航天嵌入式軟件進行適度的恢復性設計。但是,在此過程中,經常會因顯式需求遺漏導致出現隱含需求?；謴托缘湫碗[含需求及其首要分析方法如表3所示。

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

4.4 性能隱含需求

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

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

4.5 功能隱含需求

功能隱含需求需要結合具體功能進行具體分析。表5給出2個典型實例的具體說明。

5 結束語

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

但是,隱含需求是客觀存在的,隱含需求分析始終是工程上的難點,目前還沒有徹底的解決方法,需要相關科研人員在軟件研發、測試等各個環節,通過隱含需求顯式化不斷地加以完善。從工程角度而言,建立行業性、領域性的隱含需求庫是一個值得推薦的方法,后續還可以借助人工智能手段實現包含隱含需求庫、共性需求庫、共性用例庫等在內的知識庫系統的智能化管理與應用,從而有效彌補人員的領域知識和經驗不足的問題。