第六章 AI工程质量

admin管理员组

文章数量:1440489

第六章 AI工程质量

第6章 AI工程质量

人工智能(AI)作为当前最热门的一项技术，基于AI技术的产品越来越多，比如：我们支付时的人脸识别，基于OCR(Optical Character Recognition:光学字符识别)的证件文字提取产品，智能音箱等产品。AI产品的背后离不开用于算法训练的AI数据、AI算法模型以及最终将AI算法封装起来对外服务的软件工程。AI产品质量的保障工作也主要通过AI工程质量、AI数据质量以及AI模型质量来开展。本章我们将首先介绍下AI产品的研发流程，然后我们简单介绍下整个AI产品质量体系，接着我们将重点介绍下AI工程质量模型以及常见的工程质量评估手段。

6.1 AI产品研发流程

开发一款AI应用软件和非AI应用软件在研发流程上有什么不同呢？下面我们分别讲解下传统的软件研发流程和AI软件产品的研发流程。

图6-1是传统的软件研发流程，一般分为以下几个步骤：

（1）需求分析：这个阶段主要是通过深入的调研和分析，深刻理解用户的诉求，也就是“实现什么”，并梳理出系统要实现的功能、性能等具体要求。

（2）软件设计：这个阶段主要是完成“如何实现”的任务，通常是完成技术方案的概要设计和详细设计，包括如DB表设计、流程图、类图、数据流图等各类设计方案。

（3）开发阶段：主要是根据设计阶段的文档，完成代码开发和系统的实现。

（4）测试阶段：对开发阶段的产物进行多维度的测试，包括如功能测试及非功能测试等方面的测试。

（5）部署阶段：产品测试通过后，就可以部署上线了，通常有一些上线的策略，如：灰度逐步放量的方式上线，避免一次全量上线带来的风险。

（7）维护阶段：上线后，需要持续维护产品，包括如：采集和监控产品线上数据，分析线上问题，收集用户反馈等，根据这些信息指定新的产品需求，循环上述过程。

图6-1 传统的软件研发流程

那么，AI软件产品的研发流程和传统的软件研发流程有什么不同呢？图6-2是一种典型的AI软件产品的研发流程。我们可以看到，主要的不同点是：

（1）数据采集：在需求分析阶段后，我们需要做的是AI算法所需的数据样本的采集工作，这个阶段会根据业务场景制定所需的训练样本以及测试样本的采集方案。

（2）模型训练：这个阶段主要是选取AI算法模型，制定AI算法的评测标准，接着进行模型训练，期间会进行模型参数的调优等工作，最终获得一个表现比较优异的算法模型。

（3）模型工程化开发：这个阶段主要是将训练好的AI模型封装成服务向外提供服务，比如：定义restful的接口协议，通过HTTP网关方式向外提供服务。

图6-2 AI软件产品的研发流程

通过上述描述，我们可以看到AI模型是整个AI软件产品的核心，但将其工程化封装同样重要，良好的工程化才能确保AI模型能够对外输出稳定的能力，特别是对于一些比较耗时的AI算法，如果要对外提供较高的系统吞吐量，就需要把AI算法服务封装成支持并发的多任务系统。

6.2 AI产品质量体系

我们简单介绍下整个AI产品的质量体系，参见图6-3。我们主要通过工程质量、数据质量以及模型质量这三个维度对质量进行保障。

（1）工程质量: AI产品最终要工程化对外提供服务，那么传统的工程质量保障手段同样适用于AI产品，例如，V型测试模型、测试金字塔等，以及质量模型覆盖及代码覆盖率等工程质量评估手段。

（2）数据质量: 数据是机器学习的核心，它是训练模型和取得好的结果的关键。数据可以分为两类：一类是真实数据，另一类是合成数据。在数据采集和构造上，对真实数据，我们可以采用手工或自动化的采集方式；对于合成数据，我们可以通过数据增强、AI合成以及3D引擎合成等手段来快速扩充。对于数据质量的评估维度，包括如：准确性、完整性、一致性、及时性、公平性等多个维度。

（3）模型质量: 我们有多种测试手段，包括端到端的黑盒测试、分层测试、蜕变测试、基于灰盒的精准测试，以及基于覆盖率的Fuzz白盒测试等手段。在模型质量度量上，我们有端到端的算法指标、基于单个神经元的覆盖率指标，以及基于网络层的覆盖率指标。

在后续的章节中，我们将依次介绍这三个维度。

图6-3 AI产品质量体系

6.3 工程质量模型

在6.2节，我们提到AI算法的落地依赖于将其工程化封装并提供外部服务。针对工程化部分的代码我们将如何保证质量呢？这部分的测试和传统软件的测试手段基本相同。本小节，我们简单的看一下有哪些测试维度和度量指标。

测试维度上我们可以参考国标GB/T 25000.10系统与软件质量模型，如图6-4所示。该质量模型的特性说明如下。

1.功能性：在指定条件下使用时，软件或系统提供满足明确和隐含需求的功能的程度。它又包括功能完备性、功能正确性和功能的适用性多个指标。

我们以活体检测为例，功能完备性包括检查系统是否能够准确识别出真实人脸和照片、视频或者面具等非真实人脸；功能正确性包括检查系统在识别真实人脸时是否能够给出正确的结果；功能适用性包括检查系统是否能够在不同的光照、角度和表情下进行准确的活体检测。

2.性能效率：在指定的条件下，软件或系统所使用的资源量，资源可包括其他软件产品、系统的软件和硬件配置等。它又包括时间特性(如响应时间、处理时间及吞吐率)、资源利用性和容量(产品或系统参数的最大限量满足需求的程度，系统参数如：存储量、带宽、数据库规模等)多个指标。

我们同样以活体检测为例，时间特性包括测量系统在进行活体检测时的响应时间；资源 利用性包括检查系统在进行活体检测时的CPU和内存使用情况；容量包括检查系统在处理大量并发请求时是否能够保持稳定的性能。

3.兼容性：在共享相同的硬件或软件环境的条件下，产品、系统或组件能够与其他产品、系统或组件交换信息，和/或执行其所需的功能的程度。它又包括共存性（相互间负面影响的程度）和互操作性（相互间交换信息的程度）两个指标。

4.易用性：产品或系统可为用户使用的程度，它包括可辨识性、易学性、易操作性、用户差错防御性、用户界面舒适性、易访问性多个指标。

在活体检测应用中，易用性包括用户界面是否直观，用户是否能够轻松地找到并使用活体检测功能（可辨识性），新用户是否能够快速学习如何使用活体检测功能（易学性），用户在使用过程中是否容易犯错，应用是否提供了防止用户错误的机制（用户差错防御性），用户界面是否舒适，例如，提示信息是否清晰，颜色搭配是否合理（用户界面舒适性），以及应用是否支持无障碍访问，例如，对视力障碍的用户，是否提供了语音提示或者大字体模式（易访问性）。

2.可靠性：产品或系统在指定的条件下、在指定的时间内完成指定功能的程度。它又包括成熟性（正常运行时满足可靠性要求的程度）、可用性（使用时能够进行操作和访问的程度）、容错性（在故障时，产品运行符合预期的程度）、易恢复性（在产品发生中断或失效时，产品能够恢复直接受影响的数据并重建系统状态的程度）多个指标。

在活体检测应用中，可靠性包括应用在正常运行时是否能够稳定地提供活体检测功能（成熟性），在网络不稳定或者服务器负载过高的情况下，应用是否仍然能够提供服务（可用性），在出现错误或者故障时，应用是否能够正确地处理，例如，不会崩溃，能够给出错误提示（容错性），以及在应用崩溃或者其他错误导致的服务中断后，是否能够快速恢复服务（易恢复性）。

3.信息安全性：产品或系统保护信息和数据的程度，它又包括：保密性、完整性、抗抵赖性、可核查性、真实性多个指标。

在活体检测应用中，信息安全性包括用户的人脸数据是否被正确地保护，未经授权的用户或者系统是否能够访问到这些数据（保密性），在传输过程中，用户的人脸数据是否可能被篡改（完整性），在争议发生时，是否能够证明数据没有被篡改（抗抵赖性），是否能够验证数据的来源（可核查性），以及数据是否真实有效（真实性）。

4.维护性：产品或系统能够被预期的维护人员修改的有效性和效率的程度。它又包括：模块化（多个独立的组件间影响最小的程度）、可重用性、易分析性、易修改性和易测试性多个指标。

在活体检测应用中，维护性包括应用是否被设计成模块化，以便于维护人员理解和修改（模块化），代码或者组件是否能够在其他地方重用（可重用性），是否容易理解应用的行为和找出错误（易分析性），是否容易修改应用的行为（易修改性），以及是否容易测试应用的行为（易测试性）。

5.可移植性：产品或系统能够从一种硬件、软件或其他运行环境迁移到另一个环境的有效性和效率的程度。它又包括适应性（有效适用不同的或演变的硬件、软件或其他运行环境的程度）、易安装性、易替代性多个指标。

在活体检测应用中，可移植性包括应用是否能够在不同的硬件和操作系统上运行（适应性），是否容易安装应用（易安装性），以及在需要替换应用时，是否容易将数据和设置迁移到新的应用（易替代性）。

图6-4 GB/T 25000.10 软件质量模型

6.4 工程质量保障手段

在6.3节中，我们了解到通用的软件工程质量模型，那么在实际项目中我们有哪些手段来保证工程质量呢？我们首先根据软件研发流程，介绍一种常见的V型测试模型，V型模型的主要优点是它强调了开发阶段和测试阶段的对应关系，使得在开发的每个阶段都有相应的测试活动，从而能够及时发现和修复问题，提高软件的质量，保障我们的工程质量。接着我们将介绍V型测试各个阶段的测试重点和用例占比，即测试金字塔。

6.4.1 V型测试模型

V型测试模型的名称来源于其图形形状，它将软件开发和测试过程表示为一个V字形，如图6-5所示。在V型测试模型中，测试过程与开发过程是相互对应的，每个开发阶段都有一个对应的测试阶段。

从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。

图6-5 V型测试模型

1.需求分析

在需求分析阶段，软件开发团队需要与用户和利益相关者进行沟通和交流，了解他们的需求和期望。然后，开发团队需要对这些需求进行分析和整理，以确定软件系统需要实现的功能和性能要求。这些需求通常以需求规格说明书的形式进行记录和描述，以便开发团队和用户之间进行沟通和确认。

2.概要设计

概要设计是软件设计的高层次，它是在需求分析的基础上，对软件系统进行整体设计的过程。概要设计的目的是确定软件系统的整体结构和模块之间的关系，以及确定软件系统的基本框架和算法。概要设计通常包括以下内容：（1）系统结构设计：确定软件系统的整体结构和模块之间的关系。

（2）数据结构设计：确定软件系统中所需的数据结构和数据处理算法。

（3）接口设计：确定软件系统与外部系统和用户之间的接口。

（4）算法设计：确定软件系统中所需的算法和数据处理方法。

3.详细设计

详细设计是软件设计的低层次，它是在概要设计的基础上，对软件系统进行详细设计的过程。详细设计的目的是确定软件系统的具体实现方式和细节，以及确定软件系统的各个模块的具体实现方法。详细设计通常包括以下内容：

1.模块设计：确定软件系统中各个模块的具体实现方式和细节。

2.数据结构设计：确定软件系统中所需的数据结构和数据处理算法的具体实现方法。

3.界面设计：确定软件系统的用户界面和交互方式。

4.算法设计：确定软件系统中所需的算法和数据处理方法的具体实现方法。

4.软件编码

按照详细设计文档，编程人员编写出实际的代码。

5.单元测试

单元测试是对软件系统中最小的可测试单元进行测试的过程。单元测试通常由开发人员进行，目的是测试代码的正确性和可靠性。单元测试通常使用自动化测试工具进行，以确保测试的准确性和可重复性。

6.集成测试

集成测试是对软件系统中不同模块之间的集成进行测试的过程。集成测试的目的是测试模块之间的接口和交互是否正确，以及测试整个系统的功能和性能是否符合要求。集成测试通常由测试人员进行，可以使用自动化测试工具或手动测试进行。

7.系统测试

系统测试是对整个软件系统进行测试的过程。系统测试的目的是测试软件系统的功能、性能、可靠性、安全性等方面是否符合要求。系统测试通常由测试人员进行，可以使用自动化测试工具或手动测试进行。

8.验收测试

验收测试是在软件系统开发完成后，由用户或客户进行的测试过程。验收测试的目的是测试软件系统是否符合用户的需求和期望，以及是否满足合同和规范的要求。验收测试通常由用户或客户进行，可以使用自动化测试工具或手动测试进行。

6.4.2 测试金字塔

Mike Cohn的测试金字塔模型是一种软件测试策略，它将软件测试分为三个层次，分别是单元测试、服务测试和UI测试。与传统的测试金字塔模型不同，Mike Cohn的测试金字塔模型将服务测试和UI测试分别作为两个独立的层次，以更好地适应现代软件开发的需求。

图6-6 Mike Cohn的测试金字塔

Mike Cohn的测试金字塔模型的三个层次及其占比如下：

1.单元测试(Unit Tests)：单元测试是测试金字塔模型的底层，它占据了测试金字塔模型的最大部分。单元测试的目的是测试软件系统中最小的可测试单元，例如函数、方法和类等。单元测试通常由开发人员进行，占据了测试金字塔模型的70%。

2.服务测试(Service Tests)：服务测试是测试金字塔模型的中间层，它占据了测试金字塔模型的中等部分。服务测试的目的是测试软件系统中不同服务之间的集成和交互，以确保整个系统的功能和性能是否符合要求。服务测试通常由测试人员进行，占据了测试金字塔模型的20%。

3.UI测试(UI Tests)：UI测试是测试金字塔模型的顶层，它占据了测试金字塔模型的最小部分。UI测试的目的是测试软件系统的用户界面和交互方式，以确保软件系统能够满足用户的需求和期望。UI测试通常由测试人员或用户进行，占据了测试金字塔模型的10%。

Mike Cohn的测试金字塔模型强调了单元测试的重要性，并将服务测试和UI测试分别作为两个独立的层次进行测试，层次越高，你写的测试应该越少。这种测试金字塔模型可以更好地适应现代软件开发的需求，同时也可以提高测试效率和测试质量，降低测试成本和测试时间。

测试金字塔模型和V型测试模型都是软件测试的策略，但它们关注的方面和侧重点有所不同。测试金字塔模型主要关注测试的层次和比例，而V型测试模型则强调了开发阶段和测试阶段的对应关系，这种模型强调在开发的每个阶段都进行相应的测试，以便及时发现和修复问题。

这两种模型可以结合使用。例如，在V型模型的每个测试阶段，都可以参考测试金字塔模型来决定应该进行哪些类型的测试以及各类型测试的比例。这样，我们既可以保证在开发的每个阶段都进行了适当的测试，又可以保证各类型测试的比例合理，从而提高软件的质量和可靠性。

6.5 工程质量评估

有了6.4节介绍的多种工程质量保障手段后，我们将如何评估这些工程保障手段是否满足预定的标准呢？我们需要一定的度量指标来衡量我们测试的质量，同时工程质量评估，还有以下主要原因。

1.提高产品质量：通过质量评估，我们可以发现并修复软件中的问题，从而提高产品的质量。

2.降低风险：质量评估可以帮助我们及时发现潜在的问题，从而降低项目失败的风险。

3.提高用户满意度：高质量的软件可以提高用户的满意度和忠诚度。

4.提高开发效率：通过质量评估，我们可以发现并改进开发过程中的问题，从而提高开发效率。

本节我们将从以下三个方面来评估测试的充分性，即：软件质量模型覆盖度、代码覆盖率以及缺陷过程分析(包括如：缺陷密度、缺陷趋势等)。

6.5.1 质量模型覆盖度

6.3节的软件质量模型从黑盒测试的角度给出了非常全面的工程质量的评估范围，包括：功能性，性能效率，兼容性，易用性，可靠性，信息安全性，维护性，可移植性共8个维度。

在实际的业务场景中，我们需要根据业务的情况，根据软件质量模型确定需要覆盖的维度和相应的指标。对于功能，我们的目标是100%覆盖，业务还可能会包括性能、安全、合规等多个维度。下面我们举几个不同的的业务场景，每个例子都涵盖了至少四个不同的质量维度：

1.在线购物平台（例如：淘宝、亚马逊）：

a.功能性：平台需要提供商品搜索、购物车、在线支付等功能。

b.性能效率：在用户数量众多的情况下，平台需要能够快速响应用户的请求，例如商品搜索和页面加载速度。

c.兼容性：平台需要能够在各种设备（如手机、电脑）和浏览器上正常运行。

d.信息安全性：平台需要保护用户的个人信息和支付信息，防止数据泄露。

2.云存储服务（例如：Dropbox、Google Drive）：

a.功能性：服务需要提供文件上传、下载、分享等功能。

b.性能效率：服务需要能够快速处理大量的文件上传和下载请求。

c.可靠性：服务需要保证用户数据的安全，防止数据丢失。

d.维护性：服务需要能够方便地进行升级和维护，以提供新的功能和修复可能的问题。

3.移动支付应用（例如：微信支付、支付宝）：

a.功能性：应用需要提供账单查询、转账、支付等功能。

b.兼容性：应用需要能够在各种手机操作系统（如iOS、Android）上正常运行。

c.信息安全性：应用需要保护用户的支付信息，防止数据泄露。

d.性能效率：在用户数量众多的情况下，平台需要能够快速响应用户的请求。

除了功能外，这些对常规用户看不到的特性也是要覆盖的，软件质量模型给我们提供了很好的指引。

6.5.2 代码覆盖率

软件质量模型可以认为是从黑盒的角度来评估我们测试的充分度，相对来说是一种主观的评测，存在度量不客观的问题。代码覆盖率从代码层面衡量测试覆盖率，是一种客观的衡量手段，可以客观的评估我们的测试用例覆盖到了业务代码的情况。代码覆盖率一般包括代码行数、方法或函数、分支和条件覆盖率。

代码覆盖率也可以分为全量代码覆盖率和增量代码覆盖率。全量代码覆盖率是指程序运行时，被执行到的代码除以总的代码算出来的，如果以行代码覆盖率为例的话，全量代码覆盖率=执行的代码行数/总代码行数。增量代码覆盖率则是针对增量代码来计算的，如两次代码提交之间的增量代码，增量代码覆盖率=执行的增量代码行数/增量代码行数。增量代码覆盖率可以更精准的评估测试范围覆盖了多少本次修改代码的范围， 让测试更聚焦。

至于代码覆盖率的具体指标是多少比较合适，这个可以根据实际的项目情况而定。举个作者所负责过的某个支付产品的例子，对于新项目或是新模块采用全量代码覆盖率，要求在80%以上，对未覆盖的代码要给出分析和说明。对于迭代项目，一般采用增量代码覆盖率，要求在90%以上，同样也要对对未覆盖的代码要给出分析和说明。

虽然代码覆盖率能够说明测试覆盖了多少代码，即使是代码覆盖率是100%，它并不代表代码没有缺陷。我们举个简单的例子，代码段6-1是一个简单的计算器的代码和测试代码，图6-7是该代码的覆盖率情况，从图6-6我们可以看到类覆盖、方法覆盖和行覆盖都是100%。但显然divide()函数没有处理当分母为0的情况。

代码段6-1：代码覆盖率源码举例

package com.example.mytest;

class Calculator {

public Double divide(double a, double b){

return a / b;

}

}

public class Main {

public static void main(String[] args) {

Calculator cal = new Calculator();

double res = cal.divide(10,1); //测试除法接口

System.out.println(res);

}

}

图6-7 代码覆盖率结果

那么收集代码覆盖率的意义有哪些呢？

（1）找到测试设计的盲点：通过分析未覆盖部分的代码，反推前期测试设计是否全面，找到测试设计的盲点，然后再分析为什么有这些盲点，是因为需求不清晰，还是测试设计考虑不全等原因。

（2）找到程序中的死代码：如果有些代码是无法覆盖的，比如没有被调用的函数、无法触达的代码分支，进一步分析这些代码是否要删除，还是设计上的问题需要修正。

虽然代码覆盖率高不能说明代码质量一定很高，但如果代码覆盖率很低，说明很多地方没有被测试到，存在缺陷的可能性会很大。代码覆盖率是测试自我审视的重要工具之一，仍然有很大的价值。

6.5.3 缺陷过程分析

6.5.1及6.5.2两个小节提到的软件质量模型覆盖度和代码覆盖率都是终态的结果指标，缺陷过程分析是一种关注于过程和结果的指标，可以很好的帮助我们了解当前的项目缺陷情况，并预测未来的缺陷趋势。

缺陷过程分析主要有两个维度：缺陷密度分析和缺陷趋势分析。

1.缺陷密度分布：主要是分析当前缺陷的分布情况，比如：主要分布在哪些模块上、主要分布在哪些函数，如果某个模块/函数上的缺陷比较多，说明代码质量可能不高，需要我们重点关注，可能要增加更多的测试场景进行覆盖。

2.缺陷趋势分析：主要是指随着测试时间的推移，发现缺陷的数量变化情况，是否逐渐收敛。图6-8是一个项目的缺陷趋势图，我们可以看到项目的初期缺陷较少，随着项目的进展，更多的缺陷被发现出来，项目的后期，倒数第三周缺陷数量从前一周的3个激增到18个，接着又下降到3个。实际情况是项目的后期做了一些代码架构的重构，导致激增了很多问题，最后逐步收敛。基于这个收敛的缺陷趋势图，我们对要发布的产品也有了一定的质量信心。

图6-8 缺陷趋势举例

6.6 总结

本章我们主要对比了传统的软件研发流程和AI软件产品的研发流程的不同，并指出AI产品的工程化的质量同样重要，AI产品的工程质量的保障手段和非AI产品基本上是一样的。接着我们简单介绍了AI产品的质量体系，其主要包括三个维度：工程质量、数据质量以及模型质量。接着本章重点介绍AI产品的工程质量，包括：基于国标GB/T25000.10的软件质量模型，以及工程质量的常见的保障手段，最后介绍了工程质量的常见的评估指标，以保障我们发布的AI产品有着高的工程质量。

下一章节，我们将进入AI产品特有的质量保障领域：AI数据质量。

6.7 参考文献

[1] 中华人民共和国国家标准：GB/T 25000.10系统与软件质量模型

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-02-09，如有侵权请联系 cloudcommunity@tencent 删除系统测试产品模型软件

本文标签： 第六章 AI工程质量