第1章 上班第一天，新人培訓(xùn)
1.1 測試專家的第一步
小艾是某名牌大學(xué)計(jì)算機(jī)科學(xué)專業(yè)碩士畢業(yè)生，這天是他離開校園走上工作崗位的第一天。他將成為大型外資IT公司IBM的軟件測試工程師（Software Test Engineer），開始一段新的旅程。
1.1.1 我是菜鳥
在離開校園以前，小艾對將要從事的工作幾乎一無所知。記得面試時(shí)被問及對測試的想法時(shí)，他的理解是，測試就是給產(chǎn)品挑錯(cuò)吧，目標(biāo)應(yīng)當(dāng)是保證產(chǎn)品以高質(zhì)量交付給用戶。面試經(jīng)理告訴他，其實(shí)測試是軟件開發(fā)過程中必不可少的重要流程。在追求質(zhì)量和效率的軟件工程里，如何有效地對復(fù)雜的軟件半成品進(jìn)行測試，其實(shí)有許多問題值得工程師們?nèi)ニ伎己吞剿?。軟件測試工程師的工作將很有趣、充滿挑戰(zhàn)。于是，對新事物充滿好奇心的小艾欣然接受了軟件測試工程師這個(gè)職位邀請，充滿期待地走進(jìn)這個(gè)他完全不了解的神秘領(lǐng)域。
產(chǎn)品開發(fā)組的同事，包括組長和老員工，對小艾這只菜鳥照顧周到，一會兒工夫他就把入職的流程辦妥，工作的機(jī)器也準(zhǔn)備就緒。坐在新的座位，小艾開始憧憬自己的新工作?？墒菧y試卻是一張陌生的面孔，讓他有點(diǎn)無所適從。于是，小艾找到公司給他安排的“導(dǎo)師”凱文，希望凱文能幫他排解困惑。凱文是測試組組長，一位具有豐富工作經(jīng)驗(yàn)的老員工。未來，就從這一刻開始向小艾展露出微笑。
“凱文，我對將要從事的工作一無所知。你能告訴我測試工作都包含些什么內(nèi)容嗎？我們應(yīng)該如何做測試？什么時(shí)候可以真正開始工作？”
凱文對小艾的問題一點(diǎn)兒也不陌生，這些問題不正是幾年前他入職時(shí)的困惑嗎？“小艾，別著急，請慢慢聽我說。我也像你一樣，是從菜鳥一步一步成長起來的……”
經(jīng)過與凱文的談話，小艾心中的一團(tuán)迷霧逐漸消除了。
原來，在大型軟件開發(fā)團(tuán)隊(duì)中，測試被分成很多種類和步驟，每種測試有針對性地模擬使用測試對象的場景，并試圖找出測試對象的潛在問題和缺陷（Bug）。在確定原因后，制定嚴(yán)謹(jǐn)完善的解決方案并根據(jù)方案修復(fù)缺陷。測試其實(shí)是發(fā)現(xiàn)并解決問題的過程，而其目標(biāo)則是讓軟件產(chǎn)品以盡可能高的質(zhì)量交付給客戶，使軟件產(chǎn)品中存在的問題盡可能少，這樣，軟件的用戶可以得到最完美的使用體驗(yàn)。
除了小型項(xiàng)目，進(jìn)行完全（各種輸入和前提條件的組合）的測試是不可行的。可行的方法是運(yùn)用風(fēng)險(xiǎn)分析和不同系統(tǒng)功能的測試優(yōu)先級，來確定測試的關(guān)注點(diǎn)，從而替代窮盡測試。軟件開發(fā)本身是追求產(chǎn)出和投入比的工程性過程。因此，考慮測試的內(nèi)容和方式時(shí)，都應(yīng)當(dāng)以高產(chǎn)出投入比為最終目標(biāo)，最大化地利用現(xiàn)有資源排除潛在的問題。
小艾聽說過風(fēng)險(xiǎn)控制，在軟件測試過程中，風(fēng)險(xiǎn)控制是通過專業(yè)有效的方法實(shí)現(xiàn)的。測試團(tuán)隊(duì)由許多個(gè)測試分隊(duì)組成，每個(gè)分隊(duì)的測試任務(wù)和方法都具有高度的針對性。
小艾回想，在學(xué)校的時(shí)候，他曾經(jīng)參加過軟件工程課程的項(xiàng)目實(shí)訓(xùn)。在項(xiàng)目中，測試很簡單，其目的僅僅是驗(yàn)證開發(fā)的功能點(diǎn)是否正確并與設(shè)計(jì)一致。測試是在所有功能開發(fā)完畢后才開始的。當(dāng)時(shí)項(xiàng)目規(guī)模很小，從計(jì)劃的時(shí)候開始，大家就沒有仔細(xì)地考慮過怎樣做測試。由于項(xiàng)目組人數(shù)很少，在功能開發(fā)階段大家也無暇顧及測試，而是到了功能開發(fā)已經(jīng)完成后，大家才匆忙地花些時(shí)間測試。當(dāng)然，這種測試非常簡陋，沒有計(jì)劃細(xì)節(jié)，方向也不清晰，測試過程中的所有流程都手工操作一遍。發(fā)現(xiàn)問題則隨時(shí)修改代碼，如果修改后流程能走通，就認(rèn)為測試已經(jīng)通過了。
通過凱文對測試的類型和當(dāng)今流行的開發(fā)模式的介紹，小艾發(fā)現(xiàn)測試遠(yuǎn)不是從前軟件工程項(xiàng)目實(shí)訓(xùn)測試那般隨便和簡單。軟件測試是一個(gè)嚴(yán)謹(jǐn)、全面且有條理的過程。這個(gè)過程中包含了多種測試類型，每種測試類型都有針對性地驗(yàn)證軟件，發(fā)現(xiàn)相應(yīng)的問題。測試就像河流中一張精心編織的網(wǎng)，軟件的功能和流程就像河流中的魚，要通過這張網(wǎng)的魚必須足夠優(yōu)秀才能最終存活。正是這種“優(yōu)勝劣汰”的思想，保證軟件只有通過了測試這張網(wǎng)才得以與用戶見面。
凱文娓娓道來，小艾對IBM的測試方法有了初步的了解：原來測試的種類可以如此多種多樣。
單元測試是和開發(fā)最接近的一種測試。開發(fā)人員編寫單元測試用例并執(zhí)行，驗(yàn)證單元模塊是否得出預(yù)期的結(jié)果。在敏捷開發(fā)模式中，有一種流行的開發(fā)模式叫做測試驅(qū)動(dòng)開發(fā)（Test Driven Development，TDD）。測試驅(qū)動(dòng)開發(fā)的核心就是把單元測試用例先做好，功能開發(fā)以通過相應(yīng)的單元測試用例為目標(biāo)。單元測試是粒度最小的軟件測試，小粒度能保證復(fù)雜系統(tǒng)中的每個(gè)“螺絲釘”都質(zhì)量合格。通過了單元測試的代碼才可以繼承到系統(tǒng)中，進(jìn)行進(jìn)一步測試。
功能測試是通過黑盒子模式發(fā)現(xiàn)代碼集成后存在的功能問題的測試。顧名思義，功能測試關(guān)注的重點(diǎn)是系統(tǒng)的功能。通過執(zhí)行自動(dòng)或手動(dòng)的測試用例，可以驗(yàn)證相應(yīng)的功能點(diǎn)是否正確。只要測試用例設(shè)計(jì)完整，功能測試的網(wǎng)能把最終用戶可能遇見的功能問題都“提前”發(fā)現(xiàn)并解決?？梢哉f，功能測試保證了提供給用戶的是產(chǎn)品而不是一堆垃圾。單元測試和功能測試的區(qū)別主要是粒度的不同。單元測試關(guān)注的是一個(gè)最小的代碼片段，如一個(gè)類或接口，而功能測試關(guān)注的是一個(gè)完整的業(yè)務(wù)功能。
功能測試通過后，性能測試就隨之開始了。性能測試是重點(diǎn)驗(yàn)證軟件的非功能性需求的測試。企業(yè)級軟件通常用于應(yīng)對復(fù)雜苛刻的用戶場景。在軟件設(shè)計(jì)和安裝的過程中，有許多細(xì)節(jié)能提供軟件的性能，包括吞吐率、穩(wěn)定性、可靠性等。性能測試通過自動(dòng)化的方法模擬真實(shí)用戶并發(fā)訪問的場景，以驗(yàn)證系統(tǒng)的性能指標(biāo)或發(fā)現(xiàn)其性能瓶頸。性能缺陷常常不是顯而易見的，有時(shí)候得通過復(fù)雜的場景模擬方可重現(xiàn)問題。由于性能問題的復(fù)雜性，要定位問題的原因也是一個(gè)藝術(shù)的過程。通過了性能測試的軟件系統(tǒng)從根本上保證了用戶體驗(yàn)和長遠(yuǎn)利益。
正式版本發(fā)布前，測試組還要組織成品測試（GMV），測試軟件的安裝、部署、發(fā)布等情況，確保軟件能最終順利地安裝到用戶的環(huán)境中。通過集成測試后，軟件的質(zhì)量有了進(jìn)一步的保障。
軟件正式版本發(fā)布以后，根據(jù)用戶的反饋，產(chǎn)品組需要發(fā)布多個(gè)小版本。發(fā)布以前，當(dāng)然也要有針對性地測試小版本的功能、性能，以及和正式版本的兼容性。小版本的開發(fā)和測試周期比正式版本短得多，因此對測試團(tuán)隊(duì)的項(xiàng)目管理要求更高。
“在IBM，為了保證軟件質(zhì)量而進(jìn)行的測試是全面而苛刻的。”凱文說，“等你完成了新員工培訓(xùn)并開始接觸項(xiàng)目時(shí)，你將有更多機(jī)會從方法到實(shí)踐了解我們的軟件測試。”
1.1.2 苦練基本功（1）
小艾所在開發(fā)團(tuán)隊(duì)所負(fù)責(zé)的產(chǎn)品是電子商務(wù)平臺。電子商務(wù)平臺是一個(gè)功能強(qiáng)大的企業(yè)級應(yīng)用，它支持多種計(jì)算機(jī)平臺。要成為一名合格的測試工程師，首要的就是熟練掌握基本功。所謂基本功，指的是作為任何開發(fā)團(tuán)隊(duì)的一員，都應(yīng)該掌握的基本知識和技能。
小艾發(fā)現(xiàn)上大學(xué)時(shí)學(xué)習(xí)的專業(yè)課還是非常有用的，諸如數(shù)據(jù)結(jié)構(gòu)與程序設(shè)計(jì)、計(jì)算機(jī)組成原理、操作系統(tǒng)原理等。但這些課程大多只注重理論，缺少在真實(shí)環(huán)境中實(shí)踐的經(jīng)驗(yàn)。公司的軟件開發(fā)通常都有比較成熟的基礎(chǔ)設(shè)施，對于新人來說，了解開發(fā)平臺和方式也是鍛煉基本功的一部分。
操作系統(tǒng)是平臺的基礎(chǔ)。IBM的產(chǎn)品通常都支持多種流行的操作系統(tǒng)，如Windows，UNIX，Linux等；為了滿足更大規(guī)模的應(yīng)用，產(chǎn)品還能提供對大型機(jī)的支持。小艾最熟悉的操作系統(tǒng)是Windows，在學(xué)校和日常生活中基本都用這個(gè)系統(tǒng)，而對UNIX和Linux卻是一知半解。在開發(fā)組的數(shù)據(jù)庫里，小艾學(xué)習(xí)了大量關(guān)于UNIX/Linux基礎(chǔ)的材料。在學(xué)習(xí)的過程中，他有機(jī)會操作各種平臺的機(jī)器，這樣在實(shí)踐中學(xué)習(xí)效果是最好的。幾周下來，小艾已經(jīng)掌握了UNIX/Linux的系統(tǒng)管理知識和編程基礎(chǔ)。他發(fā)現(xiàn)，在簡潔的黑色文本界面背后，隱藏著超乎想象的強(qiáng)大計(jì)算能力。
學(xué)習(xí)了操作系統(tǒng)基本知識后，小艾滿懷興奮地找凱文：“我是不是可以開始測試產(chǎn)品了？”凱文搖頭說：“離測試還遠(yuǎn)著呢！不過你可以接著實(shí)踐測試環(huán)境搭建了。”所謂測試環(huán)境搭建，是指在操作系統(tǒng)基礎(chǔ)上，安裝測試需要的應(yīng)用程序，并部署測試的功能代碼，準(zhǔn)備測試數(shù)據(jù)，建立起一個(gè)可供測試的環(huán)境。電子商務(wù)系統(tǒng)是基于中間件的網(wǎng)絡(luò)應(yīng)用程序，因此，必須從安裝服務(wù)器程序開始。一個(gè)完整的企業(yè)級網(wǎng)絡(luò)應(yīng)用程序，通常需要集成多個(gè)服務(wù)器，包括網(wǎng)絡(luò)服務(wù)器、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器等。坐在機(jī)器前，小艾發(fā)現(xiàn)搭建測試環(huán)境是一個(gè)艱巨的過程。
測試環(huán)境的搭建從安裝網(wǎng)絡(luò)服務(wù)器開始，接著是數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器的安裝。網(wǎng)絡(luò)應(yīng)用程序作為企業(yè)級應(yīng)用，部署在應(yīng)用服務(wù)器上。面對一系列的設(shè)置步驟，小艾感到頭暈?zāi)垦?。一連幾天，小艾都在直接和服務(wù)器打交道。在UNIX/Linux上搭建測試環(huán)境，用戶的權(quán)限管理是關(guān)鍵的部分。因?yàn)樯婕霸S多手動(dòng)操作的部分，一時(shí)疏忽引起的用戶權(quán)限錯(cuò)誤會導(dǎo)致搭建失敗。小艾自問還是很有耐心的，這次也被測試環(huán)境安裝折騰得“體無完膚”。經(jīng)過凱文的多次“指點(diǎn)迷津”，在安裝配置好服務(wù)器以后，電子商務(wù)應(yīng)用程序也安裝好了。
小技巧：正確的流程和步驟一定要及時(shí)記錄。有了流程和步驟的指引，可以避免大量不必要的重復(fù)勞動(dòng)。
這也僅僅相當(dāng)于一個(gè)新建的購物商城做好了“硬裝修”，商城還是空空的，還不足以接受業(yè)務(wù)流程。根據(jù)測試用例的要求，需要安裝并激活業(yè)務(wù)模塊。網(wǎng)上商城的經(jīng)營模式、頁面的樣式、能夠提供的功能等特性，都是通過激活業(yè)務(wù)模塊并配置數(shù)據(jù)等步驟決定的。
激活了業(yè)務(wù)模塊以后，工程師的測試才可以開始。
領(lǐng)教了測試環(huán)境安裝的煩瑣步驟，小艾想，要是測試工程師不得不耗費(fèi)大量資源兼顧測試環(huán)境的安裝和配置，那么將難以保障軟件測試的質(zhì)量。從資源利用優(yōu)化的角度而言，這似乎也不是很好的方式。
帶著疑惑，小艾找到了凱文，“環(huán)境安裝耗時(shí)費(fèi)勁，測試人員必須每次都從頭到尾安裝測試環(huán)境嗎？”
凱文說：“看來你對環(huán)境安裝的難度有了很深的體會啊。你的顧慮項(xiàng)目組很早以前已經(jīng)考慮到了。我們發(fā)現(xiàn)，更細(xì)的分工是提高效率的源泉。你應(yīng)當(dāng)看看我們用什么樣的方式實(shí)現(xiàn)了測試平臺的高效搭建。”
凱文說，其實(shí)許多新同事也有著和小艾一樣的疑惑，解決環(huán)境安裝問題的方式是執(zhí)行構(gòu)建測試（Build Verification Testing，BVT）。
的確，構(gòu)建測試是個(gè)煩瑣、重復(fù)性的過程。為了有效搭建環(huán)境，避免人為原因的錯(cuò)誤，采取的策略是最大程度上地使構(gòu)建過程自動(dòng)化。因?yàn)榄h(huán)境的原型和步驟基本上是類同的，這種條件很適合自動(dòng)化。于是工程師們使用構(gòu)建了參數(shù)化的腳本、響應(yīng)文件等構(gòu)建測試的元素，有了這些元素，構(gòu)建過程不再每一步都需要人工干預(yù)，出現(xiàn)錯(cuò)誤的可能性有效降低。當(dāng)然，由于平臺本身的復(fù)雜性，自動(dòng)化元素的構(gòu)建由構(gòu)建組專門維護(hù)。構(gòu)建組把這個(gè)過程稱為構(gòu)建測試。通過測試驗(yàn)證環(huán)境安裝的正確性。
軟件的構(gòu)建（Build）本身是依賴于Java的，因此沒有平臺依賴性。但是，Java虛擬機(jī)是安裝在不同的操作系統(tǒng)中的，于是測試環(huán)境的安裝就有了平臺依賴性。構(gòu)建完整的測試應(yīng)該包括對多種平臺的支持。不同操作系統(tǒng)平臺結(jié)構(gòu)通常很不一樣，需要提供有針對性的自動(dòng)化構(gòu)建程序。構(gòu)建完成后，構(gòu)建組還必須完成對所有支持的平臺的構(gòu)建測試。
有了自動(dòng)化的構(gòu)建程序和構(gòu)建測試的步驟，可以保證測試環(huán)境正確和順利地安裝。但是，每次安裝還是得花時(shí)間的。熟練的工程師使用構(gòu)建程序在某個(gè)平臺構(gòu)建一個(gè)測試環(huán)境得花大半天時(shí)間。小艾從興奮轉(zhuǎn)為沮喪：每次安裝半天時(shí)間的成本并不小啊，大家測試環(huán)境的資源耗費(fèi)問題還沒有解決。
幸運(yùn)的是，開發(fā)實(shí)驗(yàn)室利用虛擬技術(shù)構(gòu)建了基于不同平臺的測試鏡像。有了虛擬技術(shù)，時(shí)間和步驟也是“可復(fù)制”的。由于測試環(huán)境必須支持多平臺，使用自動(dòng)化方式搭建第一個(gè)測試平臺的時(shí)間是不可節(jié)省的；但是，第二個(gè)、第三個(gè)測試環(huán)境的搭建時(shí)間確實(shí)可以節(jié)省。奧秘就在于虛擬技術(shù)。成功搭建一套測試環(huán)境后，就可以把這個(gè)環(huán)境保存成鏡像（Image）。以后任何時(shí)間需要再使用這套環(huán)境，不必重新安裝，僅需要把鏡像恢復(fù)，并替換必要的機(jī)器信息即可。虛擬技術(shù)被多個(gè)平臺支持，包括AIX、Windows、UNIX/Linux。用于恢復(fù)鏡像的硬件環(huán)境既可以是實(shí)際存在的，也可以是虛擬的。
雖然沒有仔細(xì)了解過虛擬技術(shù)，但小艾在學(xué)校的時(shí)候使用過Ghost克隆軟件。凱文說：“虛擬技術(shù)的原理和Ghost有相似的地方，隨著使用的深入，你會對虛擬技術(shù)有更多的認(rèn)識。”
對測試環(huán)境安裝有了初步的了解，作為菜鳥，小艾接著需要知道的是中間件技術(shù)。要知道，功能強(qiáng)大的電子商務(wù)平臺是建立在IBM的WebSphere中間件基礎(chǔ)上的。凱文開始給小艾介紹一些基于中間件的應(yīng)用服務(wù)的基礎(chǔ)內(nèi)容。
中間件（Middleware）是提供系統(tǒng)軟件和應(yīng)用軟件之間連接的軟件，以便于各種部件之間的溝通，特別是應(yīng)用軟件對于系統(tǒng)軟件的集中的邏輯。中間件技術(shù)在現(xiàn)代信息技術(shù)應(yīng)用框架，如Web服務(wù)（Web Service）、面向服務(wù)的體系結(jié)構(gòu)（Service Oriented Architecture，SOA）等應(yīng)用中應(yīng)用得比較廣泛。中間件不提供具體的功能，但它卻是系統(tǒng)中各個(gè)部件有機(jī)連接的橋梁。中間件可以提供對外圍服務(wù)器，包括數(shù)據(jù)庫服務(wù)器、應(yīng)用服務(wù)器、Web服務(wù)器等的支持和管理。中間件技術(shù)建立在對應(yīng)用軟件部分常用功能的抽象上，將常用且重要的過程調(diào)用、分布式組件、消息隊(duì)列、事務(wù)、安全、連接器、商業(yè)流程、網(wǎng)絡(luò)并發(fā)、HTTP服務(wù)器、Web服務(wù)等功能集于一身或者分別在不同品牌的不同產(chǎn)品中分別完成。
接下來的日子里，小艾開始研究WebSphere中間件提供的功能。經(jīng)過一段時(shí)間的學(xué)習(xí)，他掌握了通過應(yīng)用服務(wù)器對應(yīng)用程序進(jìn)行管理和監(jiān)控的方法。這部分知識對于測試中發(fā)現(xiàn)和解決問題起著關(guān)鍵的作用。
經(jīng)過基本能力的訓(xùn)練，小艾基本上已經(jīng)達(dá)到了進(jìn)入項(xiàng)目組的要求。然而，對于項(xiàng)目如何運(yùn)作，如何確保項(xiàng)目順利達(dá)到預(yù)期結(jié)果，小艾卻還是一知半解。接著，小艾在凱文的指導(dǎo)下，認(rèn)識了敏捷項(xiàng)目管理的基本知識。
對于敏捷開發(fā)（Agile Development）的定義，工業(yè)界其實(shí)還沒有標(biāo)準(zhǔn)的定義，而相關(guān)的描述倒是五花八門，各種定義也出現(xiàn)在出版物或網(wǎng)絡(luò)博客中。缺乏標(biāo)準(zhǔn)定義，其實(shí)是因?yàn)槊艚蓍_發(fā)的實(shí)現(xiàn)方式非常多樣化。我們可以容易地找到關(guān)于敏捷的方式、方法、實(shí)踐及技術(shù)等的描述。在IBM的軟件開發(fā)和測試中，團(tuán)隊(duì)使用了多種流行的敏捷開發(fā)方式進(jìn)行項(xiàng)目管理。使用敏捷項(xiàng)目管理的目的并不復(fù)雜，是為了提高開發(fā)效率，激發(fā)團(tuán)隊(duì)的積極性并盡可能降低項(xiàng)目失敗的風(fēng)險(xiǎn)。
提到敏捷開發(fā)，會把某種開發(fā)方式作為“非敏捷”方式來對比，而這種開發(fā)方式通常會是傳統(tǒng)的瀑布開發(fā)模型。在瀑布開發(fā)模型中，整個(gè)系統(tǒng)的開發(fā)被劃分成需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測試、集成和維護(hù)等階段。這種劃分本質(zhì)上是把不同性質(zhì)的項(xiàng)目內(nèi)容分隔到不同的階段，而某個(gè)階段則專注地進(jìn)行某種任務(wù)。專注在許多情況下帶來了高質(zhì)量，單一流程的劃分卻很容易帶來資源浪費(fèi)和失敗風(fēng)險(xiǎn)的增加。如果在一個(gè)階段，項(xiàng)目組只完成一組相同性質(zhì)的任務(wù)，那么，團(tuán)隊(duì)中其他無關(guān)的人員在這段時(shí)間里就無事可做了。項(xiàng)目的成果必須到最后階段才完成，中間任何步驟出現(xiàn)差錯(cuò)都有可能導(dǎo)致項(xiàng)目全盤失敗，這樣的項(xiàng)目風(fēng)險(xiǎn)是很高的。
敏捷開發(fā)從根本上避免了瀑布模型的弱點(diǎn)，它有兩個(gè)核心點(diǎn)--迭代開發(fā)（Iterative Development）和增量開發(fā)（Incremental Development）。
迭代開發(fā)是一種“重復(fù)時(shí)序安排”的開發(fā)方式。迭代開發(fā)把一個(gè)完整的瀑布模型開發(fā)流程分成多個(gè)迭代，每個(gè)迭代可以看做獨(dú)立的開發(fā)過程，其中包含了項(xiàng)目的主要步驟，如設(shè)計(jì)、開發(fā)和測試等。把完整過程分成多個(gè)持續(xù)時(shí)間較短的迭代，其好處是生產(chǎn)的周期變短了，每個(gè)完整的周期都會產(chǎn)出相應(yīng)的產(chǎn)品，這種方式有利于在完整項(xiàng)目開發(fā)的過程中跟蹤和控制開發(fā)進(jìn)度及產(chǎn)品質(zhì)量。
1.1.2 苦練基本功（2）
增量開發(fā)用的則是一種"分段完成"的策略。在增量開發(fā)模式中，系統(tǒng)中不同的部分被安排在多個(gè)階段完成，各個(gè)部分完成后再集成到系統(tǒng)中。
在敏捷開發(fā)模式中，迭代開發(fā)和增量開發(fā)的策略通常會被同時(shí)使用，并統(tǒng)稱為迭代開發(fā)，迭代開發(fā)框架如圖1-1所示。
增量地實(shí)現(xiàn)系統(tǒng)的思想是迭代開發(fā)的基礎(chǔ)。項(xiàng)目成員通過不斷學(xué)習(xí)和總結(jié)，使開發(fā)效率不斷提高，同時(shí)避免在后期的迭代中重犯某些錯(cuò)誤。因此增量開發(fā)對于團(tuán)隊(duì)的進(jìn)步也很有好處。
因?yàn)闀r(shí)間周期縮短，和傳統(tǒng)瀑布模式相比，迭代開發(fā)的進(jìn)度會緊湊很多。項(xiàng)目組必須定期開會確保項(xiàng)目如期進(jìn)行。項(xiàng)目的周期稱為沖刺（Sprint），每個(gè)Sprint通常持續(xù)2～6周時(shí)間。在Sprint開始之前，項(xiàng)目組會進(jìn)行Sprint計(jì)劃會議，安排當(dāng)前開發(fā)周期的任務(wù)；而在Sprint結(jié)束時(shí)，項(xiàng)目組舉行Sprint評審會議，對這個(gè)周期的交付件進(jìn)行評審核實(shí)；評審會議結(jié)束后，項(xiàng)目組還需要進(jìn)行簡明扼要的Sprint回顧會議，回顧這個(gè)開發(fā)周期中做得好的或需要提高的方面，以便在下一周期提高開發(fā)效率。
在每個(gè)Sprint中，為了確保開發(fā)進(jìn)度，項(xiàng)目組還需要舉行周期的會議（通常是每天），確定各個(gè)小組成員更新已經(jīng)完成的任務(wù)、即將開始的任務(wù)及使進(jìn)度受阻的問題，并通過討論得出解決問題的方案。這種周期的會議叫做每日站立會議（Daily Scrum Meeting），由Scrum Master主持。
小艾最討厭開會了，他認(rèn)為開會浪費(fèi)時(shí)間卻常常沒什么有效的結(jié)果。但凱文告訴他，每日站立會議有個(gè)重要原則，為了避免浪費(fèi)時(shí)間，每個(gè)成員的匯報(bào)時(shí)間必須嚴(yán)格限制，會議的持續(xù)時(shí)間只能在15到20分鐘。更細(xì)節(jié)的問題都放在會后討論。這樣的安排優(yōu)勢是明顯的，既能讓所有成員了解項(xiàng)目進(jìn)度，又不耽誤所有人的時(shí)間。
聽完凱文的介紹，小艾對敏捷開發(fā)條件下的項(xiàng)目運(yùn)作有了最基本的了解。對于敏捷開發(fā)范疇而言，這僅僅是冰山的一角。凱文還列舉了許多開發(fā)的方法，包括測試驅(qū)動(dòng)開發(fā)（Test Driven Development）、極限編程（Extreme Programming）、開發(fā)統(tǒng)一過程（Open Unified Process）、結(jié)對開發(fā)（Pair Development）等。不同的項(xiàng)目根據(jù)實(shí)際情況會使用不同的具體開發(fā)方式。然而，有兩樣?xùn)|西是所有這些方法的基礎(chǔ)--計(jì)劃和流程。
計(jì)劃定義的是做什么（What）和什么時(shí)候做（When）。在項(xiàng)目或迭代的初期，項(xiàng)目負(fù)責(zé)人要根據(jù)需求定義項(xiàng)目的計(jì)劃，計(jì)劃的內(nèi)容包括要執(zhí)行的任務(wù)、任務(wù)依賴條件、負(fù)責(zé)人選、執(zhí)行任務(wù)的時(shí)間等。對于測試而言，測試計(jì)劃的制訂非常重要。測試計(jì)劃詳細(xì)描述了測試的環(huán)境、場景、執(zhí)行要點(diǎn)、依賴等內(nèi)容。項(xiàng)目執(zhí)行完全根據(jù)計(jì)劃實(shí)施，因此，好的計(jì)劃是項(xiàng)目成功的基礎(chǔ)。
流程是項(xiàng)目成功的保障，它定義了怎么做（How）。無論是開發(fā)還是測試，每個(gè)步驟都有標(biāo)準(zhǔn)的流程。在軟件測試中，測試環(huán)境的準(zhǔn)備有標(biāo)準(zhǔn)流程，沒有按標(biāo)準(zhǔn)流程安裝的環(huán)境就可能有潛在的錯(cuò)誤；執(zhí)行測試的步驟有標(biāo)準(zhǔn)控制流程，沒有按流程執(zhí)行的測試結(jié)果是無效的。完全按照標(biāo)準(zhǔn)流程完成的測試，如果存在失敗的測試用例，我們就可以很直接地從產(chǎn)品本身找原因，而不用懷疑是錯(cuò)誤的執(zhí)行導(dǎo)致了失敗。流程控制每個(gè)步驟的正確完成，有了流程控制，軟件的質(zhì)量才得以保證。
作為菜鳥的小艾對測試工程師的基本功掌握得差不多了，他明白，這些基本功需要在實(shí)踐鍛煉中不斷加深理解，才能得心應(yīng)手，融會貫通。
1.1.3 培養(yǎng)專業(yè)技能
這天中午，小艾經(jīng)過凱文的座位，發(fā)現(xiàn)他正在專心致志地閱讀一本技術(shù)書籍。小艾好奇地問凱文，究竟是什么書那么有趣。面對小艾的一臉好奇，凱文細(xì)致地解釋自己學(xué)習(xí)的內(nèi)容：“我在學(xué)習(xí)腳本語言編程技術(shù)。作為測試工程師，開發(fā)技術(shù)對我們而言也同樣重要。為了更好地進(jìn)行測試，得學(xué)點(diǎn)腳本編程知識。”
“測試工程師也必須掌握開發(fā)技術(shù)嗎？還有哪些技能是測試工程師應(yīng)該掌握的呢？”小艾有些疑惑。
“的確，我們的工作應(yīng)該專注在測試上，但這并不代表我們不需要掌握開發(fā)技術(shù)。恰恰相反，開發(fā)技術(shù)是測試工程師應(yīng)該掌握的基本專業(yè)技能之一。先給你解釋什么是專業(yè)技能，再介紹我們應(yīng)該掌握哪些專業(yè)技能吧。”
在軟件開發(fā)團(tuán)隊(duì)中，作為軟件測試工程師，為了完成測試任務(wù)，有一些技能是必須掌握的，我們把這部分技能定位為專業(yè)技能。在開發(fā)團(tuán)隊(duì)里的“專業(yè)”，與高等院校中的“專業(yè)”不同。開發(fā)團(tuán)隊(duì)的專業(yè)，強(qiáng)調(diào)的是長時(shí)期從事的行為作業(yè)規(guī)范，規(guī)范保證了產(chǎn)品的質(zhì)量。
一名專業(yè)的測試工程師，應(yīng)該把開發(fā)技能作為其技能體系的基礎(chǔ)。測試人員雖然不需要編寫功能代碼，但是測試人員在測試過程中需要完成測試代碼的編寫。掌握開發(fā)技能，有利于理解功能實(shí)現(xiàn)的方法和邏輯。我們知道，測試就像一把手術(shù)刀，務(wù)求一擊即中要害，不讓存在問題的地方漏網(wǎng)。測試工程師掌握了開發(fā)方法，基于對開發(fā)的了解，更容易設(shè)計(jì)出有效的測試場景和用例。例如，使用Java EE開發(fā)的應(yīng)用程序，程序的實(shí)現(xiàn)邏輯很有可能影響垃圾回收的效率，那么設(shè)計(jì)測試用例時(shí)，應(yīng)當(dāng)重點(diǎn)測試功能模塊對垃圾回收的影響。又如，使用JavaScript實(shí)現(xiàn)的前端頁面，在不同的瀏覽器中的顯示狀況可能有明顯差異，有些腳本是針對特定的瀏覽器開發(fā)的。了解JavaScript的這種特性及開發(fā)的邏輯后，設(shè)計(jì)測試用例時(shí)就應(yīng)當(dāng)在不同瀏覽器中針對可能有問題的腳本進(jìn)行測試。測試工程師應(yīng)該掌握數(shù)據(jù)結(jié)構(gòu)和算法設(shè)計(jì)、設(shè)計(jì)模式和體系結(jié)構(gòu)，了解不同的開發(fā)語言和平臺的差異。
開發(fā)技能不僅包括設(shè)計(jì)和實(shí)現(xiàn)功能的技術(shù)，還包括發(fā)布和部署代碼、配置環(huán)境的技術(shù)。軟件產(chǎn)品的測試通常具有嚴(yán)格的版本限制，小版本的差異也完全有可能得出不一樣的測試結(jié)果。測試人員了解代碼的發(fā)布和部署，能夠評估新代碼的影響范圍，并根據(jù)評估適當(dāng)?shù)卣{(diào)整測試的內(nèi)容。當(dāng)然，掌握代碼發(fā)布和部署以后，至少不會糊里糊涂地就開始測試，而能夠在確認(rèn)代碼的發(fā)布和版本都沒有問題之后再行動(dòng)。
開發(fā)團(tuán)隊(duì)使用了版本控制工具來管理程序的版本，了解新代碼如何進(jìn)入到軟件版本中，對測試人員而言也很有用。在對原始代碼進(jìn)行修改前，程序員或測試人員需要?jiǎng)?chuàng)建一個(gè)“缺陷”，“缺陷”意味著系統(tǒng)有需要更新的地方。缺陷創(chuàng)建后，系統(tǒng)會生成唯一的缺陷號碼，用于跟蹤代碼的更新狀態(tài)。無論是因?yàn)榧尤胄鹿δ苓€是測試失敗而創(chuàng)建的缺陷，都通過統(tǒng)一的平臺進(jìn)行管理。有了這種版本控制方法，對代碼的任何改動(dòng)都記錄在案，任何引起新問題的線索都得以保留，系統(tǒng)也可以在需要時(shí)回滾到任何較早的狀態(tài)。了解“缺陷”模式的運(yùn)作，有助于測試人員執(zhí)行測試或回歸，驗(yàn)證缺陷是否修復(fù)。
鑒于測試工程師的專職工作是完成軟件測試，因此測試專業(yè)技能是測試工程師技能體系的核心。
小知識：軟件測試，從宏觀角度而言，是指針對被測試的產(chǎn)品或服務(wù)進(jìn)行的一系列關(guān)于軟件質(zhì)量的調(diào)查，軟件測試結(jié)果對軟件的擁有者（Product Owner）負(fù)責(zé)。軟件測試還從一種獨(dú)立的視角為業(yè)務(wù)運(yùn)作提供客觀評估，這種評估包括軟件的質(zhì)量達(dá)標(biāo)程度及因?yàn)槟撤N相應(yīng)的實(shí)現(xiàn)方式而存在的風(fēng)險(xiǎn)等。
測試得到的是一種相對客觀的結(jié)果，通過事實(shí)和數(shù)據(jù)對軟件的質(zhì)量進(jìn)行定義，為軟件的擁有者提供決策的參考。測試通過執(zhí)行程序或應(yīng)用的方式，達(dá)到發(fā)現(xiàn)存在的錯(cuò)誤或缺陷的目標(biāo)。至于測試，使用的方法則是多種多樣的。理論上，任何方法，只要發(fā)現(xiàn)的錯(cuò)誤或缺陷是確實(shí)存在的，都是可行的測試方法。但是在項(xiàng)目實(shí)踐中，我們不可能把所有可能的方式都用上，而只能采取最有效和可控的方法。有效，是指這種方法有效模擬真實(shí)的應(yīng)用，并有效地暴露潛在的問題；可控，指的是使用方法有明確的步驟，通過相應(yīng)的步驟可以使暴露的問題重現(xiàn)。
真正的測試中，有效可控的測試方法通常有兩類，分別是白盒測試（White-box Testing）和黑盒測試（Black-box Testing）。
白盒測試指測試人員可以直接訪問內(nèi)部數(shù)據(jù)結(jié)果、算法及其代碼實(shí)現(xiàn)的測試，常見的方法包括編程應(yīng)用接口測試、代碼覆蓋率測試、缺陷注入方法等。通過調(diào)用應(yīng)用程序的公有或私有接口，驗(yàn)證返回內(nèi)容的正確性的方式，是很常用的白盒測試方法。通常一個(gè)測試用例可以用于驗(yàn)證一個(gè)被測的接口。如果需要驗(yàn)證一個(gè)代碼分支，還可以把分支需要使用的多個(gè)接口調(diào)用放在一個(gè)用例中。
代碼覆蓋率測試是檢驗(yàn)代碼是否滿足指定覆蓋率的測試。例如，可以設(shè)計(jì)一個(gè)測試，通過改變輸入條件，使程序中所有代碼行都被執(zhí)行至少一次，并檢驗(yàn)輸出是否符合預(yù)期。覆蓋率測試在一般條件下，最大限度地覆蓋代碼，評估代碼的整體質(zhì)量。缺陷注入關(guān)注代碼在錯(cuò)誤和臨界條件的表現(xiàn)。錯(cuò)誤和臨界條件在所有輸入條件中只占小部分，但這部分輸入?yún)s非常關(guān)鍵，而且存在問題的可能性較大。測試涵蓋了錯(cuò)誤和臨界條件，就能保證代碼的健壯性。健壯的程序不僅能處理期望的輸入，對于“不速之客”，同樣能夠從容應(yīng)對。
白盒測試用最直接的方式，從根源上發(fā)現(xiàn)程序中的缺陷。然而，底層代碼的邏輯往往錯(cuò)綜復(fù)雜，分支繁多，白盒測試的方法需要測試人員對實(shí)現(xiàn)的細(xì)節(jié)比較了解，方可設(shè)計(jì)出有效的測試用例。而且，因?yàn)闀r(shí)間等條件的限制，要覆蓋所有分支的所有條件，簡直是個(gè)“不可能的任務(wù)”。于是便有了黑盒測試，通過觸發(fā)業(yè)務(wù)相關(guān)的功能點(diǎn)，檢驗(yàn)集成條件下系統(tǒng)的正確性。雖然不能期待黑盒測試方法能覆蓋更多的代碼分支，但這些方法針對的都是和實(shí)際系統(tǒng)應(yīng)用相關(guān)的分支，因此黑盒測試對于評估系統(tǒng)是否達(dá)到需求是至關(guān)重要的。理論上，只要黑盒測試的用例設(shè)計(jì)得足夠細(xì)致，測試能發(fā)現(xiàn)所有應(yīng)用中可能存在的問題。當(dāng)然，因?yàn)檫M(jìn)行黑盒測試的時(shí)候系統(tǒng)是集成的，所以發(fā)現(xiàn)問題后，需要“打開黑盒子”，用額外的工作定位問題的確切原因。相對而言，白盒測試發(fā)現(xiàn)問題后，定位原因的過程會簡單得多。
綜合應(yīng)用白盒測試和黑盒測試，可以達(dá)到有效測試系統(tǒng)的目的。
定義了測試方法，測試工程師應(yīng)該明確的下一個(gè)內(nèi)容是測試的執(zhí)行。大型電子商務(wù)系統(tǒng)的業(yè)務(wù)邏輯非常復(fù)雜，集成測試往往需要涉及多個(gè)功能模塊。如何執(zhí)行測試用例問題，實(shí)際上是如何提高工作效率的問題。
對于界面操作、簡單的功能驗(yàn)證用例，通?？梢允褂弥苯邮止げ僮鞯臏y試方式；但是對于大多數(shù)邏輯復(fù)雜或者有特殊要求的測試用例來說，自動(dòng)化測試是主要的測試執(zhí)行方法。
手工操作的優(yōu)勢是方便靈活，只需有明確的測試用例作為指導(dǎo)便能執(zhí)行，不需要花額外的時(shí)間準(zhǔn)備完備的自動(dòng)化測試材料。我們甚至可以通過手工操作的方式執(zhí)行隨機(jī)測試（Adhoc Testing）。探索式測試不使用可識別的測試用例，而采用相對“隨機(jī)”的方式驗(yàn)證某些功能點(diǎn)的正確性。但是手工操作的重復(fù)開銷是測試策略的設(shè)計(jì)人員必須重視的。由于測試步驟必須通過手工的方式執(zhí)行，重復(fù)執(zhí)行測試用例的時(shí)間與資源開銷和第一次執(zhí)行基本上沒有任何區(qū)別。對于一線測試工程師而言，不停地重復(fù)手工測試用例是個(gè)無法擺脫的夢魘，至少熱衷于接受新挑戰(zhàn)的小艾這么認(rèn)定。
自動(dòng)化測試則能彌補(bǔ)手工測試在重復(fù)開銷方面的不足。自動(dòng)化測試，顧名思義，就是測試過程并不需要人工干預(yù)的測試方式。其優(yōu)點(diǎn)是一旦測試的材料（包括自動(dòng)化工具、自動(dòng)化測試環(huán)境和測試腳本）準(zhǔn)備好，測試可以在無須人工干預(yù)或在有限度的人工干預(yù)的條件下重復(fù)執(zhí)行。對于流程復(fù)雜的測試場景，自動(dòng)化測試在節(jié)省重復(fù)執(zhí)行的資源的同時(shí)還能很好地控制測試質(zhì)量和效率。當(dāng)然，自動(dòng)化測試對測試團(tuán)隊(duì)的組織和技術(shù)要求更高。要進(jìn)行自動(dòng)化測試，首先，測試團(tuán)隊(duì)必須有一套完備的測試工具集；其次，測試人員需要掌握測試工具的使用方法，包括如何編寫自動(dòng)化測試代碼，如何執(zhí)行并收集結(jié)果等；最后，對測試資源的維護(hù)也有更高的要求。自動(dòng)化測試腳本和對應(yīng)的測試環(huán)境應(yīng)當(dāng)嚴(yán)格歸檔保存，以備日后查詢和重復(fù)使用。
作為一個(gè)成熟高效的測試團(tuán)隊(duì)，手工測試和自動(dòng)化測試都是不可或缺的測試執(zhí)行方法。兩者優(yōu)勢互補(bǔ)，可以有效保障軟件產(chǎn)品的質(zhì)量。
在產(chǎn)品開發(fā)過程中，特別在使用敏捷開發(fā)模式的項(xiàng)目中，新功能的完成大多是分階段的。功能點(diǎn)在不同的迭代中陸續(xù)發(fā)布，同時(shí)，在新的發(fā)布中還會包含對老版本的問題修復(fù)。作為測試，除了需要測試新發(fā)布的內(nèi)容，還必須驗(yàn)證已經(jīng)存在的功能是否正確，存在的問題是否已經(jīng)修復(fù)。這是測試執(zhí)行中很重要的一環(huán)--回歸測試。就理論而言，只要有新的軟件版本發(fā)布，對執(zhí)行所有測試用例的回歸測試是必需的，因?yàn)橹挥羞@樣，才能從事實(shí)上保證所有功能在最新版本中的正確性。隨著開發(fā)完成的功能越來越多，回歸測試中要執(zhí)行的測試用例也隨之增加。自動(dòng)化測試在重復(fù)執(zhí)行方面的優(yōu)勢正好能滿足回歸測試的這種要求。
作為測試工程師，掌握了測試執(zhí)行方法，可以認(rèn)為已經(jīng)掌握基本的專業(yè)技能了。然而測試工程師專業(yè)技能的涵蓋范圍其實(shí)非常廣，因?yàn)楦哔|(zhì)量的測試要求工程師掌握更多的技術(shù)，包括架構(gòu)設(shè)計(jì)、軟件開發(fā)技術(shù)等。更好地掌握這些專業(yè)技術(shù)，目的是更好地服務(wù)于測試，測試的目的則是發(fā)現(xiàn)和排除軟件中存在的問題。
“發(fā)現(xiàn)、解決問題其實(shí)是一種藝術(shù)。”凱文語重心長地指導(dǎo)小艾，“等你熟練掌握基本的測試專業(yè)技能的時(shí)候，我們還會從更深入的層次探討測試的核心價(jià)值和技術(shù)。”
?。ㄎ赐甏m(xù)）