序言：自動化測試中，自動化
測試用例是一個重點中的重點，個人以為，到底如何去定位自動化測試
用例設計的 形式和發展是決定自動化測試成敗的關鍵，根據一些研究和看法，我寫了一個自動化測試用例設計的一個大概情況，當然一家之言而言，當然，大家在測試過程中， 接觸過自動化測試的，肯定就接觸過自動化測試用例，其是
自動化測試腳本本身也是一種自動化測試用例，看看以下的情況大家遇到過么，希望大家有什么想法，提 出來吧。
一、自動化測試用例應用
手工測試用例是針對手工測試人員，自動化測試用 例是針對自動化測試框架，前者是手工測試用例人員應用手工方式進行用例解析，后者是應用腳本技術進行用例解析，兩者最大的各自特點在于，前者具有較好的異 常處理能力，而且能夠基于測試用例，制造各種不同的邏輯判斷，而且人工測試步步跟蹤，能夠細致的定位問題。而后者是完全按照測試用例的方式測試，而且異常 處理能力不強，往往一個自動化測試用例運行完畢后，報一堆錯誤，對于測試人員來定位錯誤是一個難點，這樣往往發現的問題很少。所以，根據其各自的特點，需 要將兩者有很好的定位：手工測試是在軟件版本前幾輪測試的重點，目的是驗證功能，發現問題；自動化測試是應用在后幾輪版本，保證軟件版本模塊修改或者添加 新功能后，沒有影響開始的功能模塊（因為軟件中，各模塊之間的接口以及類、函數方法等的互相引用，也是容易出問題的地方）。
二、自動化測試用例設計發展
1、自動化測試用例設計發展前期
記得，當時的自動化測試開展是針對測試設備設計一套測試環境系統，用于自動化例行測試，根據此，專門撰寫了一套自動化測試用例，并轉化成自動化測試腳本。之后整套系統都失敗了，失敗原因包括：
a、系統太過于龐大，測試用例也過于繁瑣，每次測試運行下來，測試結果都夾雜著一大堆各種錯誤，有可能是產品問題，有可能是腳本問題，也有可能是用例問 題，這樣下來，測試人員每次運行一遍都要面對大量的問題，維護的幾次就放棄了，問題越來越多，根本沒辦法去定位，這樣反而浪費了大量的成本和時間。
b、搭建的一套測試環境系統，各個產品功能模塊都互相聯系在一起，都互相有影響，容易造成問題。
c、更重要的是，由于是單獨搭建的一套測試環境系統，其自動化測試用例與手工測試用例沒有太大關系，這樣就造成了其自動化測試很難對手工測試進行輔助。
2、自動化測試用例設計發展前中期
這時，自動化測試用例來源于手工測試用例，首先，自動化測試根據手工測試用例進行轉換而來（舉個例子：CLI測試時，自動化測試用例是根據手工測試用例 的步驟，將其需要輸入的CLI命令和回顯進行填寫），之后，自動化測試腳本人員根據其自動化測試翻譯為腳本。這樣做的好處就是手工測試用例與自動化測試用 例的結合，保證了自動化測試的明確性，后期的改進還包括
a、將自動化測試用例根據手工測試用例進行了分層，把一些共性功能和全局變量抽象到了更上一層，保證復用性和降低維護性。
b、設計的自動化測試框架的管理。
經過一段時間之后，問題還是很大，主要問題在于
1）前期為了追求自動化測試覆蓋率，往往忽視了自動化測試用例的質量，大家想想，出產一個自動化測試項目，得經過手工測試用例—自動化測試用例—自動化 測試腳本三個階段，而自動化測試用例是手工測試人員來撰寫，因為其懂業務；自動化測試腳本是由專門的自動化測試人員撰寫，但是這導致了一個項目出產的周期 長（需要經過兩個階段，而且還要反復調試），而且由于經過了兩個階段，所以伴隨問題也多了，特別是接口這方面，往往由于兩者的溝通和認知問題，使得自動化 測試項目的發布后還隱藏大量問題，往往使測試人員疲于調試和維護。
2）雖
然是按照手工測試用例設計出來的，但是由于手工測試用例開始沒有考慮到自動化測試者一塊，因此手工測試用例的每個測試模塊往往測試步驟很 長，而且測試前后不能保證測試環境的恢復，所以也造成了后期一個自動化測試項目的問題以及出產成本。（這里建議最好自動化測試用例的每個功能模塊的步驟不 長，而且每個模塊之間不要有聯系，這樣是要從手工測試入手的）
3、自動化測試用例設計發展中期
在這個過程中，最好的是測試人員能夠根據自動化測試框架與平臺來自行進行測試腳本的設計，往往在前幾輪的測試中，手工測試人員就能在手工測試的同時將自動化測試腳本設計了出來
a、錄制就是這樣一種思想，測試人員在測試過程中，本身就是在測試過程中，將測試人員的測試過程進行了記錄，所以，我的想法一直是，錄制的方向是沒錯的。
b、而針對CLI測試，也可以制作了這么一個錄制工具，就是模擬制作一個超級終端，測試人員應用其進行手工測試，其工具自動記錄其命令行操作， 而且手工測試人員能進行回顯的需要匹配的某一個字段進行選擇，然后在后臺根據模板，自動生成一個自動化腳本，之后測試人員自行進行維護即可，這樣可以縮減 環節，降低出錯幾率和維護問題。
c、當然，要做到這一步，一個強大的自動化測試框架和平臺是其支撐，我曾經做過一個基于GUI的自動化測試框架，部門里面也動員過一次試用，每 個產品線都出了一兩個人進行腳本開發，測試人員往往對腳本開發沒什么太大興致，更多的是一種好奇，而且調試工作大多是我做的，整整10多個產品線，調試了 我大部分時間，因此其難點本身不是在于腳本的開發，因為當時測試人員開發出這些腳本是很快的事情，其真正難點在其測試人員的調試和維護方面，而且測試人員 往往疲于去進行這方面，他們在乎的是測試和業務本身，要協調這方面的沖突是一件很難的事情，需要不斷思考和總結吧。
4、自動化測試用例設計發展中后期
留一個中后期，現在的自動化測試用例設計發展還是很淺，還需要一個長遠的發展過程，中后期發展成什么形式，因為見識有限，所以請大家積極猜想啦。希望能給我帶來一些見識和想法。
三、一些感想
下面感想僅我個人之言：自動化測試就本身而言，其實技術方面的前瞻性是需要的，但是自動化測試確實是一個長期的過程，對自動化測試的定位很重 要，然后是一系列的細節問題，每一個問題都是需要值得重視的問題；定位、細節、技術真的都是缺一不可啊，而且還要把握這么一個平衡，想到自己以前注重需 求，后到注重技術，后又因為技術懷疑需求，最后又回歸到認識需求，短短時間，總有變化，現在想想，三者，技術是基礎，需要不斷學習，但卻不能看的太遠而忽 略了現在的最重要的需求，在實現現在需求的同時，不斷步步跟進，進行探索。自動化測試還真是一個“步步驚心”的過程啊。
版權聲明：本文出自 散步的SUN 的51Testing軟件測試博客：http://www.51testing.com/?382641