51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2630|回复: 1

[转贴] 测试设计之四步测试设计法

[复制链接]

该用户从未签到

发表于 2020-10-19 18:02:46 | 显示全部楼层 |阅读模式
1、四步测试设计法

  把测试点加工为测试用例,就叫测试设计,在这个过程中使用的方法就叫测试设计方法。路径分析法、判定表、正交分析法、等价类、边界值等都是常见的测试设计方法。
  在测试分析中,我们对被测对象按照测试方法进行思考,就能得到测试点,所以测试分析是一个“发现性”的过程,如图4-35所示,而测试设计不同。

  图4-35 测试分析是一个“发现性”的过程
  大家可以做这样一个试验,让两个测试者根据“车轮图”来分析同一个测试对象,他们得到的测试点差异并不会太大,但是最后生成的测试用例却会千差万别。这是因为,从测试点到测试设计,我们会加工测试点,对它们进行组合、拆分,选择测试数据,等等,这是个“创造性”的过程,100个测试者,就会有100个不同的思路,最后得到的测试用例当然就千差万别了。
  不同的测试者设计的测试用例不同,本也是一件无可厚非的事情,但也使得一个测试团队中的测试用例的质量良莠不齐。对软件测试架构师来说,在测试设计阶段,保证测试用例的质量,为测试团队提供有效的测试技术支持是一项重要的职责。我们不禁要问,有没有一套测试设计方法,能够对测试团队在测试设计中起到很好的指引作用,并能帮助我们输出优质的测试用例呢?答案是有,就是“四步测试设计法”。
  四步测试设计法是一套通过四个步骤来完成测试设计的方法。四步测试设计法中包含一些模型,对每一种模型,都有适合这个模型的测试设计方法,起到了很好的测试设计指引的作用。
  四步测试设计法的四个关键步骤如图4-36所示。

图4-36 四步测试设计法的四个关键步骤
  第一步:建模。
  很多朋友可能一听到“建模”,就觉得这个方法一定很难。其实,在这个步骤中,我们并不是要大家对每个测试点都原创出一些测试模型,而是根据测试点的特征,为测试点选择一个适合后续测试设计的模型。也许我们称这个步骤为“选模”更为贴切。
  既然“选模”需要参考测试点的特征,研究测试点、分析特征的情况并对其进行归类是必不可少的。目前我们将其分为四类:
  类型1:“流程”;
  类型2:“参数”;
  类型3:“数据”;
  类型4:“组合”。
  对每一类测试点,我们都给出了一些最适合的“建模”方法:
  · 对“流程”类,可以通过绘制“流程图”来建立测试模型。
  · 对“参数”类,可以通过“输入输出表”来建立测试模型。
  · 对“数据”类,可以通过“等价类分析表”来建立测试模型。
  · 对“组合”类,可以通过“因子表”来建立测试模型。
  “建模”帮我们解决了面对众多测试方法的选择性难题,使得测试设计变得很有针对性,科学又有效。在4.4.3节中,我们还将为大家详细介绍如何对测试点进行分类。
  第二步:设计基础测试用例。
  在这个步骤中,我们会对已经建立好的测试模型,来设计一些基础测试用例,覆盖这个测试模型。
  为什么我们称此时的测试用例为基础测试用例呢?测试用例和基础测试用例最大的差别在于,测试用例确定了测试条件(类似“在××情况下,进行××的测试”的描述)和测试数据(就是输入的“参数值”或“数值”),而基础测试用例只确定了测试条件。
  由于此时我们关心的仅是对模型的覆盖,得到的是一些测试条件,因此我们称此时的测试用例是基础测试用例。
  对有些测试设计方法来说,可以在覆盖模型的同时确定测试数据,这时得到的就是测试用例,当然这样我们也不再需要进行第三步了。但是为了统一起见,我们还是称这个步骤为“设计基础测试用例”。
  第三步:补充测试数据。
  在这个步骤中,我们为基础测试用例来确定测试输入,补充测试数据,这时基础测试用例就升级成真正的测试用例了。
  第四步:扩展。
  模型不是银弹,不能解决测试设计的所有问题。我们还需要根据经验,特别是对系统哪些地方容易发生缺陷的认识,补充一些测试用例,增加系统的有效性

2、对测试点进行分类

  在使用四步测试方法之前,我们首先要对测试点进行分类。分类的依据,就是看测试点是否有“流程”类的特征、“参数” 类的特征、“数据”类的特征、“组合”类的特征。
  1.流程类测试点有哪些特征
  流程类测试点,拥有流程方面的一些特征。具体来说,我们将测试点分成一些步骤,会因为输入的不同而进行不同的处理,全部分析完成后,能够将测试点绘成如图4-37所示的流程图。

图4-37 流程类测试点的流程图
  有时候,一个测试点可能只能绘出一个流程片段,我们可以把与此相关的测试点放到一起,使其能够表示一个较为完整的流程。
  我们来看一个实际的例子。
  举例:分析“PC连接WiFi”的测试点属于哪些类型
  “PC连接WiFi”这个功能包含表4-12所示的测试点。

  在分析测试点之前,我们先来了解一下“PC连接WiFi”的业务流程(这里只是为了举例说明测试设计的方法,并不是真正的PC连接WiFi的流程,而是一个简化的
  版本)。
  第一步,选择WiFi网络:PC会先判断首选的WiFi网络是否可用,如果不可用,就判断备选WiFi是否可用。
  第二步,判断WiFi是否需要加密:PC会判断连接的WiFi是否需要加密。
  第三步,连接网络:如果需要加密,就加密后再连接;如果不需要加密,就直接连接网络。
  从测试点的描述来看,测试点1和测试点2描述的是选择WiFi网络,测试点3和测试点4描述的是判断WiFi是否需要加密和连接网络。测试点1~测试点4每个测试点都描述了“PC连接WiFi”的一些操作步骤,共同描述了整个流程,它们属于“流程”类的测试点,并且在测试设计的时候,需要把这4个测试点放在一起进行分析。
  测试点5虽然可以归属于“判断WiFi是否需要加密”这个步骤中(如果配置了上述加密算法中的任意一种,就表示需要加密),但是这个测试点是从“支持的配置参数”这个角度去描述的,并没有去描述一个步骤或是一个流程片段。而且从流程上来说,无论我们选择哪种加密算法,都不会影响“判断WiFi是否需要加密”这个结果,所以它不属于流程类的测试点。
  2.参数类测试点有哪些特征
  如果测试点中主要包含的是一些参数,能够概括成和图4-38所示类似的样子(“A”表示参数,“a1”“a2”“a3”表示“A”的取值),就可以认为这个测试点是参数类的。
  例如,测试点“用户登录时可以使用‘用户名密码’‘数字证书’或‘短信验证’的方式来进行身份认证”,“用户登录方式”可以看成图中的“A”,“用户名密码”相当于 “a1”,“数字证书”相当于“a2”,“短信验证”相当于“a3”,这个测试点就是参数类的测试点。
  参数类的测试点有以下两个重要的特点:
  第一,“参数值”的个数是有限的,可以通过遍历的方式来测试覆盖到;
  第二,系统会对不同的“参数值”作出不同的处理或响应。
  理解这两个特点,能够帮助我们区分参数类和数据类(下一节就会讲到)测试点。
  有时候,一个测试点中可能会有好几个参数,如图4-39所示。
  有时候,“A”和“B”之间可能也会存在一些依赖关系,如“A要选择a1,B才能配置”“如果A选择了a1,B就必须选择b1”等。如果这样的关系存在于不同的测试点中,如图4-40所示,“A”和“B”分别存在于“测试点1”和“测试点2”中,在做“测试设计”的时候,我们就需要把“测试点1”和“测试点2”放在一起来考虑。

  我们还是来看“PC连接WiFi”这个例子。
  举例:分析“PC连接WiFi”的测试点属于哪些类型(续1)
  “PC连接WiFi”这个功能包含的测试点见表4-12。
  前面我们已经分析出测试点1~测试点4属于流程类测试点,而测试点5,主要是从“支持的配置参数”这个角度去描述的,其中“设置加密的WiFi网络的加密算法”就是参数,WEP、WPA和WPA2就是它的参数值,“测试点5”属于参数类的测试点。
  需要特别指出的是,测试点5和测试点1~测试点4是存在一定的内在关系的:
  测试点5要想测试成功,需要保证“首选WiFi网络”或者“备选WiFi网络”至少有一个可用,换句话说,测试点1或者测试点2是测试点5的测试条件。
  测试点1~测试点4在测试连接加密的WiFi网络的流程中,也需要输入任意一种加密算法,即测试点5为测试点1~测试点4提供输入值。
  我们在测试设计的时候,将测试点1~测试点4和测试点5分开来考虑的原因是,我们希望通过对测试点1~测试点4设计测试用例,来测试验证“PC连接WiFi”的连接流程的正确性,而不关注使用的是怎样的加密算法;对测试点5设计测试用例,来测试验证每个加密算法在实现上的正确性,而不关注对流程的覆盖。通过这样的归类,我们的测试变得很聚焦,突出了测试重点,弱化了我们不太关心的地方,同时也能减少测试设计的复杂性。
  当然,我们也可将测试点1~测试点5整个放在一起来考虑,这是后话,将在后面的章节中为大家介绍。
  3.数据类测试点有哪些特征
  如果测试点中主要包含的是一些数据,能够概括成和图4-41所示类似的样子(“A”表示参数,“amin”“amax”表示“A”的取值范围),就可以认为这个测试点是数据类的。
  例如,测试点“允许输入的用户名的长度为1~32个字符”,“用户名的长度”等同于图中的“A”,“amin”为“1个字符长度的用户名”,“amax”为“32个字符长度的用户名”,这个测试点就是数据类的测试点。
  和“参数”类相比,“数据”类的特点是:
  第一,数据的取值是一个范围,通常不能用遍历的方式来测试覆盖。
  就拿“允许输入的用户名的长度为1~32个字符”来说,如果要进行遍历测试,就需要依次测试“1个字符长度的用户名”“2个字符长度的用户名”……直到“32个字符长度的用户名”,这样的测试就显得很冗余。
  第二,系统对允许输入的“数据”作出的处理或响应往往是一样的。
  例如,系统在处理“1个字符长度的用户名”和“2个字符长度的用户名”时,往往是一样的。
  一个数据类的测试点中,也可能会有好几个数据,如图4-42所示。
  但是数据类的“A”和“B”之间是没有关系的,换句话说,我们可以将这个包含“A”和“B”的“测试点”直接拆为两个“测试点”,然后分别对测试点1和测试点2进行分析,如图4-43所示。


如果我们发现“A”和“B”之间存在关联,我们就需要通过等价类和边界值的分析,将它们转换为参数类的测试点,再进行测试。
  我们来看一个实际的例子。
  举例:分析“WiFi上可以修改WiFi网络的默认名称”的测试点属于什么测试类型
  “WiFi上可以修改WiFi网络的默认名称”包含表4-13所示的测试点。

  我们先来看测试点3。测试点3描述了WiFi网络名称的长度范围和命名限制,满足前面我们讨论的数据类测试点的特点,属于数据类。
  对测试点1和测试点2而言,它们描述的是修改WiFi网络名称的条件。
  条件1:通过WiFi的管理口直接登录到WiFi上去修改。
  条件2:PC连接成功后,可以登录到WiFi上去修改(即通过WiFi的业务口去修改)。
  它们不能脱离开测试点3而单独存在。因此,测试点1和测试点2需要与测试点3放在一起考虑,将它们整体归属为数据类。
  4.组合类测试点有哪些特征
  测试点是可以“组合”的。在测试设计时,我们可以把流程类、数据类和参数类的测试点组合在一起进行测试设计。为了和前面的测试点类型对应,我们称这种需要放在一起进行测试设计的测试点为“组合”类测试点。
  组合类的测试点可以描述为如图4-44所示的流程。

  和单纯的流程类相比,它可能有多个“输入”,这多个“输入”可能为参数,也可能为数据。
  我们继续来看“PC连接WiFi”这个例子。
  举例:分析“PC连接WiFi”功能的测试点属于哪些类型(续2)
  “PC连接WiFi”这个功能包含的测试点见表4-12。
  在参数类测试点分析举例的时候,我们就提到能够将测试点1~测试点5放在一起考虑,把它们放一起就构成了“组合”类的测试点。
  我们将测试点1~测试点4和测试点5分开来考虑,是为了能够分别验证“PC连接WiFi”的连接流程的正确性和每个加密算法在实现上的正确性。这样设计出来的测试用例也会更关注设计,更关注功能在实现上的细节,在测试时也能比较多地发现这些方面的问题。
  如果我们将测试点1~测试点5组合在一起考虑,更多的是站在系统的角度上来进行测试,能够测试到各个功能之间的配合和与系统整体相关的一些问题。
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-3-29 09:34 , Processed in 0.063084 second(s), 23 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表