稳定性

确保您的功能在所有可能的 Kibana 场景下都能正常工作。

环境配置场景

云
- 该功能在云环境下有效吗？
- 它是否创建了需要在云端暴露或与默认设置不同的设置？（是否需要白名单化某些设置/用户？参见：docs-content://deploy-manage/deploy/elastic-cloud/edit-stack-settings.md ， /reference/cloud/elastic-cloud-kibana-settings.md）
- 是否存在可能影响 Cloud Kibana 实例的显著性能影响？
- 它是否需要感知到在容器中运行？（例如监控）
多个 Kibana 实例
- 指向同一个索引
- 指向不同的索引
  - 应确保 Kibana 索引未在任何地方被硬编码。
  - 不应将大量内容存储在 Kibana 内存中。
  - 应模拟高可用部署。
  - 预见由于共享资源访问而导致的各种时序相关问题。
  - 我们需要确保为非标准 Kibana 索引以特定方式设置安全性。（创建他们自己的自定义角色）
Kibana 在反向代理或负载均衡器后面运行，没有粘性会话。
如果代理/负载均衡器运行在 ES 和 {kib} 之间

测试 UI 代码很困难。我们致力于实现代码和 UX 的全部自动化测试覆盖率，但这很难衡量，而且我们受到时间的限制。在开发过程中，测试覆盖率的衡量是主观和手动进行的，基于我们对功能的理解。代码覆盖率报告可能指示潜在的差距，但最终需要权衡判断。以下是一些指南，可帮助您确保足够的自动化测试覆盖率。

每个 PR 都应附带测试。
检查自动化测试覆盖率指标的修改前后。如果覆盖率下降了，您可能遗漏了一些测试。
用您的测试覆盖失败用例、边缘用例和正常路径。
特别注意可能包含损害用户利益的 bug 的代码。“损害”包括数据丢失和数据进入不良状态等直接问题，以及基于 UI 呈现的错误信息做出糟糕的业务决策等间接问题。例如，状态迁移和安全权限是需要覆盖的重要领域。
特别注意公共 API，它们可能会被意外使用。您发布的供其他插件使用的任何代码都应经过多种排列的严格测试。
在逻辑跨越全局状态、URL 和多个插件 API 的区域中包含端到端测试。
每次报告 bug 时，都要添加一个测试来覆盖它。
通过跟踪已发布功能的 bug 数量，回顾性地衡量您交付的代码的质量。您如何通过改进测试方法来减少这个数字？

请参考 Kibana 支持的浏览器和操作系统列表：https://elastic.ac.cn/support/matrix

该功能在支持的浏览器列表中是否高效工作？