专项测试技术

专项测试技术培训教材目录1质量属性和专项测试关系 (4)1.1软件质量属性 (4)1.2专项测试 (5)2可测试性 (6)2.1可测试性定义 (6)2.1.1业界的可测试性定义 (6)2.1.2我司的可测试性定义 (6)2.1.3影响软件可测试性的要素 (7)2.2可测试性设计 (8)2.2.1可测试性设计要素 (8)2.2.2可测试性T-IBO模型 (9)2.2.3系统可测试性设计体系 (12)2.3典型设计的可测试性 (13)2.3.1日志可测试性设计 (13)2.3.2数据库可测试性设计 (19)2.3.3文件可测试性设计 (21)2.3.4内部对象的可测试性设计 (23)2.3.5资源池可测试性设计 (24)2.3.6接口协议可测试性设计 (26)2.3.7操作系统资源可测试性设计 (27)3安全性测试 (28)3.1概念 (28)3.2攻击手段/漏洞分析 (28)3.3安全保护技术 (28)3.4测试方法 (28)3.5典型案例 (28)4可靠性测试 (28)4.1概念 (28)4.2故障模式 (28)4.3可靠性保护技术 (29)4.4测试方法 (29)4.5典型案例 (29)5可服务性测试 (29)5.1概念 (29)5.1.1可服务性的定义 (29)5.1.2可服务性的意义 (30)5.2可服务性规范和基线 (31)5.2.1可服务性规范 (31)5.2.2可服务性基线 (32)5.3可服务性测试 (32)5.3.1可服务性测试目的 (33)5.3.2可服务性测试范围 (33)5.3.3可服务性测试策略 (34)5.3.4可服务性测试方法 (35)5.4典型案例 (37)专项测试技术培训教材关键词：质量属性、专项测试、可测试性、安全性测试、可靠性测试、可服务性测试、测试方法摘要：本教材主要介绍了可测试性、安全性测试、可靠性测试、可服务性测试的基本概念以及基本测试方法。

可作为新员工培训教材，无经验的老员工也可以作为参考资料。

1 质量属性和专项测试关系1.1 软件质量属性国际标准组织于2001年制定软件质量标准ISO 9126，主要规范了软件质量模型和一套表征软件从内部和外部看的衡量软件质量的维度，叫做软件质量属性。

9126-2、9126-3主要定义软件质量属性。

软件质量属性分为6个维度，功能性、可靠性、可用性、效率、可维护性、可移植性。

功能性主要关注功能需求符合度、功能合适、功能正确、功能互操作性、功能安全性。

可靠性主要关注可靠性符合度（满足用户期望）、成熟度、故障容错能力、故障恢复能力。

可用性主要关注可用性符合度（满足用户期望）、软件的易理解性、易学习性、易操作性、对用户的吸引力。

效率性主要关注软件在用户使用场景和特定配置下表现出来的性能符合度，包括动作效率和资源使用。

可维护性主要关注软件的故障定位能力、可变更能力、稳定性、可测试性以及可维护符合度。

可移植性主要关注可移植符合度（符合用户期望）、可适配性、可安装性、可升级性。

1.2 专项测试一般，除功能性外，其他质量属性都叫做非功能质量属性。

华为的专项测试主要指的是针对非功能质量属性的测试。

本培训教材涉及的可测试性、安全性测试、可靠性测试、可服务性测试分别针对可维护质量属性的可测试性、功能质量属性安全性、可靠性质量属性、可维护质量属性和可移植质量属性的可安装性。

针对非功能质量属性，华为的专项测试主要包括以下测试类型：质量属性中的非功能属性是运营商非常关注的方面，在功能差异不大的情况下，通常会直接影响产品竞争力。

但是，非功能质量属性并非越高越好，只要满足客户期望即可。

因为，一般来讲，非功能质量属性的提高与软件架构的先进性关系很大，提高它会花费很多成本。

所以，测试作出结论时，一定要坚持够了就好的原则。

2 可测试性2.1 可测试性定义2.1.1 业界的可测试性定义业界对可测试性的定义是多种多样的。

而这些定义大多数都是从一个特定的应用领域发展出来的。

如美军工就把其军工产品能及时准确地确定其状态（可工作、不可工作、性能下降），隔离其内部故障的设计特性作为其可测试性定义。

这个定义最终被引申并形成美军工产品的设计原则和标准，并在设计军工产品时把这些属性设计到他们的产品中去。

同样，学术界也提出了不少可测试性的定义，这些定义则更为抽象，是作为一些软件基础研究的前提假设，与实际的工程实践有很大的差距。

Jeffery Voas的可测试性定义是现在学术界中最具代表性的一个。

该定义用软件满足“故障失效模型”所必须具备的三个必要条件的概率情况来综合评价一个软件的可测试性。

下表罗列了一些业界的可测试性定义。

2.1.2 我司的可测试性定义从业界的可测试性定义来看，所有的定义都是在一个特定的应用领域发展起来的。

而现在业界的定义中还没有针对软件系统的可测试性提出过具备指导性的定义。

结合我司的具体情况，在综合美军工和IEEE的可测试性定义基础上，我们给出本地化的可测试性定义：在既定的质量目标与有限的成本、时间约束的前提下，为达到一定测试目标而进行：1)测试设计和测试执行的难易程度；2)问题发现的难易程度；2）问题隔离与定位的难易程度。

2.1.3 影响软件可测试性的要素可测试性作为软件的一个固有属性，本身与软件的许多其它属性相关，比如：业界有许多专家都在就软件复杂度与可测试性的关系进行研究。

而当前普遍受到业界认同的可测试性技术研究方向是由James Bach从影响软件运行、测试难易程度的角度出发，提出的影响软件可测试性的7大软件要素理论，这七大要素描述如下：◆可操作性：“运行得越好，测试的效率越高。

”系统的错误很少（错误增加测试过程中的分析和报告开销）；没有阻碍测试执行的错误；产品在功能阶段的演化（允许并行的开发和测试）；◆可观察性：“你所看见的就是你所测试的。

”每个输入有唯一的输出；系统状态和变量可见，或在运行中可查询；过去的系统状态和变量可见，或在运行中可查询（例如：事务日志）；所有影响输出的因素都可见；容易识别错误输出；通过自测试机制自动侦测内部错误；自动报告内部错误；可获取源代码；◆可控制性：“对软件的控制越好，测试越能够被自动化执行与优化。

”所有可能的输出都产生于某种输入组合；通过某种输入组合，所有的代码都可能被执行；测试工程师可直接控制软件和硬件的状态及变量；输入和输出的格式保持一致且有结构；能够便利地对测试进行说明、自动化和重用；◆可分解性：“通过控制测试范围，能够更快地分解问题，执行更灵巧的再测试”软件系统由独立模块构成；能够独立测试各软件模块；◆简单性：“需要测试的内容越少，测试的速度越快。

”功能简单性（例如：特性集是满足需求所需的最小集合）；结构简单性（例如：将体系结构模块化以限制错误的繁殖）；代码简单性（例如：采用代码标准为检查和维护提供方便）；◆稳定性：“改变越少，对测试的破坏越小。

”软件的变化是不经常的；软件的变化是要控制的；软件的变化不影响已有测试；软件失效后能得到良好的恢复；易理解性：“得到的信息越多，进行的测试越灵巧。

”设计能够被很好的理解；内部、外部和共享构件之间的依赖性能够被很好的理解；设计的改变被通知；可随时获取技术文档；技术文档的组织合理；技术文档明确详细；技术文档精确性稳定。

2.2 可测试性设计2.2.1 可测试性设计要素可测试性设计是在系统基本功能之上按照一定的设计规则设置控制点和观测点，并根据故障隔离和定位要求设置内部结构变换机制，内置必要的测试模块，设计自测试功能。

如图1所示，可测试性设计的基本要素有：输入/输出通道、控制点、观测点、故障隔离与定位机制、内建自测试共5个要素。

控制点是系统外部“控制输入”的作用点，用于给系统的特定状态施加控制激励或内部结构变换控制指令，主要表现为能够对产品内部状态进行控制（能控性）。

在本规范中把控制点分成了二大类：输入控制点－这部分控制点是系统本身提供的；测试控制点－这部分控制点是专门为了测试设置的，通常还需要实现对应的输入通道；观测点是系统外部直接可观测其状态，根据状态变化确定系统工作正常与否，主要表现为能够对产品内部状态进行观测（能观性）。

在本规范中把观察点分成了二大类：输出观察点－这部分观察点是系统本身提供的；测试观察点－这部分观察点是专门为了测试设置的，通常还需要实现对应的输出通道；内部隔离与定位机制用于根据测试目的变更系统内部的信息流向和处理结构，并在故障状态下对内部故障进行隔离和定位，主要表现为能够对产品内部故障进行隔离（隔离性）；输入/输出通道是为了实现对控制点进行控制和对观测点进行观测，在系统内部需要嵌入对应的外部控制输入通道和信息输出通道，常见的输入/输出通道有串口、网口等。

内建自测试（BIST）用于对系统内部进行自检、自测试以及内置数据发生器等；图1可测试性设计基本要素示意图系统的每一个基本功能模块都应具有图1所示可测试性的5个基本要素，根据各模块输入/输出通道的不同组合，可以演变为多种系统可测试性设计结构。

在可测试性理论中，系统的控制点分成8类：输入、预置条件、操作、状态、消息事件、错误、性能、资源。

输入通道在系统中也不是只有唯一的一个，需要根据不同的控制点要求进行设计。

观察点分成9类：输入、预置条件、操作、状态、消息事件、错误、性能、资源、输出。

输出通道在系统中通常不只一个，也需要根据不同的观察点特点进行设计。

2.2.2 可测试性T-IBO 模型1. IBO 模型业界有个通用的对象分析模型－IPO （Input-Process-Output ），它是一个经典的系统分析模型，典型的应用如：UML 中的USE CASE 。

它将一个对象分为输入、输出，内部处理三个部分。

相似的，对于一个软件系统（不论大小），我们将其归纳为下面的这样一个抽象模型－IBO （Input-Behavior-Output ）模型，如图7所示。

我们将软件系统分为边界外的部分和边界内的部分。

边界外有输入和输出，边界内则是软件内部行为。

这样的一个模型可以对应到整个产品软件，也可以对应到一个组件或者模块，甚至是一个函数。

因此，它可以说是一种逻辑抽象，可以方便的应用于各种粒度大小的软件的分析。

图2 通用的IPO 模型IBO模型与IPO模型的区别在于，后者强调如何去做（Process），而前者强调做了什么，对外表示出怎样的行为结果（Behavior）；后者用于分析设计软件如何完成某种功能，满足用户的需要，而前者强调对功能完成过程的观察与控制，达到验证功能实现的好坏——代码与设计的一致性，设计与用户需求的一致性。

因此从可测试性的角度出发，应用IBO模型更为合适。

对于IBO模型，举例来说：一个软件产品，其边界是系统级接口，包括：人机接口、与其它软件系统的接口、与硬件系统的接口等。