如何進行測試自動化的成本估算

　　如何選擇合適的測試用例實現自動化?

　　對于自動化測試團隊而言，容易犯的一個典型的錯誤是：沒有選擇恰當的測試用例來實現自動化。

　　大部分測試自動化項目失敗的原因主要歸咎于被測試應用程序的快速變化、不恰當的測試用例、不可靠的框架、腳本編程的問題。分析這些問題的根源，我們可以看到，自動化測試必須分階段逐步開展，而不能局限在某個階段完成自動化測試。因此，建議自動化測試從選擇那些重要的、合適的測試用例開始，然后慢慢地擴展到其他方面。這樣會帶來較低的維護成本，但是實現更重要的業務價值。

　　那么如何選擇合適的測試用例呢?

　　通常需要結合測試用例的復雜度的評估來考慮選擇的測試用例以及個數。首先把測試用例按一定的原則分為簡單、中等、復雜3大類。然后從這3大類的測試用例中按一定的比例來抽取需要實現自動化的用例。

　　測試用例的復雜度分組可以通過綜合分析測試用例包含的測試步驟(操作步驟)，以及測試用例所包含的檢查點個數來判定，例如可參考下表來分類：

　　表中規定：

　　1、如果測試用例中包含的測試步驟個數小于5，檢查點個數也小于5，則判定為簡單類型的測試用例，對于這類測試用例，可多選擇一些用于實現自動化。

　　2、如果測試用例中包含的測試步驟在5到15個之間，檢查點個數在5到10個之間，則判定為中等復雜類型的測試用例，對于這類測試用例，可略選擇少一些用于實現自動化。

　　3、如果測試用例中包含的測試步驟在15到25個之間，檢查點個數在10到15個之間，則判定為復雜類型的測試用例，對于這類測試用例，可再略為選擇少一些用于實現自動化。

　　至于選擇的比例，則可參考一些項目的經驗數值，或者根據項目實際情況自己調整。這種通過測試用例復雜度分組選擇的方式來篩選出自動化測試用例比較簡單易行，而又不失科學性。因為眾所周知，自動化測試腳本的實現難度，在很大程度上取決于測試用例的復雜度，而測試用例的復雜度又在很大程度上取決于測試步驟和檢查點的復雜度。

　　在自動化測試的測試用例范圍內，找出每個測試用例的操作數量和驗證點的數量，然后畫出一個圖表來找出平均值，并且定出控制點，這樣可以基于被測試應用程序的實際情況而不是僅僅根據行業標準來判斷復雜度。

　　例如下表顯示了25個測試用例中每個用例所包含的測試步驟：

　　根據這個表，可以畫出圖1所示的復雜度與測試步驟個數的關系圖：

　　圖1 復雜度與測試步驟個數的關系圖

　　然后，我們可以基于這個圖計算出平均的測試步驟個數是16個，那么以此為基準點，再定出上、下限分別是8和25，則可以這樣定義測試用例的復雜度：

　　簡單 ： ≤ 7 個步驟

　　中等 ： ≥ 8 個步驟 -- ≤ 16 個步驟

　　復雜 ： ≥ 17 個步驟 -- ≤ 25 個步驟

　　類似的，我們可以再加入檢查點的個數，按類似的方法進行計算。

　　影響測試自動化工作量評估的因素

　　但是，前面所講到依據測試步驟和檢查點個數來判斷測試用例復雜度的方法還是有不少的缺陷，個數僅僅是一種參考，還需要綜合考慮其他的方面，例如

　　1、需要注意每個腳本開發前的工作量也要納入計算：

　　(1) 通過手工測試確認操作的正確性。

　　(2) 測試數據的選擇和生成。

　　(3) 腳本模板的創建，例如頭信息、步驟注釋、抽取公用的腳本函數等。

　　當然，這些方面的工作量也很大程度上取決于測試用例的測試步驟個數。

　　2、另外功能的重復性也是判斷復雜度和工作量的因素之一。如果測試用例的步驟比較復雜，但是與其他測試用例比較類似，具有功能上的重復性，則也可以標志為“中等”或“低”的復雜度。

　　3、如果測試用例的測試步驟超過了上限控制點(例如25)，那么那些額外的超出上限的步驟可以考慮放到另外一個測試用例中。例如，上面的例子中，編號為06的測試用例包含30個步驟，則可標識為“1個復雜的用例 + 1個簡單的用例”

　　4、需要考慮那些被標識為“復雜”而不是“中等”的測試用例是否應該被自動化實現，因為實現過多的復雜的測試用例會給自動化測試帶來沉重的負擔。

　　下表按其影響程度從高到低列出了8個影響自動化測試實現的方面，這些方面也是自動化測試工作量評估中不可忽視的因素：

　　其中可以看到，測試框架對于自動化測試的影響程度是最大的，一個好的測試框架可以讓腳本編寫、調試和維護變得更加簡單。在自動化測試項目開展的前期搭建一個穩健的好用的測試框架，可以讓后面的腳本開發事半功倍。

　　另外，不可忽視的一點是測試工具以及自動化測試工程師的個人技能，這些都會對自動化測試項目能否成功實現有著重大的影響。

　　在被測試的應用程序中，如果包含了大量的自定義控件、第三方控件，則自動化測試工程師需要付出更多的努力來“對付”這些問題，這是因為大部分的測試工具在這些方面都僅僅提供非常有限的支持。

　　測試框架設計與工作量評估

　　針對某個測試工具的測試框架而言，商業的和開源的都有很多，例如QTestWare、SAFFRON、EMOS等。當然也可以自己構建自動化測試框架。這些框架可以節省很多腳本編寫、調試和維護等方面的工作量。但是需要注意根據被測試應用程序來進行修改和個性化改造。

　　框架的一般特點是：

　　1、在項目中是可移植、可擴展、可重用的。

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