專案的自動化測試有了乙個比較理想的結果，易於擴充套件、維護和使用的測試架構，接近
80%的覆蓋率，專案組積極的反饋結果，半年的努力沒有白費。回想起剛到公司時接下這個重任，自己並沒有把握，甚至有些心虛，畢竟自動測試並不是我所擅長的，而且，陌生的測試工具、龐大而複雜的測試系統，對我來說都是一種挑戰。心裡沒有把握自然不能跟老闆說，打**給乙個在這方面經驗很豐富的朋友，他告訴我
「要自信，要靠自己
」，於是，摒棄了所有的雜念和依賴，一頭紮進了自己
底氣不足
的自動化測試。
很感激我的
mentor
，在剛進公司的前兩周，沒有馬上讓我接手自動化測試，使我有足夠的時間熟悉系統的基本功能，就這麼乙個緩衝，了解了系統的基本功能，也研究了乙個基本的自動化測試架構的組成，對測試系統、對自動化測試自己有了感覺。熟悉測試系統，這是軟體自動化測試的第一步。
我的一些剛來的新同事或實習生，總是迫不及待地想學習自動化測試或者是想通過自動測試指令碼學習業務，我總會告訴他們，熟悉業務是自動測試的基礎，不要小看手工測試過大誇大自動化測試。如果乙個系統你都沒有親自手工測試過，又怎會做好自動化測試呢？
用什麼工具，我沒有選擇，因為專案組在我來之前就已經決定了。關於工具的選擇，我看重的首先是它是否能夠滿足專案的需要，是否容易擴充套件，可以滿足系統任何功能的測試自動化；其次是它是否易用，能否容易上手；當然最重要的是它的穩定性，是否不需要人工干預就能穩定地批量執行所有的自動化測試指令碼。這三點，專案組所選擇的工具都滿足了，我自然樂於接受。選擇合適的測試工具，是軟體測試自動化的第二步。
開始做自動化測試，是從系統的基本功能開始，目標是每次出
built
都需要花半小時以上的手工
**oke test cases
測試自動化。在我接手前，已經有同事做了頁面相關的功能測試，看了一些以前的指令碼，只是簡單的錄製、回放，因為沒有整理過，也就沒有業務邏輯和注釋，花了很大的精力才弄清乙個指令碼的步驟和功能。而且，這些指令碼中，關鍵字的引數化做得不好，每次執行都需要手工修改，需要手工來干預的指令碼，只能算是半自動化。最嚴重的問題是，同樣的功能，同樣的指令碼，會被重複地拷貝，當這個功能或業務流程被改變的時候，所有相關的指令碼都需要修改，那將會是很大的維護代價。思考了一天，我決定放棄原有的所有指令碼，重新設計系統的架構。放棄原有的兩百多個指令碼，有些可惜，但如果按照原來的思路走下去，我將會付出更大的維護代價。有捨才會有得。
問題我看到了，知道要改，但至於怎樣改，心裡並沒有把握，我知道自己需要時間去研究。我將用於
**oke test
的系統最基本的功能挑出來，作為設計的研究物件。
web測試自動化，無非就是錄製、整理和回放，錄製和回放都是簡單的事情，關鍵是整理，好的指令碼，應該容易擴充套件、維護和使用。這十幾個指令碼，我花了很多心思，不斷地思考、不斷地改進、不斷地與我的同事討論。慢慢地，自己的思路清稀了起來，做出了自己想要的架構。首先是容易擴充套件，能夠滿足現在的功能需求，也能滿足以後需要測試的功能的需求。第二，容易維護，當業務流程、介面或頁面變動的時候，只需要做一些簡單的修改就可以實現。第三，可讀性強，別人能夠容易讀懂和接手維護。第四，容易使用，專案組的其他人想要使用的時候能夠簡單地搭建和執行。第五，有統一的編碼規範、儲存規範和編寫風格。最後，是最重要的一點，是指令碼具有很高的可信性以及自動執行的穩定性。
我像繡花一樣一點一點地將這個自動測試架構繡了出來，比別人多花了
n倍的心思和時間，晚上從公司走出來，傻傻的望著夜空數星星，雖然累很仍然很快樂。
從系統的基本功能入手，設計自動測試架構，這是軟體測試的關鍵一步。架構的好與壞很重要，它影響到系統的擴充套件、維護和使用，如果想要系統容易擴充套件和維護，一定要多花心思在設計上。很多同行問我使用什麼測試工具，我會告訴他們，用什麼測試工具其實並不那麼重要，不同的人使用同樣的測試工具，會做出效果完全不一樣的東西，那是因為他們的架構不同，設計比工具重要得多。
架構出來之後，就是系統功能的自動化指令碼編寫，因為專案的原因，當時的自動測試團隊已經解散，我面臨的是只有乙個人的自動測試團隊，怎樣將上千個測試案例自動化，成了我頭疼的問題。至今仍然很感激我的老闆和專案經理，調配給我足夠的資源，真正的開啟了專案的軟體測試自動化之門。團隊中的其它成員，都是沒有自動化測試經驗的同事，給他們足夠的培訓和技術支援很關鍵。他們所負責的功能，我都會寫乙個例子，他們可以參照例子按照我們自動測試架構編寫規範寫指令碼，遇到技術問題或業務問題，我會協助解決，在整體的架構上，我會全域性把握。那一段時間，特別忙，架構的擴充套件、業務的熟悉、問題的跟蹤解決，有時候同時有好幾個問題在等著我解決，但就是這麼一段忙碌的日子，從對系統基本業務的理解到系統業務的全面理解，從原來的只有十幾個測試案例的自動化測試指令碼到上千個自動化測試指令碼的實現。很感激我的這些同事，現在他們大部分都回到了他們原來的角色，我也將要開始擔任新的角色，但那一段一起工作的日子，我會記在心裡。也是因為大家一起的努力，老闆原要求實現
web頁面自動測試或系統
30%功能的自動化測試，我們最終實現的是幾乎所有介面所有檢查點的自動化測試，接近
80%的測試覆蓋率。
自動化指令碼的編寫，當然要注意全域性的把握和
review
，不同的人會有不同的風格，稍不注意就會問題多多。
指令碼編寫完成之後，自然是使用。指令碼在前期的使用是功能測試和資料準備，在專案穩定之後的最大價值就是回歸測試。我將指令碼分為了三個級別：基本流程測試指令碼，用於每次出新
built
安裝後做
**oke test
；關鍵功能測試指令碼，每次出新
built
後對所有重要功能進行回歸測試，確保改動不會對原有功能的造成影響；全面回歸測試指令碼，一般每週跑三次或者是系統經過比較大的修改後作回歸測試。自動測試指令碼在回歸測試中發揮了出色的作用，特別是系統在上線前夕，為了適應客戶的需求，功能不斷修改，對於原有的功能，自然不可能都手工測試，指令碼在這個時候的意義特別大。
同事或朋友經常問我，自動化測試應該在什麼時候介入？如果系統的功能需求和介面定義都很清晰，系統開發完成並且基本功能手工測試成功後，就可以開始編寫自動化測試指令碼了，一方面可以利用指令碼做功能測試和
bug驗證，另一方面也可以用來做回歸測試。但如果系統的變化比較大或介面的定義不夠清晰，最好還是先手工測試，待功能比較穩定之後再寫指令碼，因為如果功能的變化太大，維護指令碼的付出可能遠遠小於指令碼可以帶來的效益。
當然，並不是所有的系統都適合做自動測試，如果只是一些短期的專案，或者是指令碼不會被重複利用，就沒有做自動化測試的必要，成本會遠遠大於收益，也就沒有做自動化測試的必要了。反之，如果是產品的測試或長期的專案或是自動化測試指令碼會被反覆使用，自動化測試就顯得很有必要了，做完一套指令碼之後就會反覆被使用，當然可以節省很多成本，也可以提供測試的效率。
這個架構，自己付出了很多心思，付出所得到的回報找到了自動測試的感覺，底氣不足變成了胸有成竹。專案組的其它團隊也看到了自動化測試的好處並打算參考我們的架構實現自動化測試，再做設計，揚長避短、一氣呵成。
敲完這些文字，也就意味著我的自動化測試工作暫告一段落，下週開始，因為專案的需要，將會開始我的另乙個全新的角色。這個架構，絕對不是完美的，肯定還存在可以改進的空間，希望接替我自動化測試工作的同事，也能像繡花一樣用心去完善它。
Monkey 自動測試
如何使用 進入命令列，來到android sdk的platform tools目錄下，輸入命令 user user workspace android sdk linux x86 platform tools adb shell monkey 即可檢視到monkey工具的配置引數的用法。如下 在執行...
讀書 手工測試與自動測試
探索式軟體測試 當軟體測試的熱點漸漸轉向測試自動化，當越來越多的測試人員談論白盒測試 測試程式設計 測試指令碼時，測試專家james a.whittaker旗幟鮮明地捍衛手工測試 manual testing 如何用探索式測試 exploratory testing 來應對嚴峻的現實挑戰。作者以 漫...
簡單的自動測試系統
最近，在公司製作乙個自動測試系統，能夠把測試的資料傳輸到計算機上，第一款產品已經完成了，用買來的pci資料採集卡 qt5.0，設計了乙個簡單的顯示介面，算是完成了。但是，pci卡用起來太難受，想換一種方便 簡單一點的。所以想到了串列埠和區域網的形式 1 串列埠就是用微控制器將ad資料採集出來，然後傳...