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