缺陷跟踪应用程序架构
  • 04 Nov 2023
  • 1 分钟阅读
  • 贡献者

缺陷跟踪应用程序架构


文章摘要

应用程序结构

Functional Example} 是 Tulip 库中的一个应用程序,但当可以构建专用应用程序以支持不同用户角色和需求时,Tulip 应用程序的价值就体现出来了。

传统的缺陷跟踪解决方案充其量只是漏洞百出的一次性点解决方案,最糟糕的是涉及数十个随机的 Excel 表单和纸质表格,而且需要花费大量时间进行手动数据录入。

缺陷跟踪是一个比较特殊的问题,因为最好的缺陷跟踪解决方案是在上下文中(在可以发现缺陷的流程中)存在的,所以最好的缺陷跟踪解决方案应该可以在可能发现缺陷的所有流程应用中使用。应用程序转换可用于将用户从任何流程应用程序转移到中央缺陷跟踪应用程序,或者在所有应用程序中复制缺陷报告功能。

一个中央缺陷跟踪应用程序

优点

  • 对缺陷管理流程的更改非常简单,只需一个更改点
  • 与流程应用程序相比,独立团队可以管理应用程序版本

缺点

  • 用户体验更不连贯,因为缺陷是在不同的应用程序中输入的
  • 在多个应用程序中管理变量可能需要更多触发器。

在每个应用程序中进行缺陷报告

优点

  • 用户体验更加完美。
  • 不同缺陷类型的流程可以使用不同的用户界面,以更好地支持其标准缺陷。
  • 应用程序变量管理更简单。

缺点

  • 当流程发生变化时,会有很多变化点。这些更改需要一次性应用到每个应用程序。
  • 管理流程应用程序的同一个团队将拥有每个应用程序的缺陷跟踪。

应用程序分解

缺陷跟踪的 Functional Example 是跟踪缺陷所需的核心功能:

  • 报告缺陷
  • 编辑缺陷报告
  • (可选)打印用于隔离的缺陷标签
  • 查看缺陷
  • 更新下一步和状态
  • 查看缺陷历史记录
  • 通过分析深入了解缺陷情况

如功能示例所示,所有功能都可以合并到一个应用程序中,也可以在更多细分应用程序中利用其任何核心功能。

无论采用哪种方法(如上所述),Tulip 都建议将缺陷的编辑和处置功能转移到只有具有特殊权限的用户才能访问的单独应用程序中。这样可以更好地控制哪些用户可以编辑质量关键数据。


本文对您有帮助吗?