１?；靖拍?/p>

１。１軟件

軟件就是可以在計算機(jī)上運(yùn)行的計算機(jī)程序，如操作系統(tǒng)Windows、辦公軟件Office、聊天ＱＱ、手機(jī)游戲等。軟件和我們的生活和工作之間的聯(lián)系越來越密切。

１。２軟件測試

軟件測試的經(jīng)典定義是：在規(guī)定的條件下對程序進(jìn)行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件品質(zhì)，并對其是否能滿足設(shè)計要求進(jìn)行評估的過程。

軟件測試的現(xiàn)實(shí)定義是：軟件測試是貫穿整個軟件開發(fā)生命周期、對軟件產(chǎn)品（包括階段性產(chǎn)品）進(jìn)行驗(yàn)證和確認(rèn)的活動過程，其目的是盡快盡早地發(fā)現(xiàn)在軟件產(chǎn)品中所存在的各種問題——與用戶需求、預(yù)先定義的不一致性。

１。３測試的方法

軟件測試一般分為白盒測試和黑盒測試。

黑盒測試

黑盒測試，軟件測試的主要方法之一，也可以稱為功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試。測試應(yīng)用程序的功能，而不是其內(nèi)部結(jié)構(gòu)或運(yùn)作。測試者不需具備應(yīng)用程序的代碼、內(nèi)部結(jié)構(gòu)和編程語言的專門知識。測試者只需知道什么是系統(tǒng)應(yīng)該做的事，即當(dāng)鍵入一個特定的輸入，可得到一定的輸出，這是從用戶的角度針對軟件界面、功能及外部結(jié)構(gòu)進(jìn)行測試，而不考慮程序內(nèi)部邏輯結(jié)構(gòu)。測試用例是應(yīng)用系統(tǒng)應(yīng)該做的功能，照規(guī)范、規(guī)格或要求等設(shè)計。測試者選擇有效輸入和無效輸入來驗(yàn)證是否正確的輸出。此測試方法可適合大部分的軟件測試，例如單元測試（unit testing）、集成測試（integration testing）以及系統(tǒng)測試（system testing）。

白盒測試

白盒測試（又稱透明盒測試、結(jié)構(gòu)測試等）是一個測試軟件的方法，測試應(yīng)用程序的內(nèi)部結(jié)構(gòu)或運(yùn)作，而不是測試應(yīng)用程序的功能（即黑盒測試）。在白箱測試時，以編程語言的角度來設(shè)計測試案例。測試者輸入數(shù)據(jù)驗(yàn)證數(shù)據(jù)流在程序中的移動路徑，并確定適當(dāng)?shù)妮敵?，類似測試電路中的節(jié)點(diǎn)。

白箱測試可以應(yīng)用于單元測試、集成測試和系統(tǒng)的軟件測試流程，可測試在集成過程中每一單元之間的路徑，或者主系統(tǒng)跟子系統(tǒng)中的測試。盡管這種測試的方法可以發(fā)現(xiàn)許多的錯誤或問題，它可能無法檢測未使用部分的規(guī)范。

１。４測試的類型

功能測試

按照測試軟件的各個功能劃分進(jìn)行有條理的測試，在功能測試部分要保證測試項(xiàng)覆蓋所有功能和各種功能條件組合。

更詳細(xì)的描述請參見“黑盒測試”。

系統(tǒng)測試

對一個完整的軟件以用戶的角度來進(jìn)行測試，系統(tǒng)測試和功能測試的區(qū)別是，系統(tǒng)測試?yán)玫乃袦y試數(shù)據(jù)和測試的方法都要模擬成和用戶的實(shí)際使用環(huán)境完全一樣，測試的軟件也是經(jīng)過系統(tǒng)集成以后的完整軟件系統(tǒng)，而不是在功能測試階段利用的每個功能模塊單獨(dú)編譯后生成的可執(zhí)行程序。

極限值測試

對軟件在各種特殊條件，特殊環(huán)境下能否正常運(yùn)行和軟件的性能進(jìn)行測試。

特殊條件一般指的是軟件規(guī)定的最大值，最小值，以及在超過最大，小值條件下的測試。

特殊環(huán)境一般指的是軟件運(yùn)行的機(jī)器處于CPU高負(fù)荷，或是網(wǎng)絡(luò)高負(fù)荷狀態(tài)下的測試，根據(jù)軟件的不同，特殊環(huán)境也有過不同。

性能測試

性能測試是對軟件性能的評價。簡單的說，軟件性能衡量的是軟件具有的響應(yīng)及時度能力。因此，性能測試是采用測試手段對軟件的響應(yīng)及時性進(jìn)行評價的一種方式。根據(jù)軟件的不同類型，性能測試的側(cè)重點(diǎn)也不同。

壓力測試

壓力測試，確立系統(tǒng)穩(wěn)定性的一種測試方法，在軟件工程、金融風(fēng)險管理等領(lǐng)域應(yīng)用比較普遍。通常在系統(tǒng)正常運(yùn)作范圍之外進(jìn)行，以考察其功能極限和隱患。

壓力測試與性能測試的區(qū)別

壓力測試常常和性能測試相混淆。它們主要不同點(diǎn)是，壓力測試要求進(jìn)行超過規(guī)定性能指標(biāo)的測試。例如一個網(wǎng)站設(shè)計容量是100個人同時點(diǎn)擊，壓力測試就要是采用120個同時點(diǎn)擊的條件測試。

１。５測試的階段

單元測試

單元測試是對軟件組成單元進(jìn)行測試，其目的是檢驗(yàn)軟件基本組成單位的正確性，測試的對象是軟件設(shè)計的最小單位---模塊。單元測試一般由開發(fā)人員完成。

集成測試

集成測試又稱組裝測試，是將程序模塊采用適當(dāng)?shù)募刹呗越M裝起來，對系統(tǒng)的接口及集成后的功能進(jìn)行正確性檢測的測試工作。其主要目的是檢查軟件單位之間的接口是否正確，集成測試的對象是已經(jīng)經(jīng)過單元測試的模塊。

實(shí)踐表明，有時模塊雖然可以單獨(dú)工作，但是并不能保證組裝起來也可以同時工作。

系統(tǒng)測試

系統(tǒng)測試主要包括功能測試、界面測試、可靠性測試、易用性測試、性能測試。 功能測試主要針對包括功能可用性、功能實(shí)現(xiàn)程度（功能流程&業(yè)務(wù)流程、數(shù)據(jù)處理&業(yè)務(wù)數(shù)據(jù)處理）方面測試。

回歸測試

回歸測試是為了檢測代碼修改而引入的錯誤所進(jìn)行的測試活動?；貧w測試是軟件測試階段的重要工作，有研究表明，回歸測試帶來的耗費(fèi)占軟件生命周期的1/3總費(fèi)用以上。

與普通的測試不同，在回歸測試過程開始的時候，測試者有一個完整的測試用例集可供使用，因此，如何根據(jù)代碼的修改情況對已有測試用例集進(jìn)行有效的復(fù)用是回歸測試研究的重要方向，此外，回歸測試的研究方向還涉及自動化工具，面向?qū)ο蠡貧w測試，測試用例優(yōu)先級，回歸測試用例補(bǔ)充生成等。

Alpha測試

α測試通常是階段性的開發(fā)完成后所開始進(jìn)行，一直持續(xù)到進(jìn)入Beta測試階段前的階段。α測試是一種驗(yàn)證測試，在模擬的環(huán)境中以模擬的數(shù)據(jù)來運(yùn)行。

在這個階段中，通常是在開發(fā)單位由開發(fā)人員與測試的測試人員，以模擬或?qū)嶋H操作性的方式進(jìn)行驗(yàn)證測試。

Beta測試

在系統(tǒng)測試中通常先進(jìn)行α測試以驗(yàn)證信息系統(tǒng)符合用戶以及設(shè)計需求所期望的功能。當(dāng)α階段完成后，開發(fā)過程進(jìn)入到β階段；由公眾參與的測試的階段。β測試可稱為確認(rèn)測試，在一個真實(shí)的環(huán)境中以實(shí)際的數(shù)據(jù)來運(yùn)行測試，以確認(rèn)性能、系統(tǒng)運(yùn)行有效率，系統(tǒng)撤消與備份作業(yè)正常，通過測試讓信息系統(tǒng)日后可以

Beta測試和黑盒測試的區(qū)別

對Alpha和Beta測試常見的一個認(rèn)識誤區(qū)是“Beta測試＝黑盒測試”。實(shí)際上，Alpha和Beta測試對應(yīng)在軟件產(chǎn)品發(fā)布之前的Alpha和Beta階段，而白盒、黑盒和灰盒測試技術(shù)是從技術(shù)和方法層面對測試的描述，不應(yīng)該將這兩部分概念混淆。

驗(yàn)收測試

驗(yàn)收測試是系統(tǒng)部署到用戶環(huán)境后，用戶運(yùn)行系統(tǒng)，考察系統(tǒng)是否滿足用戶需求的過程。驗(yàn)收測試是用戶主導(dǎo)的，用戶可能聘請專家?guī)椭?yàn)收測試。

１。６軟件測試的作用

1.對產(chǎn)品質(zhì)量完成全面的評估，為軟件產(chǎn)品發(fā)布（如驗(yàn)收測試）、軟件系統(tǒng)部署（如性能規(guī)劃測試）、軟件產(chǎn)品鑒定（第三方獨(dú)立測試）委托方和被委托方糾紛仲裁（第三方獨(dú)立測試）和其它決策提供信息；

2.通過持續(xù)的測試（包括需求評審、設(shè)計評審、代碼評審等）可以對產(chǎn)品質(zhì)量提供持續(xù)的、快速的反饋，從而在整個開發(fā)過程中不斷地、及時地改進(jìn)產(chǎn)品的質(zhì)量，并減少各種返工，降低軟件開發(fā)的成本；

3.通過測試發(fā)現(xiàn)所要交付產(chǎn)品的缺陷，特別是盡可能地發(fā)現(xiàn)各種嚴(yán)重的缺陷，降低或消除產(chǎn)品質(zhì)量風(fēng)險，提高客戶的滿意度，擴(kuò)大市場份額，提高客戶的忠誠度。

4.通過對缺陷進(jìn)行分析，找出缺陷發(fā)生的根本原因（軟件過程中的問題，包括錯誤的行為方式）或總結(jié)出軟件產(chǎn)品的缺陷模式，避免將來犯同樣的錯誤或產(chǎn)生類似的產(chǎn)品問題，達(dá)到缺陷預(yù)防的目的

２。初級軟件測試工程師主要工作

２。１編寫功能測試用例

１）測試用例設(shè)計步驟

設(shè)計測試案例的時候，需要有清晰的測試思路，對要測試什么，按照什么順序測試，覆蓋哪些需求做到心中有數(shù)。測試用例編寫者不僅要掌握軟件測試的技術(shù)和流程，而且要對被測軟件的設(shè)計、功能規(guī)格說明、用戶試用場景以及程序/模塊的結(jié)構(gòu)都有比較透徹的理解。測試用例設(shè)計一般包括以下幾個步驟：

1、測試需求分析

從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點(diǎn)是：包含軟件需求，具有可測試性。

測試需求應(yīng)該在軟件需求基礎(chǔ)上進(jìn)行歸納、分類或細(xì)分，方便測試用例設(shè)計。測試用例中的測試集與測試需求的關(guān)系是多對一的關(guān)系，即一個或多個測試用例集對應(yīng)一個測試需求。

2、業(yè)務(wù)流程分析

軟件測試，不單純是基于功能的黑盒測試，還需要對軟件的內(nèi)部處理邏輯進(jìn)行測試。為了不遺漏測試點(diǎn)，需要清楚的了解軟件產(chǎn)品的業(yè)務(wù)流程。建議在做復(fù)雜的測試用例設(shè)計前，先畫出軟件的業(yè)務(wù)流程。如果設(shè)計文檔中已經(jīng)有業(yè)務(wù)流程設(shè)計，可以從測試角度對現(xiàn)有流程進(jìn)行補(bǔ)充。如果無法從設(shè)計中得到業(yè)務(wù)流程，測試工程師應(yīng)通過閱讀設(shè)計文檔，與開發(fā)人員交流，最終畫出業(yè)務(wù)流程圖。業(yè)務(wù)流程圖可以幫助理解軟件的處理邏輯和數(shù)據(jù)流向，從而指導(dǎo)測試用例的設(shè)計。

從業(yè)務(wù)流程上，應(yīng)得到以下信息：

A、 主流程是什么

B、 條件備選流程是什么

C、 數(shù)據(jù)流向是什么

D、 關(guān)鍵的判斷條件是什么

3、測試用例設(shè)計

完成了測試需求分析和軟件流程分析后，開始著手設(shè)計測試用例。測試用例設(shè)計的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等。在用例設(shè)計中，除了功能測試用例外，應(yīng)盡量考慮邊界、異常、性能的情況，以便發(fā)現(xiàn)更多的隱藏問題。

黑盒測試的測試用例設(shè)計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用例設(shè)計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里主要討論黑盒測試。在設(shè)計測試用例的時候可以使用軟件測試用例設(shè)計方法，結(jié)合前面的需求分析和軟件流程分析進(jìn)行設(shè)計：

功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。

適合的技術(shù)：由業(yè)務(wù)需求和設(shè)計說明導(dǎo)出的功能測試、等價類劃分

邊界測試：對某個功能的邊界情況進(jìn)行測試。

適合的技術(shù)：邊界值劃分

異常測試：對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是可能發(fā)生的，類似這樣的情況需要書寫相關(guān)的異常測試。

適合的技術(shù)：由業(yè)務(wù)需求和設(shè)計說明導(dǎo)出的特殊業(yè)務(wù)流程、錯誤猜測法、邊界值分析、內(nèi)部邊界值測試、

性能測試：檢查系統(tǒng)是否滿足在需求中所規(guī)定達(dá)到的性能，性能主要包括了解程序的內(nèi)外部性能因素。內(nèi)部性能因素包括測試環(huán)境的配置，系統(tǒng)資源使用狀況；外部因素包括響應(yīng)時間，吞吐量等。

適合的技術(shù)：業(yè)務(wù)需求和設(shè)計說明導(dǎo)出的測試

壓力測試：壓力測試又稱強(qiáng)度測試，主要是檢查系統(tǒng)運(yùn)行環(huán)境在極限情況下軟件運(yùn)行的能力，比如說給一個相當(dāng)大的負(fù)荷或網(wǎng)絡(luò)流量給應(yīng)用軟件兼容測試：測試軟件產(chǎn)品在不同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

測試用例設(shè)計完成后，為了確認(rèn)測試過程和方法是否正確，是否有遺漏的測試點(diǎn)，需要進(jìn)行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設(shè)計者、測試leader、項(xiàng)目經(jīng)理、開發(fā)工程師、其它相關(guān)開發(fā)測試工程師。測試用例評審?fù)戤?，測試工程師根據(jù)評審結(jié)果，對測試用例進(jìn)行修改，并記錄修改日志。

5、測試用例更新完善

測試用例編寫完成之后需要不斷完善，軟件產(chǎn)品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發(fā)現(xiàn)設(shè)計測試用例時考慮不周，需要對測試用例進(jìn)行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進(jìn)行完善。一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應(yīng)隨之編制升級更新版本。測試用例是“活”的，在軟件的生命周期中不斷更新與完善。

２）測試用例設(shè)計方法

黑盒測試的測試用例設(shè)計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用例設(shè)計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里，主要討論的是黑盒測試的測試用例的設(shè)計方法。

一、等價類劃分

等價列劃分設(shè)計方法是把所有可能的輸入數(shù)據(jù)劃分成若干部分（子集），然后從每一個子集中選取少量具有代表性的數(shù)據(jù)作為測試用例，測試某等價類的代表值就等于對這一類其他值的測試。

使用等價類劃分方法設(shè)計測試用例主要有兩個步驟：（1）確定等價類；（2）生成測試用例。

1、劃分等價類

等價類劃分有兩種不同的情況：有效等價類代表對程序的有效輸入和無效等價類代表不正確的輸入值，設(shè)計時要同時考慮這兩種等價類。下面是確定等價類的原則：

（1）在輸入條件規(guī)定了取值范圍的情況下，則可以確立一個有效等價類（在取值范圍之內(nèi)）和兩個無效等價類（小于取值范圍和大于取值范圍）。 例如：使用手機(jī)發(fā)送短信的時候，短信內(nèi)容長度必須在70個字符之內(nèi)，則有效等價類：短信內(nèi)容長度在70個字符之內(nèi)，無效等價類：短信內(nèi)容長度為0、短信內(nèi)容長度大于70。

（2）在輸入條件規(guī)定了取值的個數(shù)的情況下，則可以確立一個有效等價類（在取值個數(shù)范圍之內(nèi)）和兩個無效等價類（小于取值個數(shù)和大于取值個數(shù)）。例如：一名學(xué)生一個學(xué)期可以選修一至五門課程，則有效等價類為：1《=學(xué)生選修課程《=5，無效等價類為：沒有選修課程、選修課程大于5

（3）在輸入條件規(guī)定了輸入值的集合的情況下，則可以確立一個有效等價類和一個無效等價類。 比如：發(fā)送短信的編碼的取值范圍是0、3、4、8、15或16，則有效等價類是：短信編碼為0或3或4或8或15或16，無效等價類是：短信編碼不是0或3或4或8或15或16其中任何一種。

（4）在輸入條件規(guī)定了 “必須如何”的條件的情況下，則可以確立一個有效等價類和一個無效等價類。 例如：變量的命名比如以大寫字母開頭，則有效等價類為：變量命名以大寫字母開頭，無效等價類為：變量開頭非答寫字母開頭。

（5）在輸入條件是一個布爾量的情況下，可以確立一個有效等價類和一個無效等價類。 例如：在神州行手機(jī)號碼預(yù)扣費(fèi)成功的情況下，允許該用戶發(fā)送短信，則有效等價類為：神州行預(yù)扣費(fèi)成功，無效等價類為神州行預(yù)扣費(fèi)失敗。

（6）在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個），并且程序要對每一個輸入值分別處理的情況下，可以確立n個有效等價類和一個無效等價類。

（7）在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。

（8） 在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應(yīng)再將該等價類進(jìn)一步的劃分為更小的等價類。

2、生成測試用例

在確立了等價類后，可建立等價類表，列出所有劃分出的等價類，過程為：

（1）為每一個等價類規(guī)定一個唯一的編號。

（2）設(shè)計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復(fù)這一步，直到所有的有效等價類都被覆蓋為止。

（3）設(shè)計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復(fù)這一步，直到所有的無效等價類都被覆蓋為止。

二、邊界值分析法

邊界條件指的是輸入和輸入等價類中剛好處于邊界、或超過邊界或小于邊界的狀態(tài)，使用邊界值分析方法設(shè)計測試用例應(yīng)先確定邊界情況，然后選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)。

基于邊界值分析方法選擇測試用例的原則：

（1）如果輸入條件規(guī)定了值的范圍，則應(yīng)取剛達(dá)到這個范圍的邊界值設(shè)計有效測試用例，以及剛剛超過這個范圍的邊界值作設(shè)計無效測試用例。比如：短信內(nèi)容的有效長度為70個漢字以內(nèi)，則有效測試用例：短信內(nèi)容長度為1，短信內(nèi)容長度為70個漢字，無效測試用例：短信內(nèi)容長度為0，短信內(nèi)容長度為71個漢字。

（2）如果輸入條件規(guī)定了值的數(shù)量，則應(yīng)取最大個數(shù)、最小個數(shù)、比最小個數(shù)少一、比最大個數(shù)多一的數(shù)作為測試輸入的數(shù)據(jù)。 例如：短信的有效編碼為1~255，則應(yīng)取0、1、255、256設(shè)計邊界值測試用例。

（3）根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則1。

（4）根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則2。

（5）如果程序的輸入或輸出是一個有序集合，則應(yīng)選取集合的第一個元素和最后一個元素設(shè)計測試用例。

（6）如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，應(yīng)當(dāng)選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)邊界上的值設(shè)計測試用例。

（7）分析規(guī)格說明書，找出其他可能的邊界條件。

三、因果圖法

因果圖法是一種適合于描述對于多種條件的組合、相應(yīng)產(chǎn)生多個動作的形式的測試用例設(shè)計方法。

利用因果圖生成測試用例的步驟為：

（1）將規(guī)范說明書分解成可執(zhí)行的片段。

（2）確定規(guī)格說明書中的因果關(guān)系。分析軟件規(guī)格說明描述中那些是原因，那些是結(jié)果，并給每個原因和結(jié)果賦予一個標(biāo)識符。

（3）分析軟件規(guī)格說明描述的語義，找出原因和結(jié)果之間、原因和原因之間的關(guān)系，并將其轉(zhuǎn)換成因果圖。

（4）在因果圖上加上注解符號，用一些記號表明約束或限制條件。

（5）跟蹤圖中的狀態(tài)變化情況，把因果圖轉(zhuǎn)換為判定表。

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

四、錯誤推測法

錯誤推測法就是根據(jù)經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯誤，從而有針對性地設(shè)計測試用例的方法。

錯誤推測法的基本思路是列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的清單，根據(jù)清單設(shè)計測試用例；另一個思路就是在閱讀規(guī)格說明時有哪些容易被程序員忽略的內(nèi)容來設(shè)計測試用例。

錯誤推測法是一種非常有效的測試用例設(shè)計方法，這要求測試人員有豐富的測試經(jīng)驗(yàn)和對業(yè)務(wù)的處理非常熟悉。比如，在短信發(fā)送的時候，如果發(fā)送短信之后，對方網(wǎng)關(guān)沒有響應(yīng)或者超時響應(yīng)或者沒有回復(fù)狀態(tài)報告，那程序怎樣處理呢？

進(jìn)階參考：

測試用例設(shè)計

http://www.cnblogs.com/mayingbao/category/82529.html

如何編寫有效測試用例

http://blog.csdn.net/smilings/article/details/840917

２。２執(zhí)行功能測試

根據(jù)測試計劃和測試用例進(jìn)行測試，在測試過程中記錄測試結(jié)果和提交發(fā)現(xiàn)的Bug。下班前將當(dāng)天的測試情況匯報給測試組長或測試經(jīng)理。

２。３提交Bug

２。２.１Bug基本概念

１）BUG的定義

BUG：（小錯誤，缺陷，不足，過失 …） 一個計算機(jī)bug指在計算機(jī)程序中存在的一個錯誤（error）、缺陷（flaw）、疏忽（mistake）或者故障（fault），這些bug使程序無法正確的運(yùn)行。Bug產(chǎn)生于程序的源代碼或者程序設(shè)計階段的疏忽或者錯誤。

Defect：（缺陷） 在軟件工程（Software Engineering）中，軟件與它的需求（requirements）不一致，常常指軟件無法正確完成需求所要求的功能，也稱之為bug。

２）BUG分級－嚴(yán)重性

我們一般把發(fā)現(xiàn)的錯誤（Bug）/缺陷（Defect）按嚴(yán)重性分為4類：

1.嚴(yán)重：系統(tǒng)崩潰或掛起等導(dǎo)致系統(tǒng)不能繼續(xù)運(yùn)行；

2.主要：使系統(tǒng)不穩(wěn)定、或破壞數(shù)據(jù)、或產(chǎn)生錯誤結(jié)果，而且是常規(guī)操作中經(jīng)常發(fā)生或非常規(guī)操作中不可避免的主要問題；

3.次要：系統(tǒng)性能或響應(yīng)時間變慢、產(chǎn)生錯誤的中間結(jié)果但不影響最終結(jié)果等影響有限的問題，如：顯示不正確但輸出正確；

4.輕微：界面拼寫錯誤或用戶使用不方便等小問題或需要完善的問題；

３）BUG分級－優(yōu)先級

我們也把發(fā)現(xiàn)的錯誤按優(yōu)先級分為三種：

1.高：立即修改；

2.中：必須修改，但不一定馬上修改；

3.低：允許不修改；

一般來說是越影響用戶接受或使用該產(chǎn)品的錯誤優(yōu)先級越高。

２。２.２怎樣提交Bug

首先，確保你所發(fā)現(xiàn)的問題是確實(shí)是一個bug，不要出現(xiàn)因?yàn)闇y試人員操作錯誤或配置錯誤所引起的“bug”，這樣會降低你在開發(fā)人員心中的可信度。在測試的時候，如果發(fā)現(xiàn)測試的實(shí)際結(jié)果與預(yù)期測試結(jié)果不符時，不要著急馬上報bug，先想想為什么會出現(xiàn)錯誤。作為專業(yè)的測試人員，應(yīng)該能夠?qū)Τ霈F(xiàn)的問題進(jìn)行跟蹤，確認(rèn)了在配置、操作沒有錯誤的前提下，通過追蹤分析確認(rèn)所測試的業(yè)務(wù)流程確實(shí)是存在bug，并能大概對bug的產(chǎn)生原因進(jìn)行定位。測試人員，需要做到專業(yè)，盡量少給開發(fā)找麻煩，不要制造實(shí)際上并不存在的bug。

確認(rèn)了所發(fā)現(xiàn)的問題是一個bug之后，按照測試步驟再執(zhí)行一次，確保bug是可重現(xiàn)的而不是隨機(jī)的。如果bug不能重現(xiàn)，應(yīng)該盡量找到bug重現(xiàn)的規(guī)律，在一些比較難重現(xiàn)的問題可以找開發(fā)配合一起查找原因，如果還是無法重現(xiàn)則需要在bug report中對出現(xiàn)的問題描述清楚并說明出現(xiàn)的隨機(jī)性。

接下來就是填寫bug report了，在填寫bug report的時候，最重要的是bug的標(biāo)題和bug描述。在bug報告中，首先用一句話對bug進(jìn)行簡要精確的描述作為bug的標(biāo)題，讓開發(fā)或項(xiàng)目經(jīng)理一看就知道存在什么問題，比如“XX模塊在壓力測試2小時后出現(xiàn)內(nèi)存泄露”。而在bug的描述中，需要使用簡明準(zhǔn)確的語言描寫出現(xiàn)bug的測試步驟、實(shí)際的測試結(jié)果、預(yù)期的測試結(jié)果和結(jié)論；也就是說描述導(dǎo)致出現(xiàn)bug的操作步驟是怎樣，由測試步驟所做的操作引起的測試結(jié)果是什么，而預(yù)期的結(jié)果應(yīng)該是怎樣，并由實(shí)際結(jié)果與預(yù)期結(jié)果相對比說明問題所在。比如：“在管理網(wǎng)頁新增用戶，當(dāng)新增的用戶登錄名名稱很長（例如登錄名長度為輸入框允許的最大長度），按‘新增’按紐新增后系統(tǒng)提示已經(jīng)有該用戶存在，而事實(shí)上該用戶并不存在，建議對超長的用戶名進(jìn)行處理?！?/p>

在測試人員發(fā)現(xiàn)了一個已隔離的，可重現(xiàn)的問題后，應(yīng)該對問題進(jìn)行歸納。同一個問題是否出現(xiàn)在其他的模塊或其他的流程？同一個故障是否會引起更加嚴(yán)重的問題？如果存在，也需要提出來讓開發(fā)一并處理。

在開發(fā)對bug進(jìn)行修改之后，測試需要報著懷疑的態(tài)度認(rèn)真地對問題進(jìn)行驗(yàn)證，需要嚴(yán)格按照測試步驟來進(jìn)行測試，檢查開發(fā)是否已經(jīng)正確修改了所出現(xiàn)的問題，以及開發(fā)對bug進(jìn)行了修復(fù)之后是否會引進(jìn)新的問題。不要相信開發(fā)說“已經(jīng)修改好了，肯定沒問題了”就不對問題進(jìn)行細(xì)致的檢查了，如果開發(fā)修改得不徹底，問題仍然會存在的，或者可能會由于開發(fā)在修改bug的時候忽略了另一些細(xì)節(jié)導(dǎo)致了新bug的出現(xiàn)。盡量不要在關(guān)閉bug之后，才發(fā)現(xiàn)這個問題還沒有修改徹底；也不要出現(xiàn)bug關(guān)閉之后，出現(xiàn)了新的bug。

測試對bug進(jìn)行驗(yàn)證確認(rèn)已經(jīng)修改ok之后，關(guān)閉bug。在關(guān)閉的時候，應(yīng)該對Bug最終修改結(jié)果進(jìn)行簡要描述，如果bug的修改引起配置或數(shù)據(jù)庫或業(yè)務(wù)流程的變更，也需要在bug關(guān)閉描述中進(jìn)行說明。

進(jìn)階參考：

如何編寫有效bug報告

http://blog.csdn.net/smilings/article/details/840840

準(zhǔn)確報告軟件缺陷

http://blog.csdn.net/kerryzhu/article/details/1436398

２。３編寫功能測試報告

測試報告是測試人員在測試過程中用于反映測試狀況的文檔。其實(shí)測試報告的內(nèi)容基本都是模板的那些，只是在實(shí)際測試過程中，如何去整理內(nèi)容結(jié)構(gòu)，使得報告的通常閱讀者：開發(fā)人員、測試經(jīng)理、產(chǎn)品經(jīng)理、項(xiàng)目負(fù)責(zé)人能夠一目了然地查看想要了解的內(nèi)容才是測試報告最值得注意的地方。

產(chǎn)品要想有廣闊的市場，得需要切實(shí)了解用戶的需求及感受，同理測試報告要想能夠讓閱讀者能夠滿意，也需要能將質(zhì)量情況條理性地列出。通常來說，開發(fā)人員往往希望能從報告中了解缺陷的情況，而測試經(jīng)理還關(guān)心用例的執(zhí)行情況及覆蓋率、項(xiàng)目責(zé)任人則最關(guān)心還有多少問題，此次版本是否測試通過。因此測試報告根據(jù)內(nèi)容的側(cè)重點(diǎn)，分為『版本測試報告』和『總結(jié)測試報告』，目的也是希望不將所有內(nèi)容列舉在一個報告中，造成內(nèi)容臃腫繁雜。

總體來說，功能測試報告的編寫就是要做到簡約而不簡單。

版本測試報告

ü 主要反映開發(fā)人員提交的測試版本的質(zhì)量狀況。

ü 測試用例設(shè)計與執(zhí)行、缺陷概況及問題概要是版本測試報告中的主要內(nèi)容。

ü 測試人員在每個輪次測試結(jié)束時編寫提交。

其內(nèi)容結(jié)構(gòu)和每個章節(jié)的編寫內(nèi)容說明如下：

大綱

子章節(jié)

詳細(xì)內(nèi)容

測試簡介

測試目的

本次測試的背景及主要內(nèi)容

測試資源

測試人員、本次測試開始和截止日期、花費(fèi)工作日

測試環(huán)境

硬件環(huán)境

實(shí)際情況的詳細(xì)列舉，過低的配置、軟件版本的不匹配、網(wǎng)絡(luò)拓?fù)涞腻e誤都會讓提交的缺陷缺乏說服力，也會讓開發(fā)人員對于某些缺陷是否由于環(huán)境因素導(dǎo)致而產(chǎn)生疑惑。

軟件版本

網(wǎng)絡(luò)拓?fù)鋱D

測試方法

無

本次測試的功能點(diǎn)、各功能點(diǎn)對應(yīng)的測試用例設(shè)計、測試用到的測試工具

測試用例

用例分析

測試用例維護(hù)記錄

用例執(zhí)行情況

用例執(zhí)行總數(shù)、通過用例數(shù)、未通過用例數(shù)、阻塞用例數(shù)

測試執(zhí)行率=（已執(zhí)行的用例數(shù)）/用例總數(shù)

測試用例效率=發(fā)現(xiàn)的缺陷總數(shù)/測試用例的數(shù)量

測試過程

缺陷統(tǒng)計

新建bug數(shù)、修復(fù)bug數(shù)、未修復(fù)bug數(shù)、bug總數(shù)

問題摘要

遺留問題、拒絕問題、掛起問題、長期驗(yàn)證問題、待評估問題

測試結(jié)果

資源占用

測試項(xiàng)目的啟動、退出時間

測試項(xiàng)目的CPU占用率初始值、峰值（如果項(xiàng)目啟動會有多個進(jìn)程，則分多個進(jìn)程進(jìn)行統(tǒng)計）

測試項(xiàng)目的內(nèi)存占用初始值、峰值

測試結(jié)論

測試結(jié)論不論僅僅只是測試通過或不通過，應(yīng)該使用詳細(xì)的數(shù)據(jù)來支持測試結(jié)論，需要列舉的數(shù)據(jù)有：

『測試用例通過率』

總用例

未通過用例

未通過比率

『遺留bug情況』

總bug數(shù)

未修復(fù)bug

遺留bug率

備注

用例執(zhí)行記錄

插入測試用例的詳細(xì)執(zhí)行結(jié)果文檔

資源監(jiān)控記錄

說明資源占用監(jiān)控的場景，詳細(xì)列舉各場景的監(jiān)控時長、監(jiān)控內(nèi)容，場景操作

總結(jié)測試報告

ü 主要偏重于各已測試版本的缺陷變化分析，風(fēng)險預(yù)估。

ü 各測試版本質(zhì)量情況概況統(tǒng)計、缺陷分布統(tǒng)計、風(fēng)險分析是總結(jié)測試報告中的主要內(nèi)容。

ü 測試人員在項(xiàng)目發(fā)布上線前編寫提交。

其內(nèi)容結(jié)構(gòu)和每個章節(jié)的編寫內(nèi)容進(jìn)行說明如下：

標(biāo)題

子章節(jié)

詳細(xì)內(nèi)容

測試簡介

測試目的

本次測試的背景及主要內(nèi)容

測試資源

測試人員、第一輪測試的開始日期和最后一輪測試的截止日期、總共花費(fèi)工作日統(tǒng)計

測試環(huán)境

硬件環(huán)境

實(shí)際情況的詳細(xì)列舉，過低的配置、軟件版本的不匹配、網(wǎng)絡(luò)拓?fù)涞腻e誤都會讓提交的缺陷缺乏說服力，也會讓開發(fā)人員對于某些缺陷是否由于環(huán)境因素導(dǎo)致而產(chǎn)生疑惑。

軟件版本

網(wǎng)絡(luò)拓?fù)鋱D

測試過程

各版本測試狀況

各測試版本的計劃提交日期、實(shí)際提交日期、測試類型（回歸或全量）、測試耗時、備注（被打回或提交補(bǔ)丁次數(shù)）

各版本bug統(tǒng)計

各測試版本的新建bug數(shù)、修復(fù)bug數(shù)、遺留bug數(shù)，表格統(tǒng)計、線形圖或餅狀圖輔助表示

測試分析

缺陷分析

缺陷的總體分布情況，以線形圖或餅狀圖輔助表示

2 根據(jù)功能模塊進(jìn)行劃分

2 根據(jù)嚴(yán)重、較嚴(yán)重、普通、輕微級別進(jìn)行劃分

遺留問題

打開狀態(tài)bug、長期驗(yàn)證bug、用戶體驗(yàn)問題

測試小結(jié)

資源占用

測試項(xiàng)目的啟動、退出時間

測試項(xiàng)目的CPU占用率初始值、峰值（如果項(xiàng)目啟動會有多個進(jìn)程，則分多個進(jìn)程進(jìn)行統(tǒng)計）

測試項(xiàng)目的內(nèi)存占用初始值、峰值

風(fēng)險分析

測試進(jìn)度、人員安排導(dǎo)致的風(fēng)險

測試內(nèi)容考慮范圍之外導(dǎo)致的風(fēng)險

測試環(huán)境不全面導(dǎo)致的風(fēng)險

其他因素導(dǎo)致的風(fēng)險

進(jìn)階參考：

軟件測試階段報告編寫指南

http://blog.csdn.net/smilings/article/details/1032221

軟件測試報告編寫指南

http://blog.csdn.net/smilings/article/details/1032246

３。測試牛人Randall W.Rice給測試新手的話

前言

因?yàn)橐呀?jīng)帶領(lǐng)和訓(xùn)練測試團(tuán)隊(duì)多年，所以按慣例我總有些東西確定需要傳達(dá)給測試新手。不管你是一個測試新手還是一個經(jīng)驗(yàn)豐富的測試專家，都有不少有益的東西需要牢記在心。

1、你是一個檢查者，你不需要為質(zhì)量負(fù)責(zé)

很多測試人員誤入歧途，不明白他們是評測產(chǎn)品的而不是控制產(chǎn)品的。這兩者之間有著天壤之別。例如，一個測試團(tuán)隊(duì)花費(fèi)好幾周時間測試并發(fā)現(xiàn)很多缺陷，只是為了看著管理層決定發(fā)布一個有已知嚴(yán)重缺陷的產(chǎn)品。測試團(tuán)隊(duì)經(jīng)常會感到士氣受挫，置疑他們測試的目的。

我詢問團(tuán)隊(duì)中的成員他們是否被支付薪水了，通常得到的回答都是“是”。我又詢問他們是否盡力去做工作了，再一次，通常得到的回答都是“是”。我于是告訴他們，“你們做了你們的工作。你們盡力測試，發(fā)現(xiàn)了缺陷并進(jìn)行了上報。那么現(xiàn)在可以回家休息了。實(shí)際上，作為一名測試人員唯一失敗的地方是不上報一個已知的缺陷?！?/p>

這不會提高士氣，但卻有助于事情向正確的方向發(fā)展，特別是能讓人不用每天晚上都在家接著辦公。

很多測試人員，包括我，當(dāng)我們剛開始測試工作時，似乎會覺得自己對我們所測試的系統(tǒng)應(yīng)用的質(zhì)量負(fù)責(zé)。盡管這個工作的出發(fā)點(diǎn)是讓人欽佩的，可實(shí)際上我們測試人員對于產(chǎn)品的質(zhì)量基本沒有控制能力。也是由于這個原因，測試人員不為質(zhì)量負(fù)責(zé)?，F(xiàn)在問題是管理層并不總是能看到這種區(qū)別。所以經(jīng)?？匆姽芾韺犹岢鲱愃朴凇拔覀兏跺X給這些人不是為了獲得高質(zhì)量的軟件嗎？”的問題。

2、缺陷都是有價值的

每一個缺陷都是深入了解和提高的機(jī)會。我們可能只有一次機(jī)會觀察到一個缺陷，所以我總是告訴測試人員始終保持高度注意力，不要為測試的乏味所折磨。

缺陷信息可能是可獲取的項(xiàng)目數(shù)據(jù)中最有效的資源之一。但是這都取決于我們能多好的捕捉和傳達(dá)我們所發(fā)現(xiàn)的缺陷的相關(guān)信息。

每個缺陷都會花費(fèi)整個組織的金錢。如果我們不能從中更進(jìn)一步了解產(chǎn)品，我們會浪費(fèi)大量時間和金錢。當(dāng)我們把一個錯誤轉(zhuǎn)換成一次深入了解的機(jī)會時杠桿作用就出現(xiàn)了。讓我們面對它――有些教訓(xùn)只能通過經(jīng)歷來學(xué)習(xí)的。

由于一個缺陷而責(zé)備誰不會有任何好的作用。責(zé)備只會讓士氣低落、溝通中斷。這就像不斷鞭打一匹死馬希望它能活過來一樣。

3、你報告第一個問題之前一切都是美好的

這就是一個測試人員所面對的現(xiàn)實(shí)。你可以計劃測試，獲取所需要的資源，看起來所有人都站在你這邊?？僧?dāng)你報告第一個問題之后，事情就開始變得緊張了。

出現(xiàn)這種態(tài)度上的突然變化的原因是現(xiàn)在你在批評某些人的工作了。自尊心使得自我收到傷害，關(guān)系變得緊張。有些情況下自尊心是值得期盼的，只要知道當(dāng)你開始發(fā)現(xiàn)問題的時候態(tài)度有可能變化就可以了。

我經(jīng)常建議測試人員做的一件事是讀一讀一些你過去寫的缺陷報告，假設(shè)自己是接收缺陷報告的人。你會發(fā)現(xiàn)自己需要更老練一些。寫一個沒有任何挖苦語句的缺陷報告可能沒什么樂趣，但它的確有助于和開發(fā)人員之間保持一個好的關(guān)系。

4、只能測試你能觀察的

你可能總想測試一些真正有創(chuàng)造性的用例，但如果你沒有辦法觀察到結(jié)果，那有什么意義？盡管有些應(yīng)用讓你能觀察到很多，但仍然有你沒辦法接近的，例如結(jié)構(gòu)、隱藏的對象、后臺進(jìn)程等。

5、別忘記你是怎樣到一個地方的

我不是在談?wù)撝罏槭裁茨阕哌M(jìn)一個房間，而是在測試時執(zhí)行的步驟。對于測試新手常見的是發(fā)現(xiàn)了一個重大的缺陷，但卻無法復(fù)現(xiàn)它以便定位解決。這樣你只會覺得不舒服，不知道自己到底是真發(fā)現(xiàn)了一個缺陷，還是說僅僅是錯誤的使用了應(yīng)用。

你能用來跟蹤你的測試步驟的方法有測試腳本、測試記錄、敲鍵記錄器如Spector和屏幕視頻捕捉工具如Hypercam。

6、標(biāo)準(zhǔn)和流程是你的朋友

盡管標(biāo)準(zhǔn)和流程讓一些人覺得受限，但它們?yōu)槟愕墓ぷ魈峁┝擞袃r值的指導(dǎo)。不要拒絕標(biāo)準(zhǔn)因?yàn)樗鼈兪窃敿?xì)的、具體的。因此用它們指導(dǎo)自己更快、更一致的完成自己的工作。

7、沒有足夠的時間用于測試

幾乎每一個測試人員都抱怨沒有足夠的時間用于測試，但實(shí)際情況是測試任何東西到完整的程度都是不可能有充足時間的。當(dāng)你充分考慮軟件的特性如可用性、安全性、兼容性、互操作性等時這一點(diǎn)尤其正確。

不要再抱怨缺少時間，學(xué)會根據(jù)風(fēng)險來進(jìn)行優(yōu)先級排序，把注意力都放在對管理層很重要的應(yīng)用目標(biāo)上。有時候我們測試的內(nèi)容超出了我們需要測試的，因?yàn)槲覀兊哪繕?biāo)偏離了產(chǎn)品的價值。

8、你不可能發(fā)現(xiàn)所有的缺陷

如果你測試的東西后來有缺陷被發(fā)現(xiàn)，不要變得氣餒。你可能已經(jīng)做了非常全面的工作，獲得了高水平的缺陷移除，但100%都是不可能的目標(biāo)。

9、保持幽默感和對前景充滿信心

經(jīng)常微笑、保持健康可能是你最好的生存方式。如果你正處在困難條件下，請相信，這一切都將過去。

10、爭取做到最好而不是完美

測試新手經(jīng)常會陷入追求完美的過程中，認(rèn)為100%的正確才是標(biāo)準(zhǔn)。我曾經(jīng)也是受害者之一，但要為自己辯護(hù)的是，我以前深受80年代后期類似于“99.9%還不夠好”的TQM帖子和文章的影響。

追求完美的問題在于它會讓測試進(jìn)程變慢，將擔(dān)心引入你所做的一切，使得你對別人更挑剔，而且通常會讓你的朋友和家人感到失望。

當(dāng)然，沒人愿意犯錯誤，但他們稍不注意就出現(xiàn)了。想不犯錯誤就是否認(rèn)現(xiàn)實(shí)。爭取做到最好是一種好的習(xí)慣，表明你對工作的態(tài)度和投入程度。如果你想努力做到最好，你就會往前再多走一點(diǎn)。

根據(jù)我的觀察，大多數(shù)人看到錯誤或者經(jīng)歷失誤時都是很寬容的。人們最關(guān)心的是你對待問題的反應(yīng)。

11、開發(fā)人員不是敵人

需要整個項(xiàng)目團(tuán)隊(duì)的努力才能遞交高質(zhì)量的產(chǎn)品。有時候似乎開發(fā)人員不太關(guān)心質(zhì)量，這個時候事情背后可能存在隱情。這時候你需要更好的和開發(fā)人員合作而不是反對他們。要始終牢記良好的交流是一個項(xiàng)目成功的關(guān)鍵因素。當(dāng)你和開發(fā)人員站到對立面時，交流就停止了，你測試所需的很多信息也無法獲取了。

12、建立和維護(hù)一個私人的交際網(wǎng)

你的私人工作關(guān)系是一個很重要的資產(chǎn)。無論時當(dāng)你有工作時還是當(dāng)你沒工作時他們都是一個很好的支持系統(tǒng)。找一個好的指導(dǎo)者，而當(dāng)你學(xué)到足夠的東西時成為別人的指導(dǎo)者。

13、持續(xù)鍛煉自己的技能

你的技能把你和別人區(qū)分開。始終通過參加專業(yè)會議、獲取認(rèn)證、閱讀專業(yè)資料等來不斷學(xué)習(xí)。我給自己制定的目標(biāo)是每周至少讀一本和個人發(fā)展以及職業(yè)發(fā)展相關(guān)的書（測試、領(lǐng)導(dǎo)藝術(shù)、商業(yè)、IT等）。

一個個人發(fā)展方面的專家說過如果你每天在任何特定的主題上花費(fèi)30分鐘進(jìn)行閱讀，五年之內(nèi)你肯定能成為這個主題方面的專家。這一點(diǎn)對我是起作用的――你也可以試試。

另一種讓自己始終內(nèi)行并建立網(wǎng)絡(luò)的好的方式是活躍在一些QA或者測試論壇上。

14、當(dāng)前進(jìn)變得困難，懶惰就需要創(chuàng)造力了

當(dāng)我第一次成為一個測試團(tuán)隊(duì)負(fù)責(zé)人時，我用這句話做了一個字條掛在我的桌上。它不斷提醒我把創(chuàng)造力作為我解決問題的一個杠桿。

學(xué)著從一個新的有創(chuàng)造性的方式來看待問題。你可能有一個好的測試計劃，但你如何應(yīng)付各種變化呢？彈性是一個優(yōu)秀的問題解決負(fù)責(zé)人的關(guān)鍵特性。

15、簡單并不總是很容易

我們測試中做的很多工作看起來都很簡單。但是，挑戰(zhàn)在于保持努力的連貫性。

有些解決問題的方式剛開始看起來很簡單，但不要由于它簡單和明顯就丟棄任何一種想法。同樣，不要低估實(shí)現(xiàn)一個簡單想法所需要付出的努力。

一些看過我和William E.Perry合著的書“Surviving the Top Ten Challenges of Software Testing”評論說這些挑戰(zhàn)都很簡單且很容易解決。這就讓我奇怪為什么人們還在年復(fù)一年的提出“人的問題”。我認(rèn)為在大腦中產(chǎn)生想法比實(shí)際實(shí)現(xiàn)出來要簡單的多。

結(jié)論

智慧比知識更重要。你可能已經(jīng)學(xué)習(xí)了大量測試技術(shù)，但如果你沒有足夠的智慧判斷什么時候采用它們，沒有從整體上理解它們，你應(yīng)用它們的能力將受到很大限制。對任何都有涉獵的你存在的一個問題是“你不知道什么你不知道”。智慧幫助你明白你需要知道哪些東西才能成功。

４。軟件測試工作求職

４。１測試人員面試時常見問題及問題背后的考核內(nèi)容分析

1）你最近3-5年的職業(yè)規(guī)劃是什么？

重點(diǎn)考察測試人員的職業(yè)發(fā)展方向是否與當(dāng)前職位招聘相符？ 從其中可以側(cè)面看出來其員工穩(wěn)定性。

2）一個項(xiàng)目測試結(jié)束，有沒什么經(jīng)驗(yàn)總結(jié)？如果有，具體是如何開展的？

重點(diǎn)考察測試人員對自己能力提升方面，有沒有提高總結(jié)的地方，從項(xiàng)目中吸取的經(jīng)驗(yàn)與教訓(xùn)。從中可以看出來，測試人員是否屬行自我驅(qū)動型人才！

3）為什么會選擇做測試這份工作？

重點(diǎn)考察測試人員對待測試工作的態(tài)度及是否有發(fā)展?jié)摿?？面試過很多測試人員，經(jīng)常見到的回答，自己是女孩子，做測試細(xì)心，各位你認(rèn)為這樣回答你會滿意嗎？其碼不是我想要的答案！

4）請說出一個你以前參與項(xiàng)目，對你測試經(jīng)驗(yàn)提升很高的，具體是哪方面？

重點(diǎn)考察測試人員在以往的測試工作中能力提升方面，有哪些？然后重點(diǎn)詢問此部分內(nèi)容，是否測試經(jīng)驗(yàn)增長，具備一定的深度？

5）通常做測試時會碰到，提交的某個bug開發(fā)人員不認(rèn)同你的觀點(diǎn)？這時你如何辦？

重點(diǎn)考察測試人員是否堅持自已的價值觀？是否具備協(xié)調(diào)溝通處理問題能力？

6）有沒有看過什么測試書，具體是哪本？帶給你的收獲是？

重點(diǎn)考察測試人員是否為測試這個職業(yè)肯付出多少？從中也可以看出這個測試人員是否上進(jìn)心？是否有求知心？我的定義是如果哪個應(yīng)聘者來面試時，都沒系統(tǒng)的看過一本測試書籍，基本上不會錄??！

7）如果安排一項(xiàng)測試技術(shù)研究工作，你如何應(yīng)對？

重點(diǎn)考察測試人員是否具體測試技術(shù)專研精神？是否喜歡接受挑戰(zhàn)？是否屬于以后培養(yǎng)骨干對象？

8）某個項(xiàng)目上線后，出現(xiàn)問題，恰巧你是負(fù)責(zé)的，你如何應(yīng)對這突如其來的事件？

重點(diǎn)考察測試人員應(yīng)對問題的壓力，責(zé)任感，及如何處理項(xiàng)目上線后的技術(shù)問題及應(yīng)對解決能力。

9）周末放假有什么業(yè)余愛好？

重點(diǎn)考察面試測試人員性格特質(zhì)，測試工作本身就是復(fù)雜且富有技術(shù)性的工作，而且不同的職位所需要的測試人員性格品質(zhì)差異性很大。

10）公司產(chǎn)品，具體應(yīng)用什么編程技術(shù)？具體的架構(gòu)是？具體的應(yīng)用場景有哪些？

重點(diǎn)考察測試人員對以往的工作所負(fù)責(zé)的產(chǎn)品測試，是否具備一定的深度！通常我都是讓面試者自己講述或是在紙上畫出具體系統(tǒng)架構(gòu)的圖！

11）公司測試團(tuán)隊(duì)的規(guī)模如何，具體你所處的角色是什么？

重點(diǎn)考察測試人員在以往的公司測試團(tuán)隊(duì)中，具體的工作職責(zé)，評判其工作是否與當(dāng)要求職位是否符合？是否有哪些優(yōu)缺點(diǎn)？

12）特定測試技術(shù)考察：性能測試，安全性測試，自動化測試等以前有開展過沒？如果有，具體是如何實(shí)施的？

重點(diǎn)考察測試人員技術(shù)能力，是否在各方面都有所涉及？或是在各方面技術(shù)上都有一定深度？當(dāng)然從中也能看出一個測試人員是否屬于是技術(shù)路線發(fā)展方向！

13）你自己所期待加入的測試團(tuán)隊(duì)是什么樣的？

重點(diǎn)考察測試人員在以前測試團(tuán)隊(duì)中有哪些不協(xié)調(diào)？當(dāng)然最重要的是也能提供給你一些信息，這個員工以后如何更好的管理與溝通！

５。軟件測試職業(yè)發(fā)展

1）技術(shù)方向

在技術(shù)方向上面，通常是初級測試工程師，中級測試工程師，高級測試工程師，資深測試工程師，專家等方向發(fā)展；當(dāng)然像國外技術(shù)分工比較細(xì)如：通常有白盒測試，黑盒測試，自動化測試，性能測試，安全測試，易用性測試等。

2）管理方向

在管理方向上面，通常是測試組長，測試主管，測試經(jīng)理，測試總監(jiān)等方向發(fā)展。

3）業(yè)務(wù)領(lǐng)域方向

在業(yè)務(wù)領(lǐng)域則取決于各測試人員所處行業(yè)，通常像金融，銀行，證券，ERP類的，通常有初級業(yè)務(wù)測試，中級業(yè)務(wù)測試，高級業(yè)務(wù)測試等。

４）其他方向

配置管理、質(zhì)量保證（QA）等