认识软件质量
软件产品质量属性
这一章会从软件质量的基本概念出发，以标准化（ISO/IEC25010）的软件定义，介绍软件产品质量模型和使用质量模型。里面的内容都可以在《GBT25000.10-2016系统与软件工程系统与软件质量要求和评价(SQuaRE)第10部分系统与软件质量模型》中找到详细解释，这里主要列出我们测试工作中常用且必须关注的质量特性以及实际场景中如何运用。
系统/软件产品质量属性有8个特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性和可移植性。其中功能性，性能效率，可靠性、易用性（人工差错防御）是我们着重需要关注的质量特性，也是导致线上90%故障的主要因素。
产品质量特性说明和理解：
我们从8个方面去阐述产品质量特性
-
功能性
-
性能效率
-
可靠性
-
易用性
-
兼容性
-
信息安全性
-
可维护性
-
可移植性
1. 功能性
在指定条件下使用时，产品或系统提供满足明确和隐含要求的功能的程度。包括：
-
功能完备性
-
功能正确性
-
功能适合性
-
功能性的依从性
从定义上来理解，功能性并不止满足 “明确” 的要求，还有很多 “隐含” 的质量特性。我们在做功能测试的时候，“明确”+“隐含”需求一起覆盖才是完整的测试场景。我们在工作中如何能前置让隐含的需求明确，是质量同学的一项重要能力，这个过程包括在需求前期跟PD的明确，比如需求文档里描述了想要实现的功能，但没有写明对性能和用户体验的要求，测试同学就是需要在评审阶段就对焦明确，这样在TC设计，测试策略以及后面业务方验收测试中才能充分被覆盖到。还是一个基本原则，问题越前置被识别并解决，是成本最低的做法。
| 功能子属性 | 子属性特性描述 |
|---|---|
| 完备性 | 功能集对指定的任务和用户目标的覆盖程度； |
| 正确性 | 产品或系统提供具有所需精度的正确的结果的程度； |
| 适合性 | 功能促使指定的任务和目标实现的程度 |
| 功能性的依从性 | 产品或系统遵循与功能性相关的标准、约定或法规以及类似规定的程度。 |
2. 性能效率
性能效率的评估与在指定条件下所使用的资源量有关。包括时间特性、 资源利用率 、容量、性能效率的依从性。
实际工作中，我们基础架构的弹性能力，常态化压测能力、大促的全链路压测等都是这一质量属性的测试体现。后面在测试进阶能力中，会有专门篇幅介绍性能测试和全链路压测的内容。
| 功能子属性 | 子属性特性描述 |
|---|---|
| 实践特性 | 产品或系统执行其功能时,其响应时间、处理时间及吞吐率满足需求的程度； |
| 容量 | 产品或系统参数的最大限量满足需求的程度； |
| 资源利用率 | 产品或系统执行其功能时,所使用资源数量和类型满足需求的程度； |
| 性能效率的依从性 | 产品或系统遵循与性能效率相关的标准、约定或法规以及类似规定的程度。 |
3. 可靠性
系统、产品或组件在指定条件下、指定时间内执行指定功能的程度。包括成熟性、可用性、容错性、易恢复性、可靠性的依从性。
质量同学在评估方案时经常会出现这样的灵魂拷问：怎样设计测试场景保障线上不出问题、如何设计架构让主流程不受阻塞、强弱依赖如何解耦、准备怎样的预案让问题发生时也能快速恢复等，都是对可靠性质量属性的测试实践，可靠性也是我们在设计评审中需要着重关注的特性。
| 功能子属性 | 子属性特性描述 |
|---|---|
| 成熟性 | 系统、产品或组件在正常运行时满足可靠性要求的程度； |
| 可用性 | 系统、产品或组件在需要使用时能够进行操作和访问的程度； |
| 容错性 | 尽管存在硬件或软件故障,系统、产品或组件的运行符合预期的程度； |
| 易恢复性 | 在发生中断或失效时,产品或系统能够恢复直接受影响的数据并重建期望的系统状态的程度； |
| 可靠性的依从性 | 产品或系统遵循与可靠性相关的标准、约定或法规以及类似规定的程度。 |
4. 易用性
在指定的使用环境中,产品或系统在有效性、效率和满意度特性方面为了指定的目标可为指定用户使用的程度。包括可辨识性、易学性、易操作性、人工差错防御性、易访问性、易用性的依从性。
易用性的另一个描述就是功能级别的用户体验（下一章会介绍使用级别的用户体验），我们新零售技术质量的愿景就是“做用户体验的捍卫者”，因此易用性是测试过程中很重要的一个覆盖范围。易用性里核心需关注的是人工差错防御，我们有很多故障或线上问题都来自于人工操作或配置类错误，这都是人工差错防御范围。
| 功能子属性 | 子属性特性描述 |
|---|---|
| 可辨识性 | 用户能够辨识产品或系统是否适合他们的要求的程度； |
| 易学性 | 在指定的使用环境中,产品或系统在有效性、效率、抗风险和满意度特性方面为了学习使用该产品或系统这一指定的目标可为指定用户使用的程度； |
| 易操作性 | 产品或系统具有易于操作和控制的属性的程度； |
| 人工差错防御性 | 系统预防用户犯错的程度；用户界面舒适性：用户界面提供令人愉悦和满意的交互的程度； |
| 易访问性 | 在指定的使用环境中,为了达到指定的目标,产品或系统被具有最广泛的特征和能力的个体所使用的程度； |
| 易用性的依从性 | 产品或系统遵循与易用性相关的标准、约定或法规以及类似规定的程度。 |
5. 兼容性
在共享相同的硬件或软件环境的条件下,产品、系统或组件能够与其他产品、系统或组件交换信息,和/或执行其所需的功能的程度。
包括共存性、互操作性、兼容性的依从性。 兼容性测试在移动应用测试和跨平台组件应用上需着重评估。
6. 信息安全性
产品或系统保护信息和数据的程度,以使用户、其他产品或系统具有与其授权类型和授权级别一致的数据访问度。包括保密性、完整性、抗抵赖性、可核查性、真实性、信息安全的依从性。
这部分质量属性直接对应安全性测试，已经是测试领域里独立的一个重要方向。后面的进阶篇会有详细介绍。
7. 可维护性
产品或系统能够被预期的维护人员修改的有效性和效率的程度。包括 模块化、可重用性、易分析性、易修改性、易测试性、维护性依从性。 可维护性更多体现在对设计方案的评估过程中。
8. 可移植性
系统、产品或组件能够从一种硬件、软件、或者其他运行(或使用)环境迁移到另一种环境的有效性和效率的程度。包括适应性、易安装性、易替换性、可移植性的依从性。 迁移类项目和版本升级类变更需评估。
产品使用质量属性
使用质量属性是从用户使用体验的角度进行定义，质量同学作为用户体验的捍卫者，除了产品质量，使用质量也需要关注。它描述了产品(系统或软件产品)对利益相关方造成的影响。它是由软件、硬件和运行环境的质量,以及用户、任务和社会环境的特性所决定的。所有这些因素均有利于系统的使用质量。
产品使用质量属性说明：
-
有效性： 用户实现指定目标的准确性和完备性。
-
效率： 与用户实现目标的准确性和完备性相关的资源消耗。
-
满意度： 产品或系统在指定的使用环境中使用时，用户的要求被满足的程度。包括有用性：用户对实用目标的实现感到满意的程度，包括使用的结果和使用后产生的后果；可信性：用户或者其他利益相关方对产品或系统将如预期地运行有信心的程度；愉悦性：用户因个人要求被满足而获得愉悦感的程度；舒适性：用户生理上感到舒适的程度。
-
抗风险： 包括经济风险缓解性：在预期的使用环境中，产品或系统在经济现状、高效运行、商业财产、信誉或其他资源方面缓解潜在风险的程度；健康和安全风险缓解性：在预期的使用环境中，产品或系统缓解人员潜在风险的程度；环境风险缓解性：在预期的使用环境中，产品或系统在财产或环境方面缓解潜在风险程度。
-
周境覆盖： 在指定的使用周境和超出最初设定需求的周境中，产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度。包括周境完备性：在所有指定的使用环境中，产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度；灵活性：在超出最初设定需求的环境中，产品或系统在有效性、效率、抗风险和满意度特性方面能够被使用的程度。
认识软件测试
对软件质量思考的不同角度，形成了不同的测试类型，不同类型对应不同的测试方法，而不同的测试方法针对不同的质量特性。要修炼更深更广的测试覆盖度，需要了解更多的测试方法用于设计测试用例。这类方法的介绍书籍非常多，下图是一个质量特性对应测试方法的展示。实际项目中测试时间和资源往往有限，测试工程师就需要不断的思高效的质量保障手段。下图很多方法都已能通过工具或技术手段来完成，比如异常测试，故障输入，幂等，灰度验证等等。因此质量特性对应的方法更多只是一个范围的参考，给测试同学一个基本原则，如何保障好这个特性，需要我们不断的思考测试技术的突破来实现。
测试类型
根据测试方法不同的类型
-
黑盒测试 - 也称功能测试或基于需求的测试，测试设计时把被测对象当成一个黑盒子，不关心盒子的内部结构，主要通过输入/输出数据驱动功能用例。这类测试中理论上的充分测试标准就是“穷举输入”，而穷举肯定是不可能的，因此我们还需要其他的测试类型进行补充。
-
白盒测试 - 也称为逻辑驱动测试，针对性较强，需要对代码逻辑有了解。理论上的充分测试是所有的条件、语句、路径组合都被覆盖，对技术和成本都有一定要求。
-
灰盒测试 - 介于白盒与黑盒之间的测试方式，根据实际测试场景、资源、复杂度等情况进行结合，也是目前我们使用最多的测试类型。
每种测试类型都对应很多测试分析方法，后面进阶篇也会针对各种测试方向进行深入介绍，这里不对基本概念和原理多做赘述。
软件测试的基本原则
基本功修炼的最后，我们可以归纳出一系列重要的测试指导原则，可作为我们日常工作的提醒。原则大部分看上去显而易见，浅显易懂。但往往故障都发生在这些常见的场景中，用一位开发TL在某次故障复盘会上的话，给“修炼测试基本功”这一章做个结束语：故障中的一切问题看似天灾人祸，实则人事不修。
| 序号 | 原则 |
|---|---|
| 1 | 穷尽测试是不可能的 -穷举测试解决不了覆盖问题，多思考创新采用技术手段丰富覆盖度 |
| 2 | 测试左移和测试右移（Shift left testing and Shift right testing） - 测试应尽早介入，问题发现越晚修复代价越大。同时测试活动也不应停止于发布前，线上业务监控，回归以及系统恢复都是测试职责范围。 |
| 3 | 缺陷集群效应 - 一旦某个模块发现了较多问题，那一定隐藏了更多的问题 |
| 4 | 杀虫剂悖论 - 测试用例和自动化脚本、工具、数据等要定期更新，用同样的内容测变化的系统会越来越难发现问题。 |
| 5 | 测试依赖于上下文 - 质量保障不能仅仅考虑需求本身，还需要考虑关联的上下游等诸多因素 |
| 6 | **没有不存在缺陷的系统 **- 要充分对系统进行风险分析，没发现问题不代表没有缺陷。 |
| 7 | 测试用例的设计不仅要考虑有效输入输出，也应该考虑无效和未预测到的输入情况，异常测试必须覆盖 |
| 8 | 检查系统是否“没有完成应该完成的”，仅仅是测试的一半，另一半是检查系统是否“做了不应该做的”。 |
| 9 | 随时沉淀，随时总结，随时思考，质量保障是持续性的，创造性的，富有挑战性的工作。 |