1. 保證自動化測試成功的三塊基石
保證軟體項目的自動化測試工作成功，如果有三個方面能夠做好，那麼項目成功即自動化測試成功指日可待。那麼，它們是什麼呢。它們分別是資料、自動化，以及工具。在此我們分別來討論一下它們。
資料：對於驗證日益複雜的軟體功能來講，測試資料的有效性是極其重要的，並且如果測試資料是能夠重複的，那麼才能夠保證自動化測試的效率。所以對於資料來講，我們要求它是能夠被定製的，能夠恢複的並且可以重複使用的。如果上述這些內容能夠是自動的，那麼資料部分就應該準備的比較充分了。通常情況下，我們的手工測試資料與自動化測試資料是混雜在一起的，通常情況下會互相受影響。特別是當你的軟體項目有許多個release的時候，你每次為之前的項目跟自動化測試指令碼的時候你就會探索資料幾乎不能使用了，我們差不多需要為每個指令碼重複製作資料，這其中的成本是很大的，而且自動化測試有效率的特性也無法顯現。當然對於這種情況有多種不同的解決方案，我的建議是自動化測試部分的資料是能夠獨立存在的。當然你得保證它的有效性，這裡不做具體的討論，大家可以嘗試多思考交流解決。
自動化：關於自動化，我們主要是講自動化測試，也就是說，我們的使用者需求，能夠被轉化為自動化測試指令碼，這些自動化測試指令碼能夠對軟體進行測試，從而保證軟體功能變便以及重構後，其功能及商務程序未被破壞。對於自動化測試來講，我們希望是能夠有較高的自動化測試覆蓋率，從而獲得大量時間成本。同時我們也希望較少的指令碼的維護。所以針對於自動化測試指令碼來講，我們更應該從軟體開發的角度去考慮，構建以及維護它。而不應該簡單將手工測試案例轉化為自動化測試。如果只是將手工測試案例轉為自動化測試案例，我們將會花費大量的時間在維護測試指令碼，測試物件程式庫等等方面。當然，我們這裡提到自動化，我們也指軟體工程的其它方面也被自動化，不只限於自動化測試。如果我們的整個工程大部分或絕大部分是能夠自動化的，那麼我們的生產力就會得到提升。例如：如果我們能夠有自動化測試指令碼，那麼我們的自動化測試執行也應該是被自動調用的，並且最終的測試結果以及度量結果都應該是可以被自動擷取的。簡單來說，一切都應該被自動化。
......
2. 自動化測試生產力
最近，被同事問到一個有趣的問題，就是自動化測試生產力。我們的自動化測試生產能力是多少，如何知道我們每年的自動化測試生產力是提升了，還是下降了。針對此總題，我覺得這其實是對要求我們能夠有資料指標來衡量一個企業或團隊的自動化測試能力。關於這個指標如何定義，我相信各個企業一定有自己的標準。但我想資料的擷取應該是類似的，也就是說，那些參與運算的資料應該是差不太多的。在提及這些資料之前我想說一下關於手工測試能力的考察方法，通常大家會把每年寫了多少測試案例，執行了多少測試，通過了多少，也有無效的defect有多少等等這些資料考慮進去。對於自動化來講，我們也會考慮相關資料，如我們的自動化測試覆蓋率，我們的指令碼被啟動並執行多少次，pass多少次，我們節省了多少時間，我的指令碼維護成本是多少等等，有了這些基礎資料，我們就可以定製企業自己的自動化測試生產力模型，完成對自己企業或是團隊的自動化測試能力的衡量工作。
3. 自動化測試架構
關於自動化測試架構，這其實是一個非常有意思的現象。為什麼這麼說呢，因為我們會發現，大多數自動化測試團隊都會實現一個自動化測試架構，然後做為標準或規範在團隊內推廣。而且一但有了自動化測試架構後，我們就會發現，我們的自動化測試指令碼開發效率提高了，而且了也規範了許多。這是一件好事，但在這裡我想說的事，不要過度架構化，自動化測試的架構還是要儘可能的遵循複用的原則。千萬不要搞我之前曾經實現過的類似的關鍵字架構，我認為目前所有的所謂的關鍵字測試架構都是效率極其低下的，維護成本是極其高昂的。
......
查看全文請點擊下載： http://www.51testing.com/html/98/n-1298298.html
本文收錄於《51測試天地》電子雜誌第三十六期。
著作權聲明：本文出自51Testing軟體測試網電子雜誌——《51測試天地》第三十六期。51Testing軟體測試網及相關內容提供者擁有51testing.com內容的全部著作權，未經明確的書面許可，任何人或單位不得對本網站內容複寫、轉載或進行鏡像，否則將追究法律責任。
