测试用例的版本控制

Question

测试计划是否应该与代码一起保存在版本控制中？也就是说，测试计划和代码被放在相同的版本控制系统下，并且具有相同的修订计数。我说的不是单元测试代码，而是一个用手动测试用例填充的测试计划文档。有一些基于web的测试用例管理系统，但我怀疑测试用例如何进行版本控制并与代码同步？

更新:实际上，我正在为我的组织寻找一个基于web的测试管理系统，因为它可以方便地访问非开发团队成员(即不需要使用VC从存储库中签出测试计划)。然而，我更喜欢对这些测试计划进行版本控制，与软件的主要里程碑/发布同步。我还没有找到满足这种需求的测试管理系统。还是我看错了方向？

Answer 1

这对我来说是有意义的。我希望测试(无论是手动规范还是单元测试)和相应的代码步调一致。我也会期待(也许是乐观的！)该文档将在很大程度上与特定签入的代码步调一致。

也许如果你不能让它们完全同步，你可以利用你的源代码标签(或者分支？)识别一致性版本集的机制？如果您的版本控制包含您正在修改/构建代码库以实现的测试，这可能会更有意义(即，您的测试主导您的代码-绝不是不寻常的情况)。

Answer 2

就个人而言，我喜欢你的想法。尽管许多软件开发范例中的测试应该基于系统应该如何工作的规范，而不是它当前的工作方式，因此可以很容易地独立于您的同步代码进行开发。因为它们本质上是文档，所以它们可能在不同形式的文档版本控制系统中工作得很好。

一些团队使用像TestDirector这样的工具来管理测试计划、测试用例，并将它们连接到bug跟踪系统。每个测试用例、bug等都有自己的变更历史记录存储在数据库中，这样你就可以回去查看它(就像The Doctor所说的那样，通过一些工作和一些小把戏来搜索它)。然而，我们从来没有把它与代码同步，除非在主要的里程碑中，我们做了代码冻结，当时代码+脚本进入MKS Integrity (个人，我觉得我们在工作场所没有充分利用完整性……它是为整个开发团队设计的，而不仅仅是代码推动者)。

其他团队只是编写word文档，并将它们放在一个需要备份的文件夹中。简单，但在不太大的项目中的小团队也可以工作。