【文章內(nèi)容簡介】 所有審查中發(fā)現(xiàn)的缺陷都得到更正、所有問題都被解決以及各方的意見都達成一致之后，測試用例開發(fā)人員就可以將通過審查的測試用例文檔定稿了。7測試用例的有效性驗證當新的測試用例文檔定稿之后，我們還有必要對測試用例進行一次有效性驗證。這個過程可以在軟件的非正式測試版本上進行。由于測試結(jié)果并不作為任何正式測試輪次的報告，其作用只是驗證測試用例與待測產(chǎn)品的一致性及測試用例中所描述的測試環(huán)境等的有效性，所以測試用例的有效性驗證中并不要求將所有測試用例進行測試，只需要有代表性的挑選幾個能體現(xiàn)產(chǎn)品特性和環(huán)境有效性的用例進行測試即可。 開始執(zhí)行測試經(jīng)過以上幾個小節(jié)的準備工作，測試人員就即將進入軟件測試用例的執(zhí)行階段了。這時執(zhí)行測試用例活動的組織者(通常是測試組長)就應該開始安排測試輪次用例集合和測試用例執(zhí)行進度，分配測試任務(wù)。1．挑選測試用例組成測試輪次用例集合軟件測試用例的執(zhí)行有時不是一蹴而就，而可能會分為好幾個輪次。測試輪次用例集合指的是該輪次中需要執(zhí)行的測試用例的集合。各輪次的測試用例集合間可能使用的是同樣的測試用例，也可能是完全不同的測試用例。上一小節(jié)中我們完成的所有的測試用例套件在實際使用時通常作為一個測試用例的倉庫。測試輪次用例集合中的測試用例可以是從測試用例倉庫中挑選出來的一個或多個完整的測試用例套件的組合，也可以是從一些測試用例套件中挑選出來的測試用例的集合。例如，在為軟件的某一組件進行首次功能測試時，可以將這個組件的所有功能測試用例套件中的測試用例作為一個測試輪次的用例集合使用。又如，在為一個組件進行軟件功能的回歸測試時，因為回歸測試主要是針對軟件的改動而進行的，所以我們可能會從這個組件的所有功能測試用例套件中挑選一些與本次改動有直接或間接關(guān)系的測試用例作為一個測試輪次的用例集合使用，而非所有的功能測試用例套件中的測試用例。這樣的測試用例的挑選是基于測試階段、測試目的、測試日程安排、人力和物力資源情況、測試用例的覆蓋面等諸多資源來考慮的，這也是測試計劃和測試策略的一部分。因此，可以看出測試計劃和測試策略不是一旦編寫完成之后就束之高閣，一成不變的，因為在測試活動的進行中或多或少會遇上一些突發(fā)的情況，這樣就不可避免地修改測試日程安排、人力和物力資源分配等、從而需要修改測試計劃和測試策略。測試輪次用例集合準備好之后執(zhí)行測試用例活動的組織者就可以把集合中的測試用例分配給參與執(zhí)行測試的測試人員了。2．正式執(zhí)行測試前的軟件版本驗證工作? 開發(fā)團隊的版本驗證工作當開發(fā)人員的階段性代碼編寫工作完成之后，開發(fā)人員需要將新開發(fā)的代碼和現(xiàn)存的代碼集成并進行一遍完整的單元測試。當單元測試通過之后，開發(fā)人員需要將所有的代碼進行編譯以生成可執(zhí)行的軟件鏡像，需要注意的是，這時的可執(zhí)行軟件鏡像并不是可正式發(fā)布的版本。開發(fā)人員還應該對其進行冒煙測試，其原則是挑選該產(chǎn)品最具代表性的測試用例和新改動部分的代表性的測試用例作為冒煙測試的測試用例計劃。忽視冒煙測試的風險在于，當未經(jīng)過任何測試的可執(zhí)行軟件鏡像被作為新的軟件版本直接交付于測試團隊時，如果新的版本出現(xiàn)大面積退化，甚至是重大產(chǎn)品功能不能使用，則這個軟件版本將會被測試部門直接退回。這樣會增加大量增加開發(fā)團隊和測試團隊的溝通成本和時間成本，而且有損開發(fā)團隊的聲譽。? 測試團隊的版本驗證工作在新的可執(zhí)行軟件鏡像通過冒煙測試之后，該鏡像就成為測試團隊的可測版本的一個候選版本。所謂可測版本就是指該軟件版本沒有重大產(chǎn)品功能質(zhì)量問題并且新開發(fā)的產(chǎn)品功能無重大質(zhì)量問題(如新功能無法啟動或極度不穩(wěn)定等)等。測試團隊需要將一個剛接手的可執(zhí)行軟件鏡像作為可測版本的一個候選版本的原因在于，測試團隊并不能保證新的可執(zhí)行軟件鏡像一定符合本團隊的可測版本的要求且適合正式的測試環(huán)境。因此，此時測試團隊會將這個可執(zhí)行軟件鏡像列為可測版本的一個候選版本，并對其進行版本驗證測試(BVTBuild Verification Test)或稱作Sanity Test。其測試目的就是驗證候選版本是否符合可測版本的上述要求。如果不符合，則候選版本將被退回開發(fā)團隊。如果通過了版本驗證測試，則該可執(zhí)行軟件鏡像就成為了測試團隊的可測版本。例子有了這個教訓之后，開發(fā)和測試人員就開始在每一個新的版本正式測試之前進行軟件版本驗證工作了。這樣的版本驗證測試只會在少量的服務(wù)器上進行，并執(zhí)行很少的一些為版本驗證測試專門挑選的測試用例。因此大大地避免了由版本失敗帶來的大量的人力和時間的浪費。此后開發(fā)人員的出版本的速度也降到了一周一個，因為他們在做版本驗證測試時通常會發(fā)現(xiàn)一些自己也認為不可輕易放過的缺陷。此后的工作就變得對測試人員非常有利了。3．何時開始執(zhí)行測試當新的軟件版本通過了開發(fā)團隊和測試團隊的版本證后，測試人員就可以開始按照該測試輪次中所分配的測試用例對軟件產(chǎn)品進行測試了。 報告測試缺陷執(zhí)行測試用例階段也就是測試人員發(fā)現(xiàn)軟件缺陷的重要階段。一旦測試人員確定一個軟件的問題是軟件缺陷時，測試人員就有義務(wù)將其歸檔，并對該軟件缺陷進行跟蹤。大多數(shù)軟件生產(chǎn)企業(yè)都會有一個網(wǎng)絡(luò)化的缺陷管理跟蹤系統(tǒng)，企業(yè)內(nèi)部的各種缺陷都可以存檔于這個系統(tǒng)中。這些缺陷并不僅限于軟件缺陷，還可以是需求和設(shè)計文檔的缺陷，同時也可以是硬件缺陷，例如制造嵌入式產(chǎn)品的企業(yè)：甚至可以是對現(xiàn)有工作流程所提的缺陷。1．將軟件缺陷進行歸檔并對其進行跟蹤的意義? 縮短軟件缺陷被修復的周期 開發(fā)人員必須通過被歸檔的軟件缺陷的描述對缺陷進行復現(xiàn)、分析和修復。簡練)準確、信息完整的軟件缺陷描述可以大大縮短軟件缺陷被修復的周期。 ? 反映軟件的質(zhì)量 每一輪次的測試完成之后，測試人員都會生成該輪次的缺陷列表和該輪次測試用例的通過情況列表，根據(jù)這些列表所反映的情況可以對軟件的質(zhì)量情況做出客觀的評估。因此，軟件測試人員有時也被稱為軟件項目的探路明燈。 ? 經(jīng)驗總結(jié) 無論是測試完成后所生成的表格中的數(shù)據(jù)還是每一個被歸檔的測試用例，都可以被作為以后新的工作的基石。 2．既然軟件缺陷歸檔如此的重要，那么當軟件測試人員發(fā)現(xiàn)了一個軟件缺陷時應該如何有效地對缺陷進行報告呢？ ? 在報告一個軟件缺陷時應該盡量避免重復報告 有些軟件公司提供了強大的搜索工具來方便測試人員查詢是否已存在與自己即將報告的缺陷重復的記錄。這是一個非常好的實踐，因為大量重復的報告同一個缺陷不僅會增加開發(fā)人員閱讀和分析缺陷報告記錄的時間，還會大量增加開發(fā)人員和測試人員之間無謂的溝通次數(shù)。 ? 簡練準確的在缺陷的標題中描述該缺陷 很多公司的缺陷歸檔和跟蹤系統(tǒng)對缺陷的標題都有字數(shù)的限制，其目的在于養(yǎng)成測試人員能夠以簡練的語句描述缺陷的特征。這樣，開發(fā)人員在極短的時間內(nèi)通過查看缺陷的標題就可以判斷該缺陷是否已經(jīng)有人報告過，如果沒有則能很快定位軟件缺陷產(chǎn)生的位置和現(xiàn)象。 ? 一個缺陷報告記錄一個缺陷 這樣有利于開發(fā)人員的工作開展。如果一個缺陷報告記錄了兩個缺陷，而兩個缺陷又屬于不同的開發(fā)小組，這時通常會造成開發(fā)人員的修復工作無法開展，因為很難給這樣的缺陷定一個唯一的責任人。 ? 信息完整 測試人員應該將測試用例所用到的測試數(shù)據(jù)和測試執(zhí)行過程中所產(chǎn)生的一些文件作為附件附加在缺陷報告中。 ? 直觀形象的描述缺陷，提高缺陷重現(xiàn)率 詳細、精確地提供重現(xiàn)步驟并附加一些圖片、視頻等信息有助于開發(fā)人員更直觀地了解相關(guān)缺陷。 ? 客觀描述 報告軟件缺陷時應當客觀描述現(xiàn)象，避免主觀的評價，更不應該對開發(fā)人員的技術(shù)水平等做出評價。 3．缺陷報告的內(nèi)容 當測試人員發(fā)現(xiàn)了一個軟件缺陷時，就需要開始著手把這個軟件缺陷錄入到缺陷管理跟蹤系統(tǒng)中。錄入一個缺陷報告一般需要填寫下列內(nèi)容，如表12所示。表12 缺陷報告內(nèi)容缺陷屬性含義缺陷唯一標識缺陷管理跟蹤系統(tǒng)中對于每個缺陷的唯一標識，通常為系統(tǒng)自動生成報告時間缺陷報告生成的時間，通常為系統(tǒng)自動生成狀態(tài)標識一個缺陷當前所處的狀態(tài)，是缺陷生命周期的一環(huán)，并隨之演化而變更缺陷報告人填寫缺陷報告的測試工程師標題缺陷的總結(jié)，要求簡練準確，讓開發(fā)人員在極短的時間內(nèi)就可以判斷該缺陷是否已經(jīng)有人報道過；如果沒有，則能很快定位軟件缺陷產(chǎn)生的位置和現(xiàn)象所屬項目被測產(chǎn)品的項目名稱產(chǎn)品被測產(chǎn)品的產(chǎn)品內(nèi)部名稱組件缺陷所在的組件版本缺陷所在的軟件版本嚴重度客觀地從客戶的角度描述缺陷的嚴重程度。一般分為5級，通常由測試人員確定優(yōu)先級缺陷被修復的優(yōu)先級別。一般分為3~5級，通常由項目管理人員、開發(fā)組長、測試組長共同確定發(fā)現(xiàn)階段缺陷被發(fā)現(xiàn)時的測試階段起源階段該缺陷本該在何測試階段被發(fā)現(xiàn)。例如，一個繼承測試階段應該發(fā)現(xiàn)的組件接口方面的缺陷卻被遺留到了系統(tǒng)測試階段才被發(fā)現(xiàn)當前負責人缺陷在生命周期中的某一個階段的負責人。隨著缺陷狀態(tài)的改變，缺陷的負責人會從測試人員（如Open狀態(tài)）變成項目組成員（如Assigned狀態(tài)），然后變成開發(fā)人員（如Analysis或Fixing狀態(tài)），最后又回到測試人員手中（如Verified狀態(tài)）等詳細描述直觀、現(xiàn)象、完整地描述缺陷，提高缺陷重現(xiàn)率。詳細精確地提供重現(xiàn)步驟，附加一些圖片、視頻等信息有助于開發(fā)人員更直觀地了解相關(guān)缺陷在上述需要填寫的內(nèi)容中，詳細描述一項的內(nèi)容是開發(fā)人員是否能從缺陷報告中得到準確復現(xiàn)信息的關(guān)鍵。因此，詳細描述一項的內(nèi)容應該做到條理清晰、描述精準簡練、突出重點。 在有條件的情況下缺陷報告中可以附加圖片或視頻（若不能拷屏，隨身的手機是一個好幫手）以使開發(fā)人員能夠在最短的時間里重現(xiàn)缺陷。 標明缺陷的復現(xiàn)概率可使開發(fā)人員在重現(xiàn)缺陷時更好地掌握嘗試次數(shù)。 將發(fā)現(xiàn)缺陷人員的最有效聯(lián)系方式寫在顯著的位置以便開發(fā)人員在需要時能夠第一時間與發(fā)現(xiàn)缺陷人員溝通。 同一項目的測試人員所報告的缺陷的詳細描述一項應該有統(tǒng)一的格式。以下我們列舉了一種格式以供參考： 軟件測試有前途嗎王小明同學即將踏入社會，成為一名職業(yè)人。經(jīng)過幾年的學習，小明結(jié)合自身能力及興趣愛好，決定往軟件測試領(lǐng)域發(fā)展。通過向老師、師兄師姐詢問，以及在網(wǎng)上查找相關(guān)信息，軟件測試還是很有前途的。測試行業(yè)由來已久，在傳統(tǒng)行業(yè)中它一直是用來保證產(chǎn)品質(zhì)量的一個重要手段，隨著科技的不斷進步，越來越多的新技術(shù)被應用到測試行業(yè)中。隨著國民意識到品牌的力量，以及產(chǎn)品質(zhì)量對品牌的影響，人們對質(zhì)量檢測和質(zhì)量保證的投入越來越大。同樣，軟件制造業(yè)是制造業(yè)中的一員，也需要對其質(zhì)量進行把控。在計算機誕生的初期，編程語言較為初級且程序較為簡單，這使得軟件測試僅停留在一個程序調(diào)試階段。此時只要程序能夠正常運行即可，并不需要專職的測試人員。之后隨著結(jié)構(gòu)化高級語言FORTRAN、PASCAL、C的出現(xiàn)，程序的規(guī)模隨之變得愈來愈大，復雜度也變得愈來愈高。軟件測試的重要性也逐漸顯現(xiàn)出來，專職測試員開始走上舞臺。C++等面向?qū)ο笳Z言的出現(xiàn)使得軟件規(guī)模產(chǎn)生了爆炸式的增長。動輒幾十萬、幾百萬行代碼的軟件產(chǎn)品給軟件測試行業(yè)帶來空前契機，各種軟件測試理論雨后春筍般的出現(xiàn)，當然此時期的軟件測試還是以手工測試為主。到現(xiàn)在，PC和互聯(lián)網(wǎng)的普及以及多媒體技術(shù)的成熟和大規(guī)模的使用使得軟件測試提高到了一個新的高度。軟件測試不僅僅是單純的測試軟件，還要求對產(chǎn)品的缺陷趨勢進行評估，還要對軟件產(chǎn)品的測試和質(zhì)量風險進行評估。同時軟件的測試工作也開始滲透進了軟件生產(chǎn)流程中的每個角落。隨著軟件產(chǎn)品規(guī)模的擴大，為了降低軟件測試的成本，出現(xiàn)了一大批自動化測試工具。這些工具有的直接幫助測試人員開發(fā)（或錄制）、執(zhí)行測試用例；有的幫助測試人員管理測試用例、跟蹤軟件缺陷；有的幫助項目管理人員和測試人員分析測試結(jié)果，預測產(chǎn)品的缺陷數(shù)量走勢。從現(xiàn)階段軟件的發(fā)展來看，軟件產(chǎn)品的規(guī)模在日益擴大，但人均生產(chǎn)率卻沒有提高?，F(xiàn)今軟件的生產(chǎn)還是主要依靠大量開發(fā)人員的手工編碼和測試人員的手工測試，遠沒有實現(xiàn)軟件的工業(yè)時代。因此，軟件行業(yè)留給我們測試人員的機會還很多，現(xiàn)有的自動化測試用例發(fā)現(xiàn)軟件缺陷的能力也有限?？偟膩碚f，軟件測試行業(yè)在軟件工業(yè)中的地位逐步提高。測試人員在軟件開發(fā)項目中所占的比重也越來越大。同時對軟件測試人員本身的素質(zhì)要求也越來越高。所以，王小明同學發(fā)現(xiàn)前面有一篇廣闊的天地等著自己去闖。 測試工程師這條路怎么走于是王小明同學開展望自己的未來，那這條路該怎么走呢？軟件測試行業(yè)從業(yè)者水平也是按金字塔形分布的。1．初級測試工程師王小明理解軟件測試就是坐在計算機前尋找軟件缺陷。確實，初級測試工程師一般只做黑盒測試，也就是按部就班地執(zhí)行測試用例，當預期與結(jié)果不符時，就認為能找到至少一個軟件缺陷，但往往不太關(guān)心缺陷后面的邏輯結(jié)構(gòu)。初級測試工程師往往剛畢業(yè)缺乏經(jīng)驗，或是經(jīng)過短暫的職業(yè)培訓，這種崗位不可能是企業(yè)的核心崗位，因此很多大型公司都把這種崗位外包出去，由外包公司派遣勞務(wù)人員從事此種工作。而王小明沒有太多開發(fā)經(jīng)驗，編程能力欠缺。例如，當出現(xiàn)兩個軟件缺陷現(xiàn)象不同，但根源相同的情況，由于可能缺乏對程序邏輯的背景知識，初級測試工程師往往就無法區(qū)分，這樣就造成相當數(shù)量的重復報告，增加了開發(fā)人員重復勞動，造成了缺陷統(tǒng)計數(shù)據(jù)不準確。2．中級測試工程師通過了解和軟件測試課程的學習，王小明覺得通過一段時間的訓練，應該能很快進入測試工程師的角色。所以接下來王小明的眼光放到了中級測試工程師上。中級測試工程師可能不如開發(fā)工程師在某個領(lǐng)域深入，但是知識面要寬闊一些。中級測試工程師通常具有一定的開發(fā)經(jīng)驗，而且對質(zhì)量管理、網(wǎng)絡(luò)、多種操作系統(tǒng)、多種腳本語言、數(shù)據(jù)庫等領(lǐng)域都具有相當程度的知識。另外，中級測試工程師往往較普通開發(fā)人員對項目架構(gòu)接口等細節(jié)有更深的了解，他們需要縱觀全局并且注重細節(jié)才能設(shè)計出有效精彩的測試用例，經(jīng)常需要見人所未見，還會對需求提出改進意見。由于對項目了解是入木三分，中級測試工程