净室软件认证

软件测试的统计方法首先由 Harlan Mills（Mills，Dyer，and Linger 1987）和他 IBM的同事开发出来，后来，John Musa（1993）和他 AT＆T的同事也开发了相似的方法。Mills和 Musa所用的术语虽有细微的差别，但它们都是运用成熟的工程准则对产品进行测试和验证的科学方法。在工业界，典型地采用一组产品抽检协议（protocol）进行合格性检验：首先，进行随机抽样，并应用投入运行使用中的一些测试特征进行测试。然后，进行分析和统计推断。最终，通过一定标准的产品才被认为是合格产品。
　　净室软件测试和认证方法--基于使用模型的统计测试--是这种协议在软件上的一种应用（Poore and Trammell 1998）。统计测试时，需要开发出软件投入运行时的使用模型，测试用例由该使用模型随机产生。然后，按照数学和统计学模型对结果进行分析，获取软件的质量度量，并判断测试的充分性。传统的结构化测试方法是净室统计使用测试方法的一种补充，因此，不必放弃该方法；不过，大量实践表明，基于使用模型的测试更经济有效，并且能获得实用软件的高可靠性。
一、 基于使用模型的统计测试的优点
　　软件系统的基于使用模型的统计测试提供了软件产品和过程质量的度量标准，它将用于软件的整个生命期的管理和决策。由于使用模型是基于规范而不是基于代码的，因此，源于模型构筑的洞察可用于产生在工程的早期阶段避免出现问题的有价值的管理决策。以下是使用建模和统计测试的主要优点。
　　需求确认 使用模型是系统规范的外部视图，它必须容易地被系统工程师、开发人员、客户和终端用户所理解。在投入运行的环境中，当对该使用模型（包括可能的输入、可能的输入序列以及期望的输出）进行系统地评审时，接口和需求往往被简化或明确。
　　资源和进度预测 基于一个使用模型的标准计算，为成果、进度和成本估算提供数据，如覆盖模型中所有状态和状态转移的最小测试数采用What－if分析方法可以界定基于失效数据测试的最好和最坏情况下的结果。
　　人工挑选非随机测试用例 依据一定的约定或规则，通过模型检查确定特殊的测试用例，以确保测试了特定的测试序列。可以把现存的测试用倒映射到模型中以评估遗漏或冗余。从而使用模型便构成了所有需要的或期望的测试参考模型。
　　自动生成测试用例 最小覆盖的测试脚本（对模型完全覆盖的最少测试事件）和随机测试用例（依据使用概率分布）可由测试模型自动生成。模型覆盖测试确保了在随机测试开始之前模型的最低功能，而且随机测试为投人运行时的可靠性评估提供了依据。
　　有效地、高效地测试 不同的缺陷并不同等地产生失效。位于频繁遍历路径上的缺陷比那些位于非频繁遍历路径上的缺陷更有可能导致失效。随机测试的动机源于这样一个简单的事实：发现失效是根据现场运行时失效导致故障的大致顺序。测试的预算主要用来通过测试来最大限度地提高软件在投人运行时限靠性。
　　聚焦测试（有偏抽样） 使用模型允许对特别序列的有偏抽样，譬如对非频繁使用但极为重要的功能序列抽样。可以为这些功能形成单独的模型，或者对原始模型进行变换和抽样以去除偏置。
　　量化测试管理 基于使用模型的统计测试，为决策测试是否完成或软件是否可发布提供了定量的标准。期望使用（在使用模型中所表征）与测试使用（在测试中所记录）的统计误差作为测试充分性的度量值。
　　可靠性预测 在一定的统计测试协议下，测试时可以从软件的性能中获得预期运行性能的有效预测。实际的测试结果（即对每一输入的正确的和不正确的情况）作为使用模型的权重记录下来，并且该模型的计算结果提供了投入运行时的可靠性预测。
二、 统计测试的理论基础
1 样本与总体
　　就统计测试而言，软件测试被看作是一个统计学方法的问题。先产生软件所有可能使用的一个子集，并以这个子集所表现的性能作为依据来考虑整体使用性能。换句话说，就是通过样本来描述总体。
　　作为一个出发点，这种类比的前提是：不可能对软件的所有可能应用都进行测试。这个前提似乎并非如此显而易见。在与一个测试者探讨软件测试策略时，听到有人这样说并不稀奇："我们必须对软件所有可能的应用都要进行测试；如果不进行彻底的测试，我们开发的软件有可能带来灾难性的后果。"通过下面的例子可以证明：对所有可能使用情形进行测试是不可能的。
　　拥有边界约束但存在大量输入序列的软件会具有一个有限却十分庞大的可能使用情景。就像下面（来自 Wiener 1994）的表的例子所示，随着可能输入序列的组合的增长，会导致大得惊人的测试数自。该例子假定：（1）系统中的一个使用情景至少可以有1个输入，并且至多可有10个输入；（2）允许20个不同的输入；（3）输入允许重复。这样的系统就今天的标准来说的确不算大。

　　在这个例子中，如果每秒钟测试1个使用情景，那么系统测试将至少需要 300 000年；如果每秒钟测试 100个使用情景，那么测试至少需要 3 000年；如果可以在软件的 100份拷贝同时进行测试，并对它们同时进行每秒钟100个测试情景，那么测试时间也需要30多年。所以，即便是使用情景是有限的，彻底地测试也是不可能的。
　　输入序列长度不定的软件，理论上讲有无限多的可能使用情景。比如一个软件若有两个用户输入A和B，那么可能的使用情景是：A，B，AA，AB，BB，BA，AAA，AAB，ABA，BAA，BBB……。
　　毫无疑问，所有可能的使用情景将不会被彻底测试。问题的关键就在于如何描述使用总体以及如何形成用例子集。如果对软件的测试控制合理，那么，由描述恰当的总体的一个随机测试用例，通过投入运行时的使用测试，我们可以得到总体的一个有效描述，而对于其他的用例子集而言，无论多么全面的构筑都是不可能的。
2 软件使用的随机属性
　　软件使用的过程被认为是一个随机过程（即，对一系列可能发生的事件，其中任意两个事件在时间序列上彼此互不重叠）。一个Markov过程就是一个具有Markov性质的随机过程，其中，序列中的下一个事件只依赖于当前而与过去无关。Markov理论已经用于软件使用模型的分析和开发之中（Whittaker and Poore1993，Whittaker and Thomason 1994），相关的数学方法也已被运用到模型优化之中（Walton，Poore，and Trammell 1993）。软件的使用模型可用有穷状态、离散参数的Markov链表示。Markov链的标准分析结果将有助于分析长期运行使用的情况。给定一个使用模型的约束系统（Walton 1995），那么，通过数学方法可以得到满足一定目标条件的最优化模型（比如，这样一个模型：它覆盖了所有的使用状态和相应的状态转移，并且它具有最少的测试用例）。形式化思想在净室软件认证中的应用，为当前的实践和技术进步提供了坚实的理论基础。
三、 统计使用测试的实际应用
　　一个软件使用模型描述了软件系统投入运行时的使用模型（即，从总体可以获得一个统计上比较恰当的测试用例样本）。通常，统计使用测试都是在正常使用情况下进行讨论的，但是，其他的使用环境（比如重点使用、危险使用、维护使用）也可以特别指明。
1 使用规范
　　使用模型开发的第一步是描述一般操作情形和可能的使用分类层次。软件由"用户"在一定的"环境"中"使用"，那么定义了用户、使用和环境也就定义了可推断软件质量的运行环境。如果多个使用环境都比较重要，那么有必要为每一个使用环境构造一个使用模型。使用模型的层化技术在必要的粒度层次上描述了运行条件的变化。 　　一个软件的用户可以是一个人、一个硬件设备，也可以是其他的软件，并且如果需要，每一种用户都可以进一步被层化。譬如说人，他就可以根据工作类型、访问权限或专业经验被分类。
　　一个软件的使用可能是工作任务、事务、电话呼叫或其他服务项目。使用实例可以是电源通／断、调用／终止调用、钩连／脱钩或以任何其他恰当的开始／结束事件来定义使用实例。
　　一个使用环境可由操作平台、单用户／多用户、并发执行、系统负载、外部数据的完整性以及其他因素来确定。
2 使用模型的开发
　　一个使用模型的最初框架直接源于软件规范。生成规范的净室方法为前面所提到的开发工作和这回所说的软件认证提供了一个公共分界点。特别是在定义软件规范过程中给出的规范序列确定了使用模型的初始状态空间。
　　一个使用模型可由这样的图形来表示：图中的结点代表使用状态，弧线代表导致状态之间转移的信号激励。注意：这里所说的使用状态（诸如"开始"、"初始化事务"等等）不是软件的内部状态。对使用模型图，开发者和那些经常参与使用模型检查的用户很容易理解。但是图形表示通常仅用于小型系统或大型系统的高层表示。大型使用模型往往一开始被抽象定义，然后通过把抽象信号变成具体的原子信号并对子模型进行扩展，从而得到该使用模型。使用模型也可以用表或矩阵表示，其中行列都表示状态，并且每一单元（行，列）都表示了行状态和列状态的概率。
　　使用模型的结构代表了软件的可能使用。为了表示在特殊情况下软件的期望使用，需要在结构上增加概率分布。在使用模型中，如果可能，状态的转移概率可以根据可能得到的现场数据、用户的估计或者前一个版本的说明来考虑。使用模型的状态和状态转移概率可以按常规或非常规来考虑。
3 使用模型分析和测试计划
　　就像所提到的那样，状态转移图或矩阵是使用模型的一般表示形式，而且它们也是Markov链的一般表示形式。尽管使用模型也可以用其他的表示形式，但对Markov链研究的一般结论，使得Markov链使用模型在净室软件开发的实际应用中具有明显优势。一个Markov链的标准计算结果，为测试使用中频繁使用的度量标准提供了期望值，譬如：
　　·一次使用（测试用例）中事件数的均值
　　·最终的状态发生率（全部使用时间的百分率）
　　·一个给定使用状态发生前的平均使用（测试用例）数目
　　仅从使用模型获得（在软件设计和实现之前）的这些结果在软件的整个生命周期都可使用。它们也可用于修订规格说明，度量复杂度、聚焦验证成果、确定事件频率、制定测试进度，以及确定可靠性推断的上限。
4 测试用例生成与测试
　　使用模型形成之后，依据每个状态出边所关联的转移概率，通过遍历模型的使用状态可以自动生成测试用例。因为每一个弧线都与系统的某一特定激励相关联，所以遍历导致了代表特定测试用例的后续激励的累积。测试用例构成测试中的使用脚本。为了对指导和评价测试提供说明，它们可以在制定测试计划时得到注解；当然，为了记录运行结果和观察结果，它们也可以在测试过程中被注释。测试用例可以由人来使用，也可以由自动测试工具使用。 　　一个统计过程的推断的有效性蕴涵几个潜在的假定。通常来说，测试过程的合理控制可以由以下四个准则得到保证：
　　1．软件的每一版本都必须在惟一的统计实验中进行检测。一个版本的数据只能用于评估该版本的可靠性，不同版本的数据可用于描述测试过程。可靠性模型中使用的数据可用于评估产品的可靠性，用于可靠性增长模型的数据可用于评估过程的有效性。
　　2．规格说明、环境状况以及性能评估的依据对不同的测试版本应保持一致。
　　3．测试用例应该像生成的那样使用，即不能在众多用例中"挑选"。
　　4．测试小组成员必需培训以保证对测试资料和测试方针的基本认识。测试过程中，对测试人员的工作应进行监督以避免"草率行事"。为了检查结果和讨论那些可能影响他们判断的问题，必须规定测试小组成员的交流方式。
　　在测试中，应该由测试人员或自动化工具对软件的实际行为和特殊行为进行比较。对每项转移中的软件行为都应进行检查，对软件版本、测试用例数和状态转换次数都要记录。所有的测试数据和测试脚本都要存档。
5 测试充分性和产品质量的度量
　　产生测试用例的使用模型称作使用链。每一个状态的期望的最终发生率，可以在模型分析中由使用链计算得到。在测试阶段，第二个链（测试链）用于跟踪测试中实际发生状态的遍历情况。一开始，测试链是使用链的拷贝，其中任意弧线都有一个计数器，其初始值为零（表明软件还未使用过）。在测试中，一旦应用测试用例，那么每一弧线的计数器的值都要增加以便记录状态转移（如果软件成功地完成使用状态的转移）。
　　对使用链和测试链进行对比，从而为后续的测试提供依据，以计量期望使用与测试使用之间的差异。所给出的差异，作为标准值被称作判别式（discriminant），它反映了测试中期望使用的表示程度。随着无失效测试的进展，判别式的值通常趋于零（但也不是千篇一律的），但在特殊值依赖于特殊模型和所做的测试量时，该值较为稳定。如果判别式的值足够小（由测试工程师判断），表明测试结果近似等同于期望的使用性能，测试没有继续进行的必要，那么测试应该中止。
　　随着测试的不断进展和失效的不断产生，应该用失效状态改进测试链的框架结构。软件的可靠性就是在未遇到失效的情况下，软件从头到尾随机地遍历测试链的概率。换句话说，可靠性就是在一个完整的使用规划中每一事件顺利进展的概率。可靠性通过测试链计算得到。
　　如果在测试中出现"无失效"，可靠性的计算结果应该是1．0，此时应被解释为"无信息"，而不能作为一个可靠性评估。当测试表明无失效时，应该采用其他的可靠性评估方法，譬如像Poore、Mills和Mutchler（1993）或Miller（1992）所提出的方法等。
　　基于使用模型的统计测试是软件测试的一个合适的规定。它以坚实的科学原理为基础，已简化到一个合理的工程技术准则并得到了可以验证的坚实结论。

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