網(wǎng)站測試面試題

網(wǎng)站測試面試題

網(wǎng)站測試面試題2016-07-22瀏覽：分享人：馬星舒手機(jī)版

參考答案：

兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺

上是否可以正常的運(yùn)行，即是通常說的軟件的可移植性。

兼容的類型，如果細(xì)分的話，有平臺的兼容，網(wǎng)絡(luò)兼容，

數(shù)據(jù)庫兼容，以及數(shù)據(jù)格式的兼容。

兼容測試的重點(diǎn)是，對兼容環(huán)境的分析。通常，是在運(yùn)

行軟件的環(huán)境不是很確定的情況下，才需要做兼容。根據(jù)軟

件運(yùn)行的需要，或者根據(jù)需求文檔，一般都能夠得出用戶會

在什么環(huán)境下使用該軟件，把這些環(huán)境整理成表單，就得出

做兼容測試的兼容環(huán)境了。

兼容和配置測試的區(qū)別在于，做配置測試通常不是

CleanOS下做測試，而兼容測試多是在CleanOS的環(huán)境下

做的。

參考答案：

1、檢查系統(tǒng)是否有中毒的特征；

2、檢查軟件/硬件的配置是否符合軟件的推薦標(biāo)準(zhǔn)；

3、確認(rèn)當(dāng)前的系統(tǒng)是否是獨(dú)立，即沒有對外提供什么

消耗CPU資源的服務(wù)；

4、如果是C/S或者B/S結(jié)構(gòu)的軟件，需要檢查是不是

因?yàn)榕c服務(wù)器的連接有問題，或者訪問有問題造成的；

5、在系統(tǒng)沒有任何負(fù)載的情況下，查看性能監(jiān)視器，

確認(rèn)應(yīng)用程序?qū)PU/內(nèi)存的訪問情況。

參考答案：

黑盒/白盒，靜態(tài)/動態(tài)，手工/自動，冒煙測試，回歸

測試，公測（Beta測試的策略）

參考答案：

用最少的實(shí)驗(yàn)覆蓋最多的操作，測試用例設(shè)計(jì)很少，效

率高，但是很復(fù)雜；

對于基本的驗(yàn)證功能，以及二次集成引起的缺陷，一般

都能找出來；但是更深的缺陷，更復(fù)雜的缺陷，還是無能為

力的；

具體的環(huán)境下，正交表一般都很難做的。大多數(shù)，只在

系統(tǒng)測試的時(shí)候使用此方法。

參考答案：

就是Bugzilla的狀態(tài)轉(zhuǎn)換圖。

參考答案：

界面不穩(wěn)定；

根據(jù)需要配置它的不同的部分，過程很煩瑣。

流程控制上，安全性不好界定，很容易對他人的Bug進(jìn)

行誤操作；

沒有綜合的評分指標(biāo)，不好確認(rèn)修復(fù)的優(yōu)先級別。

參考答案：

需求分析+需求變更的維護(hù)工作；

根據(jù)需求得出測試需求；

設(shè)計(jì)測試方案，評審測試方案；

方案評審?fù)ㄟ^后，設(shè)計(jì)測試用例，再對測試用例進(jìn)行評

審；

參考答案：

邏輯覆蓋、循環(huán)覆蓋、同行評審、桌前檢查、代碼走查、

代碼評審、景泰數(shù)據(jù)流分析

參考答案：

用戶動作設(shè)計(jì)；

場景設(shè)計(jì)；

測試數(shù)據(jù)分析；

參考答案：

1、測試測試

2、創(chuàng)建虛擬用戶腳本

3、創(chuàng)建運(yùn)行場景

4、運(yùn)行測試腳本

5、監(jiān)視場景

6、分析測試的結(jié)果

以上，最好是結(jié)合一個(gè)案例，根據(jù)以上流程來介紹。

參考答案：

在同一時(shí)間點(diǎn)，支持多個(gè)不同的操作。

LoadRunner中提供IP偽裝，集合點(diǎn)，配合虛擬用戶的

設(shè)計(jì)，以及在多臺電腦上設(shè)置，可以比較好的模擬真實(shí)的并

發(fā)。

集合點(diǎn)，即是多個(gè)用戶在某個(gè)時(shí)刻，某個(gè)特定的環(huán)境下

同時(shí)進(jìn)行虛擬用戶的操作的。集合點(diǎn)失敗，則集合點(diǎn)的才操

作就會取消，測試就不能進(jìn)行。

參考答案：

分析用戶登錄的基本情況，得出一組數(shù)據(jù)，通過性測試

/失敗性測試的都有（根據(jù)TC來設(shè)計(jì)這些數(shù)據(jù)），然后錄制登

錄的腳本，將關(guān)鍵的數(shù)據(jù)參數(shù)化，修改腳本，對代碼進(jìn)行加

強(qiáng)，調(diào)試腳本。

參考答案：

Action的作用

n用Action可以對步驟集進(jìn)行分組

n步驟重組，然后被整體調(diào)用

n擁有自己的sheet

n組合有相同需求的步驟，整體操作

n具有獨(dú)立的對象倉庫

Action的種類

n可復(fù)用Action

n不可復(fù)用Action

n外部Action

參考答案：

需求管理

n定義測試范圍

n定義需求樹

n描述需求樹的功能點(diǎn)

測試計(jì)劃

n定義測試目標(biāo)和測試策略。

n分解應(yīng)用程序，建立測試計(jì)劃樹。

n確定每個(gè)功能點(diǎn)的測試方法。

n將每個(gè)功能點(diǎn)連接到需求上，使測試計(jì)劃覆蓋全部的

測試需求。

n描述手工測試的測試步驟

n指明需要進(jìn)行自動測試的功能點(diǎn)

測試執(zhí)行

n定義測試集合。

n為每個(gè)測試人員制定測試任務(wù)和測試日程安排。

n運(yùn)行自動測試。

缺陷跟蹤

n記錄缺陷

n查看新增缺陷，并確定哪些是需要修正的

n相關(guān)技術(shù)人員修改缺陷

n回歸測試

n分析缺陷統(tǒng)計(jì)圖表，分析應(yīng)用程序的開發(fā)質(zhì)量。

參考答案：CompatibilityTesting（兼容性測試）,也

稱^Configurationtesting（配置測試）”,測試軟件是否和

系統(tǒng)的其它與之交互的元素之間兼容，如：瀏覽器、操作系

統(tǒng)、硬件等。驗(yàn)證測試對象在不同的軟件和硬件配置中的運(yùn)

行情況。

Functionaltesting（功能測試）,也稱為behavioral

testing（行為測試），根據(jù)產(chǎn)品特征、操作描述和用戶方案，

測試一個(gè)產(chǎn)品的特性和可操作行為以確定它們滿足設(shè)計(jì)需

求。本地化軟件的功能測試，用于驗(yàn)證應(yīng)用程序或網(wǎng)站對目

標(biāo)用戶能正確工作。使用適當(dāng)?shù)钠脚_、瀏覽器和測試腳本,

以保證目標(biāo)用戶的體驗(yàn)將足夠好，就像應(yīng)用程序是專門為該

市場開發(fā)的一樣。

Performancetesting（性能測試），評價(jià)一個(gè)產(chǎn)品或組

件與性能需求是否符合的測試。包括負(fù)載測試、強(qiáng)度測試、

數(shù)據(jù)庫容量測試、基準(zhǔn)測試等類型。

參考答案：5c標(biāo)準(zhǔn)

參考答案：Betatesting（B測試），測試是軟件的多個(gè)

用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。開發(fā)

者通常不在測試現(xiàn)場

Alphatesting（a測試），是由一個(gè)用戶在開發(fā)環(huán)境下

進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境

下進(jìn)行的受控測試

參考答案：

在正式的會議上將軟件項(xiàng)目的成果（包括各階段的文檔、

產(chǎn)生的代碼等）提交給用戶、客戶或有關(guān)部門人員對軟件產(chǎn)

品進(jìn)行評審和批準(zhǔn)。其目的是找出可能影響軟件產(chǎn)品質(zhì)量、

開發(fā)過程、維護(hù)工作的適用性和環(huán)境方面的設(shè)計(jì)缺陷，并采

取補(bǔ)救措施，以及找出在性能、安全性和經(jīng)濟(jì)方面的可能的

改進(jìn)。

人員：用戶、客戶或有關(guān)部門開發(fā)人員，測試人員，需

求分析師都可以，就看處于評審那個(gè)階段

參考答案：

測試需求分析發(fā)現(xiàn)需求文檔不完善或者不準(zhǔn)確，應(yīng)該立

即和相關(guān)人員進(jìn)行協(xié)調(diào)交流。

參考答案：

階段評審對項(xiàng)目各階段評審：對階段成果和工作

項(xiàng)目評審對項(xiàng)目總體評審：對工作和產(chǎn)品

參考答案：

構(gòu)造號：BUILD

參考答案：

樁模塊：被測模塊調(diào)用模塊

驅(qū)動模塊調(diào)用被測模塊

參考答案：

扇入：被調(diào)次數(shù)，扇出：調(diào)其它模塊數(shù)目

參考答案：

軟件測試計(jì)劃就是在軟件測試工作正式實(shí)施之前明確

測試的對象，并且通過對資源、時(shí)間、風(fēng)險(xiǎn)、測試范圍和預(yù)

算等方面的綜合分析和規(guī)劃，保證有效的實(shí)施軟件測試；

1.明確測試的目標(biāo)，增強(qiáng)測試計(jì)劃的實(shí)用性

編寫軟件測試計(jì)劃得重要目的就是使測試過程能夠發(fā)

現(xiàn)更多的軟件缺陷，因此軟件測試計(jì)劃的價(jià)值取決于它對幫

助管理測試項(xiàng)目，并且找出軟件潛在的缺陷。因此，軟件測

試計(jì)劃中的測試范圍必須高度覆蓋功能需求，測試方法必須

切實(shí)可行，測試工具并且具有較高的實(shí)用性，便于使用，生

成的測試結(jié)果直觀、準(zhǔn)確

2.堅(jiān)持“5W”規(guī)則，明確內(nèi)容與過程

“5W”規(guī)則指的是“What(做什么)"、“Why(為什么做)”

“When(何時(shí)做)”、“Where(在哪里)"、“How(如何做)利

用“5W”規(guī)則創(chuàng)建軟件測試計(jì)劃，可以幫助測試團(tuán)隊(duì)理解測

試的目的(Why),明確測試的范圍和內(nèi)容(What),確定測試

的開始和結(jié)束日期(When),指出測試的方法和工具(How),

給出測試文檔和軟件的存放位置(Where)。

3.采用評審和更新機(jī)制，保證測試計(jì)劃滿足實(shí)際需求

測試計(jì)劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給

測試團(tuán)隊(duì)，測試計(jì)劃內(nèi)容的可能不準(zhǔn)確或遺漏測試內(nèi)容，或

者軟件需求變更引起測試范圍的增減，而測試計(jì)劃的內(nèi)容沒

有及時(shí)更新，誤導(dǎo)測試執(zhí)行人員。

4.分別創(chuàng)建測試計(jì)劃與測試詳細(xì)規(guī)格、測試用例

應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包含到獨(dú)立創(chuàng)建的測試詳細(xì)

規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí)行測試過程的測試用例放

到獨(dú)立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試

計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，

測試計(jì)劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配

置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。

參考答案：

需求和設(shè)計(jì)文檔的理解程度，對系統(tǒng)的熟悉程度

參考答案：提交-＞確認(rèn)-＞分配-＞修復(fù)-＞驗(yàn)證-＞關(guān)閉

參考答案：

(1)用戶認(rèn)證機(jī)制：如數(shù)據(jù)證書、智能卡、雙重認(rèn)證、

安全電子交易協(xié)議

(2)加密機(jī)制

(3)安全防護(hù)策略：如安全日志、入侵檢測、隔離防護(hù)、

漏洞掃描

(4)數(shù)據(jù)備份與恢復(fù)手段：存儲設(shè)備、存儲優(yōu)化、存儲

保護(hù)、存儲管理

(5)防病毒系統(tǒng)

參考答案：

軟件配置管理貫穿于軟件開發(fā)、測試活動的始終，覆蓋

了開發(fā)、測試活動的各個(gè)環(huán)節(jié)，它的重要作用之一就是要全

面的管理保存各個(gè)配置項(xiàng)，監(jiān)控各配置項(xiàng)的狀態(tài)，并向項(xiàng)目

經(jīng)理及相關(guān)的人員報(bào)告，從而實(shí)現(xiàn)對軟件過程的控制。

軟件測試配置管理包括4個(gè)最基本的活動：

配置項(xiàng)標(biāo)識

配置項(xiàng)控制

配置項(xiàng)狀態(tài)報(bào)告

配置審計(jì)

軟件配置管理通常借助工具來輔助，主要有MS

SourceSafe>RationalClearCase等

參考答案：

缺陷密度值達(dá)到客戶的要求

參考答案：風(fēng)險(xiǎn)分析，進(jìn)度控制、角色分配、質(zhì)量控制

參考答案：測試計(jì)劃、測試設(shè)計(jì)與開發(fā)、測試實(shí)施、測

試評審與測試結(jié)論

參考答案：

模塊接口測試、局部數(shù)據(jù)結(jié)構(gòu)測試、路徑測試、錯誤處

理測試、邊界測試

參考答案：

(1)在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接口的數(shù)

據(jù)是否會丟失；

(2)一個(gè)模塊的功能是否會對另一個(gè)模塊的功能產(chǎn)生不

利的影響；

(3)各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能;

(4)全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；

(5)單個(gè)模塊的誤差累積起來，是否會放大，從而達(dá)到

不能接受的程度。

參考答案：

(1)集成測試的主要依據(jù)概要設(shè)計(jì)說明書，系統(tǒng)測試的

主要依據(jù)是需求設(shè)計(jì)說明書；

(2)集成測試是系統(tǒng)模塊的測試，系統(tǒng)測試是對整個(gè)系

統(tǒng)的測試，包括相關(guān)的軟硬件平臺、網(wǎng)絡(luò)以及相關(guān)外設(shè)的測

試。

參考答案：

用戶手冊

安裝和設(shè)置指導(dǎo)

聯(lián)機(jī)幫助

指南、向?qū)?/p>

樣例、示例和模板

授權(quán)/注冊登記表

最終用戶許可協(xié)議

參考答案：

開發(fā)文檔

軟件需求說明書

數(shù)據(jù)庫設(shè)計(jì)說明書

概要設(shè)計(jì)說明書

詳細(xì)設(shè)計(jì)說明書

可行性研究報(bào)告

管理文檔

項(xiàng)目開發(fā)計(jì)劃

測試計(jì)劃

測試報(bào)告

開發(fā)進(jìn)度月報(bào)

開發(fā)總結(jié)報(bào)告

參考答案：

(1)讀者群。文檔面向的讀者定位要明確。對于初級用

戶、中級用戶以及高級用戶應(yīng)該有不同的定位

(2)術(shù)語。文檔中用到的術(shù)語要適用與定位的讀者群，

用法一致，標(biāo)準(zhǔn)定義與業(yè)界規(guī)范相吻合。

(3)正確性。測試中需檢查所有信息是否真實(shí)正確，查

找由于過期產(chǎn)品說明書和銷售人員夸大事實(shí)而導(dǎo)致的錯誤。

檢查所有的目錄、索引和章節(jié)引用是否已更新，嘗試鏈接是

否準(zhǔn)確，產(chǎn)品支持電話、地址和郵政編碼是否正確。

⑷完整性。對照軟件界面檢查是否有重要的分支沒有

描述到，甚至是否有整個(gè)大模塊沒有描述到。

(5)一致性。按照文檔描述的操作執(zhí)行后，檢查軟件返

回的結(jié)果是否與文檔描述的相同。

(6)易用性。對關(guān)鍵步驟以粗體或背景色給用戶以提示,

合理的頁面布局、適量的圖表都可以給用戶更高的易用性。

需要注意的是文檔要有助于用戶排除錯誤。不但描述正確操

作，也要描述錯誤處理辦法。文檔對于用戶看到的錯誤信息

應(yīng)當(dāng)有更詳細(xì)的文檔解釋。

(7)圖表與界面截圖。檢查所有圖表與界面截圖是否與

發(fā)行版本相同。

(8)樣例與示例。像用戶一樣載入和使用樣例。如果是

一段程序，就輸入數(shù)據(jù)并執(zhí)行它。以每一個(gè)模塊制作文件,

確認(rèn)它們的正確性。

(9)語言。不出現(xiàn)錯別字，不要出現(xiàn)有二義性的說法。

特別要注意的是屏幕截圖或繪制圖形中的文字。

(10)印刷與包裝。檢查印刷質(zhì)量；手冊厚度與開本是否

合適；包裝盒的大小是否合適；有沒有零碎易丟失的小部件

等等。

參考答案：

單元測試大多數(shù)由開發(fā)人員來完成，測試人員技術(shù)背景

較好或者開發(fā)系統(tǒng)軟件時(shí)可能會安排測試人員進(jìn)行單元測

試，大多數(shù)進(jìn)行的單元測試都是開發(fā)人員調(diào)試程序或者開發(fā)

組系統(tǒng)聯(lián)合調(diào)試的過程。討論這個(gè)問題主要是擴(kuò)充一下讀者

的視野。

單元測試一般包括五個(gè)方面的測試：

(1)模塊接口測試：模塊接口測試是單元測試的基礎(chǔ)。

只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有

意義。模塊接口測試也是集成測試的重點(diǎn)，這里進(jìn)行的測試

主要是為后面打好基礎(chǔ)。測試接口正確與否應(yīng)該考慮下列因

素：

-輸入的實(shí)際參數(shù)與形式參數(shù)的個(gè)數(shù)是否相同；

-輸入的實(shí)際參數(shù)與形式參數(shù)的屬性是否匹配；

-輸入的實(shí)際參數(shù)與形式參數(shù)的量綱是否一致；

-調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的個(gè)數(shù)是否與被調(diào)模塊

的形參個(gè)數(shù)相同；

-調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的屬性是否與被調(diào)模塊

的形參屬性匹配；

-調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的量綱是否與被調(diào)模塊

的形參量綱一致；

-調(diào)用預(yù)定義函數(shù)時(shí)所用參數(shù)的個(gè)數(shù)、屬性和次序是否

正確；

-是否存在與當(dāng)前入口點(diǎn)無關(guān)的參數(shù)引用;

-是否修改了只讀型參數(shù)；

-對全程變量的定義各模塊是否一致；

-是否把某些約束作為參數(shù)傳遞。

如果模塊功能包括外部輸入輸出，還應(yīng)該考慮下列因素:

-文件屬性是否正確；

-OPEN/CLOSE語句是否正確；

-格式說明與輸入輸出語句是否匹配；

-緩沖區(qū)大小與記錄長度是否匹配；

-文件使用前是否已經(jīng)打開；

-是否處理了文件尾；

-是否處理了輸入/輸出錯誤；

-輸出信息中是否有文字性錯誤。

-局部數(shù)據(jù)結(jié)構(gòu)測試；

-邊界條件測試；

-模塊中所有獨(dú)立執(zhí)行通路測試；

(2)局部數(shù)據(jù)結(jié)構(gòu)測試：檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證

臨時(shí)存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過程中完整、正確，局

部功能是整個(gè)功能運(yùn)行的基礎(chǔ)。重點(diǎn)是一些函數(shù)是否正確執(zhí)

行，內(nèi)部是否運(yùn)行正確。局部數(shù)據(jù)結(jié)構(gòu)往往是錯誤的根源，

應(yīng)仔細(xì)設(shè)計(jì)測試用例，力求發(fā)現(xiàn)下面幾類錯誤：

-不合適或不相容的類型說明；

-變量無初值；

-變量初始化或省缺值有錯；

-不正確的變量名(拼錯或不正確地截?cái)?；

-出現(xiàn)上溢、下溢和地址異常。

(3)邊界條件測試：邊界條件測試是單元測試中最重要

的一項(xiàng)任務(wù)。眾所周知，軟件經(jīng)常在邊界上失效，采用邊界

值分析技術(shù)，針對邊界值及其左、右設(shè)計(jì)測試用例，很有可

能發(fā)現(xiàn)新的錯誤。邊界條件測試是一項(xiàng)基礎(chǔ)測試，也是后面

系統(tǒng)測試中的功能測試的重點(diǎn)，邊界測試執(zhí)行的較好，可以

大大提高程序健壯性。

(4)模塊中所有獨(dú)立路徑測試：在模塊中應(yīng)對每一條獨(dú)

立執(zhí)行路徑進(jìn)行測試，單元測試的基本任務(wù)是保證模塊中每

條語句至少執(zhí)行一次。測試目的主要是為了發(fā)現(xiàn)因錯誤計(jì)算、

不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e誤。具體做法就是

程序員逐條調(diào)試語句。常見的錯誤包括：

-誤解或用錯了算符優(yōu)先級；

-混合類型運(yùn)算；

-變量初值錯；

-精度不夠；

-表達(dá)式符號錯。

比較判斷與控制流常常緊密相關(guān)，測試時(shí)注意下列錯誤:

-不同數(shù)據(jù)類型的對象之間進(jìn)行比較；

-錯誤地使用邏輯運(yùn)算符或優(yōu)先級；

-因計(jì)算機(jī)表示的局限性，期望理論上相等而實(shí)際上不

相等的兩個(gè)量相等;

-比較運(yùn)算或變量出錯；

-循環(huán)終止條件或不可能出現(xiàn)；

-迭代發(fā)散時(shí)不能退出；

-錯誤地修改了循環(huán)變量。

模塊的各條錯誤處理通路測試：程序在遇到異常情況時(shí)

不應(yīng)該退出，好的程序應(yīng)能預(yù)見各種出錯條件，并預(yù)設(shè)各種

出錯處理通路。如果用戶不按照正常操作，程序就退出或者

停止工作，實(shí)際上也是一種缺陷，因此單元測試要測試各種

錯誤處理路徑。一般這種測試著重檢查下列問題：

-輸出的出錯信息難以理解；

-記錄的錯誤與實(shí)際遇到的錯誤不相符；

-在程序自定義的出錯處理段運(yùn)行之前，系統(tǒng)已介入；

-異常處理不當(dāng)；

-錯誤陳述中未能提供足夠的定位出錯信息。

參考答案：

強(qiáng)度測試是為了確定系統(tǒng)在最差工作環(huán)境的工作能力，

也可能是用于驗(yàn)證在標(biāo)準(zhǔn)工作壓力下的各種資源的最下限

指標(biāo)。

它和壓力測試的目標(biāo)是不同的，壓力測試是在標(biāo)準(zhǔn)工作

環(huán)境下，不斷增加系統(tǒng)負(fù)荷，最終測試出該系統(tǒng)能力達(dá)到的

最大負(fù)荷（穩(wěn)定和峰值），而強(qiáng)度測試則是在非標(biāo)準(zhǔn)工作環(huán)境

下，甚至不斷人為降低系統(tǒng)工作環(huán)境所需要的資源，如網(wǎng)絡(luò)

帶寬，系統(tǒng)內(nèi)存，數(shù)據(jù)鎖等等，以測試系統(tǒng)在資源不足的情況

下的工作狀態(tài)，通過強(qiáng)度測試，可以確定本系統(tǒng)正常工作的

最差環(huán)境.

強(qiáng)度測試和壓力測試的測試指標(biāo)相近，大多都是與時(shí)間

相關(guān)的指標(biāo)，如并發(fā)量（吞吐量），延遲（最大'最小'平均）以

及順序指標(biāo)等

強(qiáng)度測試需要對系統(tǒng)的結(jié)構(gòu)熟悉，針對系統(tǒng)的特征設(shè)計(jì)

強(qiáng)度測試的方法

參考答案：

性能測試是一個(gè)較大的范圍，實(shí)際上性能測試本身包含

了性能、強(qiáng)度、壓力、負(fù)載等多方面的測試內(nèi)容。

壓力測試是對服務(wù)器的穩(wěn)定性以及負(fù)載能力等方面的

測試，是一種很平常的測試。增大訪問系統(tǒng)的用戶數(shù)量、或

者幾個(gè)用戶進(jìn)行大數(shù)據(jù)量操作都是壓力測試。而負(fù)載測試是

壓力相對較大的測試，主要是測試系統(tǒng)在一種或者集中極限

條件下的相應(yīng)能力，是性能測試的重要部分。100個(gè)用戶對

系統(tǒng)進(jìn)行連續(xù)半個(gè)小時(shí)的訪問可以看作壓力測試，那么連續(xù)

訪問8個(gè)小時(shí)就可以認(rèn)為負(fù)載測試，1000個(gè)用戶連續(xù)訪問系

統(tǒng)1個(gè)小時(shí)也可以看作是負(fù)載測試。

實(shí)際上壓力測試和負(fù)載測試沒有明顯的區(qū)分。測試人員

應(yīng)該站在關(guān)注整體性能的高度上來對系統(tǒng)進(jìn)行測試。

參考答案:

瓶頸主要是指整個(gè)軟硬件構(gòu)成的軟件系統(tǒng)某一方面或

者幾個(gè)方面能力不能滿足用戶的特定業(yè)務(wù)要求，“特定”是

指瓶頸會在某些條件下會出現(xiàn)，因?yàn)楫吘勾蠖鄶?shù)系統(tǒng)在投入

前。

嚴(yán)格的從技術(shù)角度講，所有的系統(tǒng)都會有瓶頸，因?yàn)榇?/p>

多數(shù)系統(tǒng)的資源配置不是協(xié)調(diào)的，例如CPU使用率剛好達(dá)到

100%時(shí)，內(nèi)存也正好耗盡的系統(tǒng)不是很多見。因此我們討論

系統(tǒng)瓶頸要從應(yīng)用的角度討論：關(guān)鍵是看系統(tǒng)能否滿足用戶

需求。在用戶極限使用系統(tǒng)的情況下，系統(tǒng)的響應(yīng)仍然正常，

我們可以認(rèn)為改系統(tǒng)沒有瓶頸或者瓶頸不會影響用戶工作。

因此我們測試系統(tǒng)瓶頸主要是實(shí)現(xiàn)下面兩個(gè)目的：

-發(fā)現(xiàn)“表面”的瓶頸。主要是模擬用戶的操作，找出

用戶極限使用系統(tǒng)時(shí)的瓶頸，然后解決瓶頸，這是性能測試

的基本目標(biāo)。

-發(fā)現(xiàn)潛在的瓶頸并解決，保證系統(tǒng)的長期穩(wěn)定性。主

要是考慮用戶在將來擴(kuò)展系統(tǒng)或者業(yè)務(wù)發(fā)生變化時(shí)，系統(tǒng)能

夠適應(yīng)變化。滿足用戶目前需求的系統(tǒng)不是最好的，我們設(shè)

計(jì)系統(tǒng)的目標(biāo)是在保證系統(tǒng)整個(gè)軟件生命周期能夠不斷適

應(yīng)用戶的變化，或者通過簡單擴(kuò)展系統(tǒng)就可以適應(yīng)新的變化。

參考答案：

在國內(nèi)軟件開發(fā)管理中，文檔管理幾乎是最弱的一項(xiàng),

因而在測試工作中特別容易忽略文檔測試也就不足為奇了。

要想給用戶提供完整的產(chǎn)品，文檔測試是必不可少的。文檔

測試一般注重下面幾個(gè)方面：

文檔的完整性：主要是測試文檔內(nèi)容的全面性與完整性,

從總體上把握文檔的質(zhì)量。例如用戶手冊應(yīng)該包括軟件的所

有功能模塊。

描述與軟件實(shí)際情況的一致性：主要測試軟件文檔與軟

件實(shí)際的一致程度。例如用戶手冊基本完整后，我們還要注

意用戶手冊與實(shí)際功能描述是否一致。因?yàn)槲臋n往往跟不上

軟件版本的更新速度。

易理解性：主要是檢查文檔對關(guān)鍵、重要的操作有無圖

文說明，文字、圖表是否易于理解。對于關(guān)鍵、重要的操作

僅僅只有文字說明肯定是不夠的，應(yīng)該附有圖表使說明更為

直觀和明了。

文檔中提供操作的實(shí)例：這項(xiàng)檢查內(nèi)容主要針對用戶手

冊。對主要功能和關(guān)鍵操作提供的應(yīng)用實(shí)例是否豐富，提供

的實(shí)例描述是否詳細(xì)。只有簡單的圖文說明，而無實(shí)例的用

戶手冊看起來就像是軟件界面的簡單拷貝，對于用戶來說，

實(shí)際上沒有什么幫助。

印刷與包裝質(zhì)量：主要是檢查軟件文檔的商品化程度。

有些用戶手冊是簡單打印、裝訂而成，過于粗糙，不易于用

戶保存。優(yōu)秀的文檔例如用戶手冊和技術(shù)白皮書，應(yīng)提供商

品化包裝，并且印刷精美。

參考答案：

這個(gè)問題也是測試工程師經(jīng)常問的問題。有人主張測試

用例詳細(xì)到每個(gè)步驟執(zhí)行什么都要寫出來，目的是即使一個(gè)

不了解系統(tǒng)的新手都可以按照測試用例來執(zhí)行工作。主張這

類寫法的人還可以舉出例子：歐美、日本等軟件外包文檔都

是這樣做的。

另外一種觀點(diǎn)就是主張寫的粗些，類似于編寫測試大綱。

主張這種觀點(diǎn)的人是因?yàn)檐浖_發(fā)需求管理不規(guī)范，變動十

分頻繁，因而不能按照歐美的高標(biāo)準(zhǔn)來編寫測試用例。這樣

的測試用例容易維護(hù)，可以讓測試執(zhí)行人員有更大的發(fā)揮空

間。

實(shí)際上，軟件測試用例的詳細(xì)程度首先要以覆蓋到測試

點(diǎn)為基本要求。舉個(gè)例子：”用戶登陸系統(tǒng)”的測試用例可

以不寫出具體的執(zhí)行數(shù)據(jù)，但是至少要寫出五種以上情況()，

如果只用一句話覆蓋了這個(gè)功能是不合格的測試用例。覆蓋

功能點(diǎn)不是指列出功能點(diǎn)，而是要寫出功能點(diǎn)的各個(gè)方面

(如果組合情況較多時(shí)可以采用等價(jià)劃分)。

另一個(gè)影響測試用例的就是組織的開發(fā)能力和測試對

象特點(diǎn)。如果開發(fā)力量比較落后，編寫較詳細(xì)的測試用例是

不現(xiàn)實(shí)的，因?yàn)楦緵]有那么大的資源投入，當(dāng)然這種情況

很隨著團(tuán)隊(duì)的發(fā)展而逐漸有所改善。測試對象特點(diǎn)重點(diǎn)是指

測試對象在進(jìn)度、成本等方面的要求，如果進(jìn)度較緊張的情

況下，是根本沒有時(shí)間寫出高質(zhì)量的測試用例的，甚至有些

時(shí)候測試工作只是一種輔助工作，因而不編寫測試用例。

因此，測試用例的編寫要根據(jù)測試對象特點(diǎn)、團(tuán)隊(duì)的執(zhí)

行能力等各個(gè)方面綜合起來決定編寫策略。最后要注意的是

測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平

的同時(shí)，不斷地提高自身能力。

參考答案：

配置測試的目的是保證軟件在其相關(guān)的硬件上能夠正

常運(yùn)行，而兼容性測試主要是測試軟件能否與不同的軟件正

確協(xié)作。

配置測試的核心內(nèi)容就是使用各種硬件來測試軟件的

運(yùn)行情況，一般包括：

(1)軟件在不同的主機(jī)上的運(yùn)行情況，例如Dell和Apple；

(2)軟件在不同的組件上的運(yùn)行情況，例如開發(fā)的撥號

程序要測試在不同廠商生產(chǎn)的Modem上的運(yùn)行情況；

(3)不同的外設(shè)；

⑷不同的接口；

(5)不同的可選項(xiàng)，例如不同的內(nèi)存大?。?/p>

兼容性測試的核心內(nèi)容：

(1)測試軟件是否能在不同的操作系統(tǒng)平臺上兼容；

(2)測試軟件是否能在同一操作系統(tǒng)平臺的不同版本上

兼容;

(3)軟件本身能否向前或者向后兼容；

(4)測試軟件能否與其它相關(guān)的軟件兼容；

(5)數(shù)據(jù)兼容性測試，主要是指數(shù)據(jù)能否共享；

配置和兼容性測試通稱對開發(fā)系統(tǒng)類軟件比較重要，例

如驅(qū)動程序、操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)等。具體進(jìn)行時(shí)仍

然按照測試用例來執(zhí)行。

45、軟件文檔測試主要包含什么？

參考答案：

隨著軟件文檔系統(tǒng)日益龐大，文檔測試已經(jīng)成為軟件測

試的重要內(nèi)容。文檔測試對象主要如下：

-包裝文字和圖形；

-市場宣傳材料、廣告以及其它插頁；

-授權(quán)、注冊登記表；

-最終用戶許可協(xié)議；

-安裝和設(shè)置向?qū)В?/p>

-用戶手冊；

-聯(lián)機(jī)幫助；

-樣例、示范例子和模板；

文檔測試的目的是提高易用性和可靠性，降低支持費(fèi)用,

因?yàn)橛脩敉ㄟ^文檔就可以自己解決問題。因文檔測試的檢查

內(nèi)容主要如下：

-讀者對象一一主要是文檔的內(nèi)容是否能讓該級別的讀

者理解；

-術(shù)語一一主要是檢查術(shù)語是否適合讀者；

-內(nèi)容和主題一一檢查主題是否合適、是否丟失、格式

是否規(guī)范等；

-圖標(biāo)和屏幕抓圖——檢查圖表的準(zhǔn)確度和精確度；

-樣例和示例一一是否與軟件功能一致；

-拼寫和語法；

-文檔的關(guān)聯(lián)性一一是否與其它相關(guān)文檔的內(nèi)容一致，

例如與廣告信息是否一致；

文檔測試是相當(dāng)重要的一項(xiàng)測試工作，不但要給予充分

的重視，更要要認(rèn)真的完成，象做功能測試一樣來對待文檔

測試。

參考答案：

這個(gè)問題是國內(nèi)測試工程師經(jīng)常遇到的問題，根源就是

國內(nèi)軟件開發(fā)文檔管理不規(guī)范，對變更的管理方法就更不合

理了。實(shí)際上沒有任何文檔的時(shí)候，測試人員是能夠進(jìn)行黑

盒測試的，這種測試方式我們可以稱之為探索測試，具體做

法就是測試工程師根據(jù)自己的專業(yè)技能、領(lǐng)域知識等不斷的

深入了解測試對象、理解軟件功能，進(jìn)而發(fā)現(xiàn)缺陷。

在這種做法基本上把軟件當(dāng)成了產(chǎn)品說明書，測試過程

中要和開發(fā)人員不斷的進(jìn)行交流。尤其在作項(xiàng)目的時(shí)候，進(jìn)

度壓力比較大，可以作為加急測試方案。最大的風(fēng)險(xiǎn)是不知

道有些特性是否被遺漏。

參考答案：

"殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟件

測試技術(shù)》第二版中提出。用于描述測試人員對同一測試對

象進(jìn)行的測試次數(shù)越多，發(fā)現(xiàn)的缺陷就會越來越少的現(xiàn)象。

就像老用一種農(nóng)藥，害蟲就會有免疫力，農(nóng)藥發(fā)揮不了效力。

這種現(xiàn)象的根本原因就是測試人員對測試軟件過于熟悉，形

成思維定勢。

為了克服這種現(xiàn)象，測試人員需要不斷編寫新的測試程

序或者測試用例，對程序的不同部分進(jìn)行測試，以發(fā)現(xiàn)更多

的缺陷。也可以引用新人來測試軟件，剛剛進(jìn)來的新手往往

能發(fā)現(xiàn)一些意想不到的問題。

參考答案：

在進(jìn)行配置測試時(shí)，測試工程師仍然會發(fā)現(xiàn)一些普通的

缺陷，也就是與配置環(huán)境無關(guān)的缺陷。因此判斷新發(fā)現(xiàn)的問

題，需要在不同的配置中重新執(zhí)行發(fā)現(xiàn)軟件缺陷的步驟，如

果軟件缺陷不出現(xiàn)了，就可能是配置缺陷；如果在所有的配

置中都出現(xiàn)，就可能是普通缺陷。

需要注意的是，配置問題可以在一大類配置中出現(xiàn)。例

如，撥號程序可能在所有的外置Modem中都存在問題，而內(nèi)

置的Modem不會有任何問題。

參考答案：

表面上看這體現(xiàn)了管理的效率和靈活性，但實(shí)際上也體

現(xiàn)了管理者對測試的輕視。測試和測試的人有很大關(guān)系。測

試工作人員應(yīng)該是勤奮并富有耐心，善于學(xué)習(xí)、思考和發(fā)現(xiàn)

問題，細(xì)心有條理，總結(jié)問題，如果具備這樣的優(yōu)點(diǎn)，做其

它工作同樣也會很出色，因此這里還有一個(gè)要求，就是要喜

歡測試這項(xiàng)工作。如果他是專職的，那么肯定更有經(jīng)驗(yàn)和信

心。國內(nèi)的小伙子好象都喜歡做程序員，兩者工作性質(zhì)不同，

待遇不同，地位不同，對自我實(shí)現(xiàn)的價(jià)值的認(rèn)識也不同，這

是行業(yè)的一個(gè)需要改善的問題。如果只是為了完成任務(wù)而完

成任務(wù)，或者發(fā)現(xiàn)了幾個(gè)問題就覺得滿意了，這在任何其它

工作中都是不行的。

參考答案：

軟件測試初學(xué)者可能認(rèn)為拿到軟件后需要進(jìn)行完全測

試，找到全部的軟件缺陷，使軟件“零缺陷”發(fā)布。實(shí)際上

完全測試是不可能的。主要有以下一個(gè)原因：

-完全測試比較耗時(shí)，時(shí)間上不允許；

-完全測試通常意味著較多資源投入，這在現(xiàn)實(shí)中往往

是行不通的；

-輸入量太大，不能一一進(jìn)行測試；

-輸出結(jié)果太多，只能分類進(jìn)行驗(yàn)證；

-軟件實(shí)現(xiàn)途徑太多；

-軟件產(chǎn)品說明書沒有客觀標(biāo)準(zhǔn)，從不同的角度看，軟

件缺陷的標(biāo)準(zhǔn)不同；

因此測試的程度要根據(jù)實(shí)際情況確定。

參考答案：

我們沒有對軟件進(jìn)行完全測試，實(shí)際就是選擇了風(fēng)險(xiǎn),

因?yàn)槿毕輼O有可能存在沒有進(jìn)行測試的部分。舉個(gè)例子，程

序員為了方便，在調(diào)試程序時(shí)會彈出一些提示信息框，而這

些提示只在某種條件下會彈出，碰巧程序發(fā)布前這些代碼中

的一些沒有被注釋掉。在測試時(shí)測試工程師又沒有對其進(jìn)行

測試。如果客戶碰到它，這將是代價(jià)昂貴的缺陷，因?yàn)榻桓?/p>

后才被客戶發(fā)現(xiàn)。

因此，我們要盡可能的選擇最合適的測試量，把風(fēng)險(xiǎn)降

低到最小。

參考答案：

這是一個(gè)比較常見的現(xiàn)象。測試工程師在沒有找到缺陷

前會絞盡腦汁的思考，但是找到一個(gè)后，會接二連三的發(fā)現(xiàn)

很多缺陷，頗有個(gè)人成就感。其中的原因主要如下：

-代碼復(fù)用、拷貝代碼導(dǎo)致程序員容易犯相同的錯誤。

類的繼承導(dǎo)致所有的子類會包含基類的錯誤，反復(fù)拷貝同一

代碼意味可能也復(fù)制了缺陷。

-程序員比較勞累是可以導(dǎo)致某些連續(xù)編寫的功能缺陷

較多。程序員加班是一種司空見慣的現(xiàn)象，因此體力不只時(shí)

容易編寫一些缺陷較多的程序。而這些連續(xù)潛伏缺陷恰恰時(shí)

測試工程師大顯身手的地方。

“缺陷一個(gè)連著一個(gè)”不是一個(gè)客觀規(guī)律，只是一個(gè)常

見的現(xiàn)象。如果軟件編寫的比較好，這種現(xiàn)象就不常見了。

測試人員只要嚴(yán)肅認(rèn)真的測試程序就可以了。

參考答案：

從技術(shù)上講，所有的軟件缺陷都是能夠修復(fù)的，但是沒

有必要修復(fù)所有的軟件缺陷。測試人員要做的是能夠正確判

斷什么時(shí)候不能追求軟件的完美。對于整個(gè)項(xiàng)目團(tuán)隊(duì)，要做

的是對每一個(gè)軟件缺陷進(jìn)行取舍，根據(jù)風(fēng)險(xiǎn)決定那些缺陷要

修復(fù)。發(fā)生這種現(xiàn)象的主要原因如下：

-沒有足夠的時(shí)間資源。在任何一個(gè)項(xiàng)目中，通常情況

下開發(fā)人員和測試人員都是不夠用的，而且在項(xiàng)目中沒有預(yù)

算足夠的回歸測試時(shí)間，再加上修改缺陷可能引入新的缺陷,

因此在交付期限的強(qiáng)大壓力下，必須放棄某些缺陷的修改。

-有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商業(yè)利

益考慮，可以在以后升級中進(jìn)行修復(fù)。

-不是缺陷的缺陷。我們經(jīng)常會碰到某些功能方面的問

題被當(dāng)成缺陷來處理，這類問題可以以后有時(shí)間時(shí)考慮再處

理。

最后要說的是，缺陷是否修改要由軟件測試人員、項(xiàng)目

經(jīng)理、程序員共同討論來決定是否修復(fù)，不同角色的人員從

不同的角度來思考，以做出正確的決定。

參考答案：

軟件測試人員的職責(zé)是盡可能早的找出軟件缺陷，確保

得以修復(fù)。而質(zhì)量保證人員（QA）主要職責(zé)是創(chuàng)建或者制定標(biāo)

準(zhǔn)和方法，提高促進(jìn)軟件開發(fā)能力和減少軟件缺陷。測試人

員的主要工作是測試，質(zhì)量保證人員日常工作重要內(nèi)容是檢

查與評審，測試工作也是測試保證人員的工作對象。

軟件測試和質(zhì)量是相輔相成的關(guān)系，都是為了提高軟件

質(zhì)量而工作。

參考答案：

在IT行業(yè)里跳槽已經(jīng)是一種司空見慣的現(xiàn)象，而且跳

槽無論給公司還是給個(gè)人都會帶來一定的損失。測試隊(duì)伍也

無疑會面臨跳槽的威脅，作為測試經(jīng)理管理者，只有從日常

工作中開始做起，最能最大限度的減少損失。建議我們從以

下兩個(gè)方面做起：

-加強(qiáng)部門內(nèi)員工之間的互相學(xué)習(xí)，互相學(xué)習(xí)是建立學(xué)

習(xí)型組織的基本要求，是知識互相轉(zhuǎn)移的過程。在此基礎(chǔ)上,

可以把個(gè)人擁有的技術(shù)以知識的形式沉積下來，也就完成了

隱性知識到顯性知識的轉(zhuǎn)化。

-通常情況下，企業(yè)能為員工提供足夠大的發(fā)展空間時(shí),

如果不是待遇特別低，員工都不會主動離開企業(yè)。因此我們

要想留住員工，管理者就應(yīng)該把員工的個(gè)人成長和企業(yè)的發(fā)

展聯(lián)系起來，為員工設(shè)定合理發(fā)展規(guī)劃并付諸實(shí)現(xiàn)。不過這

項(xiàng)要求做起來比較，要有比較好的企業(yè)文化為依托。

參考答案：

習(xí)慣上把開發(fā)完成后進(jìn)行商業(yè)化、幾乎不進(jìn)行代碼修改

就可以售給用戶使用的軟件成為軟件產(chǎn)品，也就是可以買

“賣拷貝”的軟件，例如Windows2000o而通常把針對一個(gè)

或者幾個(gè)特定的用戶而開發(fā)的軟件成為軟件項(xiàng)目，軟件項(xiàng)目

是一種個(gè)性化的產(chǎn)品，可以是按照用戶要求全部重新開發(fā),

也可以修改已有的軟件產(chǎn)品來滿足特定的用戶需求。項(xiàng)目和

產(chǎn)品的不同特點(diǎn)，決定我們測試產(chǎn)品和測試項(xiàng)目仍然會有很

多不同的地方：

-質(zhì)量要求不同。通常產(chǎn)品的質(zhì)量要高一些，修復(fù)發(fā)布

后產(chǎn)品的缺陷成本較高，甚至?xí)砗芏嘭?fù)面的影響。而做

項(xiàng)目通常面向某一用戶，雖然質(zhì)量越高越好，但是一般只要

滿足用戶要求就可以了。

-測試資源投入多少不同。做軟件產(chǎn)品通常是研發(fā)中心

來開發(fā)，進(jìn)度壓力要小些。同時(shí)由于質(zhì)量要求高，因此會投

入較多的人力、物力資源。

-項(xiàng)目最后要和用戶共同驗(yàn)收測試，這是產(chǎn)品測試不具

有的特點(diǎn)。

此外，測試產(chǎn)品與測試項(xiàng)目在缺陷管理方面、測試策略

制定都會有很大不同，測試管理者應(yīng)該結(jié)合具體的環(huán)境，恰

如其分的完成工作。

參考答案：

軟件產(chǎn)品在投產(chǎn)前，通常都會進(jìn)行用戶驗(yàn)收測試。如果

用戶驗(yàn)收測試沒有通過，直接結(jié)果就是那不到“Money“，間

接影響是損害了公司的形象，而后者的影響往往更嚴(yán)重。根

據(jù)作者的經(jīng)驗(yàn)，用戶驗(yàn)收測試一定要讓用戶滿意。

實(shí)際上用戶現(xiàn)場測試更趨于是一種演示。在不欺騙用戶

的前提下，我們向用戶展示我們軟件的優(yōu)點(diǎn)，最后讓“上帝”

滿意并欣然掏出“銀子”才是我們的目標(biāo)。因此用戶測試要

注意下面的事項(xiàng)：

(1)用戶現(xiàn)場測試不可能測試全部功能，因此要測試核

心功能。這需要提前做好準(zhǔn)備，這些核心功能一定要預(yù)先經(jīng)

過測試，證明沒有問題才可以和用戶共同進(jìn)行測試。測試核

心模塊的目的是建立用戶對軟件的信心。當(dāng)然如果這些模塊

如果問題較多，不應(yīng)該進(jìn)行演示。

(2)如果某些模塊確實(shí)有問題，我們可以演示其它重要

的業(yè)務(wù)功能模塊，必要時(shí)要向用戶做成合理的解釋。爭得時(shí)

間后，及時(shí)修改缺陷來彌補(bǔ)。

(3)永遠(yuǎn)不能欺騙用戶，蒙混過關(guān)。道理很簡單，因?yàn)?/p>

軟件是要給用戶用的，問題早晚會暴露出來，除非你可以馬

上修改。

和用戶進(jìn)行測試還要注意各種交流技巧，爭取不但短期

利益得到了滿足，還要為后面得合作打好基礎(chǔ)。

參考答案：

隨著測試工作越來越受重視，開發(fā)團(tuán)隊(duì)向客戶提供測試

文檔是不可避免的事情。很多人會問：“我們可以把工作中

的測試報(bào)告提供給客戶嗎？”答案是否定的。因?yàn)樘峁﹥?nèi)部

測試報(bào)告，可能會讓客戶失去信心，甚至否定項(xiàng)目。

測試報(bào)告一般分為內(nèi)部測試報(bào)告和外部測試報(bào)告。內(nèi)部

報(bào)告是我們在測試工作中的項(xiàng)目文檔，反映了測試工作的實(shí)

施情況，這里不過多討論，讀者可以參考相關(guān)教材。這里主

要討論一下外部測試報(bào)告的寫法，一般外部測試報(bào)告要滿足

下面幾個(gè)要求：

-根據(jù)內(nèi)部測試報(bào)告進(jìn)行編寫，一般可以摘錄；

-不可以向客戶報(bào)告嚴(yán)重缺陷，即使是已經(jīng)修改的缺陷,

開發(fā)中的缺陷也沒有必要讓客戶知道；

-報(bào)告上可以列出一些缺陷，但必須是中級的缺陷，而

且這些缺陷必須是修復(fù)的；

-報(bào)告上面的內(nèi)容盡量要真實(shí)可靠；

-整個(gè)測試報(bào)告要仔細(xì)審閱，力爭不給項(xiàng)目帶來負(fù)面作

用，尤其是性能測試報(bào)告。

總之，外部測試報(bào)告要小心謹(jǐn)慎的編寫。

參考答案：

國內(nèi)的很多測試工程師對測試工具相當(dāng)迷戀，尤其是一

些新手，甚至期望測試工具可以取代手工測試。測試工具在

測試工作中起的是輔助作用，一般用來提高測試效率。自動

化測試彌補(bǔ)了手工測試的不足，減輕一定的工作量。實(shí)際上

測試工具是無法替代大多數(shù)手工測試的，而一些諸如性能測

試等自動化測試也是手工所不能完成的。

對于自動測試技術(shù)，應(yīng)當(dāng)依據(jù)軟件的不同情況來分別對

待，一般自動技術(shù)會應(yīng)用在引起大量重復(fù)性工作的地方、系

統(tǒng)的壓力點(diǎn)、以及任何適合使用程序解決大批量輸入數(shù)據(jù)的

地方。然后再尋找合適的自動測試工具，或者自己開發(fā)測試

程序。一定不要為了使用測試工具而使用。

參考答案：

參考答案：

壓力測試(StressTesting)

壓力測試的主要任務(wù)就是獲取系統(tǒng)正確運(yùn)行的極限，檢

查系統(tǒng)在瞬間峰值負(fù)荷下正確執(zhí)行的能力。例如，對服務(wù)器

做壓力測試時(shí)就可以增加并發(fā)操作的用戶數(shù)量；或者不停地

向服務(wù)器發(fā)送請求；或一次性向服務(wù)器發(fā)送特別大的數(shù)據(jù)等。

看看服務(wù)器保持正常運(yùn)行所能達(dá)到的最大狀態(tài)。人們通常使

用測試工具來完成壓力測試，如模擬上萬個(gè)用戶從終端同時(shí)

登錄，這是壓力測試中常常使用的方法。

負(fù)載測試(VolumeTesting)

用于檢查系統(tǒng)在使用大量數(shù)據(jù)的時(shí)候正確工作的能力,

即檢驗(yàn)系統(tǒng)的能力最高能達(dá)到什么程度。例如，對于信息檢

索系統(tǒng)，讓它使用頻率達(dá)到最大；對于多個(gè)終端的分時(shí)系統(tǒng),

讓它所有的終端都開動。在使整個(gè)系統(tǒng)的全部資源達(dá)到“滿

負(fù)荷”的情形下，測試系統(tǒng)的承受能力。

參考答案：（要結(jié)合自己實(shí)際的工作經(jīng)驗(yàn)進(jìn)行回答，不

同公司略有區(qū)別）

測試人員提交新的Bug入庫，錯誤狀態(tài)為New。

高級測試員/測試經(jīng)理驗(yàn)證錯誤，如果確認(rèn)是錯誤，分

配給開發(fā)組。設(shè)置狀態(tài)為Open。如果不是錯誤，則拒絕，設(shè)

置為Declined狀態(tài)。

開發(fā)經(jīng)理分配bug至對應(yīng)的模塊開發(fā)人員。

開發(fā)人員查詢狀態(tài)為Open的Bug,如果不是錯誤，則置

狀態(tài)為Declined；如果是Bug則修復(fù)并置狀態(tài)為Fixed。不

能解決的Bug,要留下文字說明及保持Bug為Open狀態(tài)。

對于不能解決和延期解決的Bug,不能由開發(fā)人員自己

決定，一般要通過某種會議（評審會）通過才能認(rèn)可。

測試人員查詢狀態(tài)為Fixed的Bug,然后驗(yàn)證Bug是否

已解決，如解決，置Bug的狀態(tài)為Closed,如沒有解決，置

bug狀態(tài)為Reopeno

參考答案：

硬件平臺和操作系統(tǒng)

測試應(yīng)用的硬件平臺（Platform）,通常選擇“PC”。

測試應(yīng)用的操作系統(tǒng)平臺（OS）。

a）版本

提交缺陷報(bào)告時(shí)通過該字段標(biāo)識此缺陷存在于被測試

軟件的哪個(gè)版本。

b）Bug報(bào)告優(yōu)先級

c）Bug狀態(tài)

d）Bug的編號

e）發(fā)現(xiàn)人

f）提交人

g）指定處理人

h）概述

i）從屬關(guān)系

j）詳細(xì)描述

k）嚴(yán)重程度

1）所屬模塊

m）附件

n）提交日期

參考答案：

這種現(xiàn)象在開發(fā)流程不規(guī)范的團(tuán)隊(duì)里特別常見，尤其是

一些“作坊式”的團(tuán)隊(duì)里。解決這種問題一般從兩個(gè)方面入

一方面從開發(fā)管理入手，也就是從根源來解決問題?？?/p>

以制定規(guī)范的開發(fā)流程，甚至可以制定懲罰制度，還有就是

軟件開發(fā)前做好規(guī)劃設(shè)計(jì)。

另一方面就是加強(qiáng)測試，具體做法就是加強(qiáng)開發(fā)人員的

自己測試，把這些問題“消滅”在開發(fā)階段，這是比較好的

做法，讀者可以參考第13章試案例分析的“缺陷反復(fù)出現(xiàn)，

誰的責(zé)任”小節(jié)，專門討論了這類問題的方法。

此外，還可以通過規(guī)范的缺陷管理來對開發(fā)人員進(jìn)行控

制，比如測試部門整理出常見的缺陷，讓開發(fā)人員自己對照

進(jìn)行檢查，以減少這類低級錯誤的發(fā)生。

開發(fā)人員犯錯誤是正常的現(xiàn)象，作為測試人員一定不能

抱怨，要認(rèn)認(rèn)真真的解決問題才是上策。

參考答案：

參考答案：

因?yàn)闆]有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件

的質(zhì)量，就好比ISO質(zhì)量認(rèn)證一樣，測試同樣也需要質(zhì)量的

保證，這個(gè)時(shí)候就需要在團(tuán)隊(duì)中開展軟件測試的工作。在測

試的過程發(fā)現(xiàn)軟件中存在的問題，及時(shí)讓開發(fā)人員得知并修

改問題，在即將發(fā)布時(shí)，從測試報(bào)告中得出軟件的質(zhì)量情況。

參考答案：（根據(jù)項(xiàng)目經(jīng)驗(yàn)不同，靈活回答即可）

我曾經(jīng)做過web測試，后臺測試，客戶端軟件，其中包

括功能測試，性能測試，用戶體驗(yàn)測試。最擅長的是功能測

試

參考答案：

測試類型有：功能測試，性能測試，界面測試。

功能測試在測試工作中占的比例最大，功能測試也叫黑

盒測試。是把測試對象看作一個(gè)黑盒子。利用黑盒測試法進(jìn)

行動態(tài)測試時(shí)，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)

品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑盒技術(shù)設(shè)計(jì)測試用例的方

法有：等價(jià)類劃分、邊界值分析、錯誤推測、因果圖和綜合

策略。

性能測試是通過自動化的測試工具模擬多種正常、峰值

以及異常負(fù)載條件來對系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載

測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過

負(fù)載測試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試

當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測

試是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來獲

得系統(tǒng)能提供的最大服務(wù)級別的測試。

界面測試，界面是軟件與用戶交互的最直接的層，界面

的好壞決定用戶對軟件的第一印象。而且設(shè)計(jì)良好的界面能

夠引導(dǎo)用戶自己完成相應(yīng)的操作，起到向?qū)У淖饔?。同時(shí)界

面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設(shè)計(jì)合理的界

面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界

面設(shè)計(jì)的失敗，讓用戶有挫敗感，再實(shí)用強(qiáng)大的功能都可能

在用戶的畏懼與放棄中付諸東流。

區(qū)別在于，功能測試關(guān)注產(chǎn)品的所有功能上，要考慮到

每個(gè)細(xì)節(jié)功能，每個(gè)可能存在的功能問題。性能測試主要關(guān)

注于產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試

更關(guān)注于用戶體驗(yàn)上，用戶使用該產(chǎn)品的時(shí)候是否易用，是

否易懂，是否規(guī)范（快捷鍵之類的），是否美觀（能否吸引用

戶的注意力），是否安全（盡量在前臺避免用戶無意輸入無效

的數(shù)據(jù)，當(dāng)然考慮到體驗(yàn)性，不能太粗魯?shù)膹棾鼍妫孔瞿?/p>

個(gè)性能測試的時(shí)候，首先它可能是個(gè)功能點(diǎn)，首先要保證它

的功能是沒問題的，然后再考慮該功能點(diǎn)的性能測試

參考答案：

白盒測試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能

多的內(nèi)部程序邏輯結(jié)果

黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模

塊輸出和輸入接口。不可能做到完全測試，以最少的用例在

合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題

參考答案：

黑盒測試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測試證

明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。

白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證

明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否

以經(jīng)過檢查。

軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這

種方法是把測試對象看做一個(gè)黑盒子，測試人員完全不考慮

程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說

明書，檢查程序的功能是否符合它的功能說明。因此黑盒測

試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒測試主要是為了發(fā)現(xiàn)

以下幾類錯誤：

1、是否有不正確或遺漏的功能？

2、在接口上，輸入是否能正確的接受？能否輸出正確的

結(jié)果？

3、是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪

問錯誤？

4、性能上是否能夠滿足要求？

5、是否有初始化或終止性錯誤？

軟件的白盒測試是對軟件的過程性細(xì)節(jié)做細(xì)致的檢查。

這種方法是把測試對象看做一個(gè)打開的盒子，它允許測試人

員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測試用

例，對程序所有邏輯路徑進(jìn)行測試。通過在不同點(diǎn)檢查程序

狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試

又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試主要是想對程序

模塊進(jìn)行如下檢查：

1、對程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一遍。

2、對所有的邏輯判定，取“真”與取“假”的兩種情

況都能至少測一遍。

3、在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循環(huán)體。

4、測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。

單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于

檢驗(yàn)被測代碼的一個(gè)很小的、很明確的功能是否正確。通常

而言，一個(gè)單元測試是用于判斷某個(gè)特定條件（或者場景）下

某個(gè)特定函數(shù)的行為。

單元測試是由程序員自己來完成，最終受益的也是程序

員自己。可以這么說，程序員有責(zé)任編寫功能代碼，同時(shí)也

就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是

為了證明這段代碼的行為和我們期望的一致。

集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯

擴(kuò)展。它的最簡單的形式是：兩個(gè)已經(jīng)測試過的單元組合成

一個(gè)組件，并且測試它們之間的接口。從這一層意義上講,

組件是指多個(gè)單元的集成聚合。在現(xiàn)實(shí)方案中，許多單元組

合成組件，而這些組件又聚合成程序的更大部分。方法是測

試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模

塊一起測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。

系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個(gè)完整系統(tǒng)

來測試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指

定功能的有效方法。（常見的聯(lián)調(diào)測試）

系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確

保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)。

驗(yàn)收測試是部署軟件之前的最后一個(gè)測試操作。驗(yàn)收測

試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用

于執(zhí)行軟件的既定功能和任務(wù)。

驗(yàn)收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那

樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計(jì)把所有的模塊組裝成

一個(gè)完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就

應(yīng)該進(jìn)一步驗(yàn)證軟件的有效性，這就是驗(yàn)收測試的任務(wù)，即

軟件的功能和性能如同用戶所合理期待的那樣。

參考答案：

軟件測試計(jì)劃是指導(dǎo)測試過程的綱領(lǐng)性文件，包含了產(chǎn)

品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試

周期、測試資源、測試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測

試計(jì)劃，參與測試的項(xiàng)目成員，尤其是測試管理人員，可以

明確測試任務(wù)和測試方法，保持測試實(shí)施過程的順暢溝通,

跟蹤和控制測試進(jìn)度，應(yīng)對測試過程中的各種變更。

測試計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)

的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的范圍、方法

和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的

具體戰(zhàn)術(shù)。所以其中最重要的是測試測試策略和測試方法

（最好是能先評審）

參考答案：

1.等價(jià)類劃分

劃分等價(jià)類：等價(jià)類是指某個(gè)輸入域的子集合.在該子

集合中，各個(gè)輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.

并合理地假定：測試某等價(jià)類的代表值就等于對這一類其它

值的測試.因此，可以把全部輸入數(shù)據(jù)合理劃分為若干等價(jià)

類，在每一個(gè)等價(jià)類中取一個(gè)數(shù)據(jù)作為測試的輸入條件，就

可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價(jià)

類劃分可有兩種不同的情況:有效等價(jià)類和無效等價(jià)類.

2.邊界值分析法

邊界值分析方法是對等價(jià)類劃分方法的補(bǔ)充。測試工作

經(jīng)驗(yàn)告訴我，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,

而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況

設(shè)計(jì)測試用例，可以查出更多的錯誤.

使用邊界值分析方法設(shè)計(jì)測試用例，首先應(yīng)確定邊界情

況.通常輸入和輸出等價(jià)類的邊界，就是應(yīng)著重測試的邊界

情況.應(yīng)當(dāng)選取正好等于，剛剛大于或剛剛小于邊界的值作

為測試數(shù)據(jù)，而不是選取等價(jià)類中的典型值或任意值作為測

試數(shù)據(jù).

3.錯誤推測法

基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯誤，

從而有針對性的設(shè)計(jì)測試用例的方法.

錯誤推測方法的基本思想：列舉出程序中所有可能有

的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)他們選擇測試用例.

例如，在單元測試時(shí)曾列出的許多在模塊中常見的錯誤.

以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等，這些就是經(jīng)驗(yàn)的總結(jié).

還有，輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況.輸入表格為空格或

輸入表格只有一行.這些都是容易發(fā)生錯誤的情況.可選

擇這些情況下的例子作為測試用例.

4.因果圖方法

前面介紹的等價(jià)類劃分方法和邊界值分析方法，都是著

重考慮輸入條件，但未考慮輸入條件之間的聯(lián)系，相互組合

等.考慮輸入條件之間的相互組合，可能會產(chǎn)生一些新的情

況.但要檢查輸入條件的組合不是一件容易的事情，即使

把所有輸入條件劃分成等價(jià)類，他們之間的組合情況也相當(dāng)

多.因此必須考慮采用一種適合于描述對于多種條件的組

合，相應(yīng)產(chǎn)生多個(gè)動作的形式來考慮設(shè)計(jì)測試用例.這就需

要利用因果圖（邏輯模型）.因果圖方法最終生成的就是判

定表.它適合于檢查程序輸入條件的各種組合情況.

參考答案：

就說最近的這次網(wǎng)站功能的測試吧

首先：得到相關(guān)文檔（需求文檔和設(shè)計(jì)文檔），理解需求

和設(shè)計(jì)設(shè)計(jì)思想后，想好測試策略（測試計(jì)劃簡單點(diǎn)就0K了）,

考慮到測試環(huán)境，測試用例，測試時(shí)間等問題。

第二步：設(shè)計(jì)測試用例，測試策略是：把網(wǎng)站部分的功

能點(diǎn)測試完，然后在進(jìn)行系統(tǒng)測試（另外個(gè)模塊呢有另一個(gè)

測試人員負(fù)責(zé)，可以進(jìn)行聯(lián)調(diào)測試），網(wǎng)站模塊的測試基本

是功能測試和界面測試（用戶并發(fā)的可能性很小，所以不考

慮）：這次的網(wǎng)站的輸入數(shù)據(jù)呢是使用數(shù)據(jù)庫中的某張表記

錄，如果表中某一數(shù)據(jù)記錄中新加進(jìn)來的（還沒有被處理的,

有個(gè)標(biāo)志位），網(wǎng)站啟動后會立刻去刷那張表，得到多條數(shù)

據(jù)，然后在進(jìn)行處理。處理過程中，會經(jīng)歷3個(gè)步驟，網(wǎng)站

才算完成了它的任務(wù)。有3個(gè)步驟呢，就可以分別對這

3個(gè)步驟進(jìn)行測試用例的設(shè)計(jì)，盡量覆蓋到各種輸入情況（包

括數(shù)據(jù)庫中的數(shù)據(jù)，用戶的輸入等），得出了差不多50個(gè)用

例。界面測試，也就是用戶看的到的地方，包括發(fā)送的郵件

和用戶填寫資料的頁面展示。

第三步：搭建測試環(huán)境（為什么這個(gè)時(shí)候考慮測試環(huán)境

呢？因?yàn)槲覍W(wǎng)站環(huán)境已經(jīng)很熟了，只有有機(jī)器能空于下來

做該功能測試就可以做了），因?yàn)榫W(wǎng)站本身的環(huán)境搭建和其

他的系統(tǒng)有點(diǎn)不同，它需要的測試環(huán)境比較麻煩，需要web

服務(wù)器（Apache,tomcat）,不過這次需求呢，網(wǎng)站部分只用

到了tomcat,所以只要有tomcat即可

第四步：執(zhí)行測試

參考答案：（以自己最熟悉的性能測試項(xiàng)目為例）

是的，曾經(jīng)做過網(wǎng)站方面的性能測試，雖然做的時(shí)間并

不久（2個(gè)月吧），當(dāng)時(shí)呢，是有位網(wǎng)站性能測試經(jīng)驗(yàn)非常豐

富的前輩帶著我一起做。

性能測試類型包括負(fù)載測試，強(qiáng)度測試，容量測試等

負(fù)載測試：負(fù)載測試是一種性能測試指數(shù)據(jù)在超負(fù)荷環(huán)

境中運(yùn)行，程序是否能夠承擔(dān)。

強(qiáng)度測試：強(qiáng)度測試是一種性能測試，他在系統(tǒng)資源特

別低的情況下軟件系統(tǒng)運(yùn)行情況

容量測試：確定系統(tǒng)可處理同時(shí)在線的最大用戶數(shù)

在網(wǎng)站流量逐漸加大的情況下，開始考慮做性能測試了,

首先要寫好性能測試計(jì)劃，根據(jù)運(yùn)營數(shù)據(jù)得出流量最大的頁

面（如果是第一次的話，一般是首頁，下載頁，個(gè)人帳戶頁

流量最大，而且以某種百分比），

Web服務(wù)器指標(biāo)指標(biāo)：

*AvgRps：平均每秒鐘響應(yīng)次數(shù)=總請求時(shí)間/秒數(shù)；

*SuccessfulRounds：成功的請求；

*FailedRounds：失敗的請求；

*SuccessfulHits：成功的點(diǎn)擊次數(shù)；

*FailedHits：失敗的點(diǎn)擊次數(shù)；

*HitsPerSecond：每秒點(diǎn)擊次數(shù)；

*SuccessfulHitsPerSecond：每秒成功的點(diǎn)擊次

數(shù)；

*FailedHitsPerSecond：每秒失敗的點(diǎn)擊次數(shù)；

*AttemptedConnections：嘗試鏈接數(shù)；

參考答案:

最大的興趣就是測試有難度，有挑戰(zhàn)性！做測試越久越

能感覺到做好測試有多難。曾經(jīng)在無憂測試網(wǎng)上看到一篇文

章，是關(guān)于如何做好一名測試工程師。一共羅列了11,12

點(diǎn)，有部分是和人的性格有關(guān)，有部分需要后天的努力。但

除了性格有關(guān)的1,2點(diǎn)我沒有把握，其他點(diǎn)我都很有信心

做好它。

剛開始進(jìn)入測試行業(yè)時(shí)，對測試的認(rèn)識是從無憂測試網(wǎng)

上了解到的一些資料，當(dāng)時(shí)是沖著做測試需要很多技能才能

做的好，雖然入門容易，但做好很難，比開發(fā)更難，雖然當(dāng)

時(shí)我很想做開發(fā)（學(xué)校專業(yè)課我基本上不缺席，因?yàn)槲蚁矚g

我的專業(yè)），但看到測試比開發(fā)更難更有挑戰(zhàn)性，想做好測

試的意志就更堅(jiān)定了。

不到一年半的測試工作中，當(dāng)時(shí)的感動和熱情沒有減退

一點(diǎn)（即使環(huán)境問題以及自身經(jīng)驗(yàn)，技術(shù)的不足，做測試的

你一定也能理解）。

我覺得做測試整個(gè)過程中有2點(diǎn)讓我覺得很有難度（對

我來說，有難度的東西我就非常感興趣），第一是測試用例

的設(shè)計(jì)，因?yàn)闇y試的精華就在測試用例的設(shè)計(jì)上了，要在版

本出來之前，把用例寫好，用什么測試方法寫？（也就是測試

計(jì)劃或測試策略），如果你剛測試一個(gè)新任務(wù)時(shí)，你得花一

定的時(shí)間去消化業(yè)務(wù)需求和技術(shù)基礎(chǔ)，業(yè)務(wù)需求很好理解

（多和產(chǎn)品經(jīng)理和開發(fā)人員溝通就能達(dá)到目的），而技術(shù)基礎(chǔ)

可就沒那么簡單了，這需要你自覺的學(xué)習(xí)能力，比如說網(wǎng)站

吧，最基本的技術(shù)知識你要知道網(wǎng)站內(nèi)部是怎么運(yùn)作的的,

后臺是怎么響應(yīng)用戶請求的？測試環(huán)境如何搭建？這些都需

要最早的學(xué)好。至少在開始測試之前能做好基本的準(zhǔn)備，可

能會遇到什么難題？需求細(xì)節(jié)是不是沒有確定好？這些問題

都能在設(shè)計(jì)用例的時(shí)候發(fā)現(xiàn)。

第二是發(fā)現(xiàn)BUG的時(shí)候了，這應(yīng)該是測試人員最基本的

任務(wù)了，一般按測試用例開始測試就能發(fā)現(xiàn)大部分的bug,

還有一部分bug需要測試的過程中更了解所測版本的情況獲

得更多信息，補(bǔ)充測試用例，測試出bug。還有如何發(fā)現(xiàn)bug?

這就需要在測試用例有效的情況下，通過細(xì)心和耐心去發(fā)現(xiàn)

bug了，每個(gè)用例都有可能發(fā)現(xiàn)bug,每個(gè)地方都有可能出

錯，所以測試過程中思維要清晰（測試過程數(shù)據(jù)流及結(jié)果都

得看仔細(xì)了，bug都在里面發(fā)現(xiàn)的）。如何描述bug也很有講

究，bug在什么情況下會產(chǎn)生，如果條件變化一點(diǎn)點(diǎn)，就不

會有這個(gè)bug,以哪些最少的操作步驟就能重現(xiàn)這個(gè)bug,

這個(gè)bug產(chǎn)生的規(guī)律是什么？如果你夠厲害的話，可以幫開

發(fā)人員初步定位問題。

參考答案：（靈活回答）

公司對測試流程沒有規(guī)定如何做，但每個(gè)測試人員都有

自己的一套測試流程。我說下我1年來不斷改正（自己總結(jié)，

吸取同行的方法）后的流程吧。需求評審（有開發(fā)人員，產(chǎn)品

經(jīng)理，測試人員，項(xiàng)目經(jīng)理）-＞需求確定（出一份確定的需求

文檔）-＞開發(fā)設(shè)計(jì)文檔（開發(fā)人員在開始寫代碼前就能輸出

設(shè)計(jì)文檔）想好測試策略，寫出測試用例-＞發(fā)給開發(fā)人員

和測試經(jīng)理看看（非正式的評審用例）-＞接到測試版本執(zhí)

行測試用例（中間可能會補(bǔ)充用例）-＞提交bug（有些bug需要

開發(fā)人員的確定（嚴(yán)重級別的，或突然發(fā)現(xiàn)的在測試用例范

圍之外的，難以重現(xiàn)的），有些可以直接錄制進(jìn)TD）-＞開發(fā)人

員修改（可以在測試過程中快速的修改）回歸測試（可能又

會發(fā)現(xiàn)新問題，再按流程開始跑）。

參考答案：

開發(fā)人員說不是bug,有2種情況，一是需求沒有確定，

所以我可以這么做，這個(gè)時(shí)候可以找來產(chǎn)品經(jīng)理進(jìn)行確認(rèn),

需不需要改動，3方商量確定好后再看要不要改。二是這種

情況不可能發(fā)生，所以不需要修改，這個(gè)時(shí)候，我可以先盡

可能的說出是BUG的依據(jù)是什么？如果被用戶發(fā)現(xiàn)或出了問

題，會有什么不良結(jié)果？程序員可能會給你很多理由，你可

以對他的解釋進(jìn)行反駁。如果還是不行，那我可以給這個(gè)問

題提出來，跟開發(fā)經(jīng)理和測試經(jīng)理進(jìn)行確認(rèn)，如果要修改就

改，如果不要修改就不改。其實(shí)有些真的不是bug,我也只是

建議的方式寫進(jìn)TD中，如果開發(fā)人員不修改也沒有大問題。

如果確定是bug的話，一定要堅(jiān)持自己的立場，讓問題得到

最后的確認(rèn)。

參考答案：版本控制命名格式：主版本號.子版本號[.

修正版本號[.編譯版本號]]

[.RevisionE.Build]]

應(yīng)根據(jù)下面的約定使用這些部分：

Major：具有相同名稱但不同主版本號的程序集不可互

換。例如，這適用于對產(chǎn)品的大量重寫，這些重寫使得無法

實(shí)現(xiàn)向后兼容性。

Minor：如果兩個(gè)程序集的名稱和主版本號相同，而次

版本號不同，這指示顯著增強(qiáng)，但照顧到了向后兼容性。例

如，這適用于產(chǎn)品的修正版或完全向后兼容的新版本。

Build：內(nèi)部版本號的不同表示對相同源所作的重新編

譯。這適合于更改處理器、平臺或編譯器的情況。

Revision:名稱、主版本號和次版本號都相同但修訂

號不同的程序集應(yīng)是完全可互換的。這適用于修復(fù)以前發(fā)布

的程序集中的安全漏洞。

BVT(BuildVerificationTest)：

作為Build的一部分，主要是通過對基本功能、特別是

關(guān)鍵功能的測試，保證新增代碼沒有導(dǎo)致功能失效，保證版

本的持續(xù)穩(wěn)定。實(shí)現(xiàn)BVT方式是有以下幾種：1、測試人員

手工驗(yàn)證關(guān)鍵功能實(shí)現(xiàn)的正確性。特點(diǎn)：這是傳統(tǒng)開發(fā)方法

中，通常采用的方式。無需維護(hù)測試腳本的成本，在測試人

力資源充足，測試人員熟悉業(yè)務(wù)、并對系統(tǒng)操作熟練情況下

效率很高，比較靈活快速。缺點(diǎn)：人力成本較高；對測試人

員能力有一定要求；測試人員面對重復(fù)的工作，容易產(chǎn)生疲

倦懈怠，從而影響測試質(zhì)量。2、借助基于GUI的自動化功

能測試工具來完成，將各基本功能操作錄制成測試腳本，每

次回放測試腳本驗(yàn)證功能實(shí)現(xiàn)的正確性。特點(diǎn)：能夠模擬用

戶操作完成自動的測試，從UI入口到業(yè)務(wù)實(shí)現(xiàn)，每一層的

代碼實(shí)現(xiàn)都經(jīng)過驗(yàn)證；節(jié)約人力成本；降低測試人員重復(fù)勞

動的工作量，機(jī)器不會疲倦;缺點(diǎn)：對于UI變動比較頻繁的

系統(tǒng)來說，這種方式的維護(hù)成本很高，實(shí)施起來非常困難。

另外，在項(xiàng)目周期較短且后續(xù)無延續(xù)性或繼承的情況下，也

不推薦使用此方式。3、由開發(fā)人員通過自動化測試工具完

成業(yè)務(wù)層的BVT測試。特點(diǎn)：通過對業(yè)務(wù)層關(guān)鍵功能的持續(xù)

集成測試，保證系統(tǒng)功能的持續(xù)穩(wěn)定?？梢越Y(jié)合DailyBuild,

做為Build的一部分，自動實(shí)現(xiàn)并輸入BVT報(bào)告。缺點(diǎn)：僅

對業(yè)務(wù)規(guī)則實(shí)現(xiàn)的正確性進(jìn)行了測試，對表現(xiàn)層無法測試到,

對于諸如：前臺頁面控件各種事件響應(yīng)、頁面元素變化等方

面的問題無法保證。

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

參考答案：

106、描述使用bugzilla缺陷管理工具對軟件缺陷(BUG)

跟蹤的管理的流程

針對不同的產(chǎn)品或者系統(tǒng)或者模塊，有不同的測試方法。

總體而言有白盒測試和黑盒測試。

案例的編寫與測試階段的定義有很大的關(guān)系。系統(tǒng)測試

和unit測試的案例可能不同?？傮w而言測試案例根據(jù)系統(tǒng)

的需求而定。

測試的全面性主要需要在設(shè)計(jì)測試計(jì)劃的時(shí)候考慮，從

測試策略，產(chǎn)品需求等等多個(gè)角度考慮從而定義全部的測試

點(diǎn)。

其他問題：（有可能清晰的思路比確切的答案更重要）

對測試的理解一一考查點(diǎn)：基本的測試知識，對測試是

否認(rèn)可

談一談過去自己的工作一一考查點(diǎn)：了解經(jīng)歷、提供進(jìn)

一步提問的素材，表達(dá)能力、測試技能