專利名稱：一種機載計算機軟件測試通用體系的構(gòu)建方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種機載計算機軟件測試通用體系的構(gòu)建方法，屬于機載計算機軟件測試技術(shù)領(lǐng)域，具體涉及到軟件的靜態(tài)測試、單元/集成測試、系統(tǒng)測試等。
背景技術(shù)：
機載計算機軟件屬于嵌入式軟件領(lǐng)域，近年來，由于軟件功能的逐步增強和規(guī)模的逐步擴大，其測試的需求也日益顯現(xiàn)，并朝著規(guī)范化、系統(tǒng)化發(fā)展。依據(jù)軟件工程的原理， 機載計算機軟件測試流程，可分為靜態(tài)測試和動態(tài)測試兩部分。靜態(tài)測試主要是在飛行控制軟件的各功能模塊代碼編寫完成后，對軟件的編程格式、結(jié)構(gòu)等方面進行檢查。動態(tài)測試則是檢驗軟件各功能模塊的實際運行效果是否符合設(shè)計標(biāo)準(zhǔn)，根據(jù)測試方法可分為白盒與黑盒測試等。
目前機載計算機軟件測試過程中，由于缺乏嵌入式軟件測試經(jīng)驗以及多數(shù)開發(fā)人員“重代碼輕測試”的開發(fā)習(xí)慣，測試工作往往僅由開發(fā)人員憑經(jīng)驗直接測試自己編寫的代碼，并沒有專業(yè)測試人員參與。根據(jù)國外近幾年來的嵌入式軟件開發(fā)經(jīng)驗，此種模式開發(fā)的應(yīng)用軟件可靠性難以保證，錯誤定位時間長，后期測試費用偏高。為解決此問題，本發(fā)明一種機載計算機軟件測試通用體系，通過建立一個與代碼開發(fā)并行的測試體系，最經(jīng)濟、有效地達(dá)到測試目的，增強了軟件系統(tǒng)的規(guī)范性及可靠性。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種機載計算機軟件測試通用體系的構(gòu)建方法，在該體系中，軟件測試人員可以依據(jù)具體需求，完整、高效地部署并執(zhí)行測試工作。從而保證機載計算機系統(tǒng)的可靠性與及時性，有效的減少軟件測試時間，縮減測試成本，提高軟件開發(fā)的規(guī)范性。
本發(fā)明一種機載計算機軟件測試通用體系的構(gòu)建方法，其主要內(nèi)容及程序是先基于嵌入式軟件開發(fā)環(huán)境以及待測軟件的需求分析/概要(詳細(xì))設(shè)計文檔，制定測試計劃。然后跟據(jù)計劃在代碼開發(fā)的同時進行靜態(tài)測試，以及單元/集成測試，發(fā)現(xiàn)問題及時反饋到開發(fā)進程中并予以修正。最后，當(dāng)模塊集成程度達(dá)到系統(tǒng)規(guī)模時，進行系統(tǒng)/確認(rèn)測試，并給出測評結(jié)果和測試分析。
本發(fā)明一種機載計算機軟件測試通用體系的構(gòu)建方法，該方法具體步驟如下 步驟一編寫測試計劃文檔，確立測試體系 1)編寫需求業(yè)務(wù)，說明用戶及功能，然后根據(jù)需求制定《測試需求分析》； 2)經(jīng)評審?fù)ㄟ^《測試需求分析》并據(jù)其制定《軟件總體測試計劃》、《單元/(集成) 測試計劃》、《系統(tǒng)測試計劃》等； 3)需求有更改時，寫入《需求更改記錄》，并隨之修改相應(yīng)測試計劃文檔。
步驟二 在代碼開發(fā)的同時進行單元測試(靜態(tài)) 功能模塊開發(fā)完成后進行靜態(tài)測試，內(nèi)容主要包括代碼和設(shè)計的一致性，代碼對標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達(dá)的正確性，代碼結(jié)構(gòu)的合理性等方面的問題。
具體實現(xiàn) 1)數(shù)據(jù)類型問題包括變量的數(shù)據(jù)類型是否有錯，是否存在不同數(shù)據(jù)類型的賦值，是否存在不同數(shù)據(jù)類型的比較 2)變量值問題包括變量的數(shù)據(jù)類型是否有錯，是否存在不同數(shù)據(jù)類型的賦值， 是否存在不同數(shù)據(jù)類型的比較； 3)邏輯判斷問題包括變量的初始化或缺省值是否有誤，變量是否發(fā)生上溢或下溢，變量的精度是否足夠； 4)循環(huán)問題包括循環(huán)終止條件是否正確，是否存在無法正常終止(死循環(huán))代碼，是否錯誤地修改循環(huán)變量，是否有可能存在誤差累積； 5)內(nèi)存問題包括使用內(nèi)存之前是否正確地初始化，是否存在內(nèi)存被釋放后卻繼續(xù)被使用，是否存在內(nèi)存泄漏，是否存在內(nèi)存越界，是否有可能出現(xiàn)野指針； 6)錯誤處理問題包括是否忘記進行錯誤處理，錯誤處理程序塊是否有可能一直沒有機會被運行，錯誤處理程序塊本身是否有誤，如與實際錯誤不一致，處理方式不正確等，是否存在錯誤處理程序塊被調(diào)用之前軟件已經(jīng)出錯； 針對機載軟件開發(fā)要點，單元測試對每個程序模塊，主要測試5個方面的問題模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨立的路徑和錯誤處理。
步驟三實際運行功能模塊進行單元/集成測試(動態(tài)) 動態(tài)測試主要流程如下 1)逐層劃分功能模塊，依據(jù)需求文件對各功能模塊編號； 2)根據(jù)接口協(xié)議及需求對各帶測模塊制定測試用例； 3)從最小的獨立單元模塊起進行動態(tài)測試，包括功能測試和路徑測試等； 4)統(tǒng)計測試結(jié)果，并分析測試效果和代碼開發(fā)質(zhì)量； 5)測試結(jié)果及問題反饋到開發(fā)人員并據(jù)此改進軟件代碼； 集成測試可在單元測試的基礎(chǔ)上，以一定規(guī)則集成部分功能模塊后進行，方法與單元模塊測試一致。
步驟四單元/集成測試完成后進行系統(tǒng)測試 集成測試完成后，退出宿主機測試環(huán)境，把系統(tǒng)移植到目標(biāo)機上來，完成應(yīng)用到現(xiàn)場環(huán)境中，從用戶的角度對系統(tǒng)進行黑盒測試，驗證每一項具體的功能。具體測試內(nèi)容如下 1)壓力測試 壓力測試的目的是想要破壞程序即檢測各類非正常情形，因此需要在反常規(guī)數(shù)據(jù)量、頻率或資源的方式下運行系統(tǒng)，以檢驗系統(tǒng)能力的最高實際限度?？梢钥紤]的測試方法有1.壓力測試中，中斷頻率為正常情況下的10倍。2.把輸入的數(shù)據(jù)量提高一個數(shù)量級來測試輸入功能會如何響應(yīng)。3.若某系統(tǒng)正常運行可支持10個終端并行工作，壓力測試則檢驗50個終端并行工作的情況。4.運行大量的消耗內(nèi)存或其他系統(tǒng)資源的測試實例。
2)性能測試 跟據(jù)項目實際情況，性能測試主要包括軟件運行時的CPU占用，內(nèi)存占用，堆棧占用，平均響應(yīng)時間等 3)可靠性測試 可靠性測試，是從驗證的角度出發(fā)，檢驗系統(tǒng)的可靠性是否達(dá)到預(yù)期的目標(biāo)，同時給出當(dāng)前系統(tǒng)可能的可靠性增長情況。關(guān)鍵的測試數(shù)據(jù)包括長時間運行時的失效間隔時間，失效修復(fù)時間，失效數(shù)量，失效級別等。
4)故障恢復(fù)測試 故障恢復(fù)測試是通過各種手段，強制性地使軟件出錯，使其不能正常工作，進而檢驗系統(tǒng)的恢復(fù)能力。本項目的恢復(fù)測試主要包括兩種情況1.如系統(tǒng)恢復(fù)是自動執(zhí)行(由系統(tǒng)自身完成)，則應(yīng)該檢驗錯誤記錄，重新啟動，重新初始化，數(shù)據(jù)恢復(fù)是否正確。2.如果某項恢復(fù)需要人為干預(yù)，則應(yīng)檢驗平均修復(fù)時間是否在限定的、可以接受的范圍之內(nèi)。
5)隨機測試 隨機測試主要是在測試后期，模仿用戶實際操作，對系統(tǒng)制造大量隨機輸入，觀察輸出結(jié)果是否和設(shè)計要求一致。
6)確認(rèn)測試 確認(rèn)測試目的是檢驗所開發(fā)的軟件是否能按用戶提出的要求進行。根據(jù)實際情況，測試考察軟件功能是否滿足需求規(guī)格說明書的規(guī)定。
步驟五驗收測試 在通過對系統(tǒng)測試后，還需進行驗收測試。驗收測試是每個系統(tǒng)的測試活動中所必須進行的，本項測試完成后，整個測試工作才告最終結(jié)束。因此要求所被測試的軟件系統(tǒng)和硬件系統(tǒng)和產(chǎn)品實際情況一樣。
本發(fā)明一種機載計算機軟件測試通用體系的構(gòu)建方法，它與現(xiàn)有技術(shù)比，其主要優(yōu)點是運用本發(fā)明后，軟件測試人員可以依據(jù)具體需求，完整、高效地部署并執(zhí)行測試工作，從而保證機載計算機系統(tǒng)的可靠性與及時性，有效的減少軟件測試時間，縮減測試成本，提高軟件開發(fā)的規(guī)范性。


圖1測試工作流程圖 圖2單元測試任務(wù)圖 圖3測試體系構(gòu)建圖 圖4單元測試文檔結(jié)構(gòu)圖 圖5系統(tǒng)測試文檔結(jié)構(gòu)圖
圖6單元/集成測試框架圖 圖7集成/系統(tǒng)測試任務(wù)圖 本說明中所有英文符號含義說明如下 VxWorks 美國風(fēng)河公司(Wind River)開發(fā)的一種嵌入式實時操作系統(tǒng)，廣泛應(yīng)用于國防、航空航天、通信、消費電子、工業(yè)控制、汽車電子等領(lǐng)域。
Tornado 美國風(fēng)河公司(Wind River)開發(fā)的一套強大的圖形化嵌入式集成開發(fā)環(huán)境，能夠?qū)崿F(xiàn)創(chuàng)建和管理工程、建立和管理宿主機與目標(biāo)機之間的通信以及運行、調(diào)試和監(jiān)控VxWorks應(yīng)用等功能。
Logiscope 瑞典Telelogic公司開發(fā)的一套自動化軟件測試工具，旨在降低人工工作量、降低成本和提高可靠性，包括Audit、RuleChecker, TestChecker三個功能模塊。
C++Test 美國Parasoft公司開發(fā)的一套軟件測試集成解決方案，可進行編碼策略增強、靜態(tài)分析、綜合代碼復(fù)審以及單元測試和組件測試等。
具體實施例方式下面結(jié)合附圖，對本發(fā)明中的各部分設(shè)計方法作進一步說明 本發(fā)明一種機載計算機軟件測試通用體系，開發(fā)環(huán)境以T0rnad02. 2為基礎(chǔ)，相應(yīng)目標(biāo)板操作系統(tǒng)可以為VxWOrks5. 5或6. 0，上位機采用Windows xp環(huán)境。單元/集成測試過程中自動化測試工具可以采用Logiscope或C++Test均可。該體系具體設(shè)計步驟如下 步驟一編寫測試計劃文檔，確立測試體系 1)編寫需求業(yè)務(wù)，說明用戶及功能，然后根據(jù)需求制定《測試需求分析》。
整個測試流程在軟件系統(tǒng)開發(fā)中的位置如圖1所示，測試工作貫穿項目需求、設(shè)計的全過程。在《測試需求分析》中，根據(jù)項目開發(fā)的實際情況，如圖3所示，需要明確測試項需求、測試時間，人力安排、測試環(huán)境、測試工具及測試中可能遇到的風(fēng)險等。
2)經(jīng)評審?fù)ㄟ^《測試需求分析》并據(jù)其制定《軟件總體測試計劃》，計劃中應(yīng)包括測試種類及測試通過標(biāo)準(zhǔn)、測試重點、進度安排、預(yù)測風(fēng)險、暫停標(biāo)準(zhǔn)及再啟動要求等。
在各測試階段需要制定相應(yīng)測試計劃文檔，如《單元測試計劃》、《集成測試計劃》、 《系統(tǒng)測試計劃》等。
3)需求有更改時，寫入《需求更改記錄》，并隨之修改相應(yīng)測試計劃文檔，對每次更改內(nèi)容均應(yīng)該編號以方便查詢。
步驟二 在代碼開發(fā)的同時進行單元/集成測試(靜態(tài)) 功能模塊開發(fā)完成后進行單元測試，包括靜態(tài)與動態(tài)測試等，其文檔結(jié)構(gòu)圖如圖4 所示。一般應(yīng)先進行靜態(tài)測試，如圖2所示，內(nèi)容主要包括代碼和設(shè)計的一致性，代碼對標(biāo)準(zhǔn)的遵循、可讀性，代碼的邏輯表達(dá)的正確性，代碼結(jié)構(gòu)的合理性等方面的問題。
具體實現(xiàn) 1)數(shù)據(jù)類型問題包括變量的數(shù)據(jù)類型是否有錯，是否存在不同數(shù)據(jù)類型的賦值，是否存在不同數(shù)據(jù)類型的比較 2)變量值問題包括變量的數(shù)據(jù)類型是否有錯，是否存在不同數(shù)據(jù)類型的賦值， 是否存在不同數(shù)據(jù)類型的比較 3)邏輯判斷問題包括變量的初始化或缺省值是否有誤，變量是否發(fā)生上溢或下溢，變量的精度是否足夠 4)循環(huán)問題包括循環(huán)終止條件是否正確，是否存在無法正常終止(死循環(huán))代碼，是否錯誤地修改循環(huán)變量，是否有可能存在誤差累積 5)內(nèi)存問題包括使用內(nèi)存之前是否正確地初始化，是否存在內(nèi)存被釋放后卻繼續(xù)被使用，是否存在內(nèi)存泄漏，是否存在內(nèi)存越界，是否有可能出現(xiàn)野指針 6)錯誤處理問題包括是否忘記進行錯誤處理，錯誤處理程序塊是否有可能一直沒有機會被運行，錯誤處理程序塊本身是否有誤，如與實際錯誤不一致，處理方式不正確等，是否存在錯誤處理程序塊被調(diào)用之前軟件已經(jīng)出錯 針對嵌入式軟件開發(fā)要點，單元測試對每個程序模塊，主要測試5個方面的問題模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨立的路徑和錯誤處理。各測試要點如下 樽塊接口測試要點 1.調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形參是否匹配； 2.所測模塊調(diào)用子模塊時，它輸入給子模塊的參數(shù)與子模塊中的形參是否匹配； 3.是否修改了只做輸入用的形參； 4.調(diào)用函數(shù)的參數(shù)是否正確； 5.全局變量的定義在各模塊中是否一致。
局部數(shù)據(jù)結(jié)構(gòu)測試要點 (1)不正確的或不一致的類型說明。
(2)錯誤的初始化或默認(rèn)值。
(3)錯誤的變量名，如拼寫錯誤或書寫錯誤。
(4)下溢、上溢或者地址錯誤。
路徑測試要點 (1)誤解的或不正確的算術(shù)優(yōu)先級。
(2精確度不夠精確。
(3)不同數(shù)據(jù)類型的比較。
(4)不正確的邏輯操作或優(yōu)先級。
(5)不正確的或不存在的循環(huán)終止。
(6)不適當(dāng)?shù)匦薷难h(huán)變量。
邊界條件測試要點 (1)運算或判斷中取最大值、最小值時是否有錯誤。
(2)在η次循環(huán)的第0次、1次、η次是否有錯誤。
(3)數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯誤。
出錯處理測試要點 (1)所報告的錯誤與實際遇到的錯誤不一致。
(2)出錯后，在錯誤處理之前就引起系統(tǒng)的干預(yù)。
(3)例外條件的處理不正確。
(4)提供的錯誤信息不足，以至于無法找到錯誤的原因。
集成各單元模塊測試時測試要點如下 (1)穿越模塊接口的數(shù)據(jù)是否丟失 (2) 一個模塊功能的實現(xiàn)是否破壞了另一個模塊的功能 (3)子功能組合之后是否達(dá)到預(yù)期的功能 (4)全局?jǐn)?shù)據(jù)是否被異常修改 (5)單個模塊的誤差是否被放大到了不能接受的地步 (6)模塊集成為子系統(tǒng)后運行是否穩(wěn)定 集成測試是在單元測試通過的基礎(chǔ)上，按一定規(guī)則(自底向上或自頂向下)將各模塊集成為子系統(tǒng)進行測試，集成測試的目的是當(dāng)單個模塊集成為子系統(tǒng)的過程中，軟件仍然可能出現(xiàn)問題。按照軟件開發(fā)的實際情況，可采取一次性集成測試方式或增殖式集成測試方式進行測試。
在代碼人工走查初步排除錯誤后可使用自動化測試工具(Logiscope以及 C++test)輔助進行靜態(tài)測試。主要分2個步驟 1)代碼質(zhì)量分析。
Logiscope Gnu. def配置以Tornado2. 2集成開發(fā)環(huán)境裝在C: \盤根目錄為例， 目標(biāo)機采用Pentium處理器(可依據(jù)開發(fā)實際情況，根據(jù)相應(yīng)BSP也可配置PowerPC) //System include paths //TODO-complete according to your environment IC:\Tornado2. 2\target\h IC:\Tornado2. 2\target\config\pcPentium IC:\Tornado2. 2\host\x86-win32\lib\gcc-lib\i386-pc-mingw32\gcc-2.96\ include IC:\Tornado2. 2\target\config\comps\src //Compiler predefined macros D_GNUC_ = 1 D_STDC_ = 1 DCPU = PENTIUM 依照Logiscope提供的質(zhì)量模型，對被檢測的程序文件可以給出2部分質(zhì)量檢測結(jié)果系統(tǒng)質(zhì)量檢測結(jié)果和函數(shù)質(zhì)量檢測結(jié)果。
其中系統(tǒng)質(zhì)量度量兀主要有ap_cg_levl, ap_comf, ap_eloc, ap_func, ap_scomm, ap_sline, ap_sloc, ap_ssbra, ap_stat, ap_vg, ap_wmc 等，可根據(jù)實際要求采用不同質(zhì)量度量元來分析程序質(zhì)量。
函數(shù)質(zhì)量分析包括可維護性，可分析性，適應(yīng)變化性，穩(wěn)定性，易測試性等。
2)編碼規(guī)則檢查 C++test內(nèi)嵌了多套常用編碼規(guī)則以供檢測，如MISRA C,Effective C++，GJB5369 以及Parasoft推薦規(guī)則等，也可根據(jù)實際需要自定義編碼規(guī)則。
步驟三實際運行功能模塊進行單元/集成測試(動態(tài)) 單元/集成測試的主要流程如下 1)功能模塊編號 依據(jù)需求文件從上至下逐層劃分功能模塊，并按層級對每個功能模塊進行測試編號。編號中應(yīng)突出測試層級(如單元、集成、系統(tǒng)測試可分別用U，I，S開頭編號表示Unit/ Integration/System)、測試對象(如測試編號中應(yīng)包括所測試的函數(shù)/文件名)及測試內(nèi)容(需要測試的功能編號)等 2)制定測試用例 進行動態(tài)測試前，須對所編號的各測試項編寫測試用例，測試用例按照一定規(guī)則進行編號，內(nèi)容應(yīng)包括輸入數(shù)據(jù)，期望輸出數(shù)據(jù)，實際輸出數(shù)據(jù)等。各類用例制定要點如下 黑盒(功能)測試一般在測試模塊接口處時使用。用例設(shè)計可采用等價類劃分和邊界值分析相結(jié)合的方法。如輸入值域為0-2000，精度為0. 1，等價類用例可取{-10.2， 150. 6,2100. 7)，邊界值用例可取{0士0. 1，2000士0· 1) 白盒(覆蓋)測試一般在測試各模塊內(nèi)部路徑時使用?？上葘δK程序流程圖進行簡化，得出控制流圖。然后依實際情況確定不同覆蓋方式進行測試，如語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、組合覆蓋和路徑覆蓋等，并據(jù)其制定測試數(shù)據(jù)。條件覆蓋舉例如下 void TaskReadData_HighCANl () { if (HighCANl Packet, m msgID < 5)_分支 1 { msgQSendO ； } else_分支 2 { if (msgQSendO == ERROR) IogMsgC Send CAN Message to TaskDataManage failed ！ \n〃 ,0,0, 0,0,0,0)； } } 路徑覆蓋舉例如下 void Input—Broadcast () { if(CanPacket_R. m_msgID < = IDT_MAINN0DE_4) { CanPacket_R. m_msgID = IDT_MAINN0DE_4 ； } switch (CanPacket_R. m_msgID) { case IDT MAINNODE 4 路徑 1 { Input_Timing()； break ； } case IDNP DETECT BROADCAST 路徑 2 { break ； } default :break _路徑 3 } } 3)執(zhí)行測試 依照測試進度安排，從最小的獨立單元模塊起進行動態(tài)測試，然后逐層往上，包括功能測試和路徑測試等。對于需要插樁的被測模塊需首先編寫好樁模塊然后一并運行，大致架構(gòu)如圖6。測試用例編寫完后，依機載軟件的實際情況，方法可以選擇人工測試或自動化工具輔助測試等 自動化測試工具以C++test為例，custom flow在PowerPC架構(gòu)下配置如下 <SetProperty key = “ nm〃 value=" nmppc“ />< ！ —GNU too 1 chain—> <SetProperty key = " munch_opts" value=" -asm ppc" /> testLogFile = " /tgtsvr/cpptest_results. tlog" covLogFile = " /tgtsvr/cpptest_results. clog" <ReadTestLogStep testLogFile = " F:/cpptest_results. tlog" timeoutlnfoProperty = " test_exec_timeouted〃 /> <ReadDynamicCoverageStep covLogFile = " F:/cpptest_results. clog" 這里把C++test的Logfile放到F: \根目錄下。
4)統(tǒng)計測試結(jié)果，并分析測試效果和代碼開發(fā)質(zhì)量 把單元/集成測試的用例運行的實際結(jié)果同理論結(jié)果對比，得出單元測試bug數(shù)量、覆蓋率等數(shù)據(jù)，并加以分析總結(jié)。
5)測試結(jié)果及問題反饋到開發(fā)人員并據(jù)此改進軟件代碼 步驟四單元/集成測試完成后進行系統(tǒng)測試 集成/系統(tǒng)測試的文檔結(jié)構(gòu)如圖5所示，測試項分布如圖7所示，根據(jù)項目開發(fā)實際情況可以有所刪減。集成測試完成后，退出宿主機測試環(huán)境，把系統(tǒng)移植到目標(biāo)機上來， 完成應(yīng)用到現(xiàn)場環(huán)境中，從用戶的角度對系統(tǒng)進行測試，驗證每一項具體的功能。具體測試內(nèi)容如下 1)壓力測試 壓力測試的目的是想要破壞程序即檢測各類非正常情形，因此需要在反常規(guī)數(shù)據(jù)量、頻率或資源的方式下運行系統(tǒng)，以檢驗系統(tǒng)能力的最高實際限度?？梢钥紤]的測試方法有1.壓力測試中，中斷頻率為正常情況下的10倍。2.把輸入的數(shù)據(jù)量提高一個數(shù)量級來測試輸入功能會如何響應(yīng)。3.若某系統(tǒng)正常運行可支持10個終端并行工作，壓力測試則檢驗50個終端并行工作的情況。4.運行大量的消耗內(nèi)存或其他系統(tǒng)資源的測試實例。根據(jù)機載計算機軟件的實際情況，壓力測試主要包括測試總線在不同周期下的表現(xiàn)。參考記錄方式如下
2)性能測試 根據(jù)實際情況性能測試需和壓力測試結(jié)合進行，重點考察在數(shù)據(jù)傳輸率增大的情況下，系統(tǒng)的表現(xiàn)情況。性能測試主要包括軟件運行時的CPU占用，內(nèi)存占用，堆棧占用，平均響應(yīng)時間等。參考記錄方式如下
3)可靠性測試 可靠性測試，是從驗證的角度出發(fā)，檢驗系統(tǒng)的可靠性是否達(dá)到預(yù)期的目標(biāo)，同時給出當(dāng)前系統(tǒng)可能的可靠性增長情況。關(guān)鍵的測試數(shù)據(jù)包括長時間運行時的失效間隔時間，失效修復(fù)時間，失效數(shù)量，失效級別等。根據(jù)獲得的測試數(shù)據(jù)，可以得到系統(tǒng)的失效率及可靠性增長趨勢。跟據(jù)機載軟件實際情況，本測試可分為正常情況長時間工作測試及故障情況長時間工作測試兩類。參考記錄方式如下
4)故障恢復(fù)測試 故障恢復(fù)測試是通過各種手段，強制性地使軟件出錯，使其不能正常工作，進而檢驗系統(tǒng)的恢復(fù)能力。本項目的恢復(fù)測試主要包括兩種情況1.如系統(tǒng)恢復(fù)是自動執(zhí)行(由系統(tǒng)自身完成)，則應(yīng)該檢驗錯誤記錄，重新啟動，重新初始化，數(shù)據(jù)恢復(fù)是否正確。2.如果某項恢復(fù)需要人為干預(yù)，則應(yīng)檢驗平均修復(fù)時間是否在限定的、可以接受的范圍之內(nèi)。測試前，測試人員需與開發(fā)人員協(xié)商，事先擬定故障列表，并依據(jù)列表進行測試。參考記錄方式如下

5)隨機測試 隨機測試主要是在測試后期，模仿用戶實際操作，對系統(tǒng)制造大量隨機輸入，觀察輸出結(jié)果是否和設(shè)計要求一致。參考記錄方式如下
6)確認(rèn)測試 確認(rèn)測試目的是檢驗所開發(fā)的軟件是否能按用戶提出的要求進行。根據(jù)實際情況，測試考察軟件功能是否滿足需求規(guī)格說明書的規(guī)定。
步驟五驗收測試 在通過對系統(tǒng)測試后，還需進行驗收測試。驗收測試是每個系統(tǒng)的測試活動中所必須進行的，本項測試完成后，整個測試工作才告最終結(jié)束。因此要求所被測試的軟件系統(tǒng)和硬件系統(tǒng)和產(chǎn)品實際情況一樣。
測試要點 1.所被測的系統(tǒng)應(yīng)該是穩(wěn)定版本，各項技術(shù)指標(biāo)要求符合技術(shù)文檔規(guī)定。
2.驗收測試應(yīng)該在系統(tǒng)被封版后進行。
3.驗收測試的測試用例有些不能夠采用在確認(rèn)測試中的，一般情況下必須重新制定符合驗收測試的測試用例，設(shè)計時要盡量考慮到實際環(huán)境狀態(tài)下，如機載軟件運行時的低溫、低氣壓條件等。
4.在進行驗收測試期間，原則上開發(fā)人員不能對正在進行驗收測試的系統(tǒng)進行修改。
權(quán)利要求
1. 一種機載計算機軟件測試通用體系的構(gòu)建方法，其特征在于該方法具體步驟如下步驟一編寫測試計劃文檔，確立測試體系1)編寫需求業(yè)務(wù)，說明用戶及功能，然后根據(jù)需求制定《測試需求分析》；2)經(jīng)評審?fù)ㄟ^《測試需求分析》并據(jù)其制定《軟件總體測試計劃》、《單元/集成測試計 劃》和《系統(tǒng)測試計劃》；3)需求有更改時，寫入《需求更改記錄》，并隨之修改相應(yīng)測試計劃文檔；步驟二在代 碼開發(fā)的同時進行單元測試即靜態(tài)測試；功能模塊開發(fā)完成后進行靜態(tài)測試，內(nèi)容主要包括代碼和設(shè)計的一致性，代碼對標(biāo)準(zhǔn) 的遵循、可讀性，代碼的邏輯表達(dá)的正確性和代碼結(jié)構(gòu)的合理性；具體實現(xiàn)的方法是1)數(shù)據(jù)類型問題包括變量的數(shù)據(jù)類型是否有錯，是否存在不同數(shù)據(jù)類型的賦值，是 否存在不同數(shù)據(jù)類型的比較；2)變量值問題包括變量的數(shù)據(jù)類型是否有錯，是否存在不同數(shù)據(jù)類型的賦值，是否 存在不同數(shù)據(jù)類型的比較；3)邏輯判斷問題包括變量的初始化、缺省值是否有誤，變量是否發(fā)生上溢、下溢，變 量的精度是否足夠；4)循環(huán)問題包括循環(huán)終止條件是否正確，是否存在無法正常終止即死循環(huán)代碼，是 否錯誤地修改循環(huán)變量，是否有可能存在誤差累積；5)內(nèi)存問題包括使用內(nèi)存之前是否正確地初始化，是否存在內(nèi)存被釋放后卻繼續(xù)被 使用，是否存在內(nèi)存泄漏，是否存在內(nèi)存越界，是否有可能出現(xiàn)野指針；6)錯誤處理問題包括是否忘記進行錯誤處理，錯誤處理程序塊是否有可能一直沒有 機會被運行，錯誤處理程序塊本身是否有誤，是否存在錯誤處理程序塊被調(diào)用之前軟件已 經(jīng)出錯；針對機載軟件開發(fā)要點，單元測試對每個程序模塊，主要測試5個方面的問題模塊接 口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨立的路徑和錯誤處理；步驟三實際運行功能模塊進行單元/集成測試即動態(tài)測試動態(tài)測試實現(xiàn)方法如下1)逐層劃分功能模塊，依據(jù)需求文件對各功能模塊編號；2)根據(jù)接口協(xié)議及需求對各帶測模塊制定測試用例；3)從最小的獨立單元模塊起進行動態(tài)測試，包括功能測試和路徑測試；4)統(tǒng)計測試結(jié)果，并分析測試效果和代碼開發(fā)質(zhì)量；5)測試結(jié)果及問題反饋到開發(fā)人員并據(jù)此改進軟件代碼；集成測試可在單元測試的基礎(chǔ)上，以一定規(guī)則集成部分功能模塊后進行，方法與單元 模塊測試一致；步驟四單元/集成測試完成后進行系統(tǒng)測試集成測試完成后，退出宿主機測試環(huán)境，把系統(tǒng)移植到目標(biāo)機上來，完成應(yīng)用到現(xiàn)場環(huán) 境中，從用戶的角度對系統(tǒng)進行黑盒測試，驗證每一項具體的功能。具體測試內(nèi)容如下1)壓力測試壓力測試的目的是想要破壞程序即檢測各類非正常情形，因此需要在反常規(guī)數(shù)據(jù)量、 頻率或資源的方式下運行系統(tǒng)，以檢驗系統(tǒng)能力的最高實際限度；測試方法有1.壓力測 試中，中斷頻率為正常情況下的10倍；2.把輸入的數(shù)據(jù)量提高一個數(shù)量級來測試輸入功能 會如何響應(yīng)；3.若某系統(tǒng)正常運行可支持10個終端并行工作，壓力測試則檢驗50個終端 并行工作的情況；4.運行大量的消耗內(nèi)存及其他系統(tǒng)資源的測試實例；2)性能測試跟據(jù)項目實際情況，性能測試主要包括軟件運行時的CPU占用，內(nèi)存占用，堆棧占用， 和平均響應(yīng)時間； 3)可靠性測試可靠性測試，是從驗證的角度出發(fā)，檢驗系統(tǒng)的可靠性是否達(dá)到預(yù)期的目標(biāo)，同時給出 當(dāng)前系統(tǒng)可能的可靠性增長情況；關(guān)鍵的測試數(shù)據(jù)包括長時間運行時的失效間隔時間，失 效修復(fù)時間，失效數(shù)量和失效級別；4)故障恢復(fù)測試故障恢復(fù)測試是通過各種手段，強制性地使軟件出錯，使其不能正常工作，進而檢驗系 統(tǒng)的恢復(fù)能力；本項目的恢復(fù)測試主要包括兩種情況1.如果系統(tǒng)恢復(fù)是自動執(zhí)行，則應(yīng) 該檢驗錯誤記錄，重新啟動，重新初始化，數(shù)據(jù)恢復(fù)是否正確；2.如果某項恢復(fù)需要人為 干預(yù)，則應(yīng)檢驗平均修復(fù)時間是否在限定的、可以接受的范圍之內(nèi)；5)隨機測試隨機測試是在測試后期，模仿用戶實際操作，對系統(tǒng)制造大量隨機輸入，觀察輸出結(jié)果 是否和設(shè)計要求一致；6)確認(rèn)測試確認(rèn)測試目的是檢驗所開發(fā)的軟件是否能按用戶提出的要求進行；根據(jù)實際情況，測 試考察軟件功能是否滿足需求規(guī)格說明書的規(guī)定；步驟五驗收測試在通過對系統(tǒng)測試后，還需進行驗收測試；驗收測試是每個系統(tǒng)的測試活動中所必須 進行的，要求所被測試的軟件系統(tǒng)和硬件系統(tǒng)和產(chǎn)品實際情況一樣；本項測試完成后，整個 測試工作才告最終結(jié)束。
全文摘要
本發(fā)明一種機載計算機軟件測試通用體系的構(gòu)建方法，它有五大步驟步驟一編寫測試計劃文檔，確立測試體系；步驟二在代碼開發(fā)的同時進行單元測試(靜態(tài))；步驟三實際運行功能模塊進行單元/集成測試(動態(tài))；步驟四單元/集成測試完成后進行系統(tǒng)測試；步驟五驗收測試；本發(fā)明是一種機載計算機軟件測試通用體系，它通過建立一個與代碼開發(fā)并行的測試體系，最經(jīng)濟、有效地達(dá)到測試目的，增強了軟件系統(tǒng)的規(guī)范性及可靠性，軟件測試人員可以依據(jù)具體需求，完整、高效地部署并執(zhí)行測試工作。它在機載計算機軟件測試技術(shù)領(lǐng)域里具有實用價值和廣闊地應(yīng)用前景。
文檔編號G06F11/36GK101847123SQ20101019144
公開日2010年9月29日 申請日期2010年5月26日 優(yōu)先權(quán)日2010年5月26日
發(fā)明者鄭澤偉, 胡軼之, 祝明 申請人:北京航空航天大學(xué)