首先，在制定自动化计划时，第一步是了解现有的自动化开发技术。 如上所述，底部的是其中几个，根据实际去测试的业务需求选择合适的自动化框架。 例如负责pc、无线m站、无线app(Android、ios )四大用户门户的自动化测试，同时考虑到整个研发团队的技术背景和组内测试人员的技术背景，选择的开发语言为java。 因为我的基础开发语言一直使用java，所以研发团队有java、php开发，有问题也可以向人请教。 然后，考虑如何管理自动化测试用例、如何管理测试基础数据以及如何反馈测试结果。 也就是说，我知道这个用例的执行是成功还是失败，有什么理由。 在此，我们使用junit单元测试框架来管理测试用例。 为什么没有选择testng？ 因为我最熟悉junit。 而且，后述的理由之一是需要持续执行自动化。 不需要特殊技能来请求或执行特殊的人，因此需要持续整合框架的支持。 自然选择jenkins，然后创建的用例需要生成编译。 这里直接选择了ant。 为什么呢，如上所述
因为ant junit可以直接生成测试报告，所以不需要编写测试报告管理系统，避免了车轮的重构
系统选型后的技术框架如下所示
如上所述，所有测试用例最后都返回用例的执行结果、json数据格式、boolean对象success来标记用例的执行情况，然后在junit中使用assert断言用例的执行情况当然，结果保存在数据库或本地文件中。 便于以后的分析。 没有保存数据库。 时间不够。 稍后开发
上面忽略了一点，测试用例需要测试基础数据。 这些数据会从那里读取吗？ testng支持从本地配置文件读取。 junit很麻烦。 虽然可以在beforeclass中自行编写从本地读取文件的功能，但由于不断集成测试，因此数据并不会每次都发生变化。 要更新文件，请从commit到代码分支。 这样做是可以的，但由于测试数据经常更新，因此也需要没有安装svn或git的人。 因此，在管理原结构的系统中追加网页，用web构成所有的测试基础数据，每次执行用例时，测试用例来这里更新最近执行的数据即可。
数据流图如下
综上所述，构建并完成了基本合格的可持续集成UI测试框架。 当然，该框架只需替换底层用例，也可以改为接口接口测试框架。 这目前只是调查了可行性，估计还没有实施，踩了很多漏洞
以上不仅是为了便于管理测试的基础数据，而且是使用现有车轮支架构建的框架