• cocos unity 需要根据引擎自己去设计自动化框架。可以做个跟 appium 兼容的 agent。 从而实现各种自动化。参考 selendroid 的模式。

  • Appium 主从远程控制执行 at 2015年04月28日

    #27 楼 @cywin @lihuazhang @testly 我有时候觉得反过来反而更好。 agent 不是接受请求, 而是主动去连接询问是否有要求。这样的架构可以突破网络限制。

  • 文中提到的端到端测试的缺点

    团队延迟了一周才达到他们的里程碑(并且加了不少班)。

    原因没说, 估计就是下面的这些原因。

    寻找导致端到端测试失败的问题根源非常痛苦且花时间。

    如果测试部门也能用上淘宝鹰眼或者 twtter 的 zipkin, 我觉得排查问题会少很多时间。
    商业产品也有了, 比如 newrelic, oneapm 等。这些产品都是来自于 google 的论文和内部产品。
    为什么 google 测试部门没有用起来, 表示疑惑。

    搭档团队环境的问题和实验室问题导致的失败出现了好几天。

    搭档团队环境出了问题, 这个有几种解法。
    通过接口测试, stub 来替换有问题的模块
    使用可用的老版本替换
    分层测试

    在大的 bug 后面还隐藏着很多小的 bug

    这个端到端测试的确是搞不定的。 需要做好针对模块的特定测试。端到端的测试不能测试完全。
    需要结合测试建模,或者一定的白盒和黑盒的探索测试。

    端到端测试中有几次由于碎片导致结果不稳定。

    这类问题是无解的。需要分层测试。后端总有一些超时或者网络拥塞,或者磁盘满。
    我的建议是这些不稳定的 case 同样也是非常重要的测试场景数据。不稳定也具备参考价值。让你了解真实的系统表现。

    开发需要等到第二天才能知道自己的 fix 是否正确。

    整体的测试的确会很慢, 需要分层测试来解决。搭建环境也很费劲。 我推荐用 docker vagrant 这类工具来解决环境问题。
    如果是持续交付或者持续集成的环境。 速度应该很快。

    我的看法

    1. 端到端测试可以发现很多问题。他能模拟比较真实的环境。可以建立一些业务模型。让所有人熟悉业务流。
    2. 端到端测试可以用来反推各个模块的测试。 比如录制各个模块之间的交互。 自动生成对应的接口测试。 单元测试理论也可以自动生成, 不过这种后补的单测没有太大意义,不符合单测的定位。
    3. 比如有一些非常零散的多模块通过端到端测试可以较为理想的覆盖他们。而不用去考虑各种复杂的接口拆解。可以省一些时间。 所以我总体上赞同 google 的观点。 但是我喜欢端到端测试。觉得他的比重应该高一些。70% 的单测我相信中国 99% 的团队都达不到。在研发人员质量参差不齐的情况下。 他们的单测根本靠不住。 所以集成测试和端到端测试应该成为国内测试人员重点关注的领域。除此之外一些专项测试也是非常有必要的。

    端到端测试工具的支持

    1. 环境管理工具。 vagrant docker
    2. Trace 技术。比如覆盖率工具, Trace 和 Debug 工具。 我赞同 Trace,不太喜欢 debug
    3. 监控平台。Twitter 的 zipkin,淘宝鹰眼,京东和去哪儿也有类似的各种系统。 推荐看看 ZipKin。 商业工具主要是 newrelic,oneapm。开源的 ELK 组合技术栈 Logstash+ElasticSearch+Kibana
    4. 持续集成和持续交付
    5. 接口测试。利用端到端测试的场景。慢慢积累起来业务模型和接口测试体系

    没有良好的工具支撑,端到端测试这种复杂测试场景是没法管理好的。

  • 推荐. 很好的高级机会.

  • 先确定慢在什么地方吧. 然后再决定如何优化. appium 整体的确是慢的.

  • #12 楼 @anonymous 大部分的帖子基本都回了, 这说明大家对小白还是很耐心的. 一些低质量的问题 ,或者不懂提问的帖子尽量删掉. 这些小白半年后也会成为不错的人才. 大家多包容.

  • 福利挺好

  • 比 jmeter 好在哪?
    我之前试验过 gating. 但是功能还不太完善. 所以还是坚定的回到了 jmeter.
    不过 gating 本身的确做的挺好的.

  • 有胆量给到 30K 的公司都是好公司. 比如美团. 这代表了对人才的重视和岗位的重视. 推荐
    衣食住行是硬需求, 是可以搞一百年的事业.

  • #2 楼 @chenhengjie123 从内部测试最稳定可靠. 是可依赖的. espresso 也不错, 不过这个框架没太多亮点.

  • uiautomator 做测试不稳定, 没有 selendroid 模式好. 大部分的 case 还是应该基于 selendroid. 少部分跨 app 场景可以交给 uiautomator

  • #3 楼 @gitcafe 赞赞赞, 我们也要报名

  • #10 楼 @paris_love_u 用 docker 就行, 一个命令就起来了

  • #8 楼 @oscarxie 现在数据行业很火啊, 大数据和数据分析很流行

  • 这家公司貌似挺牛逼 昨天问了一些 docker 圈子里面的人, 有人就提到用的这个商业产品

  • redmine 很不错啊

  • Appium 测试,遇到签名异常 at 2015年04月13日

    你从哪看到了签名异常?

  • Appium 主从远程控制执行 at 2015年04月13日

    #3 楼 @testly adb 本来就是可以控制多个手机的. 反弹端口是一种形式 用 *** 让所有的手机和电脑处于同一局域网也可以.

  • Appium 主从远程控制执行 at 2015年04月13日

    你终于发现了啊. 楼主是第一个发现这个技巧并分享出来的人, 赞
    我希望可以做的更好些. 比如把测试用例编译到 app 中, 然后手机上运行, selendroid 貌似是可以做到的. 这样可以绕过 tcp 传输 更稳定. 不过这个难度太大. 相当于安装卸载基本已经无法控制了. 或者要失效

    还有一个疯狂的想法是把所有的 android 的 4723 端口反弹到云端的服务器上. 然后用 adb connect 所有的端口, 最后通过一个 appium 来控制. 我干过, 可行.

  • 测试之我见 (二) at 2015年04月13日

    #17 楼 @xhk1 传统公司走这条路是对的.

  • #3 楼 @kasi accessibility api 是不是也可以抓取到, 试过没?

  • #8 楼 @chenhengjie123 @monkey 我是怀疑这个方法的有效性. 可以实验下. 我自己没验证.