自動化測試用例設計的原則

很多公司在實施自動化測試的過程中，往往會把所有的手工測試用例作為自動化測試用例，並且直接進行腳本的開發工作，甚至有些公司不寫自動化測試用例，直接想當然地開發測試腳本，這些都是極其不規範的做法，甚至很有可能是導致最後自動化測試項目失敗的最大原因。那麽問題就來了，為什麽不能使用手工測試用例完全替代自動化測試用例呢？有以下幾點原因，同時也是自動化測試用例的設計原則

　● 原則1：自動化測試用例的範圍往往是核心業務流程或者重復執行率較高的。

　　在選取自動化測試用例範圍時，很多測試工程師或者上級領導可能心裏會過分依賴自動化測試，會認為自動化測試就應該覆蓋所有的手工測試用例，自動化測試的覆蓋率就應該達到百分之百。其實恰好相反，這樣的想法往往會導致自動化測試最終失敗。在一些大型項目中，往往測試用例的數量會很龐大，而且如果遇到一些繁雜的被測程序（特別是C/S架構），腳本開發工作往往會相當耗時間，並且很多測試用例甚至根本就不能通過自動化來實現。舉些例子，現在很多公司自動化測試都是剛起步，對自動化測試的了解程度只是停留在字面上，在公司對測試也不是非常重視的情況下，當然不太願意去花精力招一個具有自動化測試開發經驗的工程師，很多還是停留在使用工具的錄制回放功能來完成自動化測試。正是存在這樣的技術限制情況下，往往在實施中，會出現很多錄制回放不能解決的問題，測試工具完全無法識別測試對象，無法識別一些特殊的加密測試控件。還有，如果項目的變更頻率，測試用例數量大的話，增加了後期的維護工作量等，都是造成最終失敗的一些隱患。投入越大，損失越大。因此，往往我們會選取最核心的一些業務路徑或者是重復執行率較高的一些手工測試用例進行自動化測試，這樣能夠充分發揮出自動化測試的優勢。

　　● 原則2：自動化測試用例的選擇一般以“正向”為主。

　　手工測試用例分正常情況和異常情況，在設計的時候，可能往往會去設計很多異常情況來驗證程序是否有Bug，並且一個正常情況的測試用例往往會對應幾十個非正常情況的測試用例，而每種異常情況的測試用例都會有各種各樣的預期結果。在自動化測試中，很多人喜歡將正常情況稱為“正向”；反之，異常情況則稱為“反向”。下面，我們試想以下，如果將這些異常情況全部轉化、反應到自動化測試腳本中，那肯定需要非常繁瑣的判斷才能做到。這個對於自動化測試工程師來說，其現有的工作量還是今後的腳本維護量都是不可小視的。對於整個自動化測試項目來說，如果每個異常情況都要寫進腳本中，那真的是花了大價錢買一堆小東西，小東西真正能發揮大作用的畢竟很少。因此，真正在自動化測試項目實施中，往往會舍棄反向用例，個別比較重要的除外。使每個東西都能發揮其最大的作用才是企業最想看到的。功能自動化測試主要還是用於回歸測試，回歸測試的目的就是保證新增功能後老功能是否能夠正常繼續運作。而自動化測試則是讓測試人員從繁瑣又枯燥的重復手工測試中解放出來，這就是目的和目標。

　　原則3：不是所有手工測試用例都可以使用自動化測試來實現的。

　　這裏糾正許多測試從業人員的一個錯誤觀念，剛接觸測試自動化的普遍都會認為手工測試用例全部要轉化為自動化測試用例，但是在真正實施的時候，卻發現很多測試用例是自動化無法實現的，或者有些測試用例根本就沒有必要去自動化的。例如，有些用例會牽涉到硬件設備輔助的，最簡單的例子就是用例執行過程中需要使用刷卡機才能獲取卡號信息（如果有技術能力，當然不排除自行開發接口供測試工具調用，但畢竟能有技術實力做到這一步的不多，能有這樣的重視程度的更不多）；再比如，有些測試用例是需要與合作機構進行互動聯調，聯調時是需要和對方實時溝通，以及根據具體情況給予響應的，這些情況多數還是只能使用手工人為地來完成。當然，決定是否轉化為自動化測試，必須事先有一個規範文檔來定義哪些是需要轉化為自動化測試哪些是不需要的，否則測試工程師就會不知所措，沒有一個標準。一旦有了這個標準，自動化測試工程師就可以嚴格按照文檔裏的流程去完成需要轉化部分的自動化測試用例的腳本開發工作了。

　　原則4：手工測試用例可以不用回歸原點，而自動化用例往往是必須的。

　　很多有經驗的自動化測試從業人員一定有這樣的經歷，很多時候腳本寫完後，第一次執行沒有任何問題，而第二次執行時立刻就會報錯，原因就是沒有回歸原點。所謂回歸原點就是執行的測試用例最終需要恢復其在執行前的初始狀態，如果沒有回歸原點，就會把此腳本稱之為死腳本。舉個最簡單的例子，比如添加用戶功能，我們都知道每個用戶名都是唯一的，當寫完一個添加用戶的腳本之後，執行第一次沒有問題，因為執行前此用戶還不存在，但是當執行第二次時，程序就會出現用戶重復而報錯，此時這個添加用戶的腳本就失去了它的價值，在這種情況下，我們就需要在自動化測試用例的最後加上刪除這個用戶的步驟，這樣在下次執行用例時就不會出現用戶重復的情況了。當然，除了回歸原點，還可以使用另一種方式進行，那就是初始化數據，比如ATM機取款，假設需要執行取款100元的操作，而銀行卡余額是120元，當測試腳本第一次執行時可能沒有任何問題，但是第二次系統就會報余額不足，這樣就成為了死腳本，解決方案有兩種：一種是直接進行初始化數據，每次執行用例之前都重置下余額（只需大於100即可）；第二種方法可以在用例執行前，先查詢下余額是否大於100，若大於等於則繼續，若小於則做一筆充值100的操作，這樣即可解決。兩種方式可以看具體情況使用，數據初始化方便，但有時候初始化之後可能會影響到其他自動化測試用例的執行，而第二種方式相對在腳本上需要稍微花點功夫。究竟使用哪種方式還需要具體情況具體分析。總之，在執行自動化測試用例之前做好數據準備，這也是自動化測試的關鍵步驟。

　　原則5：自動化測試用例和手工測試用例不同，不需要每個步驟都寫預期結果。

　　在手工測試用例的設計過程中，幾乎每一個測試步驟都有一個預期結果。但是，在自動化測試用例的設計中並不采用，在自動化測試用例中，只有準備在測試腳本中設置成檢查點的步驟才有預期結果，其他所有的步驟只將它看作一個步驟，這樣做的好處是一目了然、目的明顯、層次分明，以後寫測試腳本直接跟著自動化測試用例就行了。因為經過前面的探討應該已經知道，自動化測試中並不是所有的東西都需要驗證的。所以，作者在前面的章節中也提到過，基本上手工測試用例多多少少都要進行一些轉換的，就是因為它們之間的格式是不一致的。舉一個簡單的例子，假設需要設計一個註冊頁面的自動化測試用例，有10幾個表單需要填寫，在手工測試用例中，每個表單的填寫都一定會有預期結果，因為它的確在檢查每一項是對了還是錯了，只是用的是你的眼睛在檢查而已，所以速度非常的快，甚至你自己潛意識都忽略了其實你已經檢查了。但是，在自動化測試中，我們知道如果你要檢查，那一定需要寫代碼，如果每項都檢查，那代碼量有多大是可想而知的，不是說做不到，只是這樣做根本不符合自動化測試的特點。所以，絕大部分時候，這些在自動化測試中可有可無的檢查，我們全部“不檢查”，只當做一個業務流程和步驟，是不需要設立預期結果的。

自動化測試用例設計的原則