• 略谈测试之发展 at November 09, 2018

    这是一篇发自肺腑的文章。说一下自己的观点 - 我觉得没必要去划那么多的界限,不要去在意鄙视链。只需要知道,自己目前的工作是什么,怎么样才能把他做好,怎么样才能得到更多的收入,仅此而已。 至于是开发还是测试,是运维还是PM,这个只是你和别人吹牛逼时候的谈资,饭局过后,一切如常你还得养家糊口跑步看书。

  • 接口自动化测试平台 at November 08, 2018

    是这样。 我上面也再三说了,不是在说这东西不好。我只是在请教问题,想看一下别人是怎么解决我当初遇到的一些问题。
    好的代码结构,好的封装同样可以避免所谓的重复劳作。目前我的那一套框架虽然没有一个WEB UI,但是也只是维护数据和用例本身,不需要又去写什么重复的类,都是封装好的。这么说吧,我如果加一个DB把我的数据文件存起来,加个前端支持填写用例并把我们的数据和用例展示出来,那也和楼主这个平台差不多。不过这时候就会无端的多出很多开发成本。 正和你说的一样,人力有限的时候。这是灾难性的。楼主的团队规模大,所以上面是想请教我之前遇到的一些问题,看他们是否有解决方案吧。

  • 我只是基于简单的需求用了下,觉得很棒,毕竟github 4w+ star,可以了解下的。 你这个文章也给了我一些做性能的思路,接下来去试验下😀

  • Nodejs Puppeteer 简直神器

  • 接口自动化测试平台 at November 07, 2018

    我说jenkins是说一种模式,并不强调jenkins本身。因为一般基于jenkins构建体系,所有的东西都在代码里,所以要做数据准备也就是几个类的封装,起码不需要做前端的开发。 好吧,既然您的态度是这样,那交流可以停止了。

  • 接口自动化测试平台 at November 07, 2018

    意思就是你们这个平台还从Web端提供了前后置方法的入口? 比如创建一个Case的时候,有提供一个前置条件的表单,可以傻瓜式的选择“执行SQL”或者“调用用例id=15”这样的操作?

    只是想交流一下,因为我之前也捣鼓过类似的平台,只是在资源(特别是人力资源)有限的情况下,我深深体会到这样还不如纯coding来基于jenkins做持续集成。 因为一旦项目有新的诉求,如果我采用自建轮子的模式,需要从后端开始将新的feature implement到前端,而且有可能会遇到很折腾的问题; 如果是以jenkins为中心的构建模式,要省去很多维护时间,从而把精力集中到测试用例本身。

    再次强调,没有贬低的意思,只是交流。

  • 接口自动化测试平台 at November 07, 2018

    我就想请教一点,通过你这样一个自己造的轮子,做数据维护不会增加成本? 我举个例子,我要测试一个电商用户Coupon的查询接口getCoupon,并且测试查询“已使用Coupon的情况”。那么我需要的条件如下 -

    #1 新建一个用户
    #2 为新建用户领取一个coupon
    #3 下一个订单,并且使用这个Coupon
    接下来才可以来到target本身执行测试逻辑

    那么通过你这个平台,如何实现No coding的测试数据准备?

  • 上班,领工资;干不走了就想其他办法谋生。活下去。尽量活得好。

    瞎J8扯这些干嘛。

  • 天府软件狗在此,时间地点呢?怎么参加?

  • 把测试脚本写的美如画