程序员的测试课
郑晔
开源项目 Moco 作者
18911 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 23 讲
加餐 (1讲)
结束语 (1讲)
程序员的测试课
15
15
1.0x
00:00/00:00
登录|注册

03 | 程序员的测试与测试人员的测试有什么不同?

你好,我是郑晔!
前面用了两讲的篇幅,我们一起一步一步地用带测试的方式完成了一个项目,现在相信你已经对如何在实际工作中编写测试有了一个初步的认识。有了实践的根基,我们还需要对如何编写测试有一个更全面地理解,以便日后能够更好地应对各种场景。
关于测试,许多程序员的第一个问题就是:测试不是测试人员的工作吗?如果我把测试写了,那是不是就抢了测试人员的工作呢?
不瞒你说,之所以我要把这个话题放在专栏前面讲,一个重要的原因就是我当年真的就这么想过。好,今天我们就来聊聊程序员的测试和测试人员的测试究竟有哪些不一样的地方。

程序员的测试能否替代测试人员的测试?

我给你讲一个我在职业生涯初期的故事。那时候,我刚刚踏上自己的程序员精进之路,我不断地寻找着各种能够更好地写程序的方式。当我意识到测试对于编程的重要性时,我就开始有意识地在写代码的时候编写测试,尽我所能把各种场景都考虑到。作为一个骄傲的程序员,我总是希望自己的代码是无懈可击的。
有一次,我写了一个协议的解析器,我把各种字段缺失或不正确的场景都处理了。结果交给测试同学后,他上来就发了一个空包,然后我的代码就崩溃了。我当时的第一反应是,你怎么能这么做?测试同学却反问,我为什么不能这么做?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

程序员的测试与测试人员的测试有着明显的区别。程序员的测试是站在实现的角度,关注白盒测试,而测试人员的测试则是站在业务的视角,进行黑盒测试。尽管程序员可以从业务角度思考,但由于注意力有限,很难完全代替测试人员的视角。在实际工作中,大部分测试人员并没有机会全力以赴,因为系统的基础质量不高,导致大部分工作都是发现极其简单的 bug。然而,如果程序员能够做好自己的测试,很多问题就可以在萌芽状态被消灭,从而给测试人员更多机会进行探索性测试。因此,程序员的测试不能替代测试人员的测试,而测试人员的优势也值得程序员学习。通过这篇文章,读者可以了解到程序员的测试和测试人员的测试之间的差异,以及它们在实际工作中的影响。程序员和测试人员拥有不同的视角,程序员更关注实现,而测试人员更关注业务,所以,即便程序员编写测试,也很难覆盖所有的情况。实际上,即便是测试人员也不敢说自己能够覆盖所有的情况。目前大多数团队的情况是,测试人员并没有得到充分的发挥。只有程序员做好了自己的测试,测试人员才能从日常琐碎的验证工作中解脱出来,去做更有价值的测试。在测试问题上,程序员应该向测试人员学习,与工具相比,更重要的是思维方式。我们可以像测试人员一样从测试场景入手,多考虑各种情况,尤其是异常情况。需求的验收条件是一个很好的测试起始点。在团队中,测试人员可以把自己的测试用例分享给程序员,而程序员可以把新的测试用例用代码的方式固化下来,二者就此可以形成良好的互动。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《程序员的测试课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(14)

  • 最新
  • 精选
  • sylan215
    看到这么理解测试的开发,真是很难得,不仅仅是理解,而且理解的相当到位。 首先,开发和测试是互补的,开发做白盒测试,测试做探索性测试、场景测试等; 其次,开发的出发点是逻辑实现的质量保证,测试的出发点是业务场景的质量保证,所以角度不同,测试点也不一样; 然后,开发和测试可以互补,比如开发提醒测试应该多关注哪部分测试内容,测试可以提供用例给开发,帮助提前考虑各种场景; 总之,开发同学应该尽可能的提高提测质量,这样可以让测试同学可以专心的做好自己应该保障的那部分质量,而不是在一些很简单很明显的问题上疲于奔命。

    作者回复: 程序员和测试人员彼此都扩大上下文,开发过程会更顺畅。

    2021-08-16
    18
  • 胖虫子
    终于遇到个能理解测试的开发了,有时候提交的东西都是一堆明显问题,此时修改来修改去,真的留给测试人员专心去想,专心去测的时间已不多了

    作者回复: 扩大上下文,理解不同角色的价值。

    2021-08-09
    3
    6
  • 阿姆斯壮
    从「10x程序员工作法」到「代码之丑」然后来到了「程序员的测试课」,昨天又情不自禁把「软件设计之美」纳入学习中。 非常喜欢郑老师的风格。案例生动,简单意骇。从10x到代码之丑,明显发现了自己的问题。原来自己虽然很努力学习。但一直在错误的道路上。感谢老师提供了一条清晰明确的道路。对未来从此不再迷惘。

    作者回复: 欢迎回归

    2021-08-10
    3
  • webmin
    测试人员通常采用反证法,用无法证伪来达到当下足够正确。 程序员大多时候习惯逻辑推理,只是这个推理过程的严谨性无法和数学的证明过程相比。

    作者回复: 我在《软件设计之美》中讲过,一开始人们想通过证明的方式验证程序的正确性,不过,这条路在实践中没有走通,只能靠测试了。

    2021-08-09
    3
  • 学习
    非常认同之前听到的一句话,单元测试不是为公司写的,而是为自己写的。 在公司都不写单元测试的情况,你写了,差距就产生了,你进步得越快,就能越早脱离不好的公司,至少我认为,单元测试都不愿意写的公司绝对不是好公司

    作者回复: 事实是,好公司是有要求的。

    2021-12-16
    2
  • webmin
    今天的课程帮我修正了对测试工作的认知,我以往认为测试人员的研发能力如果没有研发人员的能力强的话,怎么能发现研发人的问题。

    作者回复: 很多问题的出现都是脑子里的开关,拨过去就不一样了

    2021-08-09
    2
  • 自由鸟
    测试人员测试的时候会认为程序有bug,就会各种举证试错,这可能也是测试总能发现问题的原因。

    作者回复: 这不是认为,不要用恶意去揣测别人,用例证就好了。

    2021-08-25
    2
    1
  • 北风一叶
    测试人员不下班,我们也下不了班

    作者回复: 拼体力,加油!

    2021-08-19
    1
  • Geek_3b1096
    学习用代码支持复用新的测试用例
    2021-08-26
    1
  • 6点无痛早起学习的和尚
    分享 2 个故事 1. 因为之前团队 QA 都关注代码实现,这个团队 QA 不关注代码实现,比如有些异常正常不会出现的,QA 直接通过手动改数据库的数据,然后测试这种操作,不知道这种测试case是否合理 2. 研发觉得离谱的一个事:http 请求入参字段是 int 类型的,然后 QA 用 postman 测试传 1.1,然后代码最后接收到的是 1,这时候就提出 bug 了,理论上应该报错。 我反馈的是: 1. 服务是内网调用,不存在外部用 postman 请求, 2. postman 给 body 赋值都是用的"",所以你才能测到 1.1,实际情况上游不可能 int 传 1.1,如果用 string 传 1.1,这个会报错。
    2023-04-28归属地:北京
收起评论
显示
设置
留言
14
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部