我的測試之旅：（8）困難——沒有現成的測試工具

新的測試工作面臨的第一個調整就是無法使用熟悉的工具，之前的工具是根據產品的作業系統平臺以及人機介面進行了封裝的，而新的Linux系統顯然還不在他們的關注範圍內。於是我得另尋方法，方法當然也簡單，因為被測物件也就是我們所開發的東西，就是在Linux下執行的應用程式，其中有些核心模組（Kernel Module），只要通過Shell指令碼使用相關的命令就可以完成測試了。

Shell指令碼只能夠做到一個測試用例，寫一個Shell指令碼，於是有大量的重複，測試自動化上已經有豐富經驗的我自然難以接受，不過暫時也無能為力，畢竟我還不具備單獨開發出一個測試自動化框架的能力。只能夠在單個Shell指令碼中去執行多個測試用例，在指令碼內抽取出一些公用程式碼，做成函式，最大的缺陷就在於測試的顆粒度不夠清晰，以及測試用例之間的耦合度太高。

在Linux系統下進行測試，瞭解一些基本命令是必然的，比如查程式清單、輸出重定向之類的命令。由於沒有現成的函式可以使用，要能夠處理應用程式或核心模組的輸出，進行自動化的測試結果收集和分析也需要了解一些文字操作的高階命令，例如awk和sed等，最好還要懂得怎麼使用正規表示式，才有可能從瀚如煙海的日誌輸出中快速地識別出所要尋找的資訊。

一點點的程式設計能力也是需要的，有時候開發的功能就是為系統其他應用程式和模組提供服務，測試的物件就是它們提供出來的API（Application Programming Interface，應用程式程式設計介面），就只能夠自己寫一些測試用小程式，在程式裡面呼叫這些API，並通過輸出一些日誌資訊來進行測試。

所幸的是，後來測試自動化小組又從芬蘭引入了一套新的框架，也是口碑非常好，我後來也非常的喜歡，愛不釋手。這套框架叫做robotframework（www.robotframework.org），目前已經開源。它提供了Telnet的庫，可以通過Telnet協議和我們的被測裝置互動，向被測裝置寫入命令，以及獲得輸出，從而完成測試。框架本身的測試用例的格式也很簡單，當時主要支援Excel的CSV格式和HTML表格格式，我偏好其中的表格格式。表格格式的意思是，在一個HTML檔案中（或者叫頁面上），有四個表格，每個表格分別具有不同的含義，框架本身會區別對待其中的資訊，加以處理。根據其表格的內容和格式，填入文字化語言，而不是指令碼語言或是程式語言的函式呼叫，就是文字化的語言，寫好儲存，這就是一個測試用例，也是一個測試指令碼了。文字化的語句需要有對應的庫函式才可以真正產生作用，例如“Get Page Title”就得有類似於相應的get_page_title()庫函式，庫可以用Java或者Python語言實現。

檢視更多“我的測試之旅”文章
1. 起點——作為軟體開發人員
2. 轉變——作為專職測試人員
3. 同期——加入測試自動化小組
4. 並行——自動化迴歸測試
5. 難點——功能改進的測試
6. 跳轉——追逐新鮮事物的探險者
7. 啟程——Scrum中的測試工作者
8. 困難——沒有現成的測試工具
9. 行動——簡化測試文件和流程
10. 貢獻——開發項流程（Development Item Process）
11. 嘗試——Scrum Master
12. 機遇——測試自動化培訓師和教練
13. 轉型——敏捷教練

敬請關注 《大測大悟——測試的敏捷之道》開放出版過程

聯絡方式：
- 新浪微博
- 谷歌郵箱 kaverjody @gmail.com
- LinkedIn