導(dǎo)語：如何才能寫好一篇測試報告缺陷分析，這就需要搜集整理更多的資料和文獻(xiàn)，歡迎閱讀由公務(wù)員之家整理的十篇范文，供你借鑒。

篇1

【關(guān)鍵詞】軟件測試 測試報告 測試流程

1 引言

軟件測試是軟件開發(fā)過程的重要組成部分，是用來確認(rèn)一個產(chǎn)品的品質(zhì)或性能是否符合開發(fā)之前所提出的要求。對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，某種程度上測試工作的好壞直接影響了軟件產(chǎn)品的交付和用戶的滿意度。因此，如何做好測試工作，使測試在軟件工程中順利進(jìn)行，輔助軟件開發(fā)工作是我們每個軟件人員應(yīng)該考慮的問題。

2 軟件測試的目的

（1）確認(rèn)軟件的質(zhì)量，確認(rèn)軟件做了你所期望的事情，確認(rèn)軟件以正確的方式來做了這個事件。

（2）提供信息，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風(fēng)險評估所準(zhǔn)備的信息。

（3）軟件測試不僅是在測試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過程。軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質(zhì)量的。

3 軟件測試的對象

軟件測試并不等于程序測試。軟件測試應(yīng)該貫穿整個軟件定義與開發(fā)整個期間。因此需求分析、概要設(shè)計、詳細(xì)設(shè)計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細(xì)設(shè)計規(guī)格說明以及源程序，都應(yīng)該是軟件測試的對象。

4 軟件測試流程

軟件測試工作并不是在軟件代碼開發(fā)完畢后才開始的，這一點(diǎn)是很多軟件人員的誤區(qū)，需要明確一下，它其實是在項目進(jìn)入軟件實現(xiàn)階段就開始了，項目進(jìn)入軟件實現(xiàn)階段的時候，就應(yīng)該啟動軟件測試工作了。

下面根據(jù)筆者的測試經(jīng)驗，詳細(xì)闡述一下軟件測試的流程、每個階段需要做的工作及整個測試過程產(chǎn)生的文檔。

4.1 計劃與設(shè)計階段

4.1.1 召開測試啟動會議

當(dāng)項目進(jìn)入軟件實現(xiàn)階段（編碼），測試經(jīng)理召集項目經(jīng)理、開發(fā)經(jīng)理開會確定測試交接時間，開發(fā)團(tuán)隊與測試團(tuán)隊交接測試內(nèi)容，對測試目標(biāo)達(dá)成一致，商討測試計劃的可行性，統(tǒng)一項目組的目標(biāo)和測試的工作重點(diǎn)。進(jìn)行規(guī)模預(yù)估并成立測試團(tuán)隊，完成《測試計劃》和《測試方案》。

4.1.2 設(shè)計測試用例

明確了測試需求和測試計劃，在需求分析文檔確立基線以后，測試組需要針對測試需求編寫全部測試用例，在實際的測試中，測試用例將是唯一實施標(biāo)準(zhǔn)。

4.2 實施測試階段

4.2.1 實施測試用例

實施測試用例將花費(fèi)測試組絕大部分時間，這些工作都是建立在前期很多計劃工作的基礎(chǔ)上。當(dāng)測試用例全部編寫完成后，測試工程師根據(jù)測試計劃中分配給自己的測試任務(wù)，實施相應(yīng)的測試用例，并記錄測試結(jié)果。

4.2.2 填寫測試記錄

測試人員在進(jìn)行具體的測試工作時，需要將測試內(nèi)容填寫在測試記錄表中，直到所有的測試執(zhí)行工作結(jié)束。

4.2.3 提交BUG清單

在具體的測試過程中，測試人員發(fā)現(xiàn)BUG后，需要將BUG記錄在清單里，并及時提交給測試經(jīng)理。

4.2.4 提交測試報告

在約定的測試周期完成之后，測試工程師需要總結(jié)此測試的結(jié)果，編寫測試報告。測試工程師根據(jù)此輪測試的結(jié)果，編寫測試報告，主要應(yīng)包含以下內(nèi)容：

（1）測試報告的版本。

（2）測試的人員和時間。

（3）測試所覆蓋的缺陷――測試組在這輪測試中所有處理的缺陷， 不僅要寫出覆蓋缺陷的總數(shù)，還要寫明這些缺陷的去向。

（4）上一版本活動缺陷的數(shù)量。

（5）經(jīng)過此輪測試，所有活動缺陷的數(shù)量及其狀態(tài)分類。

（6）測試評估――寫明在這一版本中，哪些功能被實現(xiàn)了，哪些還沒有實現(xiàn)，這里只需寫明和上一版本不同之處即可。

（7）急待解決的問題――寫明當(dāng)前項目組中面臨的最優(yōu)先的問題，可以重復(fù)提出。

在每輪測試結(jié)束之后應(yīng)盡快將符合標(biāo)準(zhǔn)的測試報告發(fā)給測試經(jīng)理。

4.3 總結(jié)階段

測試工作結(jié)束或即將結(jié)束時，測試組就要開始著手準(zhǔn)備進(jìn)行總結(jié)的工作。

4.3.1 編寫測試總結(jié)報告

在測試結(jié)束之后，測試經(jīng)理編寫測試報告，對測試進(jìn)行總結(jié)，并且提交給項目經(jīng)理，為產(chǎn)品的后續(xù)工作提供重要的信息支持。

測試經(jīng)理根據(jù)測試的結(jié)果及測試工程師提交的測試報告編寫測試總結(jié)報告，測試總結(jié)報告必須包含以下重要內(nèi)容：

（1）測試資源概述―多少人、多長時間。

（2）測試結(jié)果摘要―分別描述各個測試需求的測試結(jié)果，產(chǎn)品實 現(xiàn)了哪些功能點(diǎn)，哪些還沒有實現(xiàn)。

（3）缺陷分析―按照缺陷的屬性分類進(jìn)行分析。

（4）測試需求覆蓋率―原先列舉的測試需求的測試覆蓋率，可能 一部分測試需求因為資源和優(yōu)先級的因素沒有進(jìn)行測試，那么 在這里要進(jìn)行說明。

（5）測試評估―從總體對項目質(zhì)量進(jìn)行評估。

（6）測試組建議―從測試組的角度為項目組提出工作建議。

4.3.2 測試驗收

測試驗收工作是在以上工作全部結(jié)束后，測試經(jīng)理對測試的過程、效果進(jìn)行驗收，簽發(fā)測試驗收報告，宣布測試結(jié)束。由測試經(jīng)理進(jìn)行測試驗收，驗收內(nèi)容包括：

（1）測試效果驗收―測試是否達(dá)到預(yù)期目的。

（2）測試文檔驗收―測試過程文檔是否齊全，符合標(biāo)準(zhǔn)。

（3）測試評估―從總體對測試的質(zhì)量進(jìn)行評估。

（4）測試建議―對本次測試工作指出不足，需要在以后工作中改 進(jìn)的地方。

（5）宣布測試結(jié)束―測試組成員簽字宣布本次測試結(jié)束。

4.3.3 測試歸檔

測試歸檔是在測試驗收結(jié)束宣布測試有效，結(jié)束測試后，對測試過程中涉及到各種標(biāo)準(zhǔn)文檔進(jìn)行歸檔，主要包括測試計劃、測試用例、測試報告、驗收報告等。這些文檔的編寫保障了測試的順利進(jìn)行，同時作為整個測試項目的痕跡，被保留下來，供查閱。

參考文獻(xiàn)

[1]佟偉光.軟件測試[M].北京：人民郵電出版，2008.

[2]Rex Black.測試流程管理[M].北京：北京大學(xué)出版社，2001.

[3]Robert V.Binder著，華慶一等譯.面向?qū)ο笙到y(tǒng)的測試[M].北京：人民郵電出版社，2001.

[4]Mark Fewster， Dorothy Graham著，舒智勇等譯.軟件測試自動化技術(shù)與實例詳解[M].北京：電子工業(yè)出版社，2000.

[5]Karl E.Wiegers著，陸麗娜，王忠民，王志敏譯.軟件需求[M].北京：機(jī)械工業(yè)出版社，2000.

篇2

兩年以上工作經(jīng)驗|男|27歲（1989年12月11日）

居住地：北京

電　話：135*******（手機(jī)）

E-mail：

最近工作[1年7個月]

公　司：XX有限公司

行　業(yè)：互聯(lián)網(wǎng)/電子商務(wù)

職　位：系統(tǒng)測試工程師

最高學(xué)歷

學(xué)　歷：本科

?！I(yè)：計算機(jī)科學(xué)與技術(shù)

學(xué)　校：北京農(nóng)學(xué)院

自我評價

本人自中學(xué)開始就養(yǎng)成凡事應(yīng)該從基層做起，并且不能把自己的能力定位過高的性格習(xí)慣，所以我在校期間無論從事什么工作都是從基層做起，盡量把工作約束在自己的能力之內(nèi)，腳踏實地的工作。但只要有機(jī)會，我一樣會進(jìn)行更高的嘗試，讓自己的能力繼續(xù)升級。

求職意向

到崗時間：可隨時到崗

工作性質(zhì)：全職

希望行業(yè)：互聯(lián)網(wǎng)/電子商務(wù)

目標(biāo)地點(diǎn)：北京

期望月薪：面議/月

目標(biāo)職能：系統(tǒng)測試工程師

工作經(jīng)驗

2013/10 – 2015/5：XX有限公司[1年7個月]

所屬行業(yè)：互聯(lián)網(wǎng)/電子商務(wù)

集成部

系統(tǒng)測試工程師

1.熟悉軟件測試?yán)碚?、流程和方法，有較強(qiáng)的邏輯分析能力、測試用例設(shè)計能力。

2.能根據(jù)系統(tǒng)業(yè)務(wù)需求獨(dú)立完成測試用例設(shè)計、執(zhí)行，缺陷跟蹤，風(fēng)險分析，并根據(jù)結(jié)果執(zhí)行回歸測試，分析測試結(jié)果，撰寫測試報告。

3.能從多角度考慮模塊設(shè)計的完備性，靈活性，可擴(kuò)展性，并提出改進(jìn)建議。

2012/6 – 2013/9：XX有限公司[1年3個月]

所屬行業(yè)：互聯(lián)網(wǎng)/電子商務(wù)

集成部

系統(tǒng)測試工程師

1.熟悉軟件測試?yán)碚?、流程和方法，有較強(qiáng)的邏輯分析能力、測試用例設(shè)計能力。

2.能根據(jù)系統(tǒng)業(yè)務(wù)需求獨(dú)立完成測試用例設(shè)計、執(zhí)行，缺陷跟蹤，風(fēng)險分析，并根據(jù)結(jié)果執(zhí)行回歸測試，分析測試結(jié)果，撰寫測試報告。

3.能從多角度考慮模塊設(shè)計的完備性，靈活性，可擴(kuò)展性，并提出改進(jìn)建議。

教育經(jīng)歷

2008/8— 2012/6 北京農(nóng)學(xué)院 計算機(jī)科學(xué)與技術(shù) 本科

證書

2009/12 大學(xué)英語四級

篇3

1 簡介

1.1 范圍

測試用例的執(zhí)行覆蓋高原夏菜無公害胡蘿卜栽培管理專家系統(tǒng)、日光溫室黃瓜無公害栽培管理專家系統(tǒng)、特色產(chǎn)業(yè)決策系統(tǒng)（綿花產(chǎn)業(yè)）、特色產(chǎn)業(yè)決策系統(tǒng)（綿花羊產(chǎn)業(yè)）等。

系統(tǒng)測試自2011年9月7日起對系統(tǒng)的功能及業(yè)務(wù)流程、界面風(fēng)格、安全訪問控制等進(jìn)行了黑盒測試，對系統(tǒng)的用戶使用數(shù)、頁面性能要求進(jìn)行了相應(yīng)的性能測試。

1.2 定義、首字母縮寫詞和縮略語

EXP 為特色產(chǎn)業(yè)專家系統(tǒng)與決策支持系統(tǒng)的英文簡寫。

1.3 概述

本測試評估從功能測試和性能測試的兩個角度來對我省特色產(chǎn)業(yè)專家系統(tǒng)與決策支持系統(tǒng)進(jìn)行評估。內(nèi)容主要包括：基于需求的測試覆蓋、建議的措施以及相關(guān)的測試結(jié)果圖示說明。

2 測試設(shè)備

PC1：硬件 CPU：PIV 1.50G，內(nèi)存：512M硬盤：40G，軟件：Winserver 2003/IE8.0；

PC2：硬件 CPU：PIV 2G，內(nèi)存：2G硬盤：300 G，軟件Winxpsp2 Winserver 2003/IE8.0。

3 測試環(huán)境

3.1 硬件配置

Web服務(wù)器硬件配置：TOMCAT服務(wù)器，CPU：PIV2.80，內(nèi)存：1 G；硬盤：300 G；網(wǎng)卡：10/100 M自適應(yīng)。

數(shù)據(jù)庫服務(wù)器硬件配置：PC臺式機(jī)，CPU：P43G，內(nèi)存：1 G；硬盤：300 G；網(wǎng)卡：10/100 M自適應(yīng)。

3.2 軟件配置

服務(wù)器軟件配置：開發(fā)工具：IBMWSAD5.0；JDK環(huán)境：j2se1.5或更高；

系統(tǒng)環(huán)境：Windows 2000/XP/2003；

Web服務(wù)器：Apache 2.4+tomcat6.0

數(shù)據(jù)庫系統(tǒng)：SERVER 2008。

3.3 測試方法

以黑盒測試為主，測試的重點(diǎn)集中在業(yè)務(wù)流程、數(shù)據(jù)提取和各功能模塊間的接口。其中單元測試由開發(fā)人員直接完成；功能模塊采用黑盒測試的常用方法；集成測試模塊采用非漸增式測試，偏重系統(tǒng)的接口和數(shù)據(jù)提取方面；系統(tǒng)測試主要體現(xiàn)在業(yè)務(wù)流程的測試，主要采用回歸測試。包括數(shù)據(jù)測試、功能測試、用戶界面測試、性能評測、安全性和訪問控制測試。

4 測試覆蓋分析

需求覆蓋率是指經(jīng)過測試的需求/功能和系統(tǒng)分析中所有需求/功能的比值，通常情況下要至少達(dá)到99 %的目標(biāo)。

被驗證通過的需求26個，需求總數(shù)26個。

需求覆蓋率=通過驗證的需求/需求總數(shù)=26/(26)×100 %=100 %(詳見表1)。

4.1 缺陷收斂曲線圖

4.2 缺陷生命周期圖

從缺陷生存周期來分析：整個缺陷數(shù)占比最多的是生存周期在1周的缺陷,總共161個，約占總數(shù)的75.23 %,說明開發(fā)組對缺陷的響應(yīng)時間相對較快，能在較短的時間內(nèi)對bug進(jìn)行修復(fù)。

5 測試結(jié)論

5.1 安全性 做了用戶登錄安全訪問控制測試，即各種條件下的用戶登錄測試，系統(tǒng)安全性高。

篇4

認(rèn)清“第三方”的責(zé)任

第三方測試以合同的形式制約了測試方，使得它與開發(fā)方存在某種“對立”的關(guān)系，所以它不會刻意維護(hù)開發(fā)方的利益，保證了測試工作在一開始就具有客觀性。第三方一般都不直接參加開發(fā)方系統(tǒng)的設(shè)計和編程，為了能夠深入理解系統(tǒng)，發(fā)現(xiàn)系統(tǒng)中存在得問題，第三方測試必須按軟件工程的要求辦事，以軟件工程的標(biāo)準(zhǔn)要求開發(fā)方和用戶進(jìn)行配合，從而較好地體現(xiàn)軟件工程的理念。引入第三方測試后，由于測試方相對的客觀位置，由用戶、開發(fā)方、測試方三方組成的三角關(guān)系也便于處理以往用戶、開發(fā)方雙方糾纏不清的矛盾，使得許多問題能得到比較客觀的處理。

第三方測試不同于開發(fā)方的自測試。由于他熟悉設(shè)計和編程等，往往習(xí)慣于按一定的“程式”考慮問題，以至思路比較局限，難于發(fā)現(xiàn)“程式”外存在的問題。因為第三方測試的目的就是為盡量多地發(fā)現(xiàn)程序中的錯誤而運(yùn)行程序的過程，可以更多的發(fā)現(xiàn)問題。隨著系統(tǒng)越做越大，客觀上講開發(fā)人員也無精力參與測試，同時也不符合大生產(chǎn)專業(yè)分工的原則。

第三方測試不同于用戶的自測試。用戶是應(yīng)用軟件需求的提出者，對于軟件應(yīng)該完成的功能是非常清楚的，是進(jìn)行功能驗證的最佳人選。客觀情況是，大部分的用戶都不是計算機(jī)的專業(yè)人士，很難對系統(tǒng)的內(nèi)部實現(xiàn)過程進(jìn)行深入的分析。對系統(tǒng)的全面測試，功能測試僅僅是一個方面，還要包括并發(fā)能力、性能等多種技術(shù)測試。

如何組織管理

在測試的過程中，用戶、開發(fā)方與測試方形成了一個三角關(guān)系，從最終目標(biāo)來講，三方是完全一致的，都是希望保證系統(tǒng)穩(wěn)定運(yùn)行。但在測試過程中，三方的關(guān)系卻是既對立又合作。

軟件測試的過程

為了保證測試的順利進(jìn)行，測試方必須強(qiáng)化內(nèi)部的組織管理。根據(jù)我們的經(jīng)驗，完整的測試機(jī)構(gòu)必須包括業(yè)務(wù)分析部門、技術(shù)支持部門、規(guī)劃設(shè)計部門和綜合后勤部門。

“第三方”測試什么

根據(jù)軟件的特性，第三方軟件測試工程可劃分為三種類型四個層次。

第一類是系統(tǒng)軟件、環(huán)境軟件和各類工具軟件等的測評。對這類軟件的評測重點(diǎn)是軟件產(chǎn)品的功能、性能和特點(diǎn)評測。

第二類是面向應(yīng)用軟件系統(tǒng)的測評。這類軟件，具有很強(qiáng)的行業(yè)應(yīng)用特性，往往是要由用戶與開發(fā)商簽定項目合同，開發(fā)商負(fù)責(zé)開發(fā)，用戶負(fù)責(zé)驗收。對這類軟件的評測，根據(jù)用戶對第三方的依賴程度，又可分為兩個層次。第一個層次只對應(yīng)用軟件系統(tǒng)進(jìn)行綜合、性能測試。第二個層次是對應(yīng)用軟件系統(tǒng)進(jìn)行質(zhì)量監(jiān)理與評測。

承擔(dān)該類軟件質(zhì)量監(jiān)理評測的第三方，承擔(dān)軟件過程質(zhì)量監(jiān)理的責(zé)任，在軟件生命周期過程中，從軟件定義開始，要對軟件過程從質(zhì)量保證角度進(jìn)行規(guī)范化的監(jiān)督、管理和控制。評測工作不僅包括軟件生命周期各階段的評審，而且還要對程序系統(tǒng)，進(jìn)行包括模塊白盒測試在內(nèi)的系統(tǒng)集成、系統(tǒng)驗收等測試。

第三類是對軟件企業(yè)的CMM評估認(rèn)證,也是最高層次的軟件評測。

了解測試評估

測試評估是軟件測試的一個階段性的結(jié)論，用所生成的測試評估報告，來確定測試是否達(dá)到完全和成功的標(biāo)準(zhǔn)。在測度評估階段向用戶提供強(qiáng)有力的支持，包括通過測試報告，驗證測試結(jié)果是否符合測試計劃中制定的測試標(biāo)準(zhǔn)；根據(jù)缺陷報告提供的測試結(jié)果數(shù)據(jù)，給出軟件質(zhì)量和測試完整性的評估報告；特別在以下幾方面對測試的過程進(jìn)行評測：

評估測試用例覆蓋：測試的目標(biāo)是確保100%的測試用例成功地執(zhí)行。主要考慮風(fēng)險和嚴(yán)重性、可接受的覆蓋百分比。

評估代碼覆蓋：需要斷定測試目標(biāo)期望的總的測試代碼行數(shù)，在測試中真正執(zhí)行的代碼行數(shù)及其百分比，將此結(jié)果記錄在測試評估報告中。

篇5

關(guān)鍵詞：計算機(jī)；軟件測試

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9599?。?012）　18-0000-02

1 計算機(jī)軟件測試的概念

所謂軟件測試，主要是以發(fā)現(xiàn)程序錯誤為目的而執(zhí)行程序的過程，是結(jié)合軟件開發(fā)過程中每一個階段的規(guī)格及軟件內(nèi)部的結(jié)構(gòu)進(jìn)行認(rèn)真設(shè)計的測試用例。因此，我們可以說，軟件測試就是在精心搭建的環(huán)境下對程序進(jìn)行執(zhí)行，以更好的發(fā)現(xiàn)軟件中的錯誤，對其可靠性給出鑒定。

2 軟件測試的流程

2.1 設(shè)計測試方案。設(shè)計測試方案是在軟件測試初始階段進(jìn)行的，在這個工作中，首先要調(diào)研所需要應(yīng)對的系統(tǒng)框架和業(yè)務(wù)模型，對測試需求進(jìn)行收集。其次，根據(jù)測試需求制訂一個合理的測試計劃。具體來說，我們的測試團(tuán)隊要對被測試項目有著提前的了解，而且開發(fā)部門也要配合測試部門的工作，提供各種系統(tǒng)規(guī)格書、系統(tǒng)總體介紹、網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖、用戶使用手冊、系統(tǒng)配置說明、應(yīng)用部署與配置以及關(guān)鍵服務(wù)器及等文檔。經(jīng)過與業(yè)務(wù)部門協(xié)商之后，就可以確定下來這次測試的目標(biāo)，然后對這一目標(biāo)進(jìn)行細(xì)化，制定出各個階段的目標(biāo)，并制定相應(yīng)的指標(biāo)要求。

2.2 開發(fā)測試場景。這主要是指開發(fā)測試腳本，是針對被測系統(tǒng)業(yè)務(wù)進(jìn)行模擬、錄制、編程、參數(shù)化、腳本定制以及調(diào)試測的工作，通過測試場景的開發(fā)，可以使測試腳本實現(xiàn)對現(xiàn)實場景的真是模擬，而且我們還可以通過改變參數(shù)來控制并發(fā)數(shù)以及思考時間等屬性。

2.3 執(zhí)行測試。這主要是按照預(yù)先制訂的測試方案，在完成測試環(huán)境以及測試場景之后進(jìn)行的工作。

2.4 測試報告及分析。這一工作主要是在執(zhí)行完測試之后進(jìn)行的，主要的任務(wù)是對測試過程中所暴露的問題進(jìn)行收集及分析。而測試報告則主要是對測試過程中監(jiān)控報告以及報表的匯總，然后對其進(jìn)行一定整理之后所得到的結(jié)論性文檔。

2.5 回歸測試。開發(fā)部門在分析了測試報告之后，會對軟件的缺陷進(jìn)行了修復(fù)或者優(yōu)化，使其具有更高的性能，而對于這種修復(fù)之后軟件的測試就是回歸測試。

3 計算機(jī)軟件測試的基本方法

3.1 按照階段進(jìn)行劃分。如果按照階段對計算機(jī)軟件測試方法進(jìn)行劃分的話，則可以分為單元測試、集成測試、系統(tǒng)測試、驗收測試、回歸測試、Alpha測試以及Beta測試。

（1）單元測試。這主要是指對軟件的基本組成單位進(jìn)行測試，比如一個模塊。單元測試是動態(tài)測試中最基本，也是最重要的部分，它主要的目的是對軟件基本單元的正確性進(jìn)行驗證。在單元測試中，由于需要我們了解程序的設(shè)計及編碼的細(xì)節(jié)，所以這一工作主要是由程序員進(jìn)行。另外，單元測試還需要開發(fā)測試驅(qū)動模塊以及樁模塊進(jìn)行輔助。在單元測試中，主要的方法包括控制流測試、排錯測試、數(shù)據(jù)流測試以及分域測試等。

（2）集成測試。集成測試主要進(jìn)行于軟件系統(tǒng)集成過程中，它的作用是對單位之間接口的正確性進(jìn)行檢查。一般來說，根據(jù)計劃，我們將在模塊集成為較大系統(tǒng)的過程中運(yùn)行該系統(tǒng)，查看各個組成部分是否合拍。在這個過程中，使用的策略有自底向上以及自頂向下這兩種。

（3）系統(tǒng)測試。這主要是針對已經(jīng)集成好的系統(tǒng)進(jìn)行測試，進(jìn)而對系統(tǒng)的性能及正確性進(jìn)行檢查。由于這一測試的整體難度比較大，我們要制定合理的計劃，并嚴(yán)格按照計劃執(zhí)行測試工作。在系統(tǒng)測試工作中，主要的方法有隨機(jī)測試、性能測試以及功能測試。

（4）驗收測試。這種測試的目的是主要是對軟件的購買者展示軟件的性能，確保其符合購買者的需求。在這個過程中，測試數(shù)據(jù)主要來自于系統(tǒng)測試中使用的數(shù)據(jù)。這是軟件在應(yīng)用之前最后的測試。

（5）回歸測試。上文中已經(jīng)對其概念進(jìn)行了簡要的分析，這里將進(jìn)一步對其進(jìn)行分析?；貧w測試的主要目的是檢測所進(jìn)行的修改是否合理。在這個問題上，修改有著以下內(nèi)涵：首先是修改達(dá)到了預(yù)期的目的，其次是修改不能夠?qū)浖渌δ艿恼_性產(chǎn)生影響。

（6）Alpha測試。這是在軟件開發(fā)即將完成的時候所進(jìn)行的測試，在測試之后，一般仍然會有一些設(shè)計上的變更，在這一測試工作中，測試人員主要是最終用戶而不是程序員或者測試員。

（7）Beta測試。這是指在開發(fā)及測試在根本完成之后進(jìn)行的測試，這種測試的工作一般由其他人員或者最終用戶來完成，不可以由測試員完成。

3.2 按照按測試方法進(jìn)行劃分。按照測試方法進(jìn)行劃分則可以分為白盒測試以及黑盒測試這兩種。

（1）白盒測試。這也被我們稱之為邏輯驅(qū)動測試或者結(jié)構(gòu)測試，是基于覆蓋所有代碼、路徑、分支以及條件的測試。在白盒測試中，我們是清楚程序內(nèi)部工作過程的，主要的目的是檢測其內(nèi)部動作是否符合規(guī)格說明書的要求，至于軟件的功能是否符合要求則不屬于這一測試的范疇。常見的白盒測試方法有邏輯驅(qū)動以及基路測試等。

在使用白盒測試方法的時候，測試者必須對程序的內(nèi)部結(jié)構(gòu)進(jìn)行檢查，并通過對其邏輯的檢查得到測試數(shù)據(jù)。在這種測試方法中，存在著以下不足：首先，對于程序是否符合設(shè)計規(guī)范，或者說程序本身就是錯誤程序的情況，我們是沒有辦法檢查的。其次，對于程序中因路徑遺漏而導(dǎo)致的錯誤，我們無法檢查。最后，某些和數(shù)據(jù)相關(guān)的錯誤我們沒有辦法檢查。在這一具體的工作中，常使用的工具有Junit　Framework，Jtest等。

（2）黑盒測試。顧名思義，黑盒測試和白盒測試是相反的。在黑盒測試中，我們的測試目的不是為了檢查內(nèi)部設(shè)計及代碼是否正確，而是檢查程序能否符合功能性方面的需求，因此，這種測試也被我們稱之為數(shù)據(jù)驅(qū)動測試或者功能測試。

在測試的過程中，我們將完全不考慮其內(nèi)部特性，只是將程序作為一個黑盒子看待，然后在其接口進(jìn)行測試，具體的工作就是檢查程序在接收到輸入數(shù)據(jù)之后能否產(chǎn)生正確的數(shù)據(jù)輸出信息。在黑盒測試方法中，常見的方法等價類劃分、因—果圖、邊值分析以及錯誤推測等。

由于黑盒測試方法屬于窮舉輸入測試，我們只有將所有的輸入都當(dāng)成測試情況使用之后才能夠檢查出程序中所有的錯誤，而實際的測試情況有無窮多個，因此，我們除了要有合法的輸入之外，還要有不合法卻可能的輸入。一般常用的工具有WinRunner，Rational　Robot，QuickTestPro等。

4 結(jié)語

由上文我們可以看出，軟件測試中的環(huán)節(jié)比較多，而且方法也有很大的差別。因此，做好計算機(jī)軟件測試工作并不是一件很輕松的事情，需要我們對各種軟件測試方法了如指掌。所以，我們還要不斷的學(xué)習(xí)，并加強(qiáng)探索，以一個嚴(yán)謹(jǐn)科學(xué)的態(tài)度去面對軟件測試工作，只有這樣才能真正的使軟件發(fā)揮其應(yīng)有的作用，進(jìn)而提升企業(yè)的競爭力。

參考文獻(xiàn)：

[1]何強(qiáng).通信軟件自動化測試系統(tǒng)的研究與實現(xiàn)[D].中南大學(xué)，2009.

篇6

一、室內(nèi)覆蓋工程質(zhì)量監(jiān)理的重要性

室內(nèi)無線網(wǎng)絡(luò)的鏈路不平衡將會導(dǎo)致上行不足，此時手機(jī)有信號卻無法接入，無法有效吸收話務(wù)，導(dǎo)致室內(nèi)覆蓋沒有發(fā)揮應(yīng)有作用，在定位干擾問題時，對干擾源的特點(diǎn)和干擾通道的理解是非常重要的，但是傳統(tǒng)的分析只看到了表面現(xiàn)象，簡單地認(rèn)為只存在外部干擾，并認(rèn)為上行干放增益會產(chǎn)生上行干擾。由于對干擾成因存在錯誤的理解，以往室內(nèi)覆蓋普遍采用調(diào)低上行干放增益的錯誤方法，導(dǎo)致大量的站點(diǎn)出現(xiàn)鏈路不平衡。由于存在以上缺陷，以往的室內(nèi)覆蓋實際上是在進(jìn)行低水平的大量建設(shè)，存在嚴(yán)重的隱患。針對這些問題質(zhì)量監(jiān)理應(yīng)該采取多種手段，從根本上定位與解決信號傳輸通道的質(zhì)量監(jiān)理問題，提高室內(nèi)覆蓋的質(zhì)量，從而提升用戶體驗。

二、室內(nèi)覆蓋工程設(shè)計階段的監(jiān)理

在設(shè)計階段，監(jiān)理人員首先要從現(xiàn)場勘察，設(shè)計文件審查和信源方案審查等方面，做好設(shè)計階段的監(jiān)理工作。

（1）現(xiàn)場勘察監(jiān)理

根據(jù)集成商提交的設(shè)計草圖，監(jiān)理人員需和集成商一同到現(xiàn)場進(jìn)行現(xiàn)場勘查和信號模測　并注意做好以下幾方面的工作。首先應(yīng)該核對設(shè)計草圖中的大樓結(jié)構(gòu)與現(xiàn)場環(huán)境是否相符，在室內(nèi)擬安裝的天線位置處進(jìn)行模擬信號測試，檢查設(shè)計草圖的天線密度是過密還是過疏。對地下室出口處的天線進(jìn)行信號泄露測試，檢查出入口處的信號泄露強(qiáng)度是否在標(biāo)準(zhǔn)范圍內(nèi)。監(jiān)理還需要對大樓的平層及大樓的安全走梯進(jìn)行現(xiàn)有信號測試，檢查是否需做室內(nèi)信號覆蓋。在大樓地下室的各個出口處、各部電梯的中層和高層的出口處收集已有信號的導(dǎo)頻信號PN上報給建設(shè)單位的網(wǎng)管中心，以便網(wǎng)管中心選取室內(nèi)覆蓋站點(diǎn)的施主宏基站及配置附近周圍宏基站的鄰區(qū)列表。對現(xiàn)場測試得到的數(shù)據(jù)，監(jiān)理人員要做好詳細(xì)的記錄，以便能夠更好地審核設(shè)計文件。

（2）設(shè)計文件監(jiān)理審查

室內(nèi)覆蓋工程的施工地點(diǎn)多為大樓的地下室、電梯、線槽等，現(xiàn)場環(huán)境相對較為惡劣，且施工安全隱患較多。由于室內(nèi)覆蓋工程的設(shè)計和施工都是由集成商負(fù)責(zé)完成，有些集成商為了增大工程的投資規(guī)模，增加自身收入，在設(shè)計文件中修改了現(xiàn)場信號模測數(shù)據(jù)，以增加天線數(shù)量，饋線的走線路由出現(xiàn)重復(fù)走線，增加布放不必要的饋線，修改分布系統(tǒng)中的信號衰減數(shù)量，增加不必要的7/8饋線。直放站的安裝位置設(shè)計不合理，增加不必要的干放設(shè)備。監(jiān)理人員應(yīng)注意根據(jù)現(xiàn)場勘查時已收集到的測試數(shù)據(jù)對設(shè)計圖進(jìn)行審查，及時發(fā)現(xiàn)設(shè)計圖中存在的問題，并要求集成商改正，提高設(shè)計文件的質(zhì)量。

（3）室內(nèi)覆蓋工程信源方案的審查

室內(nèi)覆蓋工程的信源設(shè)備主要有光纖直放站、無線直放站、微蜂窩。監(jiān)理人員在審核各種信源建設(shè)方案時應(yīng)注意審查光線直放站近端和遠(yuǎn)端問的光路損耗不宜過大，光路長度不宜過長。需調(diào)整施主基站的信號搜索窗，同時，光路過長也會導(dǎo)致光路的損耗大。在無線直放站的監(jiān)理中對施主天線接收到的宏基站信號，必須進(jìn)行詳細(xì)測試，確定所接收的宏基站信號的主導(dǎo)頻單一穩(wěn)定、信號強(qiáng)度、ECIO等數(shù)值滿足要求。另外，微蜂窩是本身能夠提供話務(wù)容量的設(shè)備。建設(shè)完成后，在微蜂窩覆蓋區(qū)域內(nèi)會引入新的導(dǎo)頻PN信號要注意對室外周圍基站的臨區(qū)列表做相應(yīng)調(diào)整，避免出現(xiàn)手機(jī)切換掉話現(xiàn)象。

三、室內(nèi)覆蓋工程施工階段的監(jiān)理

室內(nèi)覆蓋工程施工環(huán)境特殊且大部分屬于隱蔽工程，所以施工過程需和大樓業(yè)主協(xié)商進(jìn)行，施工過程需一次完成。室內(nèi)覆蓋系統(tǒng)是通過饋線，耦合器和功分器，將信號均勻地傳輸?shù)酱髽堑母鱾€角樓。其中，饋線頭的制作質(zhì)量是影響整個系統(tǒng)運(yùn)行效果的主要因素。如果饋線頭制作的質(zhì)量不合格，將使信號在饋線頭處發(fā)生反射、折射、散射等現(xiàn)象，增大信號在傳輸過程中的損耗，引起信號發(fā)生失真，增大信號的誤碼率。由于CDMA屬于白干擾系統(tǒng)，發(fā)射信號功率的增大，意味著系統(tǒng)容量和質(zhì)量的降低。為了做好室內(nèi)覆蓋工程的質(zhì)量控制，在工程的前期監(jiān)理人員要對施工單位的施工質(zhì)量，饋線頭制作工藝等進(jìn)行旁站監(jiān)理。室內(nèi)覆蓋系統(tǒng)中，每段饋線都有兩個饋線頭，如果在工程前期沒有對施工工藝質(zhì)量和施工隊伍素質(zhì)進(jìn)行把關(guān)或者把關(guān)不嚴(yán)，等到工程建設(shè)完成后再來查找室內(nèi)覆蓋系統(tǒng)的故障點(diǎn)，將是一件十分困難的事情。

在室內(nèi)覆蓋工程建設(shè)完成后，監(jiān)理人員要對室內(nèi)覆蓋系統(tǒng)進(jìn)行預(yù)驗收。面對如此龐大，分布在大樓各個角落的室內(nèi)覆蓋系統(tǒng)，找出系統(tǒng)中的質(zhì)量問題點(diǎn)可通過駐波儀對室內(nèi)覆蓋系統(tǒng)進(jìn)行檢查。反向高駐波信號在經(jīng)過耦合器時，由于耦合端對信號功率衰減量較大，駐波信號經(jīng)過耦合端時產(chǎn)生較大衰減，直通端對信號功率衰減量很小，可近視看作駐波信號是直接通過的。反向高駐波信號在經(jīng)過功分器時，也要產(chǎn)生相應(yīng)的衰減。當(dāng)功分器位于室內(nèi)覆蓋系統(tǒng)前端時，功分器對末端高駐波信號的衰減影響較大，故位于系統(tǒng)前端的功分器出口端都應(yīng)進(jìn)行駐波測試，當(dāng)功分器位于系統(tǒng)末端時，對駐波信號的衰減影響較小，可直接在功分器的輸人口處進(jìn)行駐波測試。所以，使用駐波儀對室內(nèi)覆蓋系統(tǒng)進(jìn)行駐波測試時應(yīng)分段進(jìn)行測試，通過對分布系統(tǒng)的高駐波點(diǎn)進(jìn)行整改，能夠使整個室內(nèi)覆蓋系統(tǒng)的信號質(zhì)量大大提高。

四、室內(nèi)覆蓋工程驗收階段的監(jiān)理

在工程正式驗收前，監(jiān)理人員應(yīng)組織集成商開展預(yù)驗收工作，確保室內(nèi)覆蓋工程的質(zhì)量合格后再交付驗收。對交工資料的審查，應(yīng)重點(diǎn)檢查其中的測試報告，對于大樓地下室，要求進(jìn)行DT測試及出入口的信號外泄測試。對每份測試數(shù)據(jù)要求要有詳細(xì)全面的圖表和數(shù)據(jù)，對圖表和測試數(shù)據(jù)的分析結(jié)果指標(biāo)應(yīng)在規(guī)范要求范圍內(nèi)。測試報告反映了室分站點(diǎn)的信號覆蓋效果，通過審查測試報告，能夠檢查室內(nèi)覆蓋系統(tǒng)的工程質(zhì)量是否達(dá)到要求。除此以外，還應(yīng)注意檢查直放站和干放等設(shè)備的監(jiān)控是否已經(jīng)連接網(wǎng)管并工作正常。

結(jié)　語

室內(nèi)覆蓋工程由于具有施工環(huán)境的特殊性，隱蔽工程較多且故障點(diǎn)難以查找，為了更好地開展工程監(jiān)理工作，監(jiān)理人員除了控制好設(shè)計、實施及驗收階段的質(zhì)量監(jiān)理，還應(yīng)注意采取措施不斷增強(qiáng)施工人員的質(zhì)量監(jiān)理意識，從根本上改變以前不當(dāng)?shù)氖┕ち?xí)慣，以達(dá)到保證施工質(zhì)量的最終目的。

參考文獻(xiàn)

篇7

關(guān)鍵詞：可靠測試；優(yōu)化；數(shù)據(jù)分析

高質(zhì)量且高可靠性的企業(yè)應(yīng)用程序系統(tǒng)是數(shù)字化時代非常重要的元素[1]。測試團(tuán)隊在確保企業(yè)應(yīng)用程序系統(tǒng)滿足既定標(biāo)準(zhǔn)或需求時會發(fā)揮非常重要的作用。隨著系統(tǒng)的規(guī)模和復(fù)雜性升級，其可靠性和質(zhì)量要求必然成倍增長，這意味著測試團(tuán)隊需要開發(fā)更有效的測試方法。一個完整的測試過程包括數(shù)據(jù)記錄、數(shù)據(jù)維護(hù)、數(shù)據(jù)驗證等多個方面。測試數(shù)據(jù)管理策略對于測試數(shù)據(jù)的記錄必須是全面的，這也為后期的數(shù)據(jù)分析挖掘提供了支撐。

陳翔等人在文獻(xiàn)[2]中重點(diǎn)闡述了回歸測試中用例優(yōu)先排序（test case prioritization，簡稱TCP）問題。從源代碼、需求和模型三個角度對TCP問題進(jìn)行分類，重點(diǎn)分析了回歸測試中測試資源缺乏時的TCP問題。另外，潘偉豐等人在文獻(xiàn)[3]中提出了基于錯誤傳播網(wǎng)絡(luò)的測試用例排序方法。該方法在類粒度將軟件抽象成加權(quán)類依賴網(wǎng)絡(luò)（weighted class dependency network， 簡稱WCDN）模型，并基于WCDN分析錯誤在網(wǎng)絡(luò)上的傳播行為，構(gòu)造錯誤傳播網(wǎng)絡(luò)（bug propagation network，BPN）。實例研究表明，基于錯誤傳播網(wǎng)絡(luò)的測試用例排序方法在錯誤檢出率上相比于其他經(jīng)典方法有一定的提高，并且具有較好的穩(wěn)定性。一個全面的用例排序方法，能準(zhǔn)確地將當(dāng)前的軟件質(zhì)量反映到執(zhí)行用例的優(yōu)先級上[4-5]。通過使用正確的TCP策略測試團(tuán)隊能夠提供及早發(fā)現(xiàn)缺陷，在整個產(chǎn)品開發(fā)過程中，為提供更簡單的方法去解決系統(tǒng)缺陷提供支撐。因此，擁有正確的TCP策略對測試團(tuán)隊乃至公司都至關(guān)重要，能加快系統(tǒng)周期并大幅削減成本。然而在現(xiàn)有的研究工作中，TCP策略問題主要集中在回歸測試階段，但是回歸測試處于整個測試過程的末端[6]。由于回歸測試時對于本系統(tǒng)缺陷分布情況有非常清晰的概念，但是由于處于末端，對于測試團(tuán)隊的優(yōu)化畢竟有限。同時測試團(tuán)隊與研發(fā)團(tuán)隊往往是單線交流，即研發(fā)團(tuán)隊待測系統(tǒng)，測試團(tuán)隊極少參與提高研發(fā)團(tuán)隊的開發(fā)質(zhì)量。

因此，可以從測試用例執(zhí)行策略和測試結(jié)果反向優(yōu)化開發(fā)策略兩個方面展開研究，并提高系統(tǒng)可靠性。測試用例執(zhí)行順序問題是測試執(zhí)行策略中非常重要的部分，在測試項目中持續(xù)優(yōu)化測試用例執(zhí)行順序可以提早發(fā)現(xiàn)潛在的缺陷。同時由于測試團(tuán)隊對于項目整體的理解更為透徹，對缺陷的總體分析可以幫助研發(fā)團(tuán)隊在類似問題上處理地更為妥善。測試團(tuán)隊在需求分析階段的有效介入，將從源頭上提高系統(tǒng)的質(zhì)量和可靠性。

1 測試執(zhí)行策略優(yōu)化

測試中的關(guān)鍵問題是第一時間發(fā)現(xiàn)被測系統(tǒng)不符合規(guī)范要求的內(nèi)容。測試經(jīng)理在測試規(guī)劃時是通過大量的測試用例保證測試的覆蓋率。持續(xù)優(yōu)化測試用例執(zhí)行順序是在保障測試覆蓋率的同時，合理地安排測試用例地執(zhí)行順序，即TCP問題。文章提出將項目測試分為三個階段，在項目測試的初期、中期、后期三方面分別進(jìn)行優(yōu)化TCP，最終優(yōu)化整個測試執(zhí)行策略。

如圖1 所示，項目測試初期，分析測試用例的歷史數(shù)據(jù)得到測試用例的執(zhí)行潛在價值，優(yōu)先執(zhí)行潛在價值高的測試用例。比如在其它項目中執(zhí)行某些用例時，發(fā)現(xiàn)了系統(tǒng)不符合規(guī)范要求的部分，并提交了缺陷。在新的測試用例執(zhí)行時，應(yīng)首先執(zhí)行這類測試用例以便快速發(fā)現(xiàn)系統(tǒng)缺陷。項目測試中期，分析本項目當(dāng)前缺陷情況得到各個系統(tǒng)功能模塊的缺陷發(fā)生概率。優(yōu)先執(zhí)行缺陷分布較多的功能模塊相關(guān)的測試用例。項目測試后期，即回歸測試階段，需結(jié)合各個系統(tǒng)功能模塊在本項目和歷史項目中的缺陷發(fā)生概率，在保證一定回歸比率的情況下，綜合考慮本項目和歷史項目的分析，優(yōu)先回歸測試缺陷發(fā)生概率較高的模塊。

2 需求分析優(yōu)化

項目測試工作通常被安排在項目研發(fā)工作之后，測試團(tuán)隊的主要工作也僅僅是將測試結(jié)果中發(fā)現(xiàn)的缺陷情況報告給研發(fā)團(tuán)隊，并沒有對缺陷情況進(jìn)行分析，可能使得類似的缺陷在不同的項目中反復(fù)出現(xiàn)。因此測試團(tuán)隊在提供測試報告的同時，對各個功能模塊中所發(fā)現(xiàn)的缺陷進(jìn)行分析，并在新項目立項初期給出系統(tǒng)模塊開發(fā)時的缺陷概率，幫助研發(fā)團(tuán)隊在需求分析階段重點(diǎn)考慮高缺陷概率的模塊開發(fā)和模塊間的協(xié)作，從源頭上降低缺陷發(fā)生的概率。測試團(tuán)隊與研發(fā)團(tuán)隊的雙向反饋將優(yōu)化產(chǎn)品設(shè)計的需求分析階段，提高系統(tǒng)的可靠性，如圖2所示。

圖2 測試團(tuán)隊和研發(fā)團(tuán)隊雙向通道

3 結(jié)束語

文章從優(yōu)化測試用例執(zhí)行順序和測試結(jié)果優(yōu)化需求分析兩個方面，闡述了現(xiàn)在系統(tǒng)開發(fā)中提高系統(tǒng)可靠性的重要方法。測試數(shù)據(jù)的管理是一座金礦，對測試數(shù)據(jù)的深入分析可以讓整個測試過程不再是靜止的，而是可以動態(tài)調(diào)節(jié)以應(yīng)對更復(fù)雜的情況，同時深入分析測試結(jié)果也可以建立測試研發(fā)的雙向通道，形成良性循環(huán)。最終可以超預(yù)期地提交高質(zhì)量的系統(tǒng)，節(jié)約運(yùn)營成本，完成市場搶占。

參考文獻(xiàn)

[1]K.Krishna Murthy， Janardhana S Channagiri， "test data management： Enabling reliable testing through realistic test data"Building Tomorrow's Enterprise， Oct 2009.

[2]陳翔，陳繼紅，鞠小林，等.“回歸測試中的測試用例優(yōu)先排序技術(shù)述評”[J].系統(tǒng)軟件與軟件工程，2013（8）.

[3]潘偉豐，李兵，周曉燕，等.“基于錯誤傳播網(wǎng)絡(luò)的回歸測試用例排序方法”[J].計算機(jī)研究與發(fā)展，2016（3）.

[4]朱海燕，范輝，謝青松，等.“測試用例排序的研究”[J].計算機(jī)工程與科學(xué)，2008（1）.

篇8

二年以上工作經(jīng)驗 |男| 29歲（1986年6月9日）

居住地：上海

電　話：153********（手機(jī)）

E-mail：

最近工作 [ 1年7個月 ]

公　司：XX計算機(jī)軟件有限公司

行　業(yè)：計算機(jī)服務(wù)(系統(tǒng)、數(shù)據(jù)服務(wù)、維修)

職　位：軟件測試

最高學(xué)歷

學(xué)　歷：本科

?！I(yè)：軟件測試

學(xué)　校：西北大學(xué)

自我評價

本人熟悉軟件開發(fā)測試流程，豐富的自動化測試經(jīng)驗，善于學(xué)習(xí)。能在成功與失敗中完善自己，活潑開朗，樂觀向上，適應(yīng)力強(qiáng)，勤奮好學(xué)，認(rèn)真負(fù)責(zé)。待人誠懇，做事踏實細(xì)心，對工作有熱情有責(zé)任心。

求職意向

到崗時間： 一周之內(nèi)

工作性質(zhì)： 全職

希望行業(yè)： 計算機(jī)軟件

目標(biāo)地點(diǎn)： 上海

期望月薪： 面議/月

目標(biāo)職能： 軟件測試

工作經(jīng)驗

2012 /12—至今：XX計算機(jī)軟件有限公司[ 1年7個月]

所屬行業(yè)：計算機(jī)服務(wù)(系統(tǒng)、數(shù)據(jù)服務(wù)、維修)

測試部 軟件測試

1.負(fù)責(zé)需求分析，制定測試計劃，編寫測試計劃和測試案例；

2.負(fù)責(zé)測試環(huán)境的搭建；

3.負(fù)責(zé)使用JIRA 缺陷管理系統(tǒng), 管理跟蹤BUG；

4.負(fù)責(zé)系統(tǒng)的功能測試，以及處理客戶的回饋，重現(xiàn)問題；

5.負(fù)責(zé)熟練使用LINUX腳本語言，實現(xiàn)測試環(huán)境的自動安裝和定時運(yùn)行，并進(jìn)行日志的查看及排錯等；

6.負(fù)責(zé)根據(jù)用戶需求，編寫用戶使用說明手冊；

7.負(fù)責(zé)系統(tǒng)的安裝及配置,負(fù)責(zé)客戶版本升級。

2011 /1—2011 /12：XX軟件科技有限公司[ 11個月]

所屬行業(yè)：計算機(jī)軟件

事業(yè)部 軟件測試

1、負(fù)責(zé)根據(jù)軟件開發(fā)年度進(jìn)程表，與美國微軟測試及開發(fā)團(tuán)隊溝通，確定各階段測試目標(biāo)；

2、負(fù)責(zé)在項目測試過程中，制定測試計劃，參與測試用例的編寫、修改和審核；

3、負(fù)責(zé)定期組織技術(shù)交流會議，以提高組員工作效率；

4、負(fù)責(zé)及時處理客戶對軟件提出的問題，執(zhí)行測試定位問題,以幫助產(chǎn)品的修復(fù)。

2010 /7—2011 /1：XX網(wǎng)絡(luò)游戲有限公司[ 6個月]

所屬行業(yè)：娛樂/休閑/體育

技術(shù)部 軟件測試

1、負(fù)責(zé)了解軟件的測試流程，并制定測試流程；

2、負(fù)責(zé)編寫測試用例，BUG提交給開發(fā)人員；

3、負(fù)責(zé)開發(fā)人員修復(fù)，進(jìn)行回歸測試；

4、負(fù)責(zé)根據(jù)需求寫測試大綱、編寫測試用例、測試報告。

教育經(jīng)歷

2006 /9--2010 /7 西北大學(xué) 軟件測試 本科

證 書

2009 /6 大學(xué)英語六級

2008 /12 大學(xué)英語四級

篇9

關(guān)鍵詞：軟件代碼審查；代碼審查過程；代碼審查問題

中圖分類號：TP311.52文獻(xiàn)標(biāo)識碼：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

一、引言

軟件測試常用方法可分為動態(tài)測試和靜態(tài)測試，只有動態(tài)測試和靜態(tài)測試有效結(jié)合，才能更好的完成軟件測試工作。代碼審查是軟件靜態(tài)測試中常用的軟件測試方法之一，代碼審查時，只要測試人員方法得當(dāng)、足夠細(xì)心，往往能夠產(chǎn)生意想不到的效果。

二、代碼審查的作用

代碼審查是在不執(zhí)行軟件的條件下有條理的仔細(xì)審查軟件代碼，從而找出軟件缺陷的過程。

代碼審查可以找出動態(tài)測試難以發(fā)現(xiàn)或隔離的軟件缺陷。在開發(fā)過程初期讓測試人員集中精力進(jìn)行軟件代碼審查非常有價值：可以提高代碼質(zhì)量；在項目的早期發(fā)現(xiàn)缺陷，將損失降至最低；促進(jìn)團(tuán)隊溝通、促進(jìn)知識共享、共同提高。

代碼審查還可以為動態(tài)測試時設(shè)計和執(zhí)行測試用例提供思路。通過代碼審查，可以確定有問題或者容易產(chǎn)生軟件缺陷的特性范圍。

三、代碼審查的過程

代碼審查過程可分為：代碼審查策劃階段、代碼審查實施階段以及代碼審查總結(jié)階段。

（一）代碼審查策劃階段

1.項目負(fù)責(zé)人分配代碼審查任務(wù)；

2.確定代碼審查策略：依據(jù)軟件開發(fā)文檔，確定軟件關(guān)鍵模塊，作為代碼審點(diǎn)；將復(fù)雜度高的模塊也作為代碼審查的重點(diǎn)；

3.項目負(fù)責(zé)人確定代碼審查單，審查內(nèi)容一般可包括：

（1）可追溯性：

――代碼是否遵循詳細(xì)設(shè)計？

――代碼是否與需求一致？

（2）邏輯：

――表示優(yōu)先級的括號用法是否正確？

――代碼是否依賴賦值順序？

――“if…else”和“switch”使用是否正確清晰？

――循環(huán)能否結(jié)束？

――復(fù)合語句是否正確地被花括號括起來？

――case語句是否所有可能出現(xiàn)的情況均已考慮？

――“goto”是否使用？

（3）數(shù)據(jù)：

――變量在使用前是否已初始化？

――變量的聲明是否按組劃分為外部的和內(nèi)部的？

――除最明顯的聲明外，是否所有聲明都有注釋？

――每個命名是否僅用于一個用途？

――常量名是否都大寫？

――常量是否都是通過“#define”定義的？

――用于多個文件中的常量是否在一個頭文件中定義？

――頭文件中是否存在可執(zhí)行的代碼？

――定義為指針的變量是否作為指針使用（而不是作為整數(shù)）？

――指針是否初始化？

――釋放內(nèi)存后是否將指針立即設(shè)置為NULL（或0）？

――傳遞指針到另一個函數(shù)的代碼是否首先檢查了指針的有效性？

――通過指針寫入動態(tài)分配內(nèi)存的代碼是否首先檢查了指針的有效性？

――宏的命名是否都大寫？

――數(shù)組是否越界？

（4）接口：

――在所有的函數(shù)及過程調(diào)用中，參數(shù)的個數(shù)都正確嗎？

――形參與實參類型匹配嗎？

――參數(shù)順序正確嗎？

――如果訪問共享內(nèi)存，是否具有相同的共享內(nèi)存結(jié)構(gòu)模式？

（5）文檔：

――軟件文檔是否與代碼一致？

（6）注釋：

――注釋與代碼是否一致？

――用于理解代碼的注釋是否提供了必要的信息？

――是否對數(shù)組和變量的作用進(jìn)行了描述？

（7）異常處理：

――是否所有可能的錯誤都已加以考慮？

（8）內(nèi)存：

――在向動態(tài)分配的內(nèi)存寫入之前是否檢查了內(nèi)存申請是否成功？

――若采用動態(tài)分配內(nèi)存，內(nèi)存空間分配是否正確？

――當(dāng)內(nèi)存空間不再需要時，是否被明確的釋放？

（9）其它：

――是否檢查了函數(shù)調(diào)用返回值？

――所有的輸入變量都用到了嗎？

――所有的輸出變量在輸出前都已賦值了嗎？

4.確定代碼審查進(jìn)度安排，項目負(fù)責(zé)人負(fù)責(zé)安排代碼審查的進(jìn)度。

（二）代碼審查實施階段

1.代碼講解：軟件開發(fā)人員詳細(xì)向測試人員講解如何以及為何這樣實現(xiàn)，測試人員提出問題和建議。通過代碼講解，測試人員對被審查的軟件有了一個全面的認(rèn)識，為后續(xù)代碼審查打下良好的基礎(chǔ)。

2.靜態(tài)分析：一般采用靜態(tài)分析工具進(jìn)行，主要分析軟件的代碼規(guī)模、模塊數(shù)、模塊調(diào)用關(guān)系、扇入、扇出、圈復(fù)雜度、注釋率等軟件質(zhì)量度量元。靜態(tài)分析在代碼審查時應(yīng)優(yōu)先進(jìn)行，有利于軟件測試人員在后續(xù)代碼審查時對軟件建立宏觀上認(rèn)識，在審查中容易做到有的放矢，更易于發(fā)現(xiàn)軟件代碼中的缺陷。

3.規(guī)則檢查：采用靜態(tài)分析工具對源程序進(jìn)行編碼規(guī)則檢查，對于工具報出的問題再由人工進(jìn)行進(jìn)一步的分析以確認(rèn)軟件問題，是一種比較有效的方法。

4.正式代碼審查：代碼審查可分兩步進(jìn)行：獨(dú)立審查和會議審查。根據(jù)情況，這兩步可以反復(fù)進(jìn)行多次。

（1）獨(dú)立審查：測試人員根據(jù)項目負(fù)責(zé)人的工作分配，獨(dú)自對自己負(fù)責(zé)的軟件模塊進(jìn)行代碼審查。測試人員根據(jù)代碼審查單，對相關(guān)代碼進(jìn)行閱讀、理解和分析后，記錄發(fā)現(xiàn)的錯誤和疑問。

（2）會議審查：項目負(fù)責(zé)人主持召開會議，測試人員和開發(fā)人員參加；測試人員就獨(dú)立審查發(fā)現(xiàn)的問題和疑問與開發(fā)人員溝通，并討論形成一致意見；對發(fā)現(xiàn)的問題匯總，填寫軟件問題報告單，提交開發(fā)人員處理。

5.更改確認(rèn)：開發(fā)人員對問題進(jìn)行處理，代碼審查人員對軟件的處理情況進(jìn)行確認(rèn)，驗證更改的正確性，并防止出現(xiàn)新的問題。

（三）代碼審查總結(jié)階段

代碼審查工作結(jié)束后，項目負(fù)責(zé)人總結(jié)代碼審查結(jié)果；編寫測試報告，對軟件代碼質(zhì)量進(jìn)行評估，給出合理建議。

把代碼審查提出的所有問題、亮點(diǎn)及最終結(jié)論詳細(xì)的記錄下來，供其他軟件項目代碼審查借鑒。必要時，可建立常見軟件代碼缺陷數(shù)據(jù)庫，為軟件代碼審查人員培訓(xùn)和執(zhí)行代碼審查提供數(shù)據(jù)支持，也可以為軟件編碼規(guī)則制定規(guī)范提供實踐依據(jù)。

四、代碼審查中的常見問題

如果軟件測試人員熟悉常見的軟件代碼審查問題，對代碼審查效率是很有幫助的。筆者根據(jù)自己的應(yīng)驗，列舉部分常見軟件代碼審查問題如下（僅供參考）：

（1）浮點(diǎn)數(shù)相等比較：可能造成程序未按設(shè)計的路徑執(zhí)行；

（2）因設(shè)計原因?qū)е履承┐a不能執(zhí)行：如邏輯表達(dá)式永遠(yuǎn)為真（或假）造成某分支不能執(zhí)行、代碼前面有return語句、某模塊從未被調(diào)用等；

（3）switch語句沒有break語句（有意如此設(shè)計時除外）；

（4）數(shù)組越界使用：數(shù)組越界容易發(fā)生在數(shù)組下標(biāo)是計算得到的情況下，而且審查時很難發(fā)現(xiàn)這種代碼缺陷，應(yīng)加以重視；

（5）變量未初始化就使用或者是條件賦值就使用；

（6）程序中存在未使用的多余變量；

（7）復(fù)合邏輯表達(dá)式?jīng)]有使用括號造成運(yùn)算順序錯誤；

（8）有返回值的函數(shù)中return沒有帶返回值；

（9）邏輯判別的表達(dá)式不是邏輯表達(dá)式；

（10）動態(tài)分配的內(nèi)存沒有及時釋放：忘記寫內(nèi)存釋放代碼或由于其它邏輯缺陷導(dǎo)致內(nèi)存釋放代碼未得到執(zhí)行；

（11）沒有對緩沖區(qū)溢出進(jìn)行必要的防護(hù)；

（12）訪問空指針，即指針未初始化就使用；

（13）指針指向的內(nèi)存釋放后，未將指針置為NULL：其它函數(shù)訪問該指針時，判斷指針不為空，當(dāng)作有效指針使用，會造成內(nèi)存訪問錯誤；

（14）注釋說明與程序代碼實現(xiàn)不一致，甚至相反；

（15）循環(huán)存在不能跳出的可能，程序中沒有相應(yīng)的保護(hù)機(jī)制。

五、結(jié)束語

篇10

關(guān)鍵詞： 軟件潛在分析； 軟件可靠性； 軟件安全性； 故障樹分析； 調(diào)試器

中圖分類號： TN915.04?34； TM417 文獻(xiàn)標(biāo)識碼： 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 引 言

在航空、航天等安全關(guān)鍵領(lǐng)域，軟件承擔(dān)的任務(wù)包括數(shù)據(jù)采集、導(dǎo)航控制和通信指揮等任務(wù)。隨著科技的發(fā)展，軟件已經(jīng)成為這些系統(tǒng)的神經(jīng)中樞，發(fā)揮著越來越重要的作用。在安全關(guān)鍵系統(tǒng)的運(yùn)行過程中，若其軟件一旦發(fā)生故障，就可能造成十分嚴(yán)重的后果[1]。然而，目前的軟件缺陷分析方法及工具均從某個單一的角度檢測軟件缺陷。在實際的可靠性和安全性測試中，不可能只采用其中的一種分析方法來斷定軟件的缺陷，而需要將多種分析方法有效結(jié)合，在最大程度上保證安全關(guān)鍵軟件的質(zhì)量[2]。

1 需求分析

1.1 設(shè)計目標(biāo)

首先，系統(tǒng)能夠提供以XML為接口的缺陷導(dǎo)入，并對工程項目代碼的靜態(tài)分析結(jié)果進(jìn)行處理，對代碼的安全缺陷進(jìn)行等級劃分，實現(xiàn)層次化的缺陷識別，統(tǒng)一缺陷類型。其次，該平臺能夠建立準(zhǔn)確的故障分析模式和故障樹分析方法，在測試過程中提高軟件故障分析及安全性測試的高效性和全面性，實現(xiàn)全數(shù)字仿真測試環(huán)境的無縫集成[3]。并提供便利的輔助功能，實現(xiàn)測試腳本的生成、測試用例的生成、測試報告單的生成。

1.2 業(yè)務(wù)流程

基于C語言的潛在分析工具共有兩條主線流程，如圖1所示。靜態(tài)分析結(jié)束后，通過XML接口將缺陷導(dǎo)入本系統(tǒng)，可以查看缺陷所在的源文件、根據(jù)已整理完成的缺陷分級獲得缺陷嚴(yán)重等級、對缺陷進(jìn)行處理并填寫問題報告單、編寫測試用例等。使用系統(tǒng)提供的工具在故障模式輔助下的故障樹建模，并計算故障樹的最小割集，生成測試用例[4]。以上2個步驟生成測試用例后，在全數(shù)字仿真測試平臺的基礎(chǔ)上編寫測試腳本，使用調(diào)試器進(jìn)行動態(tài)測試，在測試過程中可進(jìn)行單步跳過和單步進(jìn)入等，并觀察寄存器狀態(tài)、內(nèi)存值和變量值，測試結(jié)束后分析測試數(shù)據(jù)。

1.3 功能分析

系統(tǒng)是在全數(shù)字仿真測試環(huán)境采用軟件仿真技術(shù)的基礎(chǔ)上構(gòu)建的，仿真平臺能夠模擬SPARCV7處理器以及其他片上與片外設(shè)備的功能和時序關(guān)系，為最終的測試腳本運(yùn)行提供仿真的運(yùn)行平臺[5]。在此基礎(chǔ)上，本平臺包含下述4個系統(tǒng)，為軟件的潛在問題分析與處理提供服務(wù)，功能結(jié)構(gòu)如圖2所示。

1.4 靜態(tài)分析結(jié)果處理

靜態(tài)分析結(jié)果處理需要具備的功能包括項目管理、缺陷分析處理、測試用例管理、問題報告單管理和測試結(jié)果分析。其中，項目管理的作用是對每個軟件程序可以在該模塊建立相應(yīng)的項目來管理該軟件項目的問題；缺陷分析處理用于提供工具輔助測試人員對缺陷結(jié)果進(jìn)行處理；測試用例管理主要管理測試用例，對缺陷對應(yīng)測試用例的管理，包括添加、刪除和查詢?nèi)毕轀y試用例的功能；能夠通過提供的測試用例模板輔助生成測試用例。

1.5 故障模式及故障樹分析

靜態(tài)分析結(jié)果處理需要具備的功能包括故障樹建模、輔助建立故障樹及故障樹分析。其中故障樹建模提供用戶繪制故障樹的平臺，包括建模、導(dǎo)入保存節(jié)點(diǎn)屬性的編輯和故障樹工具集管理等。輔助建立故障樹指故障樹建模過程中，使用知識庫中已經(jīng)保存的故障模式及其對應(yīng)的故障樹，輔助用戶使用故障樹分析方法建立故障樹模型，該功能模塊分為故障樹對齊、完整性檢查、根據(jù)故障樹節(jié)點(diǎn)搜索故障樹、根據(jù)故障模式搜索故障樹、保存節(jié)點(diǎn)對應(yīng)的故障模式。故障樹分析是分析可靠性缺陷的主要模塊，是故障樹分析方法最核心的部分，包括：生成最小割集、計算事件概率、故障樹解析和測試用例生成[6]。

2 系統(tǒng)設(shè)計

2.1 硬件整體架構(gòu)

缺陷分析工具的設(shè)計采用基于服務(wù)器?客戶端的設(shè)計方案。其中服務(wù)器主要提供靜態(tài)分析服務(wù)和測試數(shù)據(jù)的存儲。靜態(tài)分析服務(wù)一般由靜態(tài)分析軟件提供，包括靜態(tài)分析服務(wù)、數(shù)據(jù)存儲服務(wù)。客戶端主要負(fù)責(zé)進(jìn)行實際的測試，包含：靜態(tài)分析結(jié)果處理、故障模式及故障樹分析、基于故障注入的動態(tài)測試功能。軟硬件的整體架構(gòu)如圖3所示。

2.2 軟件設(shè)計

客戶端軟件實現(xiàn)了平臺的主要功能，其設(shè)計分為三層，其結(jié)構(gòu)見圖4。其中用戶層為用戶提供直接的服務(wù)；功能層實現(xiàn)了本安全性測試平臺的主要功能，供用戶層模塊使用。

軟件是基于EclipseRCP進(jìn)行開發(fā)的，采用GEF框架進(jìn)行建模。

2.3 功能設(shè)計

根據(jù)系統(tǒng)的需求，將工具的功能劃分為靜態(tài)分析結(jié)果處理、故障模式及故障樹分析、動態(tài)測試調(diào)試器和基礎(chǔ)數(shù)據(jù)管理。

靜態(tài)分析結(jié)果包括項目管理、缺陷分析模塊、測試用管理模塊、問題報告單模塊和測試結(jié)果分析。

故障模式及故障樹分析包括故障樹建模、輔助建立故障樹及故障樹分析。

動態(tài)測試調(diào)試器包括工程管理、斷點(diǎn)管理、調(diào)試過程控制及調(diào)試信息管理。

基礎(chǔ)數(shù)據(jù)管理的劃分包括用戶管理、角色管理、缺陷分級管理及故障模式的管理。

3 系統(tǒng)實現(xiàn)

3.1 功能實現(xiàn)

3.1.1 靜態(tài)分析結(jié)果處理

靜態(tài)分析結(jié)果處理需要具備的功能包括項目管理、缺陷分析處理、測試用例管理、問題報告單管理和測試結(jié)果分析[7]。

缺陷分析處理：按文件劃分顯示缺陷通過SQL的group by file查詢實現(xiàn)。

測試用例管理：根據(jù)測試用例模板輔助生成測試用例時，首先要根據(jù)缺陷代碼查詢其對應(yīng)的所有用例模板，點(diǎn)擊模板后，將模板內(nèi)容填充至界面中，點(diǎn)擊添加即可添加。另外，測試用例模板的字段與測試用例的字段相同。

問題報告單管理：問題報告單和測試用例的導(dǎo)出通過iText完成。問題報告單和測試用例的表現(xiàn)形式為word中的表格，生成報告的核心是表格的創(chuàng)建。在表格的創(chuàng)建過程中，需根據(jù)用戶的處理自動填寫至相應(yīng)位置。

測試結(jié)果分析：首先按照給定條件查詢數(shù)據(jù)，再使用JfreeChart包繪制餅圖或柱狀圖。

3.1.2 故障模式及故障樹分析

故障樹建模采用GEF實現(xiàn)，GEF是一個圖形編輯框架。根據(jù)實際需要，系統(tǒng)提供了事件節(jié)點(diǎn)、門節(jié)點(diǎn)、轉(zhuǎn)入轉(zhuǎn)出三類節(jié)點(diǎn)和節(jié)點(diǎn)間的連線。

輔助建立故障樹，該模塊的實現(xiàn)涉及較多的數(shù)據(jù)庫操作，故障樹采用Sftree類描述，其包括多個表示節(jié)點(diǎn)的SftElement類，節(jié)點(diǎn)之間的關(guān)系為SftRelation類。

最小割集的生成是根據(jù)用戶構(gòu)建的故障樹進(jìn)行分析，查找導(dǎo)致頂事件發(fā)生的所有基本事件的集合。其步驟大致為：輸入故障樹，判斷故障樹是否合法，若不合法則直接返回，否則進(jìn)行下一步；利用“下行法”求該故障樹的最小割集；輸出得到的最小割集，并顯示在對話框中。

3.1.3 基礎(chǔ)數(shù)據(jù)管理

基礎(chǔ)數(shù)據(jù)管理模塊用于數(shù)據(jù)庫管理員對輔助測試數(shù)據(jù)的編輯，系統(tǒng)在與數(shù)據(jù)庫進(jìn)行交互過程中采用了Hibernate包[8]。對于數(shù)據(jù)庫表的增刪改，本系統(tǒng)采用了Common框架的實現(xiàn)方式。Common框架的流程如圖5所示。

3.2 SNMP協(xié)議網(wǎng)絡(luò)設(shè)備管理模塊的實現(xiàn)

3.2.1 最小割集生成算法

故障樹完整性檢查完畢，需要求出最小割集，采用“下行法”進(jìn)行計算，其步驟如下：

（1） 創(chuàng)建保存最小割集的列表cutset，cutset保存了若干個AnalysisNode對象，該對象保存了一個最小割集，包括這個最小割集中的所有節(jié)點(diǎn)nodes及每個節(jié)點(diǎn)到達(dá)根節(jié)點(diǎn)的路徑path；

（2） 從頂事件root開始，若root為null，則返回結(jié)束；不為null，則將創(chuàng)建AnalysisNode對象set，將root加入set的節(jié)點(diǎn)列表，并設(shè)置root的path為root，將set加入cutset列表；

（3） 獲得最小割集cutset中不全為根節(jié)點(diǎn)的currentset，若其為null，則轉(zhuǎn)步驟（7），否則轉(zhuǎn)步驟（4）；

（4） 將currentset從cuteset中移除，獲得currentset的首個非葉節(jié)點(diǎn)dealnode及門節(jié)點(diǎn)gatenode。若gatenode為“與門”，轉(zhuǎn)步驟（5）；若為“或門”，轉(zhuǎn)步驟（6）；

（5） 創(chuàng)建一個新的最小割集newset，遍歷currentset和“與”門的所有子節(jié)點(diǎn)inode，若其為dealnode則continue；將inode加入到newset的節(jié)點(diǎn)中，其路徑不變；遍歷gatenode的子節(jié)點(diǎn)gnode，將gnode加入到newset的節(jié)點(diǎn)中，并設(shè)置其路徑為dealnode的path與gnode之和，將newset加入到最小割集列表cutset中，轉(zhuǎn)步驟（3）；

（6） 遍歷“或”門的所有子節(jié)點(diǎn)snode，并創(chuàng)建一個新的最小割集newset，遍歷currentset的所有子節(jié)點(diǎn)inode，將其加入到newset的節(jié)點(diǎn)中；并獲得inode的路徑path，也加入到newset的path中；遍歷結(jié)束后將snode加入newset節(jié)點(diǎn)中并設(shè)置其path為dealnode路徑，將newset加入最小割集列表cutset，轉(zhuǎn)步驟（3）；

（7） 返回cutset，cutset即為該故障樹的最小割集列表。

3.2.2 混編文件生成算法

數(shù)字仿真測試平臺記錄了源代碼與混編碼的對應(yīng)方式，需要根據(jù)接口生成源代碼與匯編代碼的混合代碼，其中一條源代碼可能對應(yīng)著多個匯編代碼塊，需要一次讀取源文件，查找其相應(yīng)的混編文件并進(jìn)行顯示。生成混編文件的步驟如下：

（1） 獲得源文件，將其路徑添加到數(shù)組，保證創(chuàng)建混編文件的線程只有一個；

（2） 創(chuàng)建混編文件輸出流及源文件的輸入流；

（3） 遍歷源碼行號[i，]根據(jù)文件名和行號得到自[i]開始合理的第一條源碼行號[j，]若[j=0]或[i=j+1，]則將[i][到]lineSum行源文件寫入混編文件輸出流，轉(zhuǎn)步驟（6）；否則，將[i]至[j]行內(nèi)容寫入混編文件輸出流中；

（4） 根據(jù)源碼行對應(yīng)的目標(biāo)碼代碼的數(shù)組，獲得代碼塊的數(shù)組，遍歷代碼塊，獲得起始目標(biāo)碼地址m_start_address，設(shè)置address_temp為m_start_address，轉(zhuǎn)步驟（5）；

（5） 遍歷代碼塊，根據(jù)PC地址address_temp獲取該行匯編文件，加入混編文件輸出流，并設(shè)置address_temp為下條指令的地址（因為存在多條代碼塊時為call指令）；

（6） 將混編文件輸出流寫入文件，混編文件生成過程完成。

4 測試與驗證

4.1 測試準(zhǔn)備

（1） 測試環(huán)境包括服務(wù)器和客戶端兩個部分，硬件環(huán)境和軟件環(huán)境如表1所示。

（2） 在服務(wù)器上安裝數(shù)據(jù)庫系統(tǒng)，采用Klocwork作為靜態(tài)分析軟件，因此也需要安裝Klocwork的服務(wù)器端軟件。在客戶端上，需要安裝本系統(tǒng)和Klocwork的客戶端。

4.2 測試實例

（1） 靜態(tài)分析結(jié)果處理部分的驗證

如采用Klocwork9進(jìn)行靜態(tài)代碼分析，對其加入了支持GJB9369的擴(kuò)展規(guī)則，分析結(jié)果通過K9提供商提供的軟件，已經(jīng)轉(zhuǎn)為本工具可接受的XML文件。導(dǎo)入后發(fā)現(xiàn)存在源代碼缺陷的文件共有4個，總計10個缺陷。由于在基礎(chǔ)數(shù)據(jù)中設(shè)置代碼為“UNINIT.STACK.MUST”的缺陷嚴(yán)重度為等級1，對其進(jìn)行缺陷確認(rèn)并填寫問題報告單，對于等級2的確認(rèn)為非缺陷，等級3的缺陷忽略。

在對靜態(tài)分析結(jié)果進(jìn)行處理后，可通過兩種途徑對處理結(jié)果進(jìn)行驗證，一是通過打印問題報告單和測試用例與填寫內(nèi)容進(jìn)行比較確認(rèn)；二是通過數(shù)據(jù)統(tǒng)計進(jìn)行。經(jīng)過對比和驗證，靜態(tài)分析出的源代碼缺陷處理結(jié)果正確的生成了報告和統(tǒng)計圖。

（2） 故障模式和故障樹分析驗證

故障模式和故障樹分析驗證中，將“火箭發(fā)動機(jī)誤點(diǎn)火”作為頂事件進(jìn)行分析，造成頂事件發(fā)生的事件是外部因素或提前點(diǎn)火，其中外部因素不做分析，僅對提前點(diǎn)火事件進(jìn)行分析。提前點(diǎn)火事件可能由硬件故障或軟件故障造成，硬件故障的原因有蓄電池接通和點(diǎn)火電路允許，而軟件故障可能是由內(nèi)存溢出或線程非法造成。在故障樹的分析過程中，可根據(jù)節(jié)點(diǎn)名稱或故障模式輔助建模，在建模結(jié)束后，為每個基本事件設(shè)置發(fā)生的概率。建模結(jié)束后對故障樹進(jìn)行完整性檢查后即可進(jìn)行故障樹分析，分析結(jié)果如表2所示。

（3） 動態(tài)調(diào)試的驗證

首先需要針對前兩步添加的測試用例編寫相應(yīng)的測試腳本。在源代碼缺陷分析中遇到的未初始化變量 unsigned int [x，]對于該缺陷的驗證可通過兩種方式：一是在非故障注入的腳本運(yùn)行過程中，可通過單步調(diào)試查看[x]變量的變化；二是通過針對該問題編寫測試腳本，需按上述格式填寫，再從調(diào)試器中打開運(yùn)行，觀察測試記錄文件。首先，在 rs232.c的第36行加入斷點(diǎn)，點(diǎn)擊run運(yùn)行至該行號后，單步跳過至37行。然后，下文為腳本的片段，首先在2～3內(nèi)取變量[x]的值，再通過故障注入改變[x]的值，再次取出變量[x]的指令。

源代碼缺陷可能導(dǎo)致內(nèi)存變量發(fā)生故障，因此，需要對靜態(tài)分析處理中構(gòu)建的測試用例進(jìn)行確認(rèn)。在動態(tài)測試結(jié)束之后，還需要根據(jù)結(jié)果對測試用例進(jìn)行確認(rèn)，即確認(rèn)靜態(tài)分析或故障樹分析的軟件缺陷的測試用例是否通過。通過基于故障注入的動態(tài)測試，可在測試過程或其記錄的文件中觀察出故障發(fā)生時系統(tǒng)的運(yùn)行狀態(tài)，從而保證系統(tǒng)的安全性。而其他分析，如源代碼缺陷的分析和故障模式及故障樹分析可以在安全性缺陷分析采用的基于故障注入的動態(tài)測試中進(jìn)行驗證，驗證過程即跟蹤了缺陷的產(chǎn)生到故障的出現(xiàn)。

5 結(jié) 論

航天航空等關(guān)鍵領(lǐng)域，軟件缺陷直接影響著整個系統(tǒng)。本文由缺陷產(chǎn)生到發(fā)生故障的過程著手，進(jìn)行了全程跟蹤，并對這些安全關(guān)鍵軟件測試中使用的分析方法進(jìn)行了深入的整合。工具采用接口化的方法，使得各種分析方法能夠靈活組合；并模型化數(shù)據(jù)，建立了統(tǒng)一的數(shù)據(jù)管理平臺，使得分析數(shù)據(jù)以標(biāo)準(zhǔn)化形式表示，增加了數(shù)據(jù)使用的延展性，便于多領(lǐng)域的故障數(shù)據(jù)管理；建立了多階段的分析概念，把缺陷分析流程化，多維化。在可靠性和安全性測試流程中輔助分析人員針對C語言缺陷進(jìn)行完整的分析和記錄。

參考文獻(xiàn)

[1] 陳靜.Klocwork在嵌入式軟件靜態(tài)測試中的應(yīng)用[J].電子與電腦，2013，38（5）：89?92.

[2] 樊林波，吳映程，趙明.軟件可靠性與安全性的區(qū)別分析及其證明[J].計算機(jī)科學(xué)，2008，35（9）：285?288.

[3] 何鑫，鄭軍，劉暢.軟件安全性測試研究綜述[J].計算機(jī)測量與控制，2011，19（3）：493?496.

[4] 仉俊峰，洪炳，喬永強(qiáng).基于軟件方法故障注入系統(tǒng)[J].哈爾濱工業(yè)大學(xué)學(xué)報，2011，38（6）：873?876.

[5] 漆蓮芝，張軍，謝敏.故障樹分析測試用例生成技術(shù)研究與應(yīng)用[J].信息與電子工程，2010（8）：594?597.

[6] 姜興杰，楊峰輝.軟件可靠性分析與設(shè)計[J].現(xiàn)代電子技術(shù)，2011，34（7）：135?137.