• #2 楼 @xdf 赞,server 和 client 通信的具体 json 字段能不能贴了看看?另外 client 这边查找元素是否支持 xpath?如果支持,是使用 uiselector 来实现类 xpath 的逻辑还是 dump xml 来做?

  • App 自动遍历工具初版 at 2016年03月20日

    赞赞!。有几个问题想问一下,问题比较多,多包涵。

    1. 如果 activity 中元素是变化的,即点击或其他后出现了新的元素,遍历是否能遍历到这些元素并进行相应操作?
    2. 如果 1 可以,当前 activity 的 md5 发生变化后,工具认为是新的 activity 还是旧的?后续遍历是否还是进入该 activity?
    3. 业务逻辑中如果发生 activity 跳转,即 原先路径为 A->B->C, C 中的某个业务触发后发生了 C->A,此时 B 的遍历是否还会继续?
    4. 业务中有可能会发生完全一模一样的界面,且 activity 名称相同,我们的工具是如何来区别这 2 个功能页面的?
    5. 当前性能如何?遍历一个 app 大致需要多少时间?
    6. 如果出现类似扫码和拍照界面,我们是继续操作还是跳出?
    7. 如果 6 成立,发生了类似"从相册中选择"的事件,是否支持切换回被测应用?
    8. 具体遍历时,在 Android 上如果需要有滚屏去显示更多的元素并针对这些元素进行操作,是否支持类似的遍历?
  • 这个赞啊

  • 是重写了 bootstrap 吗?部署在 Docker 上是 emulator?

  • 又见遍历..上次说整理的结果一直到现在还没有弄。整个遍历的困难点就在于 “当前页面是否来过,从哪里开始”。 LZ 所说的 “以当前 Activity 名称为 Key 保存到 JSON(A)中,如果当前页面布局信息已经保存,则读取 JSON(A)数据获得当前页面的元素,”, 实际使用中会碰到完全一模一样的 activity, 则无法根据布局来判断页面是否保存过。 正如@seveniruby所说, 做树形结构是比较稳妥的方案,缺点是判断比较多,实现起来不是简单的迭代,最后落地跑起来发现运行速度比较慢。个人比较推荐根据自己的模型来计算当前页面 hashcode,作为 key 将个页面对象保存在一个容器中,每次发生页面变化则重新计算 hashcode 来判断当前是新 activity 还是旧 activity。

  • 自动化测试的困惑 at 2016年01月17日

    其实就是一句话。兵熊熊一个,将熊熊一窝。取决于有拍板权的人的思维高度。

  • #10 楼 @lihuazhang
    可以的,找个时间整理一下。目前算法还有些恶心的逻辑,正好大家可以帮忙改进下。

  • #7 楼 @seveniruby
    赞,我们花了近 2 周才完成遍历算法。深度遍历很有挑战。

  • 没有仔细看脚本。但是有个问题,monkey 的随机测试很多情况下都是无效的操作,有效操作的分布也是不可控的,这个如何来衡量你的压力测试是有效的?

  • 详解 Android 耗电量 API at 2015年10月26日

    有没有计算耗电量和接近理想状态下的实际耗电量的比较?

  • 类似的框架几年前开发过几个,业界其他公司包括去年在淘宝的测试嘉年华看到阿里系也有类似的框架。xml 也好,其他类似的关键字驱动框架也好,在灵活性和适应性上都有比较大的问题,例如如何来做数据库数据的验证,如何灵活的来做断言等等,解决好自定义标签才能使这种类型的框架脱胎换骨,淘宝的,包括我自己开发的都没有很好的解决这个问题。搞到最后发现还是直接写代码合适一点。

  • 是个不错的创新!

  • 封装对象后重写 equals 方法。https://testerhome.com/topics/2843
    具体实现看自己的需求了。

  • @lanxiangtechnical 的确是的,需要自己来实现。

  • @springs412 我们也有类似性能参数的收集,思路也有点类似。lz 如何解决 ios 的性能参数收集?

  • @xdlhy 框架中开发的是常用移动端测试的接口, Android 和 ios 各有自己的实现类, 框架会自行识别当前的运行环境 (真机/模拟器, ios/android, 环境配置在 properties 文件中, 可遍历执行.) 来判断具体使用哪个实现类. 所以测试代码在不同平台上使用的是同一套接口也就不需要写 2 套代码了. 维护比较方便.

  • 似乎是没找到超时了. 看看适当延长 wait 的时间, 或者在 activity 开启之后加个 sleep 看看是否能稳定查找到.

  • Docker 的技术可以运用于快速创建定制化的测试环境, 另外可以结合 Grid 来部署分布式测试. 赞!

  • page object 最大的问题是在于多租户的情况下如何管理你的页面对象, 如果 LZ 做的是通用 web 测试框架的话, 那需要把多租户的情况考虑进去, 不同的租户在某些功能模块或多或少会有不同的情况. 另外, 在多租户的情况下, 针对每个租户的 smoke test 或者 regression 也要考虑进去.

    还有一点就是, 在目前的互联网趋势下, 如果有条件的话可能需要考虑自动定位页面元素的情况. 原因是 1) 针对开发的频繁修改 2) web 自动化测试框架可以用于有些爬虫数据的验证, 同时爬虫最大的问题是页面改版, 智能定位查找可以有效地处理这些情况.

    总体来说 web 自动化测试框架要比移动端的复杂的多. 我们都在前进的道路上...