› ›

系统测试

编辑

系统测试编辑

Elastic 包由数据流组成。系统测试是对包数据流的端到端数据流进行测试 - 从包集成服务中提取数据一直到将其索引到 Elasticsearch 数据流中。

概念流程编辑

从概念上讲，运行系统测试涉及以下步骤

部署 Elastic Stack，包括 Elasticsearch、Kibana 和 Elastic Agent。此步骤需要时间，因此您通常应将其作为先决条件，仅执行一次，以对多个数据流运行系统测试。
将 Elastic Agent 注册到 Fleet（在 Kibana 实例中运行）。此步骤也可以仅执行一次，作为先决条件。
根据要测试其数据流的 Elastic 包，部署包集成服务的一个实例。
创建一个测试策略，为单个包配置单个数据流。
将测试策略分配给注册的 Agent。
等待合理的时间，让 Agent 从集成服务收集数据并将其索引到正确的 Elasticsearch 数据流中。
根据 @timestamp 查询前 500 个文档以进行验证。
验证是否为索引文档中包含的字段定义了映射。
验证 _source 中包含的 JSON 数据类型是否与为字段声明的映射兼容。
删除测试工件并拆除包集成服务的实例。
一旦所有所需的数据流都通过了系统测试，请拆除 Elastic Stack。

限制编辑

目前，系统测试存在一些限制。最突出的限制是：* 无法断言索引数据与文件中的数据匹配（例如，黄金文件测试）。

定义系统测试编辑

包具有特定的文件夹结构（仅显示相关部分）。

<package root>/
  data_stream/
    <data stream>/
      manifest.yml
  manifest.yml

要定义系统测试，我们必须在至少一个级别上定义配置：包或数据流的级别。

首先，我们必须定义用于部署包集成服务的配置。我们可以在包级别定义它

<package root>/
  _dev/
    deploy/
      <service deployer>/
        <service deployer files>

或数据流级别

<package root>/
  data_stream/
    <data stream>/
      _dev/
        deploy/
          <service deployer>/
            <service deployer files>

<service deployer> - 支持的服务部署程序的名称

docker - Docker Compose
k8s - Kubernetes
tf - Terraform

Docker Compose 服务部署程序编辑

当使用 Docker Compose 服务部署程序时，<service deployer files> 必须包含一个 docker-compose.yml 文件。该 docker-compose.yml 文件定义了包的集成服务。例如，如果您的包具有日志数据流，则来自包集成服务的日志文件必须写入卷。例如，该 apache 包在其集成服务的 docker-compose.yml 文件中具有以下定义。

version: '2.3'
services:
  apache:
    # Other properties such as build, ports, etc.
    volumes:
      - ${SERVICE_LOGS_DIR}:/usr/local/apache2/logs

这里，SERVICE_LOGS_DIR 是一个特殊的关键字。我们稍后将需要它。

Terraform 服务部署程序编辑

当使用 Terraform 服务部署程序时，<service deployer files> 必须包含至少一个 *.tf 文件。该 *.tf 文件使用 Terraform 语法定义基础设施。基于 Terraform 的服务对于启动使用选定云提供商的资源并使用它们进行测试（例如，观察和收集指标）非常有用。

示例 main.tf 定义

variable "TEST_RUN_ID" {
  default = "detached"
}

provider "aws" {}

resource "aws_instance" "i" {
  ami           = data.aws_ami.latest-amzn.id
  monitoring = true
  instance_type = "t1.micro"
  tags = {
    Name = "elastic-package-test-${var.TEST_RUN_ID}"
  }
}

data "aws_ami" "latest-amzn" {
  most_recent = true
  owners = [ "amazon" ] # AWS
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*"]
  }
}

注意使用了 TEST_RUN_ID 变量。它包含一个唯一的 ID，可以帮助区分在潜在的并发测试运行中创建的资源。

Kubernetes 服务部署程序编辑

Kubernetes 服务部署程序需要 _dev/deploy/k8s 目录存在。它可以包含其他 *.yaml 文件，以在 Kubernetes 集群中部署自定义应用程序（例如，Nginx 部署）。如果不需要资源定义（*.yaml 文件），则 _dev/deploy/k8s 目录必须包含一个 .empty 文件（以在版本控制下保留 k8s 目录）。

Kubernetes 服务部署程序需要 [kind](https://kind.kubernetes.ac.cn/) 安装并集群运行。

wget -qO-  https://raw.githubusercontent.com/elastic/elastic-package/main/scripts/kind-config.yaml | kind create cluster --config -

在执行系统测试之前，服务部署程序将应用 Elastic Agent 在集群中的部署一次，并将 kind 集群与 Elastic Stack 网络链接起来 - 在 kind 集群中运行的应用程序可以访问 Elasticsearch 和 Kibana 实例。Elastic Agent 的部署在测试后不会删除，以缩短总测试执行时间，但它可以重复使用。

查看如何对 Kubernetes 集成（pod 数据流）执行系统测试

elastic-package stack up -d -v # start the Elastic stack
wget -qO-  https://raw.githubusercontent.com/elastic/elastic-package/main/scripts/kind-config.yaml | kind create cluster --config -
elastic-package test system --data-streams pod -v # start system tests for the "pod" data stream

测试用例定义编辑

接下来，我们必须为每个要进行系统测试的数据流定义至少一个配置。您可以为同一个数据流定义多个测试用例。

提示：如果您计划只定义一个测试用例，您可以考虑将文件名命名为 test-default-config.yml。

<package root>/
  data_stream/
    <data stream>/
      _dev/
        test/
          system/
            test-<test_name>-config.yml

该 test-<test_name>-config.yml 文件允许您为包和数据流级别变量定义值。例如，该 apache/access 数据流的 test-access-log-config.yml 如下所示。

vars: ~
input: logfile
data_stream:
  vars:
    paths:
      - "{{SERVICE_LOGS_DIR}}/access.log*"

顶级 vars 字段对应于在 apache 包的 manifest.yml 文件中定义的包级别变量。在上面的示例中，我们没有覆盖任何这些包级别变量，因此它们在 apache 包的 manifest.yml 文件中使用的默认值。

该 data_stream.vars 字段对应于当前数据流（在上面的示例中为 apache/access）的数据流级别变量。在上面的示例中，我们覆盖了 paths 变量。所有其他变量都将使用其默认值填充，如 apache/access 数据流的 manifest.yml 文件中所指定。

注意使用了 {{SERVICE_LOGS_DIR}} 占位符。这对应于我们之前在 docker-compose.yml 文件中看到的 ${SERVICE_LOGS_DIR} 变量。在上面的示例中，位于 Apache 集成服务容器内的 /usr/local/apache2/logs/access.log* 文件从 Elastic Agent 的角度来看，在同一路径下可用。

当数据流的清单声明了具有不同输入的多个流时，您可以使用 input 选项来选择要测试的流。第一个其输入类型与 input 值匹配的流将被测试。默认情况下，将测试清单中声明的第一个流。

占位符编辑

该 SERVICE_LOGS_DIR 占位符不是数据流的 test-<test_name>-config.yml 文件中可用的唯一占位符。下面显示了可用占位符的完整列表。

占位符名称	数据类型	说明
`主机名`	字符串	集成服务的可寻址主机名。
`端口`	[]int	集成服务正在监听的可寻址端口数组。
`端口`	int	对 `Ports[0]` 的别名。作为一种便利措施提供。
`Logs.Folder.Agent`	字符串	集成服务日志文件夹的路径，可供 Agent 寻址。
`SERVICE_LOGS_DIR`	字符串	对 `Logs.Folder.Agent` 的别名。作为一种便利措施提供。

在 test-<test_name>-config.yml 中使用的占位符必须用 {{ 和 }} 分隔符括起来，符合 Handlebars 语法。

运行系统测试编辑

一旦定义了上一节中描述的两个级别的配置，您就可以准备运行包数据流的系统测试。

首先，您必须部署 Elastic Stack。这对应于概念流程部分中描述的步骤 1 和步骤 2。

elastic-package stack up -d

有关此命令可用选项的完整列表，请运行 elastic-package stack up -h 或 elastic-package help stack up。

接下来，您必须设置进一步执行 elastic-package 命令所需的環境變數。

$(elastic-package stack shellinit)

接下来，您必须调用系统测试运行器。这对应于概念流程部分中描述的步骤 3 到步骤 7。

如果您要对包中的 所有数据流 运行系统测试，请导航到包的根文件夹（或其下的任何子文件夹）并运行以下命令。

elastic-package test system

如果您要对包中的 特定数据流 运行系统测试，请导航到包的根文件夹（或其下的任何子文件夹）并运行以下命令。

elastic-package test system --data-streams <data stream 1>[,<data stream 2>,...]

最后，当您完成所有系统测试的运行后，请关闭 Elastic Stack。这对应于概念流程部分中的步骤 8。

elastic-package stack down

生成示例事件编辑

由于系统测试从运行集成的服务一直到将从集成的數據流生成的數據索引到 Elasticsearch，因此在运行这些测试时，可以为集成的每个數據流生成 sample_event.json 文件。

elastic-package test system --generate

« 静态测试发布集成 »