02 | 如何设计一个“好的”测试用例?
茹炳晟

在上一篇文章中,我以“用户登录”这一简单直接的功能作为测试对象,为你介绍了如何设计测试用例。现在你应该已经知道,为了保证软件系统的质量,测试用例的设计不仅需要考虑功能性需求,还要考虑大量的非功能性需求。
那么,今天我会重点和你探讨如何才能设计出一个“好的”测试用例。
什么才算是“好的”测试用例?
在正式开始讨论之前,我先跟你聊聊,什么才是“好的”测试用例,这个“好”又应该体现在哪些方面。这是一个看似简单实则难以回答的问题,即使深入思考后,也很难有非常标准的答案。
通常,你的第一反应很可能会是“发现了软件缺陷的测试用例就是好的用例”,我可能会反问你“如果说测试用例发现了缺陷就是好用例,那么在该缺陷被修复后,同样的用例难道就不是好用例了吗?”。
你可能还会说“发现软件缺陷可能性大的测试用例就是好用例”,这话看起来还是蛮有道理的,但是我同样会反问你“你打算用什么方法来量化测试用例发现缺陷的可能性?”。
类似地,你可能还会说“发现至今未被发现的软件缺陷的测试用例就是好用例”,那么我想问你的是:如何评估是否还存在未被发现的缺陷?如果软件中根本就没有错误了呢?
其实,是你定义“好的”测试用例的思路错了,这就有点像“傻子吃烧饼”,连吃五个不饱,吃完第六个终于饱了,于是他说:早知道吃了第六个就会饱,何必吃前面五个呢。细想,他吃的六个烧饼其实是一个整体,一起吃下去才会饱,而你无法找到吃一个就能饱的“好”烧饼。
公开
同步至部落
取消
完成
0/2000
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件测试 52 讲》,新⼈⾸单¥68
《软件测试 52 讲》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(109)
- 最新
- 精选
- sylan215置顶其实一直以来,我都是把宣称「能发现 Bug 的用例就是好用例」,在讨论用例有效性的时候,我也经常问别人一个问题「你的 Bug 里有多少是通过用例跑出来的」,现在想想,这些都只是针对当前需求修改点而言的用例,毕竟在有效的时间内,用例的有效性还是非常关键的,而且针对的是具体的用例而言。 如果换个角度,从茹老师说的软件质量的角度看,确实不应该这么说,这时候覆盖面最全的用例集才是好的用例集,毕竟我们要保证的是软件的质量,那么所有可能出现质量问题的地方,都是应该有用例覆盖的。 但如果是回归测试的话,我还是更推荐「能发现 Bug 的用例就是好用例」,毕竟规定了迭代时间的话,每次都全覆盖的回归,投入产出比有点吃不消。 另外,关于全面性,我再补充一个对于互联网产品必须要考虑的一个测试点,就是需求的合理性,传统的测试,我们主要关注的是需求的详细程度以及实现细节,但是对于互联网产品,用户体验已经是一个绕不开的话题,也是商家必争之地了,所以在所有的需求和功能验证之前,建议增加一个「需求合理性测试」。 以上,欢迎沟通交流,公众号「sylan215」
作者回复: 非常棒的讨论,其实关于什么是好的用例并不存在严格的定义,最关键的是建立全方位以及多角度的思维模式。关于需求合理性性测试,我们有对应的UX就是用户体验测试,应该就是对应您说的这一点,很好的补充。
265 - 么西卡首先肯定是要保证用例覆盖全面。很多同学写用例就是直接把需求一段段的copy下来就成用例了。写用例重要的是对需求的分解和补充。能够加上自己的经验以及对产品的理解,覆盖各种显性和隐性。功能和非功能的需求。 另外用例还要简洁清晰。你写的用例不仅仅是给你自己看的。要解决用例重复。描述冗余,层次结构混乱的问题。在这样快速迭代的敏捷开发节奏下。没有时间也没有必要把一条条用例写的那么复杂。重要的是把测试点写清楚。不是要把那些显而易见的步骤,环境,预期等写的那么尽善尽美。 还有一个很重要的是用例的一个持续维护。测试用例的复用性也是其核心的价值,需求经常会有变更,用例也要跟上,另外很多问题要在实际测试的过程中才暴露出来。一定要及时对用例进行补充和完善,发现一些需求的漏洞,并总结反思自己考虑不周的地方,每个人都有自己的盲点,要多沟通
作者回复: 非常棒的总结,很到位!厉害👍厉害👍
3107 - 双子分享一些个人的想法,首先补充一个角度从用户体验出发完善测试用例,例如一些UI交互设计、push短信发送节点、banner按钮位置、不同客户端的手势快捷操作习惯等,测试人员应该是比产品和开发更了解用户使用习惯的。其次,我觉得测试不仅不能依赖开发也不能过分依赖产品,测试人员应该是对全线产品逻辑细节最熟知的,需求设计的业务漏洞也需要测试来把控,所以需求评审的过程中测试人员就应该能凭经验构思出初步的测试策略并推测出常见错误予以提醒避免开发阶段浪费时间。再次测试用例的后期归档整理也属于测试人员需要注意的事项,系统科学的整理用例有利于后期的阶段性回归测试,可以减少在编写测试用例上浪费不必要的时间。
作者回复: 非常棒的分享👍 你说的这几个点我都非常同意
247 - wangq文中很多方法在平时的工作中不谋而合,也是一直强调的。另外,即使是黑盒测试,在测试过程中,与需求确认业务规则,与开发了解代码逻辑,业务规则是准则,代码逻辑是参考,但很多测试人员容易犯的就是跟开发人员确认业务规则
作者回复: 你说得非常正确👍
742 - 刘斌宇在快速迭代的互联网环境下,我们公司测试用例都是采取xmind思维导图的形式。对于移动端来说常见的如安装卸载,版本兼容等常见测试思路可单独提取出来。
作者回复: 是的,列出测试点,我们也经常使用思维导图,我自己用的也是xmind
25 - Kola测试是一场考验耐力的运动,必须坚持到上线前最后一秒,无痛上线是测试人员毕生的追求,但是再好的测试用例也跟不上日新月异的需求,所以上线前临时改的需求必须予以极大关注并且争取更多的时间,用最快时间评估改动可能涉及的影响点;最后,千万不能让开发跳开测试,总之一句话,可以没有测试人员 但是不能没有测试!
作者回复: 很棒
18 - 小志文章从事前的角度阐述和衡量“好”的概念很系统。大部分项目受限于时间和人力成本,很难完全从覆盖率提升上评估case的“好”。所以另一种思路是从事后的角度,从漏测率和问题严重程度上来评估。漏测率和覆盖率相折中,形成一定的测试策略,最后形成好的case
作者回复: 非常有启发性的观点,感谢和大家分享👍
16 - arthur感谢老师非常棒的分享,我也非常赞同老师说的需要对被测软件的架构和实现细节有很好的理解,这样能更好的进行测试用例的设计。但是对架构和实现细节的理解需要有开发的知识。平时测试工作量很大的情况下,怎样才能提高技术,去了解软件背后的架构和实现方式呢?老师有木有什么好的建议?
作者回复: 测试前置,也就是测试人员去参加系统设计的review会议,一方面可以了解被测系统的架构设计和实现细节,另一方面可以向开发突出可测试性需求
11 - 小星星请教怎么深入理解软件的设计架构?
作者回复: 首先我觉得先要想明白作为测试为什么要了解软件架构,然后才能有所侧重的去了解和测试密切相关的架构。
28 - 胜杰@阿廉,测试用例的编写没有固定样式,但大体上是由测试点、测试步骤、期望结果、实际结果等部分构成的。到网上找几份来看看就知道了。
作者回复: 嗯嗯,很好的建议
7
收起评论