› ›

系统测试

编辑

系统测试

编辑

Elastic 包包含数据流。系统测试会测试包的数据流的端到端数据流——从包的集成服务摄取数据一直到将其索引到 Elasticsearch 数据流中。

概念过程

编辑

从概念上讲，运行系统测试包括以下步骤：

部署 Elastic Stack，包括 Elasticsearch、Kibana 和 Elastic Agent。此步骤需要时间，因此您通常应将其作为在多个数据流上运行系统测试的先决条件执行一次。
使用 Fleet（在 Kibana 实例中运行）注册 Elastic Agent。此步骤也可以作为先决条件执行一次。
根据正在测试其数据流的 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

« 静态测试发布集成 »