微信扫描登录

一张涂鸦搞定测试用例设计
作者:梅子

没错,我就是上次和大家聊涂鸦的女青年。今天想给大家分享的主题是“如何进行用例设计”。“测试设计”对测试者来说是一项比较重要的技能,虽然目前不乏测试设计的材料,但是测试者还是普遍感到对用例设计有如下问题:

  • 测试用例不全,总有遗漏。
  • 测试用例冗余,不同的用例测试的都是同样的地方。
  • 测试方法很多,但是不知道该怎么用,总觉得方法不合适。
  • 测试用例 不易读,目标不够明确,不同的人执行相同的用例效果差别很大。 这些问题总结起来就是几个字“缺原则”和“缺套路”。

作为一个爱好涂鸦的女青年,我想通过涂鸦的方式来向大家分享我总结的测试设计的“原则”和“套路”。

enter image description here

一次完整的用例设计,其实包含了两个活动:测试分析和用例设计。前者的目的是得到“测试点”,后者是对“测试点”进行组合、拆分后,再使用各种测试设计的方法和一些文字描述方法,来得到测试用例。 下面是一个“测试点”和“测试用例”的例子:

  • 测试点:

    enter image description here

  • 测试用例:

    enter image description here

而上面的这张涂鸦,就总结了如何快速分析被测对象,得到测试点,再从测试点得到测试用例的过程。

1. 使用“车轮图”来快速对被测对象进行分析,得到测试点

所谓“车轮图”,就是下面这幅图:

enter image description here

车轮图分为三层,中心是产品(在使用时也可以是某个特性),第一层是软件质量六属性(功能性、效率、易用性、可靠性、可移植性和可维护性等),第二层是测试类型,第三层是测试方法。我们将车轮图从内到外解读,就是测试者对某个产品(或功能),要从哪些角度(质量属性)去进行怎样的测试(测试方法),概括来说就是解决了“测什么”和“怎么测”的问题。

“车轮图”能够很好的解决“测试的广度”和“测试的深度”的问题。

  • “车轮图”如何来保证测试的广度?

    从软件质量的角度来说,软件需要满足质量六属性的要求。车轮图可以保证测试围绕质量属性展开测试覆盖。无论测试者的经验如何,车轮图都可以帮助他的测试内容可以覆盖基本的质量属性,不会出现大方向大块面的遗漏。

  • “车轮图”如何来保证测试深度?

    一般来说,一个测试者可以使用的测试方法越多,对产品测试得就越深。车轮图第三层就是测试方法,无论测试者的经验如何,测试者都可以根据车轮图中的测试方法,来对被测对象进行系统的分析和深入的思考,快速找到测试点。

  • 如何使用车轮图?

    想在实际项目中使用车轮图非常容易,用普通的思维导图工具就可以了,非常适合测试者对被测对象进行分析的测试设计过程,如下图所示:

    enter image description here

    前面我们举的测试点的例子,就是使用车轮图来进行测试分析的实例,大家不妨移步到前面参考。

  • 车轮图还有哪些用处?

    车轮图除了用来进行用例分析外,还有两个非常好用的作用:

    • 作用1:用车轮图来进行测试设计评审

      测试用例评审是个很让人抓狂的工作,很多人看到别人分析出来的几十条乃至几百条用例,几乎不知道该如何下手去评审。有了车轮图,测试设计的评审就变得容易多了。评审时,我们可以先check用例在测试类型的分析上是否正确,测试类型是否足够,或者考虑得过多了。然后逐一check每个测试类型的测试点是否充分或者考虑得过多了。车轮图可以帮评审者快速确定用例设计者的思路,高效定位到测试设计的问题。

    • 作用2:用车轮图来进行开发设计的评审或者讨论

      我们常常会说,测试对项目有个重要的价值,就是测试的视角可以帮助开发提前发现设计中考虑不周到的地方,起到预防缺陷的作用。车轮图,就是测试视角的集中体现。

      我们可以按照车轮图里面的内容,来对开发的设计方案进行check和讨论,确保开发在设计的时候的时候对质量属性有较为全面的考虑,对功能交互有足够的考虑。不要小看这样的沟通交流,它可以帮助测试者避免落入顺着开发的设计思路来确认开发的设计的陷阱,真真实实的起到缺陷预防的作用。

  • 如何才能让车轮图在团队中发挥最大的作用?

    车轮图是一个通用框架,要想在团队中发挥最大的作用,就需要我们根据当前产品的特点,来总结最适合的测试类型和测试方法。

    测试类型对很多测试者并不陌生,常常可以如数家珍。但大家说到“测试方法”,却不一定能够说清楚。有的测试者会用黑盒测试或者白盒测试来定义测试方法,有的测试者则认为测试方法是自动化测试或手工测试。我认为测试方法应该和测试层次和业务相关的,可以操作的具体方法,每种测试方法都可以发现不同的缺陷。

talk is cheap,我们来看一些我总结,适合我的测试产品的一些测试方法,供大家参考:

功能测试法:

  • 单运行正常值输入法。例如“用户发送了一封电子邮件”(参数都是正常的,最普通的情况)
  • 单运行边界值输入法。例如“收件人的数目为系统支持的最大数”
  • 多运行顺序测试法。例如“用户收到一封电子邮件后,再接着发送这封收到到电子邮件”
  • 多运行相互作用法。例如“用户正在发送电子邮件的时候,用户又接收到一封电子邮件”。

2. 如何对测试点,快速进行用例设计的方法

很多时候,我们只做到用车轮图分析后得到的测试点后,就没有再进行做下去了。没有继续做下去的原因一般是认为写成用例的那种格式太繁琐,太费事。或者是认为测试点就是测试用例了。

事实上,我们通过车轮图得到的测试点,测试点之间很容易出现“包含”或者“重复”的情况。还有测试点一般都没有明确测试数据,即测试的输入输出,很容易造成测试覆盖遗漏或者不同的人测试执行情况不一的问题。所以比较严谨或者说传统的方法是对测试点再进行一次加工,“去重”(去掉重复的内容)、“合并”(把太细的测试点合并起来)、“细化”(把太泛的测试点说清楚说具体),然后再确定各个“测试点”的“测试条件”、“测试数据”和“输出结果”,得到我们说的测试用例。

要想快,就要先慢。把标准动作做到位,把用例的组织和管理的规范设计好,自然就能快起来。而不是一开始为了快去快,使得整个团队都在不断的疲于奔命。

当整个团队都能够把用例设计的套路了然于心了,只用车轮图来进行用例设计和跟踪确实就够了——因为大家都知道后面的动作该怎么做了。写不写出来,就是一个形式了。

现在我们先来讲这个完整的用例设计套路。

整个套路分为四个步骤,有四种不同类型测试设计模型,如下图所示:

enter image description here

这四个步骤分别是 “建模”->“覆盖模型”->“补充测试数据”和“扩展”。四种不同类型的测试设计模型为“最小线性无关覆盖模型”,“输入输出表模型”,“等价类/边界值模型”和“因子表-Pairwise模型”。

对测试点进行建模的第一步是我们要先能够读测试点进行正确的分类。我们将测试点分为如下四类:

  • 流程类的测试点:这种测试点有明显的步骤的特点,可以绘成流程图。
  • 参数类的测试点:这类测试点包含的是一些输入的参数。
  • 数据类测试点:这类测试点是一些输入的数据。
  • 组合类测试点:包含前面三种特点的测试点。

例如:

“PC连接Wi-Fi”这个功能包含如下“测试点”。

  1. 首选Wi-Fi网络可用时选用首选Wi-Fi网络。
  2. 首选Wi-Fi网络不可用时,可以选用备选Wi-Fi网络。
  3. PC可以连接加密的Wi-Fi网络。
  4. PC可以连接不加密的Wi-Fi网络。
  5. PC可以设置加密的Wi-Fi网络的加密算法,分别为为:“WEP”、“WPA”和“WPA2”。(为了简化,我们约定PC只能选择一种加密算法)。

从测试点的描述来看,“测试点1”和“测试点2”描述的是“选择Wi-Fi网络”,“测试点3”和“测试点4”描述的是“判断Wi-Fi是否需要加密”和“连接网络”。“测试点1”~“测试点4”每个测试点都描述了“PC连接Wi-Fi”的一些操作步骤,共同描述了整个流程,它们属于“流程”类的测试点,在测试设计时,我们就可以把这4条测试点放在一起进行分析。

“测试点5”虽然可以归属于“判断Wi-Fi是否需要加密”这个步骤中(如果配置了上述加密算法中的任意一种,就表示需要加密),但是这条测试点是从“支持的配置参数”这个角度去描述的,并没有去描述一个步骤或是一个流程片段,而且从流程上来说,无论我们选择哪种加密算法,都不会影响“判断Wi-Fi是否需要加密”这个结果,所以它不属于流程类的测试点,我们可以将其认为是参数类的测试点。

我们也可以将“测试点1”~“测试点5”放在一起考虑,当然这就构成了“组合”类的测试点。

我们将“测试点1”~“测试点4”和“测试点5”分开来考虑,是为了能够分别验证“PC连接Wi-Fi”的连接流程的正确性和每个加密算法在实现上的正确性。这样设计出来的测试用例也会更关注设计,更关注功能在实现上的细节,在测试时也能比较多的发现这些方面的问题。

如果我们将“测试点1”~“测试点5”组合在一起考虑,更多的是站在系统的角度上来进行测试,能够测试到各个功能之间的配合和系统整体相关的一些问题。

再例如,对“Wi-Fi上可以修改Wi-Fi网络的默认名称”包含的测试点是:

  1. 可以通过Wi-Fi的管理口直接登录到Wi-Fi上修改Wi-Fi网络的名称
  2. PC连接成功后,可以登录到Wi-Fi上修改Wi-Fi网络的名称。
  3. Wi-Fi网络支持的名称为: 1~10个字符,允许输入为“字母”、“数字”和“下划线”,不允许其他的输入。

我们先来看“测试点3”。“测试点3”描述了“Wi-Fi网络名称”的“长度范围”和“命名限制”,满足前面我们讨论的“数据”类测试点的特点,属于“数据”类。

而对“测试点1”和“测试点2”而言,它们描述的是“修改Wi-Fi网络名称”的“条件”:

  • 条件1:“通过Wi-Fi的管理口直接登录到Wi-Fi上去修改”。
  • 条件2:“PC连接成功后,PC可以登录到Wi-Fi上去修改(即通过Wi-Fi的业务口去修改)”。

它们不能脱离开“测试点3”而单独存在。因此,“测试点1”和“测试点2”需要和“测试点3”放在一起考虑,将它们整体归属为“数据”类。

接下来就是对测试点选择合适测试设计方法来建模。

一、流程类

我们先来看流程类的测试点,我们使用的是“最小线性无关建模法”。具体操作方式是对测试点绘制流程图:

在这个步骤中需要特别注意的地方是:

  • 测试者要充分理解和测试点相关的功能业务流程,确保流程图的正确性。
  • 测试者要和产品设计者充分交流,保证绘出的流程图能够正确覆盖产品的设计。
  • 如果开发已经提供了该功能的流程图,测试者需要仔细审视流程图的正确性,如有必要可以重新绘制。

我们来看看我们对“PC连接Wi-Fi”这个功能的“测试点1”~“测试点4”绘制相关的业务流程图:

enter image description here

接下来我们就使用“最小线性无关路径覆盖法”来得到测试路径。

仅“保证流程图中每个路径片段能够被至少执行一次”,在这种覆盖策略下得到的“最少路径组合”,就是“最小线性无关覆盖”。

下面的算法能够帮我们得到一个流程图中的最小线性无关路径:

enter image description here

按照上述算法,对下面这个简单的流程图,我们可以得到如下四条“线性无关路径”:

enter image description here

但实际中的流程图一般都比较复杂(至少也是我们例子中那样的流程图)。需要特别指出的是,如果流程图中有多个输入或者多个输出,都需要将流程图拆成只有一个输入口和一个出口的情况,才能使用上面的方法来获得最小线性无关路径。

例如,下面是有两个输入的情况:

enter image description here

我们需要将其拆解为两个流程图,使得拆解后的每个流程图都只有一个输入,一个输出,如下图所示:

enter image description here

我们再来看“PC连接Wi-Fi”这个功能的“测试点1”~“测试点4”的业务流程图,这个流程有两个输出,我们对这个流程图进行拆解,拆解后的子流程图如下:

子流程1:

enter image description here

子流程2:

enter image description here

我们对这两个流程,分别使用最小线性无关的建模方法,得到路径集合为子流程1的最小线性无关路径集合:

  1. 首选Wi-Fi可用,加密,连接成功。
  2. 首选Wi-Fi不可用,备选Wi-Fi可用,加密,连接成功。
  3. 首选Wi-Fi不可用,备选Wi-Fi可用,不加密,连接成功。

子流程2的最小线性无关路径集合:

  1. 首选Wi-Fi不可用,备选Wi-Fi不可用,连接失败。
  2. 首选Wi-Fi不可用,备选Wi-Fi可用,不加密,连接失败。

然后我们再为每条路径确定相关的测试数据,就完成了这些测试点的用例设计。

当然,建模只是套路,经验也是测试者很宝贵的财富。我们可以根据经验再对这些补充一些测试用例。后面的所有建模,都应该根据经验再补充一些测试用例。

二、参数类

接下来我们来看如何对参数类的测试点进行用例设计。

对参数类的测试点,我们可以用“输入-输出表”的方式来建模。一个常见的输入输出表如下所示:

enter image description here

接下来我们以“PC连接Wi-Fi”的“测试点5”为例,使用“输入-输出表”来进行测试建模。

“测试点5”的参数为“安全性选择”,包含了3个“参数值”:“WEP”、“WPA”和“WPA2”。

根据上一节中对“流程”类测试设计的分析,我们知道“测试点5”有两个“条件”:“首选Wi-Fi可用,加密”和“首选Wi-Fi不可用,备选Wi-Fi可用,加密”。在这里我们任意选择其中一个条件。这样我们就得到了“测试点5”的“输入-输出”表:

enter image description here

然后我们只需要将表中的每一行,作为一个测试用例即可完成相关的测试用例设计。

上面这个例子向我们展示了“输入-输出表”的使用方法,却没有很好的体现出“输入-输出表”的优势——“输入-输出表”特别适合对测试点的多个“参数”之间存在相互关系,需要对这些“参数”进行“组合”分析的情况。限于篇幅限制,感兴趣的读者可以直接向我索要其他的例子。

三、数据类

接下来我们来看如何对数据类的测试点进行用例设计。

对数据类的测试点,我们用的是“等价类-边界值”的方式来建模。等价类分析表是一张对数据在特定条件下,对数据的有效输入和无效输入进行分析的表。如下表所示:

enter image description here

我们对“Wi-Fi上可以修改Wi-Fi网络的默认名称”包含的测试点,使用等价类分析表进行分析,如下:

enter image description here

相信大家已经发现,在两种条件下,有效等价类和无效等价类都是一样的,相应的输出也是一样的。我们可以对上述“等价类分析表”进行合并:

enter image description here

然后我们再为表中的每个“等价类”来确定边界值,就可以得到我们的测试用例:

enter image description here

四、组合类

对组合类的测试点,我们可以使用因子表来进行建模,然后直接使用PICT测试用例生成用例得到测试用例。

因子表,是测试点需要考虑哪些方面的表,可以是每个因子的内容,可以是参数,可以是条件,也可以是使用等价类和边界值分析法得到的测试数据。

下表是一个因子表示意图:

enter image description here

需要特别注意的是,如果因子之间存在一定的约束关系,如因子A取值为A1时,因子B只能取值为B1;因子A取值为A2的时候,因子B只能取值为B2、B3、B4,我们就需要将这张因子拆开,建立两个因子表。

我们来看“PC连接Wi-Fi”的“测试点1”~“测试点5”为例,使用“因子表”来进行测试建模。

首先我们来分析一下这些测试中包含对因子:

  • 从测试点1和测试点2中,我们可以提取出“因子1”:“Wi-Fi网络选择”。该因子的取值为“首选Wi-Fi网络”和“备选Wi-Fi网络”。
  • 从测试点3和测试点4中,我们可以提取出“因子2”:“是否加密”。该因子的取值为“加密”和“不加密”。
  • 从测试点5中,我们可以提取出“因子3”:“加密算法”。该因子的取值为“WEP”、“WPA”和“WPA2”。

测试点1~测试点4中还隐藏了一个“因子4”:“连接Wi-Fi是否成功”。该因子的取值为“成功”和“不成功”。由于“因子2”和“因子3”存在“约束关系”,只有在“因子2”选择为“加密”的情况下,“因子3”才有效,我们为此建立2个因子表:

  1. “因子2”为“加密”情况下的因子表: enter image description here

  2. “因子2”为“不加密”情况下的因子表: enter image description here

接下来我们就使用PICT工具,来自动生成测试用例。“PICT工具”是针对“Pairwise Testing”实现的测试用例设计工具。可以在http://www.pairwise.org/tools.asp下载PICT工具。

enter image description here

PICT工具的使用非常简单,我们只需将因子表写成txt格式的文件(如test.txt),在dos中运行即可: C:\Windows\System32>c:\PICT\pict c:\PICT\test.txt >c:\PICT\testcase.xls。PICT工具就能帮我们按照Pairwise的规则,自动组合因子的取值,并将结果保存在在c:\PICT的testcase.xls中。

使用PICT工具,我们可以快速得到如下测试用例:

  1. 使用备选Wi-Fi网络,WPA加密,连接不成功
  2. 使用首选Wi-Fi网络,WEP加密,连接成功
  3. 使用备选Wi-Fi网络,WPA2加密,连接成功
  4. 使用备选Wi-Fi网络,WEP加密,连接不成功
  5. 使用首选Wi-Fi网络,WPA加密,连接成功
  6. 使用首选Wi-Fi网络,WPA2加密,连接不成功
  7. 使用首选Wi-Fi网络,不加密,连接成功
  8. 使用备选Wi-Fi网络,不加密,连接不成功
  9. 使用首选Wi-Fi网络,不加密,连接不成功
  10. 使用备选Wi-Fi网络,不加密,连接成功

真正的快用例

当我们熟练掌握了测试建模的方法后,我们就不需要机械的按照建模的模板来进行测试设计了,遇到一个测试点,我们就可以快速判断出该怎样进行测试设计,快速做出测试设计反应,测试设计会变得就会变得越来越快,我们也可以称这种测试设计方法为MBT(基于模型的测试)。

这时我们可以考虑弃掉之前那个复杂的测试用例模板,使用“一句话测试用例”的方法,直接在思维导图工具中得到测试用例。

  1. 一句话测试用例

    一句话测试用例,是指我们只用一句话来描述清楚测试用例的意图,使得测试者可以一下子明白测试的意图,达到指导测试用例的目标。

    一句话测试用例的格式是这样的:

    enter image description here

    我们在前面举的测试用例的例子,都是符合一句话用例的格式的。这里再为大家举几个例子:

    • 在线抓包工具抓取指定源IP和目的IP的数据包测试。
    • 开启MSS调整功能后转发防火墙转发带MSS选项的TCP SYN报文测试。

    对一些参数比较多的用例,使用一句测试用例方式来描述测试用例时,可以再附上测试数据。

  2. 如何控制测试用例粒度?

    “用例粒度”是对“测试用例是精细还是笼统的描述测试点”的通俗说法。测试用例越聚焦到一个功能点上,这个功能点越小越细,用例粒度就越细;反之,如果一个测试用例包含了比较多的功能点,这个测试用例的用例粒度就会比较粗。

    一般说来,用例粒度“细”的测试用例,更容易发现产品在设计上的问题,但是如果整个测试团队的用例粒度都很“细”,那么需要测试的测试用例就会比较多,给测试进度、测试投入和测试用例的编写和维护等都会带来不少问题。而用例粒度“粗”的测试用例,更容易发现产品在系统上设计上、功能交互上和需求方面的问题,但是如果整个测试团队的用例粒度都很“粗”,虽然测试用例的数目可能会少很多,但我们又有可能漏掉很多功能设计上的细节问题,影响产品质量。

使用上面介绍的用例设计套路后,我们发现无论是拆分,还是组合后的测试点,我们还是可以找到适合的测试用例设计方法了:

enter image description here

这也使得我们的测试设计变得更为灵活,更有技巧性。

最后我们再来总结一下快用例设计的整个方式:

使用车轮图来分析测试点---->使用测试建的方式来对测试点进行整理---->一句话测试用例。

最后,测试用例设计并不是一件轻松的事情。“快”是我们目标,但“快”不等于“速成”。

祝你玩的愉快。

Chat实录:《梅子:关于测试用例设计的那些事儿》


enter image description here

enter image description here