仔细看一下，我们可以挑出来几个密码，比如1234！@$^！紧接着再加把劲，啊哈，我们会发现一些密码会导致status值为Invalid Password，而另一些会使得status值为Account Created。从另一方面看，我们可能也会注意不到上述内容因为该测试脚本在密码和状态status之间夹杂了太多的实现细节，或曰：测试噪声。试想，这些特殊的符号$、@、^以及单词Run、Ruby、fred究竟和密码及其有效性有什么关系！对于自动化测试的脚本来说，从用例的可读性和可维护性角度看这些都是无关紧要的过程实现细节。

　　过多无关紧要的细节是怎样毁掉可维护性的？假设我们的系统安全分析师指出六位长度的密码本身不安全。于是为了增强安全性，我们将密码长度下限由六改成十，这是一个典型的需求变更，请思考，这时候列表1的测试脚本哪里需要修改？怎样改？答案恐怕没那么简单。

　　让我们再来考虑一个更有挑战性的需求变更。假如我们想让系统管理员能够为任一种情况设定具体的密码长度最长与最短值。这时候该怎么修改刚才的测试脚本？答案还是无法一眼看出。恐怕没那么简单。

　　这其中的原因“恐怕”在于测试脚本没有清晰表达它所要测试的功能职责。当看不出一段测试用例脚本的本质 ，通常意味着需求变更之时测试人员会需要花数倍的代价来修改原测试脚本。

　　因此，为方便识别本质就要隐藏非必要细节的，以使自动化脚本用户更容易看到测试的本质，在上面创建用户的例子中，大多数非必要的细节是如何调用Create命令。该系统是基于Ruby的命令行程序，现在让我们再次返回列表1的测式脚本里解读一番，黑色字体加深的第一行告诉自动化测试框架Robot启动Ruby解释器，加载被测程序文件app/cli.rb，并调用Create命令，参数值为用户名fred以及密码1234！@$^，最后命令返回的结果存在变量${status}中，呵，数数不必要的实现，细节至少有5~6个之多！

　　再来看字体加深的第二行，实现命令返回值和期望值Invalid Password的比较，虽然看起来比刚才那一行较容易理解 ，但措辞笨重，并且过分的语法细节容易分散人们的注意力。

　　通过Robot自动化框架我们可以把实现细节提炼成关键字（Keyword），使之以类似子函数的形式为测试用例脚本调用，一个完整的自动化测试用例便可由数个关键字组合而成。

　　现在我们演示如何使用关键字来隐藏不必要的实现细节。一个可行的方法就是问自己这样一个问题：假设自己对被测系统实现一无所知，该如何写出自动化测试脚本的第一步？是的，即使对实现一无所知也无大碍，我们只需 知道我们要测试创建用户这个产品特性——被测系统显然要提供的功能。继而我们知道创建用户即是被测系统的必要职责，而且从系统需求分析可知创建用户需要提供用户名和密码。

　　基于以上所述，可能这样修改测试：

　　Create Account fred 1234@！$^

　　当然修改后的脚本可能还有其他一些问题，我会在稍后部分接着讨论。

　　再看看加深的第二行，验证创建用户命令返回的结果是否为Invalid Password，顺着上面修改的思路则可以变成：Status Should Be Invalid Password。

　　两行合并，看一看整体效果：

　　Create Account fred 1234@！$^

　　Status Should Be Invalid Password

　　原来的一步经过一次提炼现在看起来简洁多了，可读性也变强了，我们很容易发现这两行的逻辑上的联系：系统必须告知输入的这一密码是无效的。

　　现在还无法运行新的脚本，因为测试框架Robot找不到关键字Create Account和Status Should Be的定义，两个关键字的Ruby实现代码如表2。

表2 两个关键字的Ruby实现代码

　　字体加深的代码行创建了一个名为Create Account的关键字，需要两个参数user_name和password。关键字函数的主体只有两行代码，第一行加载被测程序并调用Create命令，第二行保存返回值，对比之前的原测试脚本，我们发现主体第一行代码和表1的加深第一行实现了同样的功能，非必要细节即隐藏于此。