軟件測試自動化的未來是什么？(8)

　　依舊不變的是“表格”，改變的是填寫方式——其實這背后的，是關鍵字定義終于被開放出來，tester可以自己定義keyword然后“注冊”到框架中，而那些依然沒有學會基本編程技能的tester，繼續用這些keyword重復上個時代的事情——填寫表格。

　　其實相對于最初對關鍵字驅動的定義，這個真的已經不是關鍵字驅動了，如果非說它是，那么只能說上個時代的關鍵字驅動中，test case 表格的每行都是一個頁面操作，而“新的”關鍵字驅動中，test case 的每行都已經是一個完整的業務操作，以上面的“Create Valid User” step 為例，robot framework希望的實現方式是tester通過python等4GL實現一個同名的function，這個function接受兩個參數，分別是“fred”和“P4ssw0rd”，再把這個function注冊到robot framework中。而“Create Valid User”內部的實現，可以類似于一開始“數據驅動”中的那個例子，充分利用4GL的特性和已有的其他第三方組件(例如webdriver)，來實現各種復雜的基于UI的操作，這樣也就解決了剛剛“傳統的關鍵字驅動”所遇到的問題。

　　最后，當完成了這個function的開發并在robot framework中注冊后，做手工測試的system tester就可以很容易的把原本excel中的一個個case轉變為自動化腳本了。

　　其實這個思路有它的優點，例如：通過分工協作降低實施門檻，可以一開始就編寫符合robot所需格式的manual test case，等到keyword開完全了以后這些case就可以直接導入執行了;不再自給自足，而是保持一定的開放，并利用其他第三方組件的特性。這樣很大程度上解決了自動化項目實施遇到的人員能力問題和可維護性、可擴展性的問題。

　　另外，新的關鍵字驅動還有一個更加先進的“近親”BDD作為參照，很容易把它的一些實踐也一起融合進來。

　　一切看起來都很美好，不過問題也還是有。

　　表格化的test case畢竟不同于編寫代碼，調試就變成了一個問題，如果寫錯了關鍵字的一個字母，要及時發現并定位到問題就不那么容易。當然，可以再開發一個web平臺，讓編寫case的人僅能從一個list中選擇已經定義好的keyword，不過這個成本恐怕就不是一般研發團隊能承受的了。

　　作為一個軟件，易用性和復雜度總是成反比的，當框架提供了方便的表格化編寫case功能時，也相對的增加了底層的復雜度(雖然沒看過robot framework的代碼，但是相信底層代碼的分層也應該比較復雜)，對于想要真的掌握框架的團隊來說，無形中增加了一道門檻。另外，復雜度與可擴展性也是成反比的，就像我可以用木頭做一輛車，也可以把木頭車拆了做些別的東西，但是我沒法把一輛汽車拆了弄成別的東西——前兩年廣東美院那位把解放卡車拆了做成關公像的牛人除外。當然，最終實施自動化時到底如何進行框架選型，就要團隊自己在易用性/復雜度/可擴展性上進行評估了。

　　把excel里面的manual test case通過新的關鍵字驅動直接變成可執行的腳本是最好的方法嗎?這似乎只是一個傳統system test 的慣性思維在作怪，為什么沒看過開發人員把unit test 也寫到一個個表格里面?為什么manual test case 就一定要先寫在excel里面，而不是一開始就是代碼?

　　如果僅僅是考慮把 step組裝起來，再把case組織成suite執行，其實代碼實現上可以說毫無技術含量，但是對于一個沒有開發經驗的tester來說，這畢竟是一個跟coding簡單親密接觸的機會，可以讓tester從低難度的代碼開始培養興趣和信息。而keyword，無論新的還是舊的，卻剝奪了這個機會;當tester希望學習框架的時候，會發現表格的層面跟下層框架之間的不是樓梯，而是一道溝。

　　3. “關鍵字驅動”的未來

　　我們如今所處的環境總是在變化著，今天與10年前相比，最大的變化就是測試行業獲得了極大的發展，大多數企業都認可了測試工作的重要性，并且開始思考如何提升測試工作自身的質量和效率，而且不同規模的企業都在探索著合適自己的研發流程和技術;而tester們的技術能力也在不斷增強，至少能寫代碼的人比5年前多了很多。當然，還要感謝開源世界帶來的眾多框架、組件，讓自動化的門檻不斷降低。

原文轉自：http://www.cnblogs.com/jackei/archive/2012/11/25/2787231.html