測試工程師筆試題及答案

測試工程師筆試題及答案

一、基礎(chǔ)理論

1、軟件測試的結(jié)束標(biāo)準(zhǔn)是什么，

2、一套完整的測試應(yīng)該由哪些階段組成,分別闡述一下各個階段。

3、什么是缺陷報告，

4、缺陷報告的作用

5、缺陷報告的要點(diǎn)

6、軟件測試缺陷報告的“5C”原則

7、缺陷的二八定理

8、軟件測試的流程

9、測試計劃的目的是什么，測試計劃的內(nèi)容都包括什么，其中哪些是最重要的，

10、請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收

測試的區(qū)別與聯(lián)系。

11、Alpha測試與beta測試的區(qū)別

答案：

一、基礎(chǔ)理論

1、測試計劃中所有規(guī)定的測試內(nèi)容和回歸測試都已經(jīng)運(yùn)行完成

或根據(jù)上級主管對測試結(jié)果的意見，就可以結(jié)束本次測試

2、計劃階段、設(shè)計階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統(tǒng)

測試、回歸測試、驗收測試

一套完整的測試應(yīng)該由五個階段組成：

1）測試計劃首先，根據(jù)用戶需求報告中關(guān)于功能要求和性能指標(biāo)的規(guī)格說明

書，定義相應(yīng)的測試需求報告，即制訂黑盒測試的最高標(biāo)準(zhǔn)。以后所有的測試工作

都將圍繞著測試需求來進(jìn)行，符合測試需求的應(yīng)用程序即是合格的，反之即是不合

格的；同時，還要適當(dāng)選擇測試內(nèi)容，合理安排測試人員、測試時間及測試資源

等。

2)測試設(shè)計將測試計劃階段制訂的測試需求分解、細(xì)化為若干個可執(zhí)行的測試

過程，并為每個測試過程選擇適當(dāng)?shù)臏y試用例(測試用例選擇的好壞將直接影響測

試結(jié)果的有效性)。

3)測試開發(fā)建立可重復(fù)使用的自動測試過程。

4)測試執(zhí)行執(zhí)行測試開發(fā)階段建立的自動測試過程，并對所發(fā)現(xiàn)的缺陷進(jìn)行跟

蹤管理，測試執(zhí)行一般由單元測試、組合測試、集成測試、系統(tǒng)聯(lián)調(diào)及回歸測試等

步驟組成，測試人員應(yīng)本著科學(xué)負(fù)責(zé)的態(tài)度，一步一個腳印地進(jìn)行測試。

5)測試評估結(jié)合量化的測試覆蓋域及缺陷跟蹤報告，對于應(yīng)用軟件的質(zhì)量和開

發(fā)團(tuán)隊的工作進(jìn)度及工作效率進(jìn)行綜合評價。

3、缺陷報告是描述軟件缺陷現(xiàn)象和重現(xiàn)步驟地集合。軟件缺陷報告Software

BugReport

(SBR)或軟件問題報告SoftwareProblemReport(SPR)

4、缺陷報告是軟件測試人員的工作成果之一，體現(xiàn)軟件測試的價值

缺陷報告可以把軟件存在的缺陷準(zhǔn)確的描述出來，便于開發(fā)人員修正

缺陷報告可以反映項目/產(chǎn)品當(dāng)前的質(zhì)量狀態(tài)，便于項目整體進(jìn)度和質(zhì)量控制

軟件測試缺陷報告是軟件測試的輸出成果之一，可以衡量測試人員的工作能力5、

標(biāo)題(Title)

簡潔、準(zhǔn)確、完整、反映缺陷本質(zhì)、方便查詢

前綴+標(biāo)題正文，標(biāo)題正文采用結(jié)果和動作，或者現(xiàn)象和位置的方式表達(dá)步

驟(Steps)

可復(fù)現(xiàn)、完整、簡潔、準(zhǔn)確

按數(shù)字編號

實際結(jié)果(Actualresults)

準(zhǔn)確、詳細(xì)描述軟件的現(xiàn)象和特征

期望結(jié)果(Expectedresults)

準(zhǔn)確、豐富、有理有據(jù)

平臺(Platforms)

準(zhǔn)確

截圖(Screenshots)

準(zhǔn)確反映缺陷特征

注釋(Notes)

關(guān)于缺陷的輔助說明

6^內(nèi)容準(zhǔn)確(Correct):

每個組成部分的描述準(zhǔn)確，不會引起誤解

步驟簡潔(Concise):

只包含必不可少的信息，不包括任何多余的內(nèi)容

內(nèi)容清晰(Clear):

每個組成部分的描述清晰，易于理解

結(jié)構(gòu)完整(Complete):

包含復(fù)現(xiàn)該缺陷的完整步驟和其他本質(zhì)信息

風(fēng)格一致(Consistent):

按照一致的格式書寫全部缺陷報告

7、在分析、設(shè)計、實現(xiàn)階段的復(fù)審和測試工作能夠發(fā)現(xiàn)和避免80%的缺陷，而

系統(tǒng)測試又能找出其余缺陷中的80%,最后的筋的缺陷可能只有在用戶大范圍、長

時間使用后才會暴露出來。

8、制訂測試計劃、設(shè)計測試用例、實施測試、提交缺陷報告、測試總結(jié)。

9、測試計劃的目的:編寫軟件測試計劃的目的是指導(dǎo)測試組成員進(jìn)行工作和讓測試

組以外的項目成員了解測試工作的。

測試計劃的內(nèi)容:測試目的和測試項目簡介、測試參考文檔和測試提交文檔、

術(shù)語和定義、測試策略、確定測試內(nèi)容、資源、測試進(jìn)度、測試員的職責(zé)與任務(wù)分

配、項目通過或失敗的標(biāo)準(zhǔn)、暫停和重新啟動測試的標(biāo)準(zhǔn)、風(fēng)險和問題等。

最重要的:測試策略、確定測試內(nèi)容、資源、測試進(jìn)度、測試員的職責(zé)與任務(wù)

分配、項目通過或失敗的標(biāo)準(zhǔn)

10、黑盒測試:把測試對象當(dāng)成一個黑盒子，測試人員完全不考慮邏輯結(jié)構(gòu)和

內(nèi)部特性，只依據(jù)程式的需求說明書來檢查程式的功能是否滿足它的功能說明。

白盒測試:把測試對象當(dāng)成一個透明的盒子，允許測試人員利用程序內(nèi)部邏輯

結(jié)構(gòu)及相關(guān)信息，設(shè)計或選擇測試用例，對程式所有邏輯路徑進(jìn)行測試。

單元測試：白盒測試的一種，對軟件設(shè)計中的單元模塊進(jìn)行測試。

集成測試:在單元測試的基礎(chǔ)上，對單元模塊之間的連接和組裝w進(jìn)行測試。

系統(tǒng)測試:在所有都考慮的情況下，對系統(tǒng)進(jìn)行測試。

驗收測試:第三方進(jìn)行的確認(rèn)軟件滿足需求的測試。

一、判斷題

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（集成測試計劃在需求分

析階段末提交。（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）A（alpha測試需要用戶代表參

加

B（alpha測試不需要用戶代表參加

C（alpha測試是系統(tǒng)測試的一種

D（alpha測試是驗收測試的一種

4（測試設(shè)計員的職責(zé)有：（BC）

A（制定測試計劃

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)被基線化

三、填空題

1.軟件驗收測試包括:正式驗收測試，alpha測試，beta測試。

2.系統(tǒng)測試的策略有:功能測試，性能測試，可靠性測試，負(fù)載測試，易用性

測試，強(qiáng)度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢

復(fù)測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試，（有的可以

合在一起，分開寫只要寫出15就滿分哦）

3.設(shè)計系統(tǒng)測試計劃需要參考的項目文擋有:軟件測試計劃，軟件需求工件和

迭代計劃。

4.對面向過程的系統(tǒng)采用的集成策略有：自頂向下，自底向上兩種。

5.通過畫因果圖來寫測試用例的步驟為：

（1）分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價

類），哪些是結(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ā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤，只要是找錯誤；

階段評審目的:評審模塊階段作品的正確性可行性及完整性

同行評審人數(shù)：3-7人人員必須經(jīng)過同行評審會議的培訓(xùn)I,由SQA指導(dǎo)

階段評審人數(shù)：5人左右評審人必須是專家具有系統(tǒng)評審資格

同行評審內(nèi)容：內(nèi)容小一般文檔〈40頁，代碼＜500行

階段評審內(nèi)容：內(nèi)容多,主要看重點(diǎn)

同行評審時間:一小部分工作產(chǎn)品完成

階段評審時間:通常是設(shè)置在關(guān)鍵路徑的時間點(diǎ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.每周/每兩周的構(gòu)建過程。

8.點(diǎn)對點(diǎn)的測試過程。

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ā)接近完成時對應(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)下沒有

出現(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)行測試用例和測試規(guī)程設(shè)計；

執(zhí)行:根據(jù)前期完成的計劃、方案、用例、規(guī)程等文檔，執(zhí)行測試用例。

總結(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（程序錯誤2（程序接口錯誤3（數(shù)

據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件

C類一一般性錯誤，包括以下各種錯誤：1（操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列

名定義、含義是否一致）2（打印內(nèi)容、格式錯誤3（簡單的輸入限制未放在前臺

進(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)境下是否都可以正常使用

兼容性:杯子是否能夠容納果汁、白水、酒精、汽油等

易用性:杯子是否燙手、是否有防滑措施、是否方便飲用

用戶文檔:使用手冊是否對杯子的用法、限制、使用條件等有詳細(xì)描述

疲勞測試:將杯子盛上水（案例一）放24小時檢查泄漏時間和情況;盛上汽油（案

例二）放24小時檢查泄漏時間和情況等

壓力測試:用根針并在針上面不斷加重量，看壓強(qiáng)多大時會穿透

跌落測試：杯子加包裝（有填充物），在多高的情況摔下不破損

震動測試：杯子加包裝(有填充物)，六面震動，檢查產(chǎn)品是否能應(yīng)對惡劣的鐵路

'公路'航空運(yùn)輸

測試數(shù)據(jù)：

測試數(shù)據(jù)具體編寫此處略。其中應(yīng)用至I」:場景法、等價類劃分法、因果圖法、

錯誤推測法、邊界值法等方法

期望輸出：

該期望輸出需查閱國標(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在傳輸層，IP在網(wǎng)絡(luò)層，

TCP/IP是英文TransmissionControlProtocol/InternetProtocol的縮寫,

意思是"傳輸控制協(xié)議/網(wǎng)際協(xié)議”。TCP/IP協(xié)議組之所以流行，部分原因是因為它

可以用在各種各樣的信道和底層協(xié)議(例如T1和X.25、以太網(wǎng)以及RS-232串行接

口)之上。確切地說,TCP/IP協(xié)議是一組包括TCP協(xié)議和IP協(xié)議，UDP(User

DatagramProtocol)協(xié)議、ICMP(InternetControlMessageProtocol)協(xié)議和其

他一些協(xié)議的協(xié)議組。TCP/IP協(xié)議并不完全符合0SI的七層參考模型。傳統(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é)點(diǎn)間的數(shù)據(jù)傳送服務(wù)，如傳輸控制協(xié)議(TCP)、

用戶數(shù)據(jù)報協(xié)議(UDP)等，TCP和UDP給數(shù)據(jù)包加入傳輸數(shù)據(jù)并把它傳輸?shù)?/p>

3請問交換機(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)的，

而類在默認(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繼承

這是由于class默認(rèn)是private,struct默認(rèn)是publico

一般說來，struct和class可以換用（當(dāng)然要注意一些語法問題）。

而struct更適合看成是一個數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)體，

class更適合看成是一個對象的實現(xiàn)體，

對私有成員進(jìn)行保護(hù)，還提供與外界的接口。

從習(xí)慣上更喜歡用classo

5請講一講析構(gòu)函數(shù)和虛函數(shù)的用法和作用，

答:置于“，”是析構(gòu)函數(shù);析構(gòu)函數(shù)因使用八〃符號（邏輯非運(yùn)算符），表示它為

膩構(gòu)造函數(shù)，加上類名稱來定義。

;析構(gòu)函數(shù)也是特殊的類成員函數(shù)，它沒有返回類型，沒有參數(shù)，不能隨意調(diào)

用，也沒有重載，只有在類對象的生命期結(jié)束的時候，由系統(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ù)（方法）根本沒有必要或者無法實現(xiàn)，完全要依賴子類去實現(xiàn)的

話，可以把此函數(shù)（方法）設(shè)為virturl函數(shù)名=0

我們把這樣的函數(shù)（方法）稱為純虛函數(shù)。

如果一個類包含了純虛函數(shù)，稱此類為抽象類

6全局變量和局部變量有什么區(qū)別,實怎么實現(xiàn)的,操作系統(tǒng)和編譯器是怎么知

道的,

答:主要的區(qū)別是變量的作用范圍不同。全局變量在全局范圍內(nèi)都有效，而局

部變量只在聲明此變量的作用域內(nèi)有效。

全局變量是屬于實例的,在初始化對象的時候初始化，生命周期與該實例相

同，之所以叫全局

變量是因為該實例中的所有方法或?qū)傩远伎梢砸?；局部變量是在實例方法?nèi)

或static塊中，生命周期從調(diào)用該方法到該方法退出，并且只有該方法能夠引用

之。

全局變量和局部變量的區(qū)別是在存儲器中位置不同，具體說，全局變量存儲在

數(shù)據(jù)段中，局部變量都有可能，一般來說在堆棧段

7一些寄存器的題目，主要是尋址和內(nèi)存管理等一些知識。

答:尋址方式

表示指令中操作數(shù)所在的方法稱為尋址方式。8086/8088有七種基本的尋址方

式:立即尋找，寄存器尋址，直接尋址，寄存器間接尋址，寄存器相對尋址，基址

加變址尋址，相對基址加變址尋址。

直接尋址、寄存器間接尋址、寄存器相對尋址、基址加變址尋址和相對基址加

變址尋址，這五種尋址方式屬于存儲器尋址，用于說明操作數(shù)所在存儲單元的地

址。由于總線接口單元BIU能根據(jù)需要自動引用段寄存器得到段值，所以這五種方

式也就是確定存放操作數(shù)的存儲單元有效地址EA的方法。有效地址EA是一個16

位的無符號數(shù)，在利用這五種方法計算有效地址時，所得的結(jié)果認(rèn)為是一個無符號

數(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ù)線和地址線的分時復(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í)，分析需求點(diǎn)。

2.測試計劃階段:測試組長根據(jù)SON開始編寫《測試計劃》，其中包括人員，

軟件硬件資源，測試點(diǎn)，集成順序，進(jìn)度安排和風(fēng)險識別等內(nèi)容。

3.測試設(shè)計階段:測試方案一般由對需求很熟的高資深的測試工程師設(shè)計，測

試方案要求根據(jù)《SRS》上的每個需求點(diǎn)設(shè)計出包括需求點(diǎn)簡介，測試思路和詳細(xì)

測試方法三部分的方案?！稖y試方案》編寫完成后也需要進(jìn)行評審。

4.測試方案階段:主要是對測試用例和規(guī)程的設(shè)計。測試用例是根據(jù)《測試方

案》來編寫的，通過《測試方案》階段，測試人員對整個系統(tǒng)需求有了詳細(xì)的理

解。這時開始編寫用例才能保證用例的可執(zhí)行和對需求的覆蓋。測試用例需要包括

測試項，用例級別，預(yù)置條件，操作步驟和預(yù)期結(jié)果。其中操作步驟和預(yù)期結(jié)果需

要編寫詳細(xì)和明確。測試用例應(yīng)該覆蓋測試方案，而測試方案又覆蓋了測試需求

點(diǎn)，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。

5.測試執(zhí)行階段:執(zhí)行測試用例，及時提交有質(zhì)量的Bug和測試日報，測試報

告等相關(guān)文檔。流程：

需求分析?測試計劃?測試設(shè)計?測試環(huán)境搭建?測試執(zhí)行?測試記錄?缺陷管理？

軟件評估?RTM.

測試工具：

C/S及B/S架構(gòu)相關(guān)的軟件產(chǎn)品，那么對不同操作系統(tǒng)，如Windows系列、

unix、linux甚至蘋果OS等

測試環(huán)境都是必須的

常用的軟件測試工具分為：

開源測試管理工具：Bugfree、Bugzilla、TestLink、mantis

開源功能自動化測試工具:Watir、Selenium、MaxQ、Weblnject開源性能自動

化測試工具：Jmeter、OpcnSTA,DBMonster、TPTEST.Web

ApplicationLoadSimulator

[TestDirector]:企業(yè)級測試管理工具，也是業(yè)界第一個基于Web的測試管理

系統(tǒng)。[QualityCenter]:基于Web的測試管理工具，可以組織和管理應(yīng)用程序測

試流程的所有階段，包括指定測試需求、計劃測試、執(zhí)行測試和跟蹤缺陷。

[QuickTestProfessional]:用于創(chuàng)建功能和回歸測試。

[LoadRunncr]:預(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)該從編碼時就要考慮，單元測試和集成測試時

要重點(diǎn)檢查。如果前期沒有考慮，等到了系統(tǒng)測試才想起檢查或者才發(fā)現(xiàn)泄漏，為

時已晚，此時再去定位泄漏的位置，太難太難了，它可能會讓你的交付日期delay

不確定的時間。最近看了一些自動錯誤預(yù)防(AEP)的理論，我深受啟發(fā)。作為測試

人員的我們，從“發(fā)現(xiàn)錯誤”轉(zhuǎn)變到“幫助開發(fā)人員預(yù)防錯誤”，這將是一個巨大

的轉(zhuǎn)變。所以說，下面我的答案中的第一點(diǎn)，我先說如何預(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)存泄漏）

Xmalloc語句是否正確無誤，例如字節(jié)數(shù)是否正確,類型轉(zhuǎn)換是否正確X是否

出現(xiàn)野指針，例如用free或delete釋放了內(nèi)存之后，忘記將指針設(shè)置為

NULL.............

第二步:積極主動檢測“內(nèi)存泄漏”

嚴(yán)格遵循好的編程規(guī)則，可以讓程序員在代碼中盡量少的引入bug,但一旦不

小心引入了，怎么辦,這就要求我們在單元測試和集成測試中嚴(yán)格把關(guān)。

在這個階段，單靠程序員或者測試員通過“代碼走查”的方式檢查內(nèi)存泄漏，

客戶的實踐和我的經(jīng)驗告訴我，這將是“不切實際”的，無論效率還是時間。如果

能夠借助于一些專業(yè)的工具的話，情況可能就不一樣了。

如果你的程序是用VisualC++6.0開發(fā)，那么Numega的BoundsChecker將是

你檢測“內(nèi)存泄漏”最好的選擇，如果是VisualC++.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)按照我上面提到的去做，