• 外国人的轮子啊……不知道也是基于 Jmeter 的吗?
    我文中写了不少为什么我要再开发一套的原因,要不你参考一下,然后告诉我 Taurus (Blazemeter reporting services ) 是不是都满足了。

  • 额,这种提到 issue 里吧……然后堆栈完整一点儿。
    看错误是比较简单的,数据库字段不能为 null。我本地是可以的,当然完整堆栈能看出是什么问题。

  • 好的,👍

  • 了解了,压测任务确实各有不同,不过只要是使用 Jmeter 的脚本,都可以上传到这个平台上进行压测。
    至少可以做到:

    1. 脚本的统一保存。
    2. 生成 Jmeter 自带的测试报告,并在线查看。
    3. 通过复制镜像,生成完备的压力节点机,然后配置到平台上,一键启停。

    如果你们的测试报告都是自己整理的,那么你们可能需要完备的监控截图,而我的平台监控截图比 grafana 的清晰了不少,你们可以作为参考。

  • 😂 😂 也有道理!
    不过平台的初衷之一是让开发等不专业的也可以执行性能测试,我们仅是管理测试脚本,管理权限就好。

  • 你好,是接口请求的内容保存在数据库里,所以才需要读数据库。
    并不是接口返回的预期值保存在数据库中。

  • 提几个建议吧,你的代码实现:

    1. 写好注释,让代码可读性更强。
    2. 代码良好的设计,比如要穿插 Post 等,Http 请求头不同,Https 协议等等,代码如何更优雅。
    3. 接口返回值比对是在接口成功返回之后做的事,而接口的成功返回需要各种各样的断言,要加上。
  • 有你分享的时间,我 Jmeter 都干完活了……行了大兄弟,别在我这掰扯这些了。
    我文中写的那么多 Jmeter 的优点看来在你眼里都是 P 啊……“Jmeter,功能太丰富了,比如正则表达式,自定义变量,参数化,性能测试,定时执行等等。 这基本满足所有复杂的接口测试要求,自开发这些工具真的比不了。”
    我期待你在 github 上的开源。

  • 写的不错,大势所趋。

  • 这个回答做到了:
    talk is cheap show me the code.
    这套代码工具,可以解决读接口的比对问题,也是我文中所面对的问题。
    当然我的 Jmeter+Ant 还是有其优势的:

    1. 接口测试请求链接数据不是数据库/文本等等已经保存好的,需要新创建测试数据。
    2. 请求和请求之间存在数据关联。即和上面第一种情况结合起来。

    至少这两种情况,Jmeter 还是比较方便的。
    我不展开了,我相信 python/node.js 能做到。

  • 好的。我文中就是这么做的。

  • 谢谢版主肯定。

  • 你的一个连数据库的函数 + 一个循环 再加上 @hu_qingen 的接口测试 [JsonSchema] 关于接口测试 Json 格式比对核心算法实现 (Java 版) 这应该就是你写的 “一个断言” 的完整实现。

    至于重构怎么改变大小写了,你很感兴趣……可能测试的工作就是这样吧,面对的是各种各样的问题。
    没别的意思,我觉得我的这篇至少引发了你对解决问题的思考,并且你也感兴趣了,我觉得就很好。

  • 不错,学习了。

  • diffy 是个好工具啊,界面也不错。应该可以搞定我的问题,即便搞不定二次开发的工作量也比较小,主要是这测试结果是在线的很赞。

  • 接口返回值可以包含多个表的数据,再说接口可能有缓存的,都不调用 DB 的数据,直接测试数据库是不行的。

  • 不了解这么高端的工具。

  • beyond compare 命令行没用过, 能把 JSON 格式化后再对比吗?

  • 这个地方主要是对比测试,两个环境海量接口返回值的对比测试。
    Json Schema 明显是没做的……你的建议很好,不过很难推行。

  • 不仅仅是测试返回码啊~返回值的格式,甚至大小写匹配,返回值的 key value 都要一致的。

  • 我过后也介绍一些我自己写的在线 Jmeter 用例管理吧,点我头像进 github(帮忙点个星星最好了多谢)。没想到这还能整个公司出来。

  • 学习了。
    不知道你是第几面产生这些感慨的,面试要招的人是最适合这个岗位的人,而不是技术能力最强的人,所以面试题往往点到为止,你符合岗位要求就行了,如果你要的钱比较多,那么会问一些比较深入的看看你是不是把面试官当 SB,不是说你技术最牛钱就最多的,主要还是看是否适合这个岗位(技术只是一个大的方面)。
    再多说几句吧,你写的这几个问题挺对我胃口的。
    首先你这 4 个问题,其实实际运用中意义不大,开发都很少用,更不用说测试了。
    1.3 问题是锁的,多线程的,但是现在服务器都是分布式的,使用的都是分布式锁,单进程内讨论锁和多线程意义不大,脱离实际。
    2.问题是线程池,意义很好,不过单进程内再开线程池,意义也不大,现在都是分布式,一般是队列实现任务分发,仍然是跨进程的。
    4.问题是垃圾回收机制,讨论的是各种垃圾回收机制的优缺点,可是你应该也了解,CMS 一旦出问题就是致命的,而多线程回收是默认的,你讲究这些问题,理论研究很好,实际应用上谁能让你上 CMS 呢。更何况 CMS 提高性能也并不是很明显。
    你能熟悉 JVM 到这个深度自然非常好,但对于测试工作是锦上添花并非雪中送碳,希望能理解。

  • 我才刚买《腾讯 iOS 测试实践》,还没到货呢惭愧。
    我和楼主不一样啊,我是 Java,mysql 这类书一定要精读的,测试书才是当工具书看或者 google 了。

  • 感谢肯定,前端我还有太多东西需要学习,向你学习。

  • 未知的未来,努力前行。 at 2018年02月08日

    谢谢。
    AI 不像测试,测试还可以讲是质量保证,是软件所必须的。AI 可不是必须的。