現在市面上的大部分軟件測試工具，我們在使用時都要使用工具的腳本語言。令我最煩惱的是，為了使用他們的工具，我必須學習指定的腳本語言。大部分工具有錄制功能，為你產生一些腳本，但是不可避免地，你要對腳本進行修改，自己編寫腳本。這樣的話，你就必須要學習額外的語言-廠商語言-這個語言只是在這個特定的工具上能使用！
破壞合作
因為廠商語言是特定的語言，開發人員對其知之甚少并且也不愿意學習它。我經常鼓勵測試員和開發人員在自動化項目中一起合作。這是高效的合作方式。但是廠商語言擋在中間。它們把測試員和開發人員分開，孤立在指定的工具語言上。減少了共享、合作和改進的機會。
要把測試員和開發人員整合在測試過程中，我們已經有很多困難了�，F在又多了個廠商語言的學習問題。你如果叫一個開發人員學習VB？沒問題，因為他們畢竟可以在將來有使用得上的機會。你如果叫一個開發人員學習一個指定的語言，這個語言只能在這個工具上使用？你做夢吧！你已經很難讓開發人員把注意力放在測試上了，現在又增加了一個困難。
為什么要把錢花在一個會破壞測試員與開發人員之間的合作關系的工具上？
方言
有很多這種廠商腳本的方言。有些是類C語言。意味著什么？意味著寫出來的代碼想C語言的代碼，但是沒有指針，所以你不能使用在C課程和書本上學習到的任何復雜的數據結構。C作為腳本語言來說是很差的。它是編譯的，但是測試腳本語言是解釋執行的。這是為什么類C語言不支持指針。
其它的有些使用類VB語言的方言。如果你了解VB，則代碼會看起來很眼熟，但是你不能使用VB的標準庫。而且，你在VB中學到的東西未必被應用在廠商腳本語言上。
也有一些工具使用類似面向對象的廠商腳本語言。面向對象是好的，但是你會發現對一個類的修改不會繼承到它的子類。什么？因為廠商腳本語言認為這樣更方便測試的管理安排。這樣是否真的能幫助測試員還有待討論，但是測試員真正需要的不是為測試特定設計的語言。他們應該得到標準的語言實現，這樣才會更好地幫助他們的測試工作。
一些更新的測試工具現在開始使用真正的腳本語言，像JavaScript或VB。我希望這種趨勢能繼續下去。而且，如果一些舊的工具能重新設計以支持標準語言則會更好。標準語言有正式的規范，會幫助你的測試組更好地用在測試上。
重復地發明輪子
最近有些文章在描述怎樣使用廠商腳本添加堆棧和隊列，這其實是廠商腳本的落后體現。廠商語言使自動化測試人員浪費很多時間和精力在重新發明輪子。堆棧和隊列在標準語言上已經得到很好的實現。
我自己也有同感。我必須為不同的廠商語言創建庫來支持sting操作、日期計算、計算排列組合等。有些廠商語言也有這樣的庫，但是標準語言的庫會更大、更全面，也更加健壯。
回到以前
很多非測試工具也嵌入了廠商語言。使其更難使用。John Ousterhout發明了TCL（Tool Control Language），使得跟C的集成更容易，并發布到公共領域。TCL現在被用在一些公共領域的測試工具上。
Ousterhout區分了系統編程語言（像Pascal、C、C++、Java等）和腳本語言（像Perl、Python、Rexx、TCL、VB、Unix shells等）。系統編程語言在從頭開始構建方面和性能方面會更好點。而腳本語言在重用代碼和快速開發方面有優勢，是理想的自動化測試語言。
有些測試工具的廠商語言是在Ousterhout的TCL出現之前，當時Perl也還不成熟。但是那是那時候，現在則有了很多選擇。
讓廠商腳本語言退休
因為有了很多的選擇，所以廠商腳本語言應該退休了。如果出現異常，沒有什么第三方的書可以使用，只能參考和依賴廠商提供的書或幫助文檔，這些文檔未必會坦白告訴你廠商腳本語言的缺點。語言的課程也很難隨工具附上，很昂貴，可能還要你親自去學習。
測試自動化會很難，如果我們需要熟悉不同工具的不同語言的話。開發人員不會忍受有這么多限制和缺點的編程語言，我們也不應該忍受。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
