• 不建议 excel 和 db,对于项目的维护,多人协作没有好处

  • “微服务等框架开发,很多开发逐渐已经抛弃单元测试”
    开发从来就没拿起过单元测试好吧,哪来的抛弃

  • 我这边都是测试案例写完,直接写接口测试代码的,能发现问题

  • 接口自动化不是救命稻草 at 2023年11月18日

    目前我的项目基本上都是自动化,95% 以上。接口文档完整。
    每次都全回归,然后才出包

  • 我项目里面从来不用界面。都是 testcase 执行的过程中,用测试代码动态设置 mock 的返回的。每个 testcase 跑完了,清空 wiremock 的 mock 设置,接收到的 request 的记录

  • 别白费心机了,你的做法有点不切实际

  • 首先你的接口测试是什么?其实是功能的测试,功能测试是属于黑盒范畴吧,黑盒测试关注的是啥,通过改变输入影响输出,然后验证输出。
    输出包括什么?接口的返回、数据库的新增、更新,调用第三方系统的 API 的请求等,都是输出,都是需要检查的。
    你手工测试要检查的内容,按道理来说,自动化测试就应该检查。手工和自动化之间,在证明一个被测功能的正确性上,是不应该有本质的区别的。手工和自动化的差别,只是谁执行 testcase 而已。
    如果你的自动化,什么都不检查,那么你的自动化测试的测试结果又凭什么能让你信服?

    目前我们团队做接口测试,是把接口响应、数据库校验、发送到第三方的请求、消息队列的信息、redis 的信息都做了检查的

  • 直接使用第三方开源的 WireMock,基本上你想到的功能都已经有了。没必要做重复的轮子

  • 如何对将来数据进行测试 at 2022年03月02日

    结论:这是人才呀

  • 这是作死的节奏吧。。。。。。

  • mock server 实践 at 2020年12月07日

    个人使用 wiremock 比较多,看着功能上和 mock server 大同小异

  • 赞一个

  • 验证的过程大致包含下面这些:
    检查 API 是不是根据你输入的数据返回期望的结果
    验证 API 是不是不返回结果或者返回异常结果
    验证 API 是不是正确触发其他 event 或者正确调了其他 API
    验证 API 是不是正确更新了数据等等

    我看到这里,我表示笑了。都以为这样就是接口测试,接口测试就是通过报文的返回来判断功能是否正常。然后底下回复的也没人觉得这样的想法的错误有多危险和可怕。

  • 服务端协议测试视频教程 at 2017年03月09日

    看了第二集,我只想说是一本正经的胡说八道。

  • 看完我只想说,要我选人,我宁愿要应聘者,也不要面试官。
    7 年开发中 6 年对日,我只能呵呵了。
    之前面试了几个 3~5 年的对日开发,幸亏是电话面试,不然真想骂人了。说啥啥不会的,基本概念都是错的。
    说实在的,楼主的这一句 “熟悉并能书写 WINDOWS 开发平台下 JSP、ASP、HML 中的一种网页设计语言” ,用来描述你的开发能力的话,就已经足够让我吐槽了。

    而且,你的技能积累是你 7 年开发经验所得。别人的编码方面的技能积累,是建立在 10 年测试经验基础上的,也就是在测试工作之余自发性的学习,还有比较值钱的业务知识。

  • #47 楼 @cloudhuan 自动化测试其实也是可以算是一种开发任务,如果你这样看的话。问题有出来了,这个任务的需求是否清晰呢?

  • #41 楼 @ycwdaaaa
    是的,关键字驱动、录制脚本,都是用来忽悠低水平的测试人员,进入自动化的领域。
    但是很多人都是不思进取,碰到问题的就放弃了。
    感觉这种傻瓜式的关键字驱动和脚本录制,其实并不利用自动化的良性发展

  • 我的公司的业务测试 at 2016年10月21日

    基本都是这样的流程,没什么新奇的。
    楼主在用于描述的字眼,看似测试很强势。
    关键还是要看,测试在各种评审当中能提出多少真正有价值的意见和建议,如果每次抓到点都是以一种盛气凌人的态度去说话,对于整个团队的关系和谐未必是个好事。
    而且,也不太可能每次都有评审都能发现那种原则性的漏洞,往往都是有两种或以上的方案选择,到了最后实现才知道到底有多坑。

  • 现实就是这样,很多公司里面,你要想找到能写代码的测试不容易。
    就算能写,大部分都是停留在写那种又长又臭的代码,维护成功极高,基本上是一次性使用的。
    而真的能好好设计,并且重构的好,形成框架,易于维护的,在一般公司中可以说是凤毛麟角(我不说绝对没有),而且这些人基本上都往 BAT 倾斜了。又或者,有这样的能力的,早就去做开发了,还干测试干嘛。

    所以,这就是为什么自动化,尤其是 UI 自动化一直搞不起来,没办法有声有色的。
    很多人有很好的想法,想出不错的点子弄个框架出来,但是一想到身边测试同事的水平都是停留在手工的测试,你让他写个冒泡排序也非大半天劲都没搞好(PS:测试入门门槛低,很多人都是非科班出身,本来就没什么编码能力。或者即使是计算机专业,大学的课程有多无用,又有多少人在大学不是混日子,或者当初就是因为自己编码能力就是烂才有了做测试的意向的。这些人占的比例可高了)。面对着这样的队友,你写出来的框架他们能理解吗?他们会懂的用吗?给他们玩也是相当于杀鸡用牛刀,最后弄巧成拙。

    时至今日,很多测试还对 QTP 念念不忘,那是为什么,就是因为能录制回放,不用怎么动手写代码。
    你让这类人用 selenium,那你想办法求一下他们的心理阴影面积吧。

    发个牢骚,就这样。