随着IT市场日益繁荣，测试用例管理工具百花齐放，各有千秋
但是工具只是辅助我们更好的进行工作的。
很不幸 最近 我又踩了一波坑
故事背景是这样：某日，需求评审完 研发火急火燎的就去设计代码了、测试一边沉思一边写出了测试用例，殊不知未来。。。风驰电掣
后来掰着手指头算了算，也该用例评审了，于是乎 拉着研发和产品过来一起评审测试用例。 由于本人对于需求思考的比较多，于是出现了这样的情况
产品看到后。。。。。
然后一一对我提的风险项进行了解答（不会有这个场景，逻辑补充，一期不支持）
用例评审后，产品由于处理场景漏了，有些场景比较矛盾，然后就是一波改需求
测试。。。
我用例都写好了 还要重新改，还要重新导入到jira。。。还要重新跟需求关联 以前导入的就用例还要取消和需求的关联然后删掉。
一下子工作量和工作难度从 b级升到了s级。。。。那是真的无意义 纯手工 纯粹用肉身的一己之力去做（类似一个人数1000粒大米，手工一个一个数。。）
心态当时就不好了，心里一直再琢磨，敏捷开发的特点就是变化比较快，测试需要怎么样操作才能跟上需求的变化然后变化测试用例。这是一个需要解决的问题
需求逻辑变更对测试用例造成很大人力资源浪费问题: 我是从以下几个方面解决的
1、需求变更后，测试用例excel修改 修改后 通过脚本上传至jira（覆盖） 2、测试用例都有固定的标签来表明 是属于哪个模块-哪个功能
3、能单独拆分出来的需求 做新的测试用例 导入处理
4、原有测试用例如果失效，可以按照优先级批量处理
说起来可能比较复杂，我们举一个实际的例子
小鸣接了一个需求的测试任务，这属于一个已有模块的新功能，比如在购物车模块新加一个查询功能
这个时候小鸣写好了测试用例，给这些用例标注上【购物车-导出】的标签，之后上传到JIRA
这样用例在jira上就可以关联到需求，一目了然的知道每个需求分别执行了多少测试case
例：
测试过程中，小鸣想到”已下架的商品，是否要搜索到？“ 于是他去问产品，产品想了想说，对哦，已下架的商品就不应该搜到的，于是小鸣找到了导入用例的excel
新加了一条用例，购物车搜索下架商品，然后运行脚本更新用例，于是就结束了。
如果说搜索时，发现了这个查询是模糊查询，也可以去修改用例，然后运行脚本更新用例就好了。无需做更多复杂的操作，大大降低了各种改 各种上传
