测试设计之四步测试设计法

LJboy

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组合在一起考虑，更多的是站在系统的角度上来进行测试，能够测试到各个功能之间的配合和与系统整体相关的一些问题。

Miss_love

支持分享