我们来简单点吧，我们的目的，在一定的测试范围内，充分利用工具来自动化生成测试用例，保证测试用例的覆盖率。 两种程度的复用该测试套件，一种是测试用例的生成和复用，一种是测试代码的生成和复用。 请看下面的自动化生成框架的架构图：

　　模板引擎架构图如下：

　　相关术语解释：

　　1.All Pairs：利用参数来定制化生成测试用例的工具，入口是Excel准备的参数文件;出口是txt文件的测试用例。这个工具是开源的，可以自己定制化开发

　　2.业务API库：由于需要生成测试代码，需要知道业务逻辑所涉及到的接口和类，比如IC中的发布宝贝的发布接口。

　　3.模板：根据业务逻辑规则制定的逻辑描述，可以利用因果图分析法中的“或 与 非”来描述接口业务功能逻辑(需要抽象出相应的关键因子，也是部分的接口入参)

　　4.测试用例分析器：将txt文件格式的测试用例进行分析，分析每个用例的参数和参数值和业务逻辑。

　　5.测试数据分析器：将xml文件格式的测试数据进行分析，与生成的每个测试用例代码进行组合和处理，生成带数据的测试代码。

　　那么接下来我们需要做什么呢。迭代去开发我们需要的组件行，第一步考虑自动生成接口测试框架代码，定制化的选择接口来自动生成框架代码(包括集成了现成的接口测试框架);接下来考虑如何让我们的用户(测试人员)来输入我们的测试数据，并考虑与框架代码生成进行集成融合;另外一块是测试环境的API的调用了，如何能自动运行自动生成的测试代码并反馈结果给测试人员等一系列的问题需要进一步深入挖掘。

　　这里还需要说明的是，我们不期望这个框架能解决所有接口功能接口测试代码的自动生成(有些接口实现业务逻辑较复杂)，我们能解决掉一部分重复工作(某个接口的60%的测试代码)，且能告诉大家我们可以做一些事情更智能化和简单化。