官方的说明是指 api17 以上, 不包括 api17. 你可以用 api18 试试. 这个错误前几天有人发过帖子讨论了
就是这个错误
java.lang.NoClassDefFoundError: com.android.uiautomator.core.Configurator

#5 楼 @weamylady 签名保护可以有办法绕过. 而且自己用公司的签名重签也没事. 主要是考虑到有些公司不会开放源代码给测试人员, 这种情况会影响插码框架的推广.

#1 楼 @lihuazhang 有一个 monkeytalk 系列可以出来了. 不错.
我今天还特意下载了他们的工具看了下, 觉得做的还是不错的. 我在想他的 monkeytalkIDE 录制工具, 也许可以改造为 appium, 为 appium 做服务. 比如直接把他的脚本格式转化为 appium 的.

另外就是对插码方式不太满意, 虽然插码是主流, 不过这个工作如果可以自动化, 就非常好. 从官方的步骤来看, 应该是可以自动化的. 我也是刚开始研究.

我挺看好这个工具的, 商业化工具的易用度和稳定还是可以保证的.
我关心的是他的不插码方式. 那个应该可以减少不少的工作量. 我记得 pro 版本里面有.
不知道你试过了没有..

前阵子你说过要发文章, 果然发分享了. 赞一下

大家对你的行为还是支持的, 只是表示下担心和忧虑.

写的大气磅礴.

重新做一套框架有助于提升你对其他框架的理解能力. 并提升你们对测试的把握度.
不过我仍然劝你慎重的做这件事情.

开源不只是开放源代码. 他代表一种产品, 服务和协作方式.

当你信心百倍的去打算创造新事物的时候, 你得自己想好如下可能面临的坑

1. 你的项目是否比别的同类型项目优秀, 根据你目前列举的点, 已经有框架比你的还优秀了.
2. 你的产品解决了一些问题是不是会带来更多问题.
3. 你是否有足够的资源, 精力和坚持去做要做的事情
4. 创造一个东西很容易, 但是打磨好它, 做好支持却是最重的工作量
5. 产品不是理论, 他需要细节的 feature 来支撑, 如果你不能在细节上具备钻研的能力, 你的产品必然会遇到问题. 就算是较高级别的抽象层也是有很多细节需要完善的.

我估计从业的年龄不超过 5 年吧.

#10 楼 @ww32245420 uiautomator 的确是启动超时了, 得排查下原因

#8 楼 @ww32245420 对于 api17 这个特殊的版本, appium 支持的不积极. 好像它只允许 api17 以上的, 如果是 api17 也会提示不支持. 最好使用以上的版本.

robotium 还不是完全面向对象的. 我更喜欢 Cafe

#13 楼 @nansen rft 里面有个 appium-lib 已经开源了. 在官方的 appium 里面有例子

#15 楼 @qddegtya 是的, 有很多工作其实用逻辑思维, 可以避免的.

#12 楼 @xie_0723 这个点赞方式我喜欢. 可以在论坛提倡. 纯 web app 的测试, 可以不用 appium 了. 这种方式更轻量级.

写的太赞了. 赶紧占住广告位.

我这边补刀下.
优点

1. 这个方法基于 chrome, 可以便捷的识别跨尺寸的兼容问题. 简直就可以分分钟帮企业做个自动化服务了.
2. 获取响应速度的瀑布流图也非常的容易. 很容易做性能测试和瓶颈分析

缺点

1. 方法基于 chrome 引擎, 考虑到不同浏览器的版本, 以及不同设备上浏览器引擎差异, 所以有些 css 的兼容性问题仍然需要验证. 所以尺寸兼容性可以解决, 但是设备的兼容性测试仍然需要做. 好消息是大部分企业的 h5 一般都是布局不合理占多数.

bluestacks 是最好的, 安装也很容易. 你检查过安装不上的原因了吗

#1 楼 @wensj 开启下调试吧, 看看鼠标的轨迹. iOS 的我没研究过, android 是可以跟踪鼠标轨迹的. 看看什么地方越界就清楚了

#5 楼 @gaoxing200851 共享库分两种 一种是自身带的共享库, 比如 QQ 百度地图都自带了自己的 so 文件. 这个大小应该计算到自身的内存中, 需要关注. 而系统的共享库就不用统计在内了.
一般不用在意的这么严格. app 因为内存不足被 android OOM 杀掉的情况很多, 这类的场景测试覆盖了就没太大问题. 相信一般的 app 内存占用还不是大. 现在的场景都是很碎片化的. app 被不停的前后台切换. 偶尔还会别系统回收掉.

当对于这个愤慨的楼主, 我是个温和的人. 呵呵, 给处于发芽期的同学如下的建议.

扎实的学习技术

当你要去测试产品时, 你要比产品更细致, 比研发更了解技术陷阱. 任何一种语言平台的技术栈都不是太大. 扎扎实实的去学就可以了. 这会为你的未来打下很好的基础.
所以系列的读几本某个语言的系列书籍, 然后自己动手去写代码联系就可以了. 实践是加深记忆和技能掌握程度的最佳方式.
遇到问题, 先记录. 先把真个体系阅览一遍. 之前的很多问题就会迎刃而解. 忍不住的问题也可以先问 Google
不要妄想不懂技术去测试一个产品. 业界有大佬一直吹嘘站在用户角度去思考问题. 那其实只是一个维度, 不是基础. 就好比你不了解牛奶加工机制和环节, 就无法通过用户角度品尝牛奶来分辨出是否含有三聚氰胺.

不懂先问 Google

养成每天使用搜索引擎的习惯. 不懂的事情先问 Google, Bing 然后是百度.
我是百度公司出来的, 但是我不会向你推荐百度. 因为当你对明星八卦感兴趣的时候, 百度是你的好助手. 当你决定投身于专业领域的时候, 百度就是个渣
如果你说因为墙的问题无法访问, 论坛也已经提供了墙翻的方法让你畅快的使用 Google 了.
我每天也都在不停的使用 Google 来提问并获取新知识.

实践过后想不到办法, 欢迎来论坛发帖.

基本上认真思考仍然得不到解答的帖子, 我都是争取每个都回. 除非我自己也不会.
首先自己要认真的实践和思考.动不动就挂上如题之类的不负责任的回答, 基本都被删帖了.
希望发帖的同学都是很严谨的工程师思维. 而不是随性的提问.

TesterHome 的愿景

当初我们搭建 testerhome, 其实就为了能专注研究交流些技术，最好能有些深度.
我不想让业界的人一听说测试工程师, 脑子里面就会浮现出一群只会用鼠标的人.

当你懂代码的时候, 公司会把代码开放给你,当你不懂的时候, 你问的每个问题连自己都会不自信.
连美国总统奥巴马都在号召全民学编程, 包括他自己都有自己的 github 主页.
所以作为新手, 就不要纠结于要不要学技术, 做管理是不是就可以不用接触技术之类的想法了
.
我们希望 testerhome 可以走出去一个个的技术精英和测试专家, 而不是被谬论洗脑的一个个官僚.
我们欢迎的是热爱测试, 热爱技术, 热爱产品的人,

testin 上提供的 PSS 数据 百度和腾讯提供的好像是 RSS

Calabash 框架的底层细节, 好像了解的人不错. 整个框架的机制有时间也可以给大家普及下.

写的非常的细致详细. 堪称好贴典范啊.

RSS 较大并且不是优先级别较高的进程, 很容易被配置低的系统给 kill 掉.
这个还是要关注的.