測(cè)試報(bào)告缺陷分析范文

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

篇1

【關(guān)鍵詞】軟件測(cè)試 測(cè)試報(bào)告 測(cè)試流程

1 引言

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

2 軟件測(cè)試的目的

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

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

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

3 軟件測(cè)試的對(duì)象

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

4 軟件測(cè)試流程

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

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

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

4.1.1 召開(kāi)測(cè)試啟動(dòng)會(huì)議

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

4.1.2 設(shè)計(jì)測(cè)試用例

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

4.2 實(shí)施測(cè)試階段

4.2.1 實(shí)施測(cè)試用例

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

4.2.2 填寫(xiě)測(cè)試記錄

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

4.2.3 提交BUG清單

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

4.2.4 提交測(cè)試報(bào)告

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

（1）測(cè)試報(bào)告的版本。

（2）測(cè)試的人員和時(shí)間。

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

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

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

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

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

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

4.3 總結(jié)階段

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

4.3.1 編寫(xiě)測(cè)試總結(jié)報(bào)告

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

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

（1）測(cè)試資源概述―多少人、多長(zhǎng)時(shí)間。

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

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

（4）測(cè)試需求覆蓋率―原先列舉的測(cè)試需求的測(cè)試覆蓋率，可能 一部分測(cè)試需求因?yàn)橘Y源和優(yōu)先級(jí)的因素沒(méi)有進(jìn)行測(cè)試，那么 在這里要進(jìn)行說(shuō)明。

（5）測(cè)試評(píng)估―從總體對(duì)項(xiàng)目質(zhì)量進(jìn)行評(píng)估。

（6）測(cè)試組建議―從測(cè)試組的角度為項(xiàng)目組提出工作建議。

4.3.2 測(cè)試驗(yàn)收

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

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

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

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

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

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

4.3.3 測(cè)試歸檔

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

參考文獻(xiàn)

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

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

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

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

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

篇2

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

居住地：北京

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

E-mail：

最近工作[1年7個(gè)月]

公　司：XX有限公司

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

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

最高學(xué)歷

學(xué)　歷：本科

專(zhuān)　業(yè)：計(jì)算機(jī)科學(xué)與技術(shù)

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

自我評(píng)價(jià)

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

求職意向

到崗時(shí)間：可隨時(shí)到崗

工作性質(zhì)：全職

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

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

期望月薪：面議/月

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

工作經(jīng)驗(yàn)

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

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

集成部

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

1.熟悉軟件測(cè)試?yán)碚摗⒘鞒毯头椒ǎ休^強(qiáng)的邏輯分析能力、測(cè)試用例設(shè)計(jì)能力。

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

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

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

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

集成部

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

1.熟悉軟件測(cè)試?yán)碚摗⒘鞒毯头椒ǎ休^強(qiáng)的邏輯分析能力、測(cè)試用例設(shè)計(jì)能力。

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

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

教育經(jīng)歷

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

證書(shū)

2009/12 大學(xué)英語(yǔ)四級(jí)

篇3

1 簡(jiǎn)介

1.1 范圍

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

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

1.2 定義、首字母縮寫(xiě)詞和縮略語(yǔ)

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

1.3 概述

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

2 測(cè)試設(shè)備

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

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

3 測(cè)試環(huán)境

3.1 硬件配置

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

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

3.2 軟件配置

服務(wù)器軟件配置：開(kāi)發(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ù)庫(kù)系統(tǒng)：SERVER 2008。

3.3 測(cè)試方法

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

4 測(cè)試覆蓋分析

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

被驗(yàn)證通過(guò)的需求26個(gè)，需求總數(shù)26個(gè)。

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

4.1 缺陷收斂曲線(xiàn)圖

4.2 缺陷生命周期圖

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

5 測(cè)試結(jié)論

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

篇4

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

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

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

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

如何組織管理

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

軟件測(cè)試的過(guò)程

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

“第三方”測(cè)試什么

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

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

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

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

第三類(lèi)是對(duì)軟件企業(yè)的CMM評(píng)估認(rèn)證,也是最高層次的軟件評(píng)測(cè)。

了解測(cè)試評(píng)估

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

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

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

篇5

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

中圖分類(lèi)號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1007-9599　（2012）　18-0000-02

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

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

2 軟件測(cè)試的流程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)語(yǔ)

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

參考文獻(xiàn)：

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

篇6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)　語(yǔ)

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

參考文獻(xiàn)

篇7

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

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

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

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

1 測(cè)試執(zhí)行策略?xún)?yōu)化

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

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

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

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

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

3 結(jié)束語(yǔ)

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

參考文獻(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]陳翔，陳繼紅，鞠小林，等.“回歸測(cè)試中的測(cè)試用例優(yōu)先排序技術(shù)述評(píng)”[J].系統(tǒng)軟件與軟件工程，2013（8）.

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

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

篇8

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

居住地：上海

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

E-mail：

最近工作 [ 1年7個(gè)月 ]

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

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

職　位：軟件測(cè)試

最高學(xué)歷

學(xué)　歷：本科

專(zhuān)　業(yè)：軟件測(cè)試

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

自我評(píng)價(jià)

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

求職意向

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

工作性質(zhì)： 全職

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

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

期望月薪： 面議/月

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

工作經(jīng)驗(yàn)

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

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

測(cè)試部 軟件測(cè)試

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

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

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

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

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

6.負(fù)責(zé)根據(jù)用戶(hù)需求，編寫(xiě)用戶(hù)使用說(shuō)明手冊(cè)；

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

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

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

事業(yè)部 軟件測(cè)試

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

2、負(fù)責(zé)在項(xiàng)目測(cè)試過(guò)程中，制定測(cè)試計(jì)劃，參與測(cè)試用例的編寫(xiě)、修改和審核；

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

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

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

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

技術(shù)部 軟件測(cè)試

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

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

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

4、負(fù)責(zé)根據(jù)需求寫(xiě)測(cè)試大綱、編寫(xiě)測(cè)試用例、測(cè)試報(bào)告。

教育經(jīng)歷

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

證 書(shū)

2009 /6 大學(xué)英語(yǔ)六級(jí)

2008 /12 大學(xué)英語(yǔ)四級(jí)

篇9

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

中圖分類(lèi)號(hào)：TP311.52文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：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

一、引言

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

二、代碼審查的作用

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

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

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

三、代碼審查的過(guò)程

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

（一）代碼審查策劃階段

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

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

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

（1）可追溯性：

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

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

（2）邏輯：

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

――代碼是否依賴(lài)賦值順序？

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

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

――復(fù)合語(yǔ)句是否正確地被花括號(hào)括起來(lái)？

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

――“goto”是否使用？

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

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

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

――除最明顯的聲明外，是否所有聲明都有注釋?zhuān)?/p>

――每個(gè)命名是否僅用于一個(gè)用途？

――常量名是否都大寫(xiě)？

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

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

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

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

――指針是否初始化？

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

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

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

――宏的命名是否都大寫(xiě)？

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

（4）接口：

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

――形參與實(shí)參類(lèi)型匹配嗎？

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

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

（5）文檔：

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

（6）注釋?zhuān)?/p>

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

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

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

（7）異常處理：

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

（8）內(nèi)存：

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

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

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

（9）其它：

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

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

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

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

（二）代碼審查實(shí)施階段

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

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

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

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

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

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

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

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

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

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

四、代碼審查中的常見(jiàn)問(wèn)題

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

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

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

（3）switch語(yǔ)句沒(méi)有break語(yǔ)句（有意如此設(shè)計(jì)時(shí)除外）；

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

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

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

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

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

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

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

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

（12）訪(fǎng)問(wèn)空指針，即指針未初始化就使用；

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

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

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

五、結(jié)束語(yǔ)

篇10

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

中圖分類(lèi)號(hào)： TN915.04?34； TM417 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 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ā)揮著越來(lái)越重要的作用。在安全關(guān)鍵系統(tǒng)的運(yùn)行過(guò)程中，若其軟件一旦發(fā)生故障，就可能造成十分嚴(yán)重的后果[1]。然而，目前的軟件缺陷分析方法及工具均從某個(gè)單一的角度檢測(cè)軟件缺陷。在實(shí)際的可靠性和安全性測(cè)試中，不可能只采用其中的一種分析方法來(lái)斷定軟件的缺陷，而需要將多種分析方法有效結(jié)合，在最大程度上保證安全關(guān)鍵軟件的質(zhì)量[2]。

1 需求分析

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

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

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

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

1.3 功能分析

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

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

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

1.5 故障模式及故障樹(shù)分析

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

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

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

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

2.2 軟件設(shè)計(jì)

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

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

2.3 功能設(shè)計(jì)

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

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

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

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

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

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

3.1 功能實(shí)現(xiàn)

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

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

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

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

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

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

3.1.2 故障模式及故障樹(shù)分析

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

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

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

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

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

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

3.2.1 最小割集生成算法

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

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

（2） 從頂事件root開(kāi)始，若root為null，則返回結(jié)束；不為null，則將創(chuàng)建AnalysisNode對(duì)象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的首個(gè)非葉節(jié)點(diǎn)dealnode及門(mén)節(jié)點(diǎn)gatenode。若gatenode為“與門(mén)”，轉(zhuǎn)步驟（5）；若為“或門(mén)”，轉(zhuǎn)步驟（6）；

（5） 創(chuàng)建一個(gè)新的最小割集newset，遍歷currentset和“與”門(mén)的所有子節(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） 遍歷“或”門(mén)的所有子節(jié)點(diǎn)snode，并創(chuàng)建一個(gè)新的最小割集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即為該故障樹(shù)的最小割集列表。

3.2.2 混編文件生成算法

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

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

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

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

（4） 根據(jù)源碼行對(duì)應(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為下條指令的地址（因?yàn)榇嬖诙鄺l代碼塊時(shí)為call指令）；

（6） 將混編文件輸出流寫(xiě)入文件，混編文件生成過(guò)程完成。

4 測(cè)試與驗(yàn)證

4.1 測(cè)試準(zhǔn)備

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

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

4.2 測(cè)試實(shí)例

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

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

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

（2） 故障模式和故障樹(shù)分析驗(yàn)證

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

（3） 動(dòng)態(tài)調(diào)試的驗(yàn)證

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

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

5 結(jié) 論

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

參考文獻(xiàn)

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

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

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

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

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

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