前情回顾
前面几期我们谈及了如何将测试的介入时间提前， 从而提早发现问题， 提早解决， 并介绍了两个实践：持续集成和测试先行。这个两个一个是从业务上面预防问题， 一个是从技术方面提早发现问题。是质量内建中用于提早发现问题的常用实践。
但貌似这些实践都着力于测试之外的范围， 是否有着力于测试本身的招式去将软件测试做的更加完善， 有效。这期， 我们就来感受一下软件测试本领域的内卷 -- 测试用例版本管理
通常我们的测试用例， 本质上是对软件需求的各个功能点展开与组合。开始， 在需求逐步增加的情况下，这是很容易的。一般的实践中测试用例分两种：
测试需求类型的测试用例
测试动作类型的测试用例
测试需求类型的测试用例描述的是需要测试什么， 例如：测试登录页面-进入登录页面-进行登录-查看结果 这是很不专业但是很常见的测试用例书写方法， 写这种用例的好处就是可以快速的生成成吨的用例的测试不同的功能点。
测试动作类型的测试用例则描述的是怎么测试， 例如：浏览器中输入www.xxxx.com/Login
用户名输入框输入xxx, 密码输入框输入yyyy,点击登录；期望：页面会跳转至www.xxxx.com/Dashboard
这显然就描述了测试中需要执行的步骤，无任何歧义，任何人都可以拿来执行；这样的好处明显就是可以消除功能测试中用例执行的不确定性， 使测试时执行的用例即是测试设计时所想
然而随着功能点的增加，测试用例根据功能点变化是指数级的，一个功能点下会根据不同的测试精度设计N条用例， 测试精度越高， 那单个功能点产生的测试用例就越多。
如果这个功能点发生正删改的话， 那么就会产生对测试用例维护维护工作。依照不同的测试用例精细度产生的工作量也不一样。如果多个功能发生修改的话会让维护测试用例这个工作变得更加困难。所以让测试用例保持新鲜度（实时吻合当前的功能）是非常大的挑战。
如何解决？
在实际的修改过程中， 我们通常会遇到两个困难点：1.用例多 2.定位难
在指数型的用例爆炸时，即使识别出了需要修改的用例，因为种种原因， 可能是设计过为精细或者功能点组合过于复杂， 导致有很多条需要修改。
因为要修改的用例太多，这个时候的反应要么就是花时间去重新写用例，要么就是迫于压力，采用能测则测，能舍则舍的方法去测试， 这时的测试用例聊胜于无， 如果错将已经失效的用例当成正确的执行要么就是误报，要么就是漏报。
最好的解决方法是按照模块去规划，不断的将测试用例进行原子化处理，使用业务逐级下分的方式，这里有个坑，就是往往一个测试的集合是多个人编辑的， 有可能存在放错地方问题，这个问题也很好解决：套用开发的实践-code review，来个testcase review ， 一天一个高产的测试工程师也就是60个用例，假设一组有5个测试， 300条用例，洒洒水啦
有了原子化的测试用例， 当一个功能点发生变更的时候， 只需要根据变更的功能点废弃或者重构某个节点即可， 由于用例是原子性的， 重构的成本为所有情况中最小
所以针对用例多 这个业务痛点场景， 原子分类法的效果如下：
此外，也可是使用模糊用例的方法， 很多小微的项目为了响应这已知的变化通常会将用例写的比较粗糙， 或者仅仅是记录测试的思路， 有的是画一个脑图，梳理用户故事， AC等等， 然后介于AC之后的方向继续发散，得到一些没有步骤但是明确要测试什么的一个文档。这个文档的形式有很多， 总体的特点就是可以一目了然的看到所有功能。
对于实际测试时， 需要根据当前的思路继续即兴发散， 得到一个相对比较准确的结果。
这种方法也无疑会减少因功能变更导致的用例失效， 毕竟“你变任你变， 意识在中线”
对于由于用例的分配和知识散点的出现， 会导致在功能点发生变化的第一时间， 无法精确定位到对应的测试用例，这个时候就会有第一时间找不到，测的时候碎一地的结果。
这时除了上面提到的原子分类法可以解决归类找到对应的测试用例以外，可以使用测试用例管理工具来快速的查到你需要修改的用例， 例如，zephyr, testhub, Ones testcase， 禅道，云效， tapd等等， 通过搜索对应的关键字可以非常快速的找到你想要修改的问题，甚至有些功能可以直接将用例关联到需求上， 需求变更后直接通过需求下钻的方式就可以顺路去修改即可
好了， 到了这里也列举出了几个常用的基础方法，用来解决用例多， 改用例困难的问题， 每种方法都能解决一个或者多个问题， 不过要解决定位难和用例多的问题， 貌似必须要采取多种方法混合的策略， 是否有一个通过的方法，或者是否有更高效的方式去管理测试用例呢， 有的， 这就是今天的主角--测试用例的版本管理
是想有这样的一个用例发展图：
看起来与开发中的版本管理如出一辙：
这样做的好处
使用软件开发的版本管理策略管理测试用例， 本质上是使测试用例有了版本的概念：
这样可以：
记录用例的历史变化
可以随时随地的将用例恢复到任意一个时间点
支持同时对多个不同需求或者不确定需求进行测试设计，保证了测试设计的进度
可以多人协作， 一起去review用例，使得测试更加完备
可以随时的将几个分支进行合并， 强制去除无效的用例
虽然对于版本管理这个技能很多测试都还不具备，但有很多工具可以帮助测试完成对应的设计， 且版本管理目前的学习成本很小。
值得一提的是， 测试用例管理的方法可以是一个方法论， 并结合上面提到的工作进行混合模式， 这样就有了测试用例管理的proplusmaxultra的版本了（笑）
下期预告 :
版本管理固然重要， 目前所有的实践都是散兵游勇， 下期， 我会介绍测试流程的编排，从整体上和大家一起讨论如何优化测试流程和测试流程的本质。
