测试驱动开发是个好东西，但是它需要以自动测试为前提，自动测试对于移动应用开发似乎太难了。不过UiAutomator其实是可以解决这个问题的，不过有些坑实在太难为人，其他一些问题，我以为还是有办法解决的，只要成本划算是可以做的。

界面改变导致测试用例失败

这个问题很常见，也是针对界面自动测试最为令人诟病的一点。但是我们只要考虑一下，界面改变其实是需求发生改变导致的，或者开发提出技术需求进行重构导致，那么如果我们要求每次提交都应该以自动测试用例通过为前提，付出一定维护代价是可以避免的。

这个代价也不会太大，只不过是修改几个界面ID而已，几百行代码都改了，几个界面ID改改能有多大带代价？用UiAutomator不过几分钟的工夫而已。

自动测试报假警告太多

如果这样的问题太多，确实是自动测试用例的致命问题，报告错误了查半天发现不是bug，而是测试代码写的不好导致，是十分伤害信心的。

这个问题只要把测试代码写好就行了，确实测试在这方面无能为力。可以通过要求开发来写测试代码来解决：1、如果做TDD，那么开发有义务写；2、开发写代码能力总比测试强（当然不排除有些开发强的有限）；3、开发是从白盒角度，可以看到逻辑的情况下写的，具备避免AB测试等逻辑问题的能力。

测试用例不稳定

有时候能成功，有时候不能成功，甚至半路停下来了。这种请更换手机，华为手机有这个毛病，小米、夏普手机运行非常稳定，没有任何问题，UiAutomator的可靠性是足以保证测试用例正常执行的。

写测试用例花太多时间

不多，一般做好几天的需求，测试用例连写带调试最多一个小时。