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

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

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

3、. 制定測試計劃B. 設(shè)計測試用例C. 設(shè)計測試過程、腳本D. 評估測試活動 5軟件實施活動的進(jìn)入準(zhǔn)則是： ( ABC)A. 需求工件已經(jīng)被基線化B. 詳細(xì)設(shè)計工件已經(jīng)被基線化C. 構(gòu)架工件已經(jīng)被基線化D. 項目階段成果已經(jīng)被基線化6、為保證測試活動的可控性，必須在軟件測試過程中進(jìn)行軟件測試配置管理，一般來說， 軟件測試配置管理中最基本的活動包括 _AA. 配置項標(biāo)識、配置項控制、配置狀態(tài)報告、配置審計B. 配置基線確立、配置項控制、配置報告、配置審計C. 配置項標(biāo)識、配置項變更、配置審計、配置跟蹤D. 配置項標(biāo)識、配置項控制、配置狀態(tài)報告、配置跟蹤7、_B方法根據(jù)輸出對輸入的依賴關(guān)系設(shè)計測試

4、用例。A 路徑測試B.等價類C 因果圖D.邊界值&在C+語言中，若類C中定義了一個方法int f(int a , int b)，那么方法 A不能與該方法同時存在于類C中A int f(int x ， int y)Bint f(float a ， int b)C float f(int x， float y)Dint f(int x， float y)9、下列關(guān)于軟件驗收測試的合格通過準(zhǔn)則錯誤的是：_CA 軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標(biāo)全部達(dá)到要求；B 所有測試項沒有殘余一級、二級和三級錯誤；C 立項審批表、需求分析文檔、設(shè)計文檔和編碼實現(xiàn)不一致；D 驗收測試工件

5、齊全三、填空題1. 軟件驗收測試包括：正式驗收測試， alpha 測試， beta 測試。2. 系統(tǒng)測試的策略有：功能測試，性能測試，可靠性測試，負(fù)載測試，易用性測試，強(qiáng)度測 試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢復(fù)測試，界面測試，容 量測試，兼容性測試，分布測試，可用性測試， (有的可以合在一起，分開寫只要寫出 15 就滿分哦)3. 設(shè)計系統(tǒng)測試計劃需要參考的項目文擋有：軟件測試計劃，軟件需求工件和迭代計劃。4. 對面向過程的系統(tǒng)采用的集成策略有：自頂向下，自底向上兩種。5. 通過畫因果圖來寫測試用例的步驟為：（1）分析軟件規(guī)格說明描述中， 哪些是原因（即輸入條件或輸入

6、條件的等價類） ，哪些是結(jié) 果（即輸出條件） ，并給每個原因和結(jié)果賦予一個標(biāo)識符。（2）分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對應(yīng)的是什么關(guān)系 ?根據(jù)這些關(guān)系，畫出因果圖。（3）由于語法或環(huán)境限制， 有些原因與原因之間， 原因與結(jié)果之間的組合情況不可能出現(xiàn)。 為表明這些特殊情況，在因果圖上用一些記號標(biāo)明約束或限制條件。（4）把因果圖轉(zhuǎn)換成判定表。（5）把判定表的每一列拿出來作為依據(jù)，設(shè)計測試用例。四、簡答題1. 區(qū)別階段評審的與同行評審?fù)性u審目的 : 發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤 , 只要是找錯誤 ; 階段評審目的 : 評審模塊階段作品的正確性可行性及完整性同行評審人數(shù)

7、：3-7人人員必須經(jīng)過同行評審會議的培訓(xùn)，由SQA旨導(dǎo)階段評審人數(shù) :5 人左右評審人必須是專家具有系統(tǒng)評審資格 同行評審內(nèi)容 ： 內(nèi)容小一般文檔 < 40 頁， 代碼< 500 行 階段評審內(nèi)容 ： 內(nèi)容多 ， 主要看重點 同行評審時間 ： 一小部分工作產(chǎn)品完成階段評審時間 ： 通常是設(shè)置在關(guān)鍵路徑的時間點上 !2. 什么是軟件測試 為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程3 簡述集成測試的過程 系統(tǒng)集成測試主要包括以下過程：1. 構(gòu)建的確認(rèn)過程。2. 補(bǔ)丁的確認(rèn)過程。3. 系統(tǒng)集成測試測試組提交過程。4. 測試用例設(shè)計過程。5. 測試代碼編寫過程。6. Bug 的報告過程。7. 每

8、周 /每兩周的構(gòu)建過程。8. 點對點的測試過程。9. 組內(nèi)培訓(xùn)過程。4 怎么做好文檔測試仔細(xì)閱讀，跟隨每個步驟，檢查每個圖形，嘗試每個示例。 P142檢查文檔的編寫是否滿足文檔編寫的目的內(nèi)容是否齊全，正確內(nèi)容是否完善標(biāo)記是否正確5 白盒測試有幾種方法總體上分為靜態(tài)方法和動態(tài)方法兩大類。靜態(tài)：關(guān)鍵功能是檢查軟件的表示和描述是否一致 , 沒有沖突或者沒有歧義動態(tài)：語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。6 系統(tǒng)測試計劃是否需要同行審批，為什么 需要，系統(tǒng)測試計劃屬于項目階段性關(guān)鍵文檔，因此需要評審。7Alpha 測試與 beta 的區(qū)別？Alpha 測試在系統(tǒng)開發(fā)接近完

9、成時對應(yīng)用系統(tǒng)的測試；測試后仍然會有少量的設(shè)計變更。這 種測試一般由最終用戶或其它人員完成，不能由程序或測試員完成。Beta 測試當(dāng)開發(fā)和測試根本完成時所做的測試， 最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。8 比較負(fù)載測試，容量測試和強(qiáng)度測試的區(qū)別？負(fù)載測試：在一定的工作負(fù)荷下，系統(tǒng)的負(fù)荷及響應(yīng)時間。強(qiáng)度測試： 在一定的負(fù)荷條件下， 在較長時間跨度內(nèi)的系統(tǒng)連續(xù)運(yùn)行給系統(tǒng)性能所造成的影 響。容量測試：容量測試目的是通過測試預(yù)先分析出反映軟件 系統(tǒng)應(yīng)用特征的某項指標(biāo)的極限 值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等） ，系統(tǒng)在其極限值狀態(tài)下沒

10、有出現(xiàn)任何軟件故障 或還能保持主要功能正常運(yùn)行。容量測試 還將確定測試對象在給定時間內(nèi)能夠持續(xù)處理的 最大負(fù)載或工作量。 容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處 理。容量測試是面向數(shù)據(jù) 的，并且它的目的是顯示系統(tǒng)可以處理目標(biāo)內(nèi)確定的數(shù)據(jù)容量。9 測試結(jié)束的標(biāo)準(zhǔn)是什么？用例全部測試。覆蓋率達(dá)到標(biāo)準(zhǔn)。缺陷率達(dá)到標(biāo)準(zhǔn)。 其他指標(biāo)達(dá)到質(zhì)量標(biāo)準(zhǔn)10 描述軟件測試活動的生命周期？測試周期分為計劃、設(shè)計、實現(xiàn)、執(zhí)行、總結(jié)。其中：計劃：對整個測試周期中所有活動進(jìn)行規(guī)劃，估計工作量、風(fēng)險，安排人力物力資源，安排 進(jìn)度等；設(shè)計：完成測試方案，從技術(shù)層面上對測試進(jìn)行規(guī)劃； 實現(xiàn)：進(jìn)行測試用例

11、和測試規(guī)程設(shè)計；執(zhí)行：根據(jù)前期完成的計劃、方案、用例、規(guī)程等文檔，執(zhí)行測試用例?？偨Y(jié)：記錄測試結(jié)果，進(jìn)行測試分析，完成測試報告。11 軟件的缺陷等級應(yīng)如何劃分？A 類嚴(yán)重錯誤，包括以下各種錯誤： 1 由于程序所引起的死機(jī) , 非法退出 2 死循環(huán) 3 數(shù)據(jù)庫發(fā)生死鎖 4 因錯誤操作導(dǎo)致的程序中斷 5 功能錯誤 6 與數(shù)據(jù)庫連接錯 誤 7 數(shù)據(jù)通訊錯誤B 類較嚴(yán)重錯誤，包括以下各種錯誤： 1 表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件程序錯誤 2 程序接口錯誤 3 數(shù)據(jù)庫的C 類一般性錯誤，包括以下各種錯誤： 1 含義是否一致） 2 打印內(nèi)容、 格式錯誤 3 操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、

12、簡單的輸入限制未放在前臺進(jìn)行控制 4 刪除操作未給出提示 5 數(shù)據(jù)庫表中有過多的空字段D 類較小錯誤，包括以下各種錯誤： 1 界面不規(guī)范 2 輔助說明描述不清楚 3 輸 入輸出不規(guī)范 4 長操作未給用戶提示 5 提示窗口文字未采用行業(yè)術(shù)語 6 可輸入?yún)^(qū) 域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志E類一測試建議五、用例設(shè)計隨意選取一個簡單物品，假定是一個喝水的帶廣告圖案的花紙杯，設(shè)計出盡可能多的測試用例測試項目：杯子需求測試:查看杯子使用說明書界面測試:查看杯子外觀功能度：用水杯裝水看漏不漏；水能不能被喝到安全性：杯子有沒有毒或細(xì)菌可*性杯子從不同高度落下的損壞程度可移植性：杯子再不同的地方、溫度等環(huán)境下是

13、否都可以正常使用 兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等 易用性：杯子是否燙手、是否有防滑措施、是否方便飲用 用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細(xì)描述 疲勞測試：將杯子盛上水（案例一）放 24 小時檢查泄漏時間和情況；盛上汽油（案例二）放 24 小 時 檢 查 泄 漏 時 間 和 情 況 等 壓力測試：用根針并在針上面不斷加重量，看壓強(qiáng)多大時會穿透 跌 落 測試 : 杯 子 加 包裝 （ 有 填充 物）, 在 多 高 的 情況 摔 下 不 破 損震動測試 :運(yùn)杯子加包裝 （ 有填充物 ）, 六面震動 , 檢查產(chǎn)品是否能應(yīng)對惡劣的鐵路公路 航空輸測試數(shù)據(jù)：測試數(shù)據(jù)

14、具體編寫此處略。其中應(yīng)用到：場景法、等價類劃分法、因果圖法、錯誤推測法、邊界值法等方法期望輸出：該期望輸出需查閱國標(biāo)、行標(biāo)以及使用用戶的需求說明書測試:檢查說明書書寫準(zhǔn)確性六、網(wǎng)絡(luò)、操作系統(tǒng)、語言知識1 請你分別劃劃 OSI 的七層網(wǎng)絡(luò)結(jié)構(gòu)圖，和 TCP/IP 的五層結(jié)構(gòu)圖？ 答:七層結(jié)構(gòu)從上到下依次是：7 應(yīng)用層 ;6 表示層 ;5 會話層 ;4 傳輸層 ;3 網(wǎng)絡(luò)層 ;2 數(shù)據(jù)鏈路層 ;1 物理層 五層結(jié)構(gòu)是5 應(yīng)用層 ;4 運(yùn)輸層 ;3 網(wǎng)絡(luò)層 ; 2 鏈路層 ;1 物理層。2請你詳細(xì)的解釋一下IP協(xié)議的定義，在哪個層上面，主要有什么作用？TCP與UDP呢？答 :UDP ， TCP 在

15、傳 輸 層 ， IP 在 網(wǎng) 絡(luò) 層 ，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é)議是一組包括 TCP協(xié)議和 IP 協(xié)議，UDRUser Datagram Protocol )協(xié)議、ICMP(Internet Control Message Protocol )協(xié)議和其他一些協(xié)議的協(xié)議組。 TCP/IP

16、協(xié)議并不完全符合 OSI 的七層參考模型。 傳統(tǒng)的開放式系統(tǒng)互連參考模型， 是一種通信協(xié)議的 7 層抽象的參考模型 , 其中每一層執(zhí)行某一特定任務(wù)。該模型的目的是使各種硬件在相同的層次上相互通信。這7層是 : 物理層、數(shù)據(jù)鏈路層、網(wǎng)路層、傳輸層、話路層、表示層和應(yīng)用層。而TCP/IP 通訊協(xié)議采用了 4 層的層級結(jié)構(gòu)，每一層都呼叫它的下一層所提供的網(wǎng)絡(luò)來完成自己的需求。這4層分別為：應(yīng)用層：應(yīng)用程序間溝通的層，如簡單電子郵件傳輸(SMTP、文件傳輸協(xié)議(FTP)、 網(wǎng) 絡(luò) 遠(yuǎn) 程 訪 問 協(xié) 議 ( Telnet ) 等 。 傳輸層：在此層中，它提供了節(jié)點間的數(shù)據(jù)傳送服務(wù)，如傳輸控制協(xié)議(TC

17、P、用戶數(shù)據(jù)報協(xié)議(UDP等，TCP和 UDP合數(shù)據(jù)包加入傳輸數(shù)據(jù)并把它傳輸?shù)? 請問交換機(jī)和路由器分別的實現(xiàn)原理是什么？分別在哪個層次上面實現(xiàn)的？一般意義上說交換機(jī)是工作在數(shù)據(jù)鏈路層。 但隨著科技的發(fā)展， 現(xiàn)在有了三層交換機(jī)， 三層 交換機(jī)已經(jīng)擴(kuò)展到了網(wǎng)絡(luò)層。也就是說：它等于“數(shù)據(jù)鏈路層+ 部分網(wǎng)絡(luò)層”。交換機(jī)中傳的是幀。通過存儲轉(zhuǎn)發(fā)來實現(xiàn)的。 路由器是工作在網(wǎng)絡(luò)層。路由器中傳的是 IP 數(shù)據(jù)報。 主要是選址和路由。4請問C+啲類和C里面的STRUCT有什么區(qū)別?答:除關(guān) 鍵 字 不 同 外 (class,struct)的唯一區(qū)別是,結(jié)構(gòu)在默 認(rèn) 情 況 下 的 成 員是公共(public)

18、的,而類在默 認(rèn) 情 況 下 的 成 員是私有(private)的。在C+中,結(jié)構(gòu)是特殊的類。class是從struct 發(fā) 展 而 來 的 。 之 所 以 將 struct和 class都保留，是因為：1、提出class是為了強(qiáng)調(diào)一種概念。2、保留 struct是 為 了 照 顧 到大多數(shù)人的習(xí)慣。struct和class是有區(qū)別的。struct保證成員按照聲明順序在內(nèi)存中存儲。 class 不 保 證 等 等而它們都可 以 繼 承 ， 實 現(xiàn) 多 態(tài) 等 。 但也有少許區(qū)別。比如：structA；classB: A;/private繼承structC: B ；/public繼承這 是 由于

19、 class默 認(rèn)是 private，struct默認(rèn)是public一般說來， struct和 class可 以 換用 ( 當(dāng)然要注意一些語法問題)而 struct更適合看成是一個數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)體class更適合看成是一個對象的實現(xiàn)體對私有成員進(jìn)行保護(hù) ， 還 提供與外界的接口從習(xí)慣上更喜歡用 class 。5 請講一講析構(gòu)函數(shù)和虛函數(shù)的用法和作用？答：置于“”是析構(gòu)函數(shù)；析構(gòu)函數(shù)因使用""符號（邏輯非運(yùn)算符），表示它為膩構(gòu)造函數(shù), 加上類名稱來定義；析構(gòu)函數(shù)也是特殊的類成員函數(shù)，它沒有返回類型，沒有參數(shù)，不能隨意調(diào)用，也沒有重載，有只有在類對象的生命期結(jié)束的時候， 間由系

20、統(tǒng)自動調(diào)用。用!適放內(nèi)存空的做虛函數(shù)是C+多態(tài)的一種表現(xiàn)例如：子類繼承了父類的一個函數(shù)（方法） ，而我們把父類的指針指向子類，則必須把父類 的 該 函 數(shù) （ 方 法 ） 設(shè) 為 virturl （ 虛 函 數(shù) ）。使 用虛函 數(shù) ， 我們可以靈活的進(jìn)行動態(tài)綁定， 當(dāng)然是以一定的開銷為 代價。如果父類的函數(shù) （方法）此函數(shù)（我們把這樣=0根本沒有必要或者無法實現(xiàn)，完全要依賴子類去實現(xiàn)的話，可以把 方 法 ） 設(shè) 為 virturl函 數(shù) 名的 函 數(shù) （ 方 法 ） 稱 為 純 虛 函 數(shù) 如果一個類包含了純虛函數(shù)，稱此類為抽象類6 全局變量和局部變量有什么區(qū)別？實怎么實現(xiàn)的？操作系統(tǒng)和編譯器

21、是怎么知道的？ 答： 主要的區(qū)別是變量的作用范圍不同。全局變量在全局范圍內(nèi)都有效，而局部變量只在聲明 此 變 量 的 作 用 域 內(nèi) 有 效 。 全局變量是屬于實例的 , 在初始化對象的時候初始化，生命周期與該實例相同，之所以叫全 局變量是因為該實例中的所有方法或?qū)傩远伎梢砸?；局部變量是在實例方法?nèi)或static塊中， 生命周期從調(diào)用 該方法到該方法退出， 并且只有該方法能夠引用 之。 全局變量和局部變量的區(qū)別是在存儲器中位置不同，具體說， 全局變量存儲在數(shù)據(jù)段中， 局部變量都有可能，一般來說在堆棧段7 一些寄存器的題目，主要是尋址和內(nèi)存管理等一些知識。答：尋址方式表示指令中操作數(shù)所在的方法

22、稱為尋址方式。 8086/8088 有七種基本的尋址方式： 立即尋找， 寄存器尋址，直接尋址，寄存器間接尋址，寄存器相對尋址，基址加變址尋址，相對基址加 變址尋址。 直接尋址、 寄存器間接尋址、寄存器相對尋址、基址加變址尋址和相對基址加變址尋址，這 五種尋址方式屬于存儲器尋址，用于說明操作數(shù)所在存儲單元的地址。由于總線接口單元BIU 能根據(jù)需要自動引用段寄存器得到段值， 所以這五種方式也就是確定存放操作數(shù)的存儲單元有效地址EA的方法。有效地址EA是一個 16 位的無符號數(shù)，在利用這五種方法計算有效地址時 ， 所 得 的結(jié)果認(rèn)為是一個無符號數(shù)。除了這些基 本 的 尋 址 方 式外，還有固定尋址和

23、 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ù)線和地址線的分時復(fù)用 . 8086 是 Inter 的 16 位 微 處 理 器 有 16 根 數(shù) 據(jù) 線 和 20 根 地 址 線 ， 它 既 能 處 理 16 位 數(shù) 據(jù) ， 也 能 處 理 8 位 數(shù) 據(jù) 內(nèi)部數(shù)據(jù)總線都是按 16 位設(shè)計的，單外部數(shù)據(jù)總線只有 8 條七、其他一、談?wù)勀懔私獾能浖y試流程及工具一般測試流程：1. 需求分析階段：對業(yè)務(wù)的學(xué)習(xí)，分析需求點。2. 測

24、試計劃階段：測試組長根據(jù)SOW干始編寫測試計劃，其中包括人員，軟件硬件資源，測試點，集成順序，進(jìn)度安排和風(fēng)險識別等內(nèi)容。3. 測試設(shè)計階段： 測試方案一般由對需求很熟的高資深的測試工程師設(shè)計，測試方案要求根據(jù)SRS上的每個需求點設(shè)計出包括需求點簡介，測試思路和詳細(xì)測試方法三部分的方案。測試方案編寫完成后也需要進(jìn)行評審。4. 測試方案階段： 主要是對測試用例和規(guī)程的設(shè)計。 測試用例是根據(jù) 測試方案 來編寫的，通過測試方案階段，測試人員對整個系統(tǒng)需求有了詳細(xì)的理解。這時開始編寫用例才能保證用例的可執(zhí)行和對需求的覆蓋。 測試用例需要包括測試項，用例級別， 預(yù)置條件， 操作 步驟和預(yù)期結(jié)果。 其中操作

25、步驟和預(yù)期結(jié)果需要編寫詳細(xì)和明確。測試用例應(yīng)該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。5. 測試執(zhí)行階段： 執(zhí)行測試用例， 及時提交有質(zhì)量的 Bug 和測試日報， 測試報告等相關(guān)文檔。 流程：需求分析t測試計劃t測試設(shè)計t測試環(huán)境搭建t測試執(zhí)行t測試記錄t缺陷管理t軟件 評估t RTM.測試工具：C/S 及 B/S 架構(gòu)相關(guān)的軟件產(chǎn)品，那么對不同操作系統(tǒng)，如Windows 系列、 unix 、 linux 甚至蘋果OS等測試環(huán)境都是必須的常用的軟件測試工具分為：開源測試管理工具：Bugfree 、 Bugzilla 、 TestLink

26、 、 mantis開源功能自動化測試工具：Watir 、 Selenium 、 MaxQ、 WebInject開 源 性 能 自 動 化 測 試 工 具 ： Jmeter 、 OpenSTA、 DBMonster 、 TPTEST、 Web ApplicationLoadSimulatorTestDirector:企業(yè)級測試管理工具，也是業(yè)界第一個基于Web的測試管理系統(tǒng)。Quality Center：基于Web的測試管理工具，可以組織和管理應(yīng)用程序測試流程的所有階 段，包括指定測試需求、計劃測試、執(zhí)行測試和跟蹤缺陷。QuickTest Professional ：用于創(chuàng)建功能和回歸測試。Lo

27、adRunner ：預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。、如何發(fā)現(xiàn)客戶端軟件中的內(nèi)存泄露？ 檢測內(nèi)存泄漏的問題應(yīng)該盡早進(jìn)行， 它絕不應(yīng)該是系統(tǒng)測試時的主要目標(biāo)。 也就是說， 檢查 是否存在內(nèi)存泄漏， 應(yīng)該從編碼時就要考慮， 單元測試和集成測試時要重點檢查。 如果前期 沒有考慮， 等到了系統(tǒng)測試才想起檢查或者才發(fā)現(xiàn)泄漏， 為時已晚， 此時再去定位泄漏的位 置，太難太難了，它可能會讓你的交付日期 delay 不確定的時間。 最近看了一些自動錯誤 預(yù)防（AEP的理論，我深受啟發(fā)。作為測試人員的我們，從“發(fā)現(xiàn)錯誤”轉(zhuǎn)變到“幫助開 發(fā)人員預(yù)防錯誤”， 這將是一個巨大的轉(zhuǎn)變。 所以說，下面我的答案中的第一點

28、， 我先說如 何預(yù)防內(nèi)存泄漏的問題，然后再講如何發(fā)現(xiàn)。1 如何在開發(fā)過程中有效預(yù)防內(nèi)存泄漏？ 第一步：遵循“好”的編程規(guī)則“好”的編程規(guī)則是各位前輩經(jīng)驗和教訓(xùn)的集合， 好的編程規(guī)則堪稱開發(fā)者的“圣經(jīng)”。 遵 循統(tǒng)一的編程規(guī)則， 可以讓開發(fā)新手少走好多彎路， 可以讓項目整體的質(zhì)量維持一個起碼的“質(zhì)量底線”。有關(guān)內(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是否

29、出現(xiàn)野指針，例如用free或delete釋放了內(nèi)存之后，忘記將指針設(shè)置為NULL第二步：積極主動檢測“內(nèi)存泄漏”嚴(yán)格遵循好的編程規(guī)則，可以讓程序員在代碼中盡量少的引入bug，但一旦不小心引入了，怎么辦？這就要求我們在單元測試和集成測試中嚴(yán)格把關(guān)。在這個階段， 單靠程序員或者測試員通過“代碼走查”的方式檢查內(nèi)存泄漏，客戶的實踐和我的經(jīng)驗告訴我， 這將是“不切實際”的， 無論效率還是時間。 如果能夠借助于一些專業(yè)的 工具的話，情況可能就不一樣了。如果你的程序是用 Visual C+ 6.0開發(fā)，那么 Numega的BoundsChecker將是你檢測“內(nèi)存 泄漏”最好的選擇，如果是 Visual

30、C+.NET，可以試一下 Compuware的DevPartner。如果你的程序基于 Unix或者Linux平臺，使用 C或者C+，可以考慮一下開源的工具 valgrind ，我的朋友跟我說，它在一定程度上比 Rational 的 Purify 更出色。上面的工具都要求程序能夠動態(tài)運(yùn)行起來，而且測試用例需要你自己準(zhǔn)備。 如果你正處于單元測試或集成測試階段，程序代碼量已經(jīng)足夠大，而且還不能夠動態(tài)運(yùn)行， 要盡早檢測代碼中的“內(nèi)存泄漏”問題， 該怎么辦？此時你可以試用一下目前最新的靜態(tài)分 析技術(shù)：X它不要求代碼能夠動態(tài)運(yùn)行X也不需要你來編寫測試用例X只需要代碼能夠正常編譯，就可以發(fā)現(xiàn)代碼只有在執(zhí)行過程中才出現(xiàn)的錯誤，當(dāng)然也包括內(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é)助， 雖然可能效果不一定特別理想，但總比下面我提到