写此分享的目的在于记录自己在实现UI自动化工作的心路历程，and希望可以借自己的亲身经历及经验给小伙伴做个参考。未完待续……
一、启动appium
问题原因：
首先要说的是实现自动化的第一步，我们必须要开启appium服务。这看似简单的一步操作，实则需要多考虑一层。因为python脚本是顺序执行，也就是说当上一步进程完成之后才会顺序执行下一步，这就面临一个问题：appium服务是需要始终保持开启状态的，这就会导致后续的程序无法运行，即被阻塞住，此时就需要找一种方法防止程序阻塞。
解决办法：
当我们需要调用系统的命令的时候，最先考虑的os 模块，用os.system()和os.popen()来进行操作，但这两种方法都会去等待子进程完成，造成父进程的阻塞。所以，选择另外一种方法来代替：subprocess.Popen(commend)。它可以实现多个子进程的并行，参数commend可以是字符串或者序列类型（如：list，元组），用于指定进程的可执行文件及其参数。如果是序列类型，第一个元素通常是可执行文件的路径。
二、 读取配置文件
问题原因：
配置文件存在的意义在于它的易用性，在做自动化的过程中有一些参数不是固定不变的，所以，如果将我们的程序写死就大大降低了它的灵活性。想象一下，每次运行之前先将脚本检查更改一遍，这个过程想必是很痛苦的。一切工具都是为人服务的，如果这个工具很繁琐，不好用，那它就完全失去了本身存在的意义，所谓实践是检验真理的唯一标准。说了这么多，此配置文件的作用就是，在运行用例之前，只需在本地修改测试机的uid等参数就，然后就直接读配置文件中参数的值，方便快捷。切入正题：在生成jar包时，用来读取配置文件的class文件已经被固定，导致本地修改配置文件无法生效，运行用例时读取的配置文件参数永远都是生成jar包时的参数。
解决办法：
将读取配置文件的脚本做简单修改，让它去读本地用户目录下的配置文件参数。这样一来，我们只需将配置文件放在本地用户目录下，在运行程序之前，根据实际情况修改相应的配置文件参数就OK。在运行程序时，就会自动去读本地配置文件中的参数，实现了灵活性和易用性。
三、获取最近一次运行产生的log
问题原因：
这个虽然不能构成问题，但是在实际操作实践过程中可以感受到，用最简洁的方法实现目标是最高效的。我们的目的在于获取最新的log，也就是实时性。运行一次脚本就会产生一次log，在实际过程中必然会产生很多log，导致我们不知道去分析哪些，或即便我们分析了也可能不是最新的，导致分析没有可参考价值。
解决办法：
每次运行脚本时先去本地查看一下，如果有已存在的log文件，将其删除。这样每次运行脚本后，产生的log文件及内容都是最新的，可以保证我们每次分析的log都是最近一次生成的，最新的，十分有参考价值。
