MFQ&PPDCS 大型嵌入式软件系统的测试分析和测试设计(2)

　　当被测软件变得越来越复杂，越多的测试分析工作需要在完成最后测试用例的时候完成。例如，对于大型嵌入式通信软件系统，测试分析师不得不努力将他们精力投向学习测试对象，描绘整个图，将测试对象分解到很多小组件使得每个组件都足够小到可以设计，然后分析使用不同的规范技术测试各个组件。在所有这些分析工作结束后，测试用例设计工作开始。因此，测试设计过程变成“需求/规范–>测试分析–>测试设计–>测试用例“。

　　毋庸置疑，一个有创造性和经验丰富的测试者做测试分析工作会比普通测试者做得好，因为“分析”是一种可以通过工作经验获得的能力。然而，并不是说“分析能力”是不能通过确定的方法和理论获得和加强的。实际上，基于模型的测试对帮助提高改进测试分析工作的质量有很大的帮助。Torbjorn Ryber这样定义模型:“我们的模型可以是描述系统如何工作的表格形式，流程图或者其他图表。”它就像是通过地图展示一座城市;测试对象也可以通过模型展现出来。模型可以通过一种抽象和简单的方法显示测试对象的内在联系。实际上，建立模型的过程就是测试分析的过程。

　　实践证明，使用模型做测试分析至少有三个好处：

　　通过建模的这个过程，测试分析者变得越来越熟悉测试对象，很多早期对测试对象的怀疑也变得清晰了。在建模的过程中，很多在需求描述出现的不确定问题，测试分析者要不断同软件设计者交流来找到这些问题的答案。因此，很多潜在的问题会在他们被真正成为缺陷之前被发现。这就是预防bug而不是发现bug 的活动。

　　基于更容易的理解特性的原因，模型是作为测试者和设计者，以及测试设计作者和他们的评审者的很好的媒介。

　　模型通常很容易被测试用例覆盖。通过图形的知识展现，测试者总是更容易从模型派生用例的方法，结果是模型覆盖的测试设计方法比传统的基于经验测试设计方法更好。

　　下面章节将介绍基于模型的测试分析和测试设计技术–MFQ&PPDCS

　　III MFQ-测试分析和测试设计框架

　　A MFQ介绍

　　就如上面提到的大型嵌入式软件系统有三个明显的特征：多和复杂的功能，数量众多的功能交互，高质量特性要求，相应地，大型嵌入式软件系统的MFQ测试分析和设计框架包括三个部分：M-基于模型的简单功能测试分析和设计;F-功能交互测试分析和设计;Q-质量属性测试分析和设计。

　　针对上述3个部分的每个部分，基于4-step模型的测试分析和测试方法都会用到，详细内容在B章节介绍。

　　上述的三个部分可以被用在任何测试级别(单元测试、集成测试、或者系统测试)，但是下面是一些有用的建议：

　　在单元测试或者组件测试级别，第一个部分“M-基于模型的简单功能测试分析和设计”始终都应该使用。目的是保证独立的单个功能在集成到其他组件进行高级别测试之前已经被完全测试。

　　在系统测试级别，第二部分F和第三部分Q应该尽可能使用。这是保证整个系统的功能准确性和质量属性。

　　在低级别测试应用M和Q取决于项目和人力技术技能的情况，一些质量属性在项目中可以被提早验证。例如，健壮性是组件测试非常重要的部分。

　　当测试软件从低级别测试转向高级别测试的时候(通常是从开发团队到测试团队)，测试者验证基本功能测试已经完成。因此，第一部分M在高级别测试也需要。

　　B 4-step测试分析和测试设计过程

　　MFQ框架使用4-step 测试分析和测试设计过程，详细资料可以在参考文献【2】中找到。这里简单介绍一下。

　　Step1：为测试对象建模

　　成功测试的关键在于好的分析模型，但是好的模型建立在对测试对象的熟悉程度的基础上。这在大型嵌入式软件系统尤其适用，因为商业公司背景知识永远是好的测试分析和设计工作的基础。所以在做任何测试分析的第一个步骤是收集关于测试对象的足够多的信息，从而获得对产品更深的了解。这些信息可以是手边的所有设计文档，例如特性设计规格，软件规格说明书，高级别设计规格和低级别设计规格等等。在对测试对象有一个充分的了解后，测试分析者可以尝试选择一个合适的模型来描绘测试对象。有很多流行有效的测试规范技术例如等价类划分、边界值，决策表，业务流程图、基于状态的测试等等，测试分析者常常发现在建模的时候面对很多的选择，他们很快陷入不知道选择哪个的情形。很多模型可用被用来描绘一个测试对象，但是经常情况下只有其中一种最适合我们使用。PPDCS在下一个章节就是要解决这个问题的构想。

　　Step2: 设计基础测试用例(有时候叫做合逻辑的或者抽象的测试用例)来覆盖这个模型

　　所谓的基础测试用例指的是比较泛的用例，在测试用例中没有测试数据的值。跟传统一步测试用例生成过程不同，测试用例4-step过程的产生需要两个步骤：第一设计基础测试用例，第二针对每个测试用例更多的测试数据来产生最后可执行的测试用例。

　　设计基础用例的目的是更好的进行模型覆盖。不同的模型有不同的测试覆盖方法。最近几年，很多学者在研究根据确定的生成规则或者算法自动生成测试用例的基于模型的测试。这篇论文更多地关注建模过程和观察从模型手动生成用例的过程,因为在我经验中，建模的工作花费较多时间，而从模型生成测试用例的过程相对简单且不耗时。

　　此外，在该篇论文中，”模型“的概念是广义的，例如，一个模型不一定得是通过UML或者其他确定的语言的表达。实际上，一个模型可以是任何一种表格，图表，树等等，只要它能帮助我们清楚地描述测试对象。基于我的经验，绝大多数的的测试对象可以通过简单地模型表示。我认为在大多数场景下，测试规范技术不需要非常复杂。在人们为特定的测试对象开始测试设计的过程如果需要一个很难学习的测试规范技术，我认为这个对象的系统设计或者需求设计需要重来。

　　Step3：考虑测试数据的变化来敲定测试用例(有时叫做具体的测试用例)

　　如果第一步骤是用模型覆盖需求，那么第二步是用基本测试用例覆盖模型，然后第3步是用测试数据覆盖每个基本测试用例。有一些测试数据在基本的测试用例已经包括，所以第一件事要做的是识别出测试数据，然后第二件事要做的是考虑测试数据的变化，比如使用等价类划分和边界值。(备注：等价类和边界值有点特殊因为他们也可以用在第1步骤的建模)。针对每个测试数据的变化，设计一个测试用例。第3步以后，最后可执行的用例已经完成。

原文转自：http://hejiajie.cn/archives/472