其他分享
首页 > 其他分享> > 思维导图写测试点的额外补充

思维导图写测试点的额外补充

作者:互联网

 

经过近一个月的反复宣讲,以及通过用例评审反复和大家沟通意见建议,我们用思维导图写测试点的格式已经基本固定了下来。

基础的内容,请回看前两篇文章: 

思维导图编写测试用例的两种格式》 

用思维导图写测试点的几点说明

今天是在这些内容基础上的再补充。

 

1.表示层和逻辑层测试目的的区分

表示层测试点的测试目的应该是针对业务逻辑的覆盖,所以表示层测试点的描述,可能会被误以为是需求的描述,其实不一样,需求只是描述业务的展现形式,测试点是要验证产品满足了要求的展现形式,并且在验证时,我们把需求进行了颗粒度的拆分,逐点进行验证。

逻辑层测试点的测试目的应该是针对实现逻辑的覆盖,所以逻辑层测试点的描述,都应该是逻辑实现本身,只是某些情况,无法通过针对性的逻辑结果来确认测试结果,我们就会用表示层的现象来间接证明,一般不建议这么做,但如果只能这样,那就特殊说明下,毕竟针对同一个业务逻辑,表示层和逻辑层测试点的操作步骤几乎是一样的,只是关注点不同。

这么说起来比较抽象,我还是拿个例子来说吧。

需求:有一个程序,在自己退出时,会把自己的启动时间通过 http 打点上报给服务端。

针对这个需求,如果是表示层的用例,只需要下面两条就够了: 

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

但是,经过和开发详细沟通后发现,他们的实现逻辑是这样的:

程序在启动时,把启动时间记录在一个本地文件中,程序退出时会从本地文件中读取启动时间,并且进行 http 打点。

知道这个逻辑后,我们可以补充相应的逻辑层测试点如下: 

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

和前面的测试点对比,能看出来差异吧?第一种测试点只关注业务,第二种测试点同时也关注了实现。

也许有人会说我给的例子不恰当,没有人会这么去实现,嗯,意会下就行了,主要的意思是,针对业务的表示层和针对实现的逻辑层,我们都应该有对应角度的测试点去覆盖,这也是我们早前说的测试深度,至于深度要挖到什么程度,请根据自己项目特点合理判断。

从例子中我们还能看出来前面说的,逻辑层的测试点,实际的用例执行步骤和表示层是一样的,只是关注点不同,我们去区分表示层和逻辑层,只是借助这个概念去让我们知道,需要去关注哪些内容,所以在某些情况下,不要过分纠结一个测试点属于表示层还是逻辑层,只要能满足预期的覆盖度就行了。

 

2.验证没有少做事,也要验证没有做多余的事

继续上面的例子,不管是表示层还是逻辑层的测试点,绝大部分都是在验证程序没有少做事,这是我们主要的测试目的之一。

我们的另一个测试目的是「验证程序没有做多余的事」,比如我们看到逻辑层验证有一个测试点是「验证本地文件被占用时,程序直接返回不做任何处理」,这属于异常处理的一种,但是需求中并没有明确要求应该怎么做,所以可能会有开发实现为「文件被占用,就换个文件名创建」,反正不会抛出异常就可以。

碰到这种情况,一定记得要同开发、产品三方沟通确认预期。

关于这点,还有一个类似的情况,比如在程序的设置项中勾选一项设置,理论上程序只需要调用修改注册表值的函数,把对应注册表值做个修改即可,但是有些开发图省事,打开设置时,读取一下所有设置项的值,关闭设置时,按照当前设置值全部重写一遍。

从表示层看功能符合预期,从逻辑层看没有少做事,但是增加了不必要的开销,做了多余的事。

 

3.分类是为了条理更清晰,不要在分类标准的选取上纠结

上面例子中的逻辑层测试点,我们写了 10 条,放在一个节点上已经显得有点多,这时候就可以把测试点做个分类。

比如下图,是我按照本地文件的写入和读取分成两类: 

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

这样看起来是不是清晰了很多?主要是测试目的会清晰,当然有同学会问,我换个分类标准行不行?必须行呀,如下图,是我按照程序启动和退出也分成了两类: 

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

看,没啥区别,分类是为了让众多测试点更清晰易懂,最后面的测试点才是重点,针对本次测试点,甚至还可以按文件操作和打点操作分,还可以按正常情况和异常情况分等等。

总之,不要在分类标准选取上纠结,原则就是提取合适的公共属性,让整个测试点看起来更清晰即可。

 

4.维持平衡,不要钻牛角尖

不要在表示层和逻辑层的划分上钻牛角尖,你完全可以取一个自己喜欢的名称,也完全可以不区分这个层级,只要有办法保证测试点的覆盖度即可。

不要在逻辑深度的挖掘上钻牛角尖,理论上我们能挖多深就挖多深,发现深层次的实现问题,肯定更有成就感,但一定要基于项目的现状和需要去平衡投入产出比。

不要在需求/逻辑/实现是否对错上钻牛角尖,一切都是为了产品服务,测试目的当然也是,所以适合的就是最好的。

不要在分类条件的选取上钻牛角尖,如果选不出来概括性完美的分类标准,也可以不分类,或者选一个能概括大部分测试点的分类条件即可,时间要花在刀刃上。

 

 

以上,我基于目前实践的现状,总结了思维导图写测试点的额外关注点,不知道你是否认同,或者有啥额外补充。欢迎留言说说你的想法。

标签:逻辑,额外,测试点,验证,导图,表示层,测试,分类
来源: https://blog.51cto.com/sylan215/2919744