我们目前正在研究不同的源代码控制工具，并且希望使用一些轻量但有意义的场景来测试每个工具，以了解每个工具的功能。
术语和内部逻辑在某些工具之间变化很大，以用例（“我们必须纠正版本1.3上的错误”）表示方案会很好，而不是在特定于工具的术语中（“创建名为Release 1.3的分支”）。
对于不同的团队来说，不同的事情是很重要的，但是有一些规范的测试用例可以从中挑选出不同的场景。还是我太乐观了？
有人知道这样的事吗？在调查源代码控制工具时，您是否使用过类似的方法？
答案 0 :(得分：1)
这些是requirements that Mozilla had，当他们在2006年为内部使用评估版本控制系统时。您可能会发现类似的方法很有用。
如果您发现特定于贵公司的方案，也许您可以将它们转换为上述要求。
答案 1 :(得分：1)
您有一些Google DVCS analysis的一般标准可以提供一些想法。
但您首先需要了解是否要评估：
有关测试的不同场景的更多信息（CVCS的一个答案，DVCS的一个答案），请参阅SO问题：
“ Describe your workflow of using version control (VCS or DVCS) ”
答案 2 :(得分：0)
您必须提出以下问题：您是否只有一行发布/开发，还是我们并行创建多个版本？不仅需要提到的场景，你需要考虑那个，比如将变化合并到dev行或其他多行。这可以影响方法。您选择的方法听起来非常好，因为您尝试了解该过程而不使用工具术语。我为我的客户多次这样做过。在不同的团队/公司中，不同的事物处理不同。所以问题是弄清楚你的过程是什么（有时人们不知道这一点）。