测试用例,写不写?

2022-03-01   出处: CKL的思考空间  作/译者:chenkl

上回,我们聊到了测试策略,也提到了测试策略的重要性。很多人说测试策略现在会包含在测试设计阶段,落地到测试用例中,也没什么问题,因为这都是解决问题的过程方法,不是核心目标。提到测试用例,这个作为测试入门级的问题,现在很多人对它也是看法颇多。

有的观点认为,测试用例是测试人员的工作量体现,而且是测试工作的指引和保障,需要详细来写。

有的观点认为,现在是敏捷研发,测试都来不及,写什么测试用例。

折中的观点认为测试用例可以写,但是不需要写的那么详细,用导图写个大概就可以了。

你认可哪种观点呢?

1. 测试用例及其作用

我们先从测试用例本身说起,测试用例(Test Case):为了特定的目的(证明软件存在某问题)而设计的一组由测试输入、执行条件、预期结果构成的文档。它通常包含测试用例编号、测试项目、测试标题、重要级别、预置条件、输入、操作步骤、预期输出等八个要素。

结合自己多年的测试经验,个人认为:测试用例是自己测试思维的一个载体,它指导着测试活动的进行,是测试执行的最低保障。至于以什么形式来承载,其实并不重要。

思考测试设计的过程,其实就是自己测试思维的体现。通过合理的测试用例设计策略和模型,能够让我们更好地去设计用例,通过更少的用例,去覆盖测试更多的测试场景。测试用例的好坏,能直接体现测试人员的基本素养(现在反而很多人都忽略了这些,而单纯的去追求技术)。

同时,测试用例将指导测试执行过程。因为人都会犯懒,可能是心情不好了,可能是想不起来了,也可能是单纯地遗漏了。如果没有测试用例来兜底,很多场景可能在执行的过程中就会被忽略掉了。我们可以在测试过程中去扩展测试场景,但已思考过的测试场景一定要得到执行和反馈。

至于说测试用例是否一定要满足八大要素?个人认为并不重要,只要团队形成共识就可以了,不管是Excel,还是Xmind,更或者是用例管理系统管理,都是可行的。

2. 有效的测试用例设计

那么如何进行高效的测试用例设计呢?常见例如等价类、边界类及错误推测法等等,在这里不展来说啦,网上有太多的资料。文章底部还会推荐一篇关于测试用例设计的“兵器谱”。个人在这里主要说两点想法,仅供参考:

目标导向:再好的测试设计方法论,都无法完全覆盖所有场景,所以我们要清楚地知识当前迭代或者版本的核心问题是什么,我们需要提供什么样的价值,用户在哪些场景下会去使用什么功能,需要思考和调研清楚,把自己当成用户来设计用例。再适当辅以异常场景验证系统的健壮性和可靠性。

清晰的结果验证:对于每个场景的预期输出,需要有合理的、科学的验证手段,不能仅限于页面的返回或者提示,需要深入验证每个环节的输出是否符合预期。

3. 不同阶段的选择

当团队成员经验较浅或者项目比较重要,那我们可以编写更详细的测试用例,来培养团队或者个人的测试思维,来验证版本或者迭代中的核心功能。

如果团队成员的能力较强时,我们只需要罗列出测试点即可,依托于个人的测试经验,来节约编写测试用例的时间成本,但不可以不写用例,它能在你疏忽的时候提醒到你还有哪些测试需要执行。

对于敏捷研发团队来而言,因为团队相对固定,而且全程都参与了需求的梳理和确认,并编写AC确认。所以对需求有了较为深刻的理解,对于测试用例的内容和形式要求并不是那么高,但是要写好回归测试用例。

由于不同的团队和不同的项目情况不同,所以没有一种最佳方法适合于所有团队。测试用例需要根据自己团队和项目的特点和情况,选择适合并且实用的测试用例编写方法,从而更好的维护和执行测试。

测试用例可以简单,但不能没有。

4. 对测试用例的其他理解

  • 测试用例不是测试人员的安全绳

对于评审过的测试用例,测试人员可能会有一种莫名的“安全感”,感觉只要执行完这些测试用例就可以了,产品的质量就可以得到有效地保障,最后出了问题,也不是测试的问题,因为测试用例得到团队的评审,如果有遗漏,那是大家都忽略的,我的责任也轻点,是大家都没想到,而不仅仅是我一个人没想到。这种想法非常不可取。

  • 测试用例是逐步完善的

随着测试人员对需求的理解不断加深,会有更多的场景涌现出来,需要我们不断地去补充和完善自己的测试用例。同时,伴随着系统的实现,我们对技术的了解也会更深,常见框架和中间件等一些技术问题也会逐渐浮现出来(例如一致性,时效性,可靠性等问题),需要我们通过更多的场景来验证。

  • 用例“前置条件”不一定能轻易实现

我们在写用例时,一般都会写前置条件,在用例中写起来可能只是一句话,但这些前置条件其实并不是那么容易构建出来的,比如一些支付场景、审批流、第三方回传数据,甚至于异常场景等等,需要测试人员有一定的技术能力去实现出来。

  • 用例越来越多,需要适当做减法

随着版本的迭代,我们的测试用例会逐步增加,如果不适合做减法,那最终的结果就是用例无法维护,慢慢失去作用。有一种比较好的方法就是把已经相对稳定的功能自动化(不管是UI还是接口),从而减少功能测试用例,让自动化替代人工做一些事。

5. 小结

本文结合个人的经验,对于测试用例,给出了自己的看法:测试用例是自己测试思维的一个载体,它指导着测试活动的进行,是测试执行的最低保障。至于以什么形式来承载,并不重要。处于不同阶段的团队对于测试用例的颗粒度也有不同的要求,可以从不同的目标来确认用例的颗粒度,只要团队形成统一的共识即可。同时,对于测试用例,会有一些额外的思考,大家也可以一起探讨。

附:

测试建模“兵器谱”:https://mp.weixin.qq.com/s/Oh4EbTngfQSvHx-WXwsSlg

林冰玉老师对测试用例的看法:https://mp.weixin.qq.com/s/YyEeN63bHZEQlHRaE9D4Vg

本次话题就聊到这里,接下来,我们聊点什么呢?敬请期待。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
166° /1666 人阅读/0 条评论 发表评论

登录 后发表评论