研发修改逻辑导致测试用例老变动？需求或业务逻辑经常变动，如何保障用例的可用性？

随着IT市场日益繁荣，测试用例管理工具百花齐放，各有千秋

但是工具只是辅助我们更好的进行工作的。

很不幸 最近 我又踩了一波坑

故事背景是这样：某日，需求评审完 研发火急火燎的就去设计代码了、测试一边沉思一边写出了测试用例，殊不知未来。。。风驰电掣
 

后来掰着手指头算了算，也该用例评审了，于是乎 拉着研发和产品过来一起评审测试用例。

由于本人对于需求思考的比较多，于是出现了这样的情况

 

产品看到后。。。。。

然后一一对我提的风险项进行了解答（不会有这个场景，逻辑补充，一期不支持）

 

用例评审后，产品由于处理场景漏了，有些场景比较矛盾，然后就是一波改需求

测试。。。

 

我用例都写好了 还要重新改，还要重新导入到jira。。。还要重新跟需求关联    以前导入的就用例还要取消和需求的关联然后删掉。

一下子工作量和工作难度从 b级升到了s级。。。。那是真的无意义 纯手工 纯粹用肉身的一己之力去做（类似一个人数1000粒大米，手工一个一个数。。）

心态当时就不好了，心里一直再琢磨，敏捷开发的特点就是变化比较快，测试需要怎么样操作才能跟上需求的变化然后变化测试用例。这是一个需要解决的问题

 

需求逻辑变更对测试用例造成很大人力资源浪费问题:
我是从以下几个方面解决的

1、需求变更后，测试用例excel修改 修改后 通过脚本上传至jira（覆盖）
2、测试用例都有固定的标签来表明 是属于哪个模块-哪个功能

3、能单独拆分出来的需求 做新的测试用例 导入处理

4、原有测试用例如果失效，可以按照优先级批量处理

 

说起来可能比较复杂，我们举一个实际的例子

小鸣接了一个需求的测试任务，这属于一个已有模块的新功能，比如在购物车模块新加一个查询功能

这个时候小鸣写好了测试用例，给这些用例标注上【购物车-导出】的标签，之后上传到JIRA

 

这样用例在jira上就可以关联到需求，一目了然的知道每个需求分别执行了多少测试case

例：

 

 

测试过程中，小鸣想到”已下架的商品，是否要搜索到？“   于是他去问产品，产品想了想说，对哦，已下架的商品就不应该搜到的，于是小鸣找到了导入用例的excel

新加了一条用例，购物车搜索下架商品，然后运行脚本更新用例，于是就结束了。

如果说搜索时，发现了这个查询是模糊查询，也可以去修改用例，然后运行脚本更新用例就好了。无需做更多复杂的操作，大大降低了各种改 各种上传