济南建站免费模板,教育培训类网站建设与维护,加强网站建设的意义,网页设计作业怎么交为什么 BI 测试是答案
相信你的数据可视化是成功执行商业智能 (BI) 和分析项目的关键因素。我敢肯定#xff0c;你遇到过以下情况#xff1a;业务主管或业务用户反馈说他们的分析看起来不对#xff0c;他们的 KPI 看起来有问题#xff0c;或者速度太慢而无法使用。要问自己…
为什么 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 时也称为冒烟测试它是初步测试用于检查可能拒绝潜在发布的任何简单故障。测试用例在测试环境中运行以验证软件的主要功能是否正常工作并确认基本问题例如“我的仪表板是否满足初始业务需求”、“我可以打开可视化吗”报告满足绩效要求”。
用户验收测试 (UAT) 或“冒烟测试”
用户验收测试在应用于 Analytics 时也称为冒烟测试它是初步测试用于检查可能拒绝潜在发布的任何简单故障。测试用例在测试环境中运行以验证软件的主要功能是否正常工作并确认基本问题例如“我的仪表板是否满足初始业务需求”、“我可以打开可视化吗”报告满足绩效要求”。
手动 BI 测试的真实成本
这些类型的商业智能测试都可以自动化这对公司来说是天赐之物因为手动测试会带来成本老实说反正没有人喜欢花时间测试不是吗
以下是手动测试的一些缺点
●员工正在执行单调和重复的任务这些任务占用了宝贵的时间用于更具创新性的工作。
●手动测试具有很高的人为错误风险并且会给执行测试的团队带来压力
●无法完整记录流程并获得已执行测试的证据。
●手动测试会降低员工的积极性因为他们没有时间发挥创造力和提高技能。
●当涉及到数据回归时手动测试效率低下因为它们中的大多数是不可感知的从而增加了风险。
●随着时间的推移手动测试不可扩展或不可重复并且不能应用于数以千计的 BI 仪表板和报告。
●手动测试需要业务理解和技术能力这很难找到。
●由于手动测试的所有这些缺点用户只会测试对象的一个子集。
在 Wiiisdom我们的客户通过这些不同类型的测试成功地节省了每月的工作时间从而提高了仪表板和报告的质量并有更多时间从事其他项目。自动化 BI 测试允许将测试集成为更广泛的 CI持续集成/CD持续交付流程的一部分其中仪表板在其生命周期的每个步骤从开发到维护中定期进行测试。
你进行了多少 BI 测试
你是否正在执行所有这些类型的 BI 测试 你相信你所做的商业决策吗 自动化 BI 测试对于公司始终拥有值得信赖的质量分析并能够做出最佳业务决策至关重要。 它还降低了与手动测试相关的风险而手动测试可能会降低 BI 项目的成功率。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你
