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

　　原创作者：邰晓梅

　　翻译：wzhj132

　　原创来源：2009年ICSEA大会上的论文《MFQ & PPDCS – Test Analysis and Test Design 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. 背景知识

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

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

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

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

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

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

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

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

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

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

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

　　C 论文的内容

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

　　这篇论文的组织如下：

　　第I章讲述一些背景信息;

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

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

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

　　II. 测试分析和测试设计

　　A 不同的观点

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

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

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

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

　　B 测试分析和模型

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

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

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