軟件測試之驗收測試的自動化

　　今天下午給同事就自動化驗收測試做了一個簡單的介紹，引起了大家的陣陣討論。同時還有其他Team的人來分享各自的經驗，他們也都做得相當不錯。

　　測試包括很多種，單元測試、集成測試、功能測試、驗收測試、數據庫測試等等。撇開大家都熟悉的單元測試、功能測試不談，為什么這里要單獨拿驗收測試來說自動化呢?

　　首先談談準備一次發布要做哪些事情。首先得驗收這個迭代里面的所有Story，功能符合驗收條件，沒有bug。然后呢，需要對以往的所有迭代的Story都要進行回歸測試，來驗證這個迭代里面的修改沒有破壞以前的功能。如果全部通過，或者核心功能工作完好，那么系統就能進行發布了。

　　由此看來，測試人員的工作量相當大，驗收Story+回歸所有功能。如果在一個發布很頻繁的互聯網項目上，兩周甚至一周一個發布，要是這些活全部手工做的話，測試人員就得累得吐血了。即使這樣，血吐光了都不一定能測得完。測不完?所有人都來做測試，所有人都得吐血了。“人肉測試”不僅僅是很難完成任務，而且還有以下幾個問題：

　　1. 重復勞動。這樣一件事情，每次都得做一遍，煩不煩?

　　2. 人工測試精確度不高，容易出錯。人不是機器，沒有百分百的準確性，某個時候肚子餓了，或者聽說股市大跌，精神一緊張，手一抖，就測不準了。

　　3. 浪費人力，物力和時間。一大堆人花大量時間來測試，測試完還得花時間寫書面報告，成本增長的那個快。

　　結論是人肉測試不行!能自動化的必須得自動化。因為有了自動化以后：

　　1. 系統質量得到保證。任何時候，只要測試通過，你就能勇敢的說：看!測試全過，功能肯定沒問題。

　　2. 消除浪費。上面所提到的人力、物力和時間的浪費都能消除掉。

　　3. 加快了測試速度。人工測試需要兩天的，自動化通常2個小時可以測完。累得吐血這種情況已經看不見了。而且自動化測試可以通過一系列的方法，比如使用更好的機器，將測試分布式運行等來加速。

　　4. 提高測試的效率和準確性。自動化測試是高效的，它一刻也不停的在運行。同時它也是準確的，程序代碼幫你做驗證，不會有任何偏差。

　　5. 勇氣和反饋。開發人員有勇氣去修改、維護或重構代碼，有的時候即使單元測試通過，功能不一定正確。有雙重保證的話，開發人員就有足夠的勇氣。項目所有人都有勇氣說發布，不會像以前那樣戰戰兢兢。

　　6. 可閱讀的文檔。??收測試的代碼就是測試用例?？创a就是看用例，一步一步，清晰明確。不需要投入精力去維護一份測試用例文檔，而且很有可能是過期不管用的。

　　自動化測試，不管是XP、精益還是DSDM都把它放在最重要的地位。如果還處在人工測試階段上的朋友，請自動化它們吧。

　　如果寫好測試，也是一門很高深的學問。不要認為寫測試是測試人員的專利，不管白盒黑盒，寫出漂亮的測試是開發人員的基本素質。先看看下面這個測試，以Watir+RSpec為例：

　　it “Scenario: create story with full information” do

　　@browser.open(…)

　　@browser.text_field(:id, ‘..’).set story_name

　　@browser.text_field(:id, ‘..’).set story_description

　　……

　　@browser.button(:id, ‘..’).click

　　@browser.div(:id, ‘..’).text.should contains(‘…’)

　　……

　　end

　　這里描述了一個場景，用戶填寫一些字段，然后保存提交來創建一個用戶故事。細看每一行代碼，會發現看不懂!不知道每一行代碼是在做什么。無法領會寫測試人員的意圖。

　　這段代碼最大的問題是其脆弱性。測試代碼跟頁面元素、結構緊緊耦合在一起，而UI元素是會經常被重構被改變的，一旦改變，很多測試用例就會失敗，需要做出相應的修改。

　　要想同時解決這兩個問題，可以引入Page Model模式(相信ThoughtWorks的人都會用)。上面的代碼便可以寫成這樣：

　　it “Scenario: create story with full information” do

　　create_story_page = @navigator.goto_add_story_page

　　create_story_page.add_story :name=>’…’, :description=>’…’

　　……

　　view_story_page = page.save_and_view

　　view_story_page.information.text.should contains(‘…’)

　　……

　　end

　　下面再來一個復雜點的測試用例

　　it “Scenario: import all the stories from excel file”

　　import_stories_page = @navigator.goto_import_stories_page

　　import_stories_page.import_from excel_path

　　preview_page = import_stories_page.preview_import

　　preview_page.choose_import_stories :all

　　preview_page.to_next_page

　　preview_page.choose_import_stories :first

　　story_list_page = preview_page.confirm_import

　　story_list_page.stories.should contains(‘imported story1’)

　　……

　　end

　　看!代碼是不是可讀性很好，業務意圖是不是很清晰。每一行代碼都是一個業務操作，代表著測試用例的一個步驟，最后是一些斷言，進行驗收。斷言也避免了assertEquals這種寫法，采用RSpec的should來達到可讀性最佳，最貼近人類語言的效果。如果你仔細看看這段代碼，會發現它沒有一點UI元素的操作在里面。UI再怎么重構，頁面結構再怎么變化，測試用例代碼都是穩定的。

　　因為Page Object封裝了UI元素和結構，使得測試代碼穩定，達到要修改只修改一處的效果。同時，Page Object也封裝了業務行為及操作，使得測試代碼更可???。Page Model還有幾個重要的概念，Driver, Navigator, DataFixture，其實都是封裝了不同的變化點，這里也不多做介紹。

原文轉自：http://www.anti-gravitydesign.com