您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
软件体系结构课件第七课质量属性 .ppt 64页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：200 &&
你可能关注的文档：
··········
··········
理解质量属性问题：1.描述一下基于构架的设计过程。2.什么叫构架商业周期？3.构架的需求受哪些因素的影响？4.系统的质量属性都有哪几种？它们的含义是什么？举例说明。5.什么叫质量属性场景？为什么要使用质量属性场景？基于体系结构的开发过程其中每个步骤包括：输入构造活动验证活动输出问题：1.描述一下基于构架的设计过程。2.什么叫构架商业周期？3.构架的需求受哪些因素的影响？4.系统的质量属性都有哪几种？它们的含义是什么？举例说明。5.什么叫质量属性场景？为什么要使用质量属性场景？导出体系结构需求与构架有关的影响因素构架商业周期(ABC)软件构架是技术、商业和社会等诸多因素作用的结果，而软件构架的存在反过来又会影响技术、商业和社会环境，从而影响未来的构架。我们把这种相互影响的周期-------从环境到构架又返回到环境------称作构架商业周期。问题：1.描述一下基于构架的设计过程。2.什么叫构架商业周期？3.构架的需求受哪些因素的影响？有哪几类需求？4.系统的质量属性都有哪几种？它们的含义是什么？举例说明。5.什么是质量属性场景？为什么要使用质量属性场景？需求功能需求往往为数众多，可以分成多个不同的抽象层次，并具体表示为用例。质量需求三类质量属性系统的质量属性受构架影响的商业属性：例如：上市时间与构架本身相关的一些质量属性：概念完整性质量因素从头考虑软件体系结构技术的核心是在系统开发过程中尽可能早地处理相关质量问题。系统的质量属性可用性可修改性性能安全性可测试性易用性例子：质量属性的分析中国地球系统科学数据共享网：提供科学数据共享服务的软件平台，要为科学数据共享提供广泛的技术环境支持。特点：数据来源分散。科学数据的采集和获取，是从科学工作者的研究工作中一点一滴地收集起来的。它们掌握在各个科研院所、科研人员手中。因此，作为科学数据共享网的主要服务内容——科学数据，可能是分布在全国各地，甚至还可能来自国外。特点：数据的海量存储目前人们掌握的科学数据是经历了数年、数十年地收集整理而得到的。可以想象，数据量是相当庞大的；尤其是气象、地震、地学等学科领域的数据资源，更是巨大。显然，这需要借助海量存储技术对科学数据资源进行存储和管理。特点：运算量大由于数据量的庞大，所以科学数据资源的收集、搜索方面的运算量是可观的。此外，科学数据共享网不仅仅提供数据共享的功能，还会提供科学数据计算等增值服务，这无形中也增加了系统的运算量。特点：使用人员广泛。科学数据有其广泛深远的研究价值、社会价值和经济价值。所以，对科学数据有使用需求的人员是来自各行各业的，既有科研单位和学者，也有政府机构和企业单位。需求分析能够快捷地收集数据。科学数据分散在科研院所和科学家当中。要设计开发一套收集数据的机制，使其能够快速地整合到系统中，提供数据共享服务。数据收集的途径主要通过网络媒介，而且不能影响系统所提供的网络服务的正常运行。有效存储和管理海量的数据，并快速定位数据。该系统能够提供目录服务，合理地管理数据；提供给用户查阅、下载、使用数据的服务。当用户在系统中查找数据时，希望能够快速定位数据，提供服务，平均响应时间最长不超过20秒。保护数据版权，保证数据的安全性。科学数据存在着版权的问题。在数据使用上，需要版权保护。此外，由于一些数据有其时效性和保密性，所以在提供服务时需要对数据访问进行相应的安全控制。非功能性需求简要质量属性针对质量属性的需求可用性/可靠性系统应能长期稳定地提供服务，近似7X24小时工作强度；在负载过重或是系统崩溃的情况下，能保证用户的请求不丢失；当系统出现故障或崩溃时，恢复时间不超过两小时；可维护性修改某个子系统或服务时，不影响其他子系统或服务；性能高峰时系统的平均响应时间控制在20秒以内；系统能够满足100个并发的用户查询请求；系统至少能够支持2000个用户的在线服务；安全性对有保密性要求的数据实施安全控制；提供系统运行日志监控信息，供管理员了解系统的运行和安全状态；商业属性2005年中期完成系统，年底前投入正式使用；能够利用现有系统的可利用资源；初期总共投资2000万，分别用于系统的集成建设和开发、共享数据标准的制定。系统需求的获取一般两种途径：用户直接主动地提供的需求。主要是一些功能性需求和领域知识。另一条是构架师设计“对话问题”，通过对用户提问，进一步与他们沟通，从而得到更明确的需求。（构架师以软件系统各方面的质量属性为索引，系统地启发用户谈出他们实际需要、但没有表达出来或是表达不完全的内容。这些需求虽不是具体的功能，但是对系统设计和实现具有巨大的影响）问题：1.描述一下基于构架的设计过程。2.什么叫构架商业周期？3.构架的需求受哪些因素的影响？有哪几类需求？4.系统的质量属性都有哪几种？它们的含义是什么？举例说明。5.什么是质量属性场景？为什么要
正在加载中，请稍后...谈软件质量属性——软件性能的可伸缩性 -
谈软件质量属性——软件性能的可伸缩性
软件或多或少的承载着人们这样那样的需求，如何去衡量软件的质量属性应该是软件人员一直都在思考的内容。McCall质量属性模型将软件的质量属性划分为产品修正、产品运行、产品转移三个部分，其实更简单的划分，可以将其分为&开发态质量属性&与&运行态质量属性。
1、正确性是软件质量的基础，但仅能够满足正确的代码，不过是程序世界中的一堆垃圾
克劳士比说过：“质量是一组特性满足要求的程度”，满足“客户要求”、即正确性是所有软件质量的基础。但是，往往并不是所有的要求都是明确的。没有客户有耐心详细的提出有哪些质量要求，往往只是提出“需要什么样的功能”，至于怎么实现，用什么实现从来是不关心的。所以，一个仅能满足正确性的软件/代码只不过是计算机世界中的一堆垃圾。
2、开发态质量属性
开发态质量属性狭义上可以理解为“代码的质量”，如可读性，代码不仅是写给计算机运行的，更多的时候是写给人看的。写一份不需要说明文档的代码，让所有维护的人能够轻松的看懂就是成功。此外如可扩展性，随需求的变更代码的改动情况，这里面设计模式的东西可以派上一些用场，Design
For Change的思想也由此而来。再如可移植性，写了一份代码，32位机器上可以跑，到64位机器上就出问题，或者在Linux上可以执行，到Unix上就需要大刀阔斧的改动，这样或多或少都是有些问题的。其它如可测性，这里不写了。
3、运行态质量属性
运行态质量属性指在程序运行期间的“满足要求”的表现，常见的如：
性能：12306的购票系统就是典型的反面教材，在需要的时候顶不上，影响性能的如IO、数据库、内存操作使用是否恰当；
可靠性：程序是否容易出问题，出问题能否及时恢复；
兼容性：这个对于做平台或中间件层的软硬件要求尤为突出，没有用户愿意为底层的升级买单。不兼容的直接恶果是客户不愿意升级，最终导致版本无法收编，产生巨大的维护成本；
可维护性：出了问题能否快速定位，快速分析，还是人海战术，全部成为救火队员。
4、软件性能的可伸缩性
运行态的质量属性除了这些还有很多，如易用性、易升级等。这里再提到的两点质量属性：一个是软件性能的可伸缩性，其中一层含义可以理解为软件随外部压力增大所表现的性能表现，如100W用户在线时，系统的响应时长是1秒钟，1000W用户在线的时候，系统的响应时长是否是简单的1*10秒钟？另外一层含义，可以理解成软件性能随硬件的扩充所产生的性能变化情况。举例而言：在CPU是1G
Hz的机器上，系统每秒钟可以处理1000个请求，如果CPU升级到2G Hz的处理速度，是否每秒钟就可以处理2*个请求？现实情况下，这个伸缩性一定不是线性关系的，在前一层含义里面，可能还会出现拐点，也就是所谓的“雪崩”。
另外一个值得一提的应该是软件的开放与易集成，当前像微信、微博，都在构筑自己的软件平台，生态系统，如何能够打造一个开放的平台，当前也是一个思考和尝试的途径。
上面这些更多的是一些通用的质量属性，质量属性之间可能相互有矛盾的地方，产品实现时更多的是方方面面的平衡。也可以理解为：产品的质量属性决定了软件的架构。
另外，对于不同的产品而言，其关注的质量属性可能是不一样的，如电信产品更关注的可能是可靠性，而互联网产品可能更侧重于体验和快速响应。对于同一产品而言，不同时期关注的质量属性也可能随需求的变更发生或多或少的变化。
更多相关文章
我们平时买东西的时候,要看一看东西的质量怎么样,如颜色好看否.样式时尚否.经久耐用否,然后再决定买不买.软件作为一种商品,也存在质量高低之分,从哪些方面来评价软件的质量状况呢,主要有以下质量属性:
1.正确性(Correctness)
系统满足规格说明和用户目标的程度,即在预 ...
从个人认知简单总结一下软件的质量属性. 从交付的角度讲: 正确性
--功能正确,符合要求: 易用性
--操作简单,符合大众使用习惯: 稳定可靠性--能在一定时间范围内长期运行,并且经得起异常考验: 从开发维护的角度讲: 可读性 --出于功能需求,算法和结构可以很复杂,但是代码和注释一定要 ...
The Demand for Software Quality
软件质量需求A Conversation with Bertrand Meyer, Part I
Bertrand Meyer访谈之一by Bill Venners
spring配置文件,可以将String. int 等字面值注入到Bean中,也可以将集合,Map,对象等类型数据注入到Bean中. 注:如果字面值含有 &&&& ' 特殊符时,需要在属性值外添加&![CDATA[ ]]&的特殊处理标签,以防止某些字符串对X ...
接前一篇文章: &设计模式真的能改善软件质量吗?(一)&结果分析
选取三个知名的设计模式:组合模式.抽象工厂模式.享元模式
结论:组合模式对大部分质量属性都有正影响,可伸缩性(Scalability)和健壮性(Robustne ...
例子:/jkys/7965.html &script type=&text/javascript& src=&qu ...
最近在用几张表连接起来查询的时候发现有时会得到一模一样的数据,有时却不会,为了搞清楚这是怎么回事,特地学习了一下关于笛卡尔积与连接相关的知识. 所谓的笛卡尔积,也就是笛卡尔乘积,因此如果是普通的两张表连接,就是将2张 ...
Linux: gentooKernel: 2.6.15Confirm your kernel support usblan, acm modem and usbnet zaurus feature.In my lin ...
在Windows Mobile 6.1中修改网络的连接设置即可,将&自动&选项设置为&单位网络或者家庭网络&
网络上资源很多,我景仰那些提供资源的人们,他们没有索取,只是给予.精神真的很可贵.今天在公 ...
友情链接：
管理员邮箱：info@地址：北京市海淀区中关村软件园3C楼1233(上地十街软件园广场)
测试技术您的位置：
> 测试技术
MFQ&PPDCS大型嵌入式软件系统的分析和设计
作者：邰晓梅&&发布时间：&&浏览次数：2979 次
转载注明：
1.&MFQ&PPDCS方法的原创人为邰晓梅，中、英文版权均归邰晓梅所有，任何人如需转载或用于其他用途，请事先征得邰晓梅本文的同意；
2.&请注明英文原文地址：；
3.&请注明中文译文的原文链接：大型嵌入式软件系统的测试分析和测试设计。&
原创作者：邰晓梅
翻译：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（边界值），决策表等。这些测试规范技术更像工具，方法或者测试者得到最后用例的途径。测试分析和测试设计活动并没有明显地区分。也可以说，测试分析和测试设计活动是并行的。当一个完成了，另一个也跟着结束了。测试设计过程更像是&需求/规格&&测试分析和测试设计&&测试用例&。
& & 当被测软件变得越来越复杂，越多的测试分析工作需要在完成最后测试用例的时候完成。例如，对于大型嵌入式通信软件系统，测试分析师不得不努力将他们精力投向学习测试对象，描绘整个图，将测试对象分解到很多小组件使得每个组件都足够小到可以设计，然后分析使用不同的规范技术测试各个组件。在所有这些分析工作结束后，测试用例设计工作开始。因此，测试设计过程变成&需求/规范&&测试分析&&测试设计&&测试用例&。
& & 毋庸置疑，一个有创造性和经验丰富的测试者做测试分析工作会比普通测试者做得好，因为&分析&是一种可以通过工作经验获得的能力。然而，并不是说&分析能力&是不能通过确定的方法和理论获得和加强的。实际上，基于模型的测试对帮助提高改进测试分析工作的质量有很大的帮助。Torbjorn Ryber这样定义模型:&我们的模型可以是描述系统如何工作的表格形式，流程图或者其他图表。&它就像是通过地图展示一座城市；测试对象也可以通过模型展现出来。模型可以通过一种抽象和简单的方法显示测试对象的内在联系。实际上，建立模型的过程就是测试分析的过程。
& & 实践证明，使用模型做测试分析至少有三个好处：
通过建模的这个过程，测试分析者变得越来越熟悉测试对象，很多早期对测试对象的怀疑也变得清晰了。在建模的过程中，很多在需求描述出现的不确定问题，测试分析者要不断同软件设计者交流来找到这些问题的答案。因此，很多潜在的问题会在他们被真正成为缺陷之前被发现。这就是预防bug而不是发现bug的活动。
基于更容易的理解特性的原因，模型是作为测试者和设计者，以及测试设计作者和他们的评审者的很好的媒介。
模型通常很容易被测试用例覆盖。通过图形的知识展现，测试者总是更容易从模型派生用例的方法，结果是模型覆盖的测试设计方法比传统的基于经验测试设计方法更好。
& & 下面章节将介绍基于模型的测试分析和测试设计技术&MFQ&PPDCS
III &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步以后，最后可执行的用例已经完成。
& &&Step4：进一步测试
& & 没有一种类型的模型可以有效地描述测试对象的所有方面。尽管上面三个步骤已经使用，仍然会存在测试对象的一些其他方面需要测试。例如，一些特殊的规格变量限制关系很难放进模型，所以需要另外一个分开的测试设计。另一方面是，人们的经验，测试分析者对测试对象有他们自己的理解，而且很难放到模型中，所以更进一步的测试设计过程是需要的。
& & 好的测试=正式的测试+非正式的测试。前面三个步骤是正式测试过程，最后的步骤&高级测试&是非正式的测试过程。实际上，非正式测试并不意味着没有任何规则可遵循的随机测试。有很多成熟的非正式测试的方法，比如基于错误的测试，探索性测试等等，这些测试不在这篇文章详细展开。
C M-基于模型的简单功能测试分析和设计
& & 上述&基于4-step模型的测试设计过程&是最适合简单功能测试设计的，因为简单功能的合适粒度，所以这部分用M（Model)表示。
& & 在为简单功能测试设计和分析应用4-step过程中，首要做的是将测试对象分为不同的&简单功能&（单元或者组件）。根据我的经验，一个简单功能的可以是几十行到几百行代码的大小，但是最好不要超过一千行。一个简单的功能在单元测试里可以对应1个或者几个组件，或者1个或几个SRS的需求，或者一个或者两个用户场景。没有明确的规则规定那个文档需要被引用，那个需求或者规格需要对应一个简单功能。因此，测试分析者需要收集足够多的材料来做测试分析来识别需要测试的合适的简单功能。
& & 在面向对象的程序里，简单功能可能相对比较容易识别。一个对象负责实现的方法（成员函数）或者一个类可以被看成整个系统的一个简单功能。但是在其他语言，例如C语言，识别简单功能不是那么容易。通常情况下，一个简单功能拥有两个特征：
&&& &从需求的角度看，一个简单功能是相对独立的。一个软件系统由很多特性组成，一个简单的特性可以分解为很多分开的功能。
&&& 从实现的角度看，内在逻辑和简单功能是相干的。例如，一个对象的行为可能通过很多方法（很多功能）实现，一个方法可能包含很多步骤。
& & 同Bill Wake描述的的用户故事的INVEST模型类似，一个简单功能应该是独立的、可测试的、有价值的（实现特定功能）、比较大的（根据上下文情况，没有固定的大小）、可调整的（简单功能的分发可以适应测试分析和测试设计的活动的调整）
& & 从系统特性中识别出简单功能后，下一步就是对每个简单功能使用4-step过程进行测试分析和设计。第IV章将详细描述。
D F-功能交互的测试分析和设计
& & &F&代表功能交互。
& & 在简单功能的测试分析和测试设计完成后，怎么处理简单功能间的交互关系？我们可以使用下面的4-step过程来做功能交互分析。
& & 注意：在下面表格中用单词&特征&来替代&简单功能&，因为&F&和&Q&部分在特性级别频繁使用。
& &&Step1：建立模型
&&& 列出跟所要测试功能有关的遗留功能。他们的关系是&交互&或者&修改&。&交互&以为遗留功能和被测功能需要共同配合做某些事。&修改&意味着遗留功能因为新增的被测功能需要修改。
&&& 列出跟被测功能相关的新功能。他们的关系是时间关系（先后运行，或者同时运行），空间关系（使用共同资源例如定时器、内存、或者交互的信息等）或者其他任何关系。
&&& 将遗留功能和其他新功能放到表格的第一行，将测试功能放到第一列。
&&& 将有交互的单元格标志&X& 。
&&& Step2：设计基础测试用例
&&& 针对表格中每个有交互的内容，我们设计一个或者结果基本测试用例-每个测试用例清晰描述两个有交互功能的关系。表格II阐述了这个步骤：
&&& Step3：填充测试数据
&&& 识别每个FIP基本测试用例的变量，然后使用的EP（等价类划分）和BV（边界值）获得更多的数据，完成测试用例。
&&& Step4：扩展测试
&&& 尝试基于测试者的经验得到更多的测试用例。James Bach&s Heuristic测试方法【12】有非常好的参考文档。
& & E Q-质量属性的测试分析和设计
& & Q代表质量属性.
& & 除了功能测试分析和测试设计，其他质量属性也需要考虑。
&&& Step1：建模
&&&&选择和定义要测试的产品的相关非功能质量属性。ISO9126【13】有对质量属性和子属性的非常好的定义。
&&& &将所有的质量属性写入表格的一行中，将每个组件、功能或者特性写在第一列中。
&&& 将有交互的地方画上&x&,表示这个组件、功能或者特性需要考虑这个质量属性。这个分析粒度在这里不固定，不管是组件级别、功能级别、甚至特性级别都可以。下表是基于功能级别的例子：
&&& Step2：设计基础测试用例
&&& 针对每个表格每个交互点，设计一个或者几个基本测试用例，描述清楚要验证的质量属性。
&&& Step3：补充测试数据
&&& 找出每个QCIP基本测试用例中的变量，使用等价类划分和边界值得到更多的数据，完成测试用例。
&&& Step4：拓展测试
&&& 尝试基于测试者的经验获得更多的测试用例，【12】将很有帮助。
&&& 在&F&和&Q&中使用&表格&作为模型的好处是它使得测试分析者不会那么容易忘记一些测试的相关点。
&&& 这个章节主要将MFQ框架。&表格&用来描绘功能交互和质量属性的测试分析模型。但是针对简单功能测试分析，模型的类型会是不同的，下一章节会讲到这个。
IV PPDCS-选择合适的测试技术来建模
A PPDCS介绍
& & 就像上面说的，4-step过程在每个M，F和Q测试分析和测试设计过程都会用到。在4个过程中，step1是关于测试分析的，也是最重要的步骤的。在F和Q部分，step1比较简单就是用表格作为模型。但是M部分，step1可能是大多数测试分析者认为最困难的。面对众多测试设计技术和面对不同特征的测试对象，测试者经常思考要选择哪种技术来建立一个好的模型。
& & 测试设计的关键问题是&所有可能的测试用例中哪些子集有最高可能性发现最多的错误？&。熟悉如何选择合适的测试分析模型有助于解决这个问题。这个章节阐述PPDCS方法，是一个在一个或者多个测试技术中选择的技术。
& & 一方面，当分析不同的测试设计技术，可以发现绝大多数的测试设计技术可以被归为主要的五大类，每类有一个明显的特点。比如：&商业流程图&技术是处理流程特性的。通常一个过程由很多步骤组成，这个技术可以使用活动图表或者流图来表示整个过程。
& & 另一方面，当分析不同的测试对象（经常通过需求规格说明书），可以发现测试对象有相似的特性。例如，关于ATM机器的规格会描述关于取钱的整个情形，&从插入银行卡，数据校验，检查密码，处理传输，退卡&。所以这种规格同样也是处理流程的特性。
& & 当这两个特性匹配，测试分析者可以使用特定的测试设计技术来为这个规则建模。这就是PPDCS最早的想法，每个字母代表一个特定的特性。第一个字母&P&是&流程&的意思，第二个字母&P&是&参数&的意思，第三个字母&D&是&数据&的意思，第四个字母&C&是&组合&的意思，最后一个字母&S&是&状态&的意思。这些每一个特性和简单功能的基于模型的测试分析和设计在论文的接下去部分会详细讲述。
B P-Process （P流程）
& & 1）应用条件
& & 如果在测试对象的设计规范中有存在相关&流程&的特征，&P-Process&方法可以用来建模。
& & 流程的特征包括：
&&& 很多步骤构成一个流程，且步骤之间有顺序关系
&&& 涉及超过一个角色或者触发条件
& & P-Process特征的设计规范经常包括一系列的步骤或者用户场景。
2）应用步骤
& &&Step1：建模
& & &P-Process&特性可用流图或者活动流图，使用&商用流程图【2]&测试技术。
& & 在建模过程中，测试分析者需要跟产品设计者频繁交流。任何该流程中可能异常的分支都必须被考虑到。测试分析者要确保设计规格书已经被模型准确描述。如果流图已经在测试规格文档说明了，测试分析者需要仔细地审查甚至重新描绘它，因为建模的过程对完全理解整个测试对象很有帮助。下面流图使用&取钱&功能作为例子。
& &&Step2：设计基础测试用例
& &&使用基础测试用例&有两种方法可以覆盖模型。一种方法是流图比较简单的情况，设计基础用例来覆盖流图的每个路径。另一种方式是当流图很复杂的时候，设计基础用例覆盖&主要流程+重要的二选一流程&。每条路径或者流程都是使用一个基础用例表示。
& & ATM取钱的简单功能的基础用例如下表：
& &&Step3：补充测试数据
& &&针对每个基础测试用例，识别相关的变量，通过等价类划分和边界值增加更多的测试数据，获得最终的可执行性测试用例。
& &&Step4：拓展测试
& &&有其他流程的可能性？除了流图显示的，还有其他需要的考虑的吗？
& & 1）应用条件
& & 如果在测试对象的设计规格中存在&变量或者参数&含义的特性，&P-Parameter&方法可以用来建模。
& & &参数&特性包括：
&&& 设计规格中没有明显地流程，但是涉及&很多参数&。
&&& 设计规格中包含很多规则，每条规则有很多不同的变量和不同的值组成。
&&& 参数的数量是有限的。测试分析者可以容易地识别参数间的逻辑关系。
& & 2）应用步骤
& &&Step1：建模
& &&带有&P参数&特性的测试对象可以使用表格、树图和坐标图建模，可参看决策表、决策树或域测试【2】测试技术。
& &&Step2：设计基础测试用例
& &&使用基础测试用例覆盖模型有两种方法。一种是100%规则覆盖，例如为决策表的每条规则设计一个基础用例。在决策表较简单的情况下（没有涉及太多参数），这个方法很有效。另外一种方法是，转换决策表到决策树，为树的每个叶设计一个基础用例。这个方法在决策表比较复杂的时候有效。将决策表转换为决策树的另一个好处是在转换过程中可以比较容易地发现遗留或者错误的需求。
& & 当在一个决策里包含很多条件的时候，ECT【2】（初级对照决策覆盖）可以被用来生成基础测试用例。
& &&Step3：填充测试数据
&&& 针对每个基础测试用例，识别相关的变量，使用等价类划分和边界值填充数据。
& & Step4：拓展测试
& &&基于经验补充特殊的测试用例。
&&&&1）应用条件
& & 如果在测试对象的设计规范中存在&数据&特征，&D-数据&方法可以用来建模。
& & &数据&特性包括：
&&& 每个数据有它特殊的范围值；
&&& 跟&参数&不一样，数据之间没有明显的&规则&或者逻辑关系；
&&& 不同的数据的范围可能存在限制；
&&& 涉及的数据个数是有限的。
& & 例如，在这样规格描述&当建造建筑物的时候，一个房间最多4个窗户&，可以识别2种数据，就是&房间数量&和&窗户数量&。
& & 2）应用步骤
& &&Step1: 建模
& &&带有&D-数据&特征的测试对象可以使用表格建模，等价类划分和边界值测试技术可以提供帮助。
& &&Step2：设计基础测试用例
& &&设计基础测试用例覆盖每个有效和无效地组，同时考虑有效边界值和无效边界值。
& &&Step3：补充测试数据
& &&针对每个测试用例，针对每个数据标识特定的值。
& &&Step4：拓展测试
& &&基于经验补充特殊的测试用例。
& & 1）应用条件
& & 在&P-过程&和&D-数据&的案例中，如果参数或者数据的数量太多以致很难手工列出来，&C-组合&方法可以用上。
& & &组合&特性包括：
&&& 存在大量的参数（数据）；
&&&&每个参数有很多值；
&&& 参数之间可能存在一些逻辑关系。
& & 2）应用步骤
&&& Step1：建模
&&& &C-组合&可以使用因子状态表，组合测试【2】或者正交测试技术可以参考。
&&& 例如，给定四个因素，测试所有组合需要72个测试用例。我们可以通过确保每个因素的每个值和其他任何一个值的组合至少被测试过一次的方法来减少测试用例数量同时尽可能带来的风险。
&&& Step2：设计基础用例
&&& 在站点里有很多关于结对测试的工具。其中，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&P代表&&50&P，那么用60代替。
&&& Step4：拓展测试
&&& 基于经验补充特殊的测试用例。
& & 1) 应用条件
&&&&& & 如果测试对象的设计规格中存在&状态&特征，&S-状态&方法可以被用来建模。
& & & & &状态&的特性包括：
&&& 测试对象的行为变化基于它内部的状态；
&&& 确定的事件触发测试对象的状态。
& & 2）应用步骤
& &&Step1：建模
& &&&S-状态&可以通过&状态图&建模，可参看&基于状态测试&的技术。
& & 在一个状态图中，状态可以通过节点表示，事件可以通过连接节点的弧表示。
& & 建模步骤如下：
&&& 从规格中识别行为对象；
&&& 对这些行为对象确定所有可能的状态；
&&& 对每个状态，画出节点；
&&& 识别所有在状态之间的节点传输；
&&& 针对每个传输，确定触发的事件；
&&& 针对每个事件，画出相关节点的链接。
& &&Step2：设计基础用例
& &&很多方法可以用来设计基础用例覆盖状态图。其中之一就是Chow的方法【10】
& & TableXI 列举了用Chow&s的0-Switch的覆盖方法针对上图生成的基础测试用例。TableXII列举了使用Chow的1-Switch覆盖方法的基础测试用例。注意，基础测试用例的增加是考虑单个传输还是成对的传输路径。
& && distinguish=49AE1A9C86BD data-media-type=image data-inited=true v:shapes=&_x&P&
& &&Step3:补充测试数据
& &&针对每个基础数据，我们识别涉及的相关变量然后通过等价类划分和边界值定义测试数据。这个结果在每个抽象的测试用例里可以被扩展成一个或者多个可执行的具体测试用例。
& &&Step4：拓展测试
&&& 基于经验补充特殊的测试用例。
& & 这个章节讲述的是关于PPDCS方法。简单功能的测试分析和测试设计，第一件事就是识别简单功能（或称为单元或组件）的数目。针对每个简单功能，需要哪种测试分析：通过PPDCS方法建模，设计基础用例来覆盖模型，针对每个测试用例补充更多的测试数据，然后通过基于经验设计其他的测试用例。
& & 在华为，一些实验性质的项目开发者被教导使用MFQ&PPDCS方法。表格XIII在产品的一个特性使用传统设计方法和使用PPDCS方法比较了M 部分（MFQ框架的简单功能部分）的结果。
开发人员使用传统的测试方法（主要是基于经验的测试方法）设计了86个测试用例。由于在测试用例设计过程之前没有明显的测试分析过程，该特性的2个部件在开发人员设计测试用例过程被忽视了。（识别简单功能的数量的步骤没有施行好）。运行这86个用例后，只有1个缺陷被检测出来。
& & 为了比较传统测试设计方法和PPDCS的新的测试方法的效用，一个新的测试者被指派重新使用PPDCS方法来进行这个特性的设计。结果是，设计了102个测试用例。4个部件全部被识别到，而且该特性的更多功能点被测试用例覆盖。测试分析和测试设计过程结束后，即便那个时候还没有测试用例执行，已经检测到5个缺陷。
& && distinguish=7AD5CC13BCA641AEAC09C5D data-media-type=image data-inited=true v:shapes=&_x&P&
& & 结论：
&&& 开发人员可以很快学会，然后在PPDCS的帮助下，单元测试分析和测试设计做得很好，即使之前只有一点点的测试设计知识基础。
& & 很多潜在的缺陷在建模阶段就被发现和预防了，而传统的测试需要测试者在软件实现完成以后发现。这是因为建模的过程同时也是测试分析的过程，测试规范通常在测试分析阶段会被审查一遍，然后潜在问题在早期就被发现。
& & 因为PPDCS是黑盒测试方法，当结合白盒测试方法（例如：通过白盒测试技术比如状态覆盖、分支覆盖、路径覆盖等等来补充测试用例），可以获得更好的覆盖率。
& & 开发人员可以很容易将测试分析过程合并到软件分析过程，使得软件设计更加完善。
& & 综上所述，针对大型嵌入式软件系统的测试分析和测试设计过程是：
&&& 在低级别的测试，比如单元测试，简单功能（&M&Part）要彻底测试。在高级测试级别，比如系统测试、功能交互（&F&part）和质量属性（&Q&部分）需要彻底地测试。然后，这并不是绝对的。
&&& 在每个M,F或者Q部分，4-step测试分析和测试设计过程需要使用到。
&&& 针对M部分，我们从测试对象分解未特性和独立的功能开始。我们使用PPDCS框架帮助我们选择合适的规格技术来对每个功能建模。
&&& 针对F和Q部分，功能交互表格用来建模。James Bach的启发式测试策略模型是这个的有用补充。
&&&&完整版（包括图）见附件：
&&&&相关阅读：
上一篇:&&&&&&&&下一篇: