【原创】思维导图写测试用例的再补充

关于思维导图写测试点的方法，之前已经写了三篇文章了，测试点的写法上基本上已经说的比较清晰，但是落地执行时还是会有一些小问题。

没看过之前文章的，请按顺序回顾下哈：
《思维导图编写测试用例的两种格式》
《用思维导图写测试点的几点说明》
《思维导图写测试点的额外补充》

下面我针对这几个小问题再做个补充说明。

1、要提前构思好整体分类再动手写测试点

拿到需求后，不要一上来就直接上手开始咔咔的写用例，先要整体了解下产品需求和实现逻辑。

然后根据了解的情况，决定每一个层级的分类标准，比如是按照质量模型的角度进行分类呢，还是按照修改点进行分类呢，前面层级的划分标准，直接决定了接下来子节点的划分标准。

从我自己实践的过程来看，如果一开始选择的分类标准不合理，过程中再去尝试修改，就会更纠结，因为会发现横竖都是对的，但又有点不合理，最后就成了改也不是不改也不是了。

借用老祖宗的一句话就是，一定要「三思而后行」。

2、先写表示层用例，再逐步补齐逻辑层

这么说可能有点绝对，我主要想说的是，一定要先在一个维度上保证覆盖率，然后在考虑增加覆盖的广度和深度。

或者换个说法是，先瞅准一个目标达成了，再考虑做的更完美。

之所以这么建议，是因为碰到过这么几种情况。

第一种是写表示层的时候，会把逻辑层一起带上，然后就傻傻分不清自己这个测试点的测试目的了，比如你看：

上面表示层和逻辑层混合的情况，看起来测试点也是没毛病的对吧，但是仔细想想这个测试点的测试目的到底是啥？是为了测试弹框功能和注册表值的对应关系么？这不是我们要测试的内容吧，我们真正要测试的应该是下面一种划分方式。

下面这个方式，我们表示层的验证就关注表示层的操作和操作结果就行，逻辑层的验证就关注操作和对应逻辑的对应关系即可，如果非要按上面这种方式去写测试点，应该是修改为「验证注册表start=1时，走弹框处理逻辑」和「验证注册表start=0时，走不弹框处理逻辑」，也就是说，逻辑关联的验证，最好都是通过逻辑层进行体现，不要把他们混杂在一起，这也是开发思维和测试思维的一个区别点。

第二种情况是，写测试点的时候没有考虑测试目的，而是考虑如何方便执行，导致测试目的不单纯。

比如上面用例中有一条「验证设置开启时，弹框正常」，其实实际逻辑中，弹框前还会有很多的其他逻辑判断，如果不知道背景逻辑，这条用例根本没法执行，比如弹框要满足从来没弹出过、用户没有在免打搅模式、如果之前弹出过那么需要间隔一个月，这些都是这个弹框的条件，要不要写到测试点里面呢？

如果写进去，就会变成这样了「验证设置开启时，从来没有弹框的用户会正常弹框」，看起来是不是也没问题，但是发现没？这个测试点到底是为了测试「设置」的功能还是测试「从来没有弹框」这个前提条件呢？

所以我的建议是不要写进去，如果真的害怕执行的人员不清楚，一个方法就是用例评审时进行深度的逻辑同步，另一个方法就是把详细测试步骤写到备注中，不然这样的效果就是写着写着就发现，怎么很多测试点都写成一样的了。

3、测试点是测试的指导，而不仅仅是用来做无脑执行

单独提出这个问题是因为在一次用例评审时，我们讨论到一个问题：「拿来用例开始执行前，我们是先整体看一下需求、逻辑和用例情况，还是直接从上到下开始执行？」

想一想，你是怎么做的？

如果是我，我肯定会先整体看一下是否有问题，并且把自己的疑问都解决了才继续下去，这样执行的效率和效果才是最优的，这样才能在执行过程中加入自己的思考从而顺便进行一些探索性测试。

如果是拿来用例直接无脑执行，那么目前这个测试点的写法确实无法满足要求，不要说写的是测试点，就算是简要的测试步骤描述，也不一定能保证顺利执行的，而且执行的过程中经常会发现，怎么好多测试点的执行步骤其实是一样的，只是在不同位置的测试目的不同而已，对，这是正常情况。

测试点一定是我们测试的指导，而不仅仅是作为测试执行阶段的依据这么简单看待。

以上，经过这一段时间的实践，我又总结了一些可能出现问题的点，并加以解释，希望对你有所帮助，如果对这些地方的理解有不同意见或建议，欢迎留言告诉我。

当然，如果你认可我的观点，请帮忙转发 + 点个「在看」让更多人看到，谢谢。

本文首发于公众号「sylan215」，十年测试老司机的原创干货，关注我，一起涨姿势！

【原创】思维导图写测试用例的再补充相关推荐

【原创】思维导图写测试点的额外补充
经过近一个月的反复宣讲,以及通过用例评审反复和大家沟通意见建议,我们用思维导图写测试点的格式已经基本固定了下来. 基础的内容,请回看前两篇文章: <思维导图编写测试用例的两种格式> < ...
【原创】用思维导图写测试点的几点说明
之前在文章<思维导图编写测试用例的两种格式>中,提到思维导图写用例的格式,这里澄清下,这里说的测试用例准确的说应该叫测试点,亦或者说是测试用例标题,因为测试用例本来就包含了用例标题.前置条 ...
思维导图写测试点的几点说明
1.区分测试点和用例步骤我们来看个例子: 上图是同一个测试目的的两种不同描述. 很显然,上面一种描述,我们一眼就可以看出来测试目的是验证「设为星标」的功能,第二种描述,当然也能知道目的,但是太多的操 ...
使用思维导图编写测试用例
场景:手机号登录设计工具:表格.思维导图等价类划分法包括了边界值分析法: 1.手机号11位数字是有效等价类 2.手机号10位/12位数字是无效等价类,且10.12是边界值使用表格编写测试用例使 ...
用思维导图写小说的提纲
写好一本小说需要考虑的问题非常多,所以借助思维导图进行梳理是非常便利的方式.一部小说是由多重要素组合而成,从不同维度出发所要绘制的导图也大不一样. ⭐写提纲的好处在凯蒂·维兰德<小说的骨架&g ...
全网最全Linux学习路线！十一张原创思维导图涵盖日常全部命令（干货）
测试.后端.开发.大数据分析&挖掘.AI算法.产品都能无压力掌握的linux重点知识归纳,图形化系统展现要点,你值得拥有! 无论是测试.后端.开发的同学,还是数据分析.挖掘.算法的大佬,甚至是 ...
XMind2TestCase思维导图测试用例转Excel使用方法
很多测试工程师习惯于用思维导图写测试用例,结构会比较清晰,但是我们通常把思维导图的用例整理至excel或者导入其他工具如禅道,testlink,tapd来执行用例或存档,如果再逐条把思维导图转为exc ...
写小说如何运用思维导图
在写小说中运用思维导图一般是用来绘制小说提纲,当然也不止绘制提纲这一个作用,比如安排小说写作的时间进程.搜集写作过程中的小灵感.头脑风暴.情节推衍等等.既然有这么多运用的方式,那小M就简单介绍一下,万 ...
python程序设计思维导图_程序设计思维导图
###sample: https://www.bbsmax.com/A/A7zgx2ZoJ4/ 使用python+django+twistd 开发自己的操作和维护系统的一个 yxwkaifa 2015 ...

【原创】思维导图写测试用例的再补充

【原创】思维导图写测试用例的再补充相关推荐

最新文章

热门文章