林 琳
(北京控制工程研究所,北京100190)
由于衛星等航天工程不僅涉及大量的投入,而且擔負著重要的使命,因此運行其上的星載嵌入式軟件必須具備非常高的可靠性和安全性。在這種情況下,星載嵌入式軟件的質量直接決定了整個衛星型號產品的質量,它已成為航天系統質量的重要構成因素[1]。
嵌入式系統的發展趨勢是:硬件逐漸向通用性平臺過度,依靠軟件來完成系統的各種任務。軟件已成為系統成敗的關鍵性因素[2]。為了保證系統的穩定性,避免由于其可能出現的失效而導致災難性的后果,要求對嵌入式系統,包括嵌入式軟件進行嚴格的測試、確認和驗證[3]。實時嵌入式軟件在時間和空間上的約束比較嚴格,被測軟件一般具有實時性、并發性等特點[4],測試此類軟件是計算機軟件測試中比較困難的問題。
軟件測試是軟件開發流程中的重要環節。而測試用例是軟件測試的核心,其組織性、功能覆蓋性、重復性的特點能夠保證測試功能不被遺漏。由于測試用例往往涉及多重選擇、循環嵌套,不同的路徑數目可能非常大,所以必須精心設計使之能達到最佳的測試效果。設計測試用例需要測試人員花費大量精力去熟悉需求,并在需求變化時更新用例,占了測試周期很大一部分時間。本文希望能夠總結以往的經驗,提出一個行之有效的測試用例設計流程以及一些基于黑盒測試的用例設計方法,以提高測試效率,從而降低軟件缺陷遺漏率。
航天型號軟件特別是嵌入式控制軟件目前一般采用瀑布式或增量開發生存周期模型。該模型包括的測試活動有:單元測試、集成測試、確認測試和系統測試[5]。其中確認測試作為軟件開發方的測試,是由相對獨立于設計編碼組的軟件測試組進行的,是軟件交付系統的重要保證。
確認測試屬于動態測試范疇。確認測試內容包括:在模擬環境(開發環境)下,運用黑盒測試方法,驗證所測軟件是否滿足需求規格說明列出的功能和非功能需求[6];保證軟件配置所有成分齊全,各方面質量都符合要求,具有維護階段所必須的細節。通過準則為滿足軟件需求規格說明中規定的所有功能、性能等要求。
目前,我們的確認測試是在一套自主研發的星地聯試設備(實時半實物的仿真環境)上進行的,其核心任務分為需求分析、用例設計和用例執行。軟件測試的效率和效果主要取決于用例設計[7],有效的測試用例可以定位以往未發現的軟件錯誤,從而提高測試質量。
本文主要探討確認測試中的用例設計。
以航天嵌入式軟件中的星載控制軟件為例,它的主要功能是實現對衛星的姿態和軌道控制、故障診斷,以及與其他分系統的通訊等,數據流/控制流復雜。對于太陽同步中低軌道小衛星來說,由于可測控弧段限制,對星載控制軟件的自主性要求很高。為了確保衛星的安全可靠,必須在測試中盡量覆蓋可能出現的所有情況,而不僅是做到功能點的覆蓋。眾所周知,由于軟件需求更改頻繁、軟件邏輯路徑的組合性、輸入數據的大量性及結果多樣性等因素,哪怕是一個極簡單的程序,要想窮盡所有邏輯路徑、所有輸入數據和驗證所有結果都是非常困難的。因此,進行合適的測試用例選取是做好測試工作的關鍵。
測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果,以便測試某個程序路徑或核實是否滿足某個特定需求[8]。其具體內容詳見參考文獻[9]。
確認測試用例的設計是基于需求的,主要依據軟件需求規格說明,并參考用戶需求、任務書、接口協議等文檔。用例設計的前提是進行詳細的測試需求分析,吃透功能點,才能保證測試用例的覆蓋性和正確性。測試用例的設計是測試需求細化的過程。具體的測試用例設計流程如圖1所示。
圖1 測試用例設計流程
首先,在輸入文件到位后,開始進行測試需求分析。初步了解軟件任務書、用戶需求及相關文件,對軟件功能進行合理劃分,列出被測軟件的主要功能大項,如初始化、模式切換功能、姿態控制率計算等。其次,對功能大項進行逐步細化和分解,直到每個被測試的功能點可以詳細定義和組合。最大限度地增加發現更深層次問題的可能。進而,根據細化后的測試項采用各種方法進行用例設計。然后建立詳細的跟蹤矩陣,以便對測試覆蓋性進行檢查,有效避免測試中的功能點遺漏。
按照這一思路可以進行測試復用。在測試實施過程中,直接復用成熟的測試用例所付出的代價要遠遠小于重新開發測試用例[10]。對于不同平臺的星載軟件,可從功能點級別進行提取,找出相同或相近的功能點;對于同平臺不同衛星的星載軟件,可復用到測試項或測試用例;對于繼承型號的星載軟件,可直接復用具體的測試用例。如果將大量的測試用例存入測試用例庫中,經過合理的分類,供測試人員選擇使用,將極大地提高軟件問題的發現率[11]。該思路可以為開展測試用例復用工作,搭建通用測試用例庫提供用例分類依據。
測試用例體現了完整的測試過程,因此測試用例的設計方法依據測試類型分類。確認測試是以黑盒測試為主的測試類型,因此在測試用例設計時,必須選擇適合的用例設計方法,才能保證在有限時間內,盡量多發現軟件問題,提高軟件質量。
設計確認測試的測試用例主要按照黑盒方法,具體方法見參考文獻 [8]。但是,把這些方法統稱為測試用例設計方法是不準確的,這些方法只是用例設計中如何確定測試輸入數據的方法,不能包含用例設計的全部內容。測試用例設計不僅是確定輸入數據的過程,還包括如何根據測試需求、設計規格說明等文檔確定測試用例的設計策略、設計用例的表示方法和組織管理形式等[12]。特別是對于航天嵌入式的星載軟件來說,由于實現的控制邏輯非常復雜,僅考慮輸入數據的設計是不夠的,還必須針對實際飛行任務中可能發生的各種情況以及輸入文件的具體要求設計不同的測試用例。只有全面考慮各個邏輯分支,才能保證測試覆蓋性。
確認測試中的用例設計主要是設計測試輸入數據和測試邏輯。
2.2.1 測試輸入數據設計
關于測試輸入數據的設計方法,本文中就不逐一列舉了。在實際測試中,要從大量的輸入數據中精心挑選出少數有代表性的測試數據,使得采用這些測試數據能達到最佳的測試效果,并高效地把隱藏的故障揭露出來是軟件測試的核心和關鍵。不同測試數據對發現軟件缺陷的能力差別很大[13],常需綜合使用各種方法以有效提高測試效率和測試覆蓋率。
首先使用邊界值分析方法,此類測試用例往往更易發現程序錯誤。其次,進行等價類劃分,針對輸入和輸出條件給出正常等價類和異常等價類,從而大大降低用例個數。第三,如果程序的功能說明中含有輸入條件的組合情況,可選用因果圖法。第四,采取功能圖法,通過不同狀態下條件的有效性設計不同的測試數據。另外,根據以往的經驗,可針對容易出現的錯誤追加一些測試用例(即錯誤推測法)。在功能性測試用例設計中,我們常需要把80%的精力投入到那些邊界情況和失效數據作為輸入的測試情況[14]。
2.2.2 測試邏輯設計
在確定了測試輸入數據的基礎上,需要進一步進行測試邏輯設計。本文中測試邏輯是指在設計測試用例中的執行步驟時,應考慮的邏輯關系。通常,我們可以根據功能點的復雜程度按功能和路徑分析混合模式設置用例。
在確認測試中,對簡單的功能點來說,按功能測試最簡捷,即按需求規格說明定義的功能點遍歷測試每一個功能點。對于復雜的程序模塊,其數個功能的作用是相互影響、緊密相關、環環相扣的,可以演變出數量繁多的變化。沒有嚴密的邏輯分析,產生遺漏是在所難免。路徑分析是一個很好的方法,其最大的優點在于可以避免漏測試。這里的路徑分析法與白盒測試中的路徑測試不同,它側重于功能點的路徑,而不關注程序的具體實現,路徑數據相對較少。如模式控制功能,對于中低軌道小衛星來說,控制的自主性很強,一個工作模式包含多種定姿和控制率算法,以及選用不同敏感器和執行機構的組合情況,在設計這類功能點的用例時,測試邏輯就是至關重要的了。
所以,我們在設計用例時應更多關注測試邏輯設計。首先,可以按照時間順序如星上時或者事件驅動順序來設計測試步驟,在模飛(模擬實際飛行程序)測試中通常采用這種方法;其次,根據用戶需求中相應模塊的邏輯分支來進行測試邏輯設計,通過路徑分析的方法盡量覆蓋所有分支;一般,主分支(即正常情況下運行的分支)被測試的概率很大,錯誤更有可能存在于那些程序運行時很少進入的異常分支。另外,還要考慮時序因素,數據的時間安排以及處理數據的任務并發性。例如執行某功能時被其他事件打斷的情況,以及不同功能之間的相互影響等。
2.2.3 用例設計思路
下面作者結合工作中的經驗,闡述一些在實際型號工作中的用例設計思路以及用例設計中的注意事項。進行確認測試用例設計時,首先應該有一個總體的設計思路作為指導思想,然后逐層細化。主要應遵循的原則總結如下:
(1)自頂向下
測試用例要覆蓋需求規格說明中提出的所有功能點,包括功能需求、性能需求、接口需求等。同時考慮充分性,然后按照2.1節中的用例設計流程展開用例設計。
舉一個簡單的例子說明,如表1所示。通過測試需求分析得到 “重要數據保護”這個功能點,對該功能點做進一步分解,可細化為2個測試項,每個測試項可以再分解出具體測試用例的設計要點,最后根據用例設計要點設計出完整的測試用例。
表1 “重要數據保護”功能的測試用例設計過程
(2)各有側重
針對不同功能點和測試項,在用例設計時應有側重點。對于不同的控制模式關注點也不同:如消初偏模式,應關注消除初始大角速度的能力;而軌控模式則更多地關注噴氣時間的準確度以及進入或退出條件。作為嵌入式軟件,在測試時還應關注與硬件接口的關系等。
(3)設計策略
考慮用例的執行順序與測試時間的約束;在邏輯清晰的前提下,用盡量少的用例覆蓋測試需求(一個用例包括盡可能多的邏輯分支)。有些用例可同時執行,例如部分模式切換的用例可以在模飛測試中進行;另外,可以將需要在相同模式中執行的用例統一測試,這樣能有效節約測試時間。從而在有限的時間內進行更多測試。
(4)關注細節
對于一個較復雜的大型軟件來說,測試用例的數量龐大,詳細的期望結果有助于測試執行人員更快更準確地完成測試工作。同時,某些細小的地方很容易被遺漏,如剔野、限幅和計數器清零的位置等,都要在用例設計時特別關注。
(5)安全性可靠性正確性
航天軟件對安全可靠性要求很高,因此在驗證軟件正確性的基礎上,必須包括可靠性測試和安全性測試。可以根據相應的測試需求設計用例,必要時借助相關測試工具。
(6)有全局觀
站在系統的角度思考問題,更容易發現高層次錯誤。要做好軟件測試,不能只是簡單照搬需求,關鍵在于理解。對于星載控制軟件,涉及控制分系統各領域知識,只有對這些知識都有相當的了解,才能設計出高效的用例。在確認測試階段,常會有一些測試要以系統級行為為線索,從系統的使用方式來設計測試用例,強調對使用情況的覆蓋。
以中低軌道小衛星的正常運行模式為例。假設該衛星安裝了慣性陀螺敏感器、紅外地球敏感器和數字太陽敏感器,定姿方式有3種分別為陀螺+紅外(A)、紅外+數字太陽(B)、陀螺+紅外+數字太陽(C);控制方式為輪控(D)、噴氣控制(E)和磁控(F)。在設計模式控制功能的用例時,首先按照輸入文件中正常運行模式下定姿與控制的邏輯分支進行路徑分析,分解出正常及異常分支如圖2所示,然后根據路徑分析結果得出用例的測試邏輯。在用例邏輯設計時,執行步驟應遍歷路徑分析結果,以確保功能得到完整的覆蓋。
圖2 正常運行模式定姿與控制邏輯
我們都知道,窮盡的測試是不可能的[15]。軟件測試永遠不可能發現所有的錯誤。測試人員的責任就在于盡量避免人為因素造成的測試遺漏(即本該在該項測試中發現而未被發現的軟件問題)。只有清楚地認識到測試遺漏發生的原因,才能提高軟件錯誤發現率和測試可信度,最終確保軟件產品的質量。
由于項目進度等客觀條件限制,測試人員只能有重點地選取測試用例,不可能進行面面俱到的測試,這就增加了錯誤被遺漏的可能性。在實際測試工作中用例選取不當的教訓比比皆是。經過對多個型號控制軟件的確認測試以及測試問題分析發現,為了減少測試遺漏,需重點關注以下幾方面:
(1)測試中,不能抱有僥幸心理,沒有測到的分支往往是錯誤高發的地方,測試力度決定軟件bug的發現數量;
(2)對于發生更改的軟件來說,錯誤通常集中在程序修改之處(包括新增功能)或者說是由更改引起的,所以在測試中要重點關注。回歸測試的影響域分析往往做得不夠,因此在測試時要多考慮相關功能(錯誤原因可能是編碼錯誤、修改考慮不全面或方案設計問題);
(3)加強數據庫中試驗數據的判讀:某些問題不易在動態測試時發現,通過查看數據庫,往往能暴露一些意想不到的問題;
(4)測試中暴露出問題的代碼往往隱藏著多個bug,經常出錯的模塊改錯后還會經常出錯;
(5)在軟件研制過程,特別是后續的版本升級中,不少軟件錯誤其實是相關的,常由于當時分析不到位或修改不徹底,導致將原本可解決的問題或者新的問題帶入下一版本;
世界上不存在沒有缺陷的軟件,對于軟件測試人員來說,發生測試遺漏是很難避免的,重要的是不斷提高發現問題的能力,降低測試遺漏率。
本文對航天嵌入式軟件的測試用例設計進行了探討,總結出了一套通用的用例設計流程和思路,有利于在軟件研制初期快速進行測試項分解以及開展用例設計。針對航天嵌入式軟件的用途和較難維護、邏輯時序復雜等特性,提出了測試輸入數據和測試邏輯結合的設計方法,能夠有效減輕用例設計工作量,提高測試效率,有效減少航天嵌入式軟件在測試過程中的錯誤遺漏。用例設計是一個不斷改進和日趨完善的過程,只有掌握了正確的測試用例設計流程并運用適當的用例設計方法,才能達到事半功倍的效果。
[1]CHEN Jiayu,XING Zhongbao.Research on on-board embedded software testing process model [J].Optics and Precision Engineering,2008,16(9):1654-1659(in Chinese).[陳佳豫,邢忠寶.星載嵌入式軟件測試過程模型的研究 [J].光學精密工程,2008,16(9):1654-1659.]
[2]DU Yan,LIU Congyue.Testing method for embedded realtime system software [J].Control & Automation,2006,(9-2):31-33(in Chinese).[杜延,劉從越.嵌入式實時系統軟件測試實踐 [J].微計算機信息,2006,(9-2):31-33.]
[3]ZOU Yuehe,LIN Maosen,TANG Fei.Discussion of embeded software system test [J].Electronic Product Reliability and Environmental Testing,2007,25(5):52-55(in Chinese).[鄒月和,林茂森,唐飛.嵌入式軟件系統測試綜述 [J].電子產品可靠性與環境試驗,2007,25(5):52-55.]
[4]YANG Guanghua,QI Xuan,SHI Nansheng.Design of embedded software test cases based on scenario pattern [J].Computer Engineering,2010,36(15):89-91(in Chinese). [楊廣華,齊璇,施寅生.基于場景模式的嵌入式軟件測試用例設計[J].計算機工程,2010,36(15):89-91.]
[5]Roger S Pressman.Software engineering-apractitioner's approach sixth edition [M ]. Beijing: China Machine Press,2009.
[6]Andreas Spillner,Tilo Linz,Hanz Schaefer.Software testing foundations:A study guide for the certified tester exam [M].2nd ed.Beijing:Posts & Telecom Press,2009.
[7]LU Xiaoli,GE Wei,CHEN Xinli,et al.Designing a test case library system of supporting sharing and reusing [J].Computer Science,2006,35(5):290-291(in Chinese). [路曉麗,葛瑋,陳新麗,等.支持共享和復用的測試用例庫系統的設計[J].計算機科學,2006,35(5):290-291.]
[8]Glenford J Myers.The art of software testing [M].Beijing:China Machine Press,2006.
[9]SHANG Dongjuan,HAO Kegang.A study of test cases and reuse in software testing [J].Computer Technology and Development,2006,16(1):60-72(in Chinese).[尚冬娟,郝克剛.軟件測試中的測試用例及復用研究 [J].計算機技術與發展,2006,16(1):60-72.]
[10]MENG Wei,LUO Shengxian.Study on feasibility of functional regression testing [J].Computer Engineering and Design,2009,30(1):125-128(in Chinese).[孟微,羅省賢.功能測試可回歸性研究 [J].計算機工程與設計,2009,30(1):125-128.]
[11]LIU Jie.Software testing and reuse technology [J].Science& Technology Information,2007,4(4):209-210(in Chinese).[劉杰.軟件測試與測試中的復用技術 [J].科技資訊,2007,4(4):209-210.]
[12]LIU Bai,TANG Longli,CHEN Dasheng.The method research of testcase design based on requirement [J].Electronics Quality,2007,28(10):61-63(in Chinese).[劉柏,唐龍利,陳大圣.基于需求的測試用例設計方法研究[J].電子質量,2007,28(10):61-63.]
[13]CUI Yingxia,LI Longshu.Integrated black-box test base on input/output relationship [J].Computer Engineering and Design,2007,28(23):5581-5584(in Chinese).[崔應霞,李龍澍.基于輸入輸出關系的綜合黑盒測試方法 [J].計算機工程與設計,2007,28(23):5581-5584.]
[14]ZHANG Yulin,XIE Kanglin.Test case design and reuse technology [J].Computer Applications and Software,2008,25(1):100-101(in Chinese).[張玉彬,謝康林.測試用例的設計和復用技術 [J].計算機應用與軟件,2008,25(1):100-101.]
[15]Ron Patton.Software testing [M].Beijing:China Machine Press,2008.