02.软件测试软件测试 1.是什么传统软件测试软件工程中的很多概念来自传统的工程行业，测试是一种检验产品质量的活动。

软件测试

1.是什么

传统软件测试

软件工程中的很多概念来自传统的工程行业，测试是一种检验产品质量的活动。因此，通常意义上的软件测试被定义为特定环境下检查软件是否存在错误，以及能否满足业务需求和设计的活动或过程

新时代软件测试

软件的含义不仅仅是程序本身，还包括文档、数据和其他基础设施，因此对软件质量的保证并没有局限于代码本身。这也是越来越多的公司将测试工程师的岗位转变为质量工程师的原因

全流程测试

由于对软件的修改伴随着整个软件生命周期，业界开始提倡全流程测试，或者叫全生命周期质量保证。编写单元测试或者特定类型的测试只是软件测试的一小部分

软件开发过程中，无论采用的是瀑布开发模式还是敏捷开发模式，都会存在需求分析、设计、编码、测试、运行等过程。在基于全流程测试的发展过程中，越来越多的测试类型被提出来，比如需求测试、架构测试、设计测试、单元测试、集成测试等

2.相关岗位

3.bug（缺陷）

介绍

如果软件没有按照我们的期望运行，我们会说软件有bug。bug的原意是臭虫，这个名称的来源是继电器计算机中飞进的一只飞蛾

不过在软件工程领域，更多使用缺陷来描述软件没有按照预期运行的现象。缺陷描述的不仅仅是程序编码上的错误，还包括需求和设计的不合理，运营期间的配置问题，以及基础设施故障等

历史

被公认为世界上最早一批程序员中的葛丽丝·霍普女士在Mark II计算机上工作时，设备无法正常工作了，整个团队都不知道怎么回事。后来经过排查发现是一只飞蛾飞入设备内部引起的故障（Mark II是一台继电器计算机，异物的侵入会导致元件无法工作）。葛丽丝·霍普女士在她的笔记中记录了这个故事，说明问题的根因是一个虫子引起的， bug这个词也流传了下来

注意

需要注意的是，缺陷并不一定会导致程序运行错误，由缺陷导致程序发生错误，叫做缺陷的激活。缺陷往往需要在特定的条件和场景下才会被激活，例如，一些特别的输入或者运行环境发生变化

未知条件和场景下的缺陷修复起来非常困难，软件测试的工作就是将能复现这些缺陷的场景找出来，以便于修复

级别

现在也有很多公司根据优先级和严重性对导致问题的缺陷进行分类，比如将缺陷分为4个级别：

P0致命：非常严重的线上事故（比如让整个系统瘫痪），需要停下手上的工作立即修复。如果不能在一定时间内修复，需要上报，通过其他途径来解决（比如使用备用方案）
P1严重：部分重要功能不可使用，虽然优先级没有P0那么高，但是也需要立即修复并发布补丁
P2一般：次要功能不可使用，会给用户带来不便，但是由于需要平衡正常工作节奏，因此不会立即修复，在迭代发布时修复即可
P3轻微：会给用户带来不便，或者UI、文案上存在需要调整的内容。在不影响开发节奏的前提下，进行优化处理即可

生命周期

状态

4.CMMI

能力成熟度模型集成（CMMI）是一个组织过程改进框架，CMMI中的不同等级描述了不同层次的软件开发能力，也就是软件工程成熟度。CMMI对软件质量提出了要求，这些要求也是很多公司对质量工程师的诉求

5.目的

6.流程

7.分类

按软件生产阶段划分

按源代码可见度划分

其他分类

其他

功能测试
接口测试
自动化测试
冒烟测试
回归测试
性能测试
安全测试
静态分析
E2E测试
契约测试

8.软件质量模型

介绍

功能性

性能

兼容性

易用性

可靠性

安全性

可移植性

可维护性

9.测试金字塔/自动化测试分层体系

介绍

软件测试有很多类型，测试金字塔的核心理念是：不同测试类型的收益和性价比是不一样的

为了取得最优的测试效果，在不同性价比的测试上投入的时间也应不一样的。通常来说，基于界面的测试，自动化难度高，且为了能覆盖更多的的场景，并让测试正常运行，需要准备的数据量也更多，相应地投入的时间也会较多

单元测试则不太一样，测试的目标更加精确，需要准备的测试数据量较少，同时单元测试运行得更快，因此投入的时间较少

在《Succeeding with Agile》一书中提出了一个测试金字塔，形象地描述了界面测试、服务测试和单元测试的差异。下图是简单的测试金字塔，可以用来描述不同测试类型的执行速度和消耗资源的情况

实际上测试金字塔中层次的划分取决于所采用的技术栈，并不拘泥于上图中所示这三层。在微服务系统中，我们通常使用的测试金字塔可以描述为：单元测试、API 测试、界面测试

与自动化测试的关系

测试金字塔的每一层都可以选用不同的工具来实现自动化

注意

测试金字塔只是一种对测试划分方法的模型，这种模型可以有非常多的解释和变种。在一些测试金字塔中我们可能会看到手工测试、验收测试等内容，也可能会有非常多层。测试金字塔主要应用于敏捷过程的测试工作中，在其他的软件开发过程中也不同的测试模型，例如V模型

10.测试策略

介绍

从测试金字塔又可以引申出另外一个非常重要的测试概念，那就是测试策略。测试策略描述的是一个项目或者产品如何组织测试活动，以获取最大的价值

完整的测试策略就是一个项目的完整测试框架，涵盖了关于质量的各方面测试清单，以及对应的实施方式。测试策略可以是一份详尽的文档，也可以是一个图示或者一份简单的检查清单

下图展示了一份简单明了的测试策略，用于说明测试策略。此图描述了敏捷团队活动中的测试实践，图中左下角使用了一个测试象限，描述哪些测试应该自动进行，中间展示的是一个四层的测试金字塔。测试金字塔中的测试实践为：单元测试、API集成测试、端到端测试、探索式测试

如果将测试策略延展，还可以包括各项软件质量度量的内容等

组成

测试原则：所有的实践都应该围绕这个原则展开，比如团队为质量负责
测试范围：功能特性、性能、安全、可用性、可靠性等
测试方法：需求和设计评审、静态代码分析、单元测试、集成测试、E2E测试、安全建模、渗透测试、探索性测试等

11.测试左移和测试右移

介绍

测试左移和测试右移听起来比较晦涩，简单来说就是QA参与敏捷项目的全生命周期

测试左移

测试左移是指在软件进入测试阶段之前就介入测试，QA（测试人员）在设计阶段就参与，并对设计阶段的各项活动进行评估。在需求澄清的时候就应该参与，并对需求、用户故事等输出进行检查。另外，在研发人员进入设计阶段后，也可以对输出的技术方案进行评估，验证技术方案是否能满足设计目标。测试左移还可以提前准备用例和测试环境，调整测试方案以具备更好的测试性

测试右移

测试右移是指软件进入发布阶段后也需要QA参与，软件发布后QA需要持续关注线上预警和监控，及时发现问题，并尝试在测试环境中重现。这样QA就可以驱动研发人员在开发过程中考虑接入监控、告警等基础设施，开发团队需要比市场、业务方以及用户更快地发现问题，并制定解决措施

12.质量度量

介绍

在现代软件的开发过程中，度量是一种非常重要的实践。度量可以通过用量化的方法取代定性的结论，来评估软件的质量、过程和测试有效性等，让管理层能做出合理的决策。对于人员配比、能效提升、绩效考核等各个方面都有一定意义

指标

对于普通测试人员和研发人员来说，我们不需要特别去设计这些度量指标，可以根据国际、国内的指标标准提取一些合适自己的指标，作为公司内部使用的度量体系

ISO/IEC 9126标准从功能性、可靠性、易用性、效率、可维护性、可移植性这6个特性进行度量，和前面对缺陷的理解类似，ISO/IEC 9126标准将这些指标划分为通用、内部指标、外部指标。内部指标的含义是，侧重在交付前的度量，不关注缺陷被激活的情况，更加关注软件的本质问题

在国内也有相应的度量体系，GB/T延用了ISO/IEC 9126中的指标，从6个方面对软件质量进行评估。在《GB/T 32904---2016 软件质量量化评价规范》中，该文档给出了一套根据指标计算软件质量的方法

实践经验

对于测试有效性和完整性的衡量可以参考一些主流软件公司的做法，比如某公司会根据千行代码（代码规模一般不作为唯一手段）为基线统计一些测试能力的指标：

每千行用例数
每千行缺陷率
用例平均执行时间
缺陷平均回归次数
有效缺陷率（经过确认特性描述不清楚导致的缺陷）

通过度量后，会根据缺陷的优先级和严重程度进行加权计算，获得每个版本的软件质量指数

遗留项目处理

在应用指标的时候，还需要做出区分。由于有一些项目是建立在遗留系统之上的，它的开发过程、逻辑和完全从头开始的项目很不一样。因此我们在使用这些指标的时候，可以根据项目的类型做出取舍。根据软件系统遗留特性可以将项目划分为绿地工程、棕地工程、维护性工程

绿地工程：一项绿地工程可能是在全新的领域中开发，不需要考虑历史遗留问题。绿地工程往往存在需求无法清晰描述特性，有效缺陷率低，缺陷修复的成本低，缺陷回归的效率高等特点
棕地工程：此类工程中的系统通常是现有系统的一部分，或者是其子系统。需要考虑与其他系统尤其是与历史遗留系统（Legacy system）的集成问题。这类项目往往缺陷回归次数高，缺陷的修复成本很大
维护性工程：指的是不再开发新功能的系统，只完成维护性工作

02.软件测试