關于自動化測試，關于Agile，關于團隊

　　在第一時間越獄了New Pad，開始把之前眼饞又買不起的App逐個開始下載安裝，估計又得花相當一段時間來適應這些辦公App了。

　　團隊的成員已經逐漸適應了我分享給大家文章，大家閱讀之后融入自己的一番思考并寫下blog的方式。在Agile的轉型中，驅動每個成員自主的來思考，產生改進的意愿，這可能是最重要的一個環節了。特別是在一個測試團隊中，大家深入理解Agile之后對自動化的渴望尤其迫切，我自主研發了項目的第一代自動化工具，大概Cover了100來個Case，但是由于coding比較快，穩定性和運行速度都不是很理想?，F在團隊更加理解自動化的威力和在Agile 流程中對待它的態度之后，我決定開始重構第一代的自動化工具，逐漸往一個framework的方向上來擴展。

　　在新的framework設計和底層的架構中，我不得不時刻都提醒自己的以下幾點：

　　1. 一次只專注一件事：

　　公司也有許多項目團隊在做自己的自動化，也有專門的自動化組，雖然大家都很努力，但最理解我們項目應該如何測試，大家最需要的自動化是什么樣子，還是只有我們最清楚，我把團隊的分析都逐一記錄下來，一次只專注做其中的一件事，直到大伙都能滿意的使用它為止。這一點個人覺得特別重要，泛泛而談一個自動化框架，基于Web項目，可能包括方方面面的東西，頁面的識別、安裝磁盤文件操作、Case的設計、數據結果分析、測試報告的詳盡……等等，如果我們什么都想要，什么都快速的完成并發布使用，到頭來會發現，每一塊都存在不小的缺陷，并且隨著技術的革新、產品的更新換代，陷入不斷的維護每一塊的漏洞和更新自動化框架的漩渦中無法自拔。所以，挑選最重要的一項開始，使用 Agile同樣的思路，不斷的快速迭代，保證能使用的一定是穩定且有價值的功能。

　　2. 讓全員參與起來：

　　由于團隊都基本具備了Agile的意識，我不再像第一代工具一樣個人開發僅僅讓大家來使用，而是讓整個團隊全員都參與進來。為了讓本不具備編程能力的全員團隊成員可以參與進來，我非常小心翼翼的設計底層的代碼結構和繼承關系，控制暴露出來的API清晰表意，簡單易懂。大家可能在不懂Java的代碼的情況下，就完成了許許多多的Java方法的編碼，這里我舉一段代碼作為例子：(這段代碼執行了一串頁面操作流程，Cover了系統的某一個功能點，基本上規避了Java的許多繁瑣語法和原貌)

page.home("Administration").go("Manage Device Groups");
grid.locate("Device Groups").toolbar("New Subgroup");
dialog.radio("Staging");
dialog.to("Next").form("Group Name=testGrp1", "Description=testGrp description");
dialog.click("Not specified");
dialog.popup().check("operator");
dialog.popup().click("OK");
dialog.to("Finish").process();

　　3. 三層架構：

　　幾天前剛看了一篇文章分析自動化框架的設計思路，傳統的自動化思路叫原型式：主要是界面錄制回放，它暴露的種種弊端例如：難以重用、環境依賴產生的不穩定性，步驟死板難以擴展并插入界面之外的判斷……當下的自動化，主要思路已經不一樣了，主要強調的是：界面在運行的過程中不要傻傻的等待而是持續的在后臺去做一些事情，為了重用和擴展測試數據和腳本要優雅的分離，整個自動化已經趨向開發所經常使用的MVC模型：表示層、數據層、邏輯層。頁面的識別和跟蹤操作隸屬于表示層，而頁面的調度和數據的選取、分析，甚至后臺功能的配對檢查隸屬于邏輯層，真正分離出來管理的測試數據隸屬于數據層。三層之間由框架負責協調和管理，最終即使遇見重大更新，也可以化繁為簡，只動到某一層中間的一些組件。

　　4. 完整的核心：

　　測試的核心是測試用例，在未來的道路上，我們希望每一步都走得能讓心里踏實，所以即使在最初大家有許多很不錯的想法，我逐一記錄下來卻告誡并不能什么都想要。對一個TestCase這個核心組件的定義上，我們已經有了一個很完整的想法，這里我只是留下了一張草圖和想法，在我們看來，一個TestCase應該包括的部分包括：

　　Pre-Condition: 前置條件，脫離界面的不確定性，直接在后臺檢查

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