之前在文章《思维导图编写测试用例的两种格式》中，提到思维导图写用例的格式，这里澄清下，这里说的测试用例准确的说应该叫测试点，亦或者说是测试用例标题，因为测试用例本来就包含了用例标题、前置条件和测试步骤等内容。

今天的几点说明，都是和这个概念有关的，名称不同，代表的意义也不同。

言归正传，我们来一起看看这次要说明的都有哪些点。

1、区分测试点和用例步骤

我们来看个例子：

上图是同一个测试目的的两种不同描述。

很显然，上面一种描述，我们一眼就可以看出来测试目的是验证「设为星标」的功能，第二种描述，当然也能知道目的，但是太多的操作步骤会让可读性大打折扣。

第一种描述更接近我们说的测试点的概念，第二种描述则是把测试用例的相关内容全部柔和到一句话里进行描述，如果是这样的话，使用思维导图和 Excel 就没什么区别了，反而 Excel 做了不同部分的拆分看起来更清晰。

当然，使用第二种方式，有一个好处是可以按照描述无脑操作，对新人比较友好，同样的，对其他人来说就显得目的繁杂且不清晰，所以针对这个测试目的更推荐第一种描述方式，如果觉得用例执行过程中会不知道如何操作，可以把操作步骤放到节点备注里面。

记住，尽量不要把用例步骤写到测试点里面，尽量突出测试目的。

2、区分条件和分类

我们继续看例子：

上图可以看出，方式 1 和方式 2 都进行了分类划分，但是分类的标准不一样，方式 1 是用不同的入口作为分类，方式 2 是做了提炼，把分类标准写明就是「不同入口」。

我更倾向于第二种方式，第一种分类方式，其实还是条件式分类，后面用例的执行，离不开前面节点的描述/前置操作，如果去掉前面的条件，测试目的会完全变样。

本次这个例子逻辑简单，可能体会不到两种方式的明显差异，实际上，如果条件比较多，按方式 1 这么分类下去，最终就是会变成我在《思维导图编写测试用例的两种格式》中提到第一种条件式划分，这和我们的初衷是不符的。

总的来说，条件属于前置操作，是常规测试用例格式中的一部分，但是不建议作为测试点的分类标准，分类是为了让测试点看起来条理更清晰，所以分类标准最好是经过提炼过的、概括性的描述，也就是上图方式 2 的方式；

当然，在某些逻辑比较简单的地方，这个界线会模棱两可，那就继续依据实用为主的原则来选定分类条件就好。

3、区分操作关联和逻辑关联

我们先看个需求描述：

有一个子母复选框设置项：
母复选框不勾选时，对应功能全部关闭；
母复选框勾选时，需要参考子复选框状态，子复选框勾选时，对应功能开启，子复选框不勾选时，对应功能关闭；

下面是针对这个描述用两种不同方式写出来的测试点：

可以看出来，两种方式明显的差异就是验证子复选框状态时，是否要在测试点描述中带上母复选框的状态描述，我的建议是不带，推荐使用方式 2。

这是一条表示层的用例，也就是说必须通过用户场景操作才能完成用例执行，那么要完成子复选框的勾选或不勾选，肯定要先勾选上母复选框，也就是说这是个默认的前提，而且针对本次测试点，这个操作步骤不是测试目的的一部分，所以我觉得可以省略，当然，可以放到节点备注里面作为测试步骤进行说明。

如果这是一条逻辑层的测试点，比如是通过注册表值进行验证的话，则需要区别对待，因为逻辑层的条件是可以模拟的，就是说可以模拟母复选框对应注册表值为不勾选，同时设置子复选框的状态注册表值为勾选，测试目的可以达到，但是否有必要这样测试就另当别论了。

所以逻辑层验证和表示层验证要区别对待，针对有操作关联的表示层验证，可以省略非必要的操作描述，针对有逻辑关联的逻辑层验证，则需要明确测试目的后再确定相关关联操作是否能省略。

4、写测试点的前提

既然我们说是写测试点，而不是详细的测试用例，那么我们就有一个隐含的前提，就是写测试点和执行测试的人，对需求要非常的清楚，如果忽略这个前提，我们写出来的测试点很清晰，但是可读性会很差。

在项目有参与人只是纯执行角色时，可以通过补充测试点备注的方式来完善对测试点的说明，根据参与角色能力的不同，完善的详细程度可以针对性调整，当然，尽可能让参与项目的人清晰的了解需求和测试目的是最好的。

以上，在上次的基础上，对思维导图写测试点的方式做了一些注意事项的说明，不知道你在执行的过程中是否碰到了类似的这些问题，是如何解决的呢？欢迎给我留言说说你的想法。

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