#2 楼 @chenhengjie123
waitForElement(By.partialLinkText("Your Toast message"), 4, driver);
可以看看他的实现

按照百分比滑动是跟通用的好方法. 千万不要写死一些具体数据.

#1 楼 @lucasluo 写的很用心. 赞一个. 这是第二篇了

第一段是说质量意识. 但是质量意识是什么, 没有细节说明.
只是隐约的提到两个测试的理念. 站在用户角度, 和基于风险的策略.
第二段是说质量的实践, 测试需要较好的文档和 bug 描述细节. 这个我就不太赞同. 大家可以讨论.
第三段是说测试策略,讲到了策略的复杂和工具使用. 如何肢解复杂的方法论都没提.

以上内容深度不够. 仍然是泛泛而谈, 所以没有加精. 十年前测试经典书籍里面基本也是这些理论.
有些理论也不太对, 已经偏离实践了.

我不同意你的观点, 但我会誓死捍卫你说话的权利.

selendroid 貌似已经支持了 有个 api

webview 是标准实现吗. 还是自定义的方案? 所有版本都不能获得 webview 挺奇怪. 感觉更像是跟你的 app 相关

appium 里面就有了这样的功能了. robotium 偏底层没有这功能. 你需要自己借助 adb 去搞下. 大部分情况不会有问题.

#15 楼 @cpfeng0124 是的, 都是真机, 没有模拟器.

#8 楼 @anonymous 有些操作不一定非是特殊操作引起的. 特殊的环境也可能会触发. 首先你得收集这些崩溃分析, 看看是什么地方的代码崩溃了, 然后基本就可以猜测出是什么操作或者什么场景出了问题. 一般的崩溃分析产品都已经提供了对应的 crash 收集和分析功能了. 可以直接拿来分析. 最简单的方式, 你可以自己嵌入进去 sdk 然后利用云端的分析直接报 bug.

#7 楼 @mingway_hu 我看过听云那个白皮书, 只是个噱头.里面泛泛而谈. 里面的数据很多都不是来自于他们. 我们公司也是只顾着做产品, 技术的一些宣传和数据分析一直为对外正式的宣传. 我不知道移动端他们的什么时候会对外发布.

今天看到有一些网站已经转载了这个文章了

建议你们直接使用崩溃分析产品, 让研发和老大们看看有多少用户会出现崩溃, 这是涉及到钱的问题, 知道数据后他们就不敢拖了. 可以试试我们公司的产品 mobile.oneapm.com.

appium 本来就是命令行运行的, 跟 selenium 集成到 jenkins 是一样的

好文， 感谢转发。 目前好像可以精准统计 app 耗电量的云服务还没有

上海的创业公司也越来越多了。 而且很多都还是很有创意的公司。

appium 有个 scroll_to 方法 ruby 里面有， 不知道 python 里面是否有， 你可要看看

楼主可以匿名讲讲自动化过程中遇到的问题. 先别如此消极. 也许大家伙可以帮忙出出主意.

说实话, 心路历程就这么点. 而且只有结论, 连个例子也没有...鼓励小而美的文章, 不过这个只是小, 不美.
期待楼主下次的分享.

你自己试着读下那个文件, 看看存不存在

#4 楼 @monkey 现在还缺个工具, 可以截获 intent 并直接返回期望的结果, 这种方法叫 intent mock. 这是最外层的办法. 从 google 的测试思维来说, 他们更希望是不依赖太多外部的部件. 从内部也有办法. 侵入式也是可以考虑的.

类似于 mock 的思路, 你自己写个 app, 然后接受调用摄像头的操作, 直接返回一个图片即可.
然后把自己的 app 列为摄像头调用的首选 app 即可.

最近很火的公司啊. 你是猎头还是公司员工?

#32 楼 @hiahia 估计是为了架构, 让两个 driver 继承自公共特性的 appiumdriver

#3 楼 @eurekasaber monkey 太没有规律了, google 的本意是用来做界面的压力测试和健壮性测试. 他可以发出很多的 event 来验证 activity 的消息处理机制. 也可以验证 app 自身的逻辑处理是否健壮. 最好是借助其他的方法进入各个界面, 进行自定义的控制, 然后再调用 monkey. 这样可以更好的控制你的 app 跳转逻辑. 比如不进入某个界面, 不点击某个按钮之类的.

期待能有一些接好 cydia 的资料, 他们好像是放出来一个 substrate 超级牛的工具, 可以 hook 手机上的很多 api 调用做破解.