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

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

原创作者：邰晓梅

翻译：wzhj132

原创来源：2009年ICSEA大会上的论文《MFQ & PPDCS - Test Analysis and TestDesign for Large Embedded Software Systems》

内容简介：

MFQ & PPDCS是由邰晓梅提出的一套测试设计框架：其中MFQ针对大型系统中的功能多且复杂、功能之间的交互多、质量属性要求高的特点，结合Model Based Testing的思路，按照4-step的步骤开展测试分析和测试设计；PPDCS是针对很多测试人员面对众多的测试设计技术无从选择的问题而提出的一种选择测试设计技术的思路。MFQ & PPDCS方法曾在华为内部开展过多期培训，在多个产品线内得到实践应用。

本人只是在学习之余，简单将其翻译成中文，方面学习，共享之，关于MFQ&PPDCS这个方法（不论中文、英文）版权都属于邰晓梅作者。

说明：未经允许，请勿转载。如需转载，请于作者邰晓梅及本人联系。

摘要：大型嵌入式软件系统有三个重要特点：数量巨大和复杂的功能、非常多的功能交互和严格的质量要求。这篇论文包括

两个部分，部分1提出了一个结合MBT（基于模型的测试）和Torbjorn Ryber's的4步测试设计的方法，MFQ；部分2提出了一个新的技术PPDCS，选择合适的测试规范技术来构建模型。

关键字- 测试分析；测试设计；基于模型测试；测试方法论。

I. 背景知识

1. A 大型嵌入式软件系统的特点

如今，嵌入式软件占据软件的很大一部分比例。例如在日本，“嵌入式软件占据软件行业的很大比例，主要是因为很多大公司生产电子、汽车等。”

对比传统的胖客户端或者给予浏览器的桌面应用软件，大型嵌入式软件系统有下面特点：

• 大量和复杂的功能：典型产品的代码量大小经常达到百万行，包括每个版本的新特性，涉及软件和硬件功能，包括O&M（操作和维护）和服务处理模块等等。

• 大量的功能交互：因为嵌入式软件经常运行在实时操作系统上，任何一个功能在任何时刻可能被其他事件所影响，例如被其他正在运行的功能模块，定时的任务，非预期的时间（例如交换和重置某些硬件）

• 非常严格的质量要求：除了追求准确的高质量功能特性，嵌入式软件还要提供高质量的非功能性特性，包括可靠性，可扩展性，灵活性和健壮性等等。

高质量的要求使得测试者的角色尤其重要，软件系统的复杂性也让测试工作变得很有挑战。

1. B  测试分析和设计的问题调查

通常情况下，编码后开发人员会在提交产品给测试人员前进行低级别测试（LLT：Low Level Test），一般包括单元测试（UT：Unit Test）和集成测试（IT：Integration Test）等，提交后，测试人员采用高级别测试（HLT：High Level Test）例如系统测试。LLT在单一功能上关注很多，而HLT主要关注功能交互和质量属性特点。LLT阶段和HLT阶段要测试的内容以及这两个测试阶段的负责人明显是不同的。

简单功能的测试设计，尽管开发或者测试已经做了，但是效果很差，因为对如何应用测试设计技术比如等价类划分、边界值、决策表等理解不够透彻。可能是因为在这些技术上缺乏足够的培训，即使有一些培训，这些培训经常都是一次聚焦于一两个技术，而且这些培训课程涉及的案例都太简单了。所有这些因素使得测试规范技术的使用变得困难。真实场景是，人们经常依赖自己的经验来做测试设计，所以测试用例集离完整性和有效性还差很远。

另外一个测试设计的问题是功能交互点和非功能质量特征在测试分析的时候没有被很好的考虑。基于经验的测试设计过分依赖人们的测试经验不容易将要测试的功能交互要点和质量属性考虑全面。

1. C 论文的内容

该论文试图针对大型嵌入式软件系统，提出一种基于新的建模方法和测试分析设计框架，通过系统化和层次化的方法，快速选择合适的测试规范技术来高效地创建测试分析模型，达到相对有效和完整的测试用例，提供一种指南。

这篇论文的组织如下：

• 第I章讲述一些背景信息；

• 第II章澄清测试分析和测试设计的概念

• 第III章提出针对大型嵌入式软件系统的MFQ框架

• 第IV章提出帮助选择测试规范技术的指南PPDCS方法

II. 测试分析和测试设计

1. A 不同的观点

我们经常称“测试分析和设计”，一定程度上，混淆了“测试分析”和“测试设计”。因为最后测试用例是测试设计活动的直接结果而不是测试分析活动的结果，测试分析倾向于忽略测试分析活动的重要性。

   MikeSmith指出“人们倾向于参考‘测试分析和设计活动’。我更倾向于主张测试分析和测试设计作为不同的活动，引出不同组织结构的工作作品。这个更好的反映存在的需求和已经实施的系统之间的复杂逻辑的自然联系。”Mike Smith认为“测试分析”解决“是什么”。比如测试的目标和方法是什么？他认为“测试设计”解决“怎么做”，例如这些方法和目标怎么实现。

另一个观点，Torbjorn Ryber将测试简化为“一个持续问问题的过程”，就像图1. 从这个模型可以推导出“测试分析”实际上是“怎么做---我怎么问问题？”，“测试设计”实际上是“是什么--我要问什么问题？”

实际上，两个观点都强调测试分析活动的重要性。接下来就是怎么做测试分析的问题了。

1. B 测试分析和模型

在早期的测试中，测试设计过程基本上就像“需求/规格-->测试用例”。也就是说，测试分析从需求/规格文档，大部分基于测试经验直接生成测试用例。

后来，人们开始学习特定特定的测试规范技术来设计测试用例，例如EP（等价类划分），BV（边界值），决策表等。这些测试规范技术更像工具，方法或者测试者得到最后用例的途径。测试分析和测试设计活动并没有明显地区分。也可以说，测试分析和测试设计活动是并行的。当一个完成了，另一个也跟着结束了。测试设计过程更像是“需求/规格-->测试分析和测试设计-->测试用例”。

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

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

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

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

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

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

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

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

1. A MFQ介绍

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

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

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

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

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

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

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

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

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

Step1：为测试对象建模

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

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

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

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

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

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

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

Step4：进一步测试

没有一种类型的模型可以有效地描述测试对象的所有方面。尽管上面三个步骤已经使用，仍然会存在测试对象的一些其他方面需要测试。例如，一些特殊的规格变量限制关系很难放进模型，所以需要另外一个分开的测试设计。另一方面是，人们的经验，测试分析者对测试对象有他们自己的理解，而且很难放到模型中，所以更进一步的测试设计过程是需要的。

好的测试=正式的测试+非正式的测试。前面三个步骤是正式测试过程，最后的步骤“高级测试”是非正式的测试过程。实际上，非正式测试并不意味着没有任何规则可遵循的随机测试。有很多成熟的非正式测试的方法，比如基于错误的测试，探索性测试等等，这些测试不在这篇文章详细展开。

1. C M-基于模型的简单功能测试分析和设计

上述“基于4-step模型的测试设计过程"是最适合简单功能测试设计的，因为简单功能的合适粒度，所以这部分用M（Model)表示。

在为简单功能测试设计和分析应用4-step过程中，首要做的是将测试对象分为不同的”简单功能“（单元或者组件）。根据我的经验，一个简单功能的可以是几十行到几百行代码的大小，但是最好不要超过一千行。一个简单的功能在单元测试里可以对应1个或者几个组件，或者1个或几个SRS的需求，或者一个或者两个用户场景。没有明确的规则规定那个文档需要被引用，那个需求或者规格需要对应一个简单功能。因此，测试分析者需要收集足够多的材料来做测试分析来识别需要测试的合适的简单功能。

在面向对象的程序里，简单功能可能相对比较容易识别。一个对象负责实现的方法（成员函数）或者一个类可以被看成整个系统的一个简单功能。但是在其他语言，例如C语言，识别简单功能不是那么容易。通常情况下，一个简单功能拥有两个特征：

• 从需求的角度看，一个简单功能是相对独立的。一个软件系统由很多特性组成，一个简单的特性可以分解为很多分开的功能。

• 从实现的角度看，内在逻辑和简单功能是相干的。例如，一个对象的行为可能通过很多方法（很多功能）实现，一个方法可能包含很多步骤。

同Bill Wake描述的的用户故事的INVEST模型类似，一个简单功能应该是独立的、可测试的、有价值的（实现特定功能）、比较大的（根据上下文情况，没有固定的大小）、可调整的（简单功能的分发可以适应测试分析和测试设计的活动的调整）

从系统特性中识别出简单功能后，下一步就是对每个简单功能使用4-step过程进行测试分析和设计。第IV章将详细描述。

1. D F-功能交互的测试分析和设计

”F“代表功能交互。

在简单功能的测试分析和测试设计完成后，怎么处理简单功能间的交互关系？我们可以使用下面的4-step过程来做功能交互分析。

注意：在下面表格中用单词”特征“来替代”简单功能“，因为”F“和”Q"部分在特性级别频繁使用。

Step1：建立模型

• 列出跟所要测试功能有关的遗留功能。他们的关系是“交互”或者“修改”。“交互”以为遗留功能和被测功能需要共同配合做某些事。“修改”意味着遗留功能因为新增的被测功能需要修改。

• 列出跟被测功能相关的新功能。他们的关系是时间关系（先后运行，或者同时运行），空间关系（使用共同资源例如定时器、内存、或者交互的信息等）或者其他任何关系。

• 将遗留功能和其他新功能放到表格的第一行，将测试功能放到第一列

• 将有交互的单元格标志”X"

Step2：设计基础测试用例

针对表格中每个有交互的内容，我们设计一个或者结果基本测试用例-每个测试用例清晰描述两个有交互功能的关系。表格II阐述了这个步骤：

Step3：填充测试数据

识别每个FIP基本测试用例的变量，然后使用的EP（等价类划分）和BV（边界值）获得更多的数据，完成测试用例。

Step4：扩展测试

尝试基于测试者的经验得到更多的测试用例。JamesBach's Heuristic测试方法【12】有非常好的参考文档。

1.    E Q-质量属性的测试分析和设计

   Q代表质量属性.

除了功能测试分析和测试设计，其他质量属性也需要考虑。

Step1：建模

• 选择和定义要测试的产品的相关非功能质量属性。ISO9126【13】有对质量属性和子属性的非常好的定义。

• 将所有的质量属性写入表格的一行中，将每个组件、功能或者特性写在第一列中。

• 将有交互的地方画上"x",表示这个组件、功能或者特性需要考虑这个质量属性。这个分析粒度在这里不固定，不管是组件级别、功能级别、甚至特性级别都可以。下表是基于功能级别的例子：

Step2：设计基础测试用例

针对每个表格每个交互点，设计一个或者几个基本测试用例，描述清楚要验证的质量属性。

Step3：补充测试数据

找出每个QCIP基本测试用例中的变量，使用等价类划分和边界值得到更多的数据，完成测试用例。

Step4：拓展测试

尝试基于测试者的经验获得更多的测试用例，【12】将很有帮助。

在”F“和”Q"中使用"表格“作为模型的好处是它使得测试分析者不会那么容易忘记一些测试的相关点。

这个章节主要将MFQ框架。“表格”用来描绘功能交互和质量属性的测试分析模型。但是针对简单功能测试分析，模型的类型会是不同的，下一章节会讲到这个。

IV PPDCS-选择合适的测试技术来建模

1. A PPDCS介绍

就像上面说的，4-step过程在每个M，F和Q测试分析和测试设计过程都会用到。在4个过程中，step1是关于测试分析的，也是最重要的步骤的。在F和Q部分，step1比较简单就是用表格作为模型。但是M部分，step1可能是大多数测试分析者认为最困难的。面对众多测试设计技术和面对不同特征的测试对象，测试者经常思考要选择哪种技术来建立一个好的模型。

测试设计的关键问题是“所有可能的测试用例中哪些子集有最高可能性发现最多的错误？”。熟悉如何选择合适的测试分析模型有助于解决这个问题。这个章节阐述PPDCS方法，是一个在一个或者多个测试技术中选择的技术。

一方面，当分析不同的测试设计技术，可以发现绝大多数的测试设计技术可以被归为主要的五大类，每类有一个明显的特点。比如："商业流程图“技术是处理流程特性的。通常一个过程由很多步骤组成，这个技术可以使用活动图表或者流图来表示整个过程。

另一方面，当分析不同的测试对象（经常通过需求规格说明书），可以发现测试对象有相似的特性。例如，关于ATM机器的规格会描述关于取钱的整个情形，“从插入银行卡，数据校验，检查密码，处理传输，退卡”。所以这种规格同样也是处理流程的特性。

当这两个特性匹配，测试分析者可以使用特定的测试设计技术来为这个规则建模。这就是PPDCS最早的想法，每个字母代表一个特定的特性。第一个字母“P”是“流程”的意思，第二个字母“P”是“参数”的意思，第三个字母“D”是“数据”的意思，第四个字母“C”是“组合”的意思，最后一个字母”S“是”状态”的意思。这些每一个特性和简单功能的基于模型的测试分析和设计在论文的接下去部分会详细讲述。

1. B P-Process （P流程）

   1）应用条件

如果在测试对象的设计规范中有存在相关“流程”的特征，“P-Process”方法可以用来建模。

流程的特征包括：

• 很多步骤构成一个流程，且步骤之间有顺序关系

• 涉及超过一个角色或者触发条件

  P-Process特征的设计规范经常包括一系列的步骤或者用户场景。
   2）应用步骤

Step1：建模

“P-Process”特性可用流图或者活动流图，使用“商用流程图【2]"测试技术。

在建模过程中，测试分析者需要跟产品设计者频繁交流。任何该流程中可能异常的分支都必须被考虑到。测试分析者要确保设计规格书已经被模型准确描述。如果流图已经在测试规格文档说明了，测试分析者需要仔细地审查甚至重新描绘它，因为建模的过程对完全理解整个测试对象很有帮助。下面流图使用"取钱"功能作为例子。

Step2：设计基础测试用例

使用基础测试用例有两种方法可以覆盖模型。一种方法是流图比较简单的情况，设计基础用例来覆盖流图的每个路径。另一种方式是当流图很复杂的时候，设计基础用例覆盖“主要流程+重要的二选一流程”。每条路径或者流程都是使用一个基础用例表示。

   ATM取钱的简单功能的基础用例如下表：

Step3：补充测试数据

针对每个基础测试用例，识别相关的变量，通过等价类划分和边界值增加更多的测试数据，获得最终的可执行性测试用例。

Step4：拓展测试

有其他流程的可能性？除了流图显示的，还有其他需要的考虑的吗？

1. C. P参数

   1）应用条件

如果在测试对象的设计规格中存在“变量或者参数”含义的特性，“P-Parameter”方法可以用来建模。

“参数”特性包括：

• 设计规格中没有明显地流程，但是涉及“很多参数”。

• 设计规格中包含很多规则，每条规则有很多不同的变量和不同的值组成。

• 参数的数量是有限的。测试分析者可以容易地识别参数间的逻辑关系。

   2）应用步骤

Step1：建模

带有“P参数”特性的测试对象可以使用表格、树图和坐标图建模，可参看决策表、决策树或域测试【2】测试技术。

Step2：设计基础测试用例

使用基础测试用例覆盖模型有两种方法。一种是100%规则覆盖，例如为决策表的每条规则设计一个基础用例。在决策表较简单的情况下（没有涉及太多参数），这个方法很有效。另外一种方法是，转换决策表到决策树，为树的每个叶设计一个基础用例。这个方法在决策表比较复杂的时候有效。将决策表转换为决策树的另一个好处是在转换过程中可以比较容易地发现遗留或者错误的需求。

当在一个决策里包含很多条件的时候，ECT【2】（初级对照决策覆盖）可以被用来生成基础测试用例。

Step3：填充测试数据

针对每个基础测试用例，识别相关的变量，使用等价类划分和边界值填充数据。

   Step4：拓展测试

基于经验补充特殊的测试用例。

1. D. D-数据

   1）应用条件

如果在测试对象的设计规范中存在“数据”特征，“D-数据”方法可以用来建模。

“数据”特性包括：

• 每个数据有它特殊的范围值

• 跟”参数“不一样，数据之间没有明显的”规则“或者逻辑关系

• 不同的数据的范围可能存在限制

• 涉及的数据个数是有限的

例如，在这样规格描述“当建造建筑物的时候，一个房间最多4个窗户”，可以识别2种数据，就是“房间数量”和“窗户数量”。

   2）应用步骤

Step1: 建模

带有“D-数据”特征的测试对象可以使用表格建模，等价类划分和边界值测试技术可以提供帮助。

Step2：设计基础测试用例

设计基础测试用例覆盖每个有效和无效地组，同时考虑有效边界值和无效边界值。

Step3：补充测试数据

针对每个测试用例，针对每个数据标识特定的值。

Step4：拓展测试

基于经验补充特殊的测试用例。

1. E C-组合

   1）应用条件

在“P-过程”和“D-数据”的案例中，如果参数或者数据的数量太多以致很难手工列出来，“C-组合”方法可以用上。

   "组合“特性包括：

• 存在大量的参数（数据）

• 每个参数有很多值

• 参数之间可能存在一些逻辑关系

   2）应用步骤

Step1：建模

”C-组合“可以使用因子状态表，组合测试【2】或者正交测试技术可以参考。

例如，给定四个因素，测试所有组合需要72个测试用例。我们可以通过确保每个因素的每个值和其他任何一个值的组合至少被测试过一次的方法来减少测试用例数量同时尽可能带来的风险。

Step2：设计基础用例

在http://www.pairwise.org/tools.asp站点里有很多关于结对测试的工具。其中，PICT是一款非常好用的工具。

使用PICT设计基础用例的的过程，就是使用PICT特殊的”语言“形成的表格。一旦我们定义这些规则，我们可以在DOS环境下运行这些脚本。所有的基础测试用例自动生成。

举例说明，在”model_test.txt"文件中定义了下面的规则：

      Factor A：A1，A2

      Factor B：B1，B2，B3

      Factor C：C1，C2，C3，C4

      Factor D：D1，D2，D3

当我们执行下面命令：

      C:\>pict model_test.txt > output.xls

下面12个基础测试用例会被自动保存在output.xls中：

这12个组合就是我们所需要测试的确保每个因子的每个值都至少跟其他因子的值组合测试过一次。

Step3：补充测试数据

针对每个基础测试用例，为涉及到的每个参数定义一个值。例如，如果“A1"代表”>50"，那么用60代替。

Step4：拓展测试

基于经验补充特殊的测试用例。

1. F S-State

   1) 应用条件

如果测试对象的设计规格中存在”状态“特征，”S-状态“方法可以被用来建模。

”状态“的特性包括：

• 测试对象的行为变化基于它内部的状态

• 确定的事件触发测试对象的状态

   2）应用步骤

Step1：建模

”S-状态“可以通过”状态图“建模，可参看”基于状态测试“的技术。

在一个状态图中，状态可以通过节点表示，事件可以通过连接节点的弧表示。

建模步骤如下：

• 从规格中识别行为对象

• 对这些行为对象确定所有可能的状态

• 对每个状态，画出节点

• 识别所有在状态之间的节点传输

• 针对每个传输，确定触发的事件

• 针对每个事件，画出相关节点的链接

Step2：设计基础用例

很多方法可以用来设计基础用例覆盖状态图。其中之一就是Chow的方法【10】

   TableXI列举了用Chow's的0-Switch的覆盖方法针对上图生成的基础测试用例。TableXII列举了使用Chow的1-Switch覆盖方法的基础测试用例。注意，基础测试用例的增加是考虑单个传输还是成对的传输路径。

Step3:补充测试数据

针对每个基础数据，我们识别涉及的相关变量然后通过等价类划分和边界值定义测试数据。这个结果在每个抽象的测试用例里可以被扩展成一个或者多个可执行的具体测试用例。

Step4：拓展测试

基于经验补充特殊的测试用例。

这个章节讲述的是关于PPDCS方法。简单功能的测试分析和测试设计，第一件事就是识别简单功能（或称为单元或组件）的数目。针对每个简单功能，需要哪种测试分析：通过PPDCS方法建模，设计基础用例来覆盖模型，针对每个测试用例补充更多的测试数据，然后通过基于经验设计其他的测试用例。

1. V 结果

在华为，一些实验性质的项目开发者被教导使用MFQ&PPDCS方法。表格XIII在产品的一个特性使用传统设计方法和使用PPDCS方法比较了M 部分（MFQ框架的简单功能部分）的结果。
开发人员使用传统的测试方法（主要是基于经验的测试方法）设计了86个测试用例。由于在测试用例设计过程之前没有明显的测试分析过程，该特性的2个部件在开发人员设计测试用例过程被忽视了。（识别简单功能的数量的步骤没有施行好）。运行这86个用例后，只有1个缺陷被检测出来。

为了比较传统测试设计方法和PPDCS的新的测试方法的效用，一个新的测试者被指派重新使用PPDCS方法来进行这个特性的设计。结果是，设计了102个测试用例。4个部件全部被识别到，而且该特性的更多功能点被测试用例覆盖。测试分析和测试设计过程结束后，即便那个时候还没有测试用例执行，已经检测到5个缺陷。

结论：

• 开发人员可以很快学会，然后在PPDCS的帮助下，单元测试分析和测试设计做得很好，即使之前只有一点点的测试设计知识基础。

• 很多潜在的缺陷在建模阶段就被发现和预防了，而传统的测试需要测试者在软件实现完成以后发现。这是因为建模的过程同时也是测试分析的过程，测试规范通常在测试分析阶段会被审查一遍，然后潜在问题在早期就被发现。

• 因为PPDCS是黑盒测试方法，当结合白盒测试方法（例如：通过白盒测试技术比如状态覆盖、分支覆盖、路径覆盖等等来补充测试用例），可以获得更好的覆盖率。

• 开发人员可以很容易将测试分析过程合并到软件分析过程，使得软件设计更加完善。

1. VI 总结

综上所述，针对大型嵌入式软件系统的测试分析和测试设计过程是：

• 在低级别的测试，比如单元测试，简单功能（“M”Part）要彻底测试。在高级测试级别，比如系统测试、功能交互（“F”part）和质量属性（“Q”部分）需要彻底地测试。然后，这并不是绝对的。

• 在每个M,F或者Q部分，4-step测试分析和测试设计过程需要使用到。

• 针对M部分，我们从测试对象分解未特性和独立的功能开始。我们使用PPDCS框架帮助我们选择合适的规格技术来对每个功能建模。

• 针对F和Q部分，功能交互表格用来建模。James Bach的启发式测试策略模型是这个的有用补充。