行之有效的軟件測試策略

　　在最近的一個(gè)大型項目中，我們在早期就定下了一個(gè)目標：不會(huì )在軟件中使用大量QA人員專(zhuān)注于手工測試。通過(guò)手工測試發(fā)現bug極其耗時(shí)且成本高昂，這促使團隊嘗試盡可能的將質(zhì)量?jì)惹兜疆a(chǎn)品內部。但這并不意味著(zhù)手工測試毫無(wú)價(jià)值，因為人們總能在怎樣使用軟件上給你一些特別的驚喜。

　　這是一個(gè)為期18個(gè)月左右，周期很長(cháng)的項目，并且后續也會(huì )持續更新。 在項目初期，團隊就意識到項目成功的重中之重在于一個(gè)優(yōu)秀的測試策略，尤其是讓我們的團隊能夠做到：1)隨著(zhù)項目時(shí)間的推移能夠持續的提高團隊的工作效率。2)不管面對的變更是大是小都能夠具有足夠的信心。

　　我們花費了很長(cháng)時(shí)間才確定了一種有效的策略。這在很大程度上是因為我們不得不學(xué)習怎樣讓我們的程序在所有層上都具有可測性。雖然所有的項目團隊成員都具有TDD(測試驅動(dòng)開(kāi)發(fā))的經(jīng)驗，但僅僅這樣并不足以建立有效的測試策略。

　　測試分層

　　給不同的測試分類(lèi)是一件令人煩惱的事。有功能測試，集成測試，單元測試，驗收測試，slow tests，fast tests，UI測試...等等等等。然后我們發(fā)現屬于我們的測試主要有三種類(lèi)型：

　　系統測試

　　皮下測試

　　單元測試

　　它們之間的區別主要在于被測試內容的范圍。系統測試指的是通過(guò)應用的外部接口進(jìn)行運作，無(wú)論對象是一個(gè)瀏覽器，文件下拉菜單，隊列，window窗體應用或者其他的什么東西。

　　皮下測試運行在外部用戶(hù)接口之下。如果測試的是Web應用，皮下測試在我們理解就是指在真實(shí)的類(lèi)

　　以及環(huán)境部署到位的情況下，通過(guò)命令處理器進(jìn)行發(fā)送的表單對象。繞過(guò)UI層邏輯，直接到達domain層。發(fā)送表單對象，拋出”成功/失敗”的執行結果。

　　對于最底層而言，我們有單元測試。單元測試用于測試一個(gè)類(lèi)，并且可以是fast test 或者 slow test中的一種。Fast Test 即是常規的TDD測試，用于增量的類(lèi)設計。Test doubles曾被認為是必要的，但是除非系統交互非常值得關(guān)注，否則嚴格的 基于交互的測試 并不是那么有價(jià)值。我們同樣也有slow 單元測試，其同樣可被分類(lèi)為 交互測試。當然它們同樣可歸類(lèi)為 repository tests, persistence tests等。

　　單元：皮下：系統 測試在我們的測試工作中各自占的比重差不多是 10:2:1。 為了完成項目我們做了大約 5000 個(gè)單元測試，1000個(gè)皮下測試，500個(gè)使用 WaitN 以及 Gallio驅動(dòng)瀏覽器的系統測試。6000個(gè)單元/皮下測試的執行時(shí)間大概是10分鐘，而剩下的500個(gè)UI測試大概需要50分鐘完成。

　　單元測試策略

　　單元測試是在嚴密的TDD模式下開(kāi)發(fā)的。我們在功能實(shí)現之前編寫(xiě)單元測試，并用這些測試驅動(dòng)代碼設計。這些測試可以幫助發(fā)現設計問(wèn)題、封裝問(wèn)題、代碼異味等。

　　我們努力避免編寫(xiě)純粹用于提供測試的代碼。它們常常意味著(zhù)我們有設計問(wèn)題、責任錯位或封裝已被破壞。

　　隨著(zhù)我們越來(lái)越深入項目管道，我們對交互測試的重視越來(lái)越少。 如果你真的對交互感興趣，那么通過(guò)mock進(jìn)行的交互測試也僅僅是有趣而已。但更多的時(shí)候，我們更感興趣的是附加作用，而交互只是一個(gè)實(shí)現細節。反之，我們經(jīng)常做的是模擬(mock)出過(guò)慢或不可測的代碼，比如存儲庫、基于外部服務(wù)的外觀(guān)、配置類(lèi)等等。否則，我們有限的模擬只是模擬了我們感興趣的那些觀(guān)察點(diǎn)。

　　在大型項目中的某些時(shí)間點(diǎn)，為了提取出能加快功能交付的理念，設計往往需要做大型的重構。在我們上一個(gè)項目中，我們發(fā)掘出了如下理念：

　　AutoMapper

　　將表單作為單獨的命令消息處理

　　Input builders

　　有了以上這些，單元測試是重構時(shí)的保障。但只有我們依賴(lài)這些測試來(lái)捕獲應用程序中所有有趣的行為時(shí)，才能有保障的作用。為了允許有效的大中型重構，我們需要增加額外的測試層級。

　　皮下測試策略

　　皮下測試，顧名思義，所有的測試都是在用戶(hù)界面之下進(jìn)行的。在MVC應用程序中，皮下測試是測試控制器下面的所有內容。對于Web service，一切測試都在終端下進(jìn)行。皮下測試的思想是，應用程序的最上層不執行任何實(shí)際的業(yè)務(wù)邏輯，而只是外部接口與底層服務(wù)之間的連接。

　　皮下測試的重要性體現在我們希望在拋開(kāi)如用戶(hù)接口和外部服務(wù)這類(lèi)外部連接點(diǎn)的情況下，能夠在整個(gè)系統運行的同時(shí)測試業(yè)務(wù)邏輯。相對于單元測試關(guān)注小模塊的設計，皮下測試關(guān)注的不涉及設計，而是測試整個(gè)系統的基本輸入和輸出。

原文轉自：http://www.uml.org.cn/Test/2014052911.asp