（2017.8.1 更新）
1、支持 web 端结合 sele-grid 的并发自动化测试，结合 docker 使用，具体请参考Web 应用并发自动化测试，具体命令：

python robot_mutil_test.py -s /Volumes/sd_card/lunkr_test_git/Web_AutoTest_Mutil -o web -r http://127.0.0.1:4444/wd/hub -t local,node1,node2

2、修复部分在 windows 上执行的 bug
3、修改 github 路径：https://github.com/wqzhou0208/rf_mutil_test

appium 运行过程中有做这一步，判断模拟器里面有没有 webdriveragent，有的话就直接启动，没有的话就 build 进去再启动，你可以看看日志，具体哪里命令我忘了，我之前也试过直接掉 webdrvieragent，看日志有，一般 build：

cd  /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent
xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination 'id=真机的udid 或 模拟器的名称还是id（要看看才记得）' test

是啊，前文也提到要用 1.6.5 及以后支持的

你用的是什么版本 1.6.5 可以，如果不支持的话我怎么跑起来

前者的话还没试，框架主要用于真机并发，后者的话我自己试过直接拔出，秒级干掉设备 udid，如果有这个坑的话我试试看有什么场景会这样子

apk 的坑我也遇到，你这种处理是个办法，顺序初始化也还好吧，只要不是后线程要等前线程结束后再初始化就应该没大问题

再提个点，并发用多进程，尽量不要用多线程，多线程在 Mac 会被前线程阻塞，我还在了解是什么原因，进程就没事

保证 wdabuild 是成功的，第二个看是用的端口，包括 appium 服务和 wda 转发的对不对得上设备

（2017.7.27 更新）
1、新增一个脚本连接启动服务和测试执行，一句命令即可搞定整个并发自动化流程，但考虑到有其他接入，只在 wqzhou 分支更新，未在 master 更新
2、新增参数-p 和-sp，为起始的服务端口和转发端口，以其开始 +1 启动
3、去除对 grid 方式的支持
命令如下：

how to use it
-h   help
-s   the testsuite or testcase path
-t   taglist,likes "tag1,tag2", split by ,
-o   the device os.likes ios,android
-p   server port
-sp  second server port
-n   the num of start server

python one_step_mutil.py -s /Volumes/sd_card/lunkr_test_git/iOS_AutoTest_Mutil -t tag1,tag2 -o ios -p 14000 -sp 15000 -n 2

运行例示：

就是两个问题：1、udid 分发的 appium 是否唯一，2、appium 所占用的端口

首先要知道核心竞争力是什么，何谓核心，和谁竞争，培养什么样的竞争力，就测试而言，技术测试？业务测试？还是再小分支，如某一种业务类型的专项测试？这算力的方向吧，第二是力的大小，取决于在某个关键领域上投入的多少，喜欢端的自动化测试，估计大部分时间都是在玩这个方面，熟能生巧，这就是力的大小，所以方向和投入是竞争力的基础，对于核心的话，最直接的体现是大家一说到道长就会联想起 robotframework，反过来说也是，大概就是这种意思，核心就是让某种技术，或某种思维成为你在行业或者人生中的一个标签，至于怎么拥有，我只能说 3 分天注定，7 分靠打拼了，3 分，看你能不能遇到好项目，这个还是挺关键的，那剩下的都是看自己肯不肯下苦工了，天下没有笨蛋，有的是懒惰的人

（2017.07.26 更新）假如再次执行 run_server.py 启动 appium 服务时，本来已经存在了如占用 4723 端口的 appium，考虑到没必要去 kill 掉已启动好的 appium，所以做了跳过处理，同时也把设备列表的顺序换过来，改成按连接电脑的顺序排序，这样做有什么好处，看下图

就是刚好遇到已经有设备在运行，你又想再插入多一台设备而不影响另外的设备的执行，就这么做了，当然接下来也会把启动服务和执行用例的起始端口作参数化，方便分批启动服务和分批运行

大神有何高见，看看说说我能不能优化一下

有兴趣的话一起弄，其实既然 ios 的实时同屏已经可以实现的话，对应操作方面可以利用 wd 作为连接的中间件，而且比较利好的是 xcode9 和 ios11 之后的无线技术，所以说实现一个 ios 版的 stf 技术上也已经不是什么大难题了，关键是有没有人去做，不过首先把 stf 研究好先，还要花很多时间慢慢研究呢

是可以啊，本来一个窗口就可以多个进程在里面运行，用例的并行就是这么实现的，但是，你把全部的 appium 都放到一个窗口的话，调试看日志什么的或许有点麻烦吧

用 appium 输入法，万事大吉

我一开始就是用-U 做的，但后面觉得没必要，你可以看看我后面的解释或截图，还有我今晚再加个功能，不用-U 的形式会更加灵活

好，现在 java 和 python 切来切去有点乱，我去改一下

设备相关的当然可以这么做，我里面那个 adb_helper 完全可以支持，就想多了点看看有没有其他朋友会输入自己特定的参数，刚好你提醒了我一下

像你这种需求的话，我这边可以看看是否加多一个 capabilities 的输入，能解决一些特定需求参数的问题

其实不用的，最关键就是 udid，当然，需要操作系统的话还是可以填一下，当标签，我连 devicename 都是随机字符串，仅可能的简化操作，还是看具体需求吧，就是 udid 不能缺

不用，这个问题我之前还问过别人，后面自己试过了是不用 root 的

有兴趣的话拿去试一下，有 bug 和我提一下哈。刚好在收集需求，想做个平台

有问题的话给我提 issue 哈，谢谢

非常认同，之前还被人怼了说策略什么的都是虾扯，技术才是关键，其实我比较向往用产品思维来做测试的方法，就是思维主导的意思，技术再牛，没有好的策略和思维，空谈