软件测试过程中的五要素(Five-fold Testing System)

软件测试过程中的五要素(Five-fold Testing System)     软件测试

本文的主要目标是提出一种测试手段的分类系统,我们把它叫做“五要素测试系统(Five-fold Testing System) ” 。人们可以做的所有测试都可以在五个方面进行描述：

        ·测试员。进行测试的人。例如,用尸测试是由目标市场的成员、通常使用 该产品的人应行的专项测试。

        ·覆盖率。测试了哪些内容。例如，在功能测试中，要测试每个功能。

        ·潜在问题。测试的原因(要测试什么风险) 。例如，测试极值错误。

        ·活动。如何测试。例如探索式测试。

        ·评估。怎样判定测试通过还是不通过。例如，与巳知正确结果的比较。

        本章还要详细描述几个手段，并就另外几个手段的使用提出自己的观点,不过我们的主要目标还是解释分类系统。

        所有测试都包括所有这五个要素。测试手段将测试员的关注点集中的一个或几个要素上，把其他要素留给测试员自己判断。可以把关注一个要素的手段与关注另一个要素的手段结合起来，以得到想要的结果。可以把这种结合的结果叫做新手段(有人确实这样叫)，不过我们认为思考过程要比增加另一个名字更重要。在测试领域中，正在使用的定义不一致的手段清单正在不断膨胀。我们的分类模式有助于读者有意识地理智深刻地理解这种结合。

        测试任务常常按一个要素分配,但是完成任务时要涉及所有五个要素。例如:

        ·有人可能要求测试员做功能测试(彻底测试每个功能) 。它说明的是要测试什么,测试员还必须决定谁来测试，以及要寻找什么问题,如何测试每个函数,如何确定程序是否通过。

        ·有人可能要求测试员做极值测试(测试在向变量输入极值条件下的错误处理)。它说明的是要找出什么问题。测试员还必须决定谁来测试,要测试哪些变量、如何测试这些变量,如何评估结果。

        ·有人可能要求测试员做?测试(让市场的外部代表做测试) 。它说明的是谁来测试,测试员还必须决定告诉外部代表什么(告诉他们多少)、试用产品中的哪一部分、他们应该查找什么问题(应该忽略什么问题) 。在有些?测试中，测试员还要具体地告诉他们如何识别特定类型的问题，可能要求他们以特定的方式执行特定的测试。在另外一些?测试中，可能会由他们决定要完成的活动和评估。

        手段不一定只涉及一种要素，也不应该是这样。所有测试都涉及所有五个要素,因此我们应该期望跨多个要素的更综合的测试手段。以下是多要素手段的一个例子：如果有人要求做“基于需求的测试”，则可能是表示以下三种想法的任意组合：

        ·覆盖率(测试在这个需求文档中列出的所有内容)。

        ·潜在问题(测试不满足这个需求的各种方式) 。

        ·评估(设计测试的方式，要使得测试员能够使用需求规格说明确定程序是否通过) 。

        在说到“基于需求的测试”时，不同的测试员会有这三种想法的不同组合,对这个词并不存在惟一的正确解释①。

        尽管存在模糊性(并且在一定程度上正是因为有这种模糊性)，但是我们认为这种分类系统是一种很有用的思想生成器。

        测试时要时刻想着所有五个要素，就可能做出更好的组合选择。在?测试中，可能决定不描述这些要素中的一个或多个，可以决定不确定如何评估测试结果或测试员该怎样做。但是我们的建议是，要有意识地做出类似上面提到的决定，而不是采用只关注一种要素的手段，而不注意到还要做出其他决定。

        ①基于需求测试的多种含义,提供了软件工程中一个重要普遍问题的例子。定义在测试领域是不固定的。定义的使用在不同子领域和个人之间有很大不同,即使存在期望能被看作是参考标准的文档。我们稍后讨论使很多人无视标准文档的一些因素。请注意,我们在这里不是要声称提供权威定义,或测试领域手段的描述。有些人会使用同样的词汇表示不同的含义。其他人可能会同意我们的描述,但是却以不同的方式表达。不管哪种情况都是合理的、有说服力的。

2、关注测试员的基于人员的测试手段

        以下是一些通过执行测试的人来区分的常见手段举例。

        用户测试(user testing) 。由将使用该产品的典型人员进行输入的测试。用户测试可以在开发期间任何时候进行，可以在开发场地，也可以在用户场地，可以在精心指导下进行，也可以根据用户的意愿进行。有些类型的用户测试，例如任务分析，更像是联合探索(涉及至少一名用户和至少一名公司测试小组成员),而不是由一个人完成的测试。

        α测试。由测试小组(可能还包括其他感兴趣的、友善的内部人员)执行的内部测试。

        β测试。利用不属于开发机构并且是产品的目标市场成员的测试员实施的用户测试。待测产品一般非常接近完成。很多公司都将让客户试用代码看作是β测试,他们把所有β测试都归结为叫做“β”的里程碑。这是个错误。实际上有很多不同类型的β测试。设计β,用于要求用户(特别是有关领域的专家)评价设计，应该尽可能早地实施,以便有根据评价意见进行修改的时间。市场开发友β，用于再次确认在该产品推出并投放自己的大型销售网上时会有大量客户购买,实施时间相当晚，要等到产品相当稳定之后。兼容性测试β，客户在开发机构自己不容易测试的硬件和软件平台上运行该产品。这种测试不能太晚，否则难以确定和解决兼容性问题。对于所管理的任何类型β测试,在确定进度和实施方法之前，都要确定测试目标。

        强力测试(bug bash)。利用秘书、程序员、市场开发人员和可以找到的任何人所实施的内部测试。强力测试一般持续半天，在软件接近投放市场时进行。(请注意,我们列出这种手段是为了举例,并不表示赞同。有些公司由于种种原因认为它很有用，有些公刮则认为没用。)

        有关领域的专家测试(subject-matter expert testing)。向软件目标领域内的专家提供产品，并寻求反馈唐见(错误、批评和赞扬)。专家可以是，也可以不是预期使用产品的客户,公司看重的是专家的知识,而不是其市场代表性。

        成对测试(paired testing) 。两个测试员在一起发现程序错误。一般情况下,他们共用一台计算机,在测试时轮流操作。

        自用测试(eat your own dogfood)。全公司使用并依靠自己软件的试用版，通常要等到软件足够可靠能够实际使用时.才向市场销售。

        3、关注测试内容的基于覆盖率的测试手段

        可以根据在使用这些手段时已经掌握的知识的不同,把这些手段按所关注的问题进行多种不同的分类。例如,如果把功能集成测试用于检查每个功能与所有其他功能组合在一起时是否能够正常延行.则这种测试就是面向覆盖率的测试。如果有针对功能相互交互的错误理论，并想进行跟踪，则这种测试就是面向问题的测试。(例如,如果意图是想发现功能在相互传递数据时出错，就是面向问题的测试。)

        我们将在本章末尾补充解释这些定义中的一些领域测试，因为与领域有关的手段在软件测试中使用得非常普遍、非常重要。读者应该对其有所了解。

        功能测试(function testing) 。逐个测试每个功能。彻底测试功能，直到可以确信该功能没有问题。白盒功能测试通常叫做单元测试,集中测试可以看到代码的功能。黑盒功能测试关注命令和特性,以及用户可以做或选样的事情。在做涉及多个功能的更复杂的测试之前,最好先做功能测试。在复合测试中，第一个出现问题的功能可能会使测试停下来，阻止通过这个测试发现多个其他功能也出现问题。如果依靠复合测试而下是单个测试功能，可能要到很晚才会知道有一个功能出现问题，可能要花费大量工作在复合测试中定位,最后却发现问题出现在一个简单功能上。

特性或功能集成测试(feature or function integration testing) 。一起测试多个功能,以检查功能在一起执行的情况。
　　菜单浏览(menu tour) 。遍历GUI产品中的所有菜单和对话框,使用每个可用的选项。

　　域测试(domain testing) 。域是一个(数学)集合,包含所有可能的函数变量取值.在域测试中,要识别函数和变量。变量可以是输入或输出变量。(输入域和值域之间的数学区别在这里无关,因为这两种域的测试分析都是一样的。)对于每个变量,都要把其可能取值集合划分为等价类,并从每个类中选择少量代表(一般是边界值) 。这种方法假设如果用类中的少量好的代表值进行测试,就可以发现用类中所有成员测试所能够找出的大多数或全部问题.请注意,与功能测试形成对比的是,感兴趣的要素是变量而不是功能。很多变量被多个功能使用。进行域测试时必须分析变量,然后再根据分析,以这个变量作为输入或输出,测试涉及这个变量的每个功能。

　　等价类分析(equivalence class analysis) 。等价类是测试员认为是等价的一组变量取值。如果相信一组测试用例:(a)测试的都是相同的东西;(b)如果其中一个捕获到一个程序错误,其他测试用例也可能捕获到;(c)如果其中一个不能捕获到某个程序错误,其他测试用例可能也不能捕获到,则这些测试用例是等价的。一旦找出一个等价类,可只测试其一两个成员。

　　边界测试(boundary testing) 。等价类是一组取值。如果可以成员映射到一列数字上,则边界值就是类的最小和最大值。在边界测试中,要测试这些值,还要测试相邻类的边界值,这些值比要测试的类的最小值略小,比要测试的类的最大值略大。例如,请考虑一个接受10-50整数值的输入字段。感兴趣的边界值是10(最小整数) 、9(小于10的最大整数) 、50(最大整数) 、51(大于50的最小整数) 。

　　最佳代表测试(best representative testing) 。等价类的最佳代表是在暴露软件中的错误的可能性方面至少与类中其他值一样的值。在边界测试中,边界值几乎总是最佳代表。但是有时不能将等价类映射到一组数字上。例如,兼容惠普PcL-5的打印机是(或应该是)一个等价类，因为这些打印机的工作方式相同。假设对于一个具体任务,其中一种打印机与其他打印机相比,略微更可能出现问题。那么这种打印机可以作为这个类的最佳代表。如果对它测试没有发现问题，那么可以比较可靠地认为其他打印机也没有问题。

　　输入字段测试大纲或矩阵(input field test catalogs or matrices) 。对于每种输入字段,可以开发一组相当标准的测试用例,在这个产品和后续产品中的类似字段中重用。本章稍后还要给出这种方法的例子。(请参阅“如何创建针对输入字段的测试矩阵”。)

　　用各种方式映射和测试编辑宇段(map and test all the ways to edit a filed) 。常常可以以多种方式改变某个字段中的值。例如可以把数据输入到该字段，直接在字段中输入数据，通过程序将计算好的结果复制到字段中，通过程序将再次计算好的结果复制到字段中，等等。字段是有限制的(限制字段可以取哪些值) 。有些限制是不变的,有些限制要依赖于其他字段的取值。例如,如果J和K是无符号整数，其限制就是0一直到MaxInt。这些都是不变限制.依赖于程序设计语言对无符号整数的定义。但是，如果N也是无符号整数,N=J+K,N=5。在这种情况下，J=5-K，J不能大于5，(N的值) 。这是可变限制，其所允许的取值范围取决于N的值。为了检查J是否在所允许的取疽范围内(5—K)，可以使用各种能够把数据输入到J中的方法改变J的取值。

　　逻辑测试(logic testing) 。变量在程序中有关系。例如,程序可能有这样一个决策规则：如果PERSON-AGE大于50，并且如果SMOKER是YES，则OFFER-INSURANCE必须是NO。这种决策规则表达了一个逻辑关系。逻辑测试试图检查程序中的所有逻辑关系。因果图(cause-effect graphing)是一种用于设计大量基于逻辑测试的手段。

　　基于状态的测试(state-based testing) 。程序的状态要发生转换。在给定状态中，有些输入是有效的,其他输入被忽略或拒绝。对于有效输入，被测程序要完成它可以做的事，并且不尝试做它不能做的事。在基于状态的测试中，每次都要通过经过大量状态迁栘(状态改变)并仔细检查结果来检验程序。

原文转自：http://www.ltesting.net