经过近一个月的反复宣讲,以及通过用例评审反复和大家沟通意见建议,我们用思维导图写测试点的格式已经基本固定了下来。
基础的内容,请回看前两篇文章:
《思维导图编写测试用例的两种格式》
《用思维导图写测试点的几点说明》
今天是在这些内容基础上的再补充。
1.表示层和逻辑层测试目的的区分
表示层测试点的测试目的应该是针对业务逻辑的覆盖,所以表示层测试点的描述,可能会被误以为是需求的描述,其实不一样,需求只是描述业务的展现形式,测试点是要验证产品满足了要求的展现形式,并且在验证时,我们把需求进行了颗粒度的拆分,逐点进行验证。
逻辑层测试点的测试目的应该是针对实现逻辑的覆盖,所以逻辑层测试点的描述,都应该是逻辑实现本身,只是某些情况,无法通过针对性的逻辑结果来确认测试结果,我们就会用表示层的现象来间接证明,一般不建议这么做,但如果只能这样,那就特殊说明下,毕竟针对同一个业务逻辑,表示层和逻辑层测试点的操作步骤几乎是一样的,只是关注点不同。
这么说起来比较抽象,我还是拿个例子来说吧。
需求:有一个程序,在自己退出时,会把自己的启动时间通过 http 打点上报给服务端。
针对这个需求,如果是表示层的用例,只需要下面两条就够了:
但是,经过和开发详细沟通后发现,他们的实现逻辑是这样的:
程序在启动时,把启动时间记录在一个本地文件中,程序退出时会从本地文件中读取启动时间,并且进行 http 打点。
知道这个逻辑后,我们可以补充相应的逻辑层测试点如下:
和前面的测试点对比,能看出来差异吧?第一种测试点只关注业务,第二种测试点同时也关注了实现。
也许有人会说我给的例子不恰当,没有人会这么去实现,嗯,意会下就行了,主要的意思是,针对业务的表示层和针对实现的逻辑层,我们都应该有对应角度的测试点去覆盖,这也是我们早前说的测试深度
,至于深度要挖到什么程度,请根据自己项目特点合理判断。
从例子中我们还能看出来前面说的,逻辑层的测试点,实际的用例执行步骤和表示层是一样的,只是关注点不同,我们去区分表示层和逻辑层,只是借助这个概念去让我们知道,需要去关注哪些内容,所以在某些情况下,不要过分纠结一个测试点属于表示层还是逻辑层,只要能满足预期的覆盖度就行了。
2.验证没有少做事,也要验证没有做多余的事
继续上面的例子,不管是表示层还是逻辑层的测试点,绝大部分都是在验证程序没有少做事,这是我们主要的测试目的之一。
我们的另一个测试目的是「验证程序没有做多余的事」,比如我们看到逻辑层验证有一个测试点是「验证本地文件被占用时,程序直接返回不做任何处理」,这属于异常处理的一种,但是需求中并没有明确要求应该怎么做,所以可能会有开发实现为「文件被占用,就换个文件名创建」,反正不会抛出异常就可以。
碰到这种情况,一定记得要同开发、产品三方沟通确认预期。
关于这点,还有一个类似的情况,比如在程序的设置项中勾选一项设置,理论上程序只需要调用修改注册表值的函数,把对应注册表值做个修改即可,但是有些开发图省事,打开设置时,读取一下所有设置项的值,关闭设置时,按照当前设置值全部重写一遍。
从表示层看功能符合预期,从逻辑层看没有少做事,但是增加了不必要的开销,做了多余的事。
3.分类是为了条理更清晰,不要在分类标准的选取上纠结
上面例子中的逻辑层测试点,我们写了 10 条,放在一个节点上已经显得有点多,这时候就可以把测试点做个分类。
比如下图,是我按照本地文件的写入和读取分成两类:
这样看起来是不是清晰了很多?主要是测试目的会清晰,当然有同学会问,我换个分类标准行不行?必须行呀,如下图,是我按照程序启动和退出也分成了两类:
看,没啥区别,分类是为了让众多测试点更清晰易懂,最后面的测试点才是重点
,针对本次测试点,甚至还可以按文件操作和打点操作分,还可以按正常情况和异常情况分等等。
总之,不要在分类标准选取上纠结,原则就是提取合适的公共属性,让整个测试点看起来更清晰即可。
4.维持平衡,不要钻牛角尖
不要在表示层和逻辑层的划分上钻牛角尖,你完全可以取一个自己喜欢的名称,也完全可以不区分这个层级,只要有办法保证测试点的覆盖度即可。
不要在逻辑深度的挖掘上钻牛角尖,理论上我们能挖多深就挖多深,发现深层次的实现问题,肯定更有成就感,但一定要基于项目的现状和需要去平衡投入产出比。
不要在需求/逻辑/实现是否对错上钻牛角尖,一切都是为了产品服务,测试目的当然也是,所以适合的就是最好的。
不要在分类条件的选取上钻牛角尖,如果选不出来概括性完美的分类标准,也可以不分类,或者选一个能概括大部分测试点的分类条件即可,时间要花在刀刃上。
以上,我基于目前实践的现状,总结了思维导图写测试点的额外关注点,不知道你是否认同,或者有啥额外补充。欢迎留言说说你的想法。
当然,如果你认可我的观点,请帮忙转发 + 点个「在看」让更多人看到,谢谢。
版权申明:
此文首发于公众号「sylan215」,作者:sylan215
无需授权,即可转载,转载请保留此文完整信息 。