测试人，你还在写用例吗？是什么在支撑着你写？

测试交付的过程，通常是伴随的是一个测试用例生命周期过程，通常有测试需求分析、测试用例设计、测试用例实现、测试用例执行，以及测试用例管理等几个阶段组成。

为什么要有测试用例？

首先测试用例这是测试岗位的基本交付物之一。开发人员的交付物是代码，是可运行的应用。这些都是可观察，实实在在的客观存在。而测试人员的交付物如果仅仅是一个所谓“经过测试”的应用，随产品发放的一个“QC”标志纸片，就不免让出钱雇佣你的人感到心里不踏实了。所以，在产品开发测试的过程中，测试团队或者测试人员不断产出和维护的测试用例，不断提升的用例执行比率，在测试报告中的这些数字或者图表，让测试管理者可以向更为高层的管理人员证明测试团队存在的价值，以及他们正在努力工作，为产品质量负责的表征。

测试用例的另外一个用处是作为一种信息的媒介，体现的是测试用例设计人员对于系统需求的理解，对于产品风险的一种理解。有了具体的测试用例，产品、开发、测试、运维人员在沟通时不再是空对空、而是可以具体到每一个测试用例，每一个检查点了。作为信息的媒介，也就可以作为个人和团队的资产留存下来了。正所谓好记性不如烂笔头，测试人员在遇到相类似的需求或者功能点改造时，这些旧的用例就能发挥作用，作为回归用例或者是稍加改造成为新的用例。亦或者当团队有新人来或者进行轮岗时，测试用例也可以作为一份新手上路的最佳参考地图。正所谓纸上学来终觉浅，对照着测试用例将系统安装部署，测试一遍，是很多团队训练新人的不二法门。

一定要有测试用例吗？

测试用例有这么多的好处，但是它一定是必须的吗？ 尤其是在当下，随着团队交付速度的加快，团队都被要求“更加敏捷 Be More Agile”了，能够按时交付产品就已经烧高香了，还有时间按照“前置条件、测试步骤、预期结果”这样进行文本形式的测试用例编写吗？从产品风险和交付的角度来看，高效全面地发现缺陷才是快速交付、降低风险的根本，“探索式测试”不是更能高效率地发现缺陷吗？在做完测试分析之后，为什么不能直接进入探索系统、发现缺陷的过程，而要将宝贵的时间浪费在编写测试用例文本这种不直接产生交付价值的活动上呢？

更何况，测试用例处在测试设计和最终执行的脚本和数据之间。作为一项智力活动测产出，测试设计，通常是以一些表格或者是思维导图的形式呈现和表达设计的思路和意图。这一部分是非常适合进行评审的，类似开发人员的设计评审或者是Code Review, 而据此平铺开之后的测试用例，则经常因为数量庞大，导致“只见树木不见森林”，让团队迷失在用例森林之中，感觉到用例评审的时间付出与价值收获非常的不成比例。也就是所谓额，测试设计是可评审的，而测试用例是不可评审的。

另外一种说法则是，用例作为一种团队的资产，其主要的价值时被复用。而为了迎合市场的变化，产品和系统自身也在快速迭代。在这个过程中，很多团队进入了类似狗熊掰棒子，走一路丢一路的状态。因为需求很多时候是探索性的，系统的变化也很快，测试用例极少能得到复用，为测试活动配套编写和沉淀几乎以后再也不会使用的测试用例，好像成了一件极为不经济和理智的行动。就这样，历史上积攒下来的测试用例库很快就乏人问津，衰变腐化，成为了坏账和呆账，数量愈大，负担愈重。有些团队就干脆丢弃包袱，“轻装上阵”或者是推倒重来，将历史的用例库丢进了垃圾堆里。

颠覆者的思路

近些年，通过基于模型的测试（MBT）、线上引流、AI测试、众测和AB测试等方式，不少团队实现了所谓的测试用例自动生成、快速回归测试以及其他有别于传统测试方式的测试实践，走出了不同以往的新路。

文章的开头的一张图，是一张测试体系衰退的图，越底层的内容在项目交付压力和资源困局下越容易被丢弃掉。

问一下很应试的问题，如果给你的时间只够完成上述列表中的三件事情？你会选哪三样？