新的测试工作面临的第一个调整就是无法使用熟悉的工具，之前的工具是根据产品的操作系统平台以及人机接口进行了封装的，而新的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”就得有类似于相应的getpagetitle（）库函数，库可以用Java或者Python语言实现。
相关链接：
我的软件测试之旅：（1）起点——作为软件开发人员
我的软件测试之旅：（2）转变——作为专职测试人员
我的软件测试之旅：（3）同期——加入测试自动化小组
我的软件测试之旅：（4）并行——自动化回归测试
我的软件测试之旅：（5）难点——功能改进的测试
我的软件测试之旅：（6）跳转——追逐新鲜事物的探险者
我的软件测试之旅：（7）启程——Scrum中的测试工作者