代码的组织结构如下：

　　测试用例由业务流的操作组合而成，同时添加必要的验证，测试用例的结构如下所示：

　　而这些业务流的初始化与清理工作完全由每个应用的测试用例基类来进行处理，测试用例基类的写法如下：

　　随着自动化测试的开展和新的项目开展，新的问题也一个个的出现了，这些问题包括：

　　<!--[if !supportLists]-->1) <!--[endif]-->开始的时候没有使用jenkins，同时由于机器的IP地址没有办法固定下来，因此没有办法得到需要的测试报告，于是提供了一套机制来生成测试报告，测试报告的生成结果如下：

　　后来使用jenkins来进行持续集成，该测试报告生成方式被抛弃;

　　<!--[if !supportLists]-->2) <!--[endif]-->电影票客户端数据每天都需要更新，如此数据准备的操作需要放到自动化中来解决，于是提供数据准备和数据清理工作，提供@DataPrepare和@DataClear来进行数据准备和数据清理的配置;

　　<!--[if !supportLists]-->3) <!--[endif]-->测试环境有时候不太稳定，一些测试用例在第二次运行的时候可以通过，问了解决这个问题提供了@Rerun标签来对失败的测试用例进行再次执行进行配置，允许设置重复执行的次数;

　　<!--[if !supportLists]-->4) <!--[endif]-->后来环境更恶劣了，已经不是靠重复执行可以解决的，同时也希望当测试环境有问题的时候不要运行测试用例，为了解决这个问题提供了@CheckEnv标签来检查环境;

　　这些部分的特点都是与业务基本上没有相关性，因此在这里的做法是将这部分独立提成一个工程，该工程为各个业务的自动化脚本提供支持，同时在这个工程中处理了运行自动化脚本时的内存泄露和异常退出时再次运行无法启动app的问题;