测试用例的内部参数传递，是测试过程对测试用例的要求，在测试框架中，需要实现的是允许测试设计工程师配置这个参数传递过程，而不是通过修改测试脚本来实现。也就是说，需要在测试用例中定义传递规则，在执行时刻由测试框架来实现参数传递，而不是脚本自己来实现。
测试用例的输入参数，这个部分解释起来会涉及到测试环境管理，这里就不再详细描述。
测试用例的验证规则，是测试用例是否执行通过的基本要求，也是必须的。在自动测试框架中，需要定义规则，而不是在测试脚本中来实现。因为如果测试脚本中实现了规则，会导致测试脚本的重用成为难以逾越的问题。
3、对测试脚本的要求
测试脚本需要体现操作流程，而不体现测试逻辑。
测试框架对测试脚本的要求，是——“尽可能简单”。
4、测试数据管理
测试数据分成两个部分(自动测试中)：1)测试用例数据;2)测试数据场景数据。
首先，我们给出一个概念：测试数据场景。测试数据场景定义：相对于测试计划，测试计划中的所有测试用例对测试环境的数据依赖，就是测试数据场景。
测试数据，包括在测试用例中。
测试框架要求测试用例把依赖于测试数据场景的数据部分，定义为输入参数。这样，当我们获得一个测试用例的集合(体现为测试集)，我们就可以得到所有测试用例输入参数的集合。
测试数据的集合，可以和测试数据场景来对应，也就是说，这个集合就是自动测试能够执行所依赖的测试数据场景。
自动测试框架的构建
自动测试框架可以通过几种方式来构建：
5、基于编写程序来构建
可以通过自己来编写一个程序，实现所有的自动测试框架。实际上，这就是一个编写一个类似于TestCenter这样的关系系统。
也有部分的测试组织来管理，相对比较少。
6、基于QC来构建
QC是一个两层次的架构，用户可以通过在QC中增加一些插件，来实现三层的测试框架、数据管理框架、测试场景框架。
大多数使用自动化测试的用户也是这样来做的。
还有一种方法，是对测试脚本进行二次封装，在测试脚本层面实现一个三层的测试框架。当然这种方法可以实现：1)参数传递;2)测试配置等工作。如果需要更好的实现自动测试框架，这种方法还是存在很多缺憾。
7、基于TestCenter来构建
TestCenter是实现3+层框架的测试工具，已经包括了完整的自动化测试框架。用户可以基于此工具来建立自己的自动化测试体系，对于当前用户对自动化测试的需求，已经支持的比较好了。
特别是对于迭代测试，TestCenter提供了非常好的支持：把第一次测试产生的测试集合，作为下一次测试的输入，组装成测试集合的测试集合，很方便的进行后一个轮次的测试过程。
文章来源于领测软件测试网 https://www.ltesting.net/
