• 711 大会的时候貌似提过,直接发一条 adb 命令点击安装按钮那个坐标。

    找天要试用下 Android Robot ,现在基本都在弄 iOS 端的东西了。。。

  • #6 楼 @ping_sky 你导入的是 all 这个包吗?貌似要做一步映射。

    有些 ide 有自动下载 source 的功能。你可以试试

  • 接口测试的一些感悟 at 2015年12月09日

    #44 楼 @oneway 主要是因为我只是浅尝了一下就没用了,所以没写在里面。表格本身主要是总结一下近期论坛关于接口测试的帖子的,并非工具合集。

  • 接口测试的一些感悟 at 2015年12月09日

    #42 楼 @momoyue 你指的是 Jmeter 里面的 copy paste 是吧?我指的主要是断言的复制粘贴。用例会复制粘贴是正常的吧,同一个接口的用例复用度应该会很高。

    Jmeter 有自带参数是文件路径/url,输出 md5 的函数?

  • #1 楼 @gaopeng1106 每次都好快。。。不愧是秒赞之王啊!

  • fir.im Weekly - 进击的 Swift at 2015年12月07日

    最后一个已经用起来了,同事回头率接近百分百。不过震动必须关掉,否则晕死。。。

  • 接口测试的一些感悟 at 2015年12月07日

    #39 楼 @zyl911_1012 因为收费。。。灵活一点的 assert 都需要用收费版,而且大部分它能做的 Jmeter 也能做吧。

  • #7 楼 @seveniruby 对,确实不一样。

  • 接口测试的一些感悟 at 2015年12月07日

    #36 楼 @momoyue 我放弃的原因是我觉得不好维护。不过这是个人观点啦。

    我当时用 Jmeter 一共写了 100 个用例左右吧,然后觉得太多地方使用 copy paste ,并且有些特殊需求(如通过 md5 校验上传的图片是否正确)用 Jmeter 来做不如直接写代码方便,所以后面就放弃了。

    至于纯 Java 代码,其实也不是不行,只是需要比较好的分层,例如 @anikikun 前面说的把 business 层封装起来,否则用例写起来代码量比较大,编写速度会慢不少。

  • Q 的 Keynote 风格很赞~话说 PPT 只有 2 个?

  • 移动无线测试工程师必备技能
    接口自动化测试实践的记录

    第二篇给我帮助好大。

  • #4 楼 @seveniruby linux 最有前途,哈哈。

  • 搬运:Battery Historian 2.0 at 2015年12月05日

    感谢,已 star

  • 不是很明白你说的移动端和 PC 端是指所有在移动端/PC 端的带界面的软件还是什么。

    因为个人觉得大部分移动端只是 PC 端的前台(类似 web 页面的前端),背后还是得有 PC 端的服务器存在。

    如果是特指带界面的软件,那么我觉得 1-2 年内应该是移动端比较火热,因为现在用户大部分时间都花在手机而非电脑上。但前途这个说不准,像大数据、机器学习这类新热点基本都是在 PC 端的,毕竟要求有高性能的应用移动端还做不了。

  • Appium Python API 中文版 By-HZJ at 2015年12月05日

    #23 楼 @lihuazhang 已加入 wifi 首页。

  • Appium Python API 中文版 By-HZJ at 2015年12月03日

    #15 楼 @anikikun
    #16 楼 @lylyliuyu 我只是小兵,最认真的还是 @huanzhijin ,他做的事情最多。

  • Appium Python API 中文版 By-HZJ at 2015年12月02日

    整体看了一遍,写的不错,有些坑有写出来了,不过有一小部分的翻译有问题。

    1. is_displayed Whether the element is visible to a user. 该元素是否是可见的用户 翻译错了,应该是此元素用户是否可见。简单地说就是隐藏元素和被控件挡住无法操作的元素(仅限 Selenium,appium 是否实现了类似功能不是太确定)这一项都会返回 False

    70.execute_script

    Synchronously Executes JavaScript in the current window/frame.
      同步执行的JavaScript在当前窗口/框架
    

    这个正确翻译应该是:在当前窗口/框架(特指 Html 的 iframe )同步执行 javascript 代码。你可以理解为如果这段代码是睡眠 5 秒,这五秒内主线程的 javascript 不会执行。

    71.execute_async_script
    execute_async_script(self, script, *args):

    Asynchronously Executes JavaScript in the current window/frame.
    异步执行JavaScript在当前窗口/框架。
    

    和上一个类似,也是插入 javascript 代码,只是这个是异步的,也就是如果你的代码是睡眠 5 秒,那么你只是自己在睡,页面的其他 javascript 代码还是照常执行。

  • Appium Python API 中文版 By-HZJ at 2015年12月02日

    #10 楼 @lylyliuyu get attribute 这个可以参考我以前的一个帖子:https://testerhome.com/topics/2606,不过有点超出 API 文档的范畴了。

  • 接口测试的一些感悟 at 2015年12月02日

    #29 楼 @4amla 首先澄清一点,我这个不是科普贴,是个人感悟贴。不敢说我的观点一定正确,只能说是我个人的个人感悟。

    那我表达一下对你这几个问题的观点吧:

    如果只验证返回值,是否代表着这个接口的功能完全 OK,或者接口测试不去管这个接口的具体功能实现?

    首先,我这里关于接口测试的观点都基于一个前提:你有比较完备的功能测试。而且我是因为条件所限按照一个用例一个接口的规则只能检查到返回值,如果你有条件应该还要同时检查数据库内容,这样完整性好一些。

    那,如果不管这个功能是否 OK(这个返回值研发也可以直接 return 一个正确值即可),那么这个功能就要在其他阶段再进行详细的测试?

    我的其中一个用例就发现了这样的一个问题,A 用户无权删除 B 用户的帖子,但接口却返回操作成功(当然实际上还是没有成功删除的)。对于这样的情况,如果可以获取到数据库那就可以调用单个接口完成,因为数据是否成功修改可以直接通过数据库知道。如果不能,而是需要调用其他 API 才能知道,那更建议把这个部分放到功能测试里做,毕竟功能测试里这个基本是必测的。当然你也可以根据功能的优先级考虑专门为这个功能做个接口层面的校验,但这个更多的是补充,而非接口测试本身的目的。

    如果这些便于测试的接口,由研发人员提供,我们是否需要检查接口的具体实现(貌似也要消耗一点时间),还是说就直接拿过来用就行了?

    肯定不是直接拿来用。。。而且检查接口的具体实现也不现实,如果某一次研发错改了这个接口呢?我觉得有两种方式吧,一种是为这个接口也做一个用例,用于保证这个接口的返回值正确,另一种是直接通过数据库来计算得出这个数据。我这里说的艰难特指模拟用户操作来逐个翻页,导致翻页次数不确定,因此应该有更合适的办法保证一次性能翻到最后一页。

    很开心我的分享能帮助到你,也欢迎你以后在接触接口测试,或者其他新的事物的时候把感悟分享出来。如果只是单纯感悟我发到自己博客给自己以后看就好,产生思维碰撞才是我把这个帖子发在 Testerhome 的目的。因为我有感觉,我目前的观点仍然不完全正确。

  • Appium Python API 中文版 By-HZJ at 2015年12月02日

    #4 楼 @huanzhijin 右下角铅笔图标。

  • 前端开发者的 Docker 之旅 at 2015年12月02日

    angular 现在这么强大了!?

  • Appium Python API 中文版 By-HZJ at 2015年12月02日

    #2 楼 @huanzhijin 64. location_once_scrolled_into_view 这里 markdown 有问题

  • 接口测试的一些感悟 at 2015年12月02日

    #25 楼 @blink 我说下我的理解吧。

    1. 很多时候服务端压根就没人做测试(我们这服务端的东西一个人搞定,因为不需要做界面,纯做接口就好,单测这些在开发的时间都不够的情况下谁去)
    2. 实际流程不会像你所说那样分三步走,而是同步走。服务端会先给个 Mock 服务器让 app 可以调节,接口测试会跟着服务器开发进度走,app 则是一直跟着 mock 的结果和设计的逻辑走,直到服务端说接口搞定了再开始联调。

    这个过程中为什么要有接口测试呢?主要是为了保证开发过程中能比较高频率得跑测试,最好做到服务端一提交代码接口测试就自动跑。同时接口测试也能在后续每次服务端更新代码的时候跑一遍,保证没有出什么重大问题。自动化本身的优势之一不就是能大幅度提高测试效率嘛。

    至于你说业务稳定为啥要测接口,这个我的观点和 monkey 一样,为了回归。而且接口有个好处,定位问题简单,一出问题基本都是服务端的问题,而且肯定是和这个接口相关的代码,不用花时间再去抓包->分析(->撕逼)

    https 的话建议你了解下 https 和 http 区别是什么吧,相信你了解后也就知道答案了。

  • #2 楼 @lihuazhang 这不是 iOS ?