使用Functional Tester的一项测试技术[1] 软件测试
使用传统的制表格式介绍决策过程。 决策表提供了一个简单的，可视化的帮助，它可以在知识库系统中被使用，来高效的执行验证过程。在软件开发过程中，决策表能够帮助测试小组在软件应用程序中管理复杂的逻辑性。
这篇文章介绍了一种基于决策表的测试技术，描述了一种使用 IBM Rational Functional Tester 和 IBM Rational Software Modeler 的实现方法。这项技术常常通过运行一系列复用测试脚本来详细描述非回归测试套件。每一个测试脚本都是使用 Functional Tester 的 GUI 记录/回放技术产生的。
这里，我的目标是"概念证明"。为此，我花费了5天的时间开发了一个Java类库，用来使用 IBM Rational 工具实现决策表技术。虽然这项技术还没有被部署到实际项目中，但是我会通过使用基于Eclipse框架的IBM Rational工具来论证这个方法的潜力。我计划的实现方法是完全基于标准的，文档化的接口，任何读者都可以很容易的理解。
问题
非回归测试是基于数据驱动的测试技术，一个简单的测试脚本会根据输入数据的不同而反复的被使用，这在测试自动化方面是很常见的。 这项技术可以使用Functional Tester中的数据池来实现，这些数据池是在一个测试脚本建立期间或者建立之后关联在测试脚本上的。不幸的是，当测试应用程序陷入复杂的逻辑中时，数据驱动的测试在没有硬编码的情况下变得难以实现。一般来说，应用程序的行为是受组成测试套件的测试脚本的不同输入数据影响的。我们需要使用等值划分来区别输入的数据，它可以提供一个AUT(被测试的应用程序)的等价行为。在每一个测试套件中都要使用硬编码环境，它能帮助我们向着正确的测试路径前进，并且可以处理数据的变化。这个方法不仅适用于测试人员，同样对于开发人员来说也很"有趣"，特别是在使用自动化测试工具时，因为在硬编码的测试脚本环境中，使得维护以及测试脚本的扩变得非常难以管理。此外，如果在头脑中没有一个清晰的策略，是很难优化测试脚本分解的。
建议方法
当一个测试人员手动实现一个测试程序时，他会根据测试目的选择输入的数据，并根据AUT的行为作决策。问题是，我们怎样在不使用硬编码而使用自动化测试工具的决策制定过程中帮助测试人员?
这个简单的问题使我们去考虑决策表技术，并开发一个Java类库来验证这个概念。决策表通过Functional Tester数据池实现。通过决策表提供的用于解释测试逻辑的决策脚本，被整合到测试套件的体系架构中，如图1所示。其他组成测试套件的可重用测试脚本是通过使用Functional Tester的GUI记录/回放技术产生的。一个测试片断被定义成一个测试脚本的序列，它可能是两个决策脚本之间的序列，或者是开始脚本和决策脚本的序列，再或者是决策脚本和结束脚本的序列。一个数据驱动表和测试套件连接在一起，它可以根据不同的输入数据重复运行测试套件，并把结果输入给不同的测试脚本。
图1：由测试脚本和决策脚本组成的测试套件。
文章来源于领测软件测试网 https://www.ltesting.net/