作者：Gakki

---

考点（分值：1 分）

• 标准化概述
• 软件质量模型与评价标准（可能考 8 个子特性）
• 软件测试标准
• 软件测试工作量及成本估算标准

1.1、标准化概述

• 软件测试作为保障软件质量的重要手段，其标准化的作用主要体现在以下几个方面：

  • 标准化是建立软件测试秩序的工具。
  • 标准化是促进软件测试技术创新应用的途径
  • 标准化是推广测试技术新技术的桥梁

• 标准的分类

  1. 国际标准
     是指国际标准化组织（ISO）、国际电工委员会（IEC）和国际电信联盟（ITU）制定的标准，以及国际标准化组织确认并公布的其他国际组织制定的标准。
  • 国家标准（可能会考）
    是指由国家标准化主管机构制定或批准发布，在全国范围内统一适用的标准。比如：GB --
    中华人民共和国国家标准；强制性国家标准代号为 GB，推荐性国家标准代号为 GB/T，国家标准指导性文件代号为 GB/Z，国军标代号为 GJB。ANSI -- 美国国家标准协会标准。
  • 行业标准
    是由某个行业机构、团队等制定的，适用于某个特定行业业务领域的标准。比如：IEEE -- 美国电气电子工程师学会标准；GA -- 公共安全标准； YD -- 通信行业标准。
  • 区域 / 地方标准
    是由某一区域/地方内的标准化主管机构制定、批准发布的，适用于某个特定区域 / 地方的标准。比如：EN -- 欧洲标准。
  • 企业标准
    是企业范围内根据需要协调、统一的技术要求、管理要求和工作要求所制定的标准，适用于本企业内部的标准。一般以 Q 字开头，比如 A/320101 RER 007 -- 2012，其中 320101 代表地区，RER 代码企业名称代号，007 一般代表企业该标准的序号，20212 代表年号。

1.2、软件质量模型与评价标准

• 软件质量是指软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度，也是执行软件测试的一个重要目标。

• GB/T 25000 “系统与软件质量要求和评价（SQuaRE）” 共分为 6 个分部，如图所示：

GB/T 25000 系列标准组织结构

• GB/T 25000 国家标准由下列分部组成：

  • GB/T 25000.n —— 质量管理分部。构成这个分部的标准定义了由 GB/T 25000 中的所有其他标准引用的全部公共模型、术语和定义。这一部分还提供了用于负责管理软件产品质量需求和评价的支持功能的要求和指南。
  • GB/T 25000.1n —— 质量模型分部。构成这个分部的标准给出了包括计算机系统和软件产品质量、使用质量和数据的详细的质量模型。同时还提供了使用这些质量模型的实用指南。
  • GB/T 25000.2n —— 质量测量分部。构成这个分部的标准包括软件产品质量测量参考模型、质量测量的数学定义及其应用的实用指南。给出了软件内部质量、软件外部质量和使用质量测量的示例。定义并给出了构成后续测量基础的质量测度元素。
  • GB/T25000.3n —— 质量需求分部。构成这个分部的标准有助于在质量模型和质量测量的基础上规定质量需求。这些质量需求可用在要开发的软件产品的质量需求抽取过程中或用作评价过程的输入。
    -GB/T25000.4n —— 质量评价分部。构成这个分部的标准给出了无论由评价方、需方还是由开发方执行的软件产品评价的要求、建议和指南。还给出了作为评价模块的测量编制支持。
    • GB/T 25000.50 — 25000.99，这是GB/T 25000的扩展分部。目前包括了就绪可用软件的质量要求和易用性测试报告行业通用格式。

• 软件质量模型的发展：

软件质量模型的发展 使用质量模型

• 考点：

  1. 5 大特性以及含义。

• 模型将使用质量属性划分为5个特性：

  • 有效性
    是指用户实现指定目标的准确性和完备性。

    • 有效性
      子特性就是其本身。

  • 效率
    是指用户实现目标的准确性和完备性时相关的资源消耗。

    • 效率
      子特性就是其本身。

  • 满意度
    是指产品或系统在指定的使用周境中，用户的要求被满足的程度。

    • 有用性
      用户对实用目标的实现感到满意的程度,包括使用的结果和使用后产生的后果。
    • 可信性
      用户或者其他利益相关方对产品或系统将如预期地运行有信心的程度。
    • 愉悦性
      用户因个人要求被满足而获得愉悦感的程度。注:个人要求可包括获得新的知识和技能、进行个性化交流和引发愉快的回忆。
    • 舒适性
      用户生理上感到舒适的程度。

  • 抗风险
    是指产品或系统在经济现状、人的生命、健康或环境方面缓解潜在风险的程度。

    • 经济风险缓解性
      在预期的使用周境中，产品或系统在经济现状、高效运行、商业财产、信誉或其他资源方面缓解潜在风险的程度。
    • 健康和安全风险缓解性
      在预期的使用周境中，产品或系统缓解人员潜在风险的程度。
    • 环境风险缓解性
      在预期的使用周境中，产品或系统在财产或环境方面缓解潜在风险程度。

  • 周境覆盖：
    是指在指定的使用周境中，产品或系统在有效性、效率、抗风险和满意度等特性方面能够被使用的程度。

    • 周境完备性：
      在所有指定的使用周境中，产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度。
    • 灵活性：
      在超出最初设定需求的周境中，产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度。灵活性使产品考虑现状、机会和个人喜好等非预期因素。如果产品设计时未考虑灵活性,那么在预期之外的周境下使用该产品可能是不安全的。

• 考点：

  1. 有哪 8 个特性
  2. 每个特性的含义。
  3. 有哪些子特性。

• 产品质量：

产品质量

• 功能性：
  在指定条件下使用时，产品或系统提供满足明确和隐含要求的功能的程度。

• 性能效率：
  性能与在指定条件下所使用的资源量有关。资源的影响因素包括硬件配置和配套的软件产品。

• 兼容性：
  在共享相同的硬件或软件环境的条件下，产品、系统或组件能够与其他产品、系统或组件交换信息，和/或执行其所需的功能的程度。

• 易用性
  在指定的使用周境中，产品或系统在有效性、效率和满意度特性方面为了指定的目标可为指定用户使用的程度。

• 可靠性
  系统、产品或组件在指定条件下、指定时间内执行指定功能的程度。

• 信息安全性
  产品或系统保护信息和数据的程度，已使用户、其他产品或系统具有与授权类型和授权级别一致的数据访问度。

• 维护性
  产品或系统能够被预期的维护人员修改的有效性和效率的程度。

• 可移植性
  系统、产品或组件能够从一种硬件、软件或者其他运行（或使用）环境迁移到另一种环境的有效性和效率的程度。

• 软件产品质量评价参考模型概述中给出了通用的软件质量评价模型，包括评价过程以及关联的评价输入、评价约束、评价资源和评价输出。其中，评价约束包括特定用户要求、资源、计划表、成本、环境、工具和方法论、报告等。评价资源包括适用的测量工具、方法论和评价模块，适用的 SQuaRE 文档，软件产品质量评价所需的人力资源、经济资源、信息系统和知识数据库等。

• 评价过程的策略和步骤具体如下：

  1. 确立评价需求
     • 明确评价目的；
     • 获取软件产品质量需求；
     • 标识待评价的产品部件；
     • 确定评价严格度；
  2. 规定评价
     • 选择质量测度；
     • 确定质量测度判定准则；
     • 确定评价判定准则；
  3. 设计评价
     • 策划评价活动
  4. 执行评价
     • 实施测量；
     • 应用质量测度判定准则；
     • 应用评价判定准则；
  5. 结束评价
     • 评审评价结果；
     • 编制评价报告；
     • 评审质量评价并向组织提交反馈；

• RUSP（就绪可用产品）是一种打包出售给对其特征和其他质量没有任何影响的需方的软件产品。

• RUSP要求：包含产品说明要求、用户文档集要求、软件质量要求。

• 测试文档集要求：主要是规定各方在对软件产品进行测试时，需要整理编写的测试文档的合集，应包括测试计划、测试说明、测试结果等文档。

• 符合性评价细则：产品说明、用户文档集和所交付软件应满足本部分的符合性评价要求。

1.3、软件测试标准

• 测试过程标准

  1. 组织级测试过程：定义用于开发和管理组织级测试规格说明的过程，例如组织级测试方针、组织级测试策略、过程、规程和其他资产的维护。
  2. 测试管理过程：定义涵盖整个测试项目；或任何测试阶段（例如系统测试）或测试类型（例如性能测试）的测试管理过程（例如项目测试管理、系统测试管理、性能测试管理）测试管理过程包含测试策划过程、测试监测和控制过程、测试完成过程3 个子过程
  3. 动态测试过程：定义执行动态测试的通用过程。动态测试可以在测试的特定阶段执行（例如单元测试、集成测试、系统测试和验收测试），或者用于测试项目中特定类型的测试（例如性能测试、信息安全测试和功能测试）。动态测试包含测试设计和实现过程、测试环境构建和维护过程、测试执行过程、测试事件报告 4 个子过程。

• 测试文档标准

  1. 组织级测试文档集：组织级测试规格说明描述组织层面测试的信息，并且不依赖于项目，其在组织测试过程中的典型示例包括测试方针和组织级测试策略。

     • 测试方针定义了组织内适用的软件测试的目的和原则，规定了测试应该完成使命
     • 组织测试策略是一个技术性文档，针对组织内部如何进行测试提供指导。

  2. 测试管理文档集：测试管理过程中制定的文档包含测试计划、测试状态报告和测试完成报告

     • 测试计划描述了在初始规划期间做的决定，并作为控制活动的一部分进行重新规划
     • 测试状态报告提供了在特定报告期间内执行测试的状态信息
     • 测试完成报告提供了已执行测试的总结，该总结可针对整个项目，也可针对特定的测试子过程。

  3. 动态测试文档集：动态测试过程中产生的文档包含测试规格说明，测试数据需求、测试环境需求、测试数据准备报告、测试环境准备报告、测试执行档集。

  • 测试规格说明分为测试设计规格说明、测试用例规格说明和测试规范规格说明。测试设计规格说明确定了要测试的特征，并从每个特征的测试依据导出测试条件，作为定义测试用例和要执行的测试规程的第一步。测试用例规格说明测试覆盖项，以及从一个或多个特征集的测试依据导出的相应测试用例。测试规程规格说明按照执行顺序描述了所选测试集中的测试用例，以及设置初始条件和执行结束后活动所需的任何相关操作。
    • 测试数据需求：描述规格说明中定义的测试规程所需的测试数据的属性
    • 测试环境需求：描述了测试规程中说明定义所需的测试环境属性
    • 测试数据准备报告：每一个测试数据的完成情况
    • 测试环境准备报告：每一个测试环境需求的完成情况
    • 测试执行文档集：实测结果、测试结果、测试执行日志和事件报告

• 测试技术标准

  • 常见的软件测试技术可分为基于规格说明的测试设计技术（黑盒测试）、基于结构的测试设计技术（白盒测试）和基于经验的测试设计技术3 类。
    • 基于规格说明的测试：测试依据（如需求、规格说明、模型或用户需求）是设计测试用例的首要信息来源
    • 基于结构的测试中，测试项的结构（如源代码或模型结构）是设计测试用例的首要信息来源
    • 基于经验的测试中，测试人员的知识和经验是设计测试用例的首要信息来源。

常用的测试设计技术

1.4、软件测试工作量及成本估算标准（不重要）

1. 软件测试成本构成：直接成本和间接成本

• 直接成本（项目直接支出）
  完成测试项目而支出的各类人力资源禾工具资源的综合，直接成本的开指仅限于测试生存周期内，包括人工成本、测试环境成本、测试工具成本等。
• 间接成本（多个项目之间分摊的成本）
  服务于软件测试项目的管理组织成本，可能会超出测试生存周期，包括办公成本和管理成本等。

2. 软件测试成本调整因子（了解）

• 由于软件本身色特性和各种客观条件，在通过软件测试人工工作量度量之后，仍需要对工作量进行调整

• 软件复杂度是指软件本身由于功能、规模或结构方面具有一定的复杂性而导致测试难度增大、增加了测试工作量，被测软件的复杂性可按照以下特性进行度量：

  • 存在大量的控制或者安全设施
  • 系统规模较大，子模块较多且相互影响关联，或需要与其他系统对接使用
  • 非简体中文软件
  • 存在大量的逻辑处理或处理过程复杂
  • 存在大量的数字处理或算法复杂

• 软件完整性调整因子是依据 GB/T 18492-2001 给出的系统完整性级别来确定调整因子取值范围，软件完整性可由系统完整性推出。

• 测试风险是指软件测试过程中可能会产生的风险，可能的测试风险由以下部分构成：

  • 被测试软件的领域有特殊要求
  • 测试需求不明确
  • 被测试软件与测试文档不一致
  • 测试过程中测试方与开发方因沟通等导致不可预计的风险
  3. 软件测试成本度量

• 软件测试成本度量可以分以下几个步骤，如图所示：

软件测试成本度量的实施步骤