軟件測(cè)試面試時(shí)?？嫉膸椎烂嬖囶}

更新時(shí)間:2019年03月18日14時(shí)23分來源:網(wǎng)絡(luò) 瀏覽次數(shù):

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

1、將問題提交到缺陷管理庫(kù)里面進(jìn)行備案。

2、要獲取判斷的依據(jù)和標(biāo)準(zhǔn)：

根據(jù)需求說明書、產(chǎn)品說明、設(shè)計(jì)文檔等，確認(rèn)實(shí)際結(jié)果是否與計(jì)劃有不一致的地方，提供缺陷是否確認(rèn)的直接依據(jù)；如果沒有文檔依據(jù)，可以根據(jù)類似軟件的一般特性來說明是否存在不一致的地方，來確認(rèn)是否是缺陷；根據(jù)用戶的一般使用習(xí)慣，來確認(rèn)是否是缺陷；3、與設(shè)計(jì)人員、開發(fā)人員和客戶代表等相關(guān)人員探討，確認(rèn)是否是缺陷；4、合理的論述，向測(cè)試經(jīng)理說明自己的判斷的理由，注意客觀、嚴(yán)謹(jǐn)，不參雜個(gè)人情緒。

等待測(cè)試經(jīng)理做出最終決定，如果仍然存在爭(zhēng)議，可以通過公司政策所提供的渠道，向上級(jí)反映，并有上級(jí)做出決定。

問：給你一個(gè)網(wǎng)站，你如何測(cè)試？

1、查找需求說明、網(wǎng)站設(shè)計(jì) m 等相關(guān)文檔，分析測(cè)試需求。

2、制定測(cè)試計(jì)劃，確定測(cè)試范圍和測(cè)試策略，一般包括以下幾個(gè)部分：

功能性測(cè)試；界面測(cè)試；性能測(cè)試；數(shù)據(jù)庫(kù)測(cè)試；安全性測(cè)試；兼容性測(cè)試3、設(shè)計(jì)測(cè)試用例：

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

鏈接測(cè)試。鏈接是否正確跳轉(zhuǎn)，是否存在空頁(yè)面和無效頁(yè)面，是否有不正確的出錯(cuò)信息返回等。提交功能的測(cè)試。

多媒體元素是否可以正確加載和顯示。多語(yǔ)言支持是否能夠正確顯示選擇的語(yǔ)言等。

界面測(cè)試可以包括但不限于一下幾個(gè)方面：

1.頁(yè)面是否風(fēng)格統(tǒng)一，美觀

2.頁(yè)面布局是否合理，重點(diǎn)內(nèi)容和熱點(diǎn)內(nèi)容是否突出
3. 控件是否正常使用

4.對(duì)于必須但為安裝的空間，是否提供自動(dòng)下載并安裝的功能文字檢查性能測(cè)試一般從以下三個(gè)方面考慮：

1. 壓力測(cè)試；負(fù)載測(cè)試；強(qiáng)度測(cè)試數(shù)據(jù)庫(kù)測(cè)試要具體決定是否需要開展。數(shù)據(jù)庫(kù)一般需要考慮連結(jié)性，對(duì)數(shù)據(jù)的存取操作，數(shù)據(jù)內(nèi)容的驗(yàn)證等方面。

2.安全性測(cè)試：

基本的登錄功能的檢查

是否存在溢出錯(cuò)誤，導(dǎo)致系統(tǒng)崩潰或者權(quán)限泄露關(guān)開發(fā)語(yǔ)言的常見安全性問題檢查，例如 SQL 注入等。

如果需要高級(jí)的安全性測(cè)試，確定獲得專業(yè)安全公司的幫助，外包測(cè)試，或者獲取支持兼容性測(cè)試，根據(jù)需求說明的內(nèi)容，確定支持的平臺(tái)組合：

兼容性包括：瀏覽器的兼容性；操作系統(tǒng)的兼容性；軟件平臺(tái)的兼容性；數(shù)據(jù)庫(kù)的兼容性4、開展測(cè)試，并記錄缺陷。合理的安排調(diào)整測(cè)試進(jìn)度，提前獲取測(cè)試所需的資源，建立管理體系（例如，需求變更、風(fēng)險(xiǎn)、配置、測(cè)試文檔、缺陷報(bào)告、人力資源等內(nèi)容）。定期評(píng)審，對(duì)測(cè)試進(jìn)行評(píng)估和總結(jié)，調(diào)整測(cè)試的內(nèi)容。

在搜索引擎中輸入漢字就可以解析到對(duì)應(yīng)的域名，請(qǐng)問如何用 r LoadRunner 進(jìn)行測(cè)試。

建立測(cè)試計(jì)劃，確定測(cè)試標(biāo)準(zhǔn)和測(cè)試范圍

設(shè)計(jì)典型場(chǎng)景的測(cè)試用例，覆蓋常用業(yè)務(wù)流程和不常用的業(yè)務(wù)流程等根據(jù)測(cè)試用例，開發(fā)自動(dòng)測(cè)試腳本和場(chǎng)景：

錄制測(cè)試腳本

新建一個(gè)腳本（Web/HTML 協(xié)議）

點(diǎn)擊錄制按鈕，在彈出的對(duì)話框的 URL 中輸入”about:blank”。

在打開的瀏覽器中進(jìn)行正常操作流程后，結(jié)束錄制。

調(diào)試腳本并保存?？赡芤⒁獾阶址年P(guān)聯(lián)。

設(shè)置測(cè)試場(chǎng)景

針對(duì)性能設(shè)置測(cè)試場(chǎng)景，主要判斷在正常情況下，系統(tǒng)的平均事務(wù)響應(yīng)時(shí)間是否達(dá)標(biāo)針對(duì)壓力負(fù)載設(shè)置測(cè)試場(chǎng)景，主要判斷在長(zhǎng)時(shí)間處于滿負(fù)荷或者超出系統(tǒng)承載能力的條件下，系統(tǒng)是否會(huì)崩潰。

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

問：一臺(tái)客戶端有三百個(gè)客戶與三百個(gè)客戶端有三百個(gè)客戶對(duì)服務(wù)器施壓，有什么區(qū)別? ?

300 個(gè)用戶在一個(gè)客戶端上，會(huì)占用客戶機(jī)更多的資源，而影響測(cè)試的結(jié)果。

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

300 個(gè)用戶在一個(gè)客戶端上，需要更大的帶寬。

IP 地址的問題，可能需要使用 IP Spoof 來繞過服務(wù)器對(duì)于單一 IP 地址最大連接數(shù)的限制。

所有用戶在一個(gè)客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調(diào)配不同客戶機(jī)上的用戶。同時(shí)，還需要給予相應(yīng)的權(quán)限配置和防火墻設(shè)置。

問：試述軟件的概念和特點(diǎn)？軟件復(fù)用的含義？構(gòu)件包括哪些？

軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，它是包括程序、文檔的完整集合。

軟件復(fù)用(Software Reuse)是將已有軟件的各種有關(guān)知識(shí)用于建立新的軟件,以縮減軟件開發(fā)和維護(hù)的花費(fèi)。軟件復(fù)用是提高軟件生產(chǎn)力和質(zhì)量的一種重要技術(shù)。早期的軟件復(fù)用主要是代碼級(jí)復(fù)用，被復(fù)用的知識(shí)專指程序，后來擴(kuò)大到包括領(lǐng)域知識(shí)、開發(fā)經(jīng)驗(yàn)、設(shè)計(jì)決定、體系結(jié)構(gòu)、需求、設(shè)計(jì)、代碼和文檔等一切有關(guān)方面。

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

問：軟件生存周期及其模型是什么？

軟件生存周期是軟件開發(fā)全部過程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架，是從可行性研究到需求分析、軟件設(shè)計(jì)、編碼、測(cè)試、軟件發(fā)布維護(hù)的過程。

在經(jīng)歷需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、部署后，軟件將被使用并進(jìn)入維護(hù)階段，直到最后由于缺少維護(hù)費(fèi)用而逐漸消亡。這樣的一個(gè)過程，稱為"生命周期模型"（Life Cycle Model）。

什么是軟件測(cè)試？軟件測(cè)試的目的與原則

使用人工或自動(dòng)手段，來運(yùn)行或測(cè)試某個(gè)系統(tǒng)的過程。其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。

軟件測(cè)試的目的：

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

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

一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試

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

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

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

軟件測(cè)試的原則：

教材的說法：

軟件測(cè)試應(yīng)盡早執(zhí)行，并貫穿于整個(gè)軟件生命周期

軟件測(cè)試應(yīng)追溯需求

測(cè)試應(yīng)由第三方來構(gòu)造

窮舉測(cè)試是不可能的,要遵循 Good-enough 原則

必須確定預(yù)期輸出（或結(jié)果）

必須徹底檢查每個(gè)測(cè)試結(jié)果

充分注意測(cè)試中的群集現(xiàn)象

缺陷的二八定理

嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè)試的隨意性

注意合法合理的輸入，也要注意非法的非預(yù)期的輸入檢查程序是否做了不該做的測(cè)試應(yīng)從“小規(guī)模”開始，逐步轉(zhuǎn)向“大規(guī)模”

反復(fù)使用同樣的測(cè)試會(huì)使軟件具有抵抗力

關(guān)注缺陷的修復(fù)

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

軟件配置管理作為軟件開發(fā)過程的必要環(huán)節(jié)和軟件開發(fā)管理的基礎(chǔ)，貫穿整個(gè)軟件生命周期，同時(shí)對(duì)軟件開發(fā)過程的宏觀管理即項(xiàng)目管理也有重要的支持作用。一個(gè)軟件開發(fā)組織真正有效的實(shí)施軟件配置管理，將會(huì)使軟件開發(fā)過程有更好的可預(yù)測(cè)性，使系統(tǒng)具有可重復(fù)性，大大提高軟件組織的競(jìng)爭(zhēng)力。

軟件配置包括如下內(nèi)容：

配置項(xiàng)識(shí)別

工作空間管理

版本控制

變更控制

狀態(tài)報(bào)告

配置審計(jì)

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

軟件質(zhì)量：軟件產(chǎn)品的特性可以滿足用戶的功能、性能需求的能力。

目前主要的測(cè)試用例設(shè)計(jì)方法是什么？

白盒測(cè)試：

邏輯覆蓋

循環(huán)覆蓋

基本路徑覆蓋

黑盒測(cè)試：

邊界值分析法

等價(jià)類劃分

錯(cuò)誤猜測(cè)法

因果圖法

狀態(tài)圖法

測(cè)試大綱法

隨機(jī)測(cè)試

場(chǎng)景法

軟件的安全性應(yīng)從哪幾個(gè)方面去測(cè)試？

軟件安全性測(cè)試包括程序、數(shù)據(jù)庫(kù)安全性測(cè)試。根據(jù)系統(tǒng)安全指標(biāo)不同測(cè)試策略也不同。

用戶認(rèn)證安全的測(cè)試要考慮問題：

明確區(qū)分系統(tǒng)中不同用戶權(quán)限

系統(tǒng)中會(huì)不會(huì)出現(xiàn)用戶沖突

系統(tǒng)會(huì)不會(huì)因用戶的權(quán)限的改變?cè)斐苫靵y

用戶登陸密碼是否是可見、可復(fù)制

是否可以通過絕對(duì)途徑登陸系統(tǒng)（拷貝用戶登陸后的鏈接直接進(jìn)入系統(tǒng)）用戶退出系統(tǒng)后是否刪除了所有鑒權(quán)標(biāo)記，是否可以使用后退鍵而不通過輸入口令進(jìn)入系統(tǒng)系統(tǒng)網(wǎng)絡(luò)安全的測(cè)試要考慮問題測(cè)試采取的防護(hù)措施是否正確裝配好，有關(guān)系統(tǒng)的補(bǔ)丁是否打上模擬非授權(quán)攻擊，看防護(hù)系統(tǒng)是否堅(jiān)固采用成熟的網(wǎng)絡(luò)漏洞檢查工具檢查系統(tǒng)相關(guān)漏洞（即用最專業(yè)的黑客攻擊工具攻擊試一下，現(xiàn)在最常用的是 NBSI 系列和 IPhacker IP ）采用各種木馬檢查工具檢查系統(tǒng)木馬情況

采用各種防外掛工具檢查系統(tǒng)各組程序的外掛漏洞

數(shù)據(jù)庫(kù)安全考慮問題：

系統(tǒng)數(shù)據(jù)是否機(jī)密（比如對(duì)銀行系統(tǒng)，這一點(diǎn)就特別重要，一般的網(wǎng)站就沒有太高要求）系統(tǒng)數(shù)據(jù)的完整性（我剛剛結(jié)束的企業(yè)實(shí)名核查服務(wù)系統(tǒng)中就曾存在數(shù)據(jù)的不完整，對(duì)于這個(gè)系統(tǒng)的功能實(shí)現(xiàn)有了障礙）系統(tǒng)數(shù)據(jù)可管理性

系統(tǒng)數(shù)據(jù)的獨(dú)立性

系統(tǒng)數(shù)據(jù)可備份和恢復(fù)能力（數(shù)據(jù)備份是否完整，可否恢復(fù)，恢復(fù)是否可以完整）什么是測(cè)試用例什么是測(cè)試腳本兩者的關(guān)系是什么？

為實(shí)施測(cè)試而向被測(cè)試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置以及期望結(jié)果的一個(gè)特定的集合。

測(cè)試腳本是為了進(jìn)行自動(dòng)化測(cè)試而編寫的腳本。

測(cè)試腳本的編寫必須對(duì)應(yīng)相應(yīng)的測(cè)試用例，

簡(jiǎn)述什么是靜態(tài)測(cè)試、動(dòng)態(tài)測(cè)試、黑盒測(cè)試、白盒測(cè)試、α測(cè)試 β測(cè)試靜態(tài)測(cè)試是不運(yùn)行程序本身而尋找程序代碼中可能存在的錯(cuò)誤或評(píng)估程序代碼的過程。

動(dòng)態(tài)測(cè)試是實(shí)際運(yùn)行被測(cè)程序，輸入相應(yīng)的測(cè)試實(shí)例，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，判定執(zhí)行結(jié)果是否符合要求，從而檢驗(yàn)程序的正確性、可靠性和有效性，并分析系統(tǒng)運(yùn)行效率和健壯性等性能。

黑盒測(cè)試一般用來確認(rèn)軟件功能的正確性和可操作性,目的是檢測(cè)軟件的各個(gè)功能是否能得以實(shí)現(xiàn),把被測(cè)試的程序當(dāng)作一個(gè)黑盒,不考慮其內(nèi)部結(jié)構(gòu),在知道該程序的輸入和輸出之間的關(guān)系或程序功能的情況下,依靠軟件規(guī)格說明書來確定測(cè)試用例和推斷測(cè)試結(jié)果的正確性。

白盒測(cè)試根據(jù)軟件內(nèi)部的邏輯結(jié)構(gòu)分析來進(jìn)行測(cè)試,是基于代碼的測(cè)試，測(cè)試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調(diào)試來判斷軟件的質(zhì)量，一般黑盒測(cè)試由項(xiàng)目經(jīng)理在程序員開發(fā)中來實(shí)現(xiàn)。

α測(cè)試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測(cè)試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測(cè)試，Alpha 測(cè)試不能由程序員或測(cè)試員完成。

β測(cè)試是軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測(cè)試。開發(fā)者通常不在測(cè)試現(xiàn)場(chǎng)，Beta 測(cè)試不能由程序員或測(cè)試員完成。

軟件質(zhì)量保證體系是什么國(guó)家標(biāo)準(zhǔn)中與質(zhì)量保證管理相關(guān)的幾個(gè)標(biāo)準(zhǔn)是什么? ? 他們的編號(hào)和全稱是什么? ?

SQA 由一套軟件工程過程和方法組成，以保證（軟件的）質(zhì)量。SQA 貫穿整個(gè)軟件開發(fā)過程，(它)應(yīng)包括需求文檔評(píng)審、代碼控制、代碼評(píng)審、變更管理、配置管理、版本管理和軟件測(cè)試。

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

功能性：適應(yīng)性、準(zhǔn)確性、互操作性、依從性、安全性。

可靠性：成熟性、容錯(cuò)性、以恢復(fù)性。

可使用性：易理解性、易學(xué)習(xí)性、易操作性。

效率：時(shí)間特性、資源特性。

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

可移植性：適應(yīng)性、易安裝性、遵循性、易替換性。

軟件測(cè)試的策略是什么? ?

軟件測(cè)試策略：在一定的軟件測(cè)試標(biāo)準(zhǔn)、測(cè)試規(guī)范的指導(dǎo)下，依據(jù)測(cè)試項(xiàng)目的特定環(huán)境約束而規(guī)定的軟件測(cè)試的原則、方式、方法的集合。

軟件測(cè)試分為幾個(gè) 階段各階段的測(cè)試策略和要求是什么? ?

軟件測(cè)試按階段劃分可以分為單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和<驗(yàn)收測(cè)試>（不一定有）幾個(gè)階段單元測(cè)試測(cè)試策略：

自頂向下的單元測(cè)試策略

總結(jié)：比孤立單元測(cè)試的成本高很多，不是單元測(cè)試的一個(gè)好的選擇。

自底向上的單元測(cè)試策略

總結(jié)：比較合理的單元測(cè)試策略，但測(cè)試周期較長(zhǎng)。

孤立單元測(cè)試策略

總結(jié)：最好的單元測(cè)試策略。

集成測(cè)試的測(cè)試策略：

大爆炸集成

適應(yīng)于一個(gè)維護(hù)型項(xiàng)目或被測(cè)試系統(tǒng)較小

自頂向下集成

適應(yīng)于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較??；底層接口未定義或經(jīng)常可能被修改；產(chǎn)口控制組件具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

自底向上集成

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

基于進(jìn)度的集成

優(yōu)點(diǎn)：具有較高的并行度；能夠有效縮短項(xiàng)目的開發(fā)進(jìn)度。

缺點(diǎn)：樁和驅(qū)動(dòng)工作量較大；有些接口測(cè)試不充分；有些測(cè)試重復(fù)和浪費(fèi)。

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

數(shù)據(jù)和數(shù)據(jù)庫(kù)完整性測(cè)試；功能測(cè)試；用戶界面測(cè)試；性能評(píng)測(cè)；負(fù)載測(cè)試；強(qiáng)度測(cè)試；容量測(cè)試；安全性和訪問控制測(cè)試；故障轉(zhuǎn)移和恢復(fù)測(cè)試；配置測(cè)試；安裝測(cè)試；加密測(cè)試；可用性測(cè)試；版本驗(yàn)證測(cè)試；文檔測(cè)試在軟件測(cè)試各個(gè)階段通常完成什么工作？各個(gè)階段的結(jié)果文件是什么？包括什么內(nèi)容？

單元測(cè)試階段。各獨(dú)立單元模塊在與系統(tǒng)地其他部分相隔離的情況下進(jìn)行測(cè)試，單元測(cè)試針對(duì)每一個(gè)程序模塊進(jìn)行正確性校驗(yàn)，檢查各個(gè)程序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能。生成單元測(cè)試報(bào)告，提交缺陷報(bào)告。

集成測(cè)試階段。集成測(cè)試是在單元測(cè)試的基礎(chǔ)上，測(cè)試在將所有的軟件單元按照概要設(shè)計(jì)規(guī)格說明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過程中各部分工作是否達(dá)到或?qū)崿F(xiàn)相應(yīng)技術(shù)指標(biāo)及要求的活動(dòng)。該階段生成集成測(cè)試報(bào)告，提交缺陷報(bào)告。

系統(tǒng)測(cè)試階段。將通過確認(rèn)測(cè)試的軟件，作為整個(gè)給予計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行全面的功能覆蓋。該階段需要提交測(cè)試總結(jié)和缺陷報(bào)告。

測(cè)試人員在軟件開發(fā)過程中的任務(wù)是什么？

1、尋找 Bug；

2、避免軟件開發(fā)過程中的缺陷；

3、衡量軟件的品質(zhì)；

4、關(guān)注用戶的需求。

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

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

一條 Bug 記錄最基本應(yīng)包含：編號(hào)、Bug 所屬模塊、Bug 描述、Bug 級(jí)別、發(fā)現(xiàn)日期、發(fā)現(xiàn)人、修改日期、修改人、修改方法、回歸結(jié)果等等；要有效的發(fā)現(xiàn) Bug 需參考需求以及詳細(xì)設(shè)計(jì)等前期文檔設(shè)計(jì)出高效的測(cè)試用例，然后嚴(yán)格執(zhí)行測(cè)試用例，對(duì)發(fā)現(xiàn)的問題要充分確認(rèn)肯定，然后再向外發(fā)布如此才能提高提交 Bug 的質(zhì)量。

黑盒測(cè)試和白盒測(cè)試是軟件測(cè)試的兩種基本方法，請(qǐng)分別說明各自的優(yōu)點(diǎn)和缺點(diǎn)！

黑盒測(cè)試的優(yōu)點(diǎn)有：

比較簡(jiǎn)單，不需要了解程序內(nèi)部的代碼及實(shí)現(xiàn)；

與軟件的內(nèi)部實(shí)現(xiàn)無關(guān)；

從用戶角度出發(fā)，能很容易的知道用戶會(huì)用到哪些功能，會(huì)遇到哪些問題；基于軟件開發(fā)文檔，所以也能知道軟件實(shí)現(xiàn)了文檔中的哪些功能；在做軟件自動(dòng)化測(cè)試時(shí)較為方便。

黑盒測(cè)試的缺點(diǎn)有：

不可能覆蓋所有的代碼，覆蓋率較低，大概只能達(dá)到總代碼量的 30%；自動(dòng)化測(cè)試的復(fù)用性較低。

白盒測(cè)試的優(yōu)點(diǎn)有：

幫助軟件測(cè)試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題。

白盒測(cè)試的缺點(diǎn)有：

程序運(yùn)行會(huì)有很多不同的路徑，不可能測(cè)試所有的運(yùn)行路徑；測(cè)試基于代碼，只能測(cè)試開發(fā)人員做的對(duì)不對(duì)，而不能知道設(shè)計(jì)的正確與否，可能會(huì)漏掉一些功能需求；系統(tǒng)龐大時(shí)，測(cè)試開銷會(huì)非常大。

如何測(cè)試一個(gè) 紙杯？

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

安全性：杯子有沒有毒或細(xì)菌

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

可移植性：杯子在不同的地方、溫度等環(huán)境下是否都可以正常使用兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等易用性：杯子是否燙手、是否有防滑措施、是否方便飲用用戶文檔：使用手冊(cè)是否對(duì)杯子的用法、限制、使用條件等有詳細(xì)描述疲勞測(cè)試：將杯子盛上水（案例一）放 24 小時(shí)檢查泄漏時(shí)間和情況；盛上汽油（案例二）放 24 小時(shí)檢查泄漏時(shí)間和情況等壓力測(cè)試：用根針并在針上面不斷加重量，看壓強(qiáng)多大時(shí)會(huì)穿透測(cè)試計(jì)劃工作的目的是什么？測(cè)試計(jì)劃文檔的內(nèi)容應(yīng)該包括什么？其中哪些是最重要的？

答案：軟件測(cè)試計(jì)劃是指導(dǎo)測(cè)試過程的綱領(lǐng)性文件。

包含了產(chǎn)品概述、測(cè)試策略、測(cè)試方法、測(cè)試區(qū)域、測(cè)試配置、測(cè)試周期、測(cè)試資源、測(cè)試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測(cè)試計(jì)劃，參與測(cè)試的項(xiàng)目成員，尤其是測(cè)試管理人員，可以明確測(cè)試任務(wù)和測(cè)試方法，保持測(cè)試實(shí)施過程的順暢溝通，跟蹤和控制測(cè)試進(jìn)度，應(yīng)對(duì)測(cè)試過程中的各種變更。

測(cè)試計(jì)劃和測(cè)試詳細(xì)規(guī)格、測(cè)試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測(cè)試計(jì)劃主要從宏觀上規(guī)劃測(cè)試活動(dòng)的范圍、方法和資源配置，而測(cè)試詳細(xì)規(guī)格、測(cè)試用例是完成測(cè)試任務(wù)的具體戰(zhàn)術(shù)。

所以其中最重要的是測(cè)試測(cè)試策略和測(cè)試方法（最好是能先評(píng)審）。

黑盒測(cè)試的測(cè)試用例常見設(shè)計(jì)方法都有哪些？請(qǐng)分別以具體的例子來說明這些方法在測(cè)試用例設(shè)計(jì)工作中的應(yīng)用。

等價(jià)類劃分

劃分等價(jià)類: 等價(jià)類是指某個(gè)輸入域的子集合.在該子集合中,各個(gè)輸入數(shù)據(jù)對(duì)于揭露程序中的錯(cuò)誤都是等效的.并合理地假定:測(cè)試某等價(jià)類的代表值就等于對(duì)這一類其它值的測(cè)試.

因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價(jià)類,在每一個(gè)等價(jià)類中取一個(gè)數(shù)據(jù)作為測(cè)試的輸入條件,就可以用少量代表性的測(cè)試數(shù)據(jù).取得較好的測(cè)試結(jié)果.等價(jià)類劃分可有兩種不同的情況:有效等價(jià)類和無效等價(jià)類.

2）邊界值分析法

邊界值分析方法是對(duì)等價(jià)類劃分方法的補(bǔ)充。測(cè)試工作經(jīng)驗(yàn)告訴我,大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對(duì)各種邊界情況設(shè)計(jì)測(cè)試用例,可以查出更多的錯(cuò)誤.

使用邊界值分析方法設(shè)計(jì)測(cè)試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價(jià)類的邊界,就是應(yīng)著重測(cè)試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測(cè)試數(shù)據(jù),而不是選取等價(jià)類中的典型值或任意值作為測(cè)試數(shù)據(jù).

3）錯(cuò)誤猜測(cè)法

基于經(jīng)驗(yàn)和直覺推測(cè)程序中所有可能存在的各種錯(cuò)誤, 從而有針對(duì)性的設(shè)計(jì)測(cè)試用例的方法.

錯(cuò)誤推測(cè)方法的基本思想: 列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況,根據(jù)他們選擇測(cè)試用例. 例如, 在單元測(cè)試時(shí)曾列出的許多在模塊中常見的錯(cuò)誤. 以前產(chǎn)品測(cè)試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等, 這些就是經(jīng)驗(yàn)的總結(jié). 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為 0 的情況.

輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯(cuò)誤的情況. 可選擇這些情況下的例子作為測(cè)試用例.

4）因果圖方法

前面介紹的等價(jià)類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會(huì)產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價(jià)類,他們之間的組合情況也相當(dāng)多. 因此必須考慮采用一種適合于描述對(duì)于多種條件的組合,相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來考慮設(shè)計(jì)測(cè)試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

5）正交表分析法

有時(shí)候，可能因?yàn)榇罅康膮?shù)的組合而引起測(cè)試用例數(shù)量上的激增，同時(shí)，這些測(cè)試用例并沒有明顯的優(yōu)先級(jí)上的差距，而測(cè)試人員又無法完成這么多數(shù)量的測(cè)試，就可以通過正交表來進(jìn)行縮減一些用例，從而達(dá)到盡量少的用例覆蓋盡量大的范圍的可能性。

6）場(chǎng)景分析方法

指根據(jù)用戶場(chǎng)景來模擬用戶的操作步驟，這個(gè)比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。

7）狀態(tài)圖法

通過輸入條件和系統(tǒng)需求說明得到被測(cè)系統(tǒng)的所有狀態(tài)，通過輸入條件和狀態(tài)得出輸出條件；通過輸入條件、輸出條件和狀態(tài)得出被測(cè)系統(tǒng)的測(cè)試用例。

8）大綱法

大綱法是一種著眼于需求的方法，為了列出各種測(cè)試條件，就將需求轉(zhuǎn)換為大綱的形式。大綱表示為樹狀結(jié)構(gòu)，在根和每個(gè)葉子結(jié)點(diǎn)之間存在唯一的路徑。大綱中的每條路徑定義了一個(gè)特定的輸入條件集合，用于定義測(cè)試用例。樹中葉子的數(shù)目或大綱中的路徑給出了測(cè)試所有功能所需測(cè)試用例的大致數(shù)量。

詳細(xì)的描述一個(gè)測(cè)試活動(dòng)完整的過程。

答案：（供參考，本答案主要是瀑布模型的做法）

項(xiàng)目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測(cè)試人員共同完成需求文檔的評(píng)審，評(píng)審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實(shí)現(xiàn)的功能的地方。

項(xiàng)目經(jīng)理通過綜合開發(fā)人員，測(cè)試人員以及客戶的意見，完成項(xiàng)目計(jì)劃。然后 SQA 進(jìn)入項(xiàng)目，開始進(jìn)行統(tǒng)計(jì)和跟蹤開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測(cè)試人員進(jìn)行評(píng)審，評(píng)審的主要內(nèi)容包括是否有遺漏或者雙方理解不同的地方。測(cè)試人員完成測(cè)試計(jì)劃文檔，測(cè)試計(jì)劃包括的內(nèi)容上面有描述。

測(cè)試人員根據(jù)修改好的需求分析文檔開始寫測(cè)試用例，同時(shí)開發(fā)人員完成概要設(shè)計(jì)文檔，詳細(xì)設(shè)計(jì)文檔。此兩份文檔成為測(cè)試人員撰寫測(cè)試用例的補(bǔ)充材料。

測(cè)試用例完成后，測(cè)試和開發(fā)需要進(jìn)行評(píng)審。

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

開發(fā)人員提交第一個(gè)版本，可能存在未完成功能，需要說明。測(cè)試人員進(jìn)行測(cè)試，發(fā)現(xiàn) BUG后提交給 BugZilla。

開發(fā)提交第二個(gè)版本，包括 Bug Fix 以及增加了部分功能，測(cè)試人員進(jìn)行測(cè)試。

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

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

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

在傳統(tǒng)的 BugZilla 中，BUG 描述應(yīng)該包括以下的信息和 BUG 產(chǎn)生對(duì)應(yīng)的軟件版本和模塊開發(fā)的接口人員

BUG 的優(yōu)先級(jí)

BUG 的嚴(yán)重程度

BUG 可能屬于的模塊，如果不能確認(rèn)，可以用開發(fā)人員來判斷BUG 標(biāo)題，需要清晰的描述現(xiàn)象BUG 描述，需要盡量給出重新 Bug 的步驟

BUG 附件中能給出相關(guān)的日志和截圖。

高質(zhì)量的 BUG 記錄就是指很容易理解的 BUG 記錄，所以，對(duì)于描述的要求高，能提供的信息多且準(zhǔn)確，很好的幫助開發(fā)人員定位，因此提交高質(zhì)量的軟件缺陷記錄需要注意對(duì) BUG 記錄的描述質(zhì)量多且準(zhǔn)確。

G BUG 管理工具的跟蹤過程

用 BugZilla 為例子

測(cè)試人員發(fā)現(xiàn)了 BUG，提交到 Bugzilla 中，狀態(tài)為 new，BUG 的接受者為開發(fā)接口人員開發(fā)接口將 BUG 分配給相關(guān)的模塊的開發(fā)人員，狀態(tài)修改為已分配，開發(fā)人員和測(cè)試確認(rèn)BUG，如果是本人的 BUG，則設(shè)置為接收；如果是別的開發(fā)人員的問題，則轉(zhuǎn)發(fā)出去，由下一個(gè)開發(fā)人員來進(jìn)行此行為；如果認(rèn)為不是問題，則需要大家討論并確認(rèn)后，拒絕這個(gè) BUG，然后測(cè)試人員關(guān)閉此問題。

如果開發(fā)人員接受了 BUG，并修改好以后，將 BUG 狀態(tài)修改為已修復(fù)，并告知測(cè)試在哪個(gè)版本中可以測(cè)試。

測(cè)試人員在新版本中測(cè)試，如果發(fā)現(xiàn)問題依然存在，則拒絕驗(yàn)證；如果已經(jīng)修復(fù)，則關(guān)閉BUG。

答:1) 測(cè)試人員或開發(fā)人員發(fā)現(xiàn)bug后，判斷屬于哪個(gè)模塊的問題，填寫bug報(bào)告后，系統(tǒng)會(huì)自動(dòng)通過Email通知項(xiàng)目組長(zhǎng)或直接通知開發(fā)者。

2) 經(jīng)驗(yàn)證無誤后，修改狀態(tài)為VERIFIED.待整個(gè)產(chǎn)品發(fā)布后，修改為CLOSED.

3) 還有問題，REOPENED，狀態(tài)重新變?yōu)?ldquo;New"，并發(fā)郵件通知。

4) 項(xiàng)目組長(zhǎng)根據(jù)具體情況，重新reassigned分配給bug所屬的開發(fā)者。

5) 若是，進(jìn)行處理，resolved并給出解決方法。(可創(chuàng)建補(bǔ)丁附件及補(bǔ)充說明)6) 開發(fā)者收到Email信息后，判斷是否為自己的修改范圍。

7) 若不是，重新reassigned分配給項(xiàng)目組長(zhǎng)或應(yīng)該分配的開發(fā)者。

8) 測(cè)試人員查詢開發(fā)者已修改的bug，進(jìn)行重新測(cè)試。

您認(rèn)為在測(cè)試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？

維持測(cè)試人員同開發(fā)團(tuán)隊(duì)中其他成員良好的人際關(guān)系的關(guān)鍵是什么？

盡量面對(duì)面的溝通，其次是能直接通過電話溝通，如果只能通過 Email 等非及時(shí)溝通工具的話，強(qiáng)調(diào)必須對(duì)特性的理解深刻以及能表達(dá)清楚。

運(yùn)用一些測(cè)試管理工具如 TestDirector 進(jìn)行管理也是較有效的方法，同時(shí)要注意在TestDirector 中對(duì) BUG 有準(zhǔn)確的描述。

在團(tuán)隊(duì)中建立測(cè)試人員與開發(fā)人員良好溝通中注意以下幾點(diǎn)：

一真誠(chéng)

二是團(tuán)隊(duì)精神

三是在專業(yè)上有共同語(yǔ)言

四是要對(duì)事不對(duì)人，工作至上

當(dāng)然也可以通過直接指出一些小問題，而不是進(jìn)入 BUG Tracking System 來增加對(duì)方的好感。

你對(duì)測(cè)試最大的興趣在哪里？為什么？

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

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

測(cè)試是一個(gè)經(jīng)驗(yàn)行業(yè)，工作越久越能感覺到做好測(cè)試的難度和樂趣通過自己的工作，能使軟件產(chǎn)品越來越完善，從中體會(huì)到樂趣回答此類問題注意以下幾個(gè)方面：

盡可能的切合招聘企業(yè)的技術(shù)路線來表達(dá)你的興趣，例如該企業(yè)是數(shù)據(jù)庫(kù)應(yīng)用的企業(yè)，那么表示你的興趣在數(shù)據(jù)庫(kù)的測(cè)試，并且希望通過測(cè)試提升自己的數(shù)據(jù)庫(kù)掌握能力。

表明你做測(cè)試的目的是為了提升能力，也是為了更好的做好測(cè)試；提升能力不是為了以后轉(zhuǎn)開發(fā)或其他的，除非用人企業(yè)有這樣的安排。

不要過多的表達(dá)你的興趣在招聘企業(yè)的范疇這外。比如招聘企業(yè)是做財(cái)務(wù)軟件的，可是你表現(xiàn)出來的是對(duì)游戲軟件的興趣；或招聘是做 JAVA 開發(fā)的，而你的興趣是在 C 類語(yǔ)言程序的開發(fā)。

你自認(rèn)為測(cè)試的優(yōu)勢(shì)在哪里？

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

有韌性

有耐心

做事有條理性

喜歡面對(duì)挑戰(zhàn)

有信心做好每一件事情

較強(qiáng)的溝通能力

從以前的經(jīng)理處都得到了很好的評(píng)價(jià)表明我做的很好集成測(cè)試通常都有那些策略？

1、大爆炸集成

2、自頂向下集成

3、自底向上集成

4、三明治集成適應(yīng)于大部分軟件開發(fā)項(xiàng)目

5、基干集成

6、分層集成

7、基于功能的集成

8、基于消息的集成

9、基于風(fēng)險(xiǎn)的集成

10、基于進(jìn)度的集成

常用 X UNIX 命令x (Linux 的常用命令) ) （至少 0 10 個(gè)）； (Unix)答：ls pwd mkdir rmdir rm cp mv cd ps ping tail more echo adduser passwd logout exit，參見 Linux 的教材。

簡(jiǎn)述你在以前的工作中做過哪些事情，比較熟悉什么。

此問題每個(gè)人都不一樣。參考答案如下。

我過去的主要工作是系統(tǒng)測(cè)試和自動(dòng)化測(cè)試。在系統(tǒng)測(cè)試中，主要是對(duì) BOSS 系統(tǒng)的業(yè)務(wù)邏輯功能，以及軟交換系統(tǒng)的 Class 5 特性進(jìn)行測(cè)試。性能測(cè)試中，主要是進(jìn)行的壓力測(cè)試，在各個(gè)不同數(shù)量請(qǐng)求的情況下，獲取系統(tǒng)響應(yīng)時(shí)間以及系統(tǒng)資源消耗情況。自動(dòng)化測(cè)試主要是通過自己寫腳本以及一些第三方工具的結(jié)合來測(cè)試軟交換的特性測(cè)試。

在測(cè)試中，我感覺對(duì)用戶需求的完全準(zhǔn)確的理解非常重要。另外，就是對(duì) BUG 的管理，要以需求為依據(jù)，并不是所有 BUG 均需要修改。

測(cè)試工作需要耐心和細(xì)致，因?yàn)樵谛掳姹局?，雖然多數(shù)原來發(fā)現(xiàn)的 BUG 得到了修復(fù)，但原來正確的功能也可能變得不正確。因此要注重迭代測(cè)試和回歸測(cè)試。

在 C/C++中中 c static 有什么用途？（請(qǐng)至少說明兩種）1)在函數(shù)體，一個(gè)被聲明為靜態(tài)的變量在這一函數(shù)被調(diào)用過程中維持其值不變。

2) 在模塊內(nèi)（但在函數(shù)體外），一個(gè)被聲明為靜態(tài)的變量可以被模塊內(nèi)所用函數(shù)訪問，但不能被模塊外其它函數(shù)訪問。它是一個(gè)本地的全局變量。

3) 在模塊內(nèi)，一個(gè)被聲明為靜態(tài)的函數(shù)只可被這一模塊內(nèi)的其它函數(shù)調(diào)用。那就是，這個(gè)函數(shù)被限制在聲明它的模塊的本地范圍內(nèi)使用引用與指針有什么區(qū)別？

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

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

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

t Internet 采用哪種網(wǎng)絡(luò)協(xié)議？該協(xié)議的主要層次結(jié)構(gòu)？t Internet 物理地址和 P IP 地址轉(zhuǎn)換采用什么協(xié)議？

TCP/IP 協(xié)議

主要層次結(jié)構(gòu)為：應(yīng)用層/傳輸層/網(wǎng)絡(luò)層/數(shù)鏈路層。

ARP (Address Resolution Protocol)（地?fù)?jù)址解析協(xié)議）說說你對(duì)集成測(cè)試中自頂向下集成和自底向上集成兩個(gè)策略的理解，要談出它們各自的優(yōu)缺點(diǎn)和主要適應(yīng)于哪種類型測(cè)試；自頂向下集成

優(yōu)點(diǎn)：較早地驗(yàn)證了主要控制和判斷點(diǎn)；按深度優(yōu)先可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能；功能較早證實(shí)，帶來信心；只需一個(gè)驅(qū)動(dòng)，減少驅(qū)動(dòng)器開發(fā)的費(fèi)用；支持故障隔離。

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

適應(yīng)于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較小；底層接口未定義或經(jīng)常可能被修改；產(chǎn)口控制組件具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

2、自底向上集成

優(yōu)點(diǎn)：對(duì)底層組件行為較早驗(yàn)證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。

缺點(diǎn)：驅(qū)動(dòng)的開發(fā)工作量大；對(duì)高層的驗(yàn)證被推遲，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)。

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

軟件驗(yàn)收測(cè)試包括 ___ 、 ___ 、 ____ 三種類型。

軟件驗(yàn)收測(cè)試包括正式驗(yàn)收測(cè)試、alpha 測(cè)試、beta 測(cè)試三種測(cè)試。

2 2 ．系統(tǒng)測(cè)試的策略有 ____________________________等等 15 種方法。（該題5 15 個(gè)空）系統(tǒng)測(cè)試的策略有很多種的，有性能測(cè)試、負(fù)載測(cè)試、強(qiáng)度測(cè)試、易用性測(cè)試、安全測(cè)試、配置測(cè)試、安裝測(cè)試、文檔測(cè)試、故障恢復(fù)測(cè)試、用戶界面測(cè)試、恢復(fù)測(cè)試、分布測(cè)試、可用性測(cè)試。

3 3 ．設(shè)計(jì)系統(tǒng)測(cè)試計(jì)劃需要參考的項(xiàng)目文檔有 ___ 、 ___ 和 ____ 。

設(shè)計(jì)系統(tǒng)測(cè)試計(jì)劃需要參考的項(xiàng)目文檔有軟件測(cè)試計(jì)劃、軟件需求工件、和迭代計(jì)劃。

4 4 ．通過畫因果圖來寫測(cè)試用例的步驟為 ___ 、 ___ 、 ___ 、 ___ 及把因果圖轉(zhuǎn)換為狀態(tài)圖共五個(gè)步驟。利用因果圖生成測(cè)試用例的基本步驟是：

§ 分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價(jià)類），哪些是結(jié)果（即輸出條件），并給每個(gè)原因和結(jié)果賦予一個(gè)標(biāo)識(shí)符。

§ 分析軟件規(guī)格說明描述中的語(yǔ)義，找出原因與結(jié)果之間，原因與原因之間對(duì)應(yīng)的是什么關(guān)系? 根據(jù)這些關(guān)系，畫出因果圖。

§ 由于語(yǔ)法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。

為表明這些特殊情況，在因果圖上用一些記號(hào)標(biāo)明約束或限制條件。 § 把因果圖轉(zhuǎn)換成判定表。

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

一、測(cè)試的種類很多，比如：

代碼、函數(shù)級(jí)測(cè)試

模塊、組件級(jí)測(cè)試

系統(tǒng)測(cè)試

請(qǐng)說出這些測(cè)試最好由那些人員完成，測(cè)試的是什么？

代碼、函數(shù)級(jí)測(cè)試一般由白盒測(cè)試人員完成，他們針對(duì)每段代碼或函數(shù)進(jìn)行正確性檢驗(yàn)，檢查其是否正確的實(shí)現(xiàn)了規(guī)定的功能。

模塊、組件級(jí)測(cè)試主要依據(jù)是程序結(jié)構(gòu)設(shè)計(jì)測(cè)試模塊間的集成和調(diào)用關(guān)系，一般由測(cè)試人員完成。

系統(tǒng)測(cè)試在于模塊測(cè)試與單元測(cè)試的基礎(chǔ)上進(jìn)行測(cè)試。了解系統(tǒng)功能與性能，根據(jù)測(cè)試用例進(jìn)行全面的測(cè)試。

二、設(shè)計(jì)測(cè)試用例時(shí)應(yīng)該考慮哪些方面，即不同的測(cè)試用例針對(duì)那些方面進(jìn)行測(cè)試？

設(shè)計(jì)測(cè)試用例時(shí)需要注意的是，除了對(duì)整體流程及功能注意外，還要注意強(qiáng)度測(cè)試、性能測(cè)試、壓力測(cè)試、邊界值測(cè)試、穩(wěn)定性測(cè)試、安全性測(cè)試等多方面。（測(cè)試用例需要考慮的四個(gè)基本要素是輸入、輸出、操作和測(cè)試環(huán)境；另外，測(cè)試用例需要考慮的是測(cè)試類型（功能、性能、安全??），這部分可以參照 TP 做答。此外，還需要考慮用例的重要性和優(yōu)先級(jí)）四、在在 s windows 下保存一個(gè)文本文件時(shí)會(huì)彈出保存對(duì)話框，如果為文件名建立測(cè)試用例，等價(jià)類應(yīng)該怎樣劃分？

單字節(jié)，如 A；

雙字節(jié)， AA、我我；

特殊字符 /‘。‘；、=-等；

保留字，如 com；

文件格式為 8.3 格式的；

文件名格式為非 8.3 格式的；

/,\,*等九個(gè)特殊字符。

假設(shè)有一個(gè)文本框要求輸入 0 10 個(gè)字符的郵政編碼，對(duì)于該文本框應(yīng)該怎樣劃分等價(jià)類？

特殊字符，如 10 個(gè)*或￥；

英文字母，如 ABCDefghik；

小于十個(gè)字符，如 123；

大于十個(gè)字符，如 11111111111；

數(shù)字和其他混合，如 123AAAAAAA；

空字符；

保留字符

5. 軟件測(cè)試項(xiàng)目從什么時(shí)候開始，？為什么？

軟件測(cè)試應(yīng)該在需求分析階段就介入,因?yàn)闇y(cè)試的對(duì)象不僅僅是程序編碼,應(yīng)該對(duì)軟件開發(fā)過程中產(chǎn)生的所有產(chǎn)品都測(cè)試,并且軟件缺陷存在放大趨勢(shì).缺陷發(fā)現(xiàn)的越晚,修復(fù)它所花費(fèi)的成本就越大.

什么是白盒測(cè)試？什么是黑盒測(cè)試? ? 什么是回歸測(cè)試? ?

答：白盒測(cè)試是測(cè)試人員要了解程序結(jié)構(gòu)和處理過程,按照程序內(nèi)部邏輯測(cè)試程序,檢查程序中的每條通路是否按照預(yù)定要求正確工作.它主要的針對(duì)被測(cè)程序的源代碼,測(cè)試著可以完全不考慮程序的功能.

白盒測(cè)試流程:詳細(xì)設(shè)計(jì)-->源程序-->分析程序內(nèi)部邏輯結(jié)構(gòu)-->流程圖-->制定測(cè)試用例-->被測(cè)程序-->執(zhí)行路徑-->覆蓋情況分析 .

黑盒測(cè)試:（Black-box Testing，又稱為功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試）是把測(cè)試對(duì)象看作一個(gè)黑盒子。利用黑盒測(cè)試法進(jìn)行動(dòng)態(tài)測(cè)試時(shí)，需要測(cè)試軟件產(chǎn)品的功能，不需測(cè)試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。

回歸測(cè)試: (regression testing): 回歸測(cè)試有兩類：用例回歸和錯(cuò)誤回歸；用例回歸是過一段時(shí)間以后再回頭對(duì)以前使用過的用例在重新進(jìn)行測(cè)試，看看會(huì)重新發(fā)現(xiàn)問題。錯(cuò)誤回歸，就是在新版本中，對(duì)以前版本中出現(xiàn)并修復(fù)的缺陷進(jìn)行再次驗(yàn)證，并以缺陷為核心，對(duì)相關(guān)修改的部分進(jìn)行測(cè)試的方法。

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

單元測(cè)試針對(duì)的是軟件設(shè)計(jì)的最小單元--程序模塊（面向過程中是函數(shù)、過程；面向?qū)ο笾惺穷?。?進(jìn)行正確性檢驗(yàn)的測(cè)試工作,在于發(fā)現(xiàn)每個(gè)程序模塊內(nèi)部可能存在的差錯(cuò).一般有兩個(gè)步驟:人工靜態(tài)檢查\動(dòng)態(tài)執(zhí)行跟蹤集成測(cè)試針對(duì)的是通過了單元測(cè)試的各個(gè)模塊所集成起來的組件進(jìn)行檢驗(yàn),其主要內(nèi)容是各個(gè)單元模塊之間的接口,以及各個(gè)模塊集成后所實(shí)現(xiàn)的功能.

系統(tǒng)測(cè)試針對(duì)的是集成好的軟件系統(tǒng)，作為整個(gè)計(jì)算機(jī)系統(tǒng)的一個(gè)元素,與計(jì)算機(jī)硬件\外設(shè)\某些支持軟件\數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起,要在實(shí)際的運(yùn)行環(huán)境中,對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的集成測(cè)試和確認(rèn)測(cè)試.

3. 設(shè)計(jì)用例的方法：

在測(cè)試的不同階段運(yùn)用不用的測(cè)試方法設(shè)計(jì)用例的方法依據(jù)不同:

白盒測(cè)試用例設(shè)計(jì)有如下方法：邏輯覆蓋、循環(huán)覆蓋和基本路徑覆蓋黑盒測(cè)試用例設(shè)計(jì)方法：等價(jià)類劃分、邊界值分析、錯(cuò)誤猜測(cè)、因果圖、狀態(tài)圖、測(cè)試大綱、場(chǎng)景法、正交策略表。

4. 一個(gè)測(cè)試工程師應(yīng)具備那些素質(zhì)？

1、責(zé)任心

2、溝通能力

3、團(tuán)隊(duì)合作精神

4、耐心、細(xì)心、信心

5、時(shí)時(shí)保持懷疑態(tài)度，并且有缺陷預(yù)防的意識(shí)

6、具備一定的編程經(jīng)驗(yàn)

5. 集成測(cè)試通常都有那些策略？

基于分解的集成:大爆炸集成\自頂向下集成\自底向上集成\ 三明治集成\基于調(diào)用圖的集成\基于路徑的集成\分層集成\基于功能的集成\高頻集成\基于進(jìn)度的集成\基于風(fēng)險(xiǎn)集成\基于事件集成\基于使用的集成\C/S 集成問題二：你所了解的的軟件測(cè)試類型都有哪些，簡(jiǎn)單介紹一下。

按測(cè)試策略分類：1、靜態(tài)與動(dòng)態(tài)測(cè)試 2、黑盒與白盒測(cè)試 3、手工和自動(dòng)測(cè)試 4、冒煙測(cè)試 5、回歸測(cè)試；按測(cè)試階段分類：?jiǎn)卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試；其他常見測(cè)試方法：1、功能測(cè)試 2、性能測(cè)試 3、壓力測(cè)試 4、負(fù)載測(cè)試 5、易用性測(cè)試 6、安裝測(cè)試 7、界面測(cè)試 8、配置測(cè)試 9、文檔測(cè)試 10、兼容性測(cè)試 11、安全性測(cè)試 12、恢復(fù)測(cè)試問題三：你認(rèn)為做好測(cè)試計(jì)劃工作的關(guān)鍵是什么？

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

編寫軟件測(cè)試計(jì)劃得重要目的就是使測(cè)試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測(cè)試計(jì)劃的價(jià)值取決于它對(duì)幫助管理測(cè)試項(xiàng)目，并且找出軟件潛在的缺陷。因此，軟件測(cè)試計(jì)劃中的測(cè)試范圍必須高度覆蓋功能需求，測(cè)試方法必須切實(shí)可行，測(cè)試工具并且具有較高的實(shí)用性，便于使用，生成的測(cè)試結(jié)果直觀、準(zhǔn)確堅(jiān)持“5W”規(guī)則，明確內(nèi)容與過程“5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時(shí)做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測(cè)試計(jì)劃，可以幫助測(cè)試團(tuán)隊(duì)理解測(cè)試的目的（Why），明確測(cè)試的范圍和內(nèi)容（What），確定測(cè)試的開始和結(jié)束日期（When），指出測(cè)試的方法和工具（How），給出測(cè)試文檔和軟件的存放位置（Where）。

采用評(píng)審和更新機(jī)制，保證測(cè)試計(jì)劃滿足實(shí)際需求測(cè)試計(jì)劃寫作完成后，如果沒有經(jīng)過評(píng)審，直接發(fā)送給測(cè)試團(tuán)隊(duì)，測(cè)試計(jì)劃內(nèi)容的可能不準(zhǔn)確或遺漏測(cè)試內(nèi)容，或者軟件需求變更引起測(cè)試范圍的增減，而測(cè)試計(jì)劃的內(nèi)容沒有及時(shí)更新，誤導(dǎo)測(cè)試執(zhí)行人員。

分別創(chuàng)建測(cè)試計(jì)劃與測(cè)試詳細(xì)規(guī)格、測(cè)試用例應(yīng)把詳細(xì)的測(cè)試技術(shù)指標(biāo)包含到獨(dú)立創(chuàng)建的測(cè)試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測(cè)試小組執(zhí)行測(cè)試過程的測(cè)試用例放到獨(dú)立創(chuàng)建的測(cè)試用例文檔或測(cè)試用例管理數(shù)據(jù)庫(kù)中。

問題四：您認(rèn)為做好測(cè)試用例設(shè)計(jì)工作的關(guān)鍵是什么？

白盒測(cè)試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測(cè)試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題問題六：您認(rèn)為性能測(cè)試工作的目的是什么？做好性能測(cè)試工作的關(guān)鍵是什么？

性能測(cè)試的目的主要是發(fā)現(xiàn)在并發(fā)多用戶和大數(shù)據(jù)量操作時(shí)是否會(huì)出現(xiàn)與需求有差異的地方。性能測(cè)試工作的關(guān)鍵是做好系統(tǒng)分析和功能分析，確定系統(tǒng)瓶頸所在（這里參看 ATT第十章 LoadRunner 的 PPT）。

問題八：你的測(cè)試職業(yè)發(fā)展目標(biāo)是什么？

測(cè)試經(jīng)驗(yàn)越多，測(cè)試能力越高。所以我的職業(yè)發(fā)展是需要時(shí)間累積的，一步步向著高級(jí)測(cè)試工程師奔去。而且我也有初步的職業(yè)規(guī)劃，前 3 年累積測(cè)試經(jīng)驗(yàn)，不斷的更新自己改正自己，做好測(cè)試任務(wù)。

問題九：你對(duì)我們公司了解有多少？

建議從招聘廣告上多了解信息，同時(shí)到應(yīng)聘公司的網(wǎng)站上去盡可能多的了解這個(gè)公司的情況，以便回答好這類問題。

問題十：測(cè)試結(jié)束的標(biāo)準(zhǔn)是什么？

從微觀上來說，在測(cè)試計(jì)劃中定義，比如系統(tǒng)在一定性能下平穩(wěn)運(yùn)行 72 小時(shí)，目前 BugTracking System 中，本版本中沒有一般嚴(yán)重的 BUG，普通 BUG 的數(shù)量在 3 以下，BUG 修復(fù)率 90%以上等等參數(shù)，然后由開發(fā)經(jīng)理，測(cè)試經(jīng)理，項(xiàng)目經(jīng)理共同簽字認(rèn)同版本 Release。

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

1 1 、軟件測(cè)試分為黑盒和白盒，分別適合什么情況？？

軟件測(cè)試方法一般分為兩種：白盒測(cè)試與黑盒測(cè)試。白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試、邏輯驅(qū)動(dòng)測(cè)試或基于程序本身的測(cè)試，它著重于程序的內(nèi)部結(jié)構(gòu)及算法，通常不關(guān)心功能與性能指標(biāo)；黑盒測(cè)試又被稱為功能測(cè)試、數(shù)據(jù)驅(qū)動(dòng)測(cè)試或基于規(guī)格說明的測(cè)試，它實(shí)際上是站在最終用戶的立場(chǎng)，檢驗(yàn)輸入輸出信息及系統(tǒng)性能指標(biāo)是否符合規(guī)格說明書中有關(guān)功能需求及性能需求的規(guī)定。

2、一套完整的測(cè)試應(yīng)該由哪些階段組成？

可行性分析、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試4、測(cè)試用例通常包括那些內(nèi)容？

不同結(jié)構(gòu)的用例包括的不一樣。（版本、編號(hào)、項(xiàng)目、設(shè)計(jì)人員、設(shè)計(jì)日期、輸入、預(yù)期輸出??）軟件測(cè)試用例的基本要素包括測(cè)試用例編號(hào)、測(cè)試標(biāo)題、重要級(jí)別、測(cè)試輸入、操作步驟、預(yù)期結(jié)果。

用例編號(hào)：測(cè)試用例的編號(hào)有一定的規(guī)則，比如系統(tǒng)測(cè)試用例的編號(hào)這樣定義規(guī)則：

PROJECT1-ST-001 ，命名規(guī)則是項(xiàng)目名稱＋測(cè)試階段類型（系統(tǒng)測(cè)試階段）＋編號(hào)。定義測(cè)試用例編號(hào)，便于查找測(cè)試用例，便于測(cè)試用例的跟蹤。

測(cè)試標(biāo)題：對(duì)測(cè)試用例的描述，測(cè)試用例標(biāo)題應(yīng)該清楚表達(dá)測(cè)試用例的用途。比如 “ 測(cè)試用戶登錄時(shí)輸入錯(cuò)誤密碼時(shí)，軟件的響應(yīng)情況 ” 。

重要級(jí)別：定義測(cè)試用例的優(yōu)先級(jí)別，可以籠統(tǒng)的分為 “ 高 ” 和 “ 低 ” 兩個(gè)級(jí)別。一般來說，如果軟件需求的優(yōu)先級(jí)為 “ 高 ” ，那么針對(duì)該需求的測(cè)試用例優(yōu)先級(jí)也為“ 高 ” ；反之亦然，一般而言，是 5 級(jí)劃分。

測(cè)試輸入：提供測(cè)試執(zhí)行中的各種輸入條件。根據(jù)需求中的輸入條件，確定測(cè)試用例的輸入。測(cè)試用例的輸入對(duì)軟件需求當(dāng)中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測(cè)試用例設(shè)計(jì)中會(huì)遇到很大的障礙。

操作步驟：提供測(cè)試執(zhí)行過程的步驟。對(duì)于復(fù)雜的測(cè)試用例，測(cè)試用例的輸入需要分為幾個(gè)步驟完成，這部分內(nèi)容在操作步驟中詳細(xì)列出。

預(yù)期結(jié)果：提供測(cè)試執(zhí)行的預(yù)期結(jié)果，預(yù)期結(jié)果應(yīng)該根據(jù)軟件需求中的輸出得出。如果在實(shí)際測(cè)試過程中，得到的實(shí)際測(cè)試結(jié)果與預(yù)期結(jié)果不符，那么測(cè)試不通過；反之則測(cè)試通過。

您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請(qǐng)?jiān)囀鲆粋€(gè)完整的開發(fā)過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？您在以往的測(cè)試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長(zhǎng)哪部分工作？

開發(fā)過程---需求調(diào)研（需求人員）、需求分析（需求人員）、概要設(shè)計(jì)（設(shè)計(jì)人員）、詳細(xì)設(shè)計(jì)(設(shè)計(jì)人員)、編碼（開發(fā)人員）測(cè)試過程---需求評(píng)審、系統(tǒng)測(cè)試設(shè)計(jì)、概要設(shè)計(jì)評(píng)審、集成測(cè)試設(shè)計(jì)、詳細(xì)設(shè)計(jì)評(píng)審、單元測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行測(cè)試工作的整個(gè)過程都做過，擅長(zhǎng)做測(cè)試設(shè)計(jì)

過程決定質(zhì)量，軟件的過程改進(jìn)正是為了提高軟件的質(zhì)量，將過往的種種經(jīng)驗(yàn)和教訓(xùn)積累起來。

在您所經(jīng)歷的測(cè)試活動(dòng)中，參與人員有哪些？您所擔(dān)任的角色是什么？

有項(xiàng)目管理員、開發(fā)管理員、系統(tǒng)分析員、設(shè)計(jì)員、開發(fā)員、質(zhì)量管理員、測(cè)試管理員、測(cè)試設(shè)計(jì)員、測(cè)試員擔(dān)任過測(cè)試管理員、測(cè)試設(shè)計(jì)員、測(cè)試員

測(cè)試用例設(shè)計(jì)的原則是什么？目前主要的測(cè)試用例設(shè)計(jì)方法有哪些？

代表性：能夠代表并覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等.

可判定性：即測(cè)試執(zhí)行結(jié)果的正確性是可判定的，每一個(gè)測(cè)試用例都應(yīng)有相應(yīng)的期望結(jié)果.

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

方法有等價(jià)類、邊界值、因果圖、狀態(tài)圖、正交法、大綱法面向?qū)ο蟮臏y(cè)試用例設(shè)計(jì)有幾種方法？如何實(shí)現(xiàn)？

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

組合類中的類變量、實(shí)例變量

組合類中的各種方法

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

根據(jù)代碼設(shè)計(jì)測(cè)試用例

LoadRunner 分為哪三個(gè)模塊？請(qǐng)簡(jiǎn)述各模塊的主要功能。

Virtual User Generator：用于錄制腳步

Mercury LoadRunner Controller：用于創(chuàng)建、運(yùn)行和監(jiān)控場(chǎng)景Mercury LoadRunner Analysis：用于分析測(cè)試結(jié)果你對(duì)測(cè)試最大的興趣在哪里？為什么？

最大的興趣就是測(cè)試有難度，有挑戰(zhàn)性！做測(cè)試越久越能感覺到做好測(cè)試有多難。曾經(jīng)在無憂測(cè)試網(wǎng)上看到一篇文章，是關(guān)于如何做好一名測(cè)試工程師。一共羅列了 11，12 點(diǎn)，有部分是和人的性格有關(guān)，有部分需要后天的努力。但除了性格有關(guān)的 1，2 點(diǎn)我沒有把握，其他點(diǎn)我都很有信心做好它。

剛開始進(jìn)入測(cè)試行業(yè)時(shí)，對(duì)測(cè)試的認(rèn)識(shí)是從無憂測(cè)試網(wǎng)上了解到的一些資料，當(dāng)時(shí)是沖著做測(cè)試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發(fā)更難，雖然當(dāng)時(shí)我很想做開發(fā)（學(xué)校專業(yè)課我基本上不缺席，因?yàn)槲蚁矚g我的專業(yè)），但看到測(cè)試比開發(fā)更難更有挑戰(zhàn)性，想做好測(cè)試的意志就更堅(jiān)定了。

我覺得做測(cè)試整個(gè)過程中有 2 點(diǎn)讓我覺得很有難度（對(duì)我來說，有難度的東西我就非常感興趣），第一是測(cè)試用例的設(shè)計(jì)，因?yàn)闇y(cè)試的精華就在測(cè)試用例的設(shè)計(jì)上了，要在版本出來之前，把用例寫好，用什么測(cè)試方法寫？（也就是測(cè)試計(jì)劃或測(cè)試策略），如果你剛測(cè)試一個(gè)新任務(wù)時(shí)，你得花一定的時(shí)間去消化業(yè)務(wù)需求和技術(shù)基礎(chǔ)，業(yè)務(wù)需求很好理解（多和產(chǎn)品經(jīng)理和開發(fā)人員溝通就能達(dá)到目的），而技術(shù)基礎(chǔ)可就沒那么簡(jiǎn)單了，這需要你自覺的學(xué)習(xí)能力，比如說網(wǎng)站吧，最基本的技術(shù)知識(shí)你要知道網(wǎng)站內(nèi)部是怎么運(yùn)作的的，后臺(tái)是怎么響應(yīng)用戶請(qǐng)求的？測(cè)試環(huán)境如何搭建？這些都需要最早的學(xué)好。至少在開始測(cè)試之前能做好基本的準(zhǔn)備，可能會(huì)遇到什么難題？需求細(xì)節(jié)是不是沒有確定好？這些問題都能在設(shè)計(jì)用例的時(shí)候發(fā)現(xiàn)。

第二是發(fā)現(xiàn) BUG 的時(shí)候了，這應(yīng)該是測(cè)試人員最基本的任務(wù)了，一般按測(cè)試用例開始測(cè)試就能發(fā)現(xiàn)大部分的 bug，還有一部分 bug 需要測(cè)試的過程中更了解所測(cè)版本的情況獲得更多信息，補(bǔ)充測(cè)試用例，測(cè)試出 bug。還有如何發(fā)現(xiàn) bug？這就需要在測(cè)試用例有效的情況下，通過細(xì)心和耐心去發(fā)現(xiàn) bug 了，每個(gè)用例都有可能發(fā)現(xiàn) bug，每個(gè)地方都有可能出錯(cuò)，所以測(cè)試過程中思維要清晰（測(cè)試過程數(shù)據(jù)流及結(jié)果都得看仔細(xì)了，bug 都在里面發(fā)現(xiàn)的）。如何描述 bug 也很有講究，bug 在什么情況下會(huì)產(chǎn)生，如果條件變化一點(diǎn)點(diǎn)，就不會(huì)有這個(gè) bug，以哪些最少的操作步驟就能重現(xiàn)這個(gè)bug，這個(gè)bug產(chǎn)生的規(guī)律是什么？如果你夠厲害的話，可以幫開發(fā)人員初步定位問題。

問題十五：你的測(cè)試職業(yè)發(fā)展目標(biāo)是什么？

測(cè)試經(jīng)驗(yàn)越多，測(cè)試能力越高。所以我的職業(yè)發(fā)展是需要時(shí)間累積的，一步步向著高級(jí)測(cè)試工程師奔去。而且我也有初步的職業(yè)規(guī)劃，前 3 年累積測(cè)試經(jīng)驗(yàn)，按如何做好測(cè)試工程師的11，12 點(diǎn)要求自己，不斷的更新自己改正自己，做好測(cè)試任務(wù)。

二、您所熟悉的軟件測(cè)試類型都有哪些？請(qǐng)?jiān)囍謩e比較這些不同的測(cè)試類型的區(qū)別與聯(lián)系（如功能測(cè)試、性能測(cè)試??）測(cè)試類型有：功能測(cè)試，性能測(cè)試，界面測(cè)試。

功能測(cè)試在測(cè)試工作中占的比例最大，功能測(cè)試也叫黑盒測(cè)試。是把測(cè)試對(duì)象看作一個(gè)黑盒子。利用黑盒測(cè)試法進(jìn)行動(dòng)態(tài)測(cè)試時(shí)，需要測(cè)試軟件產(chǎn)品的功能，不需測(cè)試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑盒技術(shù)設(shè)計(jì)測(cè)試用例的方法有：等價(jià)類劃分、邊界值分析、錯(cuò)誤推測(cè)、因果圖和綜合策略。

性能測(cè)試是通過自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。負(fù)載測(cè)試和壓力測(cè)試都屬于性能測(cè)試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測(cè)試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測(cè)試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測(cè)試是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測(cè)試。

界面測(cè)試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對(duì)軟件的第一印象。而且設(shè)計(jì)良好的界面能夠引導(dǎo)用戶自己完成相應(yīng)的操作，起到向?qū)У淖饔?。同時(shí)界面如同人的面孔，具有吸引用戶的直接優(yōu)勢(shì)。設(shè)計(jì)合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設(shè)計(jì)的失敗，讓用戶有挫敗感，再實(shí)用強(qiáng)大的功能都可能在用戶的畏懼與放棄中付諸東流。

區(qū)別在于，功能測(cè)試關(guān)注產(chǎn)品的所有功能上，要考慮到每個(gè)細(xì)節(jié)功能，每個(gè)可能存在的功能問題。性能測(cè)試主要關(guān)注于產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測(cè)試更關(guān)注于用戶體驗(yàn)上，用戶使用該產(chǎn)品的時(shí)候是否易用，是否易懂，是否規(guī)范（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（盡量在前臺(tái)避免用戶無意輸入無效的數(shù)據(jù)，當(dāng)然考慮到體驗(yàn)性，不能太粗魯?shù)膹棾鼍妫孔瞿硞€(gè)性能測(cè)試的時(shí)候，首先它可能是個(gè)功能點(diǎn)，首先要保證它的功能是沒問題的，然后再考慮該功能點(diǎn)的性能測(cè)試三、請(qǐng)?jiān)囍容^一下黑盒測(cè)試、白盒測(cè)試、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試的區(qū)別與聯(lián)系。

黑盒測(cè)試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測(cè)試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。

白盒測(cè)試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測(cè)試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。

軟件的黑盒測(cè)試意味著測(cè)試要在軟件的接口處進(jìn)行。這種方法是把測(cè)試對(duì)象看做一個(gè)黑盒子，測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測(cè)試又叫功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試。黑盒測(cè)試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤：

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

2、在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？

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

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

5、是否有初始化或終止性錯(cuò)誤？

軟件的白盒測(cè)試是對(duì)軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測(cè)試對(duì)象看做一個(gè)打開的盒子，它允許測(cè)試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。通過在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。白盒測(cè)試主要是想對(duì)程序模塊進(jìn)行如下檢查：

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

2、對(duì)所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測(cè)一遍。

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

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

單元測(cè)試（模塊測(cè)試）是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測(cè)代碼的一個(gè)很小的、很明確的功能是否正確。通常而言，一個(gè)單元測(cè)試是用于判斷某個(gè)特定條件（或者場(chǎng)景）下某個(gè)特定函數(shù)的行為。

單元測(cè)試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責(zé)任編寫功能代碼，同時(shí)也就有責(zé)任為自己的代碼編寫單元測(cè)試。執(zhí)行單元測(cè)試，就是為了證明這段代碼的行為和我們期望的一致。

集成測(cè)試（也叫組裝測(cè)試，聯(lián)合測(cè)試）是單元測(cè)試的邏輯擴(kuò)展。它的最簡(jiǎn)單的形式是：

兩個(gè)已經(jīng)測(cè)試過的單元組合成一個(gè)組件，并且測(cè)試它們之間的接口。從這一層意義上講，組件是指多個(gè)單元的集成聚合。在現(xiàn)實(shí)方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測(cè)試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測(cè)試。最后，將構(gòu)成進(jìn)程的所有模塊一起測(cè)試。

系統(tǒng)測(cè)試是將經(jīng)過測(cè)試的子系統(tǒng)裝配成一個(gè)完整系統(tǒng)來測(cè)試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測(cè)試）系統(tǒng)測(cè)試的目的是對(duì)最終軟件系統(tǒng)進(jìn)行全面的測(cè)試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)。

驗(yàn)收測(cè)試是部署軟件之前的最后一個(gè)測(cè)試操作。驗(yàn)收測(cè)試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。

驗(yàn)收測(cè)試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測(cè)試后，已經(jīng)按照設(shè)計(jì)把所有的模塊組裝成一個(gè)完整的軟件系統(tǒng)，接口錯(cuò)誤也已經(jīng)基本排除了，接著就應(yīng)該進(jìn)一步驗(yàn)證軟件的有效性，這就是驗(yàn)收測(cè)試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。

四、當(dāng)開發(fā)人員說不是 G BUG 時(shí)，你如何應(yīng)付？

開發(fā)人員說不是 bug，有 2 種情況，一是需求沒有確定，所以我可以這么做，這個(gè)時(shí)候可以找來產(chǎn)品經(jīng)理進(jìn)行確認(rèn)，需不需要改動(dòng)，3 方商量確定好后再看要不要改。二是這種情況不可能發(fā)生，所以不需要修改，這個(gè)時(shí)候，我可以先盡可能的說出是 BUG 的依據(jù)是什么？

如果被用戶發(fā)現(xiàn)或出了問題，會(huì)有什么不良結(jié)果？程序員可能會(huì)給你很多理由，你可以對(duì)他的解釋進(jìn)行反駁。如果還是不行，那我可以給這個(gè)問題提出來,跟開發(fā)經(jīng)理和測(cè)試經(jīng)理進(jìn)行確認(rèn),如果要修改就改,如果不要修改就不改。其實(shí)有些真的不是 bug，我也只是建議的方式寫進(jìn) TD 中，如果開發(fā)人員不修改也沒有大問題。如果確定是 bug 的話，一定要堅(jiān)持自己的立場(chǎng)，讓問題得到最后的確認(rèn)。

五、為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測(cè)試工作？

因?yàn)闆]有經(jīng)過測(cè)試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比 ISO 質(zhì)量認(rèn)證一樣，測(cè)試同樣也需要質(zhì)量的保證，這個(gè)時(shí)候就需要在團(tuán)隊(duì)中開展軟件測(cè)試的工作。在測(cè)試的過程發(fā)現(xiàn)軟件中存在的問題，及時(shí)讓開發(fā)人員得知并修改問題，在即將發(fā)布時(shí)，從測(cè)試報(bào)告中得出軟件的質(zhì)量情況。

六、如果有機(jī)會(huì)轉(zhuǎn)成開發(fā)人員，你會(huì)去做開發(fā)工作嗎？

如果公司確實(shí)需要我可以從事開發(fā)，但我還是喜歡做測(cè)試，我認(rèn)為我更適合做測(cè)試。

八、一份測(cè)試計(jì)劃應(yīng)該包括哪些內(nèi)容？

背景、項(xiàng)目簡(jiǎn)介、目的、測(cè)試范圍、測(cè)試策略、人員分工、資源要求、進(jìn)度計(jì)劃、參考文檔、常用術(shù)語(yǔ)、提交文檔、風(fēng)險(xiǎn)分析。

九、針對(duì)于軟件的行業(yè)背景，你如何理解軟件的業(yè)務(wù)？

閱讀用戶手冊(cè)了解軟件的功能和操作流程；

看一些業(yè)務(wù)的專業(yè)書籍補(bǔ)充業(yè)務(wù)知識(shí)；

如果有用戶實(shí)際的數(shù)據(jù)，可以拿實(shí)際的數(shù)據(jù)進(jìn)行參考；參考以前的用例和 BUG 報(bào)告；在使用軟件的過程中多思考；

多與產(chǎn)品經(jīng)理交流。

十、測(cè)試用例應(yīng)包括哪些內(nèi)容？

編號(hào)、模塊名稱、編寫人、日期、操作說明、輸入數(shù)據(jù)、預(yù)期結(jié)果等。

如何定位測(cè)試用例的作用？