• WebDriverAgent 踩坑记 at 2016年07月08日

    #14 楼 @codeskyblue 请求大概长这样:

    curl -X POST $JSON_HEADER \
    -d "{\"x\":\"10\",\"y\":\"20\"}" \
    $DEVICE_URL/session/$SESSION_ID/tap/5
    

    末尾的 5 是 element id 。如果根据 element id 能找到元素,那么 x, y 会被当做是元素左上角坐标的偏移量。如果找不到(例如给个-1),那么会当做屏幕的坐标。

    详细源码在WebDriverAgent/WebDriverAgentLib/Commands/FBElementCommands.m 里面。官方的 Queries 文档只列出了所有命令中的 70% 左右。

    有空的时候我试下用 Jmeter 录制下我的 python-client 测试过程中所有请求给你吧,我实现了大约 85% 的命令。

  • 步骤有点多,如果有提供一个 Docker 镜像就更好了。

  • 感谢 UCloud 助力 TesterHome at 2016年07月07日

    什么是最好的后背,就是你只需勇往直前。

    这句赞~ 感谢 UCloud 。

  • #3 楼 @lrw3716740 可以手动导出成你需要的格式:https://www.wireshark.org/docs/wsug_html_chunked/ChIOSaveSection.html,命令行的话估计也有,你找下。

  • 我们以前做过,先给个不 release 的 touchAction 方法,如 press->wait->perform,让它按住不放手。然后通过 findElement 找到垃圾桶控件坐标。最后再来个 longPress->moveTo->release->perform

    不过好久没用了,不知道现在是否还能用。

  • 我觉得这个报告挺好,但缺少了一个重点。如 monkey 所说,先要知道目的,然后才能找到优化点。

    我们的测试组比较小,没有像你们这么详细的报告。我们的目的是让老大们了解我们做了什么,和需要他们帮忙关注/推动的点。主要只是报告各项目测试进度、延期情况以及延期原因。

    bug 情况这些没有写上去,因为老大们也不会关心这么细的数据。如果真要写,主要也是写趋势,单纯数字的话很难表达清楚背后的含义(质量提升/降低?效率提升/降低?)

  • #5 楼 @superbaby11 感觉你这个内容和这个帖子关系不大,建议你另外开一个帖子并附上测试环境、测试脚本、 server log 等相应信息吧。

  • Ant+JMeter+WebDriverAgent 游记 at 2016年07月06日

    #6 楼 @watman 嗯,我主要感兴趣的是通过这种方式了解不同请求在不同配置机器上的耗时,这样就能出一个 benchmark 之类的东西,更有针对性地进行测试机型选型和脚本优化了。

  • Ant+JMeter+WebDriverAgent 游记 at 2016年07月06日

    思路很新颖,同时我比较感兴趣的是目前 WebDriverAgent 各个 api 的执行效率(响应时间)。

    让我想到一个新玩法,搞个比较全的 WebDriverAgent api 测试集,然后分别在目前支持 iOS 9.3 的主要机型上跑一遍,看看 api 的性能如何,可以作为机型选型和以后 WebDriverAgent 性能优化的参考

  • 请先正确使用 markdown 。。。

    另外,我相信你试了 @hp_test 的方法后日志不会和帖子正文一样。你先确认下是不是确实试了之后错误日志还是和正文一样?

  • 开源项目启动倒计时 at 2016年07月06日

    #32 楼 @zhuzhuhoye 额,这已经是一年前的了,招募已结束,暂时没有新的招募计划。

  • #15 楼 @wg689 xcode 可以,一些第三方应用市场也可以。

    idevicesyslog 是 libimobiledevice 里面的一个组件,可以通过命令行工具直接调起

  • #13 楼 @wg689 看 8 楼。。。这是 iOS 系统 log ,你可以理解为等价于 android 的 logcat

  • #4 楼 @wangcityboy 你在正文里面补充下公司说明,也说明下为何公司邮箱后缀和你给到的公司名称不一致吧。

    补充后 @ 下我,我帮你移回去

  • #3 楼 @lilychow 如果是手动获取一些调试信息(如你说的 url),可以看下 各种 真机远程调试 方法 汇总,以及微信官方给的调试工具 http://bbs.mb.qq.com/thread-295889-1-1.html

    如果是用工具做 UI 自动化,我目前没听说哪个工具可以支持。

  • 之前已经屏蔽过了。。。公司招聘请用公司邮箱。

    另外,补充下公司说明也许会让大家对你的岗位更感兴趣哦。

    1. 你是安卓还是 iOS ?安卓的话无解,因为微信里面 webview 用的是 QQ 浏览器内核,appium 不支持。
    2. 能检测到 webview 的前提是代码里开了 webview 的 debug 开关。这个开关默认都是关的,你要让开发在代码里打开它。
  • 补充录屏 + 录音版的视频地址:http://pan.baidu.com/s/1bpmfwzt

  • 关于 iOS UI 自动化测试,来看下 TMQ 的这篇文章

    看完了 TMQ 的文章,确实不错。

  • 深圳第二期沙龙笔记 at 2016年07月04日
  • #4 楼 @stephen753 我觉得其实最终还是投入产出比的问题吧。

    另外,我觉得 @quqing 的这个方式成本有点高,毕竟原来一条 UI 自动化用例能完成的事情,现在变成 UI + 接口 + db ,而且覆盖度其实还是和 UI 的一致(例如接口中 request 缺少某些字段时服务端的处理,如果是在 UI 操作的话不一定能覆盖到)。对于这种情况我比较偏向于用 stub(挡板)的方式。

    举个例子:
    UI 的,不和服务器耦合,而是直接拦截它的请求,然后直接给对应的返回。因为这里我们关注的点在于 UI 的逻辑层,即界面操作最终的输出(request)是否正确,以及界面对于服务器响应数据的展现是否正确。

    接口的,就是单独的接口测试了。当然接口测试最好还是能直接触及到数据库,确认接口的逻辑是否正确,也方便多用例时用例间的相互影响。

    个人理解,分层覆盖的意思不仅仅是说不同层级之间用例的比例,关键点是每一层有自己单独的测试,也有合起来的系统测试。而且很明显的,系统测试的覆盖度会不如每一层自己的单独测试。

    至于覆盖度的衡量,在没有很好的方法的情况下,我觉得代码覆盖率是一个不错的参考指标。

    以上是一些个人观点,大家有不同意见也可提出~

  • #2 楼 @websky 我觉得恒温的意思是说把你看完第一点里面的那些文章后,自己的理解是如何的。

  • #7 楼 @fengcanfly 什么系统?出错日志?

    js.executeScript("mobile: scroll", scrollObject); 
    

    这个印象中 appium 早就废弃了?

  • 关键 log :

    info: [debug] [BOOTSTRAP] [debug] Attempting to clear using UiObject.clearText().
    info: [debug] Didn't get a new command in 30 secs, shutting down...
    info: Shutting down appium session
    info: [debug] Pressing the HOME button
    

    进行 clearText 的时候卡住了,但也没什么错误提示。。。
    建议你先试试换台设备,看还有没有问题。有可能是设备本身的问题。clearText 在界面上表现应该是长按输入框,全选所有内容,然后直接删除。

    PS:你的 xpath 有点奇怪,第一次见 contains(@index,5) 这种语法,一般都是直接 @index=5 或者直接就是 EditText[5]

  • #2 楼 @greenplum 那为什么加了之后会更稳定?主要是不明白这点。