应该是命令超时, 网络不稳定导致的. appium --help |grep timeout 可以看看他的几个超时设置参数. 修改大一些.
总体来说, 基于 uiautomator 没有基于插桩稳定, 所以建议使用插桩框架, 比如 appium on selendroid 或者 robotium, monkeytalk 这种.

#3 楼 @sunrise 楼下有个找男朋友的 (^_)

当然也有可能是我理解错了. 这是和群里的朋友讨论的结果
觉得不错, 也分享给楼主..

谢国文-Pactera 2014/12/31 13:45:45
这个是 QA，不是 tester 了，不过创业公司测试都少，更不要说 QA 了
Monkey－alipay 2014/12/31 13:46:25
是啊。＝ ＝
Monkey－alipay 2014/12/31 13:46:29
所以我第一个就在问。。
Monkey－alipay 2014/12/31 13:46:34
怎么会讨论 QA 呢
13:51:57
言笑-Testin 2014/12/31 13:51:57
QA 真是高大上的职位啊
谢国文-Pactera 2014/12/31 13:52:54
我刚毕业 1,2 年的目标～～～
谢国文-Pactera 2014/12/31 13:53:14
一般搞认证的公司会有这样部门，敏捷类的基本不会有了
13:56:44
Sunrise Sunset 2014/12/31 13:56:44
其实文章提到的几个方面还主要是开发设计的范畴，确实不是 tester 的工作，其中主要的类似关键会议记录，执行追踪，需求管理不在敏捷迭代中进行，但是不做这些反而会让客户的需求失控；文档和代码规范书写觉得应该就是开发需要日常工作的下意识做法，否则后续开发维护很难进行，这个跟敏捷不冲突啊？这些都不是测试的工作但是属于 QA

言笑-Testin 2014/12/31 13:57:43
我怎么觉得是属于产品经理的范畴
Sunrise Sunset 2014/12/31 13:58:26
产品经理偏重于交付的成果
Sunrise Sunset 2014/12/31 13:58:38
中间产物反而不是很在意
13:59:27
言笑-Testin 2014/12/31 13:59:27
进度管理和迭代成果的验收, 他们应该关心吧. 还有跟客户的沟通.
Sunrise Sunset 2014/12/31 13:59:47
以前遇到一些敏捷项目因为前续的项目什么文档都没有，代码没有注释，所以接口都是处于猜测状态试错

言笑-Testin 2014/12/31 13:59:53
好像产品经理才是整个过程中最紧盯的人
Sunrise Sunset 2014/12/31 14:00:38
项目进展极其艰难，交付期总是失败
Sunrise Sunset 2014/12/31 14:01:23
虽然客户很理解，但是觉得很多时候我们把规范的东西跟敏捷对立了
14:01:36
Sunrise Sunset 2014/12/31 14:01:36
一时敏捷，一世糊涂
14:05:22
Sunrise Sunset 2014/12/31 14:05:22
长线产品和短期交付的矛盾在敏捷方法中经常处于交锋状态，关键核心部件的设计，用户宽容度很低的产品，敏捷面临的风险极大
14:07:36
言笑-Testin 2014/12/31 14:07:36
我觉得好像也不是敏捷的错吧. 敏捷也不是不写文档.

言笑-Testin 2014/12/31 14:08:02
最近公司请了一个技术牛人, 是 apache 项目的维护者

言笑-Testin 2014/12/31 14:08:23
目前是 remote 工作方式
Sunrise Sunset 2014/12/31 14:08:25
我们很多产品其实都是短消费产品，用户都不知道你的产品究竟要达到的目标，即使有些小毛病也会忽略掉，但是比如关键商务，物流，资财的管理宽容度极低，基本不允许出错，这类软件系统需要更高质量需要更好架构

言笑-Testin 2014/12/31 14:09:13
他们使用的方式是 jira+git 他们对 jira 中的每个 issue 要求很高, 等价于敏捷钟的 backlog 吧.
Sunrise Sunset 2014/12/31 14:09:20
敏捷其实特别适合牛人工作
14:09:56
言笑-Testin 2014/12/31 14:09:56
他们对提交的问题, 要做的事情, 有很强的规范. 还要每个 commit 都要对应到功能.

言笑-Testin 2014/12/31 14:10:09
基本上 issue 列表就已经是功能文档了
Sunrise Sunset 2014/12/31 14:10:29
尤其是技术高超，习惯良好的团队，效率极高，这也是当初为啥那些 17 个人提出敏捷的原因，因为个个都是牛人，每个人都有自己的敏捷方案
Sunrise Sunset 2014/12/31 14:11:46
其实能够写出言简意赅的 story 本身就很不容易，还不引起歧义，我看文章中不太赞同过多形容词，其实也是血泪的教训
14:12:41
Sunrise Sunset 2014/12/31 14:12:41
文章不是高大上的那种，但是能看出来确实是实践中得出的教训
14:15:16
Sunrise Sunset 2014/12/31 14:15:16
敏捷我觉得是个过渡的方法论，需要另外一个东西替代它，兼顾短期交付和长期的架构设计

#13 楼 @monkey 自己分析用 R, 搞定了数据分析, 剩下的产品化就可以转成 js 来展现. 大多数人都是使用 R 做内部的分析和报告. js 的方式适合做成更强大的产品.

里面提到的一些管理细节其实都是不错的实践. 不过公司衡量 QA 的价值, 不在于流程有多细致.
而是在于是否可以加速产品迭代, 提升产品质量, 降低整体成本. 如果没有具体的测试过程和技术保证, 就很难 hold 住产品和研发

写了这么多真心不容易, 感谢对论坛的支持.

说实话 51testing 更喜欢这类的文章.
好像通篇都在介绍高大上的管理理论, 这些理论适合在大公司和传统公司搞管理. 但是很难适应创业公司.
真正的管理是要根据团队的情况去制定适合的方案.

37signal 的那本书里曾经提到, 要招聘在一线工作的人, 招进来的不亲自负责实际工作的纯管理人员会把大量的精力运用在各种可以让他有展现自己地位的规划上, 其结果是管理, 流程繁杂无比. 而且开会也会是这类人的爱好.这会拖累一家公司的发展.

推荐你翻看下这本书. 我也一向不喜欢业界的各种假敏捷,
不过相对于你目前的理论. 我还是觉得你应该看看敏捷类的实践.

当然如果身处传统的公司, 也只有这么做才能保住 QA 的重要性和地位了....

#6 楼 @lihuazhang 没有. 他只是绘图展示信息, 并不再看重美化效果. 而且也不具备交互效果. 只是静态图.
R 语言自己可以输出特定的格式来跟 d3, google map 之类的 api 交互, 网上有人写了不少扩展来实现和 D3 的融合.
R 本身还是偏科学计算和基础的信息表达.

#8 楼 @sgq1117 厉害. 多练习下就行了 我今年又打算再入手四本高级版的书.

#9 楼 @monkey 我觉得它和 awk 很像. awk 是基于行串行的字段处理. R 是基于列计算的统计软件. 语法也都是类 C 的. 只是 R 多了一个图形功能.

有代码吗

实践证明, 测试用例才是最好的演示例子和文档.

应该是需要用到递归算法.

我记得之前有个同学发帖子提过自己扩展 appium 来实现

很不错的高阶职位, 推荐高手关注

#1 楼 @link1220 我也有同样的强迫症.

@ellaw @kidloving 你们都遇到过?

我看是 2 个 error. 先试试把安装目录放到没有空格的目录下试试.

#15 楼 @weamylady 恩, 忘记说了, 用户覆盖度的确是很重要的.

通过 SurfaceFlinger 句柄变化跟踪显示状态变化收集时间变化
这个方法挺新颖. 不错

#10 楼 @lihuazhang 这块的坑不是一般的大啊.

我在新秀群和行业人脉群分享了今年 TestDroid 发布的那个如何搭建测试实验室的文档. 你可以参考下.
主要是如下几个方面的管理工作要做好

测试管理平台

appium calabash robotium 都有不错的管理框架了. 可以用起来.
这些框架本身都不太稳定. 所以还需要自己稍微完善下.
另外就是测试用例的下发,结果的收集之类的. 细节的工作非常多.

测试设备管理

市面上的设备你需要知道如何去挑选才能做好的覆盖.

设备的兼容性主要是分几个维度.
UI 兼容性问题
硬件兼容性问题
软件兼容性问题

UI 兼容性问题大部分是布局不合理导致的. 屏幕尺寸不同, 很多开发考虑的较少. 所以不同分辨率的设备最好买齐.
h5 的兼容性测试一部分基本可以通过小 A 提到的方法去测试. 简单有效.

硬件的兼容性问题就太多了, 主要是跟硬件的 CPU GPU MEM 等几个因素强相关. 这方面需要有个合理的覆盖.
CPU 和 GPU 的型号存在很多类型, 这也是决定手机价格的一个因素. 这部分数据很难收集, 貌似目前只有 Testin 有相对全面的数据.
GPU 对游戏的影响较大, 游戏的关键区域会出现丢帧, 纹理渲染不理想, 颜色变化等.
CPU 影响运行速度甚至是运行特性, 位数的差异需要特别关注.
CPU 的型号不太多, 只有六七种. 但是 GPU 的型号非常多. 如果不是开发游戏, GPU 可以稍微忽略.
MEM 和磁卡大小会影响运行稳定性和安装卸载的一些问题
其他的一些硬件也会偶尔影响.

大部分的设别都不会按照理想状态工作, 总会出现各种问题, 比如磁盘满, wifi 信号不稳定, 内存占用导致的不稳定 OOM, 安装卸载终端导致的环境不干净 电池烧掉等等. 除非你们设别少, 不然这个管理成本还是不小的.
设备多了, 问题也会逐渐增多.

所以给你的建议是, 先不要搞太多设备, 但是设备的覆盖要足够优良.
更多的设备仍然使用云测服务.

#6 楼 @yangchengtest 你估计没用过 appium calabash 吧. 只有 robotium 依赖于 android, 其他的 android 测试框架基本不完全依赖 android 等. 他们在 pc 上运行, 丝毫不影响 android 的测试用例.

#3 楼 @yangchengtest 不用在 android 平台上跑, 把图片传回到 pc 上对比就行了. opencv 是个很强大的工具. 好像用法太多了, 反而不知道如何使用了. @weamylady 能给论坛上的兄弟们科普下吗

把所有的图片都搞下来进行对比就行.
跟 robotium 无关. 你可以让研发给你写个对比的工具. 对比清晰度和图片的相似度.

4.2 版本应该是 api18 了吧. 你用的 appium 版本是多少, 我还没研究最新的框架.