测试工程师在入行时,都会接触到一个名词——测试用例,都知道测试用例是干什么用的,提到设计测试用例的方法,大部分测试工程师都会侃侃而谈:等价类法、边界值法、判定表法、正交分解法……这些方法说起来都如数家珍,但是似乎在实际工作中,应用起来还不是那么得心应手,甚至还会有测试用例覆盖度不足的问题。
每当遇到这样的问题时,测试工程师多少都会有些无奈。测试用例写的已经尽可能详细了,但是评审时候,参与评审的角色,要么是因为用例太繁复而草草浏览一下,要么是说完后面忘了前面。而测试工程师的思路从思维导图转化为测试用例的时候,也往往达不到测试用例最初的目的——哪怕让小白来遵照执行,也应该可以看得懂。
那么作为测试工程师基本功的测试用例编写,应该怎样上手呢?遵循着设计方法的测试用例,为什么写出来会那么晦涩难懂,让人很难理清思路呢?
一般说来,测试用例的覆盖设计和思路,同操作流程和开发思维是有极大不同的,除了实现验证这样的正向思路方向外,还需要针对异常情况进行逆向验证,而这里往往是很容易出现遗漏的地方。因为场景实现是有明确的操作流程的,而异常处理的场景,则是需要测试工程师自己进行分析的。
测试用例一般来说,分几大模块组成,主要的有操作步骤,输入数据,期望结果。需要注意的是,操作步骤是必须的,但输入数据允许留空,因为在很多时候,步骤仅仅只是一个动作,比如检视页面。对于测试用例的理解来说,操作步骤应该是非常细致的。以如下一个界面为例,详细了解一下测试用例到底该怎么写。
这是Slackflow的官网页面,选取了最常见的“注册”模块来进行UI的测试用例设计。首先按照场景分析,要先分为正常和异常两种情形,异常情况则是分析如下:
那么按照测试用例编写思路,需要形成如下表格:
在表格中体现的则是测试用例书写的一些规范和注意点:
1)操作步骤叙述必须足够简练明确,不得出现断层或无法执行的操作;
2)操作步骤必须具有由上至下的连贯性;
3)输入数据必须有具体示例,如字符串等等,如果没有具体示例,则需要说明输入的规范;
4)期望结果是需要一目了然的结果,而不是需要进行其他操作之后才能查看的内容,不可以包括多余的动作,也不可包括含混不清的判断,如仅注明“显示正常”,没有进一步的描述,或“顺利登录”这样的描述。
5)每一步都要进行的操作步骤,可以提炼为前置条件,写在“Pre-Condition“栏内
6)每一步骤和结果的描述必须精准洗练,不可以冗余和重复
7)每一个测试用例只覆盖一个检查点,如果多个用例都需要覆盖中间某一个检查点,则需将该检查点作为一个独立的测试用例,其余测试用例将该检查点的结果作为前置条件。
测试用例作为测试的输入文档,以及自动化测试的基础依据,应该是简洁优美的,它体现了测试工程师思维的逻辑性和递进性,它的质量直接关系到测试执行的质量,而执行时所能够达到的覆盖度则往往是测试工程师基本功的体现。
所以,在不断将眼光投向自动化代码能力和其他测试领域扩展的时候,还是需要先夯实自己的业务基础,先编写出简洁、全面的测试用例。
文末了:
可以到我的个人号:atstudy-js,可以免费领取一份10G软件测试工程师面试宝典文档资料。同时我邀请你进入我们的软件测试学习交流平台,大家可以一起探讨交流软件测试,共同学习软件测试技术、面试等软件测试方方面面,了解测试行业的最新趋势,助你快速进阶Python自动化测试/测试开发,稳住当前职位同时走向高薪之路。