从测试角度看质量内建 -测试用例版本管理

2022-05-29 本文已影响0人中年吴叔瞎BB

前情回顾

前面几期我们谈及了如何将测试的介入时间提前，从而提早发现问题，提早解决，并介绍了两个实践：持续集成和测试先行。这个两个一个是从业务上面预防问题，一个是从技术方面提早发现问题。是质量内建中用于提早发现问题的常用实践。

但貌似这些实践都着力于测试之外的范围，是否有着力于测试本身的招式去将软件测试做的更加完善，有效。这期，我们就来感受一下软件测试本领域的内卷 -- 测试用例版本管理

通常我们的测试用例，本质上是对软件需求的各个功能点展开与组合。开始，在需求逐步增加的情况下，这是很容易的。一般的实践中测试用例分两种：

测试需求类型的测试用例

测试动作类型的测试用例

测试需求类型的测试用例描述的是需要测试什么，例如：测试登录页面-进入登录页面-进行登录-查看结果这是很不专业但是很常见的测试用例书写方法，写这种用例的好处就是可以快速的生成成吨的用例的测试不同的功能点。

测试动作类型的测试用例则描述的是怎么测试，例如：浏览器中输入www.xxxx.com/Login

用户名输入框输入xxx, 密码输入框输入yyyy,点击登录；期望：页面会跳转至www.xxxx.com/Dashboard

这显然就描述了测试中需要执行的步骤，无任何歧义，任何人都可以拿来执行；这样的好处明显就是可以消除功能测试中用例执行的不确定性，使测试时执行的用例即是测试设计时所想

然而随着功能点的增加，测试用例根据功能点变化是指数级的，一个功能点下会根据不同的测试精度设计N条用例，测试精度越高，那单个功能点产生的测试用例就越多。

如果这个功能点发生正删改的话，那么就会产生对测试用例维护维护工作。依照不同的测试用例精细度产生的工作量也不一样。如果多个功能发生修改的话会让维护测试用例这个工作变得更加困难。所以让测试用例保持新鲜度（实时吻合当前的功能）是非常大的挑战。

如何解决？

在实际的修改过程中，我们通常会遇到两个困难点：1.用例多 2.定位难

在指数型的用例爆炸时，即使识别出了需要修改的用例，因为种种原因，可能是设计过为精细或者功能点组合过于复杂，导致有很多条需要修改。

因为要修改的用例太多，这个时候的反应要么就是花时间去重新写用例，要么就是迫于压力，采用能测则测，能舍则舍的方法去测试，这时的测试用例聊胜于无，如果错将已经失效的用例当成正确的执行要么就是误报，要么就是漏报。

最好的解决方法是按照模块去规划，不断的将测试用例进行原子化处理，使用业务逐级下分的方式，这里有个坑，就是往往一个测试的集合是多个人编辑的，有可能存在放错地方问题，这个问题也很好解决：套用开发的实践-code review，来个testcase review ，一天一个高产的测试工程师也就是60个用例，假设一组有5个测试， 300条用例，洒洒水啦

有了原子化的测试用例，当一个功能点发生变更的时候，只需要根据变更的功能点废弃或者重构某个节点即可，由于用例是原子性的，重构的成本为所有情况中最小

所以针对用例多 这个业务痛点场景，原子分类法的效果如下：

图片.png

此外，也可是使用模糊用例的方法，很多小微的项目为了响应这已知的变化通常会将用例写的比较粗糙，或者仅仅是记录测试的思路，有的是画一个脑图，梳理用户故事， AC等等，然后介于AC之后的方向继续发散，得到一些没有步骤但是明确要测试什么的一个文档。这个文档的形式有很多，总体的特点就是可以一目了然的看到所有功能。

对于实际测试时，需要根据当前的思路继续即兴发散，得到一个相对比较准确的结果。

这种方法也无疑会减少因功能变更导致的用例失效，毕竟“你变任你变，意识在中线”

图片.png

对于由于用例的分配和知识散点的出现，会导致在功能点发生变化的第一时间，无法精确定位到对应的测试用例，这个时候就会有第一时间找不到，测的时候碎一地的结果。

这时除了上面提到的原子分类法可以解决归类找到对应的测试用例以外，可以使用测试用例管理工具来快速的查到你需要修改的用例，例如，zephyr, testhub, Ones testcase，禅道，云效， tapd等等，通过搜索对应的关键字可以非常快速的找到你想要修改的问题，甚至有些功能可以直接将用例关联到需求上，需求变更后直接通过需求下钻的方式就可以顺路去修改即可