现在假定新需求改变了密码极限长度，由于每一个需求和被测功能都由测试用例清晰地显示出来，我能够很快定位哪一个测试用例需要修改。并且由于每一个测试数据也即密码都以有意义的变量的形式储存，我们能够很快的找到需要修改的变量进行重新赋值。先前对测试代码所做的重构带来的好处显而易见，这里再一次强调测试即开发的主旨。
让测试经得起测试：应对系统主要实现架构的改变
在前面部分我们努力让测试能够更灵活地自适应需求变更，可如果是系统的主要实现架构发生了变化呢？测试会受到什么影响？为了找出答案，我们通过改变一点实现的细节——通过Web页面创建用户的方式取代之前的命令行调用Create命令的方式。现在创建用户只需要打开创建用户的Web页面，输入用户名和密码，然后点击创建用户按钮，由页面打印创建结果。严峻的问题来了，我们的测试该如何修改？
还记得我们之前封装不必要细节并提炼了两个关键字Create Account和Status Should Be。这两个关键字封装的细节就是如何调用命令行执行Create命令以及获得结果报告。很明显，我们肯定要重写这两个地方，因为现在需要通过Web页面操作才能实现。
表8 修改后的关键字实现
表8是修改后的关键字实现。我们修改了与系统交互的实现，即通过使用开源Web测试工具Selenium进行页面访问和操作，那么现在的问题是对于那几个具体的自动化测试用例，我们还需要修改什么？答案是什么都不需要，此次修改工作已完毕。通过改变几行代码，使我们的自动化测试轻松运行在变化了的实现架构的系统上，这往往就是成功和失败的自动化测试之间的区别。
与此同时，回到现实世界
在真实的测试中，你可能要做更多的工作以应对系统实现架构的变化，你可能不止需要修改两个关键字。但只要你创建了级别较低的关键字，将其他代码和与系统交互的细节分开， 那么你所需要做的就只是修改这些关键字而该测试用例照常运行不需要改动【译者注：如果你看到Martin Flower的《重构》一书，就应该明白这样一条重构原则，保持接口不变，改变底层实现】。
真实的项目里很多实现架构上的变动将会对测试开发工具提出更严酷更颠覆的问题。 但 即使是最坏情况，你依然可以使用先进的开源测试工具，用以解决很多重复的问题，帮助你撰写能够清晰表达测试本质的用例和脚本。
再次强调，一定要记住其中的本质内容：只有消灭重复的无关紧要细节，让测试清晰表达被测系统功能职责，才能在发生系统需求和实现变更的情况下轻松应对以便降低自动化测试维护的成本。这也正是我们衡量自动化测试开发成功的标志。
