產品開發中 敏捷測試該怎樣進行

什麼是敏捷測試呢?敏捷測試當然不能簡單地理解為測得更快，絕對不是比以前用更少時間進行測試，也不是將測試的範圍縮小了或將品質降低來減少測試工作。 也有人說，只有敏捷開發，沒有敏捷測試。 下面我們將要討論一下：

● 究竟什麼是敏捷測試?

● 敏捷測試有哪些流程改進?

● 測試人員如何面對敏捷測試的挑戰?

● 在敏捷測試中如何制定相應的自動化測試策略?

什麼是敏捷測試

假如將過去傳統的測試流程和方法硬塞入敏捷開發流程中，測試工作可能會事倍功半，測試人員可能會天天加班，而不能發揮應有的作用。 敏捷測試應該是適應敏捷方法而採用的新的測試流程、方法和實踐，對傳統的測試流程有所剪裁，有不同的側重，例如減少測試計劃、測試案例設計等工作的比重，增加與產品設計人員、開發人員的交流和協作。 在敏捷測試流程中，參與單元測試，關注持續反覆運算的新功能，針對這些新功能進行足夠的接受度測試，而對原有功能的迴歸測試則依賴于自動化測試。 由於敏捷方法中反覆運算週期短，測試人員儘早開始測試，包括及時對需求、開發設計的評審，更重要的是能夠及時、持續的對軟體產品品質進行回饋。 簡單地說，敏捷測試就是持續地對軟體品質問題進行及時地回饋，如圖1所示。

圖1 敏捷測試定義的形象描述

敏捷測試流程的優化

在敏捷方法中，需求變化比較快、產品開發週期很短，我們目前採用四周時間，也就是每個月發佈一個新版本。 開發週期短，功能不斷累加，給軟體測試帶來很大的挑戰，軟體測試流程要做相應的調整。 例如，我們原有的測試規範明確規定，首先要建立專案的主測試計劃書，然後再建立每個功能任務的測試計劃書，測試計劃書有嚴格的範本，而且需要和產品經理、開發人員討論，並和測試團隊其他人員(包括測試經理)討論， 最終得到大家的認可和簽字才能通過，僅測試計劃經過「起草、評審和簽發」一個完整的週期就需要一個月。 在敏捷方法中，不再要求寫幾十頁的測試計劃書，而是在每個反覆運算週期，寫出一頁紙的測試計劃，將測試要點(包括策略、特定方法、重點範圍等)列出來就可以了。

在原有測試規範中，要求先用Excel寫出測試案例，然後進行討論、評審，評審通過以後再導入測試案例庫(線上管理系統)中。 在敏捷測試中，可能不需要測試案例，而是針對Use Case或User Story直接進行驗證，並進行探索性測試。 而節約出來的時間，用於開發原有功能的自動化測試腳本，為迴歸測試服務。 自動化測試腳本將代替測試案例，成為軟體組織的財富。 原有測試規範還要求進行兩輪迴歸測試，在敏捷測試中，只能進行一輪迴歸測試。 綜合這些考慮，敏捷測試的流程簡單有效，如圖2所示。

圖2 敏捷測試流程簡要圖

在敏捷測試流程中，如前所述，測試是一個持續的品質回饋過程，測試中發現的問題要及時回饋給產品經理和開發人員，而且某些關鍵方面也要得到我們足夠的關注，主要有：

● 測試人員不僅要全程參與需求、產品功能設計等討論，而且要面對面地、充分地討論(包括帶語言、視頻的即時通訊)，僅僅通過郵件是不夠的。

● 參與代碼複審(Code Review)，並適當輔助開發人員進行單元測試。

● 在流程中增加一個環節「產品走查(Product Walk-through)」——測試人員和產品經理、開發人員等在一起，從頭到尾將新功能看一遍，可直觀、快速地發現問題。

新功能的測試和迴歸測試策略

測試工作簡單地可分為新功能測試和迴歸測試。 在敏捷方法中，針對這兩部分的測試建立相應的策略，以提高測試的效率，最大限度地降低品質風險。 新功能測試的策略主要有：

● 不需要測試案例，直接基於用例和對需求的理解來完成新功能的驗證。 即使要寫測試案例，只要保證各個功能點被覆蓋，不要過於詳細(大顆細微性)。

● 持續地進行驗證，一旦某塊新代碼完成(Code Drop)，就開始驗證，而不是等到所有代碼完成後才開始測試。 這也包括參與到單元測試和集成測試中。

● 實施端到端(End-to-End)的測試，確保完整的業務流程的實現，同時，也容易發現業務邏輯不夠清晰、不夠合理等各方面的問題。

● 閱讀代碼來發現問題，可以和開發人員工作保持同步，消除測試週期的壓力。

● 基於經驗，可以實施更多的探索性測試、組合交互性(Interoperation)測試和使用者場景(User Scenario)測試，更有效地發現埋藏較深的缺陷。

迴歸測試是敏捷測試中需要面對的難點。 每次反覆運算都會增加新的功能，一個產品可能會經過十幾次、甚至幾十次反覆運算，迴歸測試範圍在不斷增大，而每次反覆運算週期沒變，可能還是一個月。 這樣接受度測試的時間非常有限，所以迴歸測試很大程度上依賴于自動化測試，因為很難將迴歸測試控制在非常有限的範圍內。 當然，還是有些辦法可以説明我們減少迴歸測試的範圍，例如：

● 通過執行Code Diff 來瞭解代碼變動的所有地方，再做代碼關聯分析，就可以明確知道要進行哪些地方的迴歸測試，迴歸測試範圍會大大縮小。

● 基於風險和操作面分析來減少迴歸測試的範圍，例如迴歸測試只是保證主要功能點沒有問題，而忽視一些細節的問題。

● 持續測試的過程，只要有時間，就進行測試，包括開發人員、產品設計人員都參與到日常的試用和測試中來。

自動化測試策略

由於開發週期短，需求、設計等方面溝通也需要花費很多時間，沒有足夠時間開發自動化測試腳本，至少對新功能的測試很難實現自動化測試。 這時候，就需要正確的策略來提高自動化測試的效益，如圖3所示，並說明如下。

圖3 自動化測試的策略

● 構建一個靈活的、開放的自動化測試框架，如基於關鍵字驅動的自動化框架，使測試腳本的開發簡單易行，腳本維護也方便。

● 針對穩定的產品特性開發自動化測試腳本，也就是針對前期完成的已有功能開發自動化測試的腳本，而大部分新功能測試採用手工測試

● 集中精力在單元層次上實現自動化測試，主要由開發人員實施，測試人員提供單元測試框架，並輔助完成一些所需的基礎工作。

● 在產品設計、程式設計時就很好地考慮了自動化測試的需求，使全面的、自動化的底層測試、介面測試成為可能，儘量避免使用者介面(UI)的自動化測試。

● 良好的IT基礎設施，包括自動化構建套裝軟體、自動化版本驗證(BVT)、自動化部署、覆蓋率自動產生等。

敏捷測試控管

自動化測試依賴于測試控管，所幸的是，目前已有很多敏捷測試控管。 由於篇幅所限，這裡只是簡單地列出一些常用的敏捷測試控管，不再深入討論了。

● 單元測試工具：TestNG、xUnit家族(如JUnit、NUnit)、JMock、BizMock等。

● 功能測試自動化：ThoughtWorks Twist。

● Web功能測試(frontend)：Selenium IDE/RC、WatiR、WatiN。

● Web service測試控管(backend)：soapUI。

● 效能測試：JMeter+BadBoy。

● 接受度測試框架：Fitnesse、Tellurium。

● 敏捷測試過程管理工具：微軟的Visual Studio 2010，包括TFS 2010、Scrum範本(MS VS Scrum 1.0)、Test Manager 2010、Coded UI Test等。

● 業務智慧(BI)應用的測試框架：Oraylis BI. Quality (+ NUnit)。

● 其他一些協作工具等，如TestLink、BugZilla、BugFree、Wiki等。

測試人員在敏捷方法中的價值

在敏捷方法中，開發人員的主導作用更明顯，系統設計、程式設計實現、單元測試、重構等看似關鍵的一些任務都落在開發人員身上，測試人員容易被邊緣化。 那麼，在敏捷方法中，測試人員的價值又如何體現呢?

● 在需求和功能設計討論上，測試人員可以站在客戶角度來闡述自己的觀點，扮演「使用者代表」角色，強調使用者體驗，真正體現測試人員和開發人員的互補作用。

● 測試人員不僅扮演「使用者代表」角色，而且通過需求討論、代碼複審等各種活動及時地提供品質回饋，包括代碼品質、介面一致性等，保證在產品構造的整個過程中品質受到足夠的關注，以提高品質改進的持續性和可視性。

● 測試人員應積極參與單元測試，即使不參加單元測試，也應督促開發人員進行單元測試，確保單元測試達到80% 以上覆蓋率，確保開發出具有良好可測試性的代碼。

● 在敏捷方法中，往往將一個大的系統開發分解成多個小的子系統(模組或元件)，集成測試和端到端(End-to-End)測試顯得更為重要，測試人員在這些測試上能發揮更大的作用。

● 產品發佈前，接受度測試和迴歸測試依然不可缺少，這更是測試人員的用武之地。

● 一個反覆運算週期結束後，對缺陷根本原因進行分析、總結規律，説明開發人員建立良好的習慣，預防缺陷，從根本上提高產品質量。

理想情況下，測試人員掌握設計模式、具有很好的程式設計能力，可以和開發人員進行角色互換，如在當前版本開發中擔任測試人員角色，在下一個版本開發中則擔任開發人員角色。 這樣雙方對不同角色的工作有著更深刻的認識，消除溝通的障礙，開發的效率和品質會有進一步的提高。

總結

根據上面的討論和我們的實踐，最後針對敏捷測試進行一個簡單的總結，就是：

● 敏捷測試就是持續測試、持續回饋，扮演「使用者代表」角色，確保產品滿足客戶的需求。

● 敏捷功能測試 = 新特性的手工測試(Use Case驗證和探索性測試) + 原有功能的自動化測試 (迴歸測試)。

● 敏捷測試人員和開發人員的區別越來越小，理想情況下，敏捷方法中，測試人員和開發人員在不同的反覆運算週期可以互換。

● 敏捷測試流程依據不同的團隊特點、不同產品的特點而不同，因地制宜，適合才是最好。