当前位置：首页 > news >正文

架构师备考-背诵精华（系统质量属性）

news 2025/8/11 4:01:15

系统质量属性

根据GB/T 16260.1 定义，从管理角度对软件系统质量进行度量，可将影响软件质量的主要因素划分为6种维度特性包括：功能性、可靠性、易用性、效率、维护性、可移植性

功能性
- 适合性、准确性、互操作性、依从性、安全性

可靠性
- 容错性、易恢复性、成熟性

易用性
- 易学性、易理解性、易操作性

效率
- 资源特性、时间特性

维护性
- 可测试性、可修改性、稳定性、易分析性

可移植性
- 适应性、易安装性、一致性和可替换性

开发期质量属性

开发期质量属性包括：易理解性、可拓展性、可重用性、可测试性、可移植性

运行期质量属性

运行期质量属性包括：性能、安全性、可伸缩性、互操作性、可靠性、鲁棒性

质量属性场景描述

质量属性场景是一种面向特定质量属性的需求，由6部分组成：刺激源、刺激、环境、制品、响应、响应度量

刺激源：这是某个个生成刺激的实体。
刺激：该刺激是当刺激到达系统时需要考虑的条件
环境：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
制品：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
响应：该响应是在激励到达后所采取的行动。
响应度量：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

面向架构评估的质量属性

性能

是指系统的响应能力，及要经过多长时间才能对某个事件做出响应，或者在某段事件内系统所能处理的事件的个数。经常用单位时间内处理事务的数量或系统完成某个事物处理所需的时间来对性能进行定量标识。性能测试经常要使用基准测试程序。

性能质量属性场景

刺激源：用户请求、其他系统触发等
刺激：事件（定期、随机、偶然事件）
制品：系统
环境：正常模式、超载模式
响应：处理刺激、改变系统状态
响应度量指标：处理时间所花时间、单位时间内处理事件的数目、处理的错误率/丢失率

提升性能的策略

提升性能的策略包含以下方式：资源需求、资源管理、资源仲裁

资源的需求：减少处理事件时对资源的占用、减少处理事件的数量、控制资源的使用
- 减少处理事件时对资源的占用：改进算法、减少计算开销
- 减少处理事件的数量：控制事件到来的速率、控制采样频率
- 控制资源的使用：限制执行时间、限制队列大小
资源管理：并发机制、增加资源
- 并发机制：多核、多线程
- 增加资源：计算资源、存储资源、带宽资源
资源仲裁：先来先服务、固定优先级、动态优先级、静态调度
- 动态优先级：时限时间最早优先、轮转调度

可靠性

可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特征，通常用来衡量在规定的条件和时间内，软件完成规定功能的能力。通常用平均失效等待时间MTTF 和平均失效间隔时间 MTBF 来衡量。在失效率为常数和修复时间很短的情况下，MTTF 和 MTBF 几乎相等。可靠性分为两个方面：

容错
- 容错的目的是错误发生时确保系统正确的行为，并进行内部“修复”。例如在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作，直到错误再次发生。
健壮性
- 这里说的是保护应用程序不受错误使用和错误输入的影响，在发生意外错误事件时确保应用系统处于预先定义好的状态。值得注意的是，和容错相比，健壮性并不是说在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。软件架构对软件系统的可靠性有巨大的影响。例如，软件架构设计上通过在应用程序内部采用冗余机制，或集成监控构件和异常处理，以提升系统可靠性。

软件/硬件可靠性对比

复杂性：软件失效可能性大于硬件
物理退化：硬件有物理退化，软件没有
唯一性：软件唯一,硬件不可能相同
版本更新快：软件更新比硬件快

软件可靠性定量描述

规定时间：人们使用执行时间来度量软件的可靠性最为准确，效果也最好
失效概率
可靠度：软件规定的条件下、规定的时间内不发生失效的概率
失效强度：单位时间软件系统出现失效的概率；

使用失效强度来表示软件缺陷对软件运行的影响程度
失效严重程度类就是对用户具有相同程度影响的失效集合

平均失效前时间（MTTF）：Mean Time To Faliure：从t=0 时到故障发生时系统的持续运行时间的期望值，不包括老化失效。
平均恢复前时间（MTTR）Mean Time To Restoration：从出现故障到修复成功的一段时间
平均故障间隔时间（MTBF）Mean Time Between Failures：失效或维护中所需的平均时间，包括故障时间以及检测和维护设备的时间；MTBF = MTTF+ MTTR

影响软件可靠性的因素

运行环境
软件规模
软件的内部结构
软件的开发方法和开发环境
软件的可靠性投入

软件可靠性建模

可靠性建模的步骤包括：模型假设、性能度量、参数估计方法、数据要求

模型假设。模型是实际情况的简化或规范化，总要包含若干假设，例如测试的选取代表实际运行剖面，不同软件失效独立发生等。
性能度量。软件可靠性模型的输出量就是性能度量，如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。
参数估计方法。某些可靠性度量的实际值无法直接获得，例如残留缺陷数，这时需要通过一定的方法估计参数的值，从而间接确定可靠性度量的值。估计是通过收集到的失效数据进行统计分析，利用一定的推导过程归纳出模型的参数；预测则是使用软件产品自身的属性和开发过程来确定模型的参数，这种方法可以在开始执行程序前完成。
数据要求：一个软件可靠性模型要求一定的输入数据，即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。

模型的3个共同假设包括：代表性假设、独立性假设、相同性假设
- 代表性假设。此假设认为软件测试用例的选取代表软件实际的运行剖面，甚至认为测试用例是独立随机地选取。此假设实际上是指可以用测试产生的软件可靠性数据预测运行阶段的软件可靠性行为。
- 独立性假设。此假设认为软件失效是独立发生于不同时刻，一个软件失效的发生不影响另一个软件失效的发生。
- 相同性假设。此假设认为所有软件失效的后果相同，即建模过程只考虑软件失效的具体发生时刻，不区分软件的失效严重等级

好的可靠性建模满足：
- 基于可靠的假设
- 简单
- 计算一些有用的量
- 给出未来失效行为的好的映射
- 可广泛应用

软件的可靠性模型分类

类型	描述
种子法模型	预先在程序中播种错误“种子”，根据测试找出错误以及估计残留错误数量。
失效率类模型	用来研究程序的失效率
曲线拟合类模型	用回归分析的方法研究软件复杂性、程序中的缺陷数、失效率、失效间隔时间，包括参数方法和非参数方法两种。
可靠性增长模型	预测软件在检测过程中的可靠性改进，用增长函数来描述软件的改进过程
程序结构分析模型	根据程序、子程序及其相互间的调用关系，形成一个可靠性分析网络
输入域分类模型	选取软件输入域中的某些样本“点”运行程序，根据这些样本点在“实际”使用环境的使用概率的测试运行时的成功/失效率，推断软件的使用可靠性。
执行路径分析方法模型	先计算程序各逻辑路径的执行概率和程序中错误路径的执行概率，再综合出该软件的使用可靠性
非齐次泊松过程模型	以软件测试过程中单位时间的失效次数为独立泊松随机变量，来预测在今后软件的某使用时间点的累计失效数
马尔可夫过程模型	用于预测未来的数学模型
贝叶斯模型	利用失效率的试验前分布和当前的测试失效信息，来评估软件的可靠性

软件可靠性管理

软件可靠性管理分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、实施阶段

需求分析阶段	确定软件的可靠性目标分析可能影响可靠性的因素确定可靠性的验收标准制订可靠性管理框架制定可靠性文档编写规范制订可靠性活动初步计划确定可靠性数据收集规范
概要设计阶段	确定可靠性度量制定详细的可靠性验收方案可靠性设计收集可靠性数据调整可靠性活动计划明确后续阶段的可靠性活动的详细计划。编制可靠性文档
详细设计阶段	可靠性设计可靠性预测调整可靠性活动计划收集可靠性数据明确后续阶段的可靠性活动的详细计划编写可靠性文档
编码阶段	可靠性测试排错调整可靠性活动计划收集可靠性数据明确后续阶段的可靠性活动的详细计划编制可靠性文档
测试阶段	可靠性测试排错可靠性建模可靠性评价调整可靠性活动计划收集可靠性数据明确后续阶段的可靠性活动的详细计划编制可靠性文档
实施阶段	可靠性测试排错收集可靠性数据调整可靠性模型可靠性评价编制可靠性文档

软件可靠性设计

容错设计
- 恢复快设计：恢复快方法是一种动态的故障屏蔽技术，采用向后恢复策略。
- N版本程序设计:N版本程序设计是一种静态的故障屏蔽技术，采用向前恢复的策略。（订单、对账、清算工作）
- 防卫式程序设计：通过在程序中包含错误检查代码和错误恢复代码，使得一旦发生错误，程序就能撤销错误状态，恢复到一个已知的正确状态中去
- 冗余设计：改善软件可靠性的一个重要技术是冗余设计。在硬件系统中，在主程序运行的系统之外备用额外的元件或系统，如果出现一个元件故障或系统故障，则立即更换冗余的元件或切换到冗余的系统，则该硬件仍可以继续维持运行。在软件系统中，冗余技术的运用有所区别。如果采用相同两套软件系统互为备份，其意义不大，因为在相同的环境中，一套软件出现故障的地方，另外一套也一定会出现故障。软件冗余设计技术实现的原理是在一套完整的软件系统之外，设计一种不同路径、不同算法或不同实现方法的模块或系统作为备份，在出现故障时可以使用冗余的部分进行替换，从而维持软件系统的正常运行。

检错技术
- 采用检错技术要着重考虑几个要素：检测对象、检测延迟、实现方式和处理方式
- 检测对象：包含两个层次的含义，即检测点和检测内容。在设计时应考虑把检测点放在容易出错的地方和出错对软件系统影响较大的地方；检测内容选取那些有代表性的、易于判断的指标。
- 检测延时：从软件发生故障到被自检出来是有一定延时的，这段延时的长短对故障的处理是非常重要的。因此，在软件检错设计时要充分考虑到检测延时。如果延时长到影响故障的及时报警，则需要更换检测对象或检测方式
- 实现方式：最直接的一种实现方式是判断返回结果，如果返回结果超出正常范围，则进行异常处理。计算运行时间也是一种常用的技术，如果某个模块或函数运行超过预期的时间可以判断出现故障。另外，还有置状态标志位等多种方法，自检的实现方式要根据实际情况来选用。
- 处理方式：大多数检错采用：查出故障-停止软件系统运行-报警的处理方式，但也有采用不停止或部分停止软件系统运行的情况，这一般由故障是否需要实时处理来决定。

降低复杂度设计
- 软件复杂性常分为模块复杂性和结构复杂性
  - 模块复杂性主要包含模块内部数据流向和程序长度两个方面
  - 结构复杂性用不同模块之间的关联程度来表示
- 降低复杂度的思想就是在保证实现软件功能的基础上，简化软件结构、缩短程序代码长度，优化软件数据流向，降低软件复杂度，从而提高软件可靠性。
系统配置技术
- 系统配置技术主要包括双机热备、双机互备、双机双工、服务集群技术
- 双机热备：双机热备即是目前通常所说的active/standby方式，服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。当 active服务器出现故障的时候，通过软件诊测(一般是通过心跳诊断)将standby机器激活，保证应用在短时间内完全恢复正常使用。
- 双机互备：在双机热备的基础上，两个相对独立的应用在两台机器同时运行，但彼此均设为备机，当某一台服务器出现故障时，另一台服务器可以在短时间内将故障服务器的应用接管过来，从而保证了应用的持续性。这种方式实际上是双机热备的一种应用。它避免了两个应用使用四台服务器分别实现双机热备。
- 双机双工：两台或多台服务器均为活动，同时运行相同的应用，保证整体的性能，也实现了负载均衡和互为备份。需要利用磁盘柜存储技术(最好采用san)。对于数据库服务而言，它同时需要数据库软件的支持，是比较复杂的。而WEB服务器或应用服务器就比较简单了。
- 服务器集群技术：集群技术是指一组相互独立的服务器在网络中组合成为单一的系统工作，并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。大多数情况下，集群中所有的计算机拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户所使用。

可靠性测试

分为广义的可靠性测试与狭义的可靠性测试
- 广义的软件可靠性测试是指为了最终评价软件系统的可靠性而运用建模、统计、试验、分析和评价等一系列手段对软件系统实施的一种测试。
- 狭义的软件可靠性测试是指为了获取可靠性数据，按预先确定的测试用例，在软件的预期使用环境中，对软件实施的一种测试
目的
- 发现软件系统在需求、设计、编码、测试和实施等方面的各种缺陷
- 为软件的使用和维护提供可靠性数据
- 确认软件是否达到可靠性的定量要求
步骤
- 可靠性目标的确定
- 定义软件运行剖面
- 测试用例的设计
- 测试实施
- 测试结果分析

内容
- 软件产品标识
- 测试环境配置（软件和硬件）
- 测试依据
- 测试结果
- 测试问题
- 测试时间

可靠性评价过程

可靠性的评价过程包括：选择可靠性模型、收集可靠性数据、可靠性评估和预测

选择可靠性模型
- 模型假设的适用性
- 预测的能力与质量
- 模型输出值是否满足可靠性评价需求
- 模型使用的简便性

收集可靠性数据
- 尽早确定可靠性模型，并确定需要收集的可靠性数据
- 制定数据收集计划
- 重视测试产生的数据
- 利用数据库分析

可靠性评估和预测
- 评估和预测依赖于可靠性模型
- 使用支持软件可靠性估计的软件工具；失效数据的图形分析法、试探性数据分析技术

可用性

可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

可用性质量属性

刺激源：故障（来自系统内部或外部）
刺激：系统出错，系统崩溃（反复出错），给出结果不及时，给出错误结果
制品：计算或存储或网络
环境：正常状态，降级模式
响应：错误报告，回传厂家；通知管理员或其它系统；关闭系统，系统在维修期间不可用
响应度量指标：故障时间百分比，平均故障修复时间，平均无故障时间

提升可用性的策略

提升可用性的策略包括：错误检测、错误恢复、错误避免

错误检测：心跳，ping/Echo，异常
- 心跳：被监控组件定期向监控的组件发出心跳消息。若连续未收到的心跳信号到了一定的数目，则认为相应的系统已经出现故障。
- ping/Echo: 监控组件不定期向被监控的组件发出ping 消息，并根据收到的echo 消息做出响应
- 异常：需要编程语言的支持。如抛出+ 捕获+ 处理
错误恢复：表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚
- 表决：多个冗余的组件，用同一或不同的算法来完成一个任务，如果计算结果不同，则由表决器按照算法（少数服从多数的原则）确定
- 主动冗余：服务器A 和B并行完成同样的运算，它们的状态时刻保持一致，平时只取A算出的结果。当A 出现故障时，系统可以迅速切换到B
- 被动冗余：服务器A完成运算后，在一定时间内通知服务器B 进行更新
- 重新同步：主动冗余和被动冗余都需要在重新上线前，做状态的重新同步
- 检查点/回滚：定期保存，便于恢复
错误避免：服务下线、事务、进程监控器

安全性

是指系统在合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可根据系统可能受到的安全威胁类型来分类。安全性又可分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程。完整性保证信息的完整和准确，防止信息被非法修改；不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。