如何做一個能害死人的自動化測試工具

　　你是一家大公司里不得志的程序員。和你同年進公司的那些人在核心業務上拼命工作，被客戶罵，加班，交付，開慶功會，拿獎金。而你，不知道怎么的被放到一個叫做“測試工具開發”的邊角部門里，干著一些不疼不癢不影響公司業績的工作。你恨。你要報復。你要拿回本該屬于自己的一切。

　　現在我教你怎么做。

　　首先，你要啟動一個自主開發自動化測試工具的項目。讓老板們相信自動化測試的重要性并不困難，世界上有無數的文章和書籍在講這件事，你們公司請的咨詢顧問一定也會說到這件事，這些都是你的幫手。真正難的部分是“自主開發”。你用得上一個百試百靈的招數。告訴老板們，一個自主開發的工具可以由自己來維護和支持，只有這樣才能把核心技術的命脈掌握在自己手里，而不用向別人支付維護支持的費用──小心，千萬不要提到那些開源的工具，因為老板們萬一真的弄懂了“開源”這兩個字的含義，你的整個大計劃就泡湯了。拿IBM的RFT當靶子。除了后面我會說到的各種好處之外，IBM的咨詢價格足以幫你嚇到老板從而啟動這個項目。

　　然后，你要精心選擇一個自動化測試執行引擎。你需要這么一個引擎，因為你不能自己去做一個──工作量還在其次，要是連這都能做，你也就不在這個邊角部門里郁悶了。同時這個引擎又不能太穩定，更不能太開放，這都是你大計劃中不可或缺的要素。所以，你看，我說過了，RFT就是最好的靶子：它的開放程度確保了你要花好幾個月時間才能把它嵌在自己的工具里而且以后再也不會有別人嘗試干這件事。而且，想想吧，當你跟老板們報告說你hack了IBM的軟件從而省下了licence費用時，他們該有多開心。

　　接下來，你要發明一套自己的測試腳本語法。沿用RFT的語法當然輕松，但這樣使用它的人就會發現自己使用的其實是RFT，然后在該死的互聯網上找到相關的資料。不能讓這樣的事發生。始終記住，你的目標是讓自己變得重要。你發明的語法應該基于XML。不僅因為實現簡單，而且因為它能確保測試腳本無法被閱讀和重構，從而讓使用這工具的人跪在你腳邊求你支持。關于使用XML的好處，稍后我還會說到。

　　當然你不希望向領導演示時用記事本編輯XML。所以你得同時實現一個支持拖拽的測試用例編輯界面。把一個測試步驟表示為一個圖標，把幾個圖標往測試用例里一拖，一個測試用例就好了。別忘了，執行用例的功能也得在這個界面里實現。千萬別為了偷懶而實現一個命令行來執行用例，這很重要。好了，現在你可以去演示了，領導一定會喜歡的。“鼠標拖拽其實比鍵盤輸入慢多了!”旁邊一個傻逼顧問叫喊著。領導們不會聽懂他的話。不用理會他，更不要嘗試跟他爭論，那只會給你自己帶來麻煩。

　　現在這個工具可以小范圍試用了。那些麻煩的用戶會抱怨：“我每次都要重復這幾個同樣的操作!我想把它們合并成一個步驟!”鎮靜。不要罵他們(盡管你一直就想罵他們)。記得嗎?讓測試用例不可被重構是你大計劃中的一部分?，F在你要笑容可掬說。我們早就考慮到了這個問題，我們的工具可以把幾個步驟封裝成一個更大的、具有業務含義的東西……嗯，姑且把它叫做“操作詞匯”吧?，F在我就來幫助你們做這個抽象和封裝。當然了，操作也要用XML來承載，并且在提供給用戶時要先做一次編譯或者打包或者加密，總之是不能讓他們看到源文件。這樣他們才能永遠依賴你。

　　小范圍試用很重要。你必須努力工作，幫用戶寫測試用例，幫他們封裝操作，找你能找到的一切資源來幫他們，然后把投入二十個人月干出來的成果全都描述成你的工具帶來的神奇變化。放心，你只需要這么干一次(或者兩次)。為了把這些愚蠢的家伙踩在腳下，有時你就得先紆尊降貴。這是策略。

　　試用結束，你回到自己的辦公室，這些愚蠢的用戶還會不停地找你幫忙更新被封裝的操作。這是設計中的一環?，F在你應該做一個中央服務器，把他們的測試用例和操作全都保存在上面，讓他們每次執行測試都從服務器上取用例腳本。然后告訴他們，這叫云計算，這叫測試工廠。當然這些傻瓜不會懂得云計算是什么玩意，但他們會發現你幫他們更新操作的速度變快了，然后他們就會認為這就是云計算帶來的效果。把他們感謝你的話搜集起來，很快你就會用得上。

　　現在萬事俱備，可以向老板匯報了。這次匯報的重點是兩個關鍵詞。這也是今后宣傳這個工具時的常用語。一定要背熟。

　　關鍵詞1：“第四代自動化測試工具”。你要告訴老板，用Java啦Ruby啦C#啦這些編程語言來編寫測試用例，那是第三代(前兩代是什么就隨便你編吧)。第四代的特征就是“基于操作詞匯”──也就是圖形界面上可以拖的那個玩意，盡管你知道它背后就是一坨不能讀、不能改、連SVN合并都困難的XML。

　　關鍵詞2：“測試工廠”。這時候把界面打開，連上中央服務器，讓老板看試點項目的測試用例。“坐在辦公室就能知道所有項目的測試進展情況。”這句話是殺手锏。老板們一定會喜歡，而且會幫你推廣這個工具。

　　只要被推廣到更多的項目組，你就會變成紅人?，F在前面那些設計決策的重要性就逐漸體現了。因為測試用例不可重構，任何一個項目想要正經用你的工具都得找你幫忙做操作詞匯，為此你就可以成立一個部門，拉更多的人來給你打這份苦工，自己當領導。但你又怕別人真的用得太多太頻繁，那樣的話你就得疲于支撐了。放心，因為RFT不穩定，因為每次執行都要連到中央服務器來取用例，因為不能通過命令行或者Ant之類的辦法把它放進持續集成，還因為用鼠標拖拽就是比用鍵盤慢得多，自動化測試的進展會非常緩慢，你大可以安心享受自己的新辦公室。

　　先別急著享受，好事才剛開始呢。那些深思遠慮的設計決策確保了很多項目不會認真用你的工具。這時候作為推行先進自動化測試理念的紅人，你正好可以在老板耳邊吹吹風，讓他們強迫所有項目使用。強迫的方式有很多，但你必須記住的手段是給測試人員做職業技能鑒定考試：必須學會用你的工具才能評級加薪。這招的關鍵在于一箭雙雕：不僅可以強迫他們使用，而且確保了他們沒時間沒動力去了解別的測試工具──你當然不想這些傻瓜突然冒出來說“這個開源的工具比我們自己的好用多了，而且還有那么多社區高手在維護和支持，為什么不用它”，對吧?

原文轉自：http://gigix.thoughtworkers.org/2010/5/29/how-to-create-a-test-tool-which-sucks