做了一段时间的自动化测试，遇到了一些问题，有了一些思考，主要是关于该如何设计自动化测试代码结构。

首先，针对一个特定的项目，该如何设计自动化测试？

我认为，需要考虑一下三点：

1、核心价值有哪些？

2、核心价值中，有哪些重要的检查点？

3、操作如何进行分割，以便于控制测试用例中操作链的长度？操作链过长，一旦某个点出现故障，所有自动化操作就此停止，不利于充分利用无人值守的时间；操作链过短，重复启动和关闭，增加数据准备的开销，降低了自动化运行的效率。

4、测试用例代码如何划分结构，以便最小化解决方案的变更带来的影响？

而合理的框架，主要用来解决第4个问题，同时，又需要能方便的用于不同的项目。

目前的思路如下：

1、自动化测试代码结构分为：公用api、操作、组织、模型、数据

2、公用api，对一些基层操作进行封装，以隔离解决方案与测试代码。例如将所有类型控件的输入抽取成一个input方法，测试中，只需给出控件的id和输入值。

3、操作，以业务场景中的操作节点为一个操作，每一个操作都应该有一个检查点，且需要考虑如何自动根据测试数据判断应有的预期结果。

4、组织，将操作进行组装，形成测试用例。

5、模型，根据业务，将其中的各个业务实体封装，以便传递测试数据和获得操作结果。

5、数据。包括测试数据和环境参数。