想快速又简单地编写测试用例？看这里！
本文适用对象
初级软件测试人员,或想开拓思路拓展测试范围、提高测试覆盖率的所有测试人员等等。
本文目的
讲述如何快速、简单、有效、有条理地编写一条测试用例,并帮助测试人员从测试用例角度拓展测试思路。
如何简单、快速地
描述(编写)一个测试用例
测试用例的目的在于指导、帮助测试人员按照既定的计划步骤执行测试,并比对测试结果与预期结果是否一致。
对于中大型软件公司而言,测试用例的管理都有既定的规范和工具,如表格管理用例、测试管理软件管理用例(如下图1所示为MeterSphere测试管理软件用例编写页面)等。
但总而言之,测试用例的内容主要不外乎3个部分:前置条件、步骤、预期结果。
那么,对于没有明确地测试管理软件的小型软件公司,或者对于测试人员而言,需要暂时快速地编写一个测试用例或记录测试过程的时候,可以怎么做呢?
推荐一个临时性的用例编写模板:GIVEN...WHEN…THEN。
让我们套用GIVEN…WHEN…THEN的模式来描述下编写用例的大致步骤:
有没有觉得很简单?
让我们再用实际案例,描述下如何用GIVEN…WHEN…THEN模板编写真实用例。以测试访问 链接这个用例为例1:
使用GIVEN…WHEN…THEN能够简单呈现用例前置条件、执行步骤和预期结果间的逻辑关系,并能清晰地表述一个用例。
那么,什么地方可以用GIVEN…WHEN..THEN这个模板呢?这个模板较之文档用例更为简洁,如下图2所示,对于测试用例提交故障,阐述引发故障的操作方法或故障复现方法,以及故障修复后的验证时都可以使用。
如何使用探索式场景联想法
衍生测试用例
探索式测试更多的是一种测试风格和测试思想,要求测试人员在测试过程中不断思考、发散思维,记录、修改和更新测试方法和测试用例。
场景法则是要求测试人员认真分析测试需求,了解用户使用场景,根据不同的场景进行测试。
而本文讨论的
探索式场景联想法,则是将探索式测试方法、场景法和联想法相结合,在已有测试用例的基础上衍生更多的测试用例。
那么,如何使用探索式场景联想法衍生测试用例呢?
由上一节可知,测试用例是指导测试人员在xx预知条件(场景)下,执行xx步骤,预期得到xx结论。
显而可见,通过改变测试用例的预知条件和操作步骤,则可以衍生出不同的测试用例。而这些测试用例包含不同的测试场景和不同的测试步骤。
如下图3所示,为探索式场景联想法衍生测试用例的结构脑图。
改变前置条件
测试用例的前置条件基本包括:硬件资源和软件系统两个部分。
改变前置条件可以从这几方面入手。
以上节的访问 链接用例1为例,改变前置条件衍生新的测试用例。由于该用例的前置条件较简单,改变前置条件只需改变浏览器类型和版本即可。
由此,衍生的部分测试用例可如下所示:
改变操作步骤
改变用例操作步骤可以从以下几方面入手:插入步骤、删除步骤、改变步骤和重复步骤。
插入步骤
如图3所示,插入步骤又可以分为插入相关联步骤和不相关联步骤。并在插入步骤中增加用户输入。
同样以用例1为例,插入步骤衍生的测试用例可如下:
删除步骤
删除步骤可以分为删除部分步骤或者删除部分步骤中的部分操作。删除部分步骤,又可以分为删除关键步骤和非关键步骤。
例如,以例1为例,删除关键步骤“点击键盘回车键“衍生新的测试用例如下所示:
改变步骤
改变步骤主要涉及步骤顺序的改变和步骤内容的改变。当测试用例具有多个步骤,且步骤间具有关联性和顺序性的时候,改变步骤顺序则会变得很有意义。改变步骤内容主要是改变步骤中用户的输入(包括数据输入、用户操作等)。
以用例1为例,改变步骤内容衍生的用例如下所示:
重复步骤
对于大多测试人员来说,衍生测试用例时更多关注点在于操作步骤的变化。
但是,对于不同的测试场景,重复相同的测试步骤,仍然具有很大的测试意义。重复步骤进行测试能够挖掘不同前置条件(场景)下的故障,亦能挖掘软件在多个重复步骤操作下潜藏的故障。
以用例1为例,重复步骤衍生的用例如下所示:
测试结论衍生测试用例
除了通过改变前置条件和操作步骤衍生测试用例外,还可以根据测试结论中的异常信息,逆推测试场景,衍生新的测试用例。
这个部分更多的需要测试人员掌握探索式测试方法,对测试过程中的软件资源监控信息、错误日志等保持警惕性,挖掘错误信息中的内容,逆推产生错误信息的原因,构建新的测试用例。
小结
本文阐述了一种可以在提交测试故障信息和验证测试故障时使用的快速测试用例编写模板,快速记录测试场景、测试步骤等关键信息。
并在此基础上,简单讲解了基于探索式场景联想法的测试用例衍生方法,可以帮助测试人员借助已有的测试用例拓展新的测试用例,扩大测试范围,提高覆盖率,挖掘更多场景下的软件故障。
转自公众号投稿:
怎么编写王者荣耀背包的测试用例
没办法看到
王者荣耀
的策划案,不过背包
用例
不外乎几种操作,我对着背包界面写了个大概的检查点,实际上全部内容扩展出来应该有100多条,请根据实际情况增补。
背包界面的基本展示,进入、返回。
左侧的7个标签:全部、最近获得、道具、礼包、体验卡、局内表现、铭文,这些分类按钮是否能正常点击切换,每个物品的类别是否正确。点全部是不是所有物品都显示了,每个类型的该出现在哪的就出现在哪,某个分类里不应该出现其他分类的东西。
背包中每页显示多少个物品,背包为空的时候进入退出是否正常,少于一页是否能正常显示,多于一页是否能正常翻页。
背包中有多个物品种类时,排序是否正常(要和策划、开发确认默认的排序是什么),反复进入、退出、用掉一两种物品,排序是否会乱。
获得一个物品,检查这个物品是否正常放入背包,是否正确排序。在王者荣耀中,能够获得的物品包括:铭文、皮肤
碎皮
、英雄碎片、英雄体验卡、皮肤体验卡、双倍金币卡、双倍经验卡、改名卡、活动道具(喇叭、优惠券、限时播报和回城效果),每种写一条用例。
使用一个物品,这个物品还有剩余,检查物品数量是否-1。(以上所有物品都用一遍)
使用一个物品,这个物品全部被用完了,检查背包内的物品是否消失,排在后一位的物品是否自动填补这个物品的空位。
批量使用物品,但是不用完,检查物品数量,检查该物品的效果是否生效。
批量使用物品,当某种物品用完时,排在后一位的物品是否自动填补空位。
出售一个物品、批量卖出物品,照着使用物品的用例,把使用换成卖出再测一遍。
当物品是铭文时,装备、卸下、分解铭文,检查背包里的铭文内容是否正常变化。
物品叠加上限(如果有),这个要找开发确认,每一格最多叠加多少个,如果玩家有生之年能叠到上限,那么测一下达到上限时,再获得一个会怎样,是另开一格叠加,还是不再获得,必须用掉才能获得。(总之要有个处理方案,不能崩了客户端)
接上,物品叠加到上限后,用掉或卖掉几个,再重新获得,能不能正常叠加。
背包上限(如果有),同样找开发确认,背包一共有多少个格子,现有的道具种类能不能塞满格子,如果能塞满,那么测一下背包格子塞满的时候,再获得一种物品会怎样,是不是能正常提示背包满了?
接上,背包满了之后,用掉或卖掉一种物品,再获得这种物品或者其他物品,是不是能正常获得了。
如何设计一个完整的测试用例
软件测试的W模型,就要求测试与开发同步,在开发设计需求设计说明书的时候就开始测试流程,一般情况下,讨论需求设计的时候需要测试主管或者组员的参与,了解这个项目设计的总体情况
事实上,测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的
因为测试用例的内容要以需求设计说明书为依据,设计说明书上没体现的功能,不需要在测试用例中体现
编写测试用例(这里指功能测试用例的编写),首先要做的就是设计测试用例的模板
每个公司都有适合自己公司用例编写的模板,各有各的特点
测试用例的格式包括,测试用例摘要、测试用例需求编号(一个需求设计说明书可以分好几个用例编写)、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等
格式没有固定的要求,可以根据自己测试用例设计的思路,对测试用例的格式作相应的改变
下面以一个登陆窗口为例,说说我设计登陆界面的思路和方法
我把这个测试用例分为三层结构,表单测试、逻辑判断、业务流程
第一层,表单测试为最底层(最基础的)
这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试
一般来说登陆用户名和登陆用户密码是输入框的形式体现,那么,我们需要的是针对这两个输入框进行功能的测试
这时,我们只要考虑这个输入框的功能,而不需要考虑业务方面的内容
这样,我们考虑就是这个输入框的长度限制是多少?能否输入特殊字符?能否输入全角字符?当然,登陆窗口还有其他按钮,例如登陆按钮、退出按钮、界面设计等,这一层的测试用例只对他们最简单的功能的测试
我觉得这一层的测试用例对新开发项目很重要,也必须执行,因为这些是最基本的功能保证,当项目进入维护阶段后,如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低,时间不充足的情况就不用去执行
第二层,逻辑判断层
根据需求的设计,各功能之间的简单逻辑联系
以登陆窗口为例,账号登录,账号和密码必须对应才能登录,否则登录失败
根据这一点,我们就可以从这个要求设计这一层测试用例
例如,账号和密码不一致时;账号为空时;密码为空时;账号密码对应时等等情况
输入这些情况时,程序是作怎么样的逻辑控制的?控制是否正确?是否有相应的提示信息?我觉得,这一层的用例时最常规的一层,平时使用这个软件用经常碰到的一些情况,在常规测试或修改这部分的功能之后,这一部分的测试用例也必须执行
第三层,业务流程层
这部分不关心软件的本身的基本功能,而是关心这个软件的业务有没有实现,不同的需求就有不同的业务需求
以登陆窗口为例,就可能有不同的需求,可能用户要求停用的账号能够登录系统(可能要求登录后不允许进行其他操作),也可能用户直接要求停用的用户账号不准登录系统
根据不同的业务需求,就有不同的业务流程
这样这层的测试用例,我们就只要考虑业务需求,仍然以登录窗口为例,我们就只要考虑删除的用户能否登录?停用的用户能否登录?超级用户是如何登录的?普通用户是何种方式登录的?简单的说,这层的用例只描述业务流程,不关心具体这个业务是怎么实现的,执行这部分用例时,不要考虑哪个输入框控制了多少长度,能否输入空格等其他功能,因为这部分的测试需要基于上面两层的测试用例都已经测试通过了,所以在项目维护阶段或者说时间很紧迫的阶段,我们只需要执行这部分的用例,保证业务能够通畅的完成
其实个人觉得在执行这部分用例时,对包含了对基本功能的测试,一些明显的问题应该能被发现,虽然严格来说测试覆盖率很低,但是基本能达到要求
这三层的组合起来才是一个完整的测试用例
这是我个人对测试用例设计的一个思路和方法
真正设计这个测试用例的时候,可能会使用到黑盒测试用例的方法,例如等价类划分、边界值分析、错误猜测法(主要是个人经验)、正交分解等方法针对具体情况设计测试用例
分层测试用例的思路主要来自对自动测试实现的考虑
因为我觉得,如果需要实现自动化测试就必须对测试用例进行细分,划分得越细就越有利于自动化的实现
以上三层的划分也并不是很全面,需要在实践中不断完善,例如可以增加对数据库的部分功能的数据校验的分析
总之,测试用例写的细致、全面、步骤清晰,那么无论是用手工测试的方法还是用自动化测试的方法实现,只要能完整的跑完整个测试用例,就达到了测试的目标了
