#14 楼 @codeskyblue 录好了,一个 jmeter 的,一个 charles 的。都放网盘了:http://pan.baidu.com/s/1slEdvBn
#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 。
#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 等相应信息吧。
思路很新颖,同时我比较感兴趣的是目前 WebDriverAgent 各个 api 的执行效率(响应时间)。
让我想到一个新玩法,搞个比较全的 WebDriverAgent api 测试集,然后分别在目前支持 iOS 9.3 的主要机型上跑一遍,看看 api 的性能如何,可以作为机型选型和以后 WebDriverAgent 性能优化的参考
请先正确使用 markdown 。。。
另外,我相信你试了 @hp_test 的方法后日志不会和帖子正文一样。你先确认下是不是确实试了之后错误日志还是和正文一样?
#32 楼 @zhuzhuhoye 额,这已经是一年前的了,招募已结束,暂时没有新的招募计划。
#4 楼 @wangcityboy 你在正文里面补充下公司说明,也说明下为何公司邮箱后缀和你给到的公司名称不一致吧。
补充后 @ 下我,我帮你移回去
#3 楼 @lilychow 如果是手动获取一些调试信息(如你说的 url),可以看下 各种 真机远程调试 方法 汇总,以及微信官方给的调试工具 http://bbs.mb.qq.com/thread-295889-1-1.html。
如果是用工具做 UI 自动化,我目前没听说哪个工具可以支持。
之前已经屏蔽过了。。。公司招聘请用公司邮箱。
另外,补充下公司说明也许会让大家对你的岗位更感兴趣哦。
补充录屏 + 录音版的视频地址:http://pan.baidu.com/s/1bpmfwzt
关于 iOS UI 自动化测试,来看下 TMQ 的这篇文章。
看完了 TMQ 的文章,确实不错。
#4 楼 @stephen753 我觉得其实最终还是投入产出比的问题吧。
另外,我觉得 @quqing 的这个方式成本有点高,毕竟原来一条 UI 自动化用例能完成的事情,现在变成 UI + 接口 + db ,而且覆盖度其实还是和 UI 的一致(例如接口中 request 缺少某些字段时服务端的处理,如果是在 UI 操作的话不一定能覆盖到)。对于这种情况我比较偏向于用 stub(挡板)的方式。
举个例子:
UI 的,不和服务器耦合,而是直接拦截它的请求,然后直接给对应的返回。因为这里我们关注的点在于 UI 的逻辑层,即界面操作最终的输出(request)是否正确,以及界面对于服务器响应数据的展现是否正确。
接口的,就是单独的接口测试了。当然接口测试最好还是能直接触及到数据库,确认接口的逻辑是否正确,也方便多用例时用例间的相互影响。
个人理解,分层覆盖的意思不仅仅是说不同层级之间用例的比例,关键点是每一层有自己单独的测试,也有合起来的系统测试。而且很明显的,系统测试的覆盖度会不如每一层自己的单独测试。
至于覆盖度的衡量,在没有很好的方法的情况下,我觉得代码覆盖率是一个不错的参考指标。
以上是一些个人观点,大家有不同意见也可提出~
关键 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]
。