敏捷開發實踐總結（二）關於測試

用了兩個衝刺週期，我們組算是把敏捷開發的測試流程給捋順了。這裡對我們的測試，以及敏捷開發中的測試做乙個小結。

一、開發組一定不能諱疾忌醫。

作為開發人員，一定要秉著這個出發點去看待測試。業務測試測試組測試，自測，與開發組的目標是一致的，都是為了保證和提高專案質量，沒有誰要給誰找茬。

二、自測是第一步。

開發組自測必須是白盒測試。必須保證覆蓋率。必須是自動化測試。盡量做到交叉測試。

三、測試組測試

測試組的測試應該是最全面、細緻的。至少應是黑河測試。盡量做到白盒測試。應該具備各種效能測試的能力。測試組與業務人員、開發組要有有效、及時的溝通。

四、業務測試

業務測試的目的是需求驗收。基本只能做到黑盒測試。要做好溝通，並通過測試溝通體現業務需求、設想。

五、整個測試要有統一的記錄、反饋渠道。

如果開發組、測試組、業務組人手乙份測試記錄，很可能出現測試反饋記錄遺漏、版本錯亂等問題。

六、測試驅動。

測試驅動是個很不錯的東西。在邁步子之前先投石問路，就會知道到哪一步應該注意什麼。

敏捷開發中的測試，帶著敏捷的特點。

一、小版本。

敏捷開發的核心就是小版本需求，針對需求進行測試的功能必然也是小版本的。

二、頻率高。

所謂「小步快跑」，小版本帶來的另乙個特點必然就是測試、反饋頻率高。

三、溝通多。

本身敏捷開發的各種溝通就多。測試階段又會與業務人員直接關聯，各種關於需求理解、改動和成本的溝通必然也會增加。

四、測試、反饋帶有業務優先順序。

根據業務流程的重要性、緊急性，給測試反饋的bug排列優先順序。一方面，這種優先順序是業務價值的體現，也是敏捷開發的目標；另一方面，這種優先順序要求方便開發組安排有限的時間和人力；此外，對優先順序的排序還可以從乙個側面反映出業務需求的一些核心思路。

五、開發組自組織、自驅動性強。

關於敏捷開發的自組織和自驅動，我到現在也沒有吃透。從已有經驗來看，乙個大需求分割成小版本，並分派到各開發人員之後，各個小版本的開發、測試等工作基本就有開發人員自己掌握和推動，即使是專案負責人也很難掌握得太細。這是一種自驅動。

六、版本隔離、合併等管理工作要求高。

小版本意味著版本多，版本多意味著版本衝突的風險大。因此，敏捷開發對版本管理的要求也更高。

七、自動化

自動化也是版本多、速度快所要求的。不僅包括測試自動化，還應包括構建自動化、發布自動化等。

我們專案組現有的測試流程

現在的測試流程，借鑑了tx的敏捷流程，採用「測試班車」和「測試包車」的形式組織測試。自測和測試驅動方面開展得不太順利，還在繼續推動之中。

「測試班車」是定期的測試版本。我們的乙個衝刺規劃為3周。通常，前兩周的測試都採取「測試班車」的形式，每隔兩天（周二下午和周五上午）發布乙個測試版本，交由測試組進行測試。

「測試包車」是不定期的測試版本，什麼時候有公升級就什麼時候包一趟車。我們組通常從第二週開始就會有測試包車。第三週開始將版本發布到stage測試環境上，交由業務組進行測試。第三週的測試反饋和更新基本都是採用包車的形式。

目前測試組的測試反饋統一由mantis系統進行管理。業務組的測試反饋目前沒有統一的工具，僅由業務人員整理成統一的文件。

敏捷開發實踐總結（二） 關於測試