軟件測試常見面試題

軟件測試常見面試題

，問：你在測試中發(fā)現(xiàn)了一個bug，但是開發(fā)經(jīng)理認為這不是一個bug，你應該怎樣

解決？

首先，將問題提交到缺陷管理庫里面進行備案。

然后，要獲取判斷的依據(jù)和標準：

?根據(jù)需求說明書、產(chǎn)品說明、設計文檔等，確認實際結(jié)果是否與計劃有

不一致的地方，提供缺陷是否確認的直接依據(jù)；

?如果沒有文檔依據(jù)，可以根據(jù)類似軟件的一般特性來說明是否存在不一

致的地方，來確認是否是缺陷；

?根據(jù)用戶的一般使用習慣，來確認是否是缺陷；

?與設計人員、開發(fā)人員和客戶代表等相關人員探討，璃認是否是缺陷；

合理的論述，向測試經(jīng)理說明自己的判斷的理由，注意客觀、嚴謹，不

參雜個人情緒。

等待測試經(jīng)理做出最終決定，如果仍然存在爭議，可以通過公司政策所

提供的渠道，向上級反映，并有上級做出決定。

2、問：給你一個網(wǎng)站，你如何測試？

首先，查找需求說明、網(wǎng)站設計等相關文檔，分析測試需求。

制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：功

能性測試；界面測試；性能測試；數(shù)據(jù)庫測試；安全性測試；兼容性測

試

設計測試用例：

功能性測試可以包括，但不限于以下幾個方面：

?鏈接測試。鏈接是否正確跳轉(zhuǎn)，是否存在空頁面和無效頁面，是否有不

正確的出錯信息返回。

?提交功能的測試。

?多媒體元素是否可以正確加載和顯示。

?多語言支持是否能夠正確顯示選擇的語言等。

界面測試可以包括但不限于一下幾個方面：

?頁面是否風格統(tǒng)一,美觀

?頁面布局是否合理，重點內(nèi)容和熱點內(nèi)容是否突出

?控件是否正常使用

?對于必須但未安裝的控件，是否提供自動下載并安裝的功能

?文字檢查

性能測試一般從以下兩個方面考慮：

壓力測試；負載測試；強度測試

數(shù)據(jù)庫測試要具體決定是否需要開展。數(shù)據(jù)庫一般需要考慮連結(jié)性，對

數(shù)據(jù)的存取操作，數(shù)據(jù)內(nèi)容的驗證等方面。

安全性測試：

?基本的登錄功能的檢查

?是否存在溢出錯誤，導致系統(tǒng)崩潰或者權限泄露

?相關開發(fā)語言的常見安全性問題檢查，例如SQL注入等

?如果需要高級的安全性測試確定獲得專業(yè)安全公司的幫助，外包測試,

或者獲取支持

兼容性測試，根據(jù)需求說明的內(nèi)容，確定支持的平臺組合：

?瀏覽器的兼容性；

?操作系統(tǒng)的兼容性；

?軟件平臺的兼容性；

?數(shù)據(jù)庫的兼容性

開展測試，并記錄缺陷。合理的安排調(diào)整測試進度，提前獲取測試所需

的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺

陷報告、人力資源等內(nèi)容）。

定期評審，對測試進行評估和總結(jié)，調(diào)整測試的內(nèi)容。

3、在搜索引擎中輸入漢字就可以解析到對應的域名，請問如何用LoadRunner進行測

試。

?建立測試計戈！L確定測試標準和測試范圍

.設計典型場景的測試用例,覆蓋常用業(yè)務流程和不常用的業(yè)務流程等

?根據(jù)測試用例，開發(fā)自動測試腳本和場景：

錄制測試腳本：新建一個腳本（Web/HTML協(xié)議）；點擊錄制按鈕，

在彈出的對話框的URL中輸入〃about:blank〃；在打開的瀏覽器中進

行正常操作流程后，結(jié)束錄制；調(diào)試腳本并保存，可能要注意到字符集

的關聯(lián)。

設置測試場景：針對性能設置測試場景，主要判斷在正常情況下，系統(tǒng)

的平均事務響應時間是否達標；針對壓力負載設置測試場景，主要判斷

在長時間處于滿負荷或者超出系統(tǒng)承載能力的條件下，系統(tǒng)是否會崩潰；

執(zhí)行測試，獲取測試結(jié)果，分析測試結(jié)果，

4、問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么

區(qū)別？

300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的

結(jié)果。線程之間可能發(fā)生干擾,而產(chǎn)生一些異常。

?300個用戶在一個客戶端上，需要更大的帶寬。

?IP地址的問題，可能需要使用IPSpoof來繞過服務器對于單一IP地

址最大連接數(shù)的限制。

?所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在

不同的客戶端上，需要考慮使用控制器來整體調(diào)配不同客戶機上的用戶。

同時，還需要給予相應的權限配置和防火墻設置。

5、試述軟件的概念和特點？軟件復用的含義？構(gòu)件包括哪些？

軟件是計算機系統(tǒng)中與硬件相互依存的另一部分，與計算機系統(tǒng)操作有

關的計算機程序、規(guī)程、規(guī)則，以及可能有的文件、義檔及數(shù)據(jù)。

軟件復用(SoftwareReuse)是將已有軟件的各種有關知識用于建立新

的軟件，以縮減軟件開發(fā)和維護的花費。軟件復用是提高軟件生產(chǎn)力和

質(zhì)量的一種重要技術。早期的軟件復用主要是代碼級復用，被復用的知

識專指程序，后來擴大到包括領域知識、開發(fā)經(jīng)驗、設計決定、體系結(jié)

構(gòu)、需求、設計、代碼和文檔等一切有關方面。

可以被復用的軟件成分一般稱作可復用構(gòu)件

6、軟件生存周期及其模型是什么？

軟件生存周期（Softwarelifecycle）又稱為軟件生命期，生存期。是

指從形成開發(fā)軟件概念起，所開發(fā)的軟件使用以后，知道失去使用價值

消亡為止的整個過程。一般來說，整個生存周期包括計劃（定義）、開

發(fā)、運行（維護）三個時期，每個時期又劃分為若干個階段。每個階段

有明確的任務。

周期模型（典型的幾種）：

?瀑布模型

?快速原型模型快速原型模型允許在需求分析階段對軟件的需求進行初

步而非完全的分析和定義，快速設計開發(fā)出軟件系統(tǒng)的原型，該原型向

用戶展示待開發(fā)軟件的全部或部分功能和性能；用戶對該原型進行測試

評定，給出具體改進意見以豐富細化軟件需求；開發(fā)人員據(jù)此對軟件進

行修改完善，直至用戶滿意認可之后，進行軟件的完整實現(xiàn)及測試、維

護。

?迭代模型：迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）的全部

開發(fā)活動和要使用該發(fā)布必需的所有其他外圍元素。在某種程度上，開

發(fā)迭代是一次完整地經(jīng)過所有工作流程的過程：需求分析、設計、實施

和測試工作流程。實質(zhì)上..它類似小型的瀑布式項目。RUP認為，所有

的階段都可以細分為迭代。每一次的迭代都會產(chǎn)生一個可以發(fā)布的產(chǎn)品,

這個產(chǎn)品是最終產(chǎn)品的一個子集。

生命周期階段：

?軟件計劃與可行性分析

?需求分析

?軟件設計

,編碼

?軟件測試

?運行與維護

7、什么是軟件測試？軟件測試的目的與原則

在規(guī)定的條件下對程序進行操作,以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量,并

對其是否能滿足設計要求進行評估的過程。

軟件測試的目的：

?測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤

?一個成功的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤

?一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試

?確保產(chǎn)品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都

有明確的書面說明。

?確保產(chǎn)品滿足性能和效率的要求

?確保產(chǎn)品是健壯的和適應用戶環(huán)境的

軟件測試的原則：

?測試用例中一個必須部分是對預期輸出或接過進行定義

?程序員應避免測試自己編寫的程序

?編寫軟件的組織不應當測試自己編寫的軟件

?應當徹底檢查每個測試的執(zhí)行結(jié)果

?測試用例的編寫不僅應當根據(jù)有效和預料到的輸入情況，而且也應當根

據(jù)無效和未預料到的輸入情況

?檢擦程序是否〃未做其應該做的〃僅是測試的一半，測試的另一半是檢

查程序是否〃做了其不應該做的〃

?應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件

?計劃測試工作時不應默許假定不會發(fā)現(xiàn)錯誤

?程序某部分存在更多錯誤的可能性與該部分已經(jīng)發(fā)現(xiàn)錯誤的數(shù)量成正

比

?軟件測試是一項極富創(chuàng)造性，極具智力的挑戰(zhàn)性的工作

8、軟件配置管理的作用？軟件配置包括什么？

軟件配置管理(SoftwareConfigurationManagement,SCM)是一

種標識、組織和控制修改的技術。軟件配置管理應用于整個軟件工程過

程。在軟件建立時變更是不可避免的，而變更加劇了項目中軟件開發(fā)者

之間的混亂。SCM活動的目標就是為了標識變更、控制變更、確保變

更正確實現(xiàn)并向其他有關人員報告變更。從某種角度講，SCM是一種

標識、組織和控制修改的技術，目的是使錯誤降為最小并最有效地提高

生產(chǎn)效率。

軟件配置包括如下內(nèi)容：配置項識別、工作空間管理、版本控制、變更

控制、狀態(tài)報告、配置審計

9、什么是軟件質(zhì)量？

概括地說，軟件質(zhì)量就是"軟件與明確的和隱含的定義的需求相一致的

程度〃。具體地說，軟件質(zhì)量是軟件符合明確敘述的功能和性能需求、

文檔中明確描述的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應具有的隱含

特征的程度。影響軟件質(zhì)量的主要因素，這些因素是從管理角度對軟

件質(zhì)量的度量。可劃分為三組，分別反應用戶在使用軟件產(chǎn)品時的三種

觀點。正確性、健壯性、效率、完整性、可用性、風險（產(chǎn)品運行）；

可理解性、可維修性、靈活性、可測試性（產(chǎn)品修改）；可移植性、可

再用性、互運行性（產(chǎn)品轉(zhuǎn)移）。

10、目前主要的測試用例設計方法是什么？

白盒測試：邏輯覆蓋、循環(huán)覆蓋、基本路徑覆蓋

黑盒測試：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態(tài)

圖法、測試大綱法、隨機測試、場景法

11,軟件的安全性應從哪幾個方面去測試？

軟件安全性測試包括程序、數(shù)據(jù)庫安全性測試。根據(jù)系統(tǒng)安全指標不同

測試策略也不同。

?用戶認證安全的測試要考慮問題：明確區(qū)分系統(tǒng)中不同用戶權限、系

統(tǒng)中會不會出現(xiàn)用戶沖突、系統(tǒng)會不會因用戶的權限的改變造成混亂、

用戶登陸密碼是否是可見、可復制、是否可以通過絕對途徑登陸系統(tǒng)

（拷貝用戶登陸后的鏈接直接進入系統(tǒng)）、用戶退出系統(tǒng)后是否刪除了

所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統(tǒng)、系

統(tǒng)網(wǎng)絡安全的測試要考慮問題、測試采取的防護措施是否正確裝配好，

有關系統(tǒng)的補丁是否打上、模擬非授權攻擊，看防護系統(tǒng)是否堅固、

采用成熟的網(wǎng)絡漏洞檢查工具檢查系統(tǒng)相關漏洞（即用最專業(yè)的黑客攻

擊工具攻擊試一下，現(xiàn)在最常用的是NBSI系列和IPhackerIP）、

采用各種木馬檢查工具檢查系統(tǒng)木馬情況、采用各種防外掛工具檢查

系統(tǒng)各組程序的外掛漏洞

?數(shù)據(jù)庫安全考慮問題：系統(tǒng)數(shù)據(jù)是否機密（比如對銀行系統(tǒng)，這一點

就特別重要，一般的網(wǎng)站就沒有太高要求）、系統(tǒng)數(shù)據(jù)的完整性（我剛

剛結(jié)束的企業(yè)實名核查服務系統(tǒng)中就曾存在數(shù)據(jù)的不完整，對于這個系

統(tǒng)的功能實現(xiàn)有了障礙）、系統(tǒng)數(shù)據(jù)可管理性、系統(tǒng)數(shù)據(jù)的獨立性、

系統(tǒng)數(shù)據(jù)可備份和恢復能力（數(shù)據(jù)備份是否完整，可否恢復，恢復是否

可以完整）

12、什么是測試用例什么是測試腳本兩者的關系是什么？

為實施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設置以及

期望結(jié)果的一個特定的集合。

測試腳本是為了進行自動化測試而編寫的腳本。

測試腳本的編寫必須對應相應的測試用例

13、簡述什么是靜態(tài)測試、動態(tài)測試、黑盒測試、白盒測試、a測試B測試

?靜態(tài)測試是不運行程序本身而尋找程序代碼中可能存在的錯誤或評估

程序代碼的過程。

?動態(tài)測試是實際運行被測程序，輸入相應的測試實例，檢查運行結(jié)果與

預期結(jié)果的差異，判定執(zhí)行結(jié)果是否符合要求，從而檢臉程序的正確性、

可靠性和有效性，并分析系統(tǒng)運行效率和健壯性等性能。

?黑盒測試一般用來確認軟件功能的正確性和可操作性，目的是檢測軟件

的各個功能是否能得以實現(xiàn)才巴被測試的程序當作一個黑盒，不考慮其內(nèi)

部結(jié)構(gòu)，在知道該程序的輸入和輸出之間的關系或程序功能的情況下，依

靠軟件規(guī)格說明書來確定測試用例和推斷測試結(jié)果的正確性。

?白盒測試根據(jù)軟件內(nèi)部的邏輯結(jié)構(gòu)分析來進行測試,是基于代碼的測試,

測試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調(diào)試來判

斷軟件的質(zhì)量，一般黑盒測試由項目經(jīng)理在程序員開發(fā)中來實現(xiàn)。

?a測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用

戶在模擬實際操作環(huán)境下進行的受控測試，Alpha測試不能由程序員或

測試員完成。

?0測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的

測試。開發(fā)者通常不在測試現(xiàn)場,Beta測試不能由程序員或測試員完

成。

14、軟件質(zhì)量保證體系是什么國家標準中與質(zhì)量保證管理相關的幾個標準是什么?他們

的編號和全稱是什么?

SQA由一套軟件工程過程和方法組成，以保證（軟件的）質(zhì)量。SQA

貫穿整個軟件開發(fā)過程，（它）應包括需求文檔評審、代碼控制、代碼評

審、變更管理、配置管理、版本管理和軟件測試。

軟件質(zhì)量保證（SQA-SoftwareQualityAssurance）是建立一套有計

劃，有系統(tǒng)的方法，來向管理層保證擬定出的標準、步驟、實踐和方法

能夠正確地被所有項目所采用。軟件質(zhì)量保證的目的是使軟件過程對于

管理人員來說是可見的。它通過對軟件產(chǎn)品和活動進行評審和審計來驗

證軟件是合乎標準的。軟件質(zhì)量保證組在項目開始時就一起參與建立計

劃、標準和過程。這些將使軟件項目滿足機構(gòu)方針的要求。

15、軟件產(chǎn)品質(zhì)量特性是什么？

功能性：適應性、準確性、互操作性、依從性、安全性。

可靠性：成熟性、容錯性、易恢復性。

可使用性：易理解性、易學習性、易操作性。

效率：時間特性、資源特性。

可維護性：易分析性、易變更性、穩(wěn)定性、易測試性。

可移植性：適應性、易安裝性、遵循性、易替換性

16、軟件測試的策略是什么?

軟件測試策略：在一定的軟件測試標準、測試規(guī)范的指導下，依據(jù)測試

項目的特定環(huán)境約束而規(guī)定的軟件測試的原則、方式、方法的集合。

17、軟件測試分為幾個階段各階段的測試策略和要求是什么？

和開發(fā)過程相對應，測試過程會依次經(jīng)歷單元測試、集成測試、系統(tǒng)測

試、驗收測試四個主要階段：

.單元測試：單元測試是針對軟件設計的最小單位一程序模塊甚至代碼

段進行正確性檢驗的測試工作，通常由開發(fā)人員進行。

?集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目

的是發(fā)現(xiàn)與接口有關的問題。由于在產(chǎn)品提交到測試部門前，產(chǎn)品開發(fā)

小組都要進行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來

完成的。

?系統(tǒng)測試系統(tǒng)測試是在集成測試通過后進行的，目的是充分運行系統(tǒng)，

驗證各子系統(tǒng)是否都能正常工作并完成設計的要求。它主要由測試部門

進行，是測試部門最大最重要的一個測試，對產(chǎn)品的質(zhì)量有重大的影響。

?驗收測試：驗收測試以需求階段的《需求規(guī)格說明書》為驗收標準，測

試時要求模擬實際用戶的運行環(huán)境。對于實際項目可以和客戶共同進行,

對于產(chǎn)品來說就是最后一次的系統(tǒng)測試。測試內(nèi)容為對功能模塊的全面

測試，尤其要進行文檔測試。

單元測試測試策略：

自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測

試的一個好的選擇。

自底向上的單元測試策略:比較合理的單元測試策略，但測試周期較長。

孤立單元測試策略：最好的單元測試策略。

集成測試的測試策略：

大爆炸集成：適應于一個維護型項目或被測試系統(tǒng)較小

自頂向下集成：適應于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較

??；底層接口未定義或經(jīng)常可能被修改；產(chǎn)口控制組件具有較大的技術

風險，需要盡早被驗證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

自底向上集成：適應于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底

層組件較早被完成。

基于進度的集成

優(yōu)點：具有較高的并行度；能夠有效縮短項目的開發(fā)進度。

缺點：樁和驅(qū)動工作量較大；有些接口測試不充分；有些測試重復和浪

費。

系統(tǒng)測試的測試策略:

數(shù)據(jù)和數(shù)據(jù)庫完整性測試；功能測試；用戶界面測試；性能評測；負載

測試；強度測試；容量測試；安全性和訪問控制測試；故障轉(zhuǎn)移和恢復

測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試;

文檔測試

18、軟件測試各個階段通常完成什么工作？各個階段的結(jié)果文件是什么？包括什么內(nèi)

容？

單元測試階段：各獨立單元模塊在與系統(tǒng)地其他部分相隔離的情況下進

行測試，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序

模塊是否正確地實現(xiàn)了規(guī)定的功能。生成單元測試報告，提交缺陷報告。

集成測試階段：集成測試是在單元測試的基礎上，測試在將所有的軟件

單元按照概要設計規(guī)格說明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過程中

各部分工作是否達到或?qū)崿F(xiàn)相應技術指標及要求的活動。該階段生成集

成測試報告，提交缺陷報告。

系統(tǒng)測試階段：將通過確認測試的軟件，作為整個給予計算機系統(tǒng)的一

個元素，與計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)

元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行全面的功能覆

蓋。該階段需要提交測試總結(jié)和缺陷報告。

19、測試人員在軟件開發(fā)過程中的任務是什么？

1、盡可能早的找出系統(tǒng)中的Bug;

2、避免軟件開發(fā)過程中缺陷的出現(xiàn)；

3、衡量軟件的品質(zhì)，保證系統(tǒng)的質(zhì)量；

4、關注用戶的需求，并保證系統(tǒng)符合用戶需求。

總的目標是：確保軟件的質(zhì)量。

20、在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？如何

提交高質(zhì)量的軟件缺陷（Bug）記錄？

一條Bug記錄最基本應包含：

bug編號;

bug嚴重級別，優(yōu)先級;

bug產(chǎn)生的模塊；

首先要有bug摘要，闡述bug大體的內(nèi)容；

bug對應的版本；

bug詳細現(xiàn)象描述,包括一些截圖、錄像….等等；

bug出現(xiàn)時的測試環(huán)境，產(chǎn)生的條件即對應操作步驟;

高質(zhì)量的Bug記錄：

1）通用ui要統(tǒng)一、準確

缺陷報告的UI要與測試的軟件UI保持一致，便于查找定位。

2）盡量使用業(yè)界慣用的表達術語和表達方法

使用業(yè)界慣用的表達術語和表達方法，保證表達準確，體現(xiàn)專業(yè)化。

3）每條缺陷報告只包括一個缺陷

每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷,

集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經(jīng)正

確修正。

4）不可重現(xiàn)的缺陷也要報告

首先缺陷報告必須展示重現(xiàn)缺陷的能力。不可重現(xiàn)的缺陷要盡力重現(xiàn),

若盡力之后仍不能重現(xiàn)，仍然要報告此缺陷，但在報告中要注明無法再

現(xiàn)，缺陷出現(xiàn)的頻率。

5）明確指明缺陷類型

根據(jù)缺陷的現(xiàn)象，總結(jié)判斷缺陷的類型。例如，即功能缺陷、界面缺陷、

數(shù)據(jù)缺陷，合理化建議這是最常見的缺陷或缺陷類型,其他形式的缺陷

或缺陷也從屬于其中某種形式。

6）明確指明缺陷嚴重等級和優(yōu)先等級

時刻明確嚴重等級和優(yōu)先等級之間的差別。高嚴重問題可能不值得解決,

小裝飾性問題可能被當作高優(yōu)先級。

7）描述（Description）,簡潔、準確，完整,揭示缺陷實質(zhì)，記錄缺陷或缺陷出現(xiàn)的

位置

描述要準確反映缺陷的本質(zhì)內(nèi)容，簡短明了。為了便于在軟件缺陷管理

數(shù)據(jù)庫中尋找制定的測試缺陷，包含缺陷發(fā)生時的用戶界面（UI）是個

良好的習慣。例如記錄對話框的標題、菜單、按鈕等控件的名稱。

8）短行之間使用自動數(shù)字序號，使用相同的字體、字號、行間距

短行之間使用自動數(shù)字序號，使用相同的字體、字號、行間距，可以保

證各條記錄格式一致，做到規(guī)范專業(yè)。

9）每一個步驟盡量只記錄一個操作

保證簡潔、條理井然，容易重復操作步驟。

10）確認步驟完整，準確，簡短

保證快速準確的重復缺陷，〃完整〃即沒有缺漏，〃準確〃即步驟正確，

〃簡短〃即沒有多余的步驟。

工工）根據(jù)缺陷，可選擇是否進行圖象捕捉

為了直觀的觀察缺陷或缺陷現(xiàn)象，通常需要附加缺陷或缺陷出現(xiàn)的界面,

以圖片的形式作為附件附著在記錄的〃附件〃部分。為了節(jié)省空間，又

能真實反映缺陷或缺陷本質(zhì)，可以捕捉缺陷或缺陷產(chǎn)生時的全屏幕，活

動窗口和局部區(qū)域。為了迅速定位、修正缺陷或缺陷位置，通常要求附

加中文對照圖。

I附加必要的特殊文檔和個人建議和注解

如果打開某個特殊的文檔而產(chǎn)生的缺陷或缺陷，則必須附加該文檔，從

而可以迅速再現(xiàn)缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明

確缺陷或缺陷的表現(xiàn)，可以附加個人的修改建議或注解。

12）檢查拼寫和語法缺陷

在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內(nèi)容正確，正確的

描述缺陷。

13）盡量使用短語和短句，避免復雜句型句式

軟件缺陷管理數(shù)據(jù)庫的目的是便于定位缺陷，因此，要求客觀的描述操

作步驟，不需要修飾性的詞匯和復雜的句型，增強可讀性。

以上概括了報告測試缺陷的規(guī)范要求，隨著軟件的測試要求不同，測試

者經(jīng)過長期測試，積累了相應的測試經(jīng)驗，將會逐漸養(yǎng)成良好的專業(yè)習

慣，不斷補充新的規(guī)范書寫要求。此外，經(jīng)常閱讀、學習其他測試工程

師的測試缺陷報告，結(jié)合自己以前的測試缺陷報告進行對比和思考，可

以不斷提高技巧。

14）缺陷描述內(nèi)容

缺陷描述的內(nèi)容可以包含缺陷操作步驟，實際結(jié)果和期望結(jié)果。操作步

驟可以方便開發(fā)人員再現(xiàn)缺陷進行修正，有些開發(fā)的再現(xiàn)缺陷能力很差,

雖然他明白你所指的缺陷，但就是無法再現(xiàn)特別是對系統(tǒng)不熟悉的新加

入開發(fā)人員，介紹步驟可以方便他們再現(xiàn)。實際結(jié)果可以讓開發(fā)明白錯

誤是什么，期望結(jié)果可以讓開發(fā)了解正確的結(jié)果應該是如何。

21、黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優(yōu)點和缺點！

黑盒測試的優(yōu)點有：上匕較簡單，不需要了解程序內(nèi)部的代碼及實現(xiàn)；與

軟件的內(nèi)部實現(xiàn)無關；從用戶角度出發(fā)，能很容易的知道用戶會用到

哪些功能，會遇到哪些問題；基于軟件開發(fā)文檔，所以也能知道軟件實

現(xiàn)了文檔中的哪些功能；在做軟件自動化測試時較為方便。

黑盒測試的缺點有：不可能覆蓋所有的代碼，覆蓋率較低，大概只能達

到總代碼量的30%;自動化測試的復用性較低。

白盒測試的優(yōu)點有：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的

質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題。

白盒測試的缺點有：程序運行會有很多不同的路徑，不可能測試所有的

運行路徑；測試基于代碼,只能測試開發(fā)人員做的對不對，而不能知道

設計的正確與否，可能會漏掉一些功能需求；系統(tǒng)龐大時，測試開銷會

非常大。

22、如何測試一個紙杯？

功能度：用水杯裝水看漏不漏；水能不能被喝到

安全性：杯子有沒有毒或細菌

可靠性：杯子從不同高度落下的損壞程度

可移植性：杯子在不同的地方、溫度等環(huán)境下是否都可以正常使用

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

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

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

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

盛上汽油（案例二）放24小時檢查泄漏時間和情況等

壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透

22、測試計劃工作的目的是什么？測試計劃文檔的內(nèi)容應該包括什么？其中哪些是最重

要的？

軟件測試計劃是指導測試過程的綱領性文件：

?領導能夠根據(jù)測試計劃進行宏觀調(diào)控，進行相應資源配置等

?測試人員能夠了解整個項目測試情況以及項目測試不同階段的所要進

行的工作等

?便于其他人員了解測試人員的工作內(nèi)容，進行有關配合工作

包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周

期、測試資源、測試交流、風險分析等內(nèi)容。借助軟件測試計劃，參與

測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法,

保持測試實施過程的順暢溝通，跟蹤和控制測試進度,應對測試過程中

的各種變更。

測試計劃編寫6要素（5W1H）:

why——為什么要進行這些測試；

what—測試哪些方面,不同階段的工作內(nèi)容；

when—測試不同階段的起止時間；

where-相應文檔，缺陷的存放位置,測試環(huán)境等;

who一項目有關人員組成，安排哪些測試人員進行測試;

how—如何去做，使用哪些測試工具以及測試方法進行測試

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

劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)

格、測試用例是完成測試任務的具體戰(zhàn)術。所以其中最重要的是測試測

試策略和測試方法（最好是能先評審）。

23、黑盒測試的測試用例常見設計方法都有哪些？請分別以具體的例子來說明這些方法

在測試用例設計工作中的應用。

1）等價類劃分：等價類是指某個輸入域的子集合.在該子集合中，各個

輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價

類的代表值就等于對這一類其它值的測試.因此，可以把全部輸入數(shù)據(jù)合

理劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條

件，就可以用少量代表性的測試數(shù)據(jù),取得較好的測試結(jié)果.等價類劃分可

有兩種不同的情況:有效等價類和無效等價類.

2）邊界值分析法：是對等價類劃分方法的補充。測試工作經(jīng)驗告訴我,

大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出

范圍的內(nèi)部.因此針對各種邊界情況設計測試用例，可以查出更多的錯誤.

使用邊界值分析方法設計測試用例，首先應確定邊界情況.通常輸入和輸

出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于，剛剛大

于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中的典型值或

任意值作為測試數(shù)據(jù).

3）錯誤猜測法：基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤,

從而有針對性的設計測試用例的方法.

錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發(fā)生

錯誤的特殊情況根據(jù)他們選擇測試用例.例如，在單元測試時曾列出的

許多在模塊中常見的錯誤.以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等，這些就

是經(jīng)驗的總結(jié).還有，輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況.輸入表格為空

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

況下的例子作為測試用例.

4）因果圖方法：前面介紹的等價類劃分方法和邊界值分析方法,都是著

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

條件之間的相互組合，可能會產(chǎn)生一些新的情況.但要檢查輸入條件的

組合不是一件容易的事情，即使把所有輸入條件劃分成等價類，他們之

間的組合情況也相當多.因此必須考慮采用一種適合于描述對于多種條

件的組合,相應產(chǎn)生多個動作的形式來考慮設計測試用例.這就需要利

用因果圖（邏輯模型）.因果圖方法最終生成的就是判定表.它適合于

檢查程序輸入條件的各種組合情況.

5）正交表分析法：可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上

的激增，同時，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人

員又無法完成這么多數(shù)量的測試，就可以通過正交表來進行縮減一些用

例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

6）場景分析方法：指根據(jù)用戶場景來模擬用戶的操作步驟，這個比較

類似因果圖，但是可能執(zhí)行的深度和可行性更好。

7漱態(tài)圖法:通過輸入條件和系統(tǒng)需求說明得到被測系統(tǒng)的所有狀態(tài)，

通過輸入條件和狀態(tài)得出輸出條件；通過輸入條件、輸出條件和狀態(tài)得

出被測系統(tǒng)的測試用例。

8）大綱法：大綱法是一種著眼于需求的方法，為了列出各種測試條件，

就將需求轉(zhuǎn)換為大綱的形式。大綱表示為樹狀結(jié)構(gòu)，在根和每個葉子結(jié)

點之間存在唯一的路徑。大綱中的每條路徑定義了一個特定的輸入條件

集合，用于定義測試用例。樹中葉子的數(shù)目或大綱中的路徑給出了測試

所有功能所需測試用例的大致數(shù)量。

24、詳細的描述一個測試活動完整的過程。（供參考，本答案主要是瀑布模型的做法）

項目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共

同完成需求文檔的評審，評審的內(nèi)容包括：需求描述不清楚的地方和可

能有明顯沖突或者無法實現(xiàn)的功能的地方。項目經(jīng)理通過綜合開發(fā)人員,

測試人員以及客戶的意見，完成項目計劃。然后SQA進入項目，開始

進行統(tǒng)計和跟蹤

開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進行評審，評審的

主要內(nèi)容包括是否有遺漏或雙方理解不同的地方。測試人員完成測試計

劃文檔，測試計劃包括的內(nèi)容上面有描述。

測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時開發(fā)人員完

成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用

例的補充材料。

測試用例完成后，測試和開發(fā)需要進行評審。

測試人員搭建環(huán)境

開發(fā)人員提交第一個版本，可能存在未完成功能，需要說明。測試人員

進行測試，發(fā)現(xiàn)后提交給

BUGBugZillao

開發(fā)提交第二個版本,包括BugFix以及增加了部分功能,測試人員進

行測試。

重復上面的工作，一般是3-4個版本后BUG數(shù)量減少，達到出貨的要

求。

如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)并重新測試。

26、BUG管理工具的跟蹤過程（用BugZilla為例子）

測試人員發(fā)現(xiàn)了BUG,提交到Bugzilla中，狀態(tài)為new,BUG的接受

者為開發(fā)接口人員

開發(fā)接口將BUG分配給相關的模塊的開發(fā)人員，狀態(tài)修改為已分配，

開發(fā)人員和測試確認BUG,如果是本人的BUG,則設置為接收；如果

是別的開發(fā)人員的問題，則轉(zhuǎn)發(fā)出去，由下一個開發(fā)人員來進行此行為；

如果認為不是問題，則需要大家討論并確認后，拒絕這個BUG,然后

測試人員關閉此問題。

如果開發(fā)人員接受了BUG，并修改好以后招BUG狀態(tài)修改為已修復，

并告知測試在哪個版本中可以測試。

測試人員在新版本中測試，如果發(fā)現(xiàn)問題依然存在，則拒絕驗證；如果

已經(jīng)修復，則關閉BUG。

27、您認為在測試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的效

果？維持測試人員同開發(fā)團隊中其他成員良好的人際關系的關鍵是什么？

盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過Email

等非及時溝通工具的話，強調(diào)必須對特性的理解深刻以及能表達清楚。

運用一些測試管理工具如TestDirector進行管理也是較有效的方法，

同時要注意在TestDirector中對BUG有準確的描述。

在團隊中建立測試人員與開發(fā)人員良好溝通中注意以下幾點：

一真誠、二是團隊精神、三是在專業(yè)上有共同語言、四是要對事不對人,

工作至上

當然也可以通過直接指出一些小問題，而不是進入BUGTracking

System來增加對方的好感。

28、你對測試最大的興趣在哪里？為什么？

回答這個面試題，沒有固定統(tǒng)一的答案，但可能是許多企業(yè)都會問到的。

提供以下答案供考：

最大的興趣,感覺這是一個有挑戰(zhàn)性的工作；

測試是一個經(jīng)驗行業(yè)，工作越久越能感覺到做好測試的難度和樂趣

通過自己的工作，能使軟件產(chǎn)品越來越完善，從中體會到樂趣

回答此類問題注意以下幾個方面：

盡可能的切合招聘企業(yè)的技術路線來表達你的興趣，例如該企業(yè)是數(shù)據(jù)

庫應用的企業(yè)，那么表示你的興趣在數(shù)據(jù)庫的測試，并且希望通過測試

提升自己的數(shù)據(jù)庫掌握能力。

表明你做測試的目的是為了提升能力，也是為了更好的做好測試；提升

能力不是為了以后轉(zhuǎn)開發(fā)或其他的，除非用人企業(yè)有這樣的安排。

不要過多的表達你的興趣在招聘企業(yè)的范疇這外。比如招聘企業(yè)是做財

務軟件的，可是你表現(xiàn)出來的是對游戲軟件的興趣；或招聘是做JAVA

開發(fā)的，而你的興趣是在C類語言程序的開發(fā)。

29、你自認為測試的優(yōu)勢在哪里？

該面試也沒有固定不變的答案，但可參考以下幾點，并結(jié)合自身特點：

有韌性、有耐心、做事有條理性、喜歡面對挑戰(zhàn)、有信心做好每一件事

情、較強的溝通能力、從以前的經(jīng)理處都得到了很好的評價表明我做的

很好

30、簡述你在以前的工作中做過哪些事情，比較熟悉什么。參考答案如下。

我過去的主要工作是系統(tǒng)測試和自動化測試。在系統(tǒng)測試中，主要是對

BOSS系統(tǒng)的業(yè)務邏輯功能以及軟交換系統(tǒng)的Class5特性進行測試。

性能測試中，主要是進行的壓力測試，在各個不同數(shù)量請求的情況下,

獲取系統(tǒng)響應時間以及系統(tǒng)資源消耗情況。自動化測試主要是通過自己

寫腳本以及一些第三方工具的結(jié)合來測試軟交換的特性測試。

在測試中，我感覺對用戶需求的完全準確的理解非常重要。另外，就是

對BUG的管理，要以需求為依據(jù)，并不是所有BUG均需要修改。

測試工作需要耐心和細致，因為在新版本中，雖然多數(shù)原來發(fā)現(xiàn)的BUG

得到了修復，但原來正確的功能也可能變得不正確。因此要注重迭代測

試和回歸測試。

31、在C/C++中static有什么用途？（請至少說明兩種）

1）在函數(shù)體，一個被聲明為靜態(tài)的變量在這一函數(shù)被調(diào)用過程中維持其

值不變。

2）在模塊內(nèi)（但在函數(shù)體外），一個被聲明為靜態(tài)的變量可以被模塊

內(nèi)所用函數(shù)訪問，但不能被模塊外其它函數(shù)訪問。它是一個本地的全局

變量。

3）在模塊內(nèi)，一個被聲明為靜態(tài)的函數(shù)只可被這一模塊內(nèi)的其它函數(shù)

調(diào)用。那就是，這個函數(shù)被限制在聲明它的模塊的本地范圍內(nèi)使用

32、引用與指針有什么區(qū)別？

1）引用必須被初始化，指針不必。

2）引用初始化以后不能被改變，指針可以改變所指的對象。

3）不存在指向空值的引用，但是存在指向空值的指針。

32、Internet采用哪種網(wǎng)絡協(xié)議？該協(xié)議的主要層次結(jié)構(gòu)？Internet物理地址和IP

地址轉(zhuǎn)換采用什么協(xié)議？

TCP/IP協(xié)議主要層次結(jié)構(gòu)為：應用層/傳輸層/網(wǎng)絡層/數(shù)鏈路層。

ARP（AddressResolutionProtocol）（地據(jù)址解析協(xié)議）

3、說說你對集成測試中自頂向下集成和自底向上集成兩個策略的理解,

要談出它們各自的優(yōu)缺點和主要適應于哪種類型測試；

自頂向下集成

優(yōu)點：較早地驗證了主要控制和判斷點；按深度優(yōu)先可以首先實現(xiàn)和驗

證一個完整的軟件功能；功能較早證實，帶來信心；只需一個驅(qū)動，減

少驅(qū)動器開發(fā)的費用；支持故障隔離。

缺點：柱的開發(fā)量大；底層驗證被推遲；底層組件測試不充分。

適應于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較小；底層接口未

定義或經(jīng)?？赡鼙恍薷模划a(chǎn)口控制組件具有較大的技術風險，需要盡早

被驗證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

2、自底向上集成

優(yōu)點：對底層組件行為較早驗證；工作最初可以并行集成，比自頂向下

效率高；減少了樁的工作量；支持故障隔離。

缺點：驅(qū)動的開發(fā)工作量大；對高層的驗證被推遲，設計上的錯誤不能

被及時發(fā)現(xiàn)。

適應于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完

成。

33、軟件驗收測試包括正式驗收測試、alpha測試、beta測試三種測試。

34、系統(tǒng)測試的策略有很多種的，有性能測試、負載測試、強度測試、易用性測試、安

全測試、配置測試、安裝測試、文檔測試、故障恢復測試、用戶界面測試、恢復測試、

分布測試、可用性測試。

35、設計系統(tǒng)測試計劃需要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計

劃

36.通過畫因果圖來寫測試用例的步驟為_、_、_、_及把因果圖轉(zhuǎn)換為狀態(tài)圖

共五個步驟。利用因果圖生成測試用例的基本步驟是：

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

價類），哪些是結(jié)果（即輸出條件），并給每個原因和結(jié)果賦予一個標

識符。

§分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因

之間對應的是什么關系？根據(jù)這些關系，畫出因果圖。

§由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合

情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約

束或限制條件?！彀岩蚬麍D轉(zhuǎn)換成判定表。

§把判定表的每一列拿出來作為依據(jù)，設計測試用例。

37、請說出這些測試最好由那些人員完成，測試的是什么？

代碼、函數(shù)級測試一般由白盒測試人員完成，他們針對每段代碼或函數(shù)

進行正確性檢驗，檢查其是否正確的實現(xiàn)了規(guī)定的功能。

模塊、組件級測試主要依據(jù)是程序結(jié)構(gòu)設計測試模塊間的集成和調(diào)用關

系，一般由測試人員完成。

系統(tǒng)測試在于模塊測試與單元測試的基礎上進行測試。了解系統(tǒng)功能與

性能，根據(jù)測試用例進行全面的測試。

38、設計測試用例時應該考慮哪些方面，即不同的測試用例針對那些方面進行測試？

設計測試用例時需要注意的是，除了對整體流程及功能注意外，還要注

意強度測試、性能測試、壓力測試、邊界值測試、穩(wěn)定性測試、安全性

測試等多方面。（測試用例需要考慮的四個基本要素是輸入、輸出、操

作和測試環(huán)境；另外，測試用例需要考慮的是測試類型（功能、性能、

安全……）,這部分可以參照TP做答。此外，還需要考慮用例的重要

性和優(yōu)先級）

39、在windows下保存一個文本文件時會彈出保存對話框，如果為文件名建立測試

用例，等價類應該怎樣劃分？

單字節(jié)，如A；雙字節(jié)，AA、我我；特殊字符/；'；、=-等；保

留字，如com;文件格式為8.3格式的;文件名格式為非8.3格式的;

/,、*等九個特殊字符。

40、假設有一個文本框要求輸入10個字符的郵政編碼，對于該文本框應該怎樣劃分等

價類？

特殊字符，如10個*或￥;英文字母，如ABCDefghik;小于十個字符，

如123;大于十個字符，如11111111111；數(shù)字和其他混合，如

123AAAAAAA;空字符"呆留字符

41.軟件測試項目從什么時候開始，？為什么？

軟件測試應該在需求分析階段就介入，因為測試的對象不僅僅是程序編

碼，應該對軟件開發(fā)過程中產(chǎn)生的所有產(chǎn)品都測試，并且軟件缺陷存在放

大趨勢.缺陷發(fā)現(xiàn)的越晚，修復它所花費的成本就越大.

42、什么是回歸測試？

回歸測試：(regressiontesting):回歸測試有兩類：用例回歸和錯誤回

歸；用例回歸是過一段時間以后再回頭對以前使用過的用例在重新進行

測試，看看會重新發(fā)現(xiàn)問題。錯誤回歸，就是在新版本中，對以前版本

中出現(xiàn)并修復的缺陷進行再次驗證，并以缺陷為核心,對相關修改的部

分進行測試的方法。

43.單元測試、集成測試、系統(tǒng)測試的側(cè)重點是什么？

單元測試針對的是軟件設計的最小單元--程序模塊（面向過程中是函數(shù)、

過程；面向?qū)ο笾惺穷?。），進行正確性檢驗的測試工作,在于發(fā)現(xiàn)每個

程序模塊內(nèi)部可能存在的差錯.一般有兩個步驟:人工靜態(tài)檢查\動態(tài)執(zhí)

行跟蹤

集成測試針對的是通過了單元測試的各個模塊所集成起來的組件進行

檢驗，其主要內(nèi)容是各個單元模塊之間的接口，以及各個模塊集成后所實

現(xiàn)的功能.

系統(tǒng)測試針對的是集成好的軟件系統(tǒng)作為整個計算機系統(tǒng)的一個元素,

與計算機硬件、外設\某些支持軟件'數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在

一起，要在實際的運行環(huán)境中,對計算機系統(tǒng)進行一系列的集成測試和確

認測試.

44.一個測試工程師應具備那些素質(zhì)？

L責任心2、溝通能力3、團隊合作精神4、耐心、細心、信心5、時

時保持懷疑態(tài)度，并且有缺陷預防的意識6、具備一定的編程經(jīng)驗

45:你所了解的的軟件測試類型都有哪些，簡單介紹一下。

按測試策略分類：L靜態(tài)與動態(tài)測試2、黑盒與白盒測試3、手工和

自動測試4、冒煙測試5、回歸測試；

按測試階段分類：單元測試、集成測試、系統(tǒng)測試；

其他常見測試方法：L功能測試2、性能測試3、壓力測試4、負載

測試5、易用性測試6、安裝測試7、界面測試8、配置測試9、文

檔測試10、兼容性測試口、安全性測試12、恢復測試

46:你認為做好測試計劃工作的關鍵是什么？

明確測試的目標，增強測試計劃的實用性

編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺

陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出

軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能

需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于

使用，生成的測試結(jié)果直觀、準確

堅持〃5W〃規(guī)則，明確內(nèi)容與過程

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

"When（何時做）〃、“Where（在哪里廠、"How（如何做）〃.

利用〃5W〃規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團隊理解測試的目

的（Why）,明確測試的范圍和內(nèi)容（What）,確定測試的開始和結(jié)

束日期（When）,指出測試的方法和工具（How），給出測試文檔和

軟件的存放位置（Where）。

采用評審和更新機制，保證測試計劃滿足實際需求

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

計劃內(nèi)容的可能不準確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范

圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導測試執(zhí)行人員。

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

應把詳細的測試技術指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把用于

指導測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔

或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細規(guī)格、測試用例之間是

戰(zhàn)略和戰(zhàn)術的關系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法

和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務的具體戰(zhàn)術。

47:您認為做好測試用例設計工作的關犍是什么？

白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏

輯結(jié)果

黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接

□o不可能做到完全測試,以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問

題

48:你的測試職業(yè)發(fā)展目標是什么？

測試經(jīng)驗越多，測試能力越高。所以我的職業(yè)發(fā)展是需要時間累積的,

一步步向著高級測試工程師奔去。而且我也有初步的職業(yè)規(guī)劃，前3年

累積測試經(jīng)驗，不斷的更新自己改正自己，做好測試任務。

49:測試結(jié)束的標準是什么？

從微觀上來說，在測試計劃中定義，比如系統(tǒng)在一定性能下平穩(wěn)運行

72小時，目前BugTrackingSystem中，本版本中沒有一般嚴重的

BUG,普通BUG的數(shù)量在3以下,BUG修復率90%以上等等參數(shù),

然后由開發(fā)經(jīng)理，測試經(jīng)理，項目經(jīng)理共同簽字認同版本Release.

如果說宏觀的，則是當這個軟件徹底的消失以后，測試就結(jié)束了。

50、一套完整的測試應該由哪些階段組成？

可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、集成

測試、系統(tǒng)測試、驗收測試

51、您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請試述一個完整的開發(fā)

過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？您在以往的測試工

作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？

開發(fā)過程---需求調(diào)研（需求人員）、需求分析（需求人員）、概要設

計（設計人員）、詳細設計（設計人員）、編碼（開發(fā)人員）

測試過程一-需求評審、系統(tǒng)測試設計、概要設計評審、集成測試設計、

詳細設計評審、單元測試設計、測試執(zhí)行

測試工作的整個過程都做過，擅長做測試設計

過程決定質(zhì)量，軟件的過程改進正是為了提高軟件的質(zhì)量，將過往的種

種經(jīng)驗教訓積累起來。

52、測試用例設計的原則是什么？目前主要的測試用例設計方法有哪些？

代表性：能夠代表并覆蓋各種合理的和不合理、合法的和非法的、邊界

的和越界的、以及極限的輸入數(shù)據(jù)、操作和環(huán)境設置等.

可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的，每一個測試用例都應

有相應的期望結(jié)果.

可再現(xiàn)性：即對同樣的測試用例，系統(tǒng)的執(zhí)行結(jié)果應當是相同的。

方法有等價類、邊界值、因果圖、狀態(tài)圖、正交法、大綱法

53、面向?qū)ο蟮臏y試用例設計有幾種方法？如何實現(xiàn)？

給類中的每個構(gòu)造函數(shù)設計一組測試用例

組合類中的類變量、實例變量

組合類中的各種方法

根據(jù)前置條件和后置條件設計測試用例

根據(jù)代碼設計測試用例

54、LoadRunner分為哪三個模塊？請簡述各模塊的主要功能。

VirtualUserGenerator:用于錄制腳步

MercuryLoadRunnerController:用于創(chuàng)建、運行和監(jiān)控場景

MercuryLoadRunnerAnalysis:用于分析測試結(jié)果

55、你對測試最大的興趣在哪里？為什么？

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

試有多難。曾經(jīng)在無憂測試網(wǎng)上看到一篇文章，是關于如何做好一名測

試工程師。一共羅列了11,12點，有部分是和人的性格有關，有部分

需要后天的努力。但除了性格有關的1,2點我沒有把握，其他點我都

很有信心做好它。

剛開始進入測試行業(yè)時，對測試的認識是從無憂測試網(wǎng)上了解到的一些

資料，當時是沖著做測試需要很多技能才能做的好，雖然入門容易，但

做好很難，比開發(fā)更難，雖然當時我很想做開發(fā)（學校專業(yè)課我基本上

不缺席，因為我喜歡我的專業(yè)），但看到測試比開發(fā)更難更有挑戰(zhàn)性,

想做好測試的意志就更堅定了。

我覺得做測試整個過程中有2點讓我覺得很有難度（對我來說，有難度

的東西我就非常感興趣）,第一是測試用例的設計，因為測試的精華就

在測試用例的設計上了，要在版本出來之前，把用例寫好，用什么測試

方法寫？（也就是測試計劃或測試策略），如果你剛測試一個新任務時，

你得花一定的時間去消化業(yè)務需求和技術基礎，業(yè)務需求很好理解（多

和產(chǎn)品經(jīng)理和開發(fā)人員溝通就能達到目的），而技術基礎可就沒那么簡

單了，這需要你自覺的學習能力，比如說網(wǎng)站吧，最基本的技術知識你

要知道網(wǎng)站內(nèi)部是怎么運作的的，后臺是怎么響應用戶請求的？測試環(huán)

境如何搭建？這些都需要最早的學好。至少在開始測試之前能做好基本

的準備，可能會遇到什么難題？需求細節(jié)是不是沒有確定好？這些問題

都能在設計用例的時候發(fā)現(xiàn)。

第二是發(fā)現(xiàn)BUG的時候了，這應該是測試人員最基本的任務了，一般

按測試用例開始測試就能發(fā)現(xiàn)大部分的bug,還有一部分bug需要測

試的過程中更了解所測版本的情況獲得更多信息，補充測試用例，測試

出bug。還有如何發(fā)現(xiàn)bug?這就需要在測試用例有效的情況下,通

過細心和耐心去發(fā)現(xiàn)bug了，每個用例都有可能發(fā)現(xiàn)bug,每個地方

都有可能出錯，所以測試過程中思維要清晰（測試過程數(shù)據(jù)流及結(jié)果都

得看仔細了,bug都在里面發(fā)現(xiàn)的）。如何描述bug也很有講究,bug

在什么情況下會產(chǎn)生，如果條件變化一點點，就不會有這個bug,以哪

些最少的操作步驟就能重現(xiàn)這個bug,這個bug產(chǎn)生的規(guī)律是什么？

如果你夠厲害的話，可以幫開發(fā)人員初步定位問題。

56、您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同的測試類型的區(qū)別與

聯(lián)系（如功能測試、性能測試……）

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

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

把測試對象看作一個黑盒子。利用黑盒測試法進行動態(tài)測試時，需要測

試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑

盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、

因果圖和綜合策略。

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

載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于

性能測試，兩者可以結(jié)合進行。通過負載測試，確定在各種工作負載下

系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化

情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來

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

界面測試，界面是軟件與用戶交互的最直接的層,界面的好壞決定

用戶對軟件的第一印象。而且設計良好的界面能夠引導用戶自己完成相

應的操作，起到向?qū)У淖饔?。同時界面如同人的面孔，具有吸引用戶的

直接優(yōu)勢。設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺,

相反由于界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能

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

區(qū)別在于，功能測試關注產(chǎn)品的所有功能上，要考慮到每個細節(jié)功

能，每個可能存在的功能問題。性能測試主要關注于產(chǎn)品整體的多用戶

并發(fā)下的穩(wěn)定性和健壯性。界面測試更關注于用戶體驗上，用戶使用該

產(chǎn)品的時候是否易用，是否易懂，是否規(guī)范（快捷鍵之類的），是否美

觀（能否吸引用戶的注意力），是否安全（盡量在前臺避免用戶無意輸

入無效的數(shù)據(jù)，當然考慮到的僉性，不能太粗魯?shù)膹棾鼍妫?？做某個

性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問

題的，然后再考慮該功能點的性能測試

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

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

黑盒測試：已知產(chǎn)品的功能設計規(guī)格，可以進行測試證明每個實現(xiàn)

了的功能是否符合要求。

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

操作是否符合設計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。

軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把

測試對象看做一個黑盒子,測試人員完全不考慮程序內(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、是否有初始化或終

止性錯誤？

軟件的白盒測試是對軟件的過程性細節(jié)做細致的檢查。這種方法是

把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯

結(jié)構(gòu)及有關信息,設計或選擇測試用例，對程序所有邏輯路徑進行測試。

通過在不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預期的狀態(tài)一致。因

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

模塊進行如下檢查：

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

2、對所有的邏輯判定，取〃真〃與取〃假〃的兩種情況都能至少測一

遍。

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

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

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

代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試

是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。

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

以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼

編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期

望的一致。

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

的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試

它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。

在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大

部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組

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

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

檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。（常

見的聯(lián)調(diào)測試）

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

系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設計。

驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是

確保軟件準備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能

和任務。

驗收測試是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。經(jīng)集成測

試后，已經(jīng)按照設計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯

誤也已經(jīng)基本排除了，接著就應該進一步驗證軟件的有效性，這就是驗

收測試的任務，即軟件的功能性能如同用戶所合理期待的那樣。

58、當開發(fā)人員說不是BUG時，你如何應付？

開發(fā)人員說不是bug,有2種情況，一是需求沒有確定，所以我可

以這么做，這個時候可以找來產(chǎn)品經(jīng)理進行確認，需不需要改動，3方

商量確定好后再看要不要改。二是這種情況不可能發(fā)生，所以不需要修

改，這個時候，我可以先盡可能的說出是BUG的依據(jù)是什么？如果被

用戶發(fā)現(xiàn)或出了問題，會有什么不良結(jié)果？程序員可能會給你很多理由,

你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出

來，跟開發(fā)經(jīng)理和測試經(jīng)理進行確認，如果要修改就改，如果不要修改就不

改。其實有些真的不是bug,我也只是建議的方式寫進TD中，如果開

發(fā)人員不修改也沒有大問題。