稳定性
编辑稳定性
编辑确保您的功能在所有可能的 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 之间运行着代理/负载均衡器
Kibana.yml 设置
编辑- 使用自定义 Kibana 索引别名
-
当禁用可选依赖项时
- 确保所有必需的依赖项都列在 kibana.json 依赖项列表中！
测试覆盖率
编辑测试 UI 代码很困难。我们力求对我们的代码和 UX 进行完全自动化测试覆盖，但这很难衡量，而且我们受到时间的限制。在开发过程中，测试覆盖率的衡量是主观的和手动的，基于我们对功能的理解。代码覆盖率报告指出可能存在的差距，但最终还是要由判断来决定。以下是一些指导原则，可帮助您确保足够的自动化测试覆盖率。
- 每个 PR 都应附带测试。
- 检查自动化测试覆盖率指标的前后情况。如果覆盖率下降，您可能遗漏了一些测试。
- 用您的测试覆盖失败案例、边缘案例和正常路径。
- 特别注意可能包含对用户有害的错误的代码。“有害”包括直接问题，如数据丢失和数据进入不良状态，以及间接问题，如基于 UI 呈现的错误信息做出错误的业务决策。例如，状态迁移和安全权限是需要覆盖的重要领域。
- 特别注意公共 API，它们可能以意想不到的方式使用。您为其他插件发布供使用的任何代码都应进行严格的测试，并进行多次排列组合。
- 对于逻辑跨越全局状态、URL 和多个插件 API 的区域，请包含端到端测试。
- 每次报告错误时，都添加一个测试来覆盖它。
- 通过跟踪已发布功能报告的错误数量来回顾性地衡量您交付的代码的质量。如何通过改进测试方法来减少这个数字？
浏览器覆盖
编辑请参阅 Kibana 支持的浏览器和操作系统列表：https://elastic.ac.cn/support/matrix
该功能在支持的浏览器列表中是否高效运行？
升级和迁移场景
编辑- 该功能是否会影响旧索引或保存的对象？
- 该功能是否已使用 Kibana 别名进行过测试？
- 升级前后索引的读取/写入权限？