作为测试人员, 测试用例是主要交付物. 测试用例主要收益有两块, 一方面在新功能测试时候, 帮助需求相关方了解测试覆盖程度. 另一方面在做功能回归时候, 帮助测试人员了解相关功能的测试点. 测试用例特点是数量是持续变化的, 新功能交付, 线上事故, 以及代码重构都能产生很多新用例, 同时过期一些旧用例. 因此, 管理测试用例在考验每位测试人员的基本功.
怎样让测试用例的收益最大化呢?
新功能测试
对于第一块收益, 有两个时间点很重要.第一个一个是测试用例评审阶段 测试用例评审的目的是让相关放了解测试的覆盖程度, 而且那时候很多细节也没有足够清晰,所以不要求测试用例编写的足够细致,主要是罗列测试点.这个时候主要使用的工具是excel, 思维导图等等. 第二个阶段是真正执行测试用例, 这个时候功能已经提测, 是真刀实枪的去测试用户使用的各个场景, 这个时候用例需要颗粒度与其他测试人员一致, 同时也要及时补充在测试过程中发掘新的测试点, 为后续的回归作准备.
回归测试
对于第二块收益, 需要我们做到两点, 第一要求测试用例编写一定要规范, 因为回归的同学不一定是当初编写的同学, 就算是编写的同学, 如果当时编写的不够清楚,过了一年半载, 很多细节也会有遗忘, 所以需要统一的测试用例颗粒度. 第二个要求我们持续对测试用例做维护, 在添加新功能时候, 要及时补充新的测试用例,对于改动的老的测试用例也要及时的修改或者废弃.
测试用例是一个长期动态调整的过程, 尤其对于迭代中的产品, 变化会更频繁. 因此维护测试用例是一个冗长且复杂的工作. 我们可以通过良好的流程管控来达到这一点, 但是需要付出一定的人力成本. 本人在个人实践中发现, 可以借助一些自动化手段来减少一定的管理成本. 通过现有的ATDD的测试框架, 我们可以把自动化用例与普通用例一一绑定. 因为自动化用例一直跟着代码走, 新的功能变化, 影响的用例, 必然会迫使我们调整自动化测试用例. 测试用例的维护工作, 从“拉”变成了“推”, 别小看这一变化. 曾经我在之前文章谈到了自动化技术债问题, 其实我们测试人员是一直处在追赶态势, 如果再增加维护测试用例的技术债, 无疑是雪上加霜, 现在把这两块技术债结合为一个任务, 真有种快刀斩乱麻的愉悦感.
最后通过最近看的《显微镜下的大明》来总结一下, “唯殷先人, 有册有典, 殷革夏命”. 历史上成功的朝代之所以繁荣昌盛, 不是因为打仗厉害, 也不是政策开明, 而是因为有完备的户籍档案, 反之亦然. 类比过来, 测试用例也是测试团队甚至是产品安身立命的基础, 需要每一个人去用心呵护.
