很感激我的mentor，在剛進公司的前兩周，沒有馬上讓我接手自動化測試，使我有足夠的時間熟悉系統的基本功能，就這么一個緩沖，了解了系統的基本功能，也研究了一個基本的自動化測試架構的組成，對測試系統、對自動化測試自己有了感覺。熟悉測試系統，這是軟件自動化測試的第一步。
我的一些剛來的新同事或實習生，總是迫不及待地想學習自動化測試或者是想通過自動測試腳本學習業務，我總會告訴他們，熟悉業務是自動測試的基礎，不要小看手工測試過大夸大自動化測試。如果一個系統你都沒有親自手工測試過，又怎會做好自動化測試呢？
用什么工具，我沒有選擇，因為項目組在我來之前就已經決定了。關于工具的選擇，我看重的首先是它是否能夠滿足項目的需要，是否容易擴展，可以滿足系統任何功能的測試自動化；其次是它是否易用，能否容易上手；當然最重要的是它的穩定性，是否不需要人工干預就能穩定地批量運行所有的自動化測試腳本。這三點，項目組所選擇的工具都滿足了，我自然樂于接受。選擇合適的測試工具，是軟件測試自動化的第二步。
開始做自動化測試，是從系統的基本功能開始，目標是每次出built都需要花半小時以上的手工smoke test cases測試自動化。在我接手前，已經有同事做了頁面相關的功能測試，看了一些以前的腳本，只是簡單的錄制、回放，因為沒有整理過，也就沒有業務邏輯和注釋，花了很大的精力才弄清一個腳本的步驟和功能。而且，這些腳本中，關鍵字的參數化做得不好，每次運行都需要手工修改，需要手工來干預的腳本，只能算是半自動化。最嚴重的問題是，同樣的功能，同樣的腳本，會被重復地拷貝，當這個功能或業務流程被改變的時候，所有相關的腳本都需要修改，那將會是很大的維護代價。思考了一天，我決定放棄原有的所有腳本，重新設計系統的架構。放棄原有的兩百多個腳本，有些可惜，但如果按照原來的思路走下去，我將會付出更大的維護代價。有舍才會有得。
問題我看到了，知道要改，但至于怎樣改，心里并沒有把握，我知道自己需要時間去研究。我將用于smoke test的系統最基本的功能挑出來，作為設計的研究對象。Web測試自動化，無非就是錄制、整理和回放，錄制和回放都是簡單的事情，關鍵是整理，好的腳本，應該容易擴展、維護和使用。這十幾個腳本，我花了很多心思，不斷地思考、不斷地改進、不斷地與我的同事討論。慢慢地，自己的思路清稀了起來，做出了自己想要的架構。首先是容易擴展，能夠滿足現在的功能需求，也能滿足以后需要測試的功能的需求。第二，容易維護，當業務流程、接口或頁面變動的時候，只需要做一些簡單的修改就可以實現。第三，可讀性強，別人能夠容易讀懂和接手維護。第四，容易使用，項目組的其他人想要使用的時候能夠簡單地搭建和運行。第五，有統一的編碼規范、存儲規范和編寫風格。最后，是最重要的一點，是腳本具有很高的可信性以及自動運行的穩定性。
我像繡花一樣一點一點地將這個自動測試架構繡了出來，比別人多花了N倍的心思和時間，晚上從公司走出來，傻傻的望著夜空數星星，雖然累很仍然很快樂。
從系統的基本功能入手，設計自動測試架構，這是軟件測試的關鍵一步。架構的好與壞很重要，它影響到系統的擴展、維護和使用，如果想要系統容易擴展和維護，一定要多花心思在設計上。很多同行問我使用什么測試工具，我會告訴他們，用什么測試工具其實并不那么重要，不同的人使用同樣的測試工具，會做出效果完全不一樣的東西，那是因為他們的架構不同，設計比工具重要得多。
架構出來之后，就是系統功能的自動化腳本編寫，因為項目的原因，當時的自動測試團隊已經解散，我面臨的是只有一個人的自動測試團隊，怎樣將上千個測試案例自動化，成了我頭疼的問題。至今仍然很感激我的老板和項目經理，調配給我足夠的資源，真正的打開了項目的軟件測試自動化之門。團隊中的其它成員，都是沒有自動化測試經驗的同事，給他們足夠的培訓和技術支持很關鍵。他們所負責的功能，我都會寫一個例子，他們可以參照例子按照我們自動測試架構編寫規范寫腳本，遇到技術問題或業務問題，我會協助解決，在整體的架構上，我會全局把握。那一段時間，特別忙，架構的擴展、業務的熟悉、問題的跟蹤解決，有時候同時有好幾個問題在等著我解決，但就是這么一段忙碌的日子，從對系統基本業務的理解到系統業務的全面理解，從原來的只有十幾個測試案例的自動化測試腳本到上千個自動化測試腳本的實現。很感激我的這些同事，現在他們大部分都回到了他們原來的角色，我也將要開始擔任新的角色，但那一段一起工作的日子，我會記在心里。也是因為大家一起的努力，老板原要求實現web頁面自動測試或系統30%功能的自動化測試，我們最終實現的是幾乎所有接口所有檢查點的自動化測試，接近80%的測試覆蓋率。
自動化腳本的編寫，當然要注意全局的把握和review，不同的人會有不同的風格，稍不注意就會問題多多。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
