Appium系列(二十)分析现有不足，打造牛逼测试框架
Appium系列分享
Appium自动化(七)通过脚本自动化获取apk的包名和对应启动activity
Appium自动化(八)通过脚本自动化获取设备deviceName和platformVersion
Appium自动化(十二)Appium+unittest组织测试用例
Appium系列(十七)将Appium服务端口号通过参数传递给测试用例
前言
通过之前的分享，我们整体的框架的架子已经有了雏形，目前还存在很多问题，那么我们现在来梳理下，为接下来的方向做一次小小的复盘。
正文
看下，这是整体的结构，目前在结构上的优化没有太多的好的方向，我们接下来来看的是现有的代码的优化。
我们去分析下现在的代码，首先我们看下测试用例文件，我们可以看到在上面的路径，我们是否可以通过动态的把apk_path传入进来。对于desired_caps是否可以在前面直接安装不一样的模版传递进来。我们现在支持的Android应用，那么IOS应用如何支持呢。
元素定位这里
我们默认的都是固定，那么有一天我们的UI发生变化，我们的定位方式可能需要变化，那么我们这些都需要重新修改，是不是特别麻烦，需要代码，应该可以在定位元素的地方就可以维护。
adbtool的模块，现在支持的是获取简单的一些设备信息，那么后续是否可以增加性能数据呢？adb的部分命令是否可以兼容不同的厂商设备呢。截图是否能够增加进来。
测试用例现在不支持失败重试，我们在真实的测试中可能因为一些非必要的原因导致了测试失败呢，那么我们是否有更好的方式可以解决这个问题呢。
我们的执行过程中，我们只是收集了appium的日志，那么app崩溃了，我们是否可以收集日志呢，测试过程我们是否也可以看到app的执行日志呢。
测试数据的维护的，如何可以才维护数据才是最简单快捷的。多功能用例是否可以有更好的维护方式呢。
生成端口号，应该去重，端口可以自动根据不一样的设备自动拓展？
测试报告，我们现在的测试报告终端，没有更好的测试报告，我们是否可以引入测试报告的模版来展示呢，我们前面的adb可以获取性能数据，我们是否可以把性能数据直接展示到我们的测试报告中呢。
设备，我们是否可以加入STF设备管理平台，管理测试设备。
如果有多个项目需要自动化，现在的项目是否可以快速复制。
以上呢，我们是针对现有的框架进行了一些分析，那么在后续的分享中，我们可以围绕着上诉的方面，进行优化。
现有代码下载链接：链接: https://pan.baidu.com/s/1wCgNy4gKb1YUkzOHWpTd0g 提取码: 25bv 复制这段内容后打开百度网盘手机App，操作更方便哦