企业官网建设流程全解析

备考软考系统架构设计师的朋友，对“软件质量属性”这个词一定不陌生。但很多人在复习时容易陷入两个极端：要么觉得它太抽象，看书时一带而过；要么以为它只是选择题里的几个名词，背下来就完事。结果到了案例分析题和论文写作，碰到“质量属性场景”“效用树”“架构战术”这类考查方式，才发现自己其实并没有真正理解这块内容。

实际上，软件质量属性是系统架构设计师考试中贯通三科的核心考点。上午综合知识会考概念辨析，下午案例分析会考场景描述与架构评估，论文更是几乎绕不开对非功能需求的分析与架构决策论证。把这部分吃透，性价比非常高。本文就用一篇教程的篇幅，把质量属性的分类、核心属性、场景六要素、效用树以及架构战术完整梳理一遍，帮你在考前快速建立清晰的知识框架，顺便把最容易丢分的细节补上。

1. 软件质量属性到底是什么

1.1 从“功能之外”理解质量属性

我们平时开发软件，最先关注的是功能需求：用户点击按钮，系统能完成下单；用户输入关键词，系统能返回搜索结果。这些都是系统“做什么”的问题。

但软件系统除了要“能做这些事”，还要回答另一组问题：

• 用户下单时，系统响应要有多快？
• 系统运行过程中出故障了，能多快恢复？
• 用户数据放在系统里，安不安全？
• 三个月后业务变了，代码好不好改？
• 新来的测试人员，能不能快速把核心功能测一遍？

这些和业务功能本身没有直接关系、但又直接影响系统能否长期稳定运行的特征，就是软件质量属性。它描述的是软件系统在特定条件下满足利益相关者（用户、开发者、运维人员、管理者等）期望的程度。

专业一点说，软件质量属性是软件架构中“非功能需求”的可度量体现。功能需求决定系统提供什么能力，质量属性决定这个能力是否值得信任、是否好用、是否可持续演进。

1.2 为什么它是软考架构师的核心考点

系统架构设计师这个科目的核心命题思路，很接近一个真实架构师的工作场景：面对一堆需求，你要设计出满足功能目标、同时兼顾性能、可用性、安全性、可修改性的架构方案，并且能论证你的设计是合理的。

软考对质量属性的考查基本围绕三层展开：

• 概念层：常见的质量属性有哪些，分别解决什么问题。
• 分析层：如何把一个模糊的“系统要快一点”扩展成可度量的质量属性场景。
• 设计层：在架构设计中，用什么“战术”去支撑某个质量属性；当多个质量属性冲突时，如何权衡。

这三层恰好分布在上下午三科里。所以质量属性不只是选择题考点，更是案例分析题和论文的底层思维框架。哪怕论文题目表面上在问“论微服务架构设计”“论大数据处理架构”，你依然需要在需求分析部分交代质量属性优先级，在架构设计部分说明战术落地。

2. 软件质量属性的分类体系

软考教材和主流架构理论中，质量属性通常按软件生命周期分成两大类：运行期质量属性与开发期质量属性。

2.1 运行期质量属性

运行期质量属性指软件在运行阶段表现出来的特性，用户和运维人员可以直接感知。

常见包括：

• 性能：系统处理请求的速度和吞吐能力。
• 安全性：系统抵御非法访问和数据泄露的能力。
• 可用性：系统在给定时间段内正常运行、可被访问的程度。
• 可靠性：系统在规定条件下不发生故障的概率。
• 易用性：用户学习、操作、理解系统的难易程度。

其中可靠性和可用性容易混淆，后面会单独区分。

2.2 开发期质量属性

开发期质量属性指与软件开发、维护、测试、部署过程相关的特性，主要影响开发者和运维者的工作效率。

常见包括：

• 可修改性：需求变化时，修改系统某个部分的难易程度。
• 可测试性：软件是否容易被测试，能否快速定位缺陷。
• 可移植性：软件迁移到新硬件平台或新操作系统平台的难易程度。
• 可集成性：软件组件与其他系统、第三方模块集成时的难易程度。

2.3 质量属性不是孤立的

在实际架构设计中，质量属性之间经常互相制约。典型例子是：

• 提高可用性往往需要引入冗余节点，成本上升，可能牺牲一定性能。
• 提高可修改性会引入更多抽象层和接口，调用链变长，可能带来性能损耗。
• 提高安全性需要增加认证、加密、审计操作，用户体验变复杂，可能影响易用性。

因此，架构设计本质上是在多个质量属性之间做权衡。软考案例分析题经常通过“给定优先级列表，让你评价某架构方案的合理性”来考查这种权衡能力。

3. 八大关键质量属性逐个拆解

这部分对高频质量属性做逐一说明。不仅要知道定义，还要知道软考如何从这些属性中出题。

3.1 性能

性能是系统处理任务时体现出的时间与资源效率。衡量性能的核心指标有三个：

• 响应时间：从用户发出请求到收到完整响应所花的时间。
• 吞吐量：单位时间内系统成功处理的请求数或事务数，如 TPS（每秒事务数）。
• 并发用户数：系统同一时刻能稳定支撑的在线用户数量。

性能问题的本质是：当事件（请求）到达时，系统是否有足够的资源在限定时间内处理完毕。架构层面影响性能的因素包括：服务器硬件资源、数据库索引、缓存设计、线程模型、网络带宽、代码逻辑复杂度等。

软考中性能相关场景很容易识别，关键词通常是“响应时间小于 xx 秒”“每秒支持 xx 笔交易”“高峰期并发达到 xx”。

3.2 可用性

可用性衡量系统在给定时间点上能够正常提供服务的程度。公式是：

可用性 = MTBF / (MTBF + MTTR) × 100%

其中：

• MTBF（Mean Time Between Failures）：平均无故障时间，反映系统保持正常运行的能力。
• MTTR（Mean Time To Repair）：平均修复时间，反映系统出故障后恢复的速度。

从这个公式能看出来，提升可用性有两条路：要么延长 MTBF，让系统更少出故障；要么缩短 MTTR，让故障恢复更快。后者正是架构上引入冗余、自动故障切换、回滚机制的原因。

常见的可用性等级指标是“几个 9”：

案例分析题如果出现“系统可用性需达到 99.99%”，你要立刻想到 MTTR 必须控制在分钟级，架构上要有自动探测、自动切换、冗余部署等机制。

3.3 可靠性

可靠性指系统在规定的条件下和规定的时间内完成规定功能的概率。它关注的是“不出错”的能力。

可靠性和可用性的区别可以这样理解：

• 可靠性关注故障发生的频率：越少故障，越可靠。
• 可用性关注故障发生后，系统恢复并继续服务的能力：恢复越快，可用性越高。

一个系统可能可靠性不高，经常出小故障，但如果每次故障都能秒级自动恢复，可用性依然很高。反过来，一个系统可能一年只故障一次，但故障后要花三天修复，可用性就非常低。

软考概念题中经常把这两个放一起考，答题时优先从“故障频率 vs 修复速度”的角度做区分。

3.4 安全性

安全性是保护系统免受恶意攻击和数据泄露的能力。软考中安全性的讨论常围绕三个核心目标：

• 机密性：数据只被授权用户访问。
• 完整性：数据在传输和存储过程中不被篡改。
• 可用性：系统在攻击条件下仍能对合法用户提供服务。

这里的“可用性”和信息安全中的“可用性”其实是同一概念，只是描述角度不同，注意别和通信类“应用可用性”搞混。

安全性场景常见的架构战术包括：身份认证、权限授权、数据加密、数字签名、安全审计日志、入侵检测、防 SQL 注入等。

3.5 可修改性

可修改性指系统被修改的难易程度。需求变更、新功能开发、缺陷修复都属于“修改”的范畴。

可修改性的关键不在代码本身，而在架构层面的模块划分与耦合控制。如果一个模块改动会导致连锁反应、牵一发而动全身，它的可修改性就差。

架构上提升可修改性的常见思路包括：

• 分层架构中保持层间接口稳定。
• 模块间通过接口通信，而不是直接依赖实现类。
• 用配置文件、插件、事件驱动等方式，把“变更”的触发时间推迟到开发完成后。
• 对变化频繁的业务进行领域划分，把易变部分隔离到独立模块。

软考中可修改性场景的关键词有“新增一种支付方式”“调整促销规则”“3 天内完成某需求变更”等。

3.6 可测试性

可测试性指软件发现缺陷并进行验证的难易程度。它关注两点：

• 控制：测试人员能否方便地控制软件内部状态、注入输入。
• 观察：测试人员能否快速观察到软件的输出和内部运行结果。

架构层面可以做的支持包括：日志记录、运行状态监控、测试接口、可替换的依赖组件（便于 mock）、模块化设计带来的独立测试能力。

3.7 易用性

易用性指用户学习、操作、理解系统的难易程度。包括：

• 用户能否快速上手。
• 操作是否符合直觉。
• 出错时是否有清晰的提示。
• 误操作是否能够撤销。

架构上虽然不会为易用性做过多设计，但前端界面设计、交互流程、帮助系统、撤销/重做机制、表单校验等都支撑了易用性目标。

3.8 可移植性

可移植性指软件在不同运行环境（操作系统、硬件平台、浏览器、数据库）之间迁移的难易程度。常见支撑手段包括：

• 使用跨平台语言或运行时。
• 隔离环境依赖，通过配置层适配不同部署环境。
• 遵守标准协议和数据格式。

云原生时代，可移植性也体现在“应用可以在不同云平台或本地环境之间迁移”。软考偶尔结合分布式、容器化环境考察这个概念。

4. 重点难点：质量属性场景六要素

质量属性场景是软考系统架构设计师考试的绝对核心，也是案例分析题中最常见的考点之一。

4.1 为什么要引入质量属性场景

在项目早期，利益相关者提质量需求时往往只说一句话：

• “系统要够快。”
• “系统要稳定一点。”
• “系统一定要安全。”

这些话没法度量，也没法作为架构设计的输入。质量属性场景的作用，就是把一句模糊的期望拆解成六个具体的要素，让每个质量属性需求都变得清晰、可验证、可权衡。

这一点在实际项目中同样重要：没写清楚响应时间是“2 秒内”还是“10 秒内”，架构师根本无法判断要不要上缓存、要不要上分布式数据库。

4.2 六要素解析

质量属性场景由以下六个要素组成：

4.3 用实例理解六要素

我们以“性能”为例写一个完整场景：

在正常业务时段（环境），大量用户（刺激源）同时发起下单请求（刺激），系统订单模块（制品）需要在 2 秒内返回下单结果、每秒处理 5000 笔交易（响应），并以响应时间和吞吐量为标准度量（响应度量）。

对照一下就清楚：刺激源是用户，刺激是下单请求，环境是正常业务时段，制品是订单模块，响应是返回下单结果，响应度量是 2 秒 / 5000 TPS。

再写一个“可用性”场景：

当数据库节点故障时（刺激源为数据库节点、刺激为节点宕机），在系统高负载运行期间（环境），交易服务（制品）自动切换到备用数据库节点并在 5 分钟内恢复正常读写（响应），切换过程业务中断时间不超过 5 分钟（响应度量）。

再写一个“安全性”场景：

在系统对外开放的 Web 服务上（环境），未授权用户（刺激源）通过伪造 Token 访问管理接口（刺激），认证服务（制品）拒绝该请求并记录审计日志（响应），非法请求的拦截率应达到 100%（响应度量）。

软考出题方式一般是：给出一个场景描述，要求你指出其中的刺激源、刺激、环境、制品、响应、响应度量分别是什么。复习时只要抓住“谁触发、发生什么、什么状态下、作用在哪个对象、系统怎么回应、可量化指标是多少”这个六问法，基本能得分。

4.4 从场景反推质量属性

反过来，考试也可能给你一段业务描述，让你判断它体现的是哪个质量属性，并把六要素补完整。此时关键词识别法很好用：

• “响应时间”“吞吐量”“并发” → 性能
• “故障恢复”“可用性 xx%”“自动切换” → 可用性
• “未授权”“篡改”“加密”“审计” → 安全性
• “变更成本”“新增功能”“3 天实现” → 可修改性

5. 重点难点：质量属性效用树

5.1 效用树是什么

在架构评估方法 ATAM（Architecture Tradeoff Analysis Method，架构权衡分析方法）中，有一个非常实用的工具叫“效用树”。它把抽象的“系统效用”逐层分解为可度量的质量属性场景，用来梳理利益相关者对系统的真实需求优先级。

效用树的结构是树形分层的，从上到下一般分四层：

• 根节点：效用（Utility），可以理解成系统整体的价值体现。
• 第一层：质量属性分类，如性能、可用性、安全性、可修改性。
• 第二层：属性细分，如性能可以细分为“响应时间”“吞吐量”。
• 叶子节点：具体的场景描述，一般包含刺激和响应。

5.2 效用树示例

以在线交易系统为例，做一个简化版效用树：

效用（Utility） ├── 性能 │ ├── 响应时间 │ │ └── 正常情况下，下单请求 2 秒内返回结果 │ └── 吞吐量 │ └── 高峰期每秒处理 5000 笔交易 ├── 可用性 │ ├── 故障恢复 │ │ └── 数据库主节点宕机后，5 分钟内自动切换到备用节点 │ └── 冗余能力 │ └── 支付服务部署双节点，单节点故障不影响业务 ├── 安全性 │ ├── 身份认证 │ │ └── 非法 Token 访问管理接口时，100% 拒绝 │ └── 数据加密 │ └── 用户敏感信息存储时加密，防止内部泄露 └── 可修改性 ├── 支付渠道扩展 │ └── 新增一种支付方式，3 天内完成，且不修改核心交易流程 └── 接口扩展 └── 新增开放 API 时，不需要改动已有接口逻辑

注意看叶子节点：它们其实就是右边的简写版质量属性场景。所以先学会写质量属性场景，再学效用树就水到渠成了。

5.3 软考中的考察方式

效用树在软考中出现频率较高的是案例分析题。常见的设问方式有：

• “请用效用树描述该系统的质量属性需求。”
• “根据题目给出的架构方案，识别其中通过效用树体现出的核心质量属性。”
• “指出某质量属性在效用树中优先级最高/最低，并说明对架构选择的影响。”

答题技巧：首先明确效用树必须从“效用”这个根开始分层；其次每个叶子节点要尽量写成“刺激 + 响应 + 度量”的形式；最后要说明你选出的质量属性优先级如何影响架构决策。比如可用性优先级最高，意味着要选冗余部署、故障切换架构；性能优先级高，则要优先考虑缓存、并发设计和负载均衡。

5.4 效能评估中的优先级标注

在 ATAM 方法论中，效用树的每个叶子节点还会标上优先级和风险等级（如高/中/低），用来衡量该场景对项目成功的重要程度。软考案例分析里如果要求 “评估架构风险”，本质上就是看：高优先级的质量属性场景，当前架构方案能不能满足。如果不能满足，就是一个架构风险点，需要进行架构调整或权衡。

6. 架构战术：质量属性如何落地

知道“要什么质量属性”只是第一步。架构师还要知道“用什么机制去实现它”。这个“机制”在软考教材中称为“架构战术（Tactics）”。战术是影响质量属性控制能力的架构决策，是连接需求和设计之间的桥梁。

6.1 可修改性战术

提升可修改性的核心思路是：把变更的影响限制在一个局部范围内，减少连锁反应，并且尽可能推迟绑定时间。

常用战术有：

• 局部化变更：设计时把容易变化的点和稳定的点分开，如领域驱动设计中的限界上下文。
• 防止连锁反应：模块间依赖抽象接口而非具体实现；信息隐藏；设置中介者模式减少网状依赖。
• 推迟绑定时间：让“哪个组件参与处理、如何处理”的决策延后到编译后、启动时或运行时，典型手段包括配置文件、依赖注入、插件机制、运行时动态加载。

其中“绑定时间”这个概念容易出选择题。绑定时间越晚，系统可修改性越强，但运行时复杂度也会变高。

6.2 可用性战术

可用性战术分为三大类：错误检测、错误恢复、错误预防。

错误检测常用战术：

• 心跳：系统组件定期发出心跳消息，监控方接收不到就判定组件异常。
• Ping/Echo：主动发 Ping，对方回应 Echo 才算正常。
• 监控（Watchdog）：独立监控进程定时检查系统状态。
• 异常检测：程序抛出异常后触发默认处理流程，及时隔离错误。

错误恢复常用战术：

• 主动冗余（热备份）：多个相同组件并行接收请求，一个失败，其余节点接管。
• 被动冗余（冷备份）：备用节点定期同步主节点状态，主节点故障时由备用节点接管。
• 重试：请求失败后按策略重新发起调用。
• 回滚：事务执行失败时回退到上一个一致状态。

错误预防常用战术：

• 事务机制：保证操作要么全部成功，要么全部失败。
• 进程监视器：组件异常退出后被重新拉起。
• 缓冲区：削峰填谷，避免瞬时压力压垮系统。

6.3 性能战术

性能问题的本质是“事件到达时资源是否够用”。性能战术围绕三个方面展开：控制资源需求、管理资源、仲裁资源。

控制资源需求：

• 提高计算效率：优化算法、减少不必要计算。
• 减少计算开销：引入缓存、预取数据、批处理请求。
• 控制资源使用：限制队列长度、控制并发数。
• 管理资源：搞清资源由谁管理、什么时候创建、如何回收，典型如线程池、连接池。

管理资源：

• 引入并发：多线程、异步化，增加并行处理能力。
• 维持数据副本：把热点数据复制到缓存或本地，减少远程访问。
• 采用合理的调度策略：如读写分离、分区路由。

仲裁资源：

• 优先级策略：重要请求优先获得资源。
• 负载均衡：把请求分散到多个服务实例，避免单点过载。

6.4 安全性战术

安全性战术围绕“抵抗攻击、检测攻击、从攻击中恢复”三条线展开。

抵抗攻击：

• 身份认证：验证用户身份，如登录密码、短信验证码、OAuth 令牌。
• 用户授权：控制已认证用户能访问哪些资源。
• 数据机密性：使用加密算法保护传输和存储数据。
• 数据完整性：使用校验和、数字签名防止篡改。
• 审计：记录关键操作日志，方便追踪责任。

检测攻击：

• 入侵检测：通过规则或异常行为识别攻击。
• 验证消息完整性：识别请求在传输过程中是否被篡改。

从攻击中恢复：

• 恢复状态：定时生成检查点，攻击或故障后回退到安全状态。
• 识别攻击者：结合审计日志和 Trace 信息分析攻击来源与路径。

容易被忽略的一点是审计日志，软考案例题里常把“数据库操作不留审计”设计成一个架构缺陷，考察考生有没有意识到可审计性属于安全性的重要组成部分。

6.5 可测试性战术

可测试性战术的目标是“让测试更容易发现缺陷，更容易定位问题”。

常用手段：

• 控制接口：提供测试钩子，允许在测试时注入数据、触发特定分支。
• 记录测试输入输出：可回溯地比对结果和预期。
• 内部监控：模块暴露内部状态，方便观测。
• 可执行断言：在代码中嵌入自动校验逻辑，快速感知异常。

微服务架构中常用链路追踪和日志聚合来提升可测试性，就是观察手段的具体实践。

6.6 易用性战术

易用性战术不复杂，软考中了解即可，但不要完全不读。

运行时相关：

• 合理的界面设计与交互流程。
• 操作可取消、可撤销/重做。
• 及时的用户输入校验与错误提示。
• 帮助系统与文档。

设计时相关：

• 通过原型快速获取用户反馈。
• 建立用户模型（用户画像），提前规避操作障碍。

7. 完整案例：在线交易系统的质量属性分析

这里走一遍实际软考案例分析题的答题思路。以“在线交易系统”为例，完整展示从需求描述到质量属性场景，再到效用树和架构战术的过程。

7.1 背景说明

某在线交易平台准备重构订单核心链路，业务部门给出的关键诉求如下：

• 大促高峰期订单量是平时的 10 倍，系统不能卡死。
• 支付环节依赖第三方渠道，渠道不稳定会导致订单失败。
• 客户敏感数据被泄露。
• 运营希望未来一个月内能快速接入新的营销活动规则，而不用每次都发版。

7.2 用质量属性场景梳理

把业务诉求翻译成质量属性场景：

• 性能场景：在 618 大促高峰期（环境），大量用户（刺激源）同时提交订单（刺激），订单服务（制品）需要在 2 秒内返回成功或失败，且错误率低于 1%（响应），以响应时间、吞吐量、错误率作为度量（响应度量）。
• 可用性场景：当第三方支付网关超时或宕机（刺激源），在订单量高峰时段（环境），交易模块（制品）自动切换备用支付渠道并在 10 秒内完成切换，总体支付成功率不低于 99%（响应），以恢复时间和成功率为度量（响应度量）。
• 安全性场景：当外部攻击者（刺激源）通过构造恶意参数访问未授权订单接口（刺激），在应用对外提供服务期间（环境），API 网关（制品）拦截请求并触发告警（响应），攻击拦截率应为 100%（响应度量）。
• 可修改性场景：当运营人员（刺激源）提出新营销活动规则时（刺激），在系统运行期不停机状态下（环境），促销引擎模块（制品）通过配置方式在 1 个小时内完成规则上线且不修改订单核心代码（响应），上线耗时为度量（响应度量）。

7.3 对应效用树

效用 ├── 性能：高峰 5000 TPS，下单响应 ≤2s ├── 可用性：支付网关故障 10s 内切换，支付成功率 ≥99% ├── 安全性：非法请求拦截率 100% └── 可修改性：新活动规则 1 小时内配置上线

7.4 架构战术落地

根据上述场景，可以选择的架构方案包括：

• 性能：订单服务无状态化，支持水平扩容；热点商品数据使用 Redis 缓存；数据库读写分离；采用消息队列削峰。
• 可用性：订单服务多副本部署，通过注册中心探活；支付网关采用多通道降级，超时自动切换；失败订单进入本地消息表做可靠性重试。
• 安全性：API 网关统一做身份认证与鉴权；敏感字段 AES 加密存储；全链路审计日志；限流与熔断防止恶意流量冲击。
• 可修改性：营销活动规则引擎化，支持配置化上架；订单核心链路与促销逻辑解耦，促销模块以插件方式接入。

写作题或案例简答时，把“质量属性场景 → 效用树 → 战术 → 架构方案”这条链写清楚，就能让阅卷老师看到你有完整的架构分析能力。

8. 常见问题与备考误区

9. 应试建议与复习策略

9.1 综合知识重点范围

要把每个质量属性的定义、可用性公式、六要素、效用树结构、战术分类全部掌握。尤其是“质量属性场景六要素”和“可修改性绑定时间”这两类题，出题概率极高。

9.2 案例分析题答题套路

遇到质量属性相关案例题，建议按四步走：

1. 审题：明确题目要求你分析哪个质量属性或哪几个质量属性。
2. 找证据：从材料中圈出环境、刺激源、刺激、制品、响应、度量等关键词。
3. 结构化作答：按六要素成组写，不要只写一两句话。
4. 连架构：说明针对该场景应当采用哪些战术或架构方案。

9.3 论文写作中的质量属性嵌入

论文评分非常看重两点：架构设计是否合理、是否对需求做了充分分析。建议在论文开头就写一段“质量属性场景列表”，用表格把两三个核心质量属性写清楚，然后说明你如何通过架构设计来满足它们。这比开头泛泛写“本系统具有高可用和高性能”要扎实得多。

9.4 复习节奏建议

质量属性内容不算多，不需要花整块时间。建议用两周左右的碎片时间完成：

• 第一周：理解结论概念，逐个质量属性看例子，做分类练习。
• 第二周：集中突破场景六要素和效用树，配合历年真题练习。
• 考前：把战术分类和案例答题套路整理成速记清单，反复看。

10. 总结

软件质量属性看起来只是几个名词，但它实际上是系统架构设计师考试的一条暗线：上午题考概念，下午题考分析，论文考应用。只要把质量属性分类、场景六要素、效用树和战术体系这四块内容串起来，你会发现案例分析题里很多“无从下手”的题目其实都有固定解法。

这篇文章的重点可以浓缩成三句话：

• 质量属性是架构设计的目标，架构方案是达成目标的战术组合。
• 质量属性场景是用结构化语言描述非功能需求的最好方式。
• 效用树帮助你在多个质量属性目标之间梳理优先级，做出权衡决策。

如果你正在紧张备考，建议把文中每一个场景示例和效用树示例都亲手默写一遍，然后对照历年真题检验。质量属性这个考点一旦打通，对案例题和论文提升都很有帮助。祝你复习顺利，考试多拿分。