关于测试用例评审，很早就有这个想法，但是鉴于以下几个因素，一直未执行：
1.在刚来的时候-6年前，连需求都没有，到版本提交测试时，才第一次了解到版本做成这样，测试用例无从谈起
2.来了两三年之后-4年前，测试用例被提起，但是依然无用例：无项目流程，无写用例时间
3.来了四五年后-两年前，才开始有项目概念之说，开始执行项目流程，这时候，测试用例才真正被提上日程，但是项目流程还未成熟，用例也很多是事后补，无从评审
4.来了五六年-现在，项目流程趋于稳定完善，用例编写也已规范，至此，才开始审视用例评审
现在用例评审时机到了，关于如何开展用例评审，根据目前的一些积累经验，总结评审内容如下：
在刚实施过程中，遇到一个问题：测试成员认为，多输出这个文档的流程，是浪费时间。
这样认为的原因：在无这个文档的时候，已经开始执行用例评审，用例评审的形式是一对一评审， 评审者直接在被评审用例上备注问题及补充；多这个文档，变成在原来的基础上多一步操作-----还要多输出一份内容，特别是在用例份数多的情况下，到底有无必要？
个人推进这个规范的原因：这个评审表格，应该是作为一个check list，以防遗漏；目的是这样的，大家也认同，只是实践过程中，可能需要做些微调
具体效果如何，需要积累几个版本后再做个总结，目前还只是刚开始执行阶段
不过，个人有个困惑目前还不解：
我们的产品，是在不断升级的，升级版本会对旧功能做一些补充或改造；每次在一个升级版本中，会专门写一份这个升级版本的用例。
但是在这个版本结束后，肯定需要对这个功能的用例进行维护，那就需要整合这个功能的新旧内容；
那么问题来了，这种情况很可能新的用例逻辑跟旧的用例逻辑不一样，如果要整合起来的话，不是单纯往旧用例上累加就可以的；逻辑需要重新整理，步骤需要重新调整；这种情况下，改造还不如重新写；
这样的话：一个功能，用例写完之后，功能有升级变更情况下，该如何写用例合适？在旧用例上直接进行改造还是另起一份？