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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　测试时要时刻想着所有五个要素，就可能做出更好的组合选择。在ß测试中，可能决定不描述这些要素中的一个或多个，可以决定不确定如何评估测试结果或测试员该怎样做。但是我们的建议是，要有意识地做出类似上面提到的决定，而不是采用只关注一种要素的手段，而不注意到还要做出其他决定。
　　①基于需求测试的多种含义,提供了软件工程中一个重要普遍问题的例子。定义在测试领域是不固定的。定义的使用在不同子领域和个人之间有很大不同,即使存在期望能被看作是参考标准的文档。我们稍后讨论使很多人无视标准文档的一些因素。请注意,我们在这里不是要声称提供权威定义,或测试领域手段的描述。有些人会使用同样的词汇表示不同的含义。其他人可能会同意我们的描述,但是却以不同的方式表达。不管哪种情况都是合理的、有说服力的。
经验49,关注测试员的基于人员的测试手段

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

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

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