敏捷開發中的軟體測試

敏捷開發中的軟體測試

陳能技

2007-9-5

參考：bret pettichord 的《agile testing - what is it? can it work?》和《agile testing challenges》

敏捷宣言：個體和互動比過程和工具更有價值；能工作的軟體比全面的文件更有價值；顧客的協作比合同談判更有價值；及時響應變更比遵循計畫更有價值。- www.agilemanifesto.org

什麼是敏捷測試？

測試遵循敏捷宣言進行，把開發作為顧客看待。專案的測試採用敏捷方**。

敏捷測試的原則與上下文驅動測試（context-driven testing：www.context-driven-testing.com）的原則有交集，例如，上下文驅動測試的七大原則中的第三條：工作在一起的專案組成員是專案的上下文的最重要的組成部分。就與敏捷宣言中的「個體和互動比過程和工具更有價值」一樣強調人的作用。

敏捷測試中測試人員扮演的角色

1、

測試是專案的「車頭燈」，它告訴大家現在到哪了，正在往哪個方向走。 2、

測試為專案組提供資訊，使得專案組基於可靠的資訊作出正確的決定。 3、

「bug」是讓使用者感覺煩惱的東西，測試人員不作出發布的決定。 4、

測試員不保證質量，整個專案組對質量負責。 5、

測試不是抓蟲子的遊戲，它的目的不是糾纏在錯誤中，而是幫助找到目標。

單元測試和可接受性測試

測試驅動開發，開發人員在寫**之前要先寫單元測試，用於激發**的編寫、改進設計（降低耦合度，增加內聚）、支援重構。很多開源的測試工具支援單元測試（xunit）。

使用者故事是需要編碼實現的功能特性的簡短的描述。可接受性測試驗證使用者故事的完整性。理想的情況下，使用者故事是在**編寫前就寫完。

測試人員是否應該擁抱敏捷開發？

有些人說xp會導致差的質量並且是偷懶的藉口。我認為xp是令人激動的，並將在行業中改進測試的實踐。

參見《testers should embrace agile programming 》

（ 敏捷測試實踐

通過對話產生測試，誰來測試？客戶往往太忙了，不可能參與測試。定義測試是很關鍵的活動，應該把開發人員和顧客代表包括進來，不要只是測試員自己做。

把使用者故事轉換成測試。測試提供的是目標和指南、及時的反饋、進度度量。測試應該用指定的格式出現，以便讓使用者或顧客能清楚明白，還要足夠的明確，以便能被執行。

開發人員負責提供支援自動化測試的特性。大部分情況下，為產品新增測試介面，而盡量不用外部測試工具。

計畫在每個迭代中探索產品，尋找bug、遺漏的特性和改進的機會。

進一步學習