需求是迭代的，如果没有完整的用例库，后面就没办法整体维护。

用例也跟着迭待呀，有一版需求就会有一版用例，而且这个维护，要维护什么呢？

建议还是能统一的在一个地方去管理

学习

原因呢？

可以放脑图或者用例的链接，要不意义不大

需求迭代，我理解的是一个新的需求文档，并不会复用吧
而且这种情况下，每个版本的需求都不一样，本身只是简单的用例维护，现在会变成需求及用例维护，但需求维护方并不在测试，最后一定是混乱的
这样也不利于维护，由于需求而产生影响 的用例

我们的需求有两种形式，一种是在原来的基础上增加，还有一种是分期的，一期，二期这种，每一期略有不同，用例有部分可复用，有部分就直接没用了。有比较大的需求，等这个大的需求完成了，就会提一些小的优化。我想表达的是我们历史的用例看的很少。回归测试用例之前也整 过，但是没啥人看

这个之前是给脑图的链接，但是对应关系不太好找，一个项目多个开发时，开发也不能对应找到自己负责那部分的用例。但是需求模块是明确的，然后按模块在下方提供用例。这样开发很容易找到对应的模块和用例。有关联关系的再用例标明一下就行

逻辑感觉有点问题，需求是产品同事提的，用例是测试同学写，这两类角色写的内容，怎么会融合到一个文档里？
但是需求文档里，有时是有测试用例的，但是这个测试用例是产品验收时的出口条件，是关键的主流程，也是产品同事写的。

也不是融合到一起，谁写谁的，只是放到一个文档里了，他们还是独立存在的，不过我虽然一直在反驳大家，但是大家的意思是最好还是不要写到一起了。咱们这里都是测试同学，能不能麻烦各位看看自己的开发是如何感觉的。前提是你们也是用例驱动开发模式

BDD 难道不是解决这种的的吗？开发和测试都根据需求来做。

我大概明白楼主的意思 ，大概就是开发那边没有专门的需求分析人员，开发人员不想自己看需求文档开发，所以就直接对照测试的用例来开发了，等于你们测试给开发做了前期的需求分析工作呗。

感谢大家的回复，不讨论了，领导有了明确的要求，必须要用用例工具，方便统计出了多少用例，UI 覆盖了多少。就是为了看数据呀

不然后续随着迭代版本管理以及用例后续的转自动化会是大麻烦的