測試報告缺陷分析范文
時間：2024-01-24 18:06:46
導語：如何才能寫好一篇測試報告缺陷分析，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。
篇1
【關鍵詞】軟件測試 測試報告 測試流程
1 引言
軟件測試是軟件開發過程的重要組成部分，是用來確認一個產品的品質或性能是否符合開發之前所提出的要求。對軟件需求分析、設計規格說明和編碼的最終復審，某種程度上測試工作的好壞直接影響了軟件產品的交付和用戶的滿意度。因此，如何做好測試工作，使測試在軟件工程中順利進行，輔助軟件開發工作是我們每個軟件人員應該考慮的問題。
2 軟件測試的目的
（1）確認軟件的質量，確認軟件做了你所期望的事情，確認軟件以正確的方式來做了這個事件。
（2）提供信息，比如提供給開發人員或程序經理的反饋信息，為風險評估所準備的信息。
（3）軟件測試不僅是在測試軟件產品的本身，而且還包括軟件開發的過程。軟件測試的第三個目的是保證整個軟件開發過程是高質量的。
3 軟件測試的對象
軟件測試并不等于程序測試。軟件測試應該貫穿整個軟件定義與開發整個期間。因此需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應該是軟件測試的對象。
4 軟件測試流程
軟件測試工作并不是在軟件代碼開發完畢后才開始的，這一點是很多軟件人員的誤區，需要明確一下，它其實是在項目進入軟件實現階段就開始了，項目進入軟件實現階段的時候，就應該啟動軟件測試工作了。
下面根據筆者的測試經驗，詳細闡述一下軟件測試的流程、每個階段需要做的工作及整個測試過程產生的文檔。
4.1 計劃與設計階段
4.1.1 召開測試啟動會議
當項目進入軟件實現階段（編碼），測試經理召集項目經理、開發經理開會確定測試交接時間，開發團隊與測試團隊交接測試內容，對測試目標達成一致，商討測試計劃的可行性，統一項目組的目標和測試的工作重點。進行規模預估并成立測試團隊，完成《測試計劃》和《測試方案》。
4.1.2 設計測試用例
明確了測試需求和測試計劃，在需求分析文檔確立基線以后，測試組需要針對測試需求編寫全部測試用例，在實際的測試中，測試用例將是唯一實施標準。
4.2 實施測試階段
4.2.1 實施測試用例
實施測試用例將花費測試組絕大部分時間，這些工作都是建立在前期很多計劃工作的基礎上。當測試用例全部編寫完成后，測試工程師根據測試計劃中分配給自己的測試任務，實施相應的測試用例，并記錄測試結果。
4.2.2 填寫測試記錄
測試人員在進行具體的測試工作時，需要將測試內容填寫在測試記錄表中，直到所有的測試執行工作結束。
4.2.3 提交BUG清單
在具體的測試過程中，測試人員發現BUG后，需要將BUG記錄在清單里，并及時提交給測試經理。
4.2.4 提交測試報告
在約定的測試周期完成之后，測試工程師需要總結此測試的結果，編寫測試報告。測試工程師根據此輪測試的結果，編寫測試報告，主要應包含以下內容：
（1）測試報告的版本。
（2）測試的人員和時間。
（3）測試所覆蓋的缺陷――測試組在這輪測試中所有處理的缺陷， 不僅要寫出覆蓋缺陷的總數，還要寫明這些缺陷的去向。
（4）上一版本活動缺陷的數量。
（5）經過此輪測試，所有活動缺陷的數量及其狀態分類。
（6）測試評估――寫明在這一版本中，哪些功能被實現了，哪些還沒有實現，這里只需寫明和上一版本不同之處即可。
（7）急待解決的問題――寫明當前項目組中面臨的最優先的問題，可以重復提出。
在每輪測試結束之后應盡快將符合標準的測試報告發給測試經理。
4.3 總結階段
測試工作結束或即將結束時，測試組就要開始著手準備進行總結的工作。
4.3.1 編寫測試總結報告
在測試結束之后，測試經理編寫測試報告，對測試進行總結，并且提交給項目經理，為產品的后續工作提供重要的信息支持。
測試經理根據測試的結果及測試工程師提交的測試報告編寫測試總結報告，測試總結報告必須包含以下重要內容：
（1）測試資源概述―多少人、多長時間。
（2）測試結果摘要―分別描述各個測試需求的測試結果，產品實 現了哪些功能點，哪些還沒有實現。
（3）缺陷分析―按照缺陷的屬性分類進行分析。
（4）測試需求覆蓋率―原先列舉的測試需求的測試覆蓋率，可能 一部分測試需求因為資源和優先級的因素沒有進行測試，那么 在這里要進行說明。
（5）測試評估―從總體對項目質量進行評估。
（6）測試組建議―從測試組的角度為項目組提出工作建議。
4.3.2 測試驗收
測試驗收工作是在以上工作全部結束后，測試經理對測試的過程、效果進行驗收，簽發測試驗收報告，宣布測試結束。由測試經理進行測試驗收，驗收內容包括：
（1）測試效果驗收―測試是否達到預期目的。
（2）測試文檔驗收―測試過程文檔是否齊全，符合標準。
（3）測試評估―從總體對測試的質量進行評估。
（4）測試建議―對本次測試工作指出不足，需要在以后工作中改 進的地方。
（5）宣布測試結束―測試組成員簽字宣布本次測試結束。
4.3.3 測試歸檔
測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標準文檔進行歸檔，主要包括測試計劃、測試用例、測試報告、驗收報告等。這些文檔的編寫保障了測試的順利進行，同時作為整個測試項目的痕跡，被保留下來，供查閱。
參考文獻
[1]佟偉光.軟件測試[M].北京：人民郵電出版，2008.
[2]Rex Black.測試流程管理[M].北京：北京大學出版社，2001.
[3]Robert V.Binder著，華慶一等譯.面向對象系統的測試[M].北京：人民郵電出版社，2001.
[4]Mark Fewster， Dorothy Graham著，舒智勇等譯.軟件測試自動化技術與實例詳解[M].北京：電子工業出版社，2000.
[5]Karl E.Wiegers著，陸麗娜，王忠民，王志敏譯.軟件需求[M].北京：機械工業出版社，2000.
篇2
兩年以上工作經驗|男|27歲（1989年12月11日）
居住地：北京
電 話：135*******（手機）
E-mail：
最近工作[1年7個月]
公 司：XX有限公司
行 業：互聯網/電子商務
職 位：系統測試工程師
最高學歷
學 歷：本科
專 業：計算機科學與技術
學 校：北京農學院
自我評價
本人自中學開始就養成凡事應該從基層做起，并且不能把自己的能力定位過高的性格習慣，所以我在校期間無論從事什么工作都是從基層做起，盡量把工作約束在自己的能力之內，腳踏實地的工作。但只要有機會，我一樣會進行更高的嘗試，讓自己的能力繼續升級。
求職意向
到崗時間：可隨時到崗
工作性質：全職
希望行業：互聯網/電子商務
目標地點：北京
期望月薪：面議/月
目標職能：系統測試工程師
工作經驗
2013/10 – 2015/5：XX有限公司[1年7個月]
所屬行業：互聯網/電子商務
集成部
系統測試工程師
1.熟悉軟件測試理論、流程和方法，有較強的邏輯分析能力、測試用例設計能力。
2.能根據系統業務需求獨立完成測試用例設計、執行，缺陷跟蹤，風險分析，并根據結果執行回歸測試，分析測試結果，撰寫測試報告。
3.能從多角度考慮模塊設計的完備性，靈活性，可擴展性，并提出改進建議。
2012/6 – 2013/9：XX有限公司[1年3個月]
所屬行業：互聯網/電子商務
集成部
系統測試工程師
1.熟悉軟件測試理論、流程和方法，有較強的邏輯分析能力、測試用例設計能力。
2.能根據系統業務需求獨立完成測試用例設計、執行，缺陷跟蹤，風險分析，并根據結果執行回歸測試，分析測試結果，撰寫測試報告。
3.能從多角度考慮模塊設計的完備性，靈活性，可擴展性，并提出改進建議。
教育經歷
2008/8— 2012/6 北京農學院 計算機科學與技術 本科
證書
2009/12 大學英語四級
篇3
1 簡介
1.1 范圍
測試用例的執行覆蓋高原夏菜無公害胡蘿卜栽培管理專家系統、日光溫室黃瓜無公害栽培管理專家系統、特色產業決策系統（綿花產業）、特色產業決策系統（綿花羊產業）等。
系統測試自2011年9月7日起對系統的功能及業務流程、界面風格、安全訪問控制等進行了黑盒測試，對系統的用戶使用數、頁面性能要求進行了相應的性能測試。
1.2 定義、首字母縮寫詞和縮略語
EXP 為特色產業專家系統與決策支持系統的英文簡寫。
1.3 概述
本測試評估從功能測試和性能測試的兩個角度來對我省特色產業專家系統與決策支持系統進行評估。內容主要包括：基于需求的測試覆蓋、建議的措施以及相關的測試結果圖示說明。
2 測試設備
PC1：硬件 CPU：PIV 1.50G，內存：512M硬盤：40G，軟件：Winserver 2003/IE8.0；
PC2：硬件 CPU：PIV 2G，內存：2G硬盤：300 G，軟件Winxpsp2 Winserver 2003/IE8.0。
3 測試環境
3.1 硬件配置
Web服務器硬件配置：TOMCAT服務器，CPU：PIV2.80，內存：1 G；硬盤：300 G；網卡：10/100 M自適應。
數據庫服務器硬件配置：PC臺式機，CPU：P43G，內存：1 G；硬盤：300 G；網卡：10/100 M自適應。
3.2 軟件配置
服務器軟件配置：開發工具：IBMWSAD5.0；JDK環境：j2se1.5或更高；
系統環境：Windows 2000/XP/2003；
Web服務器：Apache 2.4+tomcat6.0
數據庫系統：SERVER 2008。
3.3 測試方法
以黑盒測試為主，測試的重點集中在業務流程、數據提取和各功能模塊間的接口。其中單元測試由開發人員直接完成；功能模塊采用黑盒測試的常用方法；集成測試模塊采用非漸增式測試，偏重系統的接口和數據提取方面；系統測試主要體現在業務流程的測試，主要采用回歸測試。包括數據測試、功能測試、用戶界面測試、性能評測、安全性和訪問控制測試。
4 測試覆蓋分析
需求覆蓋率是指經過測試的需求/功能和系統分析中所有需求/功能的比值，通常情況下要至少達到99 %的目標。
被驗證通過的需求26個，需求總數26個。
需求覆蓋率=通過驗證的需求/需求總數=26/(26)×100 %=100 %(詳見表1)。
4.1 缺陷收斂曲線圖
4.2 缺陷生命周期圖
從缺陷生存周期來分析：整個缺陷數占比最多的是生存周期在1周的缺陷,總共161個，約占總數的75.23 %,說明開發組對缺陷的響應時間相對較快，能在較短的時間內對bug進行修復。
5 測試結論
5.1 安全性 做了用戶登錄安全訪問控制測試，即各種條件下的用戶登錄測試，系統安全性高。
篇4
認清“第三方”的責任
第三方測試以合同的形式制約了測試方，使得它與開發方存在某種“對立”的關系，所以它不會刻意維護開發方的利益，保證了測試工作在一開始就具有客觀性。第三方一般都不直接參加開發方系統的設計和編程，為了能夠深入理解系統，發現系統中存在得問題，第三方測試必須按軟件工程的要求辦事，以軟件工程的標準要求開發方和用戶進行配合，從而較好地體現軟件工程的理念。引入第三方測試后，由于測試方相對的客觀位置，由用戶、開發方、測試方三方組成的三角關系也便于處理以往用戶、開發方雙方糾纏不清的矛盾，使得許多問題能得到比較客觀的處理。
第三方測試不同于開發方的自測試。由于他熟悉設計和編程等，往往習慣于按一定的“程式”考慮問題，以至思路比較局限，難于發現“程式”外存在的問題。因為第三方測試的目的就是為盡量多地發現程序中的錯誤而運行程序的過程，可以更多的發現問題。隨著系統越做越大，客觀上講開發人員也無精力參與測試，同時也不符合大生產專業分工的原則。
第三方測試不同于用戶的自測試。用戶是應用軟件需求的提出者，對于軟件應該完成的功能是非常清楚的，是進行功能驗證的最佳人選。客觀情況是，大部分的用戶都不是計算機的專業人士，很難對系統的內部實現過程進行深入的分析。對系統的全面測試，功能測試僅僅是一個方面，還要包括并發能力、性能等多種技術測試。
如何組織管理
在測試的過程中，用戶、開發方與測試方形成了一個三角關系，從最終目標來講，三方是完全一致的，都是希望保證系統穩定運行。但在測試過程中，三方的關系卻是既對立又合作。
軟件測試的過程
為了保證測試的順利進行，測試方必須強化內部的組織管理。根據我們的經驗，完整的測試機構必須包括業務分析部門、技術支持部門、規劃設計部門和綜合后勤部門。
“第三方”測試什么
根據軟件的特性，第三方軟件測試工程可劃分為三種類型四個層次。
第一類是系統軟件、環境軟件和各類工具軟件等的測評。對這類軟件的評測重點是軟件產品的功能、性能和特點評測。
第二類是面向應用軟件系統的測評。這類軟件，具有很強的行業應用特性，往往是要由用戶與開發商簽定項目合同，開發商負責開發，用戶負責驗收。對這類軟件的評測，根據用戶對第三方的依賴程度，又可分為兩個層次。第一個層次只對應用軟件系統進行綜合、性能測試。第二個層次是對應用軟件系統進行質量監理與評測。
承擔該類軟件質量監理評測的第三方，承擔軟件過程質量監理的責任，在軟件生命周期過程中，從軟件定義開始，要對軟件過程從質量保證角度進行規范化的監督、管理和控制。評測工作不僅包括軟件生命周期各階段的評審，而且還要對程序系統，進行包括模塊白盒測試在內的系統集成、系統驗收等測試。
第三類是對軟件企業的CMM評估認證,也是最高層次的軟件評測。
了解測試評估
測試評估是軟件測試的一個階段性的結論，用所生成的測試評估報告，來確定測試是否達到完全和成功的標準。在測度評估階段向用戶提供強有力的支持，包括通過測試報告，驗證測試結果是否符合測試計劃中制定的測試標準；根據缺陷報告提供的測試結果數據，給出軟件質量和測試完整性的評估報告；特別在以下幾方面對測試的過程進行評測：
評估測試用例覆蓋：測試的目標是確保100%的測試用例成功地執行。主要考慮風險和嚴重性、可接受的覆蓋百分比。
評估代碼覆蓋：需要斷定測試目標期望的總的測試代碼行數，在測試中真正執行的代碼行數及其百分比，將此結果記錄在測試評估報告中。
篇5
關鍵詞：計算機；軟件測試
中圖分類號：TP311 文獻標識碼：A 文章編號：1007-9599 （2012） 18-0000-02
1 計算機軟件測試的概念
所謂軟件測試，主要是以發現程序錯誤為目的而執行程序的過程，是結合軟件開發過程中每一個階段的規格及軟件內部的結構進行認真設計的測試用例。因此，我們可以說，軟件測試就是在精心搭建的環境下對程序進行執行，以更好的發現軟件中的錯誤，對其可靠性給出鑒定。
2 軟件測試的流程
2.1 設計測試方案。設計測試方案是在軟件測試初始階段進行的，在這個工作中，首先要調研所需要應對的系統框架和業務模型，對測試需求進行收集。其次，根據測試需求制訂一個合理的測試計劃。具體來說，我們的測試團隊要對被測試項目有著提前的了解，而且開發部門也要配合測試部門的工作，提供各種系統規格書、系統總體介紹、網絡拓撲結構圖、用戶使用手冊、系統配置說明、應用部署與配置以及關鍵服務器及等文檔。經過與業務部門協商之后，就可以確定下來這次測試的目標，然后對這一目標進行細化，制定出各個階段的目標，并制定相應的指標要求。
2.2 開發測試場景。這主要是指開發測試腳本，是針對被測系統業務進行模擬、錄制、編程、參數化、腳本定制以及調試測的工作，通過測試場景的開發，可以使測試腳本實現對現實場景的真是模擬，而且我們還可以通過改變參數來控制并發數以及思考時間等屬性。
2.3 執行測試。這主要是按照預先制訂的測試方案，在完成測試環境以及測試場景之后進行的工作。
2.4 測試報告及分析。這一工作主要是在執行完測試之后進行的，主要的任務是對測試過程中所暴露的問題進行收集及分析。而測試報告則主要是對測試過程中監控報告以及報表的匯總，然后對其進行一定整理之后所得到的結論性文檔。
2.5 回歸測試。開發部門在分析了測試報告之后，會對軟件的缺陷進行了修復或者優化，使其具有更高的性能，而對于這種修復之后軟件的測試就是回歸測試。
3 計算機軟件測試的基本方法
3.1 按照階段進行劃分。如果按照階段對計算機軟件測試方法進行劃分的話，則可以分為單元測試、集成測試、系統測試、驗收測試、回歸測試、Alpha測試以及Beta測試。
（1）單元測試。這主要是指對軟件的基本組成單位進行測試，比如一個模塊。單元測試是動態測試中最基本，也是最重要的部分，它主要的目的是對軟件基本單元的正確性進行驗證。在單元測試中，由于需要我們了解程序的設計及編碼的細節，所以這一工作主要是由程序員進行。另外，單元測試還需要開發測試驅動模塊以及樁模塊進行輔助。在單元測試中，主要的方法包括控制流測試、排錯測試、數據流測試以及分域測試等。
（2）集成測試。集成測試主要進行于軟件系統集成過程中，它的作用是對單位之間接口的正確性進行檢查。一般來說，根據計劃，我們將在模塊集成為較大系統的過程中運行該系統，查看各個組成部分是否合拍。在這個過程中，使用的策略有自底向上以及自頂向下這兩種。
（3）系統測試。這主要是針對已經集成好的系統進行測試，進而對系統的性能及正確性進行檢查。由于這一測試的整體難度比較大，我們要制定合理的計劃，并嚴格按照計劃執行測試工作。在系統測試工作中，主要的方法有隨機測試、性能測試以及功能測試。
（4）驗收測試。這種測試的目的是主要是對軟件的購買者展示軟件的性能，確保其符合購買者的需求。在這個過程中，測試數據主要來自于系統測試中使用的數據。這是軟件在應用之前最后的測試。
（5）回歸測試。上文中已經對其概念進行了簡要的分析，這里將進一步對其進行分析。回歸測試的主要目的是檢測所進行的修改是否合理。在這個問題上，修改有著以下內涵：首先是修改達到了預期的目的，其次是修改不能夠對軟件其他功能的正確性產生影響。
（6）Alpha測試。這是在軟件開發即將完成的時候所進行的測試，在測試之后，一般仍然會有一些設計上的變更，在這一測試工作中，測試人員主要是最終用戶而不是程序員或者測試員。
（7）Beta測試。這是指在開發及測試在根本完成之后進行的測試，這種測試的工作一般由其他人員或者最終用戶來完成，不可以由測試員完成。
3.2 按照按測試方法進行劃分。按照測試方法進行劃分則可以分為白盒測試以及黑盒測試這兩種。
（1）白盒測試。這也被我們稱之為邏輯驅動測試或者結構測試，是基于覆蓋所有代碼、路徑、分支以及條件的測試。在白盒測試中，我們是清楚程序內部工作過程的，主要的目的是檢測其內部動作是否符合規格說明書的要求，至于軟件的功能是否符合要求則不屬于這一測試的范疇。常見的白盒測試方法有邏輯驅動以及基路測試等。
在使用白盒測試方法的時候，測試者必須對程序的內部結構進行檢查，并通過對其邏輯的檢查得到測試數據。在這種測試方法中，存在著以下不足：首先，對于程序是否符合設計規范，或者說程序本身就是錯誤程序的情況，我們是沒有辦法檢查的。其次，對于程序中因路徑遺漏而導致的錯誤，我們無法檢查。最后，某些和數據相關的錯誤我們沒有辦法檢查。在這一具體的工作中，常使用的工具有Junit Framework，Jtest等。
（2）黑盒測試。顧名思義，黑盒測試和白盒測試是相反的。在黑盒測試中，我們的測試目的不是為了檢查內部設計及代碼是否正確，而是檢查程序能否符合功能性方面的需求，因此，這種測試也被我們稱之為數據驅動測試或者功能測試。
在測試的過程中，我們將完全不考慮其內部特性，只是將程序作為一個黑盒子看待，然后在其接口進行測試，具體的工作就是檢查程序在接收到輸入數據之后能否產生正確的數據輸出信息。在黑盒測試方法中，常見的方法等價類劃分、因—果圖、邊值分析以及錯誤推測等。
由于黑盒測試方法屬于窮舉輸入測試，我們只有將所有的輸入都當成測試情況使用之后才能夠檢查出程序中所有的錯誤，而實際的測試情況有無窮多個，因此，我們除了要有合法的輸入之外，還要有不合法卻可能的輸入。一般常用的工具有WinRunner，Rational Robot，QuickTestPro等。
4 結語
由上文我們可以看出，軟件測試中的環節比較多，而且方法也有很大的差別。因此，做好計算機軟件測試工作并不是一件很輕松的事情，需要我們對各種軟件測試方法了如指掌。所以，我們還要不斷的學習，并加強探索，以一個嚴謹科學的態度去面對軟件測試工作，只有這樣才能真正的使軟件發揮其應有的作用，進而提升企業的競爭力。
參考文獻：
[1]何強.通信軟件自動化測試系統的研究與實現[D].中南大學，2009.
篇6
一、室內覆蓋工程質量監理的重要性
室內無線網絡的鏈路不平衡將會導致上行不足，此時手機有信號卻無法接入，無法有效吸收話務，導致室內覆蓋沒有發揮應有作用，在定位干擾問題時，對干擾源的特點和干擾通道的理解是非常重要的，但是傳統的分析只看到了表面現象，簡單地認為只存在外部干擾，并認為上行干放增益會產生上行干擾。由于對干擾成因存在錯誤的理解，以往室內覆蓋普遍采用調低上行干放增益的錯誤方法，導致大量的站點出現鏈路不平衡。由于存在以上缺陷，以往的室內覆蓋實際上是在進行低水平的大量建設，存在嚴重的隱患。針對這些問題質量監理應該采取多種手段，從根本上定位與解決信號傳輸通道的質量監理問題，提高室內覆蓋的質量，從而提升用戶體驗。
二、室內覆蓋工程設計階段的監理
在設計階段，監理人員首先要從現場勘察，設計文件審查和信源方案審查等方面，做好設計階段的監理工作。
（1）現場勘察監理
根據集成商提交的設計草圖，監理人員需和集成商一同到現場進行現場勘查和信號模測 并注意做好以下幾方面的工作。首先應該核對設計草圖中的大樓結構與現場環境是否相符，在室內擬安裝的天線位置處進行模擬信號測試，檢查設計草圖的天線密度是過密還是過疏。對地下室出口處的天線進行信號泄露測試，檢查出入口處的信號泄露強度是否在標準范圍內。監理還需要對大樓的平層及大樓的安全走梯進行現有信號測試，檢查是否需做室內信號覆蓋。在大樓地下室的各個出口處、各部電梯的中層和高層的出口處收集已有信號的導頻信號PN上報給建設單位的網管中心，以便網管中心選取室內覆蓋站點的施主宏基站及配置附近周圍宏基站的鄰區列表。對現場測試得到的數據，監理人員要做好詳細的記錄，以便能夠更好地審核設計文件。
（2）設計文件監理審查
室內覆蓋工程的施工地點多為大樓的地下室、電梯、線槽等，現場環境相對較為惡劣，且施工安全隱患較多。由于室內覆蓋工程的設計和施工都是由集成商負責完成，有些集成商為了增大工程的投資規模，增加自身收入，在設計文件中修改了現場信號模測數據，以增加天線數量，饋線的走線路由出現重復走線，增加布放不必要的饋線，修改分布系統中的信號衰減數量，增加不必要的7/8饋線。直放站的安裝位置設計不合理，增加不必要的干放設備。監理人員應注意根據現場勘查時已收集到的測試數據對設計圖進行審查，及時發現設計圖中存在的問題，并要求集成商改正，提高設計文件的質量。
（3）室內覆蓋工程信源方案的審查
室內覆蓋工程的信源設備主要有光纖直放站、無線直放站、微蜂窩。監理人員在審核各種信源建設方案時應注意審查光線直放站近端和遠端問的光路損耗不宜過大，光路長度不宜過長。需調整施主基站的信號搜索窗，同時，光路過長也會導致光路的損耗大。在無線直放站的監理中對施主天線接收到的宏基站信號，必須進行詳細測試，確定所接收的宏基站信號的主導頻單一穩定、信號強度、ECIO等數值滿足要求。另外，微蜂窩是本身能夠提供話務容量的設備。建設完成后，在微蜂窩覆蓋區域內會引入新的導頻PN信號要注意對室外周圍基站的臨區列表做相應調整，避免出現手機切換掉話現象。
三、室內覆蓋工程施工階段的監理
室內覆蓋工程施工環境特殊且大部分屬于隱蔽工程，所以施工過程需和大樓業主協商進行，施工過程需一次完成。室內覆蓋系統是通過饋線，耦合器和功分器，將信號均勻地傳輸到大樓的各個角樓。其中，饋線頭的制作質量是影響整個系統運行效果的主要因素。如果饋線頭制作的質量不合格，將使信號在饋線頭處發生反射、折射、散射等現象，增大信號在傳輸過程中的損耗，引起信號發生失真，增大信號的誤碼率。由于CDMA屬于白干擾系統，發射信號功率的增大，意味著系統容量和質量的降低。為了做好室內覆蓋工程的質量控制，在工程的前期監理人員要對施工單位的施工質量，饋線頭制作工藝等進行旁站監理。室內覆蓋系統中，每段饋線都有兩個饋線頭，如果在工程前期沒有對施工工藝質量和施工隊伍素質進行把關或者把關不嚴，等到工程建設完成后再來查找室內覆蓋系統的故障點，將是一件十分困難的事情。
在室內覆蓋工程建設完成后，監理人員要對室內覆蓋系統進行預驗收。面對如此龐大，分布在大樓各個角落的室內覆蓋系統，找出系統中的質量問題點可通過駐波儀對室內覆蓋系統進行檢查。反向高駐波信號在經過耦合器時，由于耦合端對信號功率衰減量較大，駐波信號經過耦合端時產生較大衰減，直通端對信號功率衰減量很小，可近視看作駐波信號是直接通過的。反向高駐波信號在經過功分器時，也要產生相應的衰減。當功分器位于室內覆蓋系統前端時，功分器對末端高駐波信號的衰減影響較大，故位于系統前端的功分器出口端都應進行駐波測試，當功分器位于系統末端時，對駐波信號的衰減影響較小，可直接在功分器的輸人口處進行駐波測試。所以，使用駐波儀對室內覆蓋系統進行駐波測試時應分段進行測試，通過對分布系統的高駐波點進行整改，能夠使整個室內覆蓋系統的信號質量大大提高。
四、室內覆蓋工程驗收階段的監理
在工程正式驗收前，監理人員應組織集成商開展預驗收工作，確保室內覆蓋工程的質量合格后再交付驗收。對交工資料的審查，應重點檢查其中的測試報告，對于大樓地下室，要求進行DT測試及出入口的信號外泄測試。對每份測試數據要求要有詳細全面的圖表和數據，對圖表和測試數據的分析結果指標應在規范要求范圍內。測試報告反映了室分站點的信號覆蓋效果，通過審查測試報告，能夠檢查室內覆蓋系統的工程質量是否達到要求。除此以外，還應注意檢查直放站和干放等設備的監控是否已經連接網管并工作正常。
結 語
室內覆蓋工程由于具有施工環境的特殊性，隱蔽工程較多且故障點難以查找，為了更好地開展工程監理工作，監理人員除了控制好設計、實施及驗收階段的質量監理，還應注意采取措施不斷增強施工人員的質量監理意識，從根本上改變以前不當的施工習慣，以達到保證施工質量的最終目的。
參考文獻
篇7
關鍵詞：可靠測試；優化；數據分析
高質量且高可靠性的企業應用程序系統是數字化時代非常重要的元素[1]。測試團隊在確保企業應用程序系統滿足既定標準或需求時會發揮非常重要的作用。隨著系統的規模和復雜性升級，其可靠性和質量要求必然成倍增長，這意味著測試團隊需要開發更有效的測試方法。一個完整的測試過程包括數據記錄、數據維護、數據驗證等多個方面。測試數據管理策略對于測試數據的記錄必須是全面的，這也為后期的數據分析挖掘提供了支撐。
陳翔等人在文獻[2]中重點闡述了回歸測試中用例優先排序（test case prioritization，簡稱TCP）問題。從源代碼、需求和模型三個角度對TCP問題進行分類，重點分析了回歸測試中測試資源缺乏時的TCP問題。另外，潘偉豐等人在文獻[3]中提出了基于錯誤傳播網絡的測試用例排序方法。該方法在類粒度將軟件抽象成加權類依賴網絡（weighted class dependency network， 簡稱WCDN）模型，并基于WCDN分析錯誤在網絡上的傳播行為，構造錯誤傳播網絡（bug propagation network，BPN）。實例研究表明，基于錯誤傳播網絡的測試用例排序方法在錯誤檢出率上相比于其他經典方法有一定的提高，并且具有較好的穩定性。一個全面的用例排序方法，能準確地將當前的軟件質量反映到執行用例的優先級上[4-5]。通過使用正確的TCP策略測試團隊能夠提供及早發現缺陷，在整個產品開發過程中，為提供更簡單的方法去解決系統缺陷提供支撐。因此，擁有正確的TCP策略對測試團隊乃至公司都至關重要，能加快系統周期并大幅削減成本。然而在現有的研究工作中，TCP策略問題主要集中在回歸測試階段，但是回歸測試處于整個測試過程的末端[6]。由于回歸測試時對于本系統缺陷分布情況有非常清晰的概念，但是由于處于末端，對于測試團隊的優化畢竟有限。同時測試團隊與研發團隊往往是單線交流，即研發團隊待測系統，測試團隊極少參與提高研發團隊的開發質量。
因此，可以從測試用例執行策略和測試結果反向優化開發策略兩個方面展開研究，并提高系統可靠性。測試用例執行順序問題是測試執行策略中非常重要的部分，在測試項目中持續優化測試用例執行順序可以提早發現潛在的缺陷。同時由于測試團隊對于項目整體的理解更為透徹，對缺陷的總體分析可以幫助研發團隊在類似問題上處理地更為妥善。測試團隊在需求分析階段的有效介入，將從源頭上提高系統的質量和可靠性。
1 測試執行策略優化
測試中的關鍵問題是第一時間發現被測系統不符合規范要求的內容。測試經理在測試規劃時是通過大量的測試用例保證測試的覆蓋率。持續優化測試用例執行順序是在保障測試覆蓋率的同時，合理地安排測試用例地執行順序，即TCP問題。文章提出將項目測試分為三個階段，在項目測試的初期、中期、后期三方面分別進行優化TCP，最終優化整個測試執行策略。
如圖1 所示，項目測試初期，分析測試用例的歷史數據得到測試用例的執行潛在價值，優先執行潛在價值高的測試用例。比如在其它項目中執行某些用例時，發現了系統不符合規范要求的部分，并提交了缺陷。在新的測試用例執行時，應首先執行這類測試用例以便快速發現系統缺陷。項目測試中期，分析本項目當前缺陷情況得到各個系統功能模塊的缺陷發生概率。優先執行缺陷分布較多的功能模塊相關的測試用例。項目測試后期，即回歸測試階段，需結合各個系統功能模塊在本項目和歷史項目中的缺陷發生概率，在保證一定回歸比率的情況下，綜合考慮本項目和歷史項目的分析，優先回歸測試缺陷發生概率較高的模塊。
2 需求分析優化
項目測試工作通常被安排在項目研發工作之后，測試團隊的主要工作也僅僅是將測試結果中發現的缺陷情況報告給研發團隊，并沒有對缺陷情況進行分析，可能使得類似的缺陷在不同的項目中反復出現。因此測試團隊在提供測試報告的同時，對各個功能模塊中所發現的缺陷進行分析，并在新項目立項初期給出系統模塊開發時的缺陷概率，幫助研發團隊在需求分析階段重點考慮高缺陷概率的模塊開發和模塊間的協作，從源頭上降低缺陷發生的概率。測試團隊與研發團隊的雙向反饋將優化產品設計的需求分析階段，提高系統的可靠性，如圖2所示。
圖2 測試團隊和研發團隊雙向通道
3 結束語
文章從優化測試用例執行順序和測試結果優化需求分析兩個方面，闡述了現在系統開發中提高系統可靠性的重要方法。測試數據的管理是一座金礦，對測試數據的深入分析可以讓整個測試過程不再是靜止的，而是可以動態調節以應對更復雜的情況，同時深入分析測試結果也可以建立測試研發的雙向通道，形成良性循環。最終可以超預期地提交高質量的系統，節約運營成本，完成市場搶占。
參考文獻
[1]K.Krishna Murthy， Janardhana S Channagiri， "test data management： Enabling reliable testing through realistic test data"Building Tomorrow's Enterprise， Oct 2009.
[2]陳翔，陳繼紅，鞠小林，等.“回歸測試中的測試用例優先排序技術述評”[J].系統軟件與軟件工程，2013（8）.
[3]潘偉豐，李兵，周曉燕，等.“基于錯誤傳播網絡的回歸測試用例排序方法”[J].計算機研究與發展，2016（3）.
[4]朱海燕，范輝，謝青松，等.“測試用例排序的研究”[J].計算機工程與科學，2008（1）.
篇8
二年以上工作經驗 |男| 29歲（1986年6月9日）
居住地：上海
電 話：153********（手機）
E-mail：
最近工作 [ 1年7個月 ]
公 司：XX計算機軟件有限公司
行 業：計算機服務(系統、數據服務、維修)
職 位：軟件測試
最高學歷
學 歷：本科
專 業：軟件測試
學 校：西北大學
自我評價
本人熟悉軟件開發測試流程，豐富的自動化測試經驗，善于學習。能在成功與失敗中完善自己，活潑開朗，樂觀向上，適應力強，勤奮好學，認真負責。待人誠懇，做事踏實細心，對工作有熱情有責任心。
求職意向
到崗時間： 一周之內
工作性質： 全職
希望行業： 計算機軟件
目標地點： 上海
期望月薪： 面議/月
目標職能： 軟件測試
工作經驗
2012 /12—至今：XX計算機軟件有限公司[ 1年7個月]
所屬行業：計算機服務(系統、數據服務、維修)
測試部 軟件測試
1.負責需求分析，制定測試計劃，編寫測試計劃和測試案例；
2.負責測試環境的搭建；
3.負責使用JIRA 缺陷管理系統, 管理跟蹤BUG；
4.負責系統的功能測試，以及處理客戶的回饋，重現問題；
5.負責熟練使用LINUX腳本語言，實現測試環境的自動安裝和定時運行，并進行日志的查看及排錯等；
6.負責根據用戶需求，編寫用戶使用說明手冊；
7.負責系統的安裝及配置,負責客戶版本升級。
2011 /1—2011 /12：XX軟件科技有限公司[ 11個月]
所屬行業：計算機軟件
事業部 軟件測試
1、負責根據軟件開發年度進程表，與美國微軟測試及開發團隊溝通，確定各階段測試目標；
2、負責在項目測試過程中，制定測試計劃，參與測試用例的編寫、修改和審核；
3、負責定期組織技術交流會議，以提高組員工作效率；
4、負責及時處理客戶對軟件提出的問題，執行測試定位問題,以幫助產品的修復。
2010 /7—2011 /1：XX網絡游戲有限公司[ 6個月]
所屬行業：娛樂/休閑/體育
技術部 軟件測試
1、負責了解軟件的測試流程，并制定測試流程；
2、負責編寫測試用例，BUG提交給開發人員；
3、負責開發人員修復，進行回歸測試；
4、負責根據需求寫測試大綱、編寫測試用例、測試報告。
教育經歷
2006 /9--2010 /7 西北大學 軟件測試 本科
證 書
2009 /6 大學英語六級
2008 /12 大學英語四級
篇9
關鍵詞：軟件代碼審查；代碼審查過程；代碼審查問題
中圖分類號：TP311.52文獻標識碼：A文章編號：1007-9599 (2012) 03-0000-02
Discussion on the Code Review of Software Static Testing
Yuan Zhengjiang
(Jiangnan Institute of Electrical and Mechanical Design,Guiyang550009,China)
Abstract:This paper describes the software code to examine the role,content,code review process,and lists some common problems of code review.
Keywords:Software code review;Code review process;Code review problem
一、引言
軟件測試常用方法可分為動態測試和靜態測試，只有動態測試和靜態測試有效結合，才能更好的完成軟件測試工作。代碼審查是軟件靜態測試中常用的軟件測試方法之一，代碼審查時，只要測試人員方法得當、足夠細心，往往能夠產生意想不到的效果。
二、代碼審查的作用
代碼審查是在不執行軟件的條件下有條理的仔細審查軟件代碼，從而找出軟件缺陷的過程。
代碼審查可以找出動態測試難以發現或隔離的軟件缺陷。在開發過程初期讓測試人員集中精力進行軟件代碼審查非常有價值：可以提高代碼質量；在項目的早期發現缺陷，將損失降至最低；促進團隊溝通、促進知識共享、共同提高。
代碼審查還可以為動態測試時設計和執行測試用例提供思路。通過代碼審查，可以確定有問題或者容易產生軟件缺陷的特性范圍。
三、代碼審查的過程
代碼審查過程可分為：代碼審查策劃階段、代碼審查實施階段以及代碼審查總結階段。
（一）代碼審查策劃階段
1.項目負責人分配代碼審查任務；
2.確定代碼審查策略：依據軟件開發文檔，確定軟件關鍵模塊，作為代碼審點；將復雜度高的模塊也作為代碼審查的重點；
3.項目負責人確定代碼審查單，審查內容一般可包括：
（1）可追溯性：
――代碼是否遵循詳細設計？
――代碼是否與需求一致？
（2）邏輯：
――表示優先級的括號用法是否正確？
――代碼是否依賴賦值順序？
――“if…else”和“switch”使用是否正確清晰？
――循環能否結束？
――復合語句是否正確地被花括號括起來？
――case語句是否所有可能出現的情況均已考慮？
――“goto”是否使用？
（3）數據：
――變量在使用前是否已初始化？
――變量的聲明是否按組劃分為外部的和內部的？
――除最明顯的聲明外，是否所有聲明都有注釋？
――每個命名是否僅用于一個用途？
――常量名是否都大寫？
――常量是否都是通過“#define”定義的？
――用于多個文件中的常量是否在一個頭文件中定義？
――頭文件中是否存在可執行的代碼？
――定義為指針的變量是否作為指針使用（而不是作為整數）？
――指針是否初始化？
――釋放內存后是否將指針立即設置為NULL（或0）？
――傳遞指針到另一個函數的代碼是否首先檢查了指針的有效性？
――通過指針寫入動態分配內存的代碼是否首先檢查了指針的有效性？
――宏的命名是否都大寫？
――數組是否越界？
（4）接口：
――在所有的函數及過程調用中，參數的個數都正確嗎？
――形參與實參類型匹配嗎？
――參數順序正確嗎？
――如果訪問共享內存，是否具有相同的共享內存結構模式？
（5）文檔：
――軟件文檔是否與代碼一致？
（6）注釋：
――注釋與代碼是否一致？
――用于理解代碼的注釋是否提供了必要的信息？
――是否對數組和變量的作用進行了描述？
（7）異常處理：
――是否所有可能的錯誤都已加以考慮？
（8）內存：
――在向動態分配的內存寫入之前是否檢查了內存申請是否成功？
――若采用動態分配內存，內存空間分配是否正確？
――當內存空間不再需要時，是否被明確的釋放？
（9）其它：
――是否檢查了函數調用返回值？
――所有的輸入變量都用到了嗎？
――所有的輸出變量在輸出前都已賦值了嗎？
4.確定代碼審查進度安排，項目負責人負責安排代碼審查的進度。
（二）代碼審查實施階段
1.代碼講解：軟件開發人員詳細向測試人員講解如何以及為何這樣實現，測試人員提出問題和建議。通過代碼講解，測試人員對被審查的軟件有了一個全面的認識，為后續代碼審查打下良好的基礎。
2.靜態分析：一般采用靜態分析工具進行，主要分析軟件的代碼規模、模塊數、模塊調用關系、扇入、扇出、圈復雜度、注釋率等軟件質量度量元。靜態分析在代碼審查時應優先進行，有利于軟件測試人員在后續代碼審查時對軟件建立宏觀上認識，在審查中容易做到有的放矢，更易于發現軟件代碼中的缺陷。
3.規則檢查：采用靜態分析工具對源程序進行編碼規則檢查，對于工具報出的問題再由人工進行進一步的分析以確認軟件問題，是一種比較有效的方法。
4.正式代碼審查：代碼審查可分兩步進行：獨立審查和會議審查。根據情況，這兩步可以反復進行多次。
（1）獨立審查：測試人員根據項目負責人的工作分配，獨自對自己負責的軟件模塊進行代碼審查。測試人員根據代碼審查單，對相關代碼進行閱讀、理解和分析后，記錄發現的錯誤和疑問。
（2）會議審查：項目負責人主持召開會議，測試人員和開發人員參加；測試人員就獨立審查發現的問題和疑問與開發人員溝通，并討論形成一致意見；對發現的問題匯總，填寫軟件問題報告單，提交開發人員處理。
5.更改確認：開發人員對問題進行處理，代碼審查人員對軟件的處理情況進行確認，驗證更改的正確性，并防止出現新的問題。
（三）代碼審查總結階段
代碼審查工作結束后，項目負責人總結代碼審查結果；編寫測試報告，對軟件代碼質量進行評估，給出合理建議。
把代碼審查提出的所有問題、亮點及最終結論詳細的記錄下來，供其他軟件項目代碼審查借鑒。必要時，可建立常見軟件代碼缺陷數據庫，為軟件代碼審查人員培訓和執行代碼審查提供數據支持，也可以為軟件編碼規則制定規范提供實踐依據。
四、代碼審查中的常見問題
如果軟件測試人員熟悉常見的軟件代碼審查問題，對代碼審查效率是很有幫助的。筆者根據自己的應驗，列舉部分常見軟件代碼審查問題如下（僅供參考）：
（1）浮點數相等比較：可能造成程序未按設計的路徑執行；
（2）因設計原因導致某些代碼不能執行：如邏輯表達式永遠為真（或假）造成某分支不能執行、代碼前面有return語句、某模塊從未被調用等；
（3）switch語句沒有break語句（有意如此設計時除外）；
（4）數組越界使用：數組越界容易發生在數組下標是計算得到的情況下，而且審查時很難發現這種代碼缺陷，應加以重視；
（5）變量未初始化就使用或者是條件賦值就使用；
（6）程序中存在未使用的多余變量；
（7）復合邏輯表達式沒有使用括號造成運算順序錯誤；
（8）有返回值的函數中return沒有帶返回值；
（9）邏輯判別的表達式不是邏輯表達式；
（10）動態分配的內存沒有及時釋放：忘記寫內存釋放代碼或由于其它邏輯缺陷導致內存釋放代碼未得到執行；
（11）沒有對緩沖區溢出進行必要的防護；
（12）訪問空指針，即指針未初始化就使用；
（13）指針指向的內存釋放后，未將指針置為NULL：其它函數訪問該指針時，判斷指針不為空，當作有效指針使用，會造成內存訪問錯誤；
（14）注釋說明與程序代碼實現不一致，甚至相反；
（15）循環存在不能跳出的可能，程序中沒有相應的保護機制。
五、結束語
篇10
關鍵詞： 軟件潛在分析； 軟件可靠性； 軟件安全性； 故障樹分析； 調試器
中圖分類號： TN915.04?34； TM417 文獻標識碼： A 文章編號： 1004?373X（2016）15?0081?05
Abstract： In the process of C programming language software potential analysis， the management of the defect generating process is often neglected， and the progress of the defect analysis work is slow. In order to solve the above problems， the software potential analysis tool based on C programming language was designed and developed. In the paper， the process from the generation source causing C programming language software defect to accident occurrence is decomposed， in which the static analysis method is used to find out the source code defect， the reliability defect is analyzed with failure modes and fault tree method， and the security defect is tracked with dynamic test. The corresponding tool was designed and implemented after the determination of analysis method. The tool was tested and verified with an instance. The verification results show that the tool， in each stage of the defect， can manage and analyze the potential defects effectively and improve the efficiency of the software potential analysis， and provides the guarantee for the quality of critical software safety.
Keywords： software potential analysis； software reliability； software security； fault tree analysis； debugger
0 引 言
在航空、航天等安全關鍵領域，軟件承擔的任務包括數據采集、導航控制和通信指揮等任務。隨著科技的發展，軟件已經成為這些系統的神經中樞，發揮著越來越重要的作用。在安全關鍵系統的運行過程中，若其軟件一旦發生故障，就可能造成十分嚴重的后果[1]。然而，目前的軟件缺陷分析方法及工具均從某個單一的角度檢測軟件缺陷。在實際的可靠性和安全性測試中，不可能只采用其中的一種分析方法來斷定軟件的缺陷，而需要將多種分析方法有效結合，在最大程度上保證安全關鍵軟件的質量[2]。
1 需求分析
1.1 設計目標
首先，系統能夠提供以XML為接口的缺陷導入，并對工程項目代碼的靜態分析結果進行處理，對代碼的安全缺陷進行等級劃分，實現層次化的缺陷識別，統一缺陷類型。其次，該平臺能夠建立準確的故障分析模式和故障樹分析方法，在測試過程中提高軟件故障分析及安全性測試的高效性和全面性，實現全數字仿真測試環境的無縫集成[3]。并提供便利的輔助功能，實現測試腳本的生成、測試用例的生成、測試報告單的生成。
1.2 業務流程
基于C語言的潛在分析工具共有兩條主線流程，如圖1所示。靜態分析結束后，通過XML接口將缺陷導入本系統，可以查看缺陷所在的源文件、根據已整理完成的缺陷分級獲得缺陷嚴重等級、對缺陷進行處理并填寫問題報告單、編寫測試用例等。使用系統提供的工具在故障模式輔助下的故障樹建模，并計算故障樹的最小割集，生成測試用例[4]。以上2個步驟生成測試用例后，在全數字仿真測試平臺的基礎上編寫測試腳本，使用調試器進行動態測試，在測試過程中可進行單步跳過和單步進入等，并觀察寄存器狀態、內存值和變量值，測試結束后分析測試數據。
1.3 功能分析
系統是在全數字仿真測試環境采用軟件仿真技術的基礎上構建的，仿真平臺能夠模擬SPARCV7處理器以及其他片上與片外設備的功能和時序關系，為最終的測試腳本運行提供仿真的運行平臺[5]。在此基礎上，本平臺包含下述4個系統，為軟件的潛在問題分析與處理提供服務，功能結構如圖2所示。
1.4 靜態分析結果處理
靜態分析結果處理需要具備的功能包括項目管理、缺陷分析處理、測試用例管理、問題報告單管理和測試結果分析。其中，項目管理的作用是對每個軟件程序可以在該模塊建立相應的項目來管理該軟件項目的問題；缺陷分析處理用于提供工具輔助測試人員對缺陷結果進行處理；測試用例管理主要管理測試用例，對缺陷對應測試用例的管理，包括添加、刪除和查詢缺陷測試用例的功能；能夠通過提供的測試用例模板輔助生成測試用例。
1.5 故障模式及故障樹分析
靜態分析結果處理需要具備的功能包括故障樹建模、輔助建立故障樹及故障樹分析。其中故障樹建模提供用戶繪制故障樹的平臺，包括建模、導入保存節點屬性的編輯和故障樹工具集管理等。輔助建立故障樹指故障樹建模過程中，使用知識庫中已經保存的故障模式及其對應的故障樹，輔助用戶使用故障樹分析方法建立故障樹模型，該功能模塊分為故障樹對齊、完整性檢查、根據故障樹節點搜索故障樹、根據故障模式搜索故障樹、保存節點對應的故障模式。故障樹分析是分析可靠性缺陷的主要模塊，是故障樹分析方法最核心的部分，包括：生成最小割集、計算事件概率、故障樹解析和測試用例生成[6]。
2 系統設計
2.1 硬件整體架構
缺陷分析工具的設計采用基于服務器?客戶端的設計方案。其中服務器主要提供靜態分析服務和測試數據的存儲。靜態分析服務一般由靜態分析軟件提供，包括靜態分析服務、數據存儲服務。客戶端主要負責進行實際的測試，包含：靜態分析結果處理、故障模式及故障樹分析、基于故障注入的動態測試功能。軟硬件的整體架構如圖3所示。
2.2 軟件設計
客戶端軟件實現了平臺的主要功能，其設計分為三層，其結構見圖4。其中用戶層為用戶提供直接的服務；功能層實現了本安全性測試平臺的主要功能，供用戶層模塊使用。
軟件是基于EclipseRCP進行開發的，采用GEF框架進行建模。
2.3 功能設計
根據系統的需求，將工具的功能劃分為靜態分析結果處理、故障模式及故障樹分析、動態測試調試器和基礎數據管理。
靜態分析結果包括項目管理、缺陷分析模塊、測試用管理模塊、問題報告單模塊和測試結果分析。
故障模式及故障樹分析包括故障樹建模、輔助建立故障樹及故障樹分析。
動態測試調試器包括工程管理、斷點管理、調試過程控制及調試信息管理。
基礎數據管理的劃分包括用戶管理、角色管理、缺陷分級管理及故障模式的管理。
3 系統實現
3.1 功能實現
3.1.1 靜態分析結果處理
靜態分析結果處理需要具備的功能包括項目管理、缺陷分析處理、測試用例管理、問題報告單管理和測試結果分析[7]。
缺陷分析處理：按文件劃分顯示缺陷通過SQL的group by file查詢實現。
測試用例管理：根據測試用例模板輔助生成測試用例時，首先要根據缺陷代碼查詢其對應的所有用例模板，點擊模板后，將模板內容填充至界面中，點擊添加即可添加。另外，測試用例模板的字段與測試用例的字段相同。
問題報告單管理：問題報告單和測試用例的導出通過iText完成。問題報告單和測試用例的表現形式為word中的表格，生成報告的核心是表格的創建。在表格的創建過程中，需根據用戶的處理自動填寫至相應位置。
測試結果分析：首先按照給定條件查詢數據，再使用JfreeChart包繪制餅圖或柱狀圖。
3.1.2 故障模式及故障樹分析
故障樹建模采用GEF實現，GEF是一個圖形編輯框架。根據實際需要，系統提供了事件節點、門節點、轉入轉出三類節點和節點間的連線。
輔助建立故障樹，該模塊的實現涉及較多的數據庫操作，故障樹采用Sftree類描述，其包括多個表示節點的SftElement類，節點之間的關系為SftRelation類。
最小割集的生成是根據用戶構建的故障樹進行分析，查找導致頂事件發生的所有基本事件的集合。其步驟大致為：輸入故障樹，判斷故障樹是否合法，若不合法則直接返回，否則進行下一步；利用“下行法”求該故障樹的最小割集；輸出得到的最小割集，并顯示在對話框中。
3.1.3 基礎數據管理
基礎數據管理模塊用于數據庫管理員對輔助測試數據的編輯，系統在與數據庫進行交互過程中采用了Hibernate包[8]。對于數據庫表的增刪改，本系統采用了Common框架的實現方式。Common框架的流程如圖5所示。
3.2 SNMP協議網絡設備管理模塊的實現
3.2.1 最小割集生成算法
故障樹完整性檢查完畢，需要求出最小割集，采用“下行法”進行計算，其步驟如下：
（1） 創建保存最小割集的列表cutset，cutset保存了若干個AnalysisNode對象，該對象保存了一個最小割集，包括這個最小割集中的所有節點nodes及每個節點到達根節點的路徑path；
（2） 從頂事件root開始，若root為null，則返回結束；不為null，則將創建AnalysisNode對象set，將root加入set的節點列表，并設置root的path為root，將set加入cutset列表；
（3） 獲得最小割集cutset中不全為根節點的currentset，若其為null，則轉步驟（7），否則轉步驟（4）；
（4） 將currentset從cuteset中移除，獲得currentset的首個非葉節點dealnode及門節點gatenode。若gatenode為“與門”，轉步驟（5）；若為“或門”，轉步驟（6）；
（5） 創建一個新的最小割集newset，遍歷currentset和“與”門的所有子節點inode，若其為dealnode則continue；將inode加入到newset的節點中，其路徑不變；遍歷gatenode的子節點gnode，將gnode加入到newset的節點中，并設置其路徑為dealnode的path與gnode之和，將newset加入到最小割集列表cutset中，轉步驟（3）；
（6） 遍歷“或”門的所有子節點snode，并創建一個新的最小割集newset，遍歷currentset的所有子節點inode，將其加入到newset的節點中；并獲得inode的路徑path，也加入到newset的path中；遍歷結束后將snode加入newset節點中并設置其path為dealnode路徑，將newset加入最小割集列表cutset，轉步驟（3）；
（7） 返回cutset，cutset即為該故障樹的最小割集列表。
3.2.2 混編文件生成算法
數字仿真測試平臺記錄了源代碼與混編碼的對應方式，需要根據接口生成源代碼與匯編代碼的混合代碼，其中一條源代碼可能對應著多個匯編代碼塊，需要一次讀取源文件，查找其相應的混編文件并進行顯示。生成混編文件的步驟如下：
（1） 獲得源文件，將其路徑添加到數組，保證創建混編文件的線程只有一個；
（2） 創建混編文件輸出流及源文件的輸入流；
（3） 遍歷源碼行號[i，]根據文件名和行號得到自[i]開始合理的第一條源碼行號[j，]若[j=0]或[i=j+1，]則將[i][到]lineSum行源文件寫入混編文件輸出流，轉步驟（6）；否則，將[i]至[j]行內容寫入混編文件輸出流中；
（4） 根據源碼行對應的目標碼代碼的數組，獲得代碼塊的數組，遍歷代碼塊，獲得起始目標碼地址m_start_address，設置address_temp為m_start_address，轉步驟（5）；
（5） 遍歷代碼塊，根據PC地址address_temp獲取該行匯編文件，加入混編文件輸出流，并設置address_temp為下條指令的地址（因為存在多條代碼塊時為call指令）；
（6） 將混編文件輸出流寫入文件，混編文件生成過程完成。
4 測試與驗證
4.1 測試準備
（1） 測試環境包括服務器和客戶端兩個部分，硬件環境和軟件環境如表1所示。
（2） 在服務器上安裝數據庫系統，采用Klocwork作為靜態分析軟件，因此也需要安裝Klocwork的服務器端軟件。在客戶端上，需要安裝本系統和Klocwork的客戶端。
4.2 測試實例
（1） 靜態分析結果處理部分的驗證
如采用Klocwork9進行靜態代碼分析，對其加入了支持GJB9369的擴展規則，分析結果通過K9提供商提供的軟件，已經轉為本工具可接受的XML文件。導入后發現存在源代碼缺陷的文件共有4個，總計10個缺陷。由于在基礎數據中設置代碼為“UNINIT.STACK.MUST”的缺陷嚴重度為等級1，對其進行缺陷確認并填寫問題報告單，對于等級2的確認為非缺陷，等級3的缺陷忽略。
在對靜態分析結果進行處理后，可通過兩種途徑對處理結果進行驗證，一是通過打印問題報告單和測試用例與填寫內容進行比較確認；二是通過數據統計進行。經過對比和驗證，靜態分析出的源代碼缺陷處理結果正確的生成了報告和統計圖。
（2） 故障模式和故障樹分析驗證
故障模式和故障樹分析驗證中，將“火箭發動機誤點火”作為頂事件進行分析，造成頂事件發生的事件是外部因素或提前點火，其中外部因素不做分析，僅對提前點火事件進行分析。提前點火事件可能由硬件故障或軟件故障造成，硬件故障的原因有蓄電池接通和點火電路允許，而軟件故障可能是由內存溢出或線程非法造成。在故障樹的分析過程中，可根據節點名稱或故障模式輔助建模，在建模結束后，為每個基本事件設置發生的概率。建模結束后對故障樹進行完整性檢查后即可進行故障樹分析，分析結果如表2所示。
（3） 動態調試的驗證
首先需要針對前兩步添加的測試用例編寫相應的測試腳本。在源代碼缺陷分析中遇到的未初始化變量 unsigned int [x，]對于該缺陷的驗證可通過兩種方式：一是在非故障注入的腳本運行過程中，可通過單步調試查看[x]變量的變化；二是通過針對該問題編寫測試腳本，需按上述格式填寫，再從調試器中打開運行，觀察測試記錄文件。首先，在 rs232.c的第36行加入斷點，點擊run運行至該行號后，單步跳過至37行。然后，下文為腳本的片段，首先在2～3內取變量[x]的值，再通過故障注入改變[x]的值，再次取出變量[x]的指令。
源代碼缺陷可能導致內存變量發生故障，因此，需要對靜態分析處理中構建的測試用例進行確認。在動態測試結束之后，還需要根據結果對測試用例進行確認，即確認靜態分析或故障樹分析的軟件缺陷的測試用例是否通過。通過基于故障注入的動態測試，可在測試過程或其記錄的文件中觀察出故障發生時系統的運行狀態，從而保證系統的安全性。而其他分析，如源代碼缺陷的分析和故障模式及故障樹分析可以在安全性缺陷分析采用的基于故障注入的動態測試中進行驗證，驗證過程即跟蹤了缺陷的產生到故障的出現。
5 結 論
航天航空等關鍵領域，軟件缺陷直接影響著整個系統。本文由缺陷產生到發生故障的過程著手，進行了全程跟蹤，并對這些安全關鍵軟件測試中使用的分析方法進行了深入的整合。工具采用接口化的方法，使得各種分析方法能夠靈活組合；并模型化數據，建立了統一的數據管理平臺，使得分析數據以標準化形式表示，增加了數據使用的延展性，便于多領域的故障數據管理；建立了多階段的分析概念，把缺陷分析流程化，多維化。在可靠性和安全性測試流程中輔助分析人員針對C語言缺陷進行完整的分析和記錄。
參考文獻
[1] 陳靜.Klocwork在嵌入式軟件靜態測試中的應用[J].電子與電腦，2013，38（5）：89?92.
[2] 樊林波，吳映程，趙明.軟件可靠性與安全性的區別分析及其證明[J].計算機科學，2008，35（9）：285?288.
[3] 何鑫，鄭軍，劉暢.軟件安全性測試研究綜述[J].計算機測量與控制，2011，19（3）：493?496.
[4] 仉俊峰，洪炳，喬永強.基于軟件方法故障注入系統[J].哈爾濱工業大學學報，2011，38（6）：873?876.
[5] 漆蓮芝，張軍，謝敏.故障樹分析測試用例生成技術研究與應用[J].信息與電子工程，2010（8）：594?597.
[6] 姜興杰，楊峰輝.軟件可靠性分析與設計[J].現代電子技術，2011，34（7）：135?137.
