怎么用思维导图设计测试用例

2014 年之前,我们组一直使用Excel编写测试用例,从2011年开始的3年时间里,积累的 Excel文件大小将近3M,体积变大导致文件打开速度越来越慢。

同时随着项目迭代速度的加快,Excel 编写用例的效率已经开始拖后腿,经常出现在项目完结后才去追更测试用例的情况。

所以在 2014 年,我们果断的切换为思维导图编写用例,然后一直沿用至今。

思维导图也叫脑图,本来是为了做头脑风暴用的,用它来写用例完全是借助这个工具本身的功能而已。

所以最初我们并没有明确规定导图的使用格式,只要是可以快速进行需求的拆解,并保证用例对于需求的覆盖率即可。

可是脑图相对 Excel 来说,自由度太大了,最终就导致使用脑图编写测试用例的格式,出现了两种完全不同的风格。

举个栗子,现在有一个需求,完整的描述如下:

现在有一个 PC 客户端的命令行工具,这个工具可以接收三个命令行参数,其中,前两个是数字,最后一个是运算符,运算符只支持加减乘除四种,工具的功能就是把前两个数字使用运算符做下运算,然后输出运算结果。

分别使用两种格式来编写的测试用例如下图所示(部分用例):

怎么用思维导图设计测试用例

第一种风格,完全是遵循脑图的本来用法,属于层级递进式,前面层级都是后面层级的前置条件,需要把每一个分支的所有层级全部组合到一起,才是一条完整的用例。

第二种风格,是按照要素归类的方式,每一层都是同一要素的不同类别,细化到的最后一级就是一条完整用例,前面的层级只是为了让分类清晰,为了把后面一大坨的最终用例更有条理的进行展示。

相对来说,我更推荐第二种风格。

第一种风格更适合做需求分析,通过思维的逻辑发散,把不同的路径通过脑图进行展现,从而激发更多的灵感。

但是测试用例是针对已经固定的需求和实现来做覆盖,它的前提是固定的,我们用脑图需要做得,就是把已有的需求和实现,转换为用例后,再通过合理的方式进行呈现。

我们需要的,一方面是合理的拆分,比如第二种格式里的第一层,我们按照输入、输入顺序和输出分成三块,后续继续按第一个参数、第二个参数和第三个参数这种方式进行更细的划分,所以条理性还是蛮清晰的。

这种格式的用例,在做用例评审时,可以很方便的和需求进行一一对应,能够很快的确认需求覆盖率。

另一方面,这种格式的用例,对于用例执行者也是比较友好的,执行者可以只关注用例的最后一个节点,按照指定策略执行就行了,如果是第一种格式,需要每次都从头看到尾,很容易出错。

来自公众号 sylan215



留言