译者|陈军审稿人|孙淑娟如果说质量保证（QA）是一个系统的过程，用于确定一个产品或服务是否是研发过程的一个组成部分，它对保证产品质量起着一定的作用。在本文中，我将向您介绍Milvus向量数据库开发中使用的QA框架，涵盖Milvus中的主要测试模块，以及可用于提高QA测试效率的方法和工具。一、MilvusQA系统概述鉴于系统架构对于QA测试的重要性，QA工程师对系统越熟悉，就越有可能制定出合理有效的测试计划。Milvus架构Milvus2.0采用了云原生、分布式的分层架构。其中，SDK是Milvus中数据流转的主要入口。通过对常用的SDK进行功能测试，我们将能够发现Milvus系统中的问题。除了功能测试，我们还要对矢量数据库进行单元测试、部署测试、可靠性测试、稳定性测试和性能测试。云原生和分布式架构给QA测试带来了便利和挑战。不同于在本地部署和运行的系统，在Kubernetes集群上部署和运行的Milvus实例可以保证在与软件开发相同的环境中进行软件测试。但其缺点在于分布式架构的复杂性，会带来更多的不确定性，进而导致系统QA测试繁琐。例如，Milvus2.0使用了不同组件的微服务，这会导致服务和节点数量的增加，系统出错的概率增加。因此，我们需要一个更全面的QA计划来提高测试效率。2.QA测试和问题管理Milvus的QA需要对软件开发过程中出现的问题进行测试和管理。1.QA测试如下图所示，我们要根据Milvus的特点和用户需求，按照优先顺序进行不同类型的QA测试。QA测试和优先级排序在Milvus中，QA测试主要针对以下几个方面进行：功能：验证功能和特性是否能够按照最初的设计工作。部署：检查用户是否可以通过不同方式（如：DockerCompose、Helm、APT、YUM等）部署、重装、升级Milvus的单机版和集群。性能：测试数据在Milvus中的插入、索引、向量搜索和查询性能。稳定性：检查Milvus是否可以在正常工作负载水平下稳定运行5-10天。可靠性：如果出现系统错误，测试Milvus是否还能部分运行。配置：验证Milvus在特定配置下是否按预期工作。兼容性：测试Milvus是否兼容不同类型的硬件或软件。2.问题管理软件在开发过程中会遇到很多问题。这些问题可能源于QA工程师自己，也可能源于开源社区的Milvus用户。但是，QA团队应该负责发现这些问题。Milvus中Issue管理的工作流程创建Issue后，首先需要对其进行分类。在分流过程中，检查的新问题应确保有足够的问题细节，以便开发人员确认、接受并尝试修复。修复完成后，问题负责人需要对其修复进行验证，以确定问题是否可以最终关闭。3.什么时候需要QA？一个常见的误解是QA和开发是相互独立的。事实上，为了保证系统的质量，开发人员和QA工程师都需要通力合作，将QA贯穿于整个生命周期。将QA引入整个软件开发生命周期如上图所示，一个完整的软件开发生命周期包括三个阶段：初始阶段，开发人员发布设计文档，QA工程师制定测试计划，定义发布标准，分配QA任务。开发人员和QA工程师需要熟悉设计文档和测试计划，以便在两个团队之间共享对发布目标、功能、性能、稳定性、错误关闭等的相互理解。在开发过程中，开发和QA测试不断交互以验证开发的特性和功能，并修复开源社区报告的错误和问题。在最后阶段，他们可以发布满足发行说明和标签的新版本Milvus的Docker镜像。同时，QA团队也将发布该版本的测试报告。4.Milvus中的测试模块下面详细介绍一下Milvus中的六个测试模块：1.单元测试单元测试单元测试可以帮助尽早发现软件错误，为代码重组提供验证标准。根据Milvus的拉取请求（pullrequest，PR）验收标准，代码单元测试的覆盖率应该达到80%。2、功能测试在Milvus中，功能测试的主要目的是验证接口是否能按照设计运行。通过围绕PyMilvus和SDK进行开发，功能测试会涉及到以下两个方面：测试SDK在传递正确的参数时是否能够返回预期的结果。测试SDK在传入错误参数时是否能够处理错误并返回合理的错误信息。下图描绘了目前基于主流pytest的功能测试框架。该框架为PyMilvus添加了一个包装器（wrapper），并通过自动化测试接口对其进行测试。Milvus中的功能测试框架考虑到测试方法共享时，需要复用一些功能，所以我们可以直接使用上面的测试框架，而不用直接使用PyMilvus接口。此外，该框架还包括一个“检查”模块，方便验证预期值和实际值。其tests/python_client/testcases目录包含多达2700个功能测试用例，完全覆盖了几乎所有的PyMilvus接口。而功能测试可以严格监控每一个PR的质量。3.部署测试由于Milvus有单机和集群两种模式，我们可以使用DockerCompose或Helm两种重要的方式对其进行部署。同时，用户在部署Milvus后，可以进行两类：重启或升级测试。其中，重启测试是指测试数据持久化的过程，即重启后的数据是否仍然可用。升级测试是指测试数据兼容性的过程，以防止不兼容的数据格式被插入到Milvus中。如下图所示，两种部署测试可以共享同一个工作流程：部署测试工作流程在重启测试中，两种部署都会使用同一个Docker镜像。但是在升级测试中，第一次部署会使用之前版本的Docker镜像，而第二次部署会使用更新版本的Docker镜像。测试结果和数据将保存在卷文件或持久卷声明中。第一个测试在运行时创建多个集合，并对每个集合进行不同的操作。在运行第二个测试时，它侧重于验证已创建的集合是否仍可用于CRUD操作以及是否可以进一步创建新集合。4.可靠性测试云原生分布式系统的可靠性测试通常采用混沌工程的方法，目的是将错误和系统故障消灭在萌芽状态。换句话说，在混沌工程测试中，我们有目的地制造系统故障以识别压力测试中的问题并在它们真正开始造成危害之前修复它们。在Milvus的混沌测试中，我们可以选择ChaosMesh作为创建混沌的工具来创建以下类型的故障：Podkill：模拟节点宕机场景。Pod故障：测试当一个worker节点的一个pod故障时，整个系统能否继续工作。内存压力：模拟工作节点消耗大量内存和CPU资源。网络分区：由于Milvus可以将存储和计算分开，系统将严重依赖组件之间的通信。为了测试不同Milvus组件之间的依赖关系，我们需要模拟不同Pod之间的通信被分区的场景。Milvus中的可靠性测试框架上图展示了Milvus中的可靠性测试框架，可以进行自动化混沌测试。流程如下：首先通过部署配置读取并初始化Milvus集群。集群准备就绪后，运行test_e2e.py测试Milvus各项功能是否可用。运行hello_milvus.py测试数据持久化。即创建一个名为“hello_milvus”的集合，用于数据插入、刷新、索引构建、向量搜索和查询。在测试期间不会释放或丢弃此集合。创建一个监视器对象，它将启动六个线程（如下面的代码片段所示）来执行创建、插入、刷新、索引、搜索和查询操作。checkers={Op.create:CreateChecker(),Op.insert:InsertFlushChecker(),Op.flush:InsertFlushChecker(flush=True),Op.index:IndexChecker(),Op.search:SearchChecker(),Op.query:QueryChecker()}做出第一个断言-所有操作均按预期成功运行。使用ChaosMesh解析定义故障的yaml文件，将系统故障引入Milvus。例如，每五秒“杀死”一个查询节点。在引入系统故障时进行二次断言——判断系统故障期间Milvus运行返回的结果是否符合预期。使用ChaosMesh消除故障。当Milvus服务恢复（即所有pod都准备就绪）时，会进行第三次断言——所有操作都符合预期。运行test_e2e.py测试Milvus功能是否可用。混沌消除后，部分操作可能会继续阻塞，从而阻止第三次断言。所以这一步是为了方便第三次断言，作为判断Milvus服务是否恢复的判断标准。运行hello_milvus.py加载创建的集合，并对集合进行CRUP操作。然后检查系统故障前存在的数据在恢复后是否仍然可用。收集日志。5.稳定性和性能测试下表描述了稳定性和性能测试的目的、测试场景和指标。稳定性测试和性能测试共享同一组工作流：稳定性测试和性能测试的工作流解析和更新配置，并定义指标。server-configmap对应Milvus单机或集群配置，client-configmap对应测试用例的各种配置。配置服务器和客户端。准备数据。请求服务器和客户端之间的交互。报告和显示指标。5.提高QA效率的工具和方法从模块测试部分可以看出，大部分的测试流程其实都差不多，主要是修改Milvus服务端和客户端的配置，传递API参数。当存在多种配置时，不同配置的组合越多样化，实验和测试能够覆盖的场景就越广。因此，代码和程序的复用对于提高测试效率是非常关键的。1.SDK测试框架SDK测试框架为了加快测试过程，我们可以在原有的测试框架上增加一个API_requestwrapper，根据API网关进行设置。这样一个API网关将负责收集所有的API请求，然后将它们传递给Milvus，以便将响应集中接收并传回给客户端。这样的设计可以更方便的获取参数和返回结果等日志信息。另外，SDK测试框架中的检查器组件也可以对Milvus的结果进行校验和检查。所有检查方法都可以在检查器组件中定义。使用SDK测试框架，我们还可以将一些关键的初始化过程封装成一个函数，减少很多繁琐的代码。还值得注意的是，每个单独的测试用例都与其唯一的集合相关联，确保数据彼此隔离。例如，在执行测试用例时，pytest-xdist可以利用pytest扩展并行执行所有单独的测试用例，从而大大提高效率。2.GitHubActionGitHubActionGitHubAction将用于提升QA效率，因为它具有以下特点：它是一个与GitHub深度集成的原生CI/CD工具。具有统一配置的机器环境，预装Docker、DockerCompose等常用软件开发工具。它支持多种操作系统和版本，包括Ubuntu、MacOs和Windows-server。它有一个市场，提供丰富的扩展和开箱即用的功能。它的矩阵可以支持并发作业并重复使用相同的测试流程以提高效率。除了以上特点，使用GitHubAction的另一个原因是部署测试和可靠性测试需要独立的隔离环境，而GitHubAction非常适合小规模数据集的日常检查。3.基准测试工具为了使QA测试更有效，我们可以使用多种工具。基准测试工具概述Argo：是一组开源的Kubernetes工具，可用于通过调度任务来运行工作流和管理集群。同时，它还可以并行启用多个任务。KubernetesDashboard：提供基于Web的Kubernetes用户界面，可用于可视化server-configmap和client-configmap。网络附加存储是一种文件级数据存储服务器，可用于保存常见的ANN基准数据集。InfluxDB和MongoDB：可用于保存基准测试结果的数据库。Grafana：一个开源的分析和监控解决方案，可用于监控服务器资源指标和客户端性能指标。Redash：是一项可以可视化数据并创建图表以进行基准测试的服务。原文链接：https://dzone.com/articles/open-source-software-oss-quality-assurance-a-milvu
