扫码获取 VIP 码
添加管理员微信获取 VIP 码
软考体系里，软件质量从来不是一个含糊的形容词，而是一套可以被度量、被评价、被命题人反复出题的结构化框架。国家标准《软件工程—产品质量》（GB/T 16260.1-2006）给出了软件质量的规范定义：软件质量是软件产品满足规定和潜在用户需求的能力，它表现为软件特性的总和。这个定义对应国际标准 ISO/IEC 9126，它的价值在于把"质量"从一个主观感受，落地为一批可以逐项核对的客观特性。
与这一定义并列的，还有一个看似相似、实则不同的表述，那就是软件质量是"软件特性的总和，以及满足规定和潜在用户需求的能力"。这里的关键词是"规定和潜在"。规定需求是指合同、需求规格说明书中明确写出来的东西；潜在需求则是指用户没有明说、但天然默认应当满足的东西，比如数据不能被随意篡改、系统崩溃后能够恢复、操作起来符合常识。命题人特别喜欢在这里出题，让考生判断"质量就是功能加性能"这类片面说法是否正确——它当然是错的，因为功能与性能只是六大特性中的两个维度。
软件质量模型，则是把"软件特性"进一步组织成层次结构的工具。GB/T 16260 将软件质量划分为三个抽象层级：最上层是质量特性，中间层是质量子特性，最底层是度量元。质量特性是分类框架，一共六个；质量子特性是对每个特性的细化，一共二十七个；度量元则是可以直接测量、直接采集数据的底层指标，为每一个子特性提供量化的证据。理解这三层关系，是掌握整个知识点的钥匙，因为软考中项、系分、软设、网工等科目考的都是前两层——特性与子特性的归属关系。
还需要特别注意，GB/T 16260 从三个不同的视角审视软件质量：内部质量、外部质量和使用质量。内部质量关注软件产品本身在开发阶段就具备的静态属性，比如代码的模块化程度、结构的内聚性；外部质量关注软件在指定环境下运行时所表现出来的行为，比如响应时间、崩溃频率；使用质量则关注用户在真实使用场景中感受到的效果，比如学习成本、任务完成效率、满意度。三者的逻辑关系是层层递进的：好的内部质量是好的外部质量的前提，好的外部质量又是好的使用质量的前提，但三者并不能互相替代，也不能互相推导。命题人常把这三个视角混在一起，让考生辨析"某句话描述的是内部质量还是外部质量"。
很多考生背六大特性背得很熟，却不理解这套模型为什么非要拆成"特性—子特性—度量元"三个层级。这背后是软件度量学的一个根本困境：软件质量是高度抽象的，抽象到无法直接测量；而任何真正有意义的评价，都必须建立在可以测量的基础之上。质量模型的作用，就是把"抽象的质量"逐级翻译成"可测量的指标"，完成从"好不好"到"好在哪、怎么测"的转化。
第一层分解解决的是"质量有哪些维度"的问题。软件质量不是单一标量，而是多维度的复合体。一个系统功能齐全但速度极慢，另一个系统速度飞快却三天两头崩溃，二者谁的质量更高，无法用一句话回答，因为它们在不同的维度上各有所长。六大特性就是把质量这个大概念切成六个正交的切片：功能性回答"它做不做得到"，可靠性回答"它靠不靠谱"，易用性回答"它好不好用"，效率回答"它快不快、省不省资源"，可维护性回答"它坏了好不好修"，可移植性回答"它能不能换个环境继续用"。这六个切片合起来，才能比较完整地刻画一个软件产品的质量全貌。
第二层分解解决的是"每个维度怎么细化"的问题。以功能性为例，它下面还藏着互操作性、安全保密性、准确性这些更具体的侧面。如果没有子特性这一层，评价者就只能笼统地说"功能性达标"，却说不清到底是哪一项功能出了问题。子特性的意义在于把评价粒度细化到可以直接对应测试活动和度量动作的层面：互操作性对应的是系统与系统之间交互的测试，安全保密性对应的是访问控制与数据加密的验证，准确性对应的是计算结果的精度校验。
第三层度量元解决的是"具体拿什么数字说话"的问题。度量元是质量模型的末端，它直接绑定测量方法与采集手段。比如"时间特性"这个子特性，可以用平均响应时间、吞吐率、周转时间这些度量元来度量；"资源利用性"可以用 CPU 占用率、内存占用峰值、带宽消耗这些度量元来度量。只有落到度量元这一层，质量评价才从"定性判断"转化为"定量结论"，才能支撑起软件测试、质量保证和第三方评测这些工程活动。
从内部质量到外部质量再到使用质量的推导关系，同样体现了这套模型的工程理性。开发阶段你无法直接测出用户满不满意，但你能够度量代码的复杂度和模块的内聚性，这些是内部质量；交付之后你可以测得响应时间和故障率，这些是外部质量；上线运行一段时间后你才能收集到学习成本和任务效率，这些是使用质量。三者的时序性决定了质量保证必须前移：与其等上线之后发现用户怨声载道，不如在编码阶段就通过内部质量度量把隐患消除在源头。这正是质量模型存在的最深层的工程价值——它让质量活动从"事后补救"变成"事前预防"。
六大特性之下共有二十七个子特性，软考的命题几乎全部集中在"某个子特性到底属于哪个特性"这类归属判断题上。下面把每一个特性及其子特性的准确含义逐一讲清，这是整篇文章的核心。
功能性是软件满足明确和隐含需求的一组能力，它的核心问题是"软件是否提供了所要求的功能，以及这些功能是否正确地工作"。它下面包含五个子特性：适合性、准确性、互操作性、安全保密性、功能性的依从性。
适合性衡量软件提供的功能是否与需求相吻合，即"该有的功能有没有、不该有的功能多没多"。准确性衡量软件处理数据时是否给出符合要求精度的结果，即"算得对不对"。互操作性衡量软件与其他指定系统进行交互的能力，即"能不能和别人家系统对话"。安全保密性衡量软件防止对程序和数据进行未授权访问的能力，即"不该看的人能不能看不到"。功能性的依从性衡量软件是否遵循了与功能性相关的标准、约定和法规。
可靠性是软件在指定条件下、指定时间内维持规定性能水平的能力，它的核心问题是"软件能否稳定地、持续地工作，出了故障能否恢复"。它下面包含四个子特性：成熟性、容错性、易恢复性、可靠性的依从性。
成熟性衡量软件在正常情况下避免失效的能力，通俗地讲就是"它平时稳不稳、是不是经常自己崩"。容错性衡量软件在发生软件缺陷或接口违规时维持规定性能水平的能力，通俗地讲就是"出了错它扛不扛得住"。易恢复性衡量软件失效后重建规定性能水平并恢复受影响数据的能力，通俗地讲就是"崩了之后能不能快速爬起来、数据丢不丢"。可靠性的依从性衡量软件是否遵循与可靠性相关的标准和约定。
易用性是软件被理解、学习、使用和吸引用户的能力，它的核心问题是"用户用起来费不费劲"。它下面包含五个子特性：易理解性、易学性、易操作性、吸引性、易用性的依从性。
易理解性衡量用户理解软件是否适合其任务、如何使用的难易程度。易学性衡量用户学会使用软件的难易程度。易操作性衡量用户操作和控制软件的难易程度。吸引性衡量软件吸引用户的能力，关注的是界面美观、交互愉悦这类体验层面的因素。易用性的依从性衡量软件是否遵循与易用性相关的标准和约定。这五个子特性里，吸引性是后来补充进来的，它把"好不好看、用起来爽不爽"这类主观体验正式纳入了质量模型，软考如果考到"界面美观属于哪个特性"，答案是易用性而非功能性。
效率是软件在规定的条件下，其性能水平与所用资源量之间关系的能力，它的核心问题是"用最少的资源把事办成"。它下面包含三个子特性：时间特性、资源利用性、效率依从性。
时间特性衡量软件执行其功能时响应时间、处理时间和吞吐率是否合适。资源利用性衡量软件执行功能时所用资源（如 CPU、内存、存储、网络带宽）的数量和类型是否恰当。效率依从性衡量软件是否遵循与效率相关的标准和约定。需要强调的是，效率考的是"性能与资源的比值"而非单纯的"快"。一个程序跑得飞快但吃满内存，其效率未必高；评价效率必须同时看时间维度和资源维度。
可维护性是软件被修改的能力，这里的修改既包括纠错，也包括改进和适应环境变化，它的核心问题是"改起来难不难"。它下面包含五个子特性：易分析性、易改变性、稳定性、易测试性、可维护性的依从性。
易分析性衡量诊断软件缺陷或失效原因、识别待修改部分的难易程度。易改变性衡量实施修改并避免意外副作用的难易程度。稳定性衡量软件在修改后避免意外结果的能力，通俗地讲就是"改了一处，别的地方会不会莫名其妙坏掉"。易测试性衡量修改后的软件被验证的难易程度。可维护
本篇完！