#3 楼 @mick_god :plus1:

1. 麻烦加头像。。。
2. 请像一个专业的测试报 bug 那样详细描述你的问题。至少包括这些部分：

• 你的设备的 udid 是什么，你是通过什么方式获取的
• 你的 appium 版本是什么
• 你的 appium server log 是什么
• 预期结果和实际结果。

另外， 可以先告诉你结论，udid 确实可以选择设备的（至少 appium 1.3.4 及以上可以），无数人已经试验并证明了这个功能是正常的。

#1 楼 @lihuazhang angularjs 2.0 据说和 1.0 差异很大了。。。

公司竟然禁 testerhome 。。。没想到 testerhome 也会进黑名单。。。

众测确实是一种趋势，就像大公司都喜欢把没什么技术含量的那部分测试外包出去一样，测试确实有些环节对大部分公司而言成本越低越好。众测的成本比外包还低，而且还能部分起到宣传的作用，确实很吸引。

但作为自由职业估计短期内还不一定行，因为现在国内众测的报酬还不是很高，而且有些任务的报酬是以报告的有效 bug 数，而非工作量计算，报酬相对就更不稳定了。而且国外有 utest 这个最大的众测平台，报酬以美金计算，收入高很多。

不错的实践。看你的写法应该是想把操作分离出来，然后再通过非代码的方式编写测试用例是吧？

数据驱动这个目前没做过，但看你目前的实现实际上应该是数据分离吧？我的对数据驱动的理解是 不仅仅是把输入的数据分离出来，还得把数据和业务逻辑绑定，通过数据自动选择业务逻辑。例如填写销售单，不同类型的销售单会需要会有不同的业务流和不同的数据，数据驱动需要做到仅给出销售单类型和对应数据即可执行测试。

我们目前主要使用的是关键字驱动，但同样提供了简单的数据分离的方式。对于环境配置相关的数据我们分离到了一个指定的文件中，以类似 ini 的方式记录。然后用例可通过一个特殊的关键字获取这个外部文件的指定数据，实现基本的外部参数配置。

对于测试结果，个人建议框架只需要支持把测试结果导出成 Junit 格式的 xml 文件，然后你就有一大堆现成工具可以利用这个 xml 文件用来生成各种不同的测试报告了，不用重复造轮子。

对于测试案例管理（我的理解是测试用例管理，不知道对不对？），我们目前是对 testlink 进行二次开发，添加了针对自动化测试用例编写的模块（把原有的用例编写模块改了下）以及导出测试用例的接口。因此具体用例管理可以继续和以前的手工用例一样通过 testlink 进行管理。因为用例管理这块看起来简单，实际上要做到能很好地进行团队协作还是需要做很多东西的（权限管理、不同项目之间的分离、测试计划的管理等），二次开发可以减少重复造轮子。

最后，如果不想在测试工具开发这边投入太多精力或者走太多弯路，最好还是先了解一下自己想做的功能目前有哪些优秀的框架有提供，学习他们的实现架构和实现方式，这样写起来速度会快很多。在 appium 用例封装这一块个人建议学习一下 robotframework 的 Selenium2Library 和 AppiumLibrary（在里面你会了解到元素查找应该怎么封装最为简便，同时这两个库对于 robotframework 的依赖也不强，主要依赖了几个工具类和日志模块，可以很方便地分离出来），以及 Page Object 设计模式。

#4 楼 @yy_u 看起来是 selendroid 的错误，但这么少的错误信息定位不了。建议你等到能发帖时把完整 log 贴上来吧。
如果等不及，建议参考 Appium 报错后查错指南 自己排一下错吧。

赞！加油！
话说我被第一张图吓尿了。。。

额，这个是原创还是转载？如果转载最好注明一下原地址吧。

另外，排版有点乱，建议参考 https://testerhome.com/topics/2976

好强大！

你试一下直接在浏览器输入 "http://127.0.0.1:4723/wd/hub" 看有没有这样的提示信息？

That URL did not map to a valid JSONWP resource

#11 楼 @hudiefeifei 你在这一句前后都加个 log ：

driver = new IOSDriver<MobileElement>(new URL("http://127.0.0.1:4723/wd/hub"), capabilities);

看看是否前后的 log 都能打印出来？

#10 楼 @kuroky 建议你先在同一个界面使用 driver.source 获取界面元素树，然后再去 diff 出区别吧？
你这么说比较模糊，而且 inspector 显示出来的属性有些是和真正的 xml 文件有出入的（特别是 visible 属性），不能全信。

Genymotion 本身也有这个选项：

把最下面的 use virtual keyboard for text input 勾上就行了。只是这个选项必须在模拟器开机前选择，不能运行中更改，没那么方便。

只有一个 status 不停出现这个是 appium.app 本身的正常现象，只要选的 platform 是 iOS 都会有。（目前还没探究具体原因，估计应该是 GUI 界面向 server 发心跳包确认 server 是否还存活吧，我用命令行启动 appium 的话不会有这些 log ）

这个 log 和实际执行没有半毛钱关系。。。

另外，你能在 setUp 那里打个断点或者打印一个 log 吗？现在这么看貌似 Junit 的这个用例根本没执行。

#19 楼 @bjj
官方的说明：

UiAutomatorTestCase

extends InstrumentationTestCase

This class is deprecated.
It is no longer necessary to extend UiAutomatorTestCase. You can use getInstance(Instrumentation) from any test class as long as you have access to an Instrumentation instance.

http://developer.android.com/reference/android/support/test/uiautomator/UiAutomatorTestCase.html

官方的新例子：

import android.test.InstrumentationTestCase;
import android.support.test.uiautomator.UiDevice;
import android.support.test.uiautomator.By;

public class CalculatorUiTest extends InstrumentationTestCase {

    private UiDevice mDevice;

    public void setUp() {
        // Initialize UiDevice instance
        mDevice = UiDevice.getInstance(getInstrumentation());

        // Start from the home screen
        mDevice.pressHome();
        mDevice.wait(Until.hasObject(By.pkg(getHomeScreenPackage()).depth(0)),
    }
}

http://developer.android.com/training/testing/ui-testing/uiautomator-testing.html#accessing-ui-components

#8 楼 @kuroky 具体哪里不一样？

#6 楼 @kuroky 然后解决了吗？
homebrew 本身要更新到最新版哦。

试下装个最新的 homebrew ？
网上有人说 brew 版本太老也不行，不兼容新的 ideviceinstaller 自动安装脚本。

另外，麻烦添加一下头像，谢谢。

额，出错原因是你的 setUp 第二次执行时开不了 session 。

你以为的执行顺序是：

setUp->Test001->Test002

实际执行顺序是：

setUp->Test001->setUp->Test002

解决方法：

1. 如果你想使用第一种执行顺序，把 setUp 改名为 setUpBeforeClass， tearDown 改为 tearDownAfterClass（如果有）
2. 如果你确实希望每个 case 都重新启动 session ，麻烦添加 tearDown 并在 tearDown 中关闭 session（driver.quit()）

使用单元测试框架（如 Junit）前最好先了解一下它的一些基本概念吧。例如 Junit 的 setUp 和 tearDown ：http://etutorials.org/Programming/Java+extreme+programming/Chapter+4.+JUnit/4.6+Set+Up+and+Tear+Down/

#4 楼 @zsx10110 看你想做到什么程度吧。

• 方案一（开发量少，不依赖 appium client，但需要直接调用 adb 命令）：

1. 给 apk 增加控制蓝牙的命令接口
2. 把更新后的 apk 放到 appium/build/settings_apk/settings_apk-debug.apk
3. 脚本中通过 adb 命令启动这个 apk 来开关蓝牙

• 方案二（开发量相对多一些，但封装到了 appium server 中，更方便所有人使用）：

1. 给 apk 增加控制蓝牙的命令接口
2. 把更新后的 apk 放到 appium/build/settings_apk/settings_apk-debug.apk
3. 更新 appium server 相关代码，增加控制蓝牙开关的 api（主要修改 appium/lib/devices/android/android-common.js 和 appium-adb 的 appium-adb/lib/adb.js）
4. 更新 appium client 相关代码，增加控制蓝牙开关的 api 。

建议先用方案一，稳定后再做方案二的后两步吧。主要的重点难点都在 apk 和 adb 命令那里。

appium 设定 network 是通过 settings.apk 设定的，它的项目地址是 https://github.com/appium/io.appium.settings

虽然要求有点高，但如果你懂得基本的 android app 开发的话可以把它写到这个 app 里。
相关的文章http://blog.csdn.net/stevenhu_223/article/details/9052083

我去看了下 Java 客户端的 setNetworkConnection 的用法

https://github.com/appium/java-client/blob/48813418248be00dc3ca4af9821bb07dd01ab38a/src/test/java/io/appium/java_client/android/AndroidDriverTest.java

public void networkConnectionTest() {
  NetworkConnectionSetting networkConnection = new NetworkConnectionSetting(false, true, true);

  networkConnection.setData(false);
  networkConnection.setWifi(false);


  driver.setNetworkConnection(networkConnection);
  networkConnection = driver.getNetworkConnection();

  assertEquals(new NetworkConnectionSetting(false, false, false), networkConnection);

}

用起来和 python 版的一样啊，三个值分别代表数据连接、wifi 和飞行模式。
没见到有控制蓝牙的功能。