• 测试框架应该就没有好的开源的,给个思路,毕竟grpc要依赖proto,本地的能力不管怎么都要编译proto,这样还不如利用一些服务发现的工具和能力,将grpc接口泛化成http调用,这样测试就方便,但前期投入比较大

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

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

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

  • 测试开发与 XY 问题 at July 08, 2019

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

  • 测试开发与 XY 问题 at July 07, 2019

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

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

  • 测试左移和开发赋能 at April 23, 2019

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

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

广州测试攻城狮,点虫人,英文名Terry