軟件測試報告

前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇軟件測試報告范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

軟件測試報告范文第1篇

由權威調查機構的《2014年軟件測試從業人員調查報告》顯示，軟件測試行業呈現出以下幾大特征：

一、軟件測試行業人才缺口大

數據顯示，被調查測試人員所屬公司中，互聯網行業及金融行業分別占42.81%和18.15%，綜合占比超過六成，這也印證了經濟結構調整的成果，目前互聯網行業和金融行業受到了投資者和個人的青睞，企業需求急劇上升，軟件測試人才缺口巨大。

二、軟件測試人員稀缺

然而，在被調查者所在公司中，測試人員與開發人員的比例在1:4及以上的高達55.13%。在這些公司中，49.66%的公司每年對測試人員進行的培訓次數為0。也就是說，將近一半的軟件測試人員在工作后沒有進行培訓學習的機會，這就要求想從事軟件測試的人員在入職前培訓相關的技能，確保工作可以順利開展。

三、軟件測試行業前景光明

在被調查者中，進行了一年左右軟件測試工作的人員占據了72.26%。其中，大專學歷及本科學歷的比例分別為34.93%和58.22%，他們的薪資在6000元及以上的占據了53.43%，軟件測試工程師薪酬高成為不爭的事實。

軟件測試報告范文第2篇

【關鍵詞】計算機軟件；軟件測試；生命周期；BSS系統；IT系統

1 引言

通信行業通常有三個相對獨立的IT系統：OSS運營支撐系統、BSS業務支撐系統、管理支撐系統。其中，BSS是通信行業對外向客戶直接服務的系統，管理著企業的各類客戶資料，為各類客戶提供業務受理和計費服務。BSS系統做得好壞，直接牽涉到最終用戶對通信業務的使用。要保證BSS系統的質量，就需要在BSS系統的各個環節把好質量關。

本文的研究任務就是通過軟件測試環節提高BSS系統軟件的效率，從而大大提高企業的信息化服務水平，使業務支撐部門對業務部門進行強有力的支撐。

2 軟件測試研究基礎

軟件測試就是利用測試工具按照測試方案和流程對產品進行功能和性能測試，甚至根據需要編寫不同的測試工具，設計和維護測試系統，對測試方案可能出現的問題進行分析和評估。軟件測試貫穿整個軟件系統的生命周期中，為保證服務質量，軟件測試要經過開發過程中的單元測試，集成測試，以及軟件交付后的確認測試，系統測試，驗收測試，還有軟件使用后的回歸測試。如圖所示：

2.1 單元測試

單元測試是在軟件開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發過程中使用，單元測試必須是可重復的，無論是在軟件修改，或是移植到新的運行環境的過程中。

2.2 集成測試

集成測試，也叫組裝測試或聯合測試，是單元測試的邏輯擴展。在單元測試的基礎上，將所有模塊按照設計要求組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。

2.3確認測試

確認測試又稱有效性測試。有效性測試是在模擬的環境下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規格說明書列出的需求。任務是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。

2.4 系統測試

系統測試是將已經確認的軟件、計算機硬件、外設、網絡等其他元素結合在一起，進行信息系統的各種組裝測試和確認測試，其目的是通過與系統的需求相比較，發現所開發的系統與用戶需求不符或矛盾的地方。

2.5 驗收測試

驗收測試是系統開發生命周期方法論的一個階段，這時相關的用戶和獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執行軟件的既定功能和任務。

2.6 回歸測試

伴隨著軟件生命周期中的任何一個階段，還有一個重要的測試環節是回歸測試。只要軟件發生了改變，就可能給該軟件帶來問題。軟件的改變可能是源于發現了錯誤并做了修改，也有可能是因為在集成或維護階段加入了新的模塊。

3 案例分析及研究

3.1 驗收測試在通信行業BSS系統中的應用研究

本案中，軟件上線前，要經過初驗和終驗，初驗是對軟件的初次驗收，根據合同要求，初驗時一般要滿足的條件是，軟件程序在一定的范圍內上線試運行，并在試運行過程中故障率不超過一定的范圍。初驗過程中，使用人員對軟件進行充分的使用，盡量多的遍歷所有的分支點，對軟件開發商提出更詳細的需求改造要求，軟件廠家在此階段都會盡可能快地做出修改，并提交給使用人員。這樣重復多次，直到達到初驗要求，項目會繼續推廣到更大的范圍。大范圍使用后，使用人員會隨之增多，必將會碰到更大更多的問題，在經過軟件廠家的修改優化，達到軟件程序穩定運行的效果，此時，項目才滿足終驗條件。終驗后，軟件廠家會維護一段時間，簽訂長期的維護合同。

根據這種情況，驗收測試是在軟件程序的初驗和終驗都要涉及到的。測試目的都是盡量查找軟件的漏洞以便得以修改，測試的方法是功能測試涉及較多一點。BSS系統驗收測試的目的是確認系統是否滿足產品需求規格說明和技術合同的相關規定，繼而能否滿足企業應用需求。一般需要通過實施預定的測試計劃和測試執行活動，確認系統的功能需求、性能需求和文檔需求。BSS系統是較復雜的大規模系統，其驗收測試具體包括：安裝測試、功能測試、界面測試、性能測試、文檔測試、負載壓力測試、恢復測試、安全性測試、兼容性測試等。

BSS系統的驗收測試一般由使用人員來做，且必須做到對每個細節和關鍵指標的反復測試。它的測試技術方法不僅有上述提到的幾種測試，還需要一些白盒測試，避免實現當前功能的情況下影響到其他模塊。它的測試用例，需要反復推算，尋找到最佳用例，以盡多的遍歷各測試節點，對程序、數據、文檔都要做到細致的測試。

根據以上分析，驗收測試涉及BSS系統的各環節內容。其中，最主要要審核的內容就是根據軟件的需求分析，檢驗要交付的軟件系統是否滿足需求分析中的內容。具體來說，根據驗收測試方法和它所屬的狀態及重要性，在BSS系統中，驗收測試的審核內容，可以用以下文檔驗收來體現。

軟件開放商應向企業項目組成員提供以下文檔：《軟件需求分析書》、《驗收測試計劃》和《項目驗收準則》、《測試用例設計》、《測試環境標準》、《測試報告》、《測試結果分析》、《缺陷報告》、《驗收測試報告》、《使用說明》或《操作文檔》、《試運行報告》。另外，使用人員根據軟件廠家提供的上述文檔，挑選重要的測試項，組織使用人員重新編寫測試用例并進行測試，編寫客戶方自己的《驗收測試計劃》、《驗收測試報告》、《驗收測試結果及分析》。根據《驗收測試結果及分析》組織項目成員討論是否驗收此項目。

驗收測試流程圖：

根據上述要求，在本案例中，驗收測試方面存在以下不足：

第一、《驗收測試計劃》和《項目驗收準則》沒有專門的文檔。如果我們能在需求分析書完成后能夠定制獨立的《驗收測試計劃》和《項目驗收準則》，則更有利于我們做好驗收測試工作，做好終驗工作。第二、沒有《缺陷報告》，程序的開發總要伴隨著缺陷的產生，雖然開放人員在逐漸的解決這些缺陷問題，但總有一些問題解決不了。第三、甲方對驗收測試重視不足，沒有獨立的《驗收測試計劃》、《驗收測試報告》、《驗收測試結果及分析》，沒有獨立的驗收文檔，對結果也沒有做分析。第四、在驗收測試整個過程中，甲方過于依賴乙方。整個流程以乙方提供驗收文檔為主，甲方雖驗收了文檔等資料，但并沒有根據資料編制驗收測試方案，也沒有做驗收測試報告及分析，只是在乙方提供驗收測試文檔中根據驗收測試用例進行了測試。

在實際運用中，首先要重視軟件測試的重要性，另外不能過于依賴軟件開發商，要建立企業自己的IT人員測試組，對軟件進行詳盡的各方面的測試。

3.2 回歸測試在通信行業BSS系統中的應用研究

實際工作中，回歸測試需要反復進行，當測試者一次又一次地完成相同的測試時，這些回歸測試將變得非常令人厭煩，為了支持多種回歸測試策略，可以運用自動測試工具，以便滿足達到不同回歸測試目標的要求。

通信行業BSS系統的回歸測試特別頻繁，每月的應用變更幾十例，有新增的功能，也有變更的功能，還有修復的功能。這些變更都需要回歸測試來驗證功能是否達到需求的要求。根據軟件特性，進行的回歸測試大都需要結合軟件模塊自身的功能，手工完成驗證，并且不同的模塊的回歸測試方法也可能不同。進行回歸測試時，不但檢驗新增模塊的功能是否實現，還要驗證是否影響了周邊其他模塊的功能，同時檢查整個大的模塊的功能是否正常，也就是考察軟件自身的功能和兼容性。

4總結與展望

實踐證明：將軟件測試的方法引入通信行業的BSS系統中，在軟件測試的各個環節都能夠詳細和規范的記錄測試相關信息，使管理層能夠方便的掌握到整個軟件的問題、配置、變更、等環節的信息，為領導決策提供了強有力的支持，達到了軟件使用的目的。大幅提高了系統的軟件維護效率和整個BSS系統的準確性，使BSS系統對企業的業務能夠快速高效的支撐。

參考文獻

[1]（美）馬瑟著.王峰，郭長國，陳振華等譯.軟件測試基礎教程[M].北京：機械工業出版社，2011.

[2]陳能技.軟件測試技術大全[M].北京：人民郵電出版社，2011.

軟件測試報告范文第3篇

關鍵詞：嵌入式軟件；GJB2725A；軟件測試；過程模型

0 引言

隨著信息化軍事技術的不斷深入，嵌入式軟件已在航空武器裝備軟件中得到了廣泛的應用，相應的，對其進行軟件測試的要求也越來越重要。目前，大部分軟件測試項目主要由事件驅動完成，存在流程不清晰、被動性高、效率低下等問題，影響了測試質量，其嚴重后果就是沒有及時發現軟件產品缺陷，導致產品失效。

總裝備部于2001年了GJB2725A《測試實驗室和校準實驗室通用要求》[1]，其目的就是為了指導軟件測試活動，提高軟件測試過程管控能力。因此提出了一種嵌入式軟件測試過程模型，該模型能夠依據軍標，以流程驅動的方式對軟件測試進行全過程管控，具有很好的工程應用價值，提高了研制效率。

1 嵌入式軟件測試過程模型

在型號軟件研制中，測試是一項復雜而繁瑣的工作，是一門綜合性學科，涉及技術、方法、資源以及管理等諸多方面[2]，現有流行軟件測試模型，如V模型、W模型和H模型[3]，并不能完全適用于實際測試工作，而應由研制單位牽頭，建立本地化的軟件測試過程模型。

根據工程經驗，將嵌入式軟件測試過程劃分為5個階段，即測試需求分析、測試策劃、測試設計與實現、測試執行和測試總結，每個階段實現不同的測試活動，前一個階段是后一個階段的輸入，后一個階段是前一個階段的驗證，以流程為驅動力，逐步實現所有活動，通過不斷地對流程再優化，實現模型的持續改進[4]，逐步趨近實際工程應用。

1.1 測試需求分析

該階段的輸入為軟件測評合同或軟件研制任務書，以明確被測項目的范圍、目標、約束及要求。

同時，確定需要完成的測試類型，如功能測試、性能測試、邊界測試、接口測試、可靠性測試等，并明確每一個測試類型的具體要求，例如：

1）功能測試：每一個軟件測試項輸入的每一個正常等價類和異常等價類都至少被一個用例覆蓋；

2）性能測試：對軟件的精度、時間和適應性進行測試，以確認是否符合規定的性能要求；

3）接口測試：測試所有外部接口，每一個外部輸入/輸出接口應進行正常和異常情況測試。

確定測試類型后，可制定測試策略，包括白盒和黑盒測試，并對具有特殊要求的被測項進行具體描述。同時，確定測試充分性和終止要求，避免項目無法結束。

測試需求分析最重要的工作就是依據軟件設計文檔，確定測試的顯性需求和隱形需求，并分解為測試項，為后續測試用例提供設計依據，本階段的輸出為《軟件測試需求規格說明》。

1.2 測試策劃

本階段在測試需求分析的基礎上，完成如下工作：

1）確定測試技術，如等價類劃分法、邊界值分析法和猜錯法等；

2）明確定性評價準則，包括文檔、設計和實現等方面；

3）數據采集要求，主要指被測軟件、用例、缺陷和管理數據等；

4）制定軟件測試環境，包括軟/硬件環境，確保測試順利開展；

5）明確測試人員的角色與職責，合理分工，確保進度；

6）根據要求進行風險分析，如技術、人員和資源風險，并制定措施。

本階段的輸出為《軟件測試計劃》。

1.3 測試設計與實現

本階段的主要內容就是依據測試需求，設計測試用例，單元、部件測試采用“先功能后邏輯”的測試策略，即先滿足基于功能的測試（功能測試覆蓋100%），再滿足基于邏輯的測試（語句、分支、調用覆蓋率100%），配置項、系統測試采用基于功能的測試策略，測試用例主要包括名稱、標識、初始化、前提和約束、輸入、預期輸出、通過準則、追蹤關系、終止條件、用例類型和設計人員等信息，本階段的輸出為《軟件測試說明》。

1.4 測試執行

本階段的主要內容就是在實際測試環境下執行測試用例，記錄測試結果，將期望結果與實測結果進行比對，如不一致，則進行深入分析，確認為軟件缺陷，則填寫軟件問題報告單，本階段的輸出為《軟件測試記錄》和《軟件問題報告單》。

1.5 測試總結

本階段的主要內容就是依據測試結果，統計與分析測試數據，包括用例執行率、用例通過率、代碼缺陷率、功能覆蓋率等指標，進而對被測軟件產品做出客觀、公正、獨立的評價，為改進軟件產品質量提供支撐，本階段的輸出為《軟件測試報告》。

2 模型應用

被測軟件為某型嵌入式軟件，要求完成軟件測試，出具測試報告。

2.1 測試需求分析

根據測試要求，定義被測項目的范圍、目標、約束及要求。

范圍：單元、部件和配置項測試。

目標：單元測試完成語句、分支100%覆蓋，部件測試完成調用100%覆蓋，配置測試完成需求100%覆蓋。

策略：單元、部件測試采用白盒測試，配置項測試采用黑盒測試。

測試需求：經分析，單元測試共有272個測試需求，部件測試共有36個測試需求，配置項測試共有16個測試需求，27個測試項。

2.2 測試策劃

軟件測試主要采用等價類劃分法和邊界值分析法進行測試。

2.3 測試設計與實現

依據軟件設計文件設計測試用例，單元測試共設計1869個測試用例，部件測試共設計266個測試用例，配置項測試共設計168個測試用例。

2.4 測試執行

經測試，并對測試結果進行分析、確認，共計發現56個軟件問題，提交設計進行優化改進。

2.5 測試總結

測試結果總結如表4所示。

測試用例均能100%覆蓋測試需求，配置項測試的用例執行率為95%，其原因是有些硬件環境不能滿足測試要求，如破壞性測試，單元和配置項測試的用例通過率均不到100%，說明這兩種測試是發現軟件缺陷的重要手段，通過對56個問題的歸零處理，軟件問題得到解決，提高了軟件產品的質量。

3 總結

采用流程驅動式的嵌入式軟件測試過程模型能夠很好的解決測試工程化問題，通過實際運用，提高了測試管控能力，確保了測試充分性，發現了軟件問題，提高了軟件的質量和可靠性。

參考文獻：

[1] 閆宇華,李誼,黃寧等.GJB 2725A-2001，測試實驗室和校準實驗室通用要求[S].北京：中國人民總裝備部，2001.

[2] 金先仲,任宏光,李建軍等.空空導彈研制系統工程管理[M].北京：國防工業出版社，2007.

軟件測試報告范文第4篇

【摘要】信息是現代咨詢的基礎，工程咨詢業俗稱為“頭腦加工信息”的行業。工程咨詢信息系統，滿足了工程咨詢對信息化的需求，在開發一套好的工程咨詢信息系統過程中，軟件的測試是非常重要的，它對信息系統能否投入運行起著至關重要的作用，在軟件的測試中，一定要針對工程咨詢的特點，做好軟件的測試。

【關鍵詞】工程咨詢信息系統軟件測試

信息是現代咨詢的基礎，工程咨詢業俗稱為“頭腦加工信息”的行業。在信息化建設不斷推進的條件下，工程咨詢作為智力服務型企業，對信息化的需求日益增長。為了把咨詢業務做精、做強、做大，必須依靠現代科技手段和信息處理技術，建立企業內部信息庫，挖掘信息資源，改變信息管理方式。把零散的、隨機的信息管理，轉變為系統的、可持續性的、能夠便捷查詢和充分共享的信息管理，實現咨詢依據可靠、信息來源充分、方法科學的現代咨詢發展目標。工程咨詢信息系統，滿足了工程咨詢對信息化的需求，實現了項目管理及圖書等資料借閱的自動化管理方式，建立的競爭情報管理系統實現了目標信息的定時抓取，上傳企業內部公告等多種功能。在開發一套好的工程咨詢信息系統過程中，軟件的測試是非常重要的，它對信息系統能否投入運行起著至關重要的作用，軟件測試環節是保障軟件質量的最后一道關鍵性關口。在軟件的測試中，一定要針對工程咨詢的特點，做好軟件的測試。

一、工程咨詢的特點

工程咨詢業是智力服務性行業，運用多種學科知識和經驗、現代科學技術管理方法，遵循獨立、科學、公正的原則，為政府部門和投資者對經濟建設和工程項目的投資決策與實施提供咨詢服務，以提高宏觀和微觀的經濟效益。工程咨詢具有以下特點：工程咨詢業務范圍彈性很大，可以是宏觀的、整體的、全過程的咨詢，也可以是某個問題、某項內容、某項工作的咨詢；每一項工程咨詢任務都是一次性的、單獨的任務、只有類似，沒有重復；工程咨詢是高度智能化的服務，需要多學科知識、技術、經驗、方法和信息的集成及創新；工程咨詢牽涉面廣；許多工程咨詢成果具有預測性、前瞻性；工程咨詢提供智力服務，咨詢成果屬非物質產品。

二、軟件測試的目的

軟件測試是為了發現錯誤而執行程序的過程；測試是為了證明程序有錯，而不是證明程序無錯誤；一個好的測試是在于它能發現至今未發現的錯誤；一個成功的測試是發現了至今為止未發現的錯誤的測試。

軟件測試的目的不僅僅是為了發現程序中存在的錯誤，它還是軟件質量保證至關重要的一個環節。軟件測試不同于程序員在代碼編寫完成后簡單的使用、調試，軟件測試需要遵循一定的原則，軟件測試的原則大致包括以下內容：確定預期輸出是測試必不可少的一部分，程序員應避免測試自己編寫的程序，程序設計機構不應測試自己的程序，徹底檢查每一個測試結果，對非法的和非預期的情況也要象對合法的預期輸入一樣編寫測試用例，檢查程序是否做了要它做的事僅僅是成功的一半，另一半是程序是否做了不要它做的事，除了真正沒有用的程序外，一定不要扔掉測試用例，一段程序中存在錯誤的概率與在這段程序中已發現的錯誤成比例，在規劃測試時，不要設想程序中不會查出錯誤，所有的測試都應當追溯到用戶需求，應該在測試工作真正開始前就開始計劃測試，測試應該從“小規模”開始逐步轉到“大規模”，測試發現錯誤中80%的錯誤屬于20%的程序模塊，窮舉測試是不可能的，但充分覆蓋程序邏輯是可能的，測試是一件非常復雜，具有創造性的和需要高度智慧的挑戰性任務。

三、軟件測試幾點看法

軟件測試作為軟件上線的最后關口，應得到高度重視。但由于思想意識和歷史原因，出現重開發輕測試的現象，軟件測試成為制約軟件成功上線運行的瓶頸。由于對軟件測試的重要性理解不夠，很多人認為程序能夠運行基本上就已經成功，沒有必要進行專門的測試，這些都是錯誤的觀點。

軟件測試分為：單元測試（模塊測試），集成測試。在進行所有的測試前，一定先要認真閱讀各種相關文檔，同時制定測試計劃，同時進行測試用例設計，在設計測試用例時，要對待測軟件進行分析，設計合理的模型，制定測試用例。在測試進行過程中，要根據實際情況修改或增加測試用例。

在測試完成后，要根據測試結果填寫《軟件測試問題跟蹤單》，在整個軟件測試完成后，要分析測試結果并編寫測試報告。在測試報告中要說明本次測試的結果，如各個等級的BUG的數目，在各個模塊中的分布情況及評語。在整個項目完成后，將測試工作所產生的所有文檔交文檔管理員歸檔。

軟件測試是為了擬制缺陷。作為衡量和評價的手段，測試是質量控制的核心環節，除發現問題外，測試還有預防的潛力。

軟件測試報告范文第5篇

關鍵詞：軟件測試；認知誤區；嵌入式；單元測試流程

1 軟件測試簡述

軟件測試是在軟件投入商用前，對軟件需求分析報告、設計規格說明書和編碼的最終復查，是軟件質量保證的關鍵方法，軟件測試并不等于程序測試。它貫穿于軟件定義和開發的整個過程，因此，軟件需求分析、軟件概要設計、軟件詳細設計和程序編碼等各階段所得到的文檔，包括需求規格說明書、概要設計說明書、詳細設計說明書，以及源代碼都是軟件測試的測試對象。隨著軟件規模的不斷擴大，以及軟件設計復雜程度不斷的提高，軟件開發中出現失誤或缺陷的概率越來越大。隨著市場對軟件質量重要性的認知程序的提高，因此軟件測試在軟件項目實施過程中的重要性尤為突出。軟件測試將會成為一個具有很大發展前景的行業，市場將需要更多具有豐富測試技術和先進管理經驗的測試技術員和項目經理。

2 軟件開發項目測試的誤區

軟件測試從1990年左右進入中國，目前國內大的測評中心、大型企業已經完全掌握了軟件測試的測試策略和測試方法。小企業普遍存在測試人員不懂什么是單元測試，怎樣進行單元測試，很少能看懂代碼的細節。而開發人員很少能夠提供完整的詳細設計報告、需求報告。導致單元測試，以拼湊測試報告為目的。

認知誤區一：軟件測試是軟件開發的最后一道步驟，工程師們一般認為，軟件實際項目要經過下面六個階段：需求分析，概要設計，詳細設計，軟件編碼，軟件測試，軟件。因而，認為軟件測試只是編碼后的一個孤立的階段，這就是不了解軟件測試流程的認知偏差。軟件測試是一個系列的活動過程，是一個開放的體系，包括軟件測試需求分析，測試計劃設計，測試用例設計，執行測試。從而，軟件測試應當貫穿于軟件項目的整個生命周期，并不是軟件開發后最后一道步驟。認知誤區二：軟件商用后如果發現質量問題，就武斷認為是軟件測試人員的工作失誤。這種認識很狹隘，很是打擊軟件測試人員的工作積極性。軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤。因為從根本上講，軟件測試不可能發現全部錯誤，軟件后的錯誤可能來自軟件項目中的各個過程。認知誤區三：軟件測試對測試人員技術要求不高，任何人都可以做。很多工程師認為軟件測試就是安裝并運行程序，按按鍵盤的重復性工作。隨著軟件測試技術的不斷改進和完善，新測試方法、新流程、新工具都在不斷被開發出來。這就需要軟件測試工程師掌握和學習很多專業測試新理念和新技能。認知誤區四：只有編寫程序的高手才是軟件專家，而軟件測試沒有前途。由于我國軟件行業整體研發能力比較低，軟件開發過程不規范。不少軟件項目的開發都還停留在“累加堆疊“階段。項目開發依靠個別程序員決定，他們一人負責總體設計和代碼編寫，給人的印象是程序員是真正的牛人，完成了所有的軟件項目開發工作。但在微軟等世界知名軟件企業里，軟件測試人員的待遇和數量與一般程序員沒有多少差異，優秀測試人員的待遇甚至比普通程序員要高的多。

3 嵌入式軟件單元測試流程

單元測試是指對軟件中的最小可測試單元進行檢查和驗證。單元是規格說明書中的最小單元，包括函數、子程序、程序。單元測試關注獨立的函數功能，是測試過程中最低級別的測試活動。需要開發一個或多個測試用例執行單元測試。把代碼問題縮小范圍在開發階段鎖定Bug是單元測試的主旨要求，以下將介紹一種容易操作的嵌入式單元測試實戰流程。

第一階段，制定測試記錄表，記錄測試過程，和測試情況。測試記錄表包含：源文件名，子函數名，用例標號，用例名稱，用例個數，用例通過個數，語句覆蓋率，分支覆蓋率，MC/DC覆蓋率，測試結果，問題描述，測試人員，測試時間。針對第一階段的測試結果，此時需要大家分析出問題的代碼，各抒己見，總結問題，給出解決方法。

第二階段，解決部分測試用例failed問題，找出阻止生成用例的共性。常見問題匯總：局部變量未初始化，調用函數未聲明，局部變量直接賦值，結構體嵌套、結構體指針、聲明問題、聲明位置問題，函數指針，大循環、死循環，絕對地址，指針變量，C語言程序中帶有goto語句。解決辦法：局部變量聲明后，需要賦初值再使用。調用函數未聲明，該問題發生在隔離測試階段，屬于代碼書寫不規范問題。解決方法：自定義的函數都需要在頭文件中做統一聲明。局部變量直接賦初值：該問題發生在測試用例無法生成階段，屬于代碼書寫不規范問題。解決方法，結構體局部變量，指針變量需要先聲明后賦初值。結構體嵌套、結構體指針、聲明問題、聲明位置問題：該問題也屬于代碼書寫不規范問題。解決方法：根據MISRA代碼書寫規范，結構體需要放在頭文件中統一聲明。大循環、死循環：單元測試需要有程序結束的出口。解決方法：把大循環改為小循環，注釋掉死循環（if（1）、for（； ；），while（1））。絕對地址：單元測試不連接真實的硬件設備。遇到寄存器等絕對地址時，需要對寄存器做變量處理。指針變量：需要聲明一個同類的數組，然后把數組的首地址，賦給指針變量。函數指針：需要虛構一個函數實體，取函數地地址賦給函數指針，完成映射。C語言程序中帶有goto語句：需要改變程序結構，增加判斷語句，去除所有的goto語句，以便確保C語言程序的穩定性。

測試第三階段：基本圈復雜度高于MISRA閥值要求的函數，先考慮把復雜函數改為幾個小函數。改不了的由開發人員寫聲明以及具體原因，再按照路徑分支來設計測試用例。匯總測試結果，提交測試問題報告單，并提交行業標準測試報告。

4 結束語

文章簡述了軟件測試的基本概念，澄清了軟件測試工程實踐中的幾個誤區，依據單元測試實踐的具體案例，介紹了一種高效、容易操作的嵌入式單元測試的流程。

參考文獻

[1]胡丹，杜新華.基于目標機的嵌入式軟件單元測試[J].電子測量技術，2006（2）.

[2]趙正海，王寧.跟蹤雷達“指示引導”功能軟件測試方法研究[J].現代電子技術，2013（36）.

[3]于園園.軟件測試技術與測試管理研究[J].江蘇科技信息，2016（7）.

[4]王琨.嵌入式計算機軟件測試關鍵技術探討[J].科技創新與應用，2016（7）.

[5]張金環，田洪濤.淺析設備軟件測試與質量保證[J].電子工業專用備，2016，45（1）.

作者簡介：張軍（1988-），男，陜西武功人，工學碩士，助理工程師，主要研究方向：雷達信號處理算法、數字中頻收發機和嵌入式軟件測試。