0

我正在研究一个相当大的现有代码库，其中创建了 SBE 规范来定义产品的行为。

目前大约有 450 个场景，随着代码库中添加的每个新功能，这个数字还在增长。

与传统的单行需求陈述相比，由于 SBE 规范的冗长性质，很难对系统的功能有高层次的理解。例如，这些故事目前共有 46,830 个单词：

$ find src/main/resources/stories/ -name *.story | xargs cat | wc -w
   46830

另一个问题是我们正在使用gerrit 代码审查工具来协作处理故事，这导致了团队之间的正式沟通。

问题 1：SBE 是否应该是一个完整而全面的回归测试套件（示例）？或者，他们是否应该只关注每个 sprint 所需的关键功能？

问题 2 ：正如这里的答案所提到的，是否需要诸如问题跟踪器之类的工具来管理大型项目的故事？

4

1 回答 1

1

通常验收测试和行为测试侧重于确保交付价值，因为它们本身就是一种黑盒测试形式。

所以对于 1. 答案是否定的，它们不应该是完整的。他们应该确保产生价值的外部行为不会倒退。

关于 2。我会避免使用此类工具，因为它们很难查询以获取基于时间的信息：通常像 Rally 或版本一这样的敏捷工具能够制作燃尽图，为您提供按日和速度图表的燃尽图。使用错误跟踪器进行跟踪，使用敏捷工具进行敏捷！

于 2014-01-14T15:03:10.530 回答