淺談功能測試之美[1] 功能測試用例
功能測試之樂:
功能測試定義了產品的業務需求，通過它業務人員可以了解系統是否能在各個業務場景下正常工作。功能測試通常使用某種自動化測試框架編寫，這樣開發者可以從自動化的功能測試中獲得快速反饋，為下階段新功能的開發或軟件內部實現的重構提供幫助。另一方面，它大大減少了手動環節可能引入的錯誤，而將枯燥的回歸測試交給機器完成，在加快測試速度的同時，將質量保證人員解放出來，從而使他們可以更多地關注于創造性的探索測試。通過從用戶角度進行的功能測試，團隊對系統在真實條件下的可用性充滿信心，而自動化的功能測試也大大提高了工作效率。這樣一來，產品能以更高的質量，更快的速度進入市場。
功能測試之苦:
* 保持驗收條件及其技術實現的同步
在任何開展自動化功能測試的敏捷開發團隊中通常會存在兩套系統、 一套是BA(業務分析師)\QA(質量保證人員)所編寫、維護的驗收條件，可能以紙卡、Wiki等形式記錄下來。另一套是驗收條件的技術實現。以源代碼的形式記錄，由開發者維護。兩套系統的并行發展，帶來了同步的問題。如何快速將驗收條件轉變為技術實現?當驗收條件變化時如何使源代碼部分同步變化?可不可以將驗收條件與測試關聯起來，利用Rspec的思路消除這個并行的系統?
* 無法系統化的劃分測試
速度是阻礙頻繁運行功能測試的主要原因。進行功能測試的團隊常�；ㄙM數十分鐘甚至數小時來運行完整的功能測試套件，加快測試幾乎總以失敗而告終，從用戶角度進行業務場景的測試決定了功能測試的速度天生就是緩慢的。隨著軟件功能的日益完善，更多的測試被添加到套件中，龐大的套件也使得測試運行的時間越來越長。無法快速得到反饋使團隊沒有安全感，同時大大減緩開發的腳步，煩躁的開發者甚至開始逃避運行測試，將不安全的代碼集成到產品中。
只運行相關的測試，聽起來這似乎是一個解決方案。當開發者修改了登錄模塊的實現后，為什么他們非得花費1個小時等待其他模塊的測試結果呢?如果可以僅僅運行登錄模塊相關的測試，將其余的測試留給持續集成工具運行，開發的效率將大大提高。但遺憾的是在XUnit的世界中，系統化的劃分測試并不是件容易的事情。不論是利用文件名和目錄來區分，還是手工維護測試套件，最終總會變成難以維護的大泥球。
* 閱讀測試花費的大量時間
大量測試代碼總是難以閱讀。隨著項目的進行， 各種不同習慣的縮寫出現在代碼中、測試代碼中出現的大量的方法、設置數據越來越復雜等都給閱讀測試帶來了極大的麻煩。面對失敗的測試，試圖修復它的開發者總是需要在復雜的代碼中掙扎著找出測試的意圖，過濾掉準備數據的過程，抽絲剝繭地找到這個測試所覆蓋的業務流程，分析究竟是哪個產品模塊出了問題。出現這樣問題的根源是沒有對測試的目的 (業務價值)和技術實現做出合理的抽象。
能否有這樣一個視圖，過濾掉所有讓人分散注意力的方法(私有方法，準備數據、清理數據的方法等)讓開發者可以清楚地看到測試的目的和步驟，甚至讓測試以一種自然語言的形式展現出來，讓非技術人員也可以輕易地閱讀修改測試呢?
* 啟動功能測試的花費
在任何一個團隊開始功能測試的第一步，總是耗時和痛苦的。下載各種依賴的庫文件，在腳本中進行配置， 保證功能測試可以在命令行執行， 同時還要對IDE進行配置，讓開發者可以從IDE中方便地運行單個測試。
能不能縮短這個過程，減輕開發者的痛苦?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
