测试用例的设计方法-理论篇

网友投稿 923 2022-05-30

对于QA来说,测试用例就是我们的源码库。测试用例的重要性自然也是不言而喻的,相信每一个QA都曾在“写不完”的测试用例文档里挣扎过,也可能至今还有着——到底什么样的测试用例才是是好的测试用例——这样的疑问。

今天想从实用的角度总结一下测试用例的设计方法,本文是理论篇,内容包括什么是测试用例,为什么需要测试用例,以及常用的测试用例设计方法;后续还会有实用篇向大家分享,我在平常的工作中是怎么写测试用例的。

1. 什么是测试用例

软件测试员做些什么: 发现软件缺陷 (而不是简单得验证功能是否实现) ; 尽可能早地找出软件缺陷; 并确保其得以修复。 ——Ron Patton 《软件测试》

测试用例(Test Case),就是为了验证某个需求是否实现、是否存在缺陷,在测试执行之前设计的一套详细的测试方案。测试用例通常由测试标题、前置条件、测试数据、测试步骤、预期结果等组成。

敏捷开发团队中,测试用例的设计和执行通常都是一个人,这时,对测试用例文档通常没有严格的格式要求,清晰准确即可!

2. 为什么我们需要测试用例

- 如果我们不使用测试用例,难道就没办法检查出缺陷吗?

- 可以不编写测试用例直接进行测试,但这样是有风险的,不能够保证全面覆盖。除此之外,测试用例还可以:

· 体现QA了解需求的过程

敏捷开发团队中,QA通常是从IPM阶段开始接触到新的需求,此时用户故事的需求描述、Acceptance Criteria、原型图等都已基本完成。QA在编写用例的过程中,将仔细梳理整体业务流程、充分思考产品需求的细节,找出需求是否存在不合理、有矛盾、不明确等问题,从而推动BA/UX完成更加详细的设计。

· 帮助QA理清测试思路及测试过程

测试用例的设计方法-理论篇

测试用例的编写,实际上是把需求转换为一种可操作步骤的行为。QA也没有那么强大的大脑能够把所有的操作步骤都记在脑海里,写下来不仅能帮我们记住,写下来的这个过程也是梳理测试思路的过程。特别是,当你将当前需求的用例都罗列出来时,也能很清晰规划之后的测试顺序。

· 规划测试数据的准备

我们可以看到,在测试实践中,测试数据是与测试步骤分离的。在测试执行前,按照测试用例准备一组或若干组测试数据,特别是一些需要其他人协助准备的测试数据,这十分有助于高效的测试执行工作。

· 记录测试所覆盖的测试内容,同时反应测试进度

依照测试用例执行测试,并及时记录每一个测试用例的测试结果,这样项目成员都能够清楚地了解到目前已经完成了哪些测试,这些测试覆盖了哪些需求。那么在一些突发情况下,比如你被调离或离职,别人也能迅速了解测试覆盖内容及测试进度。

· 为后续的测试提供可参考的依据

新加入的功能可能会影响已有功能,新的需求是对原来的功能进行优化,新版本要上线等,项目进行过程中有这很多情况,都需要QA进行回归测试,有了测试用例,回归测试就能按部就班进行。

· 是分析缺陷的标准

测试用例并不是一写完就再也不用更新了。通过记录的缺陷数据,与测试用例进行对比,分析是否存在漏测情况,即当前测试用例是否能够覆盖该缺陷,若未能覆盖,说明当前测试用例集不完善,应补充相应测试用例;若已有相应测试用例,则表明测试执行过程中存在问题。

简单来讲,测试用例能够帮助我们在测试执行前澄清需求、梳理测试过程,并提前规划好测试数据;在测试执行中作为清单使用,记录测试覆盖的内容、反应测试进度;测试执行后也能作为回归测试等的参考,能与缺陷记录结合分析,来不断完善测试用例本身。

自动化测试

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:张小白带你体验MindSpore 1.3的新特性:MindSpore Lite端侧训练的实现(C++)
下一篇:Vuepress + GitHub Actions 实现博客自动部署!
相关文章