利用实时仪表板简化测试报告

测试报告在自动化测试中发挥着至关重要的作用，它为团队提供了有关测试工作进度、质量和效果的宝贵见解。它是一个重要的沟通工具，能让利益相关者跟踪测试状态、识别潜在问题并做出明智决策。然而，传统的手动报告生成流程既耗时又容易出错，阻碍了测试团队的灵活性和效率。这就需要实时报告解决方案，使测试人员能够即时访问最新的可操作信息。

在这篇博文中，我们将探讨测试报告在自动化测试中的重要性、手动生成报告带来的挑战以及采用实时报告解决方案的好处。我们将深入探讨一个实际案例，展示实时仪表板如何简化报告流程，为利益相关者提供测试执行结果的即时可见性，并促进更快的决策。通过采用实时报告，测试团队可以彻底改变其报告方法，提高自动化测试工作的效率。

了解实时仪表板的需求

传统的测试报告方法往往有其局限性，会阻碍自动化测试工作的有效性。这些限制包括延迟访问测试结果、静态和过时的报告，以及需要手动编译和分发报告。这些挑战会阻碍测试团队的进度，妨碍及时决策。

另一方面，实时仪表盘通过提供即时和动态的测试结果访问，为这些限制提供了解决方案。有了实时仪表板，测试团队就能在测试执行过程中监控其进度，即时了解测试状态、测试覆盖率和缺陷。这种实时信息水平使利益相关者能够做出更快、更明智的决策。

实时报告的主要优势之一是提高可见性。传统的报告方法通常会产生静态报告，可能无法捕捉到被测应用程序的最新变化。实时仪表盘通过显示最新信息克服了这一限制，使利益相关者能够实时掌握测试执行进度。这种可视性能够及早发现潜在问题，并促进主动决策以降低风险。

实时报告还有助于更快地做出决策。通过即时访问测试结果，利益相关者可以快速识别瓶颈，评估应用程序的整体健康状况，并相应地确定测试工作的优先级。实时仪表盘以直观、易懂的格式显示数据，使利益相关者能够一目了然地掌握状态和趋势。这加快了决策过程，使团队能够及时应对新出现的问题，并根据需要调整测试策略。

此外，实时仪表盘还能加强团队成员和利益相关者之间的协作。通过提供一个集中的、可访问的平台来共享测试结果，参与测试流程的每个人都能保持一致，协同工作。实时报告促进了有效沟通，使利益相关者能够讨论、分析共享数据并采取行动，从而改善协调、提高效率，最终取得更好的测试结果。

总之，自动化测试对实时仪表盘的需求源于传统报告方法的局限性。实时报告通过提供更好的可见性、更快的决策和更强的协作来解决这些局限性。通过采用实时报告解决方案，测试团队可以利用即时洞察的力量，确保更有效的测试并交付更高质量的软件产品。

设计测试自动化架构

InfluxDB

作为我们测试自动化框架的支柱，InfluxDB 在高效存储和查询时间戳数据方面发挥着至关重要的作用。它的高性能时间序列数据库非常适合汇总一段时间内的测试结果和指标。InfluxDB 的灵活性使我们能够捕获和存储各种实时测试数据，包括测试执行状态、响应时间、错误率等。

Selenium和自定义TestNG 监听器

我们的框架主要使用 Selenium（一种广泛使用的网络测试自动化工具）构建。此外，我们还在 Kotlin 中开发了一个自定义 TestNG 监听器，在测试脚本执行期间充当数据收集器。这个自定义监听器收集性能和测试指标，在整个测试过程中产生有价值的见解。

Grafana

Grafana 是满足我们实时仪表盘需求的前端可视化和监控工具。通过它，我们可以创建交互式仪表盘，显示来自 InfluxDB 的实时测试数据。Grafana 强大的查询功能使我们能够创建具有洞察力的图表、图形和可视化内容，便于监控测试执行进度和识别模式或问题。

组件如何协同工作

当我们使用 Selenium 和自定义 TestNG 监听器执行测试脚本时，监听器会在测试执行期间收集各种性能和测试指标。然后，这些指标会被实时发送到 InfluxDB 进行有效存储。

InfluxDB 拥有功能强大的时间序列数据库，可以高效地存储输入的数据，实现快速检索和分析。Grafana 与 InfluxDB 交互，动态获取最新的测试结果和指标，并将其显示在实时仪表板上。

自动化框架的优势

实时洞察： 利益相关者可即时访问测试结果，从而实时监控测试进度和结果。
细粒度数据分析： 借助 InfluxDB 丰富的查询功能，测试人员可以通过深入特定时间范围进行深入分析，从而获得有关性能趋势和异常情况的精细洞察。
交互式仪表盘： Grafana 的交互式仪表盘提供定制选项、过滤器和交互式可视化，使用户能够进行更详细的测试数据分析。
可扩展性： InfluxDB 与我们定制的 TestNG 监听器相结合，可高效处理大量时间戳数据，使该框架适用于不同规模的项目。

实施实时数据采集

那么，我们该如何做到这一点呢？我们将编写一段代码，定义一个自定义测试监听器类，该类实现了 TestNG（一种流行的 Java 测试框架）中的 ITestListener 接口。

测试监听程序

测试监听器是 TestNG 提供的一种机制，用于监听各种测试事件并根据这些事件执行操作。在本具体实现中，CustomTestListener 类将测试结果记录到 TestExecutionLogger 中。

我们将首先声明我们的 logger：

class CustomTestListener : ITestListener {
    private var logger: TestExecutionLogger? = null
}

接下来，我们需要覆盖以下方法：onStart、onTestSuccess、onTestSuccess 和 onFinish。onStart 方法在测试套件开始执行时调用。它通过创建 TestExecutionLogger 类的实例来初始化日志记录器

override fun onStart(context: ITestContext) {
    logger = TestExecutionLogger()
}

当测试方法成功通过时调用onTestSuccess方法。它调用logTestResult方法来使用logger对象记录测试结果:

override fun onTestSuccess(result: ITestResult) {
    logTestResult(result)
}

当测试方法失败时调用onTestFailure。它还调用logTestResult方法来使用logger对象记录测试结果:

override fun onTestFailure(result: ITestResult) {
    logTestResult(result)
}

当整个测试套件完成其执行时，调用onFinish方法。如果它不为空，则关闭logger，确保日志记录器的资源被释放:

override fun onFinish(context: ITestContext) {
    if (logger != null) {
        logger!!.close()
    }
}

logTestResult是一个私有助手方法，它接受一个ITestResult对象，提取有关测试的相关信息(如测试名称、状态和执行时间)，然后使用logger对象记录这些信息:

private fun logTestResult(result: ITestResult) {
    val testName = result.name
    val status = if (result.isSuccess) "passed" else "failed"
    val executionTime = result.endMillis - result.startMillis
    logger!!.logTestResult(testName, status, executionTime)
}

记录结果

接下来我们需要的是一个实用程序类，负责将测试结果记录到InfluxD数据库:

class TestExecutionLogger {
    private val influxDBClient = InfluxDBClientFactory.create(
        "http://localhost:8086", //server url
        "your_access_token".toCharArray(), //access token
        "the_green_report", //InfluxDB org
        "tgr_automation" //InfluxDB bucket
    )
}

influxDBClient 使用 InfluxDBClientFactory.create 方法创建，并连接到运行在 http://localhost:8086 的 InfluxDB 服务器。它使用以字符数组形式提供的授权令牌（访问令牌），该令牌提供了向 InfluxDB 数据库写入数据的权限。

获取访问令牌非常简单。安装并创建 InfluxDB 账户后，只需导航到 API 标记菜单并生成一个即可。

组织也是如此。组织是一组用户的工作区。所有仪表盘、任务、桶、成员等都属于一个组织。点击左侧菜单中的 “创建组织 “按钮即可创建一个组织。

一旦有了组织，就可以从左侧菜单中选择 “桶（buckets） “选项，创建一个新的桶。存储桶是存储时间序列数据的命名位置。所有桶都有保留期，即每个数据点的持续时间。InfluxDB 会删除时间戳早于数据桶保留期的所有点。

回到我们的辅助类，我们将编写一个将测试结果记录到 InfluxDB 的方法。它需要三个参数：

testName：记录的测试名称
status：测试状态，是通过还是失败
executionTime：执行测试所用的时间。

该方法使用 influxDBClient.writeApiBlocking 属性创建包含测试信息的数据点（测量）并将其写入 InfluxDB 数据库:

fun logTestResult(testName: String?, status: String?, executionTime: Long) {
    val writeApi: WriteApiBlocking = influxDBClient.writeApiBlocking
        val point = Point.measurement("test_metrics")
            .addTag("test_name", testName)
            .addTag("status", status)
            .addField("execution_time", executionTime)
            .time(System.currentTimeMillis(), WritePrecision.MS)
    writeApi.writePoint(point)
}

我们还需要一个方法来关闭与InfluxDB服务器的连接:

fun close() {
    influxDBClient.close()
}

通过这种设置，测试名称、状态和执行时间等测试指标将存储在 InfluxDB 中的 tgr_automation 桶中，我们可以使用 Grafana 的查询和可视化功能来分析和监控一段时间内的测试结果。

实际测试用例

测试用例验证的重要性与这一部分无关。最重要的是利用我们为测试类开发的监听器。

在 TestNG 中，我们通过使用 @Listeners 注解来实现这一点。它告诉 TestNG 将自定义类用作特定测试类的监听器。TestNG 监听器用于自定义测试执行行为，并收集有关测试执行事件的信息。它们可用于在测试方法执行之前或之后执行操作、处理测试失败、生成自定义报告等。

为了简明扼要，下面是一个使用自定义测试监听器（CustomTestListener）的测试类示例：

@Listeners(CustomTestListener::class)
class BaseTest {
    private var driver: WebDriver? = null
    private val baseUrl = "https://www.thegreenreport.blog/"
    private var logger: TestExecutionLogger? = null

    @BeforeClass
    fun setUp() {
        System.setProperty("webdriver.chrome.driver", "src/main/resources/chromedriver.exe")
        driver = ChromeDriver()
        (driver as ChromeDriver).manage().window().maximize()
        logger = TestExecutionLogger()
    }

    @Test
    fun testPageTitle() {
        driver!![baseUrl]
        val actualTitle = driver!!.title
        assertEquals(actualTitle, "The Green Report | Home", "Page title is not as expected.")
    }

    @AfterClass
    fun tearDown() {
        if (driver != null) {
            driver!!.quit()
        }
    }
}

集成InfluxDB和Grafana

在这一点上，如果我们执行我们的测试几次，我们将有我们感兴趣的数据发送到InfluxDB，并在我们的桶中访问:

为了利用这些数据，我们将创建一个与 Grafana 的连接。安装并确保服务器正常运行后，下一步就是为 InfluxDB 创建一个新的数据源。这是一个通过图形用户界面完成的简单过程。它需要为数据源提供一个名称，以及与 InfluxDB 进行身份验证所需的信息。

在我们的示例中，数据源信息如下：

有了数据源，我们就可以开始创建符合特定测试需求的仪表盘。Grafana 为创建仪表盘提供了一个直观、用户友好的图形用户界面。仪表盘是测试执行指标的可视化表示，可让您深入了解各种性能参数。

现在，在 Grafana 中创建仪表盘的常规流程可分为以下几个步骤：

添加面板：我们首先要为仪表盘添加面板。面板是显示特定数据的单独可视化。
配置面板：添加面板后，我们可以通过选择数据源、选择可视化类型（如图表、表格、仪表盘）以及自定义数据查询和选项来配置面板。
排列面板：我们可以在仪表盘画布上拖放面板，将它们排列成所需的布局。
自定义仪表盘：我们可以通过添加行、调整时间范围和应用样式选项来定制整个仪表盘。
保存仪表盘：设计完仪表盘后，我们要保存它，以保留布局、面板配置和设置。

我想花点时间谈谈配置步骤。在 FLUX 和 InfluxQL 的帮助下，Grafana 提供了从 InfluxDB 查询数据的强大选项。Flux 是 InfluxData 的功能性数据脚本语言，设计用于查询、分析和操作数据。该语言包含大量功能，对所有类型的查询都有帮助。例如，随后的查询将检索过去 24 小时内通过测试速度最慢的前 3 个测试:

from(bucket:"tgr_automation")
|> range(start: -1d)
|> filter(fn: (r) => r.status == "passed")
    |> group(columns: ["execution_time"])
    |> sort(desc: true)
    |> unique(column: "test_name")
    |> limit(n: 3)
    |> keep(columns: ["test_name", "_value"])

从上面的例子中可以看出，我们可以查询数据中的所有内容，并以不同的方式将其可视化。一个小的仪表板示例可能是这样的:

我将在 GitHub 页面的截图上提供面板的所有 FLUX 查询。正如您所观察到的，在 InfluxDB 数据桶中，我们只使用了三个参数：测试名称、状态和执行时间。仅凭这三个属性，我们就能获得各种有用的信息，并将其转化为面板并在仪表板上可视化。这些指标包括:

按状态分列的总测试执行次数
平均测试执行时间
最慢的前 N 个测试用例
测试执行随时间变化的趋势
测试执行持续时间分布
测试执行状态饼图

分析实时测试报告

实时测试报告开创了主动测试的新时代，使团队能够在测试过程中对测试执行和结果进行细致的监控。通过这些实时洞察力，测试团队能够在测试周期中出现异常、错误和性能瓶颈时迅速发现它们。例如，实时仪表板会突出显示三个通过速度最慢的测试。这种即时反馈使团队能够及时调查这些测试，确保在检测到的速度减慢阻碍软件开发流程之前就加以缓解。

实时测试报告的价值还包括加速调试和故障排除工作。通过获取测试失败或偏差的即时反馈，测试团队可以有条不紊地隔离问题的根源。这加快了确定代码库中有问题区域的过程，使开发人员能够及时实施有针对性的修复。试想一下，如果实时仪表板记录的失败测试次数突然激增，那么开发人员就会立即采取应对措施。这种直接的洞察力会促使开发人员立即做出反应，从而使协作调试过程更加集中、有效。

它们也是容纳基本测试指标和性能指标的动态指挥中心。这些仪表盘使团队能够根据实时数据做出明智的决策。例如，如果通过测试的人数持续下降，实时仪表盘就会直观地显示这一趋势。这种数据驱动的视角使团队能够重新评估其测试策略，将资源导向需要关注的领域，从而确保全面的测试覆盖率。

对测试进度和结果的持续监控使团队能够动态地将资源重新分配到需要立即关注的领域。如果实时仪表板上的每个测试的执行时间显示了资源密集型测试，团队就可以迅速重新分配资源，优化测试效率。这种自适应方法可防止资源瓶颈，促进测试工作的和谐分配。

实时测试报告的动态性质为测试团队提供了一个途径，可即时完善和优化测试执行策略。假设实时仪表板显示某些测试的执行时间持续延长。这种洞察力会促使团队重新评估他们的方法，寻求提高这些测试效率或分配额外资源的途径。实时报告所带来的适应性可确保测试策略保持敏捷，并与不断变化的软件需求保持一致。

文章最后，让我们来回顾一下：

实时仪表板通过提供对测试执行状态的即时洞察，彻底改变了测试报告，使团队能够对问题做出迅速反应并做出明智决策。测试自动化框架与 InfluxDB 和 Grafana 相结合，使团队能够无缝地收集、可视化和分析测试数据。自定义日志记录器和数据转换技术提高了测试指标的准确性和相关性，从而可以进行有意义的解释和明智的质量改进。

最新的 FLUX 查询语言为在 Grafana 中查询和可视化测试数据提供了灵活而强大的方法，有助于全面了解测试趋势和性能。通过采用这些先进的报告技术，自动化测试团队可以提高效率，及早发现瓶颈，并持续改进其软件质量保证流程。