🔝 浅谈软件质量

作者: 潘峰 / 2019-06-12 / 分类: Work

测试杂谈

一、软件质量是什么

GB/T 25000.10-2016 标准(基于 ISO/IEC 25010:2011 标准)中将软件质量定义为:

在规定条件下使用时,软件满足用户明确和隐含要求的能力。满足程度越高,质量就越好。

其中隐含的要求是指可能未明确阐述但实际需要的要求。
站在用户角度来看,我们可以说质量就是 终端用户的满意度

二、软件质量模型

想要清楚地知道明确和隐含的要求是什么,我们需要建立软件质量模型。GB/T 25000.10-2016 中将软件质量模型分为使用质量模型和产品质量模型,其中使用质量模型由 5 个质量特性组成,产品质量模型由 8 个质量特性组成。

产品质量可以认为是软件系统自身固有的内在特征和外部表现,而使用质量是从用户使用的角度去感知到的质量,产品质量和使用质量的关系如下:

使用质量模型

  • 有效性
    • 有效性「用户实现指定目标的准确性和完备性」
  • 效率
    • 效率「与用户实现目标的准确性和完备性相关的资源消耗」
  • 满意度「产品或系统在指定的使用周境中使用时,用户的要求被满足的程度」
    • 有用性「用户对实用目标的实现感到满意的程度,包括使用的结果和使用后产生的后果」
    • 可信性「用户或者其它利益相关方对产品或系统将如预期地运行有信心的程度」
    • 愉悦度「用户因个人要求被满足而获得愉悦感的程度」
    • 舒适性「用户生理上感到满意的程度」
  • 抗风险「产品或系统在经济现状、人的生命、健康或环境方面缓解潜在风险的程度」
    • 经济风险缓解性「在预期的使用周境中,产品或系统在经济现状、高效运行、商业财产、信誉或其它资源方面缓解潜在风险的程度」
    • 健康和安全风险缓解性「在预期的使用周境中,产品或系统缓解人员潜在风险的程度」
    • 环境风险缓解性「在预期的使用周境中,产品或系统在财产或环境方面缓解潜在风险的程度」
  • 周境覆盖「在指定的使用周境和超出最初设定需求的周境中,产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度」
    • 周境完备性「在所有指定的使用周境中,产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度」
    • 灵活性「在超出最初设定的需求的周境中,产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度」

产品质量模型

  • 功能性「在指定条件下使用产品时,产品或系统提供满足明确和隐含要求的功能的程度」
    • 功能完备性「功能集对指定的任务和用户目标的覆盖程度」
    • 功能正确性「产品或系统提供具有所需精度的正确的结果的程度」
    • 功能适合性「功能促使指定的任务和目标实现的程度」
    • 功能性的依从性「产品或系统遵循与功能性相关的标准、约定或法规以及类似规定的程度」
  • 性能效率「性能与在指定条件下所使用的资源量有关」
    • 时间特性「产品或系统执行其功能时,其响应时间、处理时间及吞吐率满足需求的程度」
    • 资源利用性「产品或系统执行其功能时,所使用资源数量和类型满足需求的程度」
    • 容量「产品或系统参数的最大限量满足需求的程度」
    • 性能效率的依从性「产品或系统遵循与性能效率相关的标准、约定或法规以及类似规定的程度」
  • 兼容性「在共享相同软硬件环境的条件下,产品、系统或组件能够与其它产品、系统或组件交换信息,和/或执行其所需的功能的程度」
    • 共存性「在与其它产品共享通用的环境和资源条件下,产品能够有效执行其所需的功能并且不会对其它产品造成负面影响的程度」
    • 互操作性「两个或多个系统、产品或组件能够交换信息并使用已交换的信息的程度」
    • 兼容性的依从性「产品或系统遵循与兼容性相关的标准、约定或法规以及类似规定的程度」
  • 易用性「在指定的使用周境中,产品或系统在有效性、效率和满意度特性方面为了指定的目标可为指定用户使用的程度」
    • 可辨识性「用户能够辨识产品或系统是否适合他们的要求的程度」
    • 易学性「在指定的使用周境中,产品或系统在有效性、效率、抗风险和满意度特性方面为了学习使用该产品或系统这一指定的目标可为指定用户使用的程度」
    • 易操作性「产品或系统具有易于操作和控制的属性的程度」
    • 用户差错防御性「系统预防用户犯错的程度」
    • 用户界面舒适性「用户界面提供令人愉悦和满意的交互的程度」
    • 易访问性「在指定的使用周境中,为了达到指定的目标,产品或系统被具有最广泛的特征和能力的个体所使用的程度」
    • 易用性的依从性「产品或系统遵循与易用性相关的标准、约定或法规以及类似规定的程度」
  • 可靠性「软件在指定条件下、指定的时间内执行指定功能的程度」
    • 成熟性「软件在正常运行时能够进行操作和访问的程度」
    • 可用性「软件在需要使用时能够进行操作和访问的程度」
    • 容错性「在出现内部或外部故障时,软件的运行符合预期的程度」
    • 易恢复性「在发生中断或失效时,系统或产品能够恢复直接受影响的数据并重建期望的系统状态的程度」
    • 可靠性的依从性「系统或产品遵循与可靠性相关的标准、约定或法规以及类似规定的程度。」
  • 信息安全性「产品或系统保护信息和数据的程度,以使用户、其他产品或系统具有」
    • 保密性「产品或系统确保数据只有在被授权时才能被访问的程度」
    • 完整性「系统、产品或组件防止未授权访问、篡改计算机程序或数据的程度」
    • 抗抵赖性「活动或事件发生后可以被证实且不可被否认的程度」
    • 可核查性「实体的活动可以被唯一地追溯到该实体的程度」
    • 真实性「对象或资源的身份标识能够被证实符合其声明的程度」
    • 信息安全性的依从性「产品或系统遵循与信息安全性相关的标准、约定或法规以及类似规定的程度」
  • 维护性「产品或系统能够被预期的维护人员修改的有效性和效率的程度」
    • 模块化「由多个独立组件组成的系统或计算机程序,其中一个组件的变更对其他组件的影响最小的程度」
    • 可重用性「资产能够被用于多个系统,或其它资产建设的程度」
    • 易分析性「可以评估预期变更(变更产品或系统的一个或多个部分)对产品或系统的影响、诊断产品的缺陷或失效原因、识别待修改部分的有效性和效率的程度」
    • 易修改性「产品或系统可以被有效地、有效率地修改,且不会引入缺陷或降低现有产品质量的程度」
    • 易测试性「能够为系统、产品或组件建立测试准则,并通过测试执行来确定测试准则是否被满足的有效性和有效率的程度」
    • 维护性的依从性「产品或系统遵循与维护性相关的标准、约定或法规以及类似规定的程度」
  • 可移植性「软件能够从一种软硬件或者其它运行环境迁移到另一种环境的有效性和效率程度」
    • 适应性「软件能够有效及有效率地适应不同的或演变的软硬件或其他运行环境的程度」
    • 易安装性「在指定环境中,产品能够成功地安装、卸载的有效性和效率的程度」
    • 易替换性「在相同环境中,产品能够替换另一个相同用途的指定软件产品或该产品旧版本的程度」
    • 可移植性的依从性「产品和系统遵循与可移植性相关的标准、约定或法规以及类似规定的程度」

软件质量模型的作用

  • 确定质量需求
  • 建立质量测度
  • 执行质量评价

三、软件质量保障

如果说软件质量是终端用户满意度的体现,
那么软件质量保障工作的终极目标就是 确保终端用户的满意度

四、软件质量保障体系(个人思考)

为了让软件质量保障工作得以系统化地开展(系统化的好处:能保证最终结果的可靠性),我们需要建立软件质量保障体系。
它需要解决软件质量保障工作做什么,如何做,以及如何评估和优化的问题。

软件质量保障工作的着手点:

  • 从质量类型上划分:产研质量控制及其数据收集、运营质量监控及其数据收集
  • 从执行上划分:人、过程、工具、数据

软件质量保障工作如何开展?

想要开展好软件质量保障工作,我们需要针对每个着手点开展一系列的工作,做到多管齐下,方能收到最大的成效。

从人的角度来看,参与到质量保障的工作中的角色不应该仅仅只有测试人员,更需要产品人员、开发人员、运维人员,甚至是老板的一起参与,因为只有大家都认真地重视质量,质量才能不断地提高。因此,在质量保障的工作中每个角色都需要关注质量,也许他们仅需要重点关注其中的某一部分,例如:产品人员需要做的是从设计层面确保产品质量的功能性、易用性,使所设计的功能与用户预期一致;
开发人员需要从实现层面确保产品质量的功能性、维护性,但这并不意味着他们就不需要关注其他质量特性了;
测试人员是质量保障工作的主导者,负责对产品质量的所有特性及子特性进行验证和确认工作,并进行软件质量的评估与反馈,以及软件缺陷的预防。除此之外,测试人员还需要有效地利用起由运维团队建立的生产监控平台和报警机制,到做到生产质量问题的尽早发现;
运维人员并不需要特别关注软件质量,但他们需要确保软件运行环境的稳定,以及协助测试人员做好线上问题监控。

从过程的角度来看,软件质量保障工作需要渗入到产品研发流程的每一个阶段。在需求阶段我们应该建立更加严格的需求评审,进行更加详细的需求分析,以及更加完善的需求准出机制;在开发阶段需要开展技术评审、开发自测、代码 review、代码扫描等工作,以及完善的代码准出机制;由于软件测试是质量保障的主要手段,测试阶段不应该是开发阶段完成后的一个独立阶段,它应该贯穿于整个软件生命周期,做到持续不断地测试。

从数据的角度来看,我们需要收集软件生命周期中的一些必要数据,以对软件质量进行有效评估和改进。包括需求阶段发现的问题数,开发未自测问题数,各时间段发现的缺陷的数量,线上用户反馈的问题数,以及新功能的用户使用率和留存率等等。

监控的目的是为了在线上及早地发现和及早地解决质量保障过程中的漏网之鱼,以降低质量问题最终影响到的用户数量。