軟件測(cè)試工程師筆試題目和答案

1、1軟件測(cè)試的目的是盡可能多的找出軟件的缺陷。 （ Y）2Beta 測(cè)試是驗(yàn)收測(cè)試的一種。 （Y） 3驗(yàn)收測(cè)試是由最終用戶來實(shí)施的。 （ N） 4項(xiàng)目立項(xiàng)前測(cè)試人員不需要提交任何工件。 （ Y）5 單元測(cè)試能發(fā)現(xiàn)約80%勺軟件缺陷。（Y） 6代碼評(píng)審是檢查源代碼是否達(dá)到模塊設(shè)計(jì)的要求。 （ N） 7自底向上集成需要測(cè)試員編寫驅(qū)動(dòng)程序。（ Y）8負(fù)載測(cè)試是驗(yàn)證要檢驗(yàn)勺系統(tǒng)勺能力最高能達(dá)到什么程度。（ N）9測(cè)試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過。（ N）10代碼評(píng)審員一般由測(cè)試員擔(dān)任。 （ N） 11我們可以人為勺使得軟件不存在配置問題。（ N）12集成測(cè)試計(jì)劃在需求分析階段末提交。（ N）

2、二、選擇題1軟件驗(yàn)收測(cè)試勺合格通過準(zhǔn)則是： （ ABCD）A. 軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求。B. 所有測(cè)試項(xiàng)沒有殘余一級(jí)、二級(jí)和三級(jí)錯(cuò)誤。C. 立項(xiàng)審批表、需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致。D. 驗(yàn)收測(cè)試工件齊全。 2軟件測(cè)試計(jì)劃評(píng)審會(huì)需要哪些人員參加？（ ABCD）A. 項(xiàng)目經(jīng)理B. SQA負(fù)責(zé)人C. 配置負(fù)責(zé)人 D 測(cè)試組3. 下列關(guān)于alpha測(cè)試的描述中正確的是：（AD Aalpha 測(cè)試需要用戶代表參加 Balpha 測(cè)試不需要用戶代表參加 Calpha 測(cè)試是系統(tǒng)測(cè)試的一種 Dalpha 測(cè)試是驗(yàn)收測(cè)試的一種 4測(cè)試設(shè)計(jì)員的職責(zé)有： （B

3、C）A. 制定測(cè)試計(jì)劃B. 設(shè)計(jì)測(cè)試用例C. 設(shè)計(jì)測(cè)試過程、腳本D 評(píng)估測(cè)試活動(dòng)5 軟件實(shí)施活動(dòng)的進(jìn)入準(zhǔn)則是： （ ABC）A 需求工件已經(jīng)被基線化B 詳細(xì)設(shè)計(jì)工件已經(jīng)被基線化C 構(gòu)架工件已經(jīng)被基線化D 項(xiàng)目階段成果已經(jīng)被基線化三、填空題1. 軟件驗(yàn)收測(cè)試包括：正式驗(yàn)收測(cè)試， alpha 測(cè)試， beta 測(cè)試。2. 系統(tǒng)測(cè)試的策略有：功能測(cè)試，性能測(cè)試，可靠性測(cè)試，負(fù)載測(cè)試，易用性測(cè)試，強(qiáng)度測(cè) 試，安全測(cè)試，配置測(cè)試，安裝測(cè)試，卸載測(cè)試，文擋測(cè)試，故障恢復(fù)測(cè)試，界面測(cè)試，容 量測(cè)試，兼容性測(cè)試，分布測(cè)試，可用性測(cè)試， （有的可以合在一起，分開寫只要寫出 15 就 滿分哦）3. 設(shè)計(jì)系統(tǒng)測(cè)試計(jì)

4、劃需要參考的項(xiàng)目文擋有：軟件測(cè)試計(jì)劃，軟件需求工件和迭代計(jì)劃。4. 對(duì)面向過程的系統(tǒng)采用的集成策略有：自頂向下，自底向上兩種。5. 通過畫因果圖來寫測(cè)試用例的步驟為：（1）分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價(jià)類），哪些是結(jié)果（即輸出條件），并給每個(gè)原因和結(jié)果賦予一個(gè)標(biāo)識(shí)符。（2）分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對(duì)應(yīng)的是什 么關(guān)系 ?根據(jù)這些關(guān)系，畫出因果圖。（3）由于語法或環(huán)境限制， 有些原因與原因之間， 原因與結(jié)果之間的組合情況不可能出現(xiàn)。 為表明這些特殊情況，在因果圖上用一些記號(hào)標(biāo)明約束或限制條件。（4）把因果圖轉(zhuǎn)換成判定表。（5）

5、把判定表的每一列拿出來作為依據(jù)，設(shè)計(jì)測(cè)試用例。四、簡(jiǎn)答題1. 區(qū)別階段評(píng)審的與同行評(píng)審 同行評(píng)審目的 :發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯(cuò)誤 ,只要是找錯(cuò)誤 ; 階段評(píng)審目的 : 評(píng)審模塊階段作品的正確性可行性及完整性 同行評(píng)審人數(shù)：3-7人人員必須經(jīng)過同行評(píng)審會(huì)議的培訓(xùn),由SQA旨導(dǎo) 階段評(píng)審人數(shù) :5 人左右評(píng)審人必須是專家具有系統(tǒng)評(píng)審資格 同行評(píng)審內(nèi)容 ： 內(nèi)容小一般文檔 < 40 頁, 代碼< 500 行 階段評(píng)審內(nèi)容 ： 內(nèi)容多 , 主要看重點(diǎn) 同行評(píng)審時(shí)間 ： 一小部分工作產(chǎn)品完成 階段評(píng)審時(shí)間 ： 通常是設(shè)置在關(guān)鍵路徑的時(shí)間點(diǎn)上 !2. 什么是軟件測(cè)試 為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行

6、程序的過程3 簡(jiǎn)述集成測(cè)試的過程 系統(tǒng)集成測(cè)試主要包括以下過程：1. 構(gòu)建的確認(rèn)過程。2. 補(bǔ)丁的確認(rèn)過程。3. 系統(tǒng)集成測(cè)試測(cè)試組提交過程。4. 測(cè)試用例設(shè)計(jì)過程。5. 測(cè)試代碼編寫過程。6. Bug 的報(bào)告過程。7. 每周/ 每?jī)芍艿臉?gòu)建過程。8. 點(diǎn)對(duì)點(diǎn)的測(cè)試過程。9. 組內(nèi)培訓(xùn)過程。4 怎么做好文檔測(cè)試 仔細(xì)閱讀，跟隨每個(gè)步驟，檢查每個(gè)圖形，嘗試每個(gè)示例。 P142 檢查文檔的編寫是否滿足文檔編寫的目的 內(nèi)容是否齊全，正確內(nèi)容是否完善標(biāo)記是否正確5 白盒測(cè)試有幾種方法總體上分為靜態(tài)方法和動(dòng)態(tài)方法兩大類。 靜態(tài)：關(guān)鍵功能是檢查軟件的表示和描述是否一致 , 沒有沖突或者沒有歧義 動(dòng)態(tài)：語句

7、覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。6 系統(tǒng)測(cè)試計(jì)劃是否需要同行審批，為什么 ? 需要，系統(tǒng)測(cè)試計(jì)劃屬于項(xiàng)目階段性關(guān)鍵文檔，因此需要評(píng)審。7Alpha 測(cè)試與 beta 的區(qū)別？Alpha 測(cè)試在系統(tǒng)開發(fā)接近完成時(shí)對(duì)應(yīng)用系統(tǒng)的測(cè)試；測(cè)試后仍然會(huì)有少量的設(shè)計(jì)變更。這 種測(cè)試一般由最終用戶或其它人員完成，不能由程序或測(cè)試員完成。Beta 測(cè)試當(dāng)開發(fā)和測(cè)試根本完成時(shí)所做的測(cè)試， 最終的錯(cuò)誤和問題需要在最終發(fā)行前找到。 這種測(cè)試一般由最終用戶或其它人員完成，不能由程序員或測(cè)試員完成。8 比較負(fù)載測(cè)試，容量測(cè)試和強(qiáng)度測(cè)試的區(qū)別？ 負(fù)載測(cè)試：在一定的工作負(fù)荷下，系統(tǒng)的負(fù)荷及響應(yīng)

8、時(shí)間。 強(qiáng)度測(cè)試： 在一定的負(fù)荷條件下， 在較長(zhǎng)時(shí)間跨度內(nèi)的系統(tǒng)連續(xù)運(yùn)行給系統(tǒng)性能所造成的影 響。容量測(cè)試：容量測(cè)試目的是通過測(cè)試預(yù)先分析出反映軟件 系統(tǒng)應(yīng)用特征的某項(xiàng)指標(biāo)的極限 值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等） ，系統(tǒng)在其極限值狀態(tài)下沒有出現(xiàn)任何軟件故障 或還能保持主要功能正常運(yùn)行。容量測(cè)試 還將確定測(cè)試對(duì)象在給定時(shí)間內(nèi)能夠持續(xù)處理的 最大負(fù)載或工作量。 容量測(cè)試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處 理。容量測(cè)試是面向數(shù)據(jù) 的，并且它的目的是顯示系統(tǒng)可以處理目標(biāo)內(nèi)確定的數(shù)據(jù)容量。9 測(cè)試結(jié)束的標(biāo)準(zhǔn)是什么？ 用例全部測(cè)試。覆蓋率達(dá)到標(biāo)準(zhǔn)。缺陷率達(dá)到標(biāo)準(zhǔn)。其他指標(biāo)達(dá)到質(zhì)量

9、標(biāo)準(zhǔn)10 描述軟件測(cè)試活動(dòng)的生命周期？ 測(cè)試周期分為計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)、執(zhí)行、總結(jié)。其中： 計(jì)劃：對(duì)整個(gè)測(cè)試周期中所有活動(dòng)進(jìn)行規(guī)劃，估計(jì)工作量、風(fēng)險(xiǎn)，安排人力物力資源，安排 進(jìn)度等；設(shè)計(jì)：完成測(cè)試方案，從技術(shù)層面上對(duì)測(cè)試進(jìn)行規(guī)劃； 實(shí)現(xiàn)：進(jìn)行測(cè)試用例和測(cè)試規(guī)程設(shè)計(jì)； 執(zhí)行：根據(jù)前期完成的計(jì)劃、方案、用例、規(guī)程等文檔，執(zhí)行測(cè)試用例?？偨Y(jié)：記錄測(cè)試結(jié)果，進(jìn)行測(cè)試分析，完成測(cè)試報(bào)告。11 軟件的缺陷等級(jí)應(yīng)如何劃分？A 類嚴(yán)重錯(cuò)誤，包括以下各種錯(cuò)誤： 1 由于程序所引起的死機(jī) , 非法退出 2 死循環(huán) 3 數(shù)據(jù)庫發(fā)生死鎖 4 因錯(cuò)誤操作導(dǎo)致的程序中斷 5 功能錯(cuò)誤 6 與數(shù)據(jù)庫連接錯(cuò) 誤 7 數(shù)據(jù)通訊錯(cuò)

10、誤B 類較嚴(yán)重錯(cuò)誤，包括以下各種錯(cuò)誤： 1 程序錯(cuò)誤 2 程序接口錯(cuò)誤 3 數(shù)據(jù)庫的 表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件C 類一般性錯(cuò)誤，包括以下各種錯(cuò)誤： 1 操作界面錯(cuò)誤（包括數(shù)據(jù)窗口內(nèi)列名定義、 含義是否一致） 2 打印內(nèi)容、格式錯(cuò)誤 3 簡(jiǎn)單的輸入限制未放在前臺(tái)進(jìn)行控制 4 刪 除操作未給出提示 5 數(shù)據(jù)庫表中有過多的空字段D 類較小錯(cuò)誤，包括以下各種錯(cuò)誤： 1 界面不規(guī)范 2 輔助說明描述不清楚 3 輸 入輸出不規(guī)范 4 長(zhǎng)操作未給用戶提示 5 提示窗口文字未采用行業(yè)術(shù)語 6 可輸入?yún)^(qū) 域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志E類一測(cè)試建議五、用例設(shè)計(jì)隨意選取一個(gè)簡(jiǎn)單物品， 假定是一個(gè)喝

11、水的帶廣告圖案的花紙杯， 設(shè)計(jì)出盡可能多的測(cè)試用 例。測(cè)試項(xiàng)目：杯子需求測(cè)試 : 查看杯子使用說明書界面測(cè)試 : 查看杯子外觀 功能度：用水杯裝水看漏不漏；水能不能被喝到 安全性：杯子有沒有毒或細(xì)菌 可*性：杯子從不同高度落下的損壞程度 可移植性：杯子再不同的地方、溫度等環(huán)境下是否都可以正常使用 兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等 易用性：杯子是否燙手、是否有防滑措施、是否方便飲用 用戶文檔：使用手冊(cè)是否對(duì)杯子的用法、限制、使用條件等有詳細(xì)描述 疲勞測(cè)試：將杯子盛上水（案例一）放 24 小時(shí)檢查泄漏時(shí)間和情況；盛上汽油（案例二）放 24 小時(shí)檢查泄漏時(shí)間和情況等 壓力測(cè)試：用根針

12、并在針上面不斷加重量，看壓強(qiáng)多大時(shí)會(huì)穿透 跌落測(cè)試 : ? 杯子加包裝 （ 有填充物 ）, 在多高的情況摔下不破損 震動(dòng)測(cè)試: 杯子加包裝 （有填充物）, 六面震動(dòng),檢查產(chǎn)品是否能應(yīng)對(duì)惡劣的鐵路 公路 航空 運(yùn)輸測(cè)試數(shù)據(jù)： 測(cè)試數(shù)據(jù)具體編寫此處略。其中應(yīng)用到：場(chǎng)景法、等價(jià)類劃分法、因果圖法、錯(cuò)誤推測(cè)法、邊界值法等方法期望輸出： 該期望輸出需查閱國標(biāo)、行標(biāo)以及使用用戶的需求 說明書測(cè)試 : 檢查說明書書寫準(zhǔn)確性六、網(wǎng)絡(luò)、操作系統(tǒng)、語言知識(shí)1請(qǐng)你分別劃劃OSI的七層網(wǎng)絡(luò)結(jié)構(gòu)圖，和TCP/IP的五層結(jié)構(gòu)圖？答: 七層結(jié)構(gòu)從上到下依次是：7 應(yīng)用層 ;6 表示層 ;5 會(huì)話層 ;4 傳輸層 ;3 網(wǎng)絡(luò)

13、層 ;2 數(shù)據(jù)鏈路層 ;1 物理層 五層結(jié)構(gòu)是5 應(yīng)用層 ;4 運(yùn)輸層 ;3 網(wǎng)絡(luò)層 ; 2 鏈路層 ;1 物理層。2請(qǐng)你詳細(xì)的解釋一下IP協(xié)議的定義，在哪個(gè)層上面，主要有什么作用？TCP與UDF呢？答:UDP, TCP在傳輸層，IP在網(wǎng)絡(luò)層，TCP/IP 是英文 Transmission Control Protocol/Internet Protocol的縮寫，意思是 "傳輸控制協(xié)議/網(wǎng)際協(xié)議"。TCP/IP協(xié)議組之所以流行，部分原因是因?yàn)樗梢杂迷诟鞣N各樣的 信道和底層協(xié)議(例如 T1和、以太網(wǎng)以及RS-232串行接口)之上。確切地說，TCP/IP協(xié) 議是一組包括 T

14、CF協(xié)議和 IP 協(xié)議，UDP(User Datagram ProtocoI )協(xié)議、ICMP (Internet Control MessageProtocol )協(xié)議和其他一些協(xié)議的協(xié)議組。 TCP/IP 協(xié)議并不完全符合 OSI 的七層參考模型。 傳統(tǒng)的開放式系統(tǒng)互連參考模型， 是一種通信協(xié)議的 7 層抽象的參考模型 , 其中每一層執(zhí)行某一特定任務(wù)。該模型的目的是使各種硬件在相同的層次上相互通信。這 7 層是:物理層、數(shù)據(jù)鏈路層、網(wǎng)路層、傳輸層、話路層、表示層和應(yīng)用層。而 TCP/IP通訊協(xié) 議采用了 4 層的層級(jí)結(jié)構(gòu)，每一層都呼叫它的下一層所提供的網(wǎng)絡(luò)來完成自己的需求。這 4 層分別為

15、：應(yīng)用層：應(yīng)用程序間溝通的層， 如簡(jiǎn)單電子郵件傳輸( SMTP) 、文件傳輸協(xié)議( FTP) 、 網(wǎng)絡(luò)遠(yuǎn)程訪問協(xié)議( TeInet )等。傳輸層：在此層中，它提供了節(jié)點(diǎn)間的數(shù)據(jù)傳送服務(wù)，如傳輸控制協(xié)議(TCP、用戶數(shù)據(jù)報(bào)協(xié)議(UDP等，TCP和 UDP給數(shù)據(jù)包加入傳輸數(shù)據(jù)并把它傳輸?shù)? 請(qǐng)問交換機(jī)和路由器分別的實(shí)現(xiàn)原理是什么？分別在哪個(gè)層次上面實(shí)現(xiàn)的？ 一般意義上說交換機(jī)是工作在數(shù)據(jù)鏈路層。但隨著科技的發(fā)展，現(xiàn)在有了三層交換機(jī)，三層 交換機(jī)已經(jīng)擴(kuò)展到了網(wǎng)絡(luò)層。也就是說：它等于“數(shù)據(jù)鏈路層 + 部分網(wǎng)絡(luò)層”。交換機(jī)中 傳的是幀。通過存儲(chǔ)轉(zhuǎn)發(fā)來實(shí)現(xiàn)的。 路由器是工作在網(wǎng)絡(luò)層。路由器中傳的是 IP

16、數(shù)據(jù)報(bào)。 主要是選址和路由。4請(qǐng)問C+啲類和C里面的STRUC有什么區(qū)別？ 答: 除關(guān)鍵字不同外 (cIass,struct) 的唯一區(qū)別是 , 結(jié)構(gòu)在默認(rèn)情況下的成員是公共 (pubIic) 的, 而類在默認(rèn)情況下的成員是私有 (private) 的。在C+中,結(jié)構(gòu)是特殊的類。cIass 是從 struct 發(fā)展而來的。之所以將 struct 和 cIass 都保留，是因?yàn)椋? 、提出 cIass 是為了強(qiáng)調(diào)一種概念。2、保留 struct 是為了照顧到大多數(shù)人的習(xí)慣。struct 和 cIass 是有區(qū)別的。struct 保證成員按照聲明順序在內(nèi)存中存儲(chǔ)。 cIass 不保證等等 而它們都

17、可以繼承，實(shí)現(xiàn)多態(tài)等。但也有少許區(qū)別。比如：struct A ；cIass B : A ; 8086 是 Inter 的 16位微處理器有 16根數(shù)據(jù)線和 20根地址線，它既能處理 16位數(shù)據(jù)，也能處理 8位數(shù)據(jù)內(nèi)部數(shù)據(jù)總線都是按 16位設(shè)計(jì)的，單外部數(shù)據(jù)總線只有 8條七、其他一、談?wù)勀懔私獾能浖y(cè)試流程及工具一般測(cè)試流程：1. 需求分析階段：對(duì)業(yè)務(wù)的學(xué)習(xí)，分析需求點(diǎn)。2. 測(cè)試計(jì)劃階段：測(cè)試組長(zhǎng)根據(jù)SOWf始編寫測(cè)試計(jì)劃，其中包括人員，軟件硬件資源， 測(cè)試點(diǎn)，集成順序，進(jìn)度安排和風(fēng)險(xiǎn)識(shí)別等內(nèi)容。3. 測(cè)試設(shè)計(jì)階段： 測(cè)試方案一般由對(duì)需求很熟的高資深的測(cè)試工程師設(shè)計(jì)， 測(cè)試方案要求根 據(jù)SRS

18、上的每個(gè)需求點(diǎn)設(shè)計(jì)出包括需求點(diǎn)簡(jiǎn)介，測(cè)試思路和詳細(xì)測(cè)試方法三部分的方案。測(cè)試方案編寫完成后也需要進(jìn)行評(píng)審。4. 測(cè)試方案階段： 主要是對(duì)測(cè)試用例和規(guī)程的設(shè)計(jì)。 測(cè)試用例是根據(jù)測(cè)試方案來編寫的， 通過測(cè)試方案階段，測(cè)試人員對(duì)整個(gè)系統(tǒng)需求有了詳細(xì)的理解。這時(shí)開始編寫用例才能 保證用例的可執(zhí)行和對(duì)需求的覆蓋。測(cè)試用例需要包括測(cè)試項(xiàng)，用例級(jí)別，預(yù)置條件，操作 步驟和預(yù)期結(jié)果。 其中操作步驟和預(yù)期結(jié)果需要編寫詳細(xì)和明確。 測(cè)試用例應(yīng)該覆蓋測(cè)試方 案，而測(cè)試方案又覆蓋了測(cè)試需求點(diǎn)，這樣才能保證客戶需求不遺漏。同樣，測(cè)試用例也需 要評(píng)審。5. 測(cè)試執(zhí)行階段：執(zhí)行測(cè)試用例，及時(shí)提交有質(zhì)量的Bug和測(cè)試日?qǐng)?bào)，測(cè)

19、試報(bào)告等相關(guān)文檔。 流程：需求分析一測(cè)試計(jì)劃一測(cè)試設(shè)計(jì)一測(cè)試環(huán)境搭建一測(cè)試執(zhí)行一測(cè)試記錄一缺陷管理一軟件評(píng)估RTM.測(cè)試工具：C/S及B/S架構(gòu)相關(guān)的軟件產(chǎn)品，那么對(duì)不同操作系統(tǒng)，女口Windows系列、unix、linux甚至蘋果OS等 測(cè)試環(huán)境都是必須的 常用的軟件測(cè)試工具分為： 開源測(cè)試管理工具： Bugfree 、 Bugzilla 、 TestLink 、 mantis 開源功能自動(dòng)化測(cè)試工具： Watir 、 Selenium、 MaxQ、 WebInject 開 源 性 能 自 動(dòng) 化 測(cè) 試 工 具 ： Jmeter 、 OpenSTA、 DBMonster 、 TPTEST、

20、 Web ApplicationLoadSimulatorTestDirector:企業(yè)級(jí)測(cè)試管理工具，也是業(yè)界第一個(gè)基于Web的測(cè)試管理系統(tǒng)。Quality Center:基于Web的測(cè)試管理工具，可以組織和管理應(yīng)用程序測(cè)試流程的所有階 段，包括指定測(cè)試需求、計(jì)劃測(cè)試、執(zhí)行測(cè)試和跟蹤缺陷。QuickTest Professional：用于創(chuàng)建功能和回歸測(cè)試。LoadRunner ：預(yù)測(cè)系統(tǒng)行為和性能的負(fù)載測(cè)試工具。二、如何發(fā)現(xiàn)客戶端軟件中的內(nèi)存泄露？ 檢測(cè)內(nèi)存泄漏的問題應(yīng)該盡早進(jìn)行，它絕不應(yīng)該是系統(tǒng)測(cè)試時(shí)的主要目標(biāo)。也就是說，檢查 是否存在內(nèi)存泄漏，應(yīng)該從編碼時(shí)就要考慮，單元測(cè)試和集成測(cè)試時(shí)

21、要重點(diǎn)檢查。如果前期 沒有考慮，等到了系統(tǒng)測(cè)試才想起檢查或者才發(fā)現(xiàn)泄漏，為時(shí)已晚，此時(shí)再去定位泄漏的位 置，太難太難了，它可能會(huì)讓你的交付日期 delay 不確定的時(shí)間。 最近看了一些自動(dòng)錯(cuò)誤 預(yù)防（AEP的理論，我深受啟發(fā)。作為測(cè)試人員的我們，從“發(fā)現(xiàn)錯(cuò)誤”轉(zhuǎn)變到“幫助開 發(fā)人員預(yù)防錯(cuò)誤”，這將是一個(gè)巨大的轉(zhuǎn)變。所以說，下面我的答案中的第一點(diǎn)，我先說如 何預(yù)防內(nèi)存泄漏的問題，然后再講如何發(fā)現(xiàn)。1 如何在開發(fā)過程中有效預(yù)防內(nèi)存泄漏？第一步：遵循“好”的編程規(guī)則“好”的編程規(guī)則是各位前輩經(jīng)驗(yàn)和教訓(xùn)的集合， 好的編程規(guī)則堪稱開發(fā)者的“圣經(jīng)”。 遵 循統(tǒng)一的編程規(guī)則， 可以讓開發(fā)新手少走好多彎路，

22、可以讓項(xiàng)目整體的質(zhì)量維持一個(gè)起碼的質(zhì)量底線” 有關(guān)內(nèi)存泄漏方面的規(guī)則主要是“內(nèi)存管理”方面的，舉幾個(gè)簡(jiǎn)單的，如下x用malloc或new申請(qǐng)內(nèi)存之后，立即檢查指針值是否為NULL（防止使用指針值為NULL的內(nèi)存）x動(dòng)態(tài)內(nèi)存的申請(qǐng)與釋放是否配對(duì)（防止內(nèi)存泄漏）x malloc 語句是否正確無誤？例如字節(jié)數(shù)是否正確？類型轉(zhuǎn)換是否正確x是否出現(xiàn)野指針，例如用free或delete釋放了內(nèi)存之后，忘記將指針設(shè)置為 NULL第二步：積極主動(dòng)檢測(cè)“內(nèi)存泄漏”嚴(yán)格遵循好的編程規(guī)則，可以讓程序員在代碼中盡量少的引入bug，但一旦不小心引入了，怎么辦？這就要求我們?cè)趩卧獪y(cè)試和集成測(cè)試中嚴(yán)格把關(guān)。在這個(gè)階段， 單

23、靠程序員或者測(cè)試員通過“代碼走查”的方式檢查內(nèi)存泄漏， 客戶的實(shí)踐和 我的經(jīng)驗(yàn)告訴我，這將是“不切實(shí)際”的，無論效率還是時(shí)間。如果能夠借助于一些專業(yè)的 工具的話，情況可能就不一樣了。如果你的程序是用 Visual C+ 開發(fā)，那么NumegaB勺BoundsChecker將是你檢測(cè)“內(nèi)存泄 漏”最好的選擇，如果是 Visual C+.NET，可以試一下 Compuware DevPartner。如果你的程序基于Unix或者Linux平臺(tái)，使用C或者C+,可以考慮一下開源的工具valgrind ， 我的朋友跟我說，它在一定程度上比 Rational 的 Purify 更出色。上面的工具都要求程序

24、能夠動(dòng)態(tài)運(yùn)行起來，而且測(cè)試用例需要你自己準(zhǔn)備。 如果你正處于單元測(cè)試或集成測(cè)試階段，程序代碼量已經(jīng)足夠大，而且還不能夠動(dòng)態(tài)運(yùn)行， 要盡早檢測(cè)代碼中的“內(nèi)存泄漏”問題， 該怎么辦？此時(shí)你可以試用一下目前最新的靜態(tài)分 析技術(shù)：x它不要求代碼能夠動(dòng)態(tài)運(yùn)行x也不需要你來編寫測(cè)試用例x只需要代碼能夠正常編譯，就可以發(fā)現(xiàn)代碼只有在執(zhí)行過程中才出現(xiàn)的錯(cuò)誤，當(dāng)然也包括內(nèi)存泄漏。這方面的工具有 Klocwork的K7，Coverity 的SQS以及C+test中的BugDetective，其中 最“物美價(jià)廉”的就是 c+test 的 BugDetective 。2 如何發(fā)現(xiàn)客戶端軟件的“內(nèi)存泄漏”？ 如果開發(fā)過

25、程中已經(jīng)按照我上面提到的去做， 相信發(fā)布后的程序存在“內(nèi)存泄漏”的可能性 幾乎為零。如果開發(fā)過程已經(jīng)到了后期，系統(tǒng)測(cè)試已經(jīng)開始做了，還要發(fā)現(xiàn)內(nèi)存泄漏，這個(gè)時(shí)候我希望 你能夠拿到源代碼。如果有源代碼，你還可以考慮 1 中的第二步，借助于專業(yè)的工具協(xié)助， 雖然可能效果不一定特別理想，但總比下面我提到的方法更好一些。當(dāng)然作為測(cè)試人員， 我當(dāng)然也理解事情總沒有想像那么完美。 我們通常會(huì)碰到“需要在系統(tǒng) 測(cè)試階段檢測(cè)是否有內(nèi)存泄漏，而且沒有源代碼”的難題。我曾經(jīng)也遇到過。記得那還是 2002年的事情了。當(dāng)時(shí)我承接的項(xiàng)目是一個(gè)電力行業(yè)的自動(dòng)化系統(tǒng)， 分為 server 端和 client 端，典型的 c/s 模式，老板要求在測(cè)試功能的同時(shí)順便檢查內(nèi)存泄漏的問題， 因?yàn)?/p>