› › ›

稳定性

稳定性编辑

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

云
- 该功能是否在 云环境 中工作？
- 它是否创建了需要在云上公开或配置为与默认值不同的设置？（某些设置/用户的白名单？参考：https://elastic.ac.cn/guide/en/cloud/current/ec-add-user-settings.html，https://elastic.ac.cn/guide/en/cloud/current/ec-manage-kibana-settings.html）
- 它是否会对云 Kibana 实例产生重大性能影响？
- 它是否需要知道自己运行在容器中？（例如监控）
多个 Kibana 实例
- 指向同一个索引
- 指向不同的索引
  - 应确保 Kibana 索引在任何地方都没有硬编码。
  - 不应在 Kibana 内存中存储大量内容。
  - 应模拟高可用性部署。
  - 预测由于共享资源访问而导致的不同时间相关问题。
  - 我们需要确保安全以特定方式为非标准 Kibana 索引设置。（创建自己的自定义角色）
Kibana 运行在反向代理或负载均衡器后面，没有粘性会话。
如果代理/负载均衡器运行在 ES 和 Kibana 之间

测试 UI 代码很困难。我们努力实现代码和 UX 的完全自动化测试覆盖率，但这很难衡量，而且我们受时间限制。在开发过程中，测试覆盖率的衡量是主观的，并且是手动的，基于我们对该功能的理解。代码覆盖率报告表明可能存在差距，但最终取决于判断。以下是一些指南，可帮助您确保足够的自动化测试覆盖率。

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

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

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