最重要的BI测试-适用于任何BI和分析平台

为什么 BI 测试是答案

相信你的数据可视化是成功执行商业智能 (BI) 和分析项目的关键因素。我敢肯定，你遇到过以下情况：业务主管或业务用户反馈说他们的分析看起来不对，他们的 KPI 看起来有问题，或者速度太慢而无法使用。要问自己的问题是：如何避免这种情况？如何确保用户满意？如何确保 100% 信任仪表板？如何确保高质量的分析？如何做出值得信赖的决定？

如今，公司正在寻求将已建立的 DevOps 和软件开发实践中的最佳实践引入分析领域。这就很容易地理解为什么 BI 测试是一个明智的选择。对于用户（内部）和消费者（外部）而言，在问题到达生产环境之前发现问题效率要高得多，而不必事后处理后果。了解内部或外部的错误比较被动，因此在用户之前发现错误同样很重要，日常监控测试应该在发布到线上后进行。任何使用 Tableau、Power BI、SAP BusinessObjects 或任何其他分析解决方案等分析平台的公司都应定期进行 BI 测试，以便在用户看到问题之前发现问题，从而确保信任并避免任何风险。本文将解释公司应该进行的不同 BI 测试。

应该进行的不同 BI 测试

我们创建了一份可以执行的不同类型测试的非详尽列表：

功能测试

你在打开仪表板时遇到过问题吗？是否曾经单击过可视化中的筛选器或参数，但它们没有按照预期执行？诸如此类的示例可能是用户日常的烦恼，但通过测试每个仪表板功能，可以确保提供最佳的用户体验。如果持续存在问题，随着时间的推移，用户将失去使用它们的耐心和动力，从而降低用户采用率。对仪表板的每个元素进行功能测试将有助于解决这些问题。

回归测试

回归是分析中的最高风险，因为它们很难或不可能被人眼发现，并且可能对决策制定造成灾难性的影响。回归的例子是：

●数据

●图像

●元数据（例如过滤器或参数）

●服务器和仪表板性能

为了克服这些回归，存在回归测试以跨时间比较两个版本的仪表板/报告并自动突出显示任何差异。有测试经验的人都知道，必须定期执行此类 BI 测试，以检测可能与 BI 软件本身或与数据源及其通向数据消费者的路径相关的任何不需要的更改。建议将这些测试应用于敏感报告和仪表板，以检测与修改相关的任何副作用，并限制所涉及的风险。

性能测试与压力测试

这两种类型的 BI 测试通常可以被视为相同但有区别！性能测试是对许多报告或仪表板的测试，以评估它们的性能，即单个功能任务需要多长时间。压力测试允许将负载驱动到服务器并评估响应时间和可用性。能够评估分析平台可以处理的最大用户数量、运行它所需的基础设施，甚至是用户负载高峰时的可持续性。它实质上是根据“标准条件”测试你的平台，以验证它是否持续按应有的方式运行。

跨环境测试

通过跨环境测试，可以将给定环境中的一个或多个仪表板与另一个环境中的相同仪表板（即开发或生产的不同站点或服务器等）进行比较——简单地说，就是跨不同环境的回归测试。

公差测试或范围测试

这种类型的 BI 测试可确保业务用户在 KPI、指标或特定数据超出其设定阈值或误差范围时在任何仪表板中出现错误时得到通知。容差测试保证显示的数据始终在可接受的范围内，并且可以非常快速地检测到任何问题。

升级和迁移测试

每当执行 BI 平台的迁移或升级时，测试对于验证一切是否仍在正常运行就变得至关重要。我的访问级别是否与以前相同？我的报告和/或仪表板是否显示了正确的数据？我可以信任在新环境中呈现的数据吗？迁移或升级后的测试将为你提供所有这些问题的明确答案。请记住，在迁移期间直接或间接连接到 BIA 平台的任何外部系统（例如数据源、数据准备工具和数据库）也可能需要回归测试。

安全测试

所有的BI工具都有安全认证和授权的要求，同时具有单点登录和嵌入式能力，测试所有的软件安全方面是非常重要的。例如，它会根据用户的访问级别检查用户是否有权访问报告和仪表板，以及是否存在相同的行级安全性。对于使用单点登录的用户，它还确保最终用户能够使用此功能访问他们的不同 BI 系统。

SQL数据测试

数据测试验证 Analytics 输出是否等于 SQL 查询返回的数据。该测试非常受欢迎，因为它可以轻松确定发现的回归是否是由数据旅程中的分析层引起的。用户验收测试 (UAT) 或“冒烟测试”用户验收测试在应用于 Analytics 时也称为冒烟测试，它是初步测试，用于检查可能拒绝潜在发布的任何简单故障。测试用例在测试环境中运行，以验证软件的主要功能是否正常工作并确认基本问题，例如：“我的仪表板是否满足初始业务需求？”、“我可以打开可视化吗？”报告满足绩效要求”。