軟件測試工程師筆試題以及答案匯總

1、軟件測試工程師筆試題以及答 案匯 總、判斷題1軟件測試的目的是盡可能多的找出軟件的缺陷。Y2 Beta 測試是驗收測試的一種。 Y 3驗收 測試是由最終用戶來實施的。 N 4工程立項 前測試人員不需要提交任何工件。 Y5. 單元測試能發(fā)現(xiàn)約80%的軟件缺陷。丫6.代 碼評審是檢查源代碼是否到達模塊設計的 要求。 N7. 自底向上集成需要測試員編寫驅(qū)動程序。 丫8. 負載測試是驗證要檢驗的系統(tǒng)的能力最高能 到達 什么程度。 N 9測試人員要堅持原那么，缺陷未 修復完堅決不 予通過。 N 10代碼評審員一般 由測試員擔任。 N 11我們可以人為的使得軟 件不存在配置問題。 N 12集成測試方案在需

2、 求分析階段末提交。 N1軟件驗收測試的合格通過準那么是： ABCD A .軟件需求分析說明書中定義的所有功能已全 部實 現(xiàn)，性能指標全部到達要求。B .所有測試項沒有剩余一級、二級和三級錯誤。C .立項審批表、需求分析文檔、設計文檔和編 碼實 現(xiàn)一致。D .驗收測試工件齊全。2軟件測試方案評審會需要哪些人員參加？ABCD A .工程經(jīng)理BSQA 負責人C .配置負責人D 測試組3以下關于 alpha 測試的描述中正確的選項是： AD A alpha 測試需要用戶代表參加B alpha 測試不需要用戶代表參加C alpha 測試是系統(tǒng)測試的一種 D alpha 測試 是驗收測試的一種4 .測試

3、設計員的職責有：BC A .制定測試計劃B .設計測試用例C .設計測試過程、腳本 D .評估測試活動5.軟件實施活動的進入準那么是：ABC A.需求工件已經(jīng)被基線化B .詳細設計工件已經(jīng)被基線化C 構架工件已經(jīng)被基線化D .工程階段成果已經(jīng)被基線化6、為保證測試活動的可控性，必須在軟件測試 過程 中進行軟件測試配置管理， 一般來說， 軟件 測試 配置管理中最根本的活動包括 _A A .配置項標識、配置項控制、配置狀態(tài)報告、 配置審計B .配置基線確立、配置項控制、配置報告、配置審計C .配置項標識、配置項變更、配置審計、配置 跟蹤 D .配置項標識、配置項控制、配置狀態(tài)報告、 配置 跟蹤7、

4、_B _ 方法根據(jù)輸出對輸入的依賴關系設 計測試用例。A 路徑測試B 等價類C 因果圖D .邊界值8、在C+語言中，假設類C中定義了一個方法int f(int a， int b) ，那么方法 _A_ 不能與該方 法同時存 在于類 C 中Aint f(int x ， int y)Bintf(float a ， int b)C float f(int x ， float y)D intf(int x ， float y)9 、以下關于軟件驗收測試的合格通過準那么錯誤 的是： _C A 軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標全部到達要求；B 所有測試項沒有剩余一級、二級和三級錯誤；C

5、 立項審批表、需求分析文檔、設計文檔和編 碼 實現(xiàn)不一致；D 驗收測試工件齊全三、填空題1. 軟件驗收測試包括： 正式驗收測試， alpha 測 試， beta 測試。2. 系統(tǒng)測試的策略有：功能測試，性能測試，可 靠 性測試，負載測試，易用性測試，強度測試， 平安 測試，配置測試，安裝測試，卸載測試，文 擋測試， 故障恢復測試， 界面測試， 容量測試， 兼容性測試， 分布測試，可用性測試， 有的可 以合在一起，分 開寫只要寫出 15 就總分值哦3. 設計系統(tǒng)測試方案需要參考的工程文擋有： 軟 件 測試方案，軟件需求工件和迭代方案。4. 對面向過程的系統(tǒng)采用的集成策略有： 自頂向 下， 自底向

6、上兩種。5. 通過畫因果圖來寫測試用例的步驟為： 1分 析軟件規(guī)格說明描述中， 哪些是原因即 輸入條件 或輸入條件的等價類 ，哪些是結(jié)果即 輸出條件， 并給每個原因和結(jié)果賦予一個標識 符。2分析軟件規(guī)格說明描述中的語義，找出原 因與 結(jié)果之間，原因與原因之間對應的是什么關 系?根據(jù) 這些關系，畫出因果圖。3由于語法或環(huán)境限制，有些原因與原因之 間， 原因與結(jié)果之間的組合情況不可能出現(xiàn)。 為 說明這 些特殊情況， 在因果圖上用一些記號標明 約束或限 制條件。 4 把因果圖轉(zhuǎn)換成判定表。5把判定表的每一列拿出來作為依據(jù)，設計 測試 用例。四、簡答題1. 區(qū)別階段評審的與同行評審 同行評審目的 :

7、發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤 , 只 要 是找錯誤 ;階段評審目的 : 評審模塊階段作品的正確性可行 性 及完整性同行評審人數(shù) :3-7 人人員必須經(jīng)過同行評審會 議的 培訓 ,由 SQA 指導階段評審人數(shù) :5 人左右評審人必須是專家具有 系統(tǒng) 評審資格同行評審內(nèi)容 :內(nèi)容小一般文檔 40 頁, 代碼 500 行階段評審內(nèi)容 : 內(nèi)容多, 主要看重點 同行評審時間 一小局部工作產(chǎn)品完成 階段評審時間 : 通常是設置 在關鍵路徑的時間點 上!2. 什么是軟件測試 為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程3 簡述集成測試的過程 系統(tǒng)集成測試主要包括以下過程：1. 構建確實認過程。2. 補丁確實認過程。3

8、. 系統(tǒng)集成測試測試組提交過程4. 測試用例設計過程5. 測試代碼編寫過程6. Bug 的報告過程。7. 每周 /每兩周的構建過程。8. 點對點的測試過程。9. 組內(nèi)培訓過程。4 怎么做好文檔測試 仔細閱讀，跟隨每個步驟，檢查每個圖形，嘗試 每 個例如。 P142檢查文檔的編寫是否滿足文檔編寫的目的內(nèi)容是否齊全，正確 內(nèi)容是否完善標記是否正確靜態(tài)：關5 白盒測試有幾種方法總體上分為靜態(tài)方法和動態(tài)方法兩大類鍵功能是檢查軟件的表示和描述是否一 致 , 沒有沖突或者沒有歧義 動態(tài)：語句覆蓋、判定 覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋6 系統(tǒng)測試方案是否需要同行審批，為什么 ? 需要，

9、 系統(tǒng)測試方案屬于工程階段性關鍵文檔， 因此需要 評審。7Alpha 測試與 beta 的區(qū)別？Alpha 測試在系統(tǒng)開發(fā)接近完成時對應用系統(tǒng)的 測 試；測試后仍然會有少量的設計變更。 這種測 試一 般由最終用戶或其它人員完成， 不能由程序 或測試 員完成。Beta 測試當開發(fā)和測試根本完成時所做的測試， 最 終的錯誤和問題需要在最終發(fā)行前找到。 這種 測試 一般由最終用戶或其它人員完成， 不能由程 序員或 測試員完成。8 比較負載測試，容量測試和強度測試的區(qū)別？ 負載測試： 在一定的工作負荷下， 系統(tǒng)的負荷及 響 應時間。強度測試： 在一定的負荷條件下， 在較長時間跨 度 內(nèi)的系統(tǒng)連續(xù)運行給

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

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

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

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

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

15、 五層結(jié)構是5 應用層 ;4 運輸層 ;3 網(wǎng)絡層 ; 2 鏈路層 ;1 物 理層。2 請你詳細的解釋一下 IP 協(xié)議的定義，在哪個 層上 面，主要有什么作用？ TCP 與 UDP 呢？ 答 :UDP ，TCP 在傳輸層， IP 在網(wǎng)絡層， TCP/IP 是 英 文 Transmission Control Protocol/Internet Protocol 的縮寫，意思是 傳輸控制協(xié)議 /網(wǎng)際協(xié)議 。 TCP/IP 協(xié)議組之所 以流行，局部原因是因為它 可以用在各種各樣的 信道和底層協(xié)議 ( 例如 T1 和X.25 、以太網(wǎng)以及 RS-232 串行接口 之上。確切地 說， TCP/IP 協(xié)

16、 議是一組包括 TCP 協(xié)議和 IP 協(xié)議， UDP User Datagram Protocol 協(xié) 議 、 ICMP Internet Control Message Protocol 協(xié)議和 其他一些協(xié) 議的協(xié)議組。 TCP/IP 協(xié)議并不完全符 合 OSI 的 七層參考模型。傳統(tǒng)的開放式系統(tǒng)互連參 考模 型，是一種通信協(xié)議的 7 層抽象的參考模型 , 其 中每一層執(zhí)行某一特定任務。 該模型的目的是使 各 種硬件在相同的層次上相互通信。這 7 層是 : 物理 層、數(shù)據(jù)鏈路層、 網(wǎng)路層、傳輸層、話路層、 表示 層和應用層。而 TCP/IP 通訊協(xié)議采用了 4 層的層級 結(jié)構，每一層都呼叫它

17、的下一層所提供 的網(wǎng)絡來完 成自己的需求。 這 4 層分別為：應用 層：應用程序 間溝通的層， 如簡單電子郵件傳輸 SMTP 、文 件傳輸協(xié)議FTP八網(wǎng)絡遠程訪問協(xié)議Telnet 等。 傳輸層：在此層中，它提供了節(jié)點間的數(shù)據(jù)傳 送 效勞，如傳輸控制協(xié)議 TCP 、用戶數(shù)據(jù)報協(xié) 議 UDP 等， TCP 和 UDP 給數(shù)據(jù)包參加傳輸數(shù) 據(jù) 并把它傳輸?shù)? 請問交換機和路由器分別的實現(xiàn)原理是什么？ 分 別在哪個層次上面實現(xiàn)的？一般意義上說交換機是工作在數(shù)據(jù)鏈路層。 但隨 著 科技的開展， 現(xiàn)在有了三層交換機， 三層交換 機 已經(jīng)擴展到了網(wǎng)絡層。 也就是說： 它等于“數(shù) 據(jù) 鏈路層 + 局部網(wǎng)絡層。

18、 交換機中傳的是幀。 通 過存儲轉(zhuǎn)發(fā)來實現(xiàn)的。 路由器是工作在網(wǎng)絡 層。路 由器中傳的是 IP 數(shù)據(jù)報。主要是選址和 路由。4請問C+的類和C里面的STRUCT有什么區(qū)別?答 : 除關鍵字不同外 (class,struct ) 的唯一區(qū)別是,結(jié)構在默認情況下的成員是公共 (public) 的, 而類在 默認情況下的成員是私有 (private) 的。在C+中，結(jié)構是特殊的類。class 是從 struct 開展而來的。之所以將 struct 和 class 都保存，是因為：1、提出 class 是為了強調(diào)一種概念。2、 保存 struct 是為了照顧到大多數(shù)人的習慣。struct 和 clas

19、s 是有區(qū)別的。struct 保證成員按照聲明順序在內(nèi)存中存儲。 class 不保證等等而它們都可以繼承， 實現(xiàn)多態(tài)等。 但也有少許區(qū) 別。 比方：struct A ；class B : A ; /private繼承struct C : B ； /public 繼承 這是由于 class 默認是 private ， struct 默認是 public 。一般說來， struct 和 class 可以換用當然要 注意些語法問題 而 struct 更適合看成是一個數(shù)據(jù)結(jié)構的實現(xiàn) 體， class 更適合看成是一個對象的實現(xiàn)體， 對私有成員 進行保護，還提供與外界的接口。從習慣上更喜歡用 class

20、 5 請講一講析構函數(shù)和虛函數(shù)的用法和作用？答：置于“是析構函數(shù)；析構函數(shù)因使用符 號 邏輯非運算符 ，表示它為膩構造函數(shù)， 加 上 類名稱來定義。；析構函數(shù)也是特殊的類成員函數(shù)， 它沒有返回 類 型，沒有參數(shù)，不能隨意調(diào)用，也沒有重載， 只有 在類對象的生命期結(jié)束的時候， 由系統(tǒng)自動 調(diào)用。 有適放內(nèi)存空間的做用 !虛函數(shù)是 C+ 多態(tài)的一種表現(xiàn) 例如：子類繼承了父 類的一個函數(shù)方法 ，而 我們把父類的指針指向 子類， 那么必須把父類的該 函數(shù)方法設為 virturl 虛函數(shù) 。 使用虛函數(shù)， 我們可以靈活的進行 動態(tài)綁定， 當 然是以一定的開銷為代價。如果父類的函數(shù) 方法 根本沒有必要或者

21、無法 實 現(xiàn)，完全要依賴子類去實現(xiàn)的話， 可以把此函 數(shù)方 法設為 virturl 函數(shù)名 =0 我們把這樣的函數(shù) 方法 稱為純虛函數(shù)。 如果一個類包含了純虛函數(shù)，稱此 類為抽象類6 全局變量和局部變量有什么區(qū)別？實怎么實現(xiàn) 的？ 操作系統(tǒng)和編譯器是怎么知道的？ 答 : 主要的區(qū)別是變量的作用范圍不同。全局變 量在 全局范圍內(nèi)都有效， 而局部變量只在聲明此 變量的 作用域內(nèi)有效。全局變量是屬于實例的 , 在初始化對象的時候初 始 化，生命周期與該實例相同， 之所以叫全局變 量是 因為該實例中的所有方法或?qū)傩远伎梢砸?用；局部 變量是在實例方法內(nèi)或 static 塊中， 生命周期從調(diào) 用該方法到

22、該方法退出， 并且只有 該方法能夠引用 之。全局變量和局部變量的區(qū)別是在存儲器中位置 不同， 具體說，全局變量存儲在數(shù)據(jù)段中，局部 變量都有 可能，一般來說在堆棧段7 一些存放器的題目， 主要是尋址和內(nèi)存管理等 一些 知識。答 : 尋址方式 表示指令中操作數(shù)所在的方法稱為尋 址方式。 8086/8088 有七種根本的尋址方式：立即 尋找， 存放器尋址，直接尋址，存放器間接尋址， 存放 器相對尋址， 基址加變址尋址， 相對基址加 變址 尋址。直接尋址、存放器間接尋址、存放器相對尋址、 基 址加變址尋址和相對基址加變址尋址， 這五種 尋址 方式屬于存儲器尋址， 用于說明操作數(shù)所在 存儲單 元的地址

23、。 由于總線接口單元 BIU 能根據(jù) 需要自 動引用段存放器得到段值， 所以這五種方 式也就是 確定存放操作數(shù)的存儲單元有效地址 EA 的方法。有 效地址 EA 是一個 16 位的無符號 數(shù)，在利用這五 種方法計算有效地址時， 所得的 結(jié)果認為是一個無 符號數(shù)。 除了這些根本的尋址方式外，還有固定尋址和 I/O 端口尋址等。內(nèi)存管理 主要包括內(nèi)存的分配和回收整理等， 實現(xiàn) 內(nèi)存的 高效利用。Q8:8086 是多少位的系統(tǒng)？在數(shù)據(jù)總線上是怎么 實 現(xiàn)的？答:16 位系統(tǒng) ,8 位數(shù)據(jù)傳送 ,通過總線控制邏輯 實現(xiàn) 數(shù)據(jù)線和地址線的分時復用 .8086 是 Inter 的 16 位微處理器有 16

24、 根數(shù)據(jù)線和 20 根地址線，它既能處理 16 位 數(shù)據(jù)，也能處理 8 位數(shù)據(jù) 內(nèi)部數(shù)據(jù)總線都是按 16 位 設計的，單外部數(shù)據(jù) 總線只有 8 條七、其他、談談你了解的軟件測試流程及工具般測試流程：1. 需求分析階段：對業(yè)務的學習，分析需求點。2. 測試方案階段： 測試組長根據(jù) SOW 開始編寫 ?測 試方案?，其中包括人員，軟件硬件資源， 測試點， 集成順序，進度安排和風險識別等內(nèi)容。3. 測試設計階段：測試方案一般由對需求很熟的 高 資深的測試工程師設計， 測試方案要求根據(jù) ?SRS ? 上的每個需求點設計出包括需求點簡介， 測試思路 和詳細測試方法三局部的方案。 ?測試 方案?編寫 完成

25、后也需要進行評審。4. 測試方案階段：主要是對測試用例和規(guī)程的設 計 測試用例是根據(jù)?測試方案?來編寫的，通 過?測 試方案?階段，測試人員對整個系統(tǒng)需求 有了詳細 的理解。 這時開始編寫用例才能保證用 例的可執(zhí)行 和對需求的覆蓋。 測試用例需要包括 測試項，用例 級別，預置條件，操作步驟和預期 結(jié)果。其中操作 步驟和預期結(jié)果需要編寫詳細和 明確。測試用例應 該覆蓋測試方案， 而測試方案 又覆蓋了測試需求點， 這樣才能保證客戶需求不 遺漏。同樣，測試用例也 需要評審。5. 測試執(zhí)行階段：執(zhí)行測試用例，及時提交有質(zhì)量 的 Bug 和測試日報，測試報告等相關文檔。 流程： 需求分析宀測試方案T測試

26、設計T測試環(huán)境搭建T測試執(zhí)行T測試記錄T缺陷管理T軟件評估TRTM.測試工具：C/S 及 B/S 架構相關的軟件產(chǎn)品，那么對不同操 作 系統(tǒng)，如 Windows 系列、 unix 、linux 甚至蘋果 OS 等測試環(huán)境都是必須的 常用的軟件測試工具分為： 開 源測試管理工具：Bugfree、Bugzilla、TestLink、 mantis 開源功能自動化測試工具： Watir 、Selenium 、 MaxQ、 WebInject 開源性能自動化測試工具： Jmeter 、 OpenSTA 、DBMonster 、 TPTEST 、 We ApplicationLoadSimulatorT

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

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

29、編程規(guī)那么，可以讓開發(fā)新手少走好多彎 路，可以讓 工程整體的質(zhì)量維持一個起碼的“質(zhì) 量底線。 有關內(nèi)存泄漏方面的規(guī)那么主要是“內(nèi)存管理 方面 的，舉幾個簡單的，如下x用malloc或new申請內(nèi)存之后，立即檢查指 針 值是否為NULL 防止使用指針值為NULL的內(nèi)存 x動態(tài)內(nèi)存的申請與釋放是否配對防止內(nèi)存泄 漏x malloc 語句是否正確無誤？例如字節(jié)數(shù)是否 正確？ 類型轉(zhuǎn)換是否正確x是否出現(xiàn)野指針，例如用free或delete釋放了內(nèi)存之后，忘記將指針設置為 NULL第二步：積極主動檢測“內(nèi)存泄漏 嚴格遵循好的 編程規(guī)那么， 可以讓程序員在代碼中 盡量少的引入 bug,但一旦不小心引入了，

30、怎么 辦？這就要求我們 在單元測試和集成測試中嚴 格把關。 在這個階段，單靠程序員或者測試員通過“代碼 走 查的方式檢查內(nèi)存泄漏， 客戶的實踐和我的 經(jīng)驗 告訴我， 這將是“不切實際的， 無論效率 還是 時間。如果能夠借助于一些專業(yè)的工具的 話，情況 可能就不一樣了 如果你的程序是用 Visual C+ 6.0 開發(fā)，那么 Numega 的 BoundsChecker 將是你檢測“內(nèi)存泄 漏 最好的選擇，如果是 Visual C+.NET ，可 以試一 下 Compuware 的 DevPartner 。 如果你的程序基 于 Unix 或者 Linux 平臺，使用 C 或者 C+ ，可以 考慮

31、一下開源的工具 valgrind ， 我的朋友跟我說， 它在一定程度上比 Rational 的 Purify 更出色。 上面 的工具都要求程序能夠動態(tài)運行起來， 而且 測試用 例需要你自己準備。 如果你正處于單元測試或集成 測試階段， 程序代 碼量已經(jīng)足夠大， 而且還不能 夠動態(tài)運行， 要盡 早檢測代碼中的“內(nèi)存泄漏問 題， 該怎么辦？ 此時你可以試用一下目前最新的靜 態(tài)分析技術：X它不要求代碼能夠動態(tài)運行 X也不 需要你來編寫測試用例 X只需要代碼能夠正常編譯， 就可以發(fā)現(xiàn)代碼只 有在執(zhí)行過程中才出現(xiàn)的錯誤， 當然也包括內(nèi)存 泄漏。這方面的工具有 Klocwork 的 K7， Coverity 的 SQS ， 以及 C+test 中的 BugDetective ，其中最 “物美 價廉的就是 c+test 的 BugDetective 。2 如何發(fā)現(xiàn)客戶端軟件的“內(nèi)存泄漏？ 如果開發(fā) 過程中已經(jīng)按照我上面提到的去做， 相 信發(fā)布后的 程序存在“內(nèi)存泄漏的可能性幾 乎為零。如果開發(fā)過程已經(jīng)到了后期， 系統(tǒng)測試已經(jīng)開始 做 了，還要發(fā)現(xiàn)內(nèi)存泄漏， 這個時候我希望你能 夠拿 到源代碼。如果有源代碼，你還可以考慮 1 中的第二 步， 借助于專業(yè)的工具協(xié)助， 雖然可能 效果不一 定特別理想， 但總比下面我提到的方法 更好一些。 當然作為測試人員， 我當然也理解