上一回，說了關於軟件測試，這次來聊一下我的自動化。
我接觸自動化是在2010年，在畢業前夕，我就知道了自動化，但是，當時也只是知道而已，沒有使用過，更沒有在項目中投入使用過。畢業後，來到了上海，進入了第一家公司。進入了一個項目組，組內的測試人員很少，加上我才只有2個人。作爲新人，便是從做手工黑盒的測試開始的。那時，開發出來的產品也比較簡單，經過了幾個月後，測試組的規模也慢慢的增大了，產品的功能也越來越強大，測試也變的越來越複雜，再加上有些客戶反映，在長時間使用這個軟件或是增加了大量的點的情況下，軟件會出現一些稀奇古怪的問題時，領導決定需要增加自動化的測試，於是，我就稀裏糊塗的開始了我的自動化測試之路。
【入】
剛開始的時候，真是什麼都不會，好不容易下載好了軟件，學會了錄製，便開始錄製腳本、回放。使用了幾天後，驚奇的發現居然還有Expert View這個編輯模式，瞬間感覺操作起來方便了好多，也更加自由的控制腳本了。由於小時候Basic玩的還不錯，再加上後來學VB也學的很好，所以上手還是比較快的，一下子就學會了基本的操作。也買了一本書，學了不少的小技巧。一邊學習，一邊直接在項目中使用測試。學的真的很快，進步也很快。所以，總結出來，這些工具，只有加入到項目中去，學習才能更快，也更有目的性。
其實QTP上手還是蠻快的，倒騰了幾次，基本在使用中，藉助的書本、網絡、論壇等一些資源，在項目中指定的功能上做自動化已經沒有什麼太大的障礙了。但是，僅僅的一些簡單的錄製、修改、回放已經滿足不了我的興趣，將這個工具發揮的更強大成了我的興趣。
【鑽】
於是萌生了一個想法，可不可以將腳本做成全自動化的測試呢？我想讓它測試什麼模塊，設置一下，然後執行它，最後只要看一下它的打印結果，就可以知道測試的結果，這樣是多麼美好啊。（當然，後來發現這樣的想法是可笑的。）
我簡單的想了一下，做了下設計：
l 根據功能模塊劃分，一個模塊的測試腳本全都寫入一個Action中。
l 然後在外面用一個大的Action包裹起來。
l 腳本包含軟件所有的測試點。
於是便開始錄製腳本、修改，最後發現了一個致命的錯誤，測試數據的處理，然後不得不再加上一條“測試數據加入Data Table中進行參數化”，當完成了2-3個模塊後，我將腳本運用到測試中，感覺很痛苦，也遇到了不少問題，總結一下：
1. 腳本很大，碎文件也很多，每次複製粘貼就要不少時間。
2. 管理Data Table要好半天，而且哪幾條運行，哪幾條不要運行，都是通過設置DataTable Iterations來控制，很不方便。
3. 感覺很多東西都是重複的，沒怎麼重用。
4. 由於模塊多，內容多，對象庫中的對象也越來越多，管理對象庫變的格外痛苦，有些一樣的部分都已經XXXXX_8、XXXXX_9了，而且有時候，腳本中的一句語句對應的控件在對象庫中找了好半天才找到。
5. 幾乎沒有用到需要用自動化同時測試兩個模塊的情況。那個包含所有測試點的設計，完全沒有必要。
這一次算是失敗的。
於是，重新設計了一下腳本部分，開始再一次的嘗試。
感覺有點鑽牛角尖的意思了。
【歧】
這次的腳本的大概幾個部分：
l 測試腳本都寫在一個Action中，一個模塊一個腳本。
l 測試的數據通過新建一個Excel文檔提供，不使用Data Table，一行一個數據，腳本判斷該行的執行列爲1，則執行這個測試用例。
l 還有一個Excel文檔，專門是用來控制腳本的配置和運行，如：“運行類型選項，是按次數運行，還是到了某個時間點就停止，還是不停運行”、“是否觸發某個動作，還是隻是新建”等等這樣的配置項。
l 再加上一個txt文檔，來記錄運行時，我需要記錄的log。
l 最後腳本編寫好後，儘量不動腳本，需要調的，只是那些Excel文檔。
於是，我便在工作空閒的時候，更加投入到所謂的“完美自動化”編寫中。經過一段時間的編寫，也有所成果，經過調整Excel，能夠執行多種不一樣的測試，很有成就感，便更加努力編寫。
但是在工作中，問題還是來了：
1. 我發現當新的產品更新了，我的腳本就報廢了，如果要對新的產品進行自動化，就要花費不少時間對腳本中的代碼進行更新，對數據庫中的對象進行更新。
2. 後來發現，產品會經常根據客戶的要求做定製，悲劇啊~不得已，將一些對象的名稱，軟件標題等一些東西也進行了參數化。
3. 還發現如果有個什麼特定數據下的測試任務，有的則是特定的組合操作，發現我的腳本根本不會做到那麼細緻，也不可能做到那麼細緻。當遇到這樣的情況時，是重新寫一個新的臨時的腳本作爲測試用的腳本呢？還是增加腳本的配置項，是個很頭疼的選擇問題。如果選擇新建臨時的，又需要寫腳本的時間，而且我之前寫的腳本的作用就更小了。如果改原來的，發現也是需要花一定時間來編輯腳本。怎麼着都得不償失。
4. 腳本複雜後，還很容易出錯，有的時候還會出現一些稀奇古怪的錯誤，一旦出錯，就很難進行修改。
5. 如果有一個函數需要改動（如登錄函數），因爲每個腳本都使用了這個函數，所以需要打開每一個腳本進行修改，太麻煩了。
6. 我一直想着，只要這個“完美自動化”出現，那以後版本更新後，跑一下它，所有功能點都測過一遍了，可現實發現，更新後，腳本就幾乎癱瘓了，和我心中的那個“完美”，似乎差的有點太遠了。
改的時候，有時候會想，還不如重新做呢，但看着那3000+行的代碼，又十分的不捨得啊。就這樣，像是走火入魔一般，想着我的“完美自動化”，腳本功能寫的越來越細，維護難度也越來越大。
歧途啊~
【毀】
也許真的是天意，老天都看不下去了，一天，我正在做測着測試工作，突然間，操作系統就報錯崩潰了，同時聽到了硬盤讀盤卡盤一樣的噪音。重啓電腦，發現再也讀不了我那硬盤了。經過了好幾個小時的嘗試，無奈以失敗告終。於是，我自己收集整理的第一批學習資料，和我的那個“完美自動化”一起，消失的一乾二淨。
【新】
經過了這一次教訓，我知道了，以後寫腳本，一定要多保存幾個地方，這樣一臺電腦報銷了，也不用擔心。
同時，我也總結了一下關於我的“完美測試腳本”，發現問題太多，完全就是，背離了自動化測試本來的意義，完全是在向一條大錯特錯的道路上在狂奔着。自動化測試，本來就是用來解放人力，將一些繁重，繁瑣的工作交給腳本自己來完成，節約時間纔是關鍵，而我一直在做的是，花五個小時開發腳本，然後運行5分鐘來測試一個手工20分鐘的測試內容。
於是，我決定重新再學習一次軟件測試的基礎知識，這次的學習，之前一些沒有看懂的知識一下子就理解了，對自動化測試也有了更新的理解。
隨後，我重新寫了測試腳本，這次的腳本便的簡單多了，除了沿用了上次版本對於數據和控制寫入Excel中這點，對需要寫腳本的功能點也進行了篩選，選擇了主要的功能點進行腳本的編寫，不再對那些細小，冷僻的功能進行腳本的編寫。腳本主要做的功能也不再是追求“完美”，而是隻做迴歸測試和長拷。反覆重用的函數寫在外部VBS文件中，用Function Library進行加載使用，減少了反覆複製粘貼的麻煩。代碼也更加直接和簡潔。似乎稀奇古怪的報錯和卡殼也少了。
之後使用中，又發現瞭如腳本拷到別的電腦上時無法使用，本地地址和相對地址的問題，更新了幾次腳本。
隨後做了一段時間的性能測試（這個這裏不講了，隨後再寫一篇細說）和對該腳本的維護。
在2012年過完年由於一些原因就跳槽了。
【建】
跳槽到了一家外包公司，以前我一直不喜歡外包公司，因爲網上總是流傳着各色各樣外包公司坑人啊、無限制加班還沒錢啊、沒有五險一金啊什麼的負面消息。不過最後我進了一家還算比較滿意的公司，主要是，1.項目我比較感興趣，2.他們想要建QTP自動化，但是沒有人會，目前還沒建，3.公司有五險一金，4.離家進，5.有午飯吃，6.不用加班，7.工資還行，畢竟年紀還輕，畢業也沒多久，就算面試的時候這也能答，那也能說，但是一些公司總是和你說你的工作經驗多少多少，公司只能給你多少多少以下，這點讓我十分的不爽。不過這家公司到也爽快，可能真的是急需人吧。經過了電話面試、面試、客戶面試、人事後，算是進入了。
測試基礎自認爲學的比較紮實，所以1周後便開始做任務，並提前結束了試用期。
有一個任務是客戶想給他們的一個業務流程管理網站BPM建自動化測試，由於表單數量龐大，且每張表單的流程複雜，當一個版本更新後，靠手工進行每張表單的每個流程測試是不可能的，所以需要自動化來進行迴歸，減少人力。
有了上家公司的經驗，這次在正式寫腳本前，做了下功課：
l 確認項目的週期，版本更新的頻率。
l 確認了一般只改後臺代碼，不動前臺頁面。
l 確認了是否有控件不能識別
然後我纔開始腳本的編寫，基本還是和之前做的差不多，不過這次很詳細的劃分好了那個VBS文件寫哪部分的函數，也參考了一些網上的關於框架的設計，我也參考着自己寫了一個“專用框架”。QTP操作一層；對於系統的操作一層；對能複用的地方進行了大量的複用；也是先了籤核流程讓腳本自己判斷並選擇方案完成；有了詳細的html版本的LOG，並截圖和文字記錄並茂，。最後，把這些vbs文件都加載進腳本。寫腳本只需寫一個新建表單，之後的事，就交給了這個“專用框架”完成。籤核的事，基本不用再編寫腳本，大大提高了腳本的編寫速度，而且使用下來，感覺也挺穩定，一直用到了現在。
我個人的總結就是：
l 一定要了解自動化是做什麼的。
l 在軟件測試理論知識還不是很牢固的情況下，不要進行自動化。
l 在軟件版本還沒有穩定的情況下，不要進行自動化。
l 系統中測試對象基本可以正常識別的情況下才進行自動化腳本的編寫。
l 自動化測試一般情況下是用來證明軟件能正常運行，而不是用在證明軟件這麼操作一定會出錯上。
l 注意腳本的銜接，和數據迴歸，有時候，同一個數據只能用一次。
l 領導不支持的情況下，就算能做，也不要輕易進行自動化。
l 領導完全不明白什麼是自動化的情況下，進行自動化要慎重啊~
l 自動化測試最主要的是提高工作效率，正確的使用是，用1天開發一個腳本能用3個月的測試，而不是花3個月開發出一個很牛的腳本來測試1天。
這些就是我目前的一些想法和觀點，無關對錯。也許一年後，我又會有更新、更加深入的瞭解。到時候，我會再寫一篇，來反駁我現在的這篇的。
希望我寫的這篇文章，對想做自動化的，正在做自動化的同學有幫助~
51testing空間同步更新：http://www.51testing.com/?307440
歡迎志同道合之人一同學習。
QQ：370464196
Email：[email protected]
陳永達
