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