数据的使用可以对减少索赔产生重大影响。然而，差异化方法表明，良好的数据并不会自动带来更好的损失率。只有得到用户的认可，才能实现最大效率并预防损坏。
展望未来，要充分发挥防损潜力，需要做两件事。首先，为了留在机动车损坏领域，自动驾驶领域需要高度自动化。从而剥夺了驾驶员对存在事故黑点的行驶路线的决策权。另一方面，需要智能控制系统和数据源来有效支持自动或部分自动驾驶的过程。
在我看来，未来几年车辆的技术成熟度能否实现完全自动驾驶还有待观察。此外，还需要对交通控制系统（例如智能交通灯）进行大量投资，以实现汽车与基础设施的通信。考虑到新冠危机的影响，公共部门的此类投资可能会非常谨慎或根本不进行。
因此，对我来说关键是使用现有的辅助系统和交通管理系统来提供实时和预测性损坏信息。
您想了解更多关于 adesso 保险领域令人兴奋的博客文章吗？那么 活动策划者电子邮件列表 请看一下我们迄今为止已发布的博客文章。该应用程序的架构由通过 REST API 相互通信的微服务组成。在后端，数据库和其他系统通过 REST 和 SOAP API 以及专有接口连接。使用的技术是Java和Spring Boot。 UI 基于 JavaScript 并集成到门户应用程序中。
MicroFocus LoadRunner 被指定来执行负载测试。该工具以前由惠普开发，历史悠久，但也是市场上功能最齐全的工具。它提供了一个用于创建和测试测试脚本的本地开发环境，以及一个带有负载生成器的托管运行时环境，用于模拟测试用户访问。在开发环境中，可以记录 UI 测试并生成 API 测试脚本——至少理论上是这样。不幸的是，通过门户应用程序记录浏览器点击在实践中已被证明是不切实际的。使用的代理没有记录所有 HTTP 请求；特别是，由于不同域之间存在许多重定向，因此无法可靠地记录用于身份验证的令牌。从接口描述生成测试脚本模板仅适用于 SOAP 请求。因此，REST API 的测试脚本必须自行实现。
挑战
创建 REST API 测试脚本时，决定性的障碍不是工具或接口的复杂性，而是缺乏在项目上下文中使用的文档和专业知识。由于组织原因，两者仅在非常有限的范围内可用。由于该团队通过试点应用参与了新流程，因此早期的特点是大量的试验和错误。
类似 C 的语法、缺乏面向对象和特殊的数据结构是最初的障碍，可以在开发过程中通过不断增长的功能脚本模块套件来弥补。真正的挑战是规划和预留资源以在托管运行时环境上进行测试以及与所使用的其他后端系统进行协调的准备时间。如果再加上维护工作或单个负载生成器的故障，或者仅仅是由于负载生成器的过度阻塞而导致的错误，那么 LoadRunner 运行时环境很快就会成为瓶颈。