一定要保持行为与代码实现分开以减少测试步骤的脆弱性，自动化脚本应该处理人类可读的功能说明和代码级别实现界面之间的转换。

图1 测试对象模型

　　步骤框进一步细分为不同的步骤类型。 步骤类型为执行时测试中所发生的一切提供了更高的可视性，引发大量的智能分类大故障。
　　设置步骤是用来准备和验证系统在正确的状态开始测试功能特性。正因如此，这些步骤中的任何可见问题都将阻止测试，测试将会被标记为“关闭”。 执行和验证的步骤是真正行使正被测试的特性的步骤。 这个空间的任何问题都必须进行调查，并把测试标记为“失败”。 后，还有一些在测试后将系统恢复到已知状态的清理步骤。这里的问题可能意味着后续测试的假故障（如果系统并不与它本应该的一致），所以一个“警告”被放在测试上了。

图2 步骤类型和状态 

　　我们已经看到步骤类型的好处主要在大量的自动化测试领域，因为它们减少了调查故障的时间。 用手工测试的话，测试工程师执行测试时可以瞬间作出这个决定。 

　　孤立的，可重复使用的构建模块和模板
　　因为超过50的测试员和1万的测试与测试下的同一系统交互，所以在我们的测试中有大量的步骤重复，大多是关于测试设置的。我们需要一种方法来增加系统功能的可用性，但同时也能限制这些功能交互的各个领域。我们通过引进构建模块和模板实现这一目标。
●构建模块是在一项功能上进行的（潜在参数驱动的）个体行动，应该包含必要的逻辑步骤以便与指定功能交互。一个模块的范围是灵活的，只需要和测试套件认为必要的那么多模块行。一个模块可以被分解成更小的模块，随后需求上升以增加一个功能交互性的灵活性。
●模板是连接在一起通过应用程序来创建流的构建模块的有序集合。功能交互不应该在模板里，而应在他们称作模块的里面。模板可以一个嵌一个，使少步骤的测试下的系统得以充分交互。

图3 构建块和模板