我们目前正在研究不同的源代码控制工具,并且希望用一些轻量但有意义的场景来测试每个源代码控制工具,以便了解每个工具的功能.

术语和内部逻辑在某些工具之间变化很大,将用例表示的情景(“我们必须更正版本1.3上的错误”)而不是潜在的工具特定术语(“创建”分支命名为版本1.3“).

确实,不同的事情对于不同的团队来说很重要,但是有一些规范的测试用例可以从中挑选出不同的场景.还是我太乐观了？

有人知道这样的事吗？在调查源代码控制工具时,您是否使用过类似的方法？

最佳答案 这些是他们在2006年为内部使用评估版本控制系统时的
requirements that Mozilla had.您可能会发现类似的方法很有用.

如果您找到特定于您公司的方案,也许您可​​以将它们转换为上述要求.