• 对的,可以朝这个方向调研学习,个人觉得学习完后可以结合你们那边本身的业务技术特点,自己搞一个能够适配你们的工具或平台,这个产出效果可能会更好

  • 稍微聊一下,doom 引流回放是最明显的能力,但是我个人在使用过程中认为其对于阿里内部技术栈,尤其是中间件层的支持才是最强大的,对于这种引流能力,就算是读操作,对两套环境的效果也不是 100% 一致的,比如可能会涉及读操作但写缓存,那写缓存的场景都要 mock 掉,以及到写操作,怎么做到数据不被击穿,队列不被引流环境消费,这种才是最需要考虑的,说真就引流这点我感觉一个 goreplay 就够用了,而且感觉 doom 也没有大力的对外推,毕竟这个的由来严重依赖于阿里的技术体系😂 😢 😓

  • 按照问题回答的话:业务测试能力和技术能力都很重要
    但有更重要的是质量服务思维,在 ali 的晋升,尤其是 6 到 7 的时候,无论业务测试能力很牛 X,还是技术很牛 X,思维不到位一样是明年再来,楼主可以思考一下,现在你所拥有的能力是质效能力,那为什么要做质效,假设业务都快死了,只做质效工程化的事情业务就能活了?推荐楼主看看《麦肯锡问题分析与解决技巧》这本书,读完之后再试试回过头来思考你现在的问题,看看有没有帮助

  • 测试开发与 XY 问题 at 2019年07月08日

    所以自己真的没有 100% 的把握的情况下,还是先多方讨论,先针对问题讨论,不针对方案讨论,虽然在时间成本上有点耗,但起码不会走弯路

  • 测试开发与 XY 问题 at 2019年07月07日

    受教了,做任何方案和设计确实要回归到 why 这个点上,针对 why 点要有充分的论证

  • 关于线上监控的思考总结 at 2019年05月17日

    我已经换回上传图片资源到社区的资源服务了,应该正常了

  • 测试左移和开发赋能 at 2019年04月23日

    大厂在近些年做了很多测试左移的探索,以我所处的环境为例,在讨论的时候就有提到怎么让业务在有保障的前提下自我迭代,而达到研发自交付的效果,在这里我们做了静态代码扫描,接口测试自动化,环境一体化,预演方案,线上引流回归,全链路压测,线上精准监控等测试工程化的措施,这里的很多工具和平台不是全部为我们自己负责业务的测试团队开发的,大部分是引用,有就拿来用,投入应用->得到数据 - 分析效果 - 赋能团队,建立起来后迭代版本时研发只要提交了代码就有一体化的质量保证服务,测试人力的涉入就可以大大减少,但我就说句站在个人立场的话,等这些都做得很完善的时候,也就是你差不多也退场的时候了,比较悲观的思考是:测试做到头就是自我淘汰自我毁灭了

  • 对于 go get 去拿 golang.org 域,就算已翻也未必会成功,一般 go 的资源在 gitlub 上都会有,直接 go get github 地址,就会直接拉下来编译好,然后改一下依赖路径,比较曲线救国,但也是我这里目前解决依赖问题的最直接方法😂 😅

  • 我太太的处境和你很像,我是男方,我太太也在家待业将近半年了,先不管行业不行业的问题,趁还没有小孩,现在这段时间最好去实现一些原本占用工作时间但做了又可以提升能力的事,像我让我老婆去学车去读她专业相关的能力课程提升自己,能力到位了工作自然也来, 想起当初在老东家的时候,当时也是想招一位已婚未育的姐姐,当时大佬的想法是,如果她真有那么符合我们部门的核心能力,生育上的问题也不是问题,而且就算找个已婚已育的,也难保她会二胎(再说下去我就要吐槽工作对女性的不公了),所以关键还是先把能力培养起来,转行不是不行,关键是你的决心和执行力,凡事要做精,做精要时间和业务积累,所以不管转不转行或是不是创业,关键还是自己的核心能力,决心和执行力,这个好了啥都没问题

  • 考证,是锦上添花,更主要是体现出你的行业能力和业务能力,东西存在必然有用处的,我自己也弄过财务相关的证书,我个人有财务专业背景,刚开始也是以为没什么用,到我现在负责的业务里面有涉及财务结算,那就很有用了

  • 对于测试而言,个人感觉比起考 PMP 和 ISQTB 技术专业相关的证书,考业务或行业相关的证书价值更来得快,比如金融,银行相关的银行从业资格,证券从业资格等,为什么有这个建议,因为在测试这个领域,任何技术和方案都是服务于业务,所以贴近业务发展就中长期来说比较符合个人发展的利益,比如一套技术没个 3 5 年就换一轮新的,一名测试人员最后体现的能力更多的表现在行业背景

  • 这样子,在控制逻辑上,一个 appium 服务节点对应一台 udid,在这个控制好的情况下, 那空闲的判断只要看 appium 是否空闲就好,判断空闲的方法是查一下 appium 上面存不存在 session

  • 打开 macaca-doctor 源码里面的 ios.js,有一段代码

    exports.xcodeBuild = function *() {
      try {
        const binPath = yield _.exec(`which xcodebuild`);
    
        if (!_.isExistedFile(binPath)) {
          return _.fail('Xcode is uninstalled');
        }
    
        let originVersion = this.getXcodeVersion();
        let version = originVersion.length !== 3 ? originVersion : `${originVersion}.0`;
    
        const MIN_VERSION = '9.2.0';
    
        if (semver.lt(version, MIN_VERSION)) {
          _.fail('xcodebuild version: %s lower than %s', originVersion, MIN_VERSION);
        } else {
          _.pass('xcodebuild version: %s', originVersion);
        }
      } catch (e) {
        console.log(e);
        return _.fail('Xcode is uninstalled');
      }
    };
    

    上面的报错都是拿到的版本号是 9.4.1.0,其实最后版本对比代码是

    const semver = require('semver');
    console.log(semver.lt('9.2.0','9.4.1.0'))
    

    然后就直接报错了

    TypeError: Invalid Version: 9.4.1.0
        at new SemVer (\node_modules\_semver@5.3.0@semver\semver.j
    s:293:11)
        at SemVer.compare (\node_modules\_semver@5.3.0@semver\semv
    er.js:342:13)
        at compare (\node_modules\_semver@5.3.0@semver\semver.js:5
    66:31)
        at Function.lt (\node_modules\_semver@5.3.0@semver\semver.
    js:600:10)
        at Object.<anonymous> (Desktop\test.js:2:20)
        at Module._compile (module.js:652:30)
        at Object.Module._extensions..js (module.js:663:10)
        at Module.load (module.js:565:32)
        at tryModuleLoad (module.js:505:12)
        at Function.Module._load (module.js:497:3)
    

    改成

    const semver = require('semver');
    console.log(semver.lt('9.2.0','9.4.1'))
    

    就返回 true 了

    基本判断是这句话的代码逻辑拿到的 xcodebuild 版本出发了 + 上.0 的操作

    let version = originVersion.length !== 3 ? originVersion : `${originVersion}.0`;
    
  • 不错,楼主应该说的是主要的对比方法,但具体的执行方法有机会可以在补充一下哈
    2 点
    1、不同版本的接口做 diff 测试,基本上至少要 2 套或以上测试环境,设 1 套为旧接口生产环境 1 套新接口 diff 环境,你这里是什么方式将流量从旧接口服务器复制到新接口
    2、新接口环境的测试数据如何管理,还是说在 diff 环境做数据挡板,还有怎么保障流量到新接口走过的子调用和旧接口子调用的差异,数据比对相同不一定就是 diff 的真正结果

  • Android 帧率测试 at 2018年07月29日

    首先是对 4 项数据的说明:
    Draw: 创建显示列表 (display lists,记录所有 view 对象的绘制指令) 的时间开销。
    Process: 执行显示列表中绘制指令的时间。UI 视窗中的 View 数量越多,需要执行的绘画命令就越多。
    Execute : 将一帧图像交给合成器 compostior 的时间。这部分占用的时间通常比较少
    而 prepare 在一些旧 adb 版本中是算在 process 上,就是指从创建显示列表到执行显示列表的这一段准备时间的开销

    所以 完整的显示一帧 =t(Draw + Prepare+Process + Execute),t(时间) 要小于 16ms 才能保证到每秒 60 帧

  • 欢迎看看测试大会 ppt 里面的这个:玩转 58 场景下的自动化测试
    https://www.jianguoyun.com/p/DdEKPEwQqNeXBhiMuWM
    轮子可以做,但做什么轮子的话,马牌还是米其林?主要还是解决什么问题

  • 这里补充一点是,用 noVNC 是为了接入无缝接入到 UI 自动化测试平台上,如果用 vncviewer 就要考虑接入一个客户端,这显然没有直接接入 web 页面那么方便,这就是我遇到的所谓的业务问题,点对点解决,所以方案都是基于遇到问题解决问题的思维路线去设计,当然直接用 vncviewer 也是可以的,如果就工具层面的话,没有最完美,只有最合适

  • 之前有用过您链接提供的,就是遇到文章所说的问题,浏览器外交互稍坑

  • 拯救匿名区 at 2018年06月26日

    我实名的说,我了解到最近社区的匿名区走样的一个原因是,脉脉,脉脉,脉脉的匿名区,如果大家有上去看过的话你会发现风格几乎是一样的,有种被降维打击的感觉,小伙伴们别被带偏,戾气让人退步,退步就是落后,落后就要挨打

  • 看看 appium 的日志,检查一下分配的测试用例对应设备的 udid 是不是没替换哈,链路是用例上这个点要配好,然后脚本会读取设备列表分发到不同的 appium 然后执行用例

  • 好 可以删除带微信号的评论哈

  • 用 robot_mutil_test.py 吧,版本有更新的,AutoTest_Mutil 是个目录名字而已

  • 买到了没,我有

  • 好啊 这个月不用怎么加班的话写一下 再加点料