还未发布过话题
  • 这是作死的节奏吧。。。。。。

  • 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,那你想办法求一下他们的心理阴影面积吧。

    发个牢骚,就这样。