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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

想一想，你是怎么做的？

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

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

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

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

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