Mikel
引入：
既然我们这篇要说《Xmind写测试点》，那么先来回顾一下，什么情况下才写测试点，而不写测试用例。
之前写过一篇《测试用例-20问20答》，没看过的朋友戳这里：，其中就有写测试点的前提条件，我摘录出来：
- 测试人员少而上线时间紧；
- 紧急的小型任务；
- 需求频繁变化，测试用例的更新速度永远跟不上需求的变化速度，每天都在改用例；
- 团队所有测试人员技能均衡，对业务也都熟，测试点能充分覆盖需求。
如果你测试的业务符合以上4点中任意一项，那么，用Xmind写测试点吧。
目录：
一．Xmind写测试点的两种格式
二．如何写测试点
三．几个注意事项
一．Xmind写测试点的两种格式
Xmind，大家一般叫它脑图。脑图用来拆解需求，一层一层往下写，的确是很给力，但是相比Excel，用它来写测试点的话，就不太容易下手了。用Excel写测试用例，格式已经规定好了：用例编号、功能模块名称、前置条件、操作步骤等等。但是用Xmind写测试点，正因为没人规定怎么写，所以才不好落地。所幸经过n多Tester的实践，最终确定出两种风格。
Eg：给产品添加“敏感词检测”的功能，多个敏感词用英文逗号隔开。系统检测到敏感词会弹窗提示并建议修改。
- 第一种格式，一个分支上所有节点串在一起，才是一条完整的测试点，前面的节点是后面节点的前置条件。
- 第二种格式，按照测试维度划分，逐级细化，测试点越来越明晰，每个分支的最后一个节点就是一个完整的测试点。
推荐使用第二种格式。这种格式的用例，在做用例评审时，方便确认需求覆盖率，而且对于用例执行者比较友好，执行者可以只关注用例的最后一个节点，按照指定策略执行就行了，如果是第一种格式，需要每次都从头看到尾，很容易出错。
注意：分类是为了让众多测试点更清晰易懂，不要在分类标准的选取上纠结，最后面的测试点才是重点。不要在分类条件的选取上钻牛角尖，如果选不出来概括性完美的分类标准，也可以不分类，或者选一个能概括大部分测试点的分类条件即可，时间要花在刀刃上。
二．如何写测试点（按照上述第二种格式-分类）
1.尽量不要把用例步骤写到测试点里面，要突出测试目的。操作步骤可以放在备注里。
2.要提前构思好整体分类再动手写测试点
拿到需求后，先要整体了解产品需求和实现逻辑，然后决定每一个层级的分类标准，比如是按照质量模型的角度进行分类，或者按照修改点进行分类，前面层级的划分标准，直接决定了接下来子节点的划分标准。
三.几个注意事项
1.写测试点的前提
写用例和执行用例的人，对需求要非常的清楚，如果忽略这个前提，我们写出来的测试点很清晰，但是可读性会很差。在项目有参与人只是纯执行角色时，可以通过补充测试点备注的方式来完善对测试点的说明。
2.测试点是测试的指导，而不是用来做无脑执行
如果直接无脑执行，那么目前用分类写出的测试点确实无法顺利执行，就算加上简要的测试步骤描述，执行的过程中也会经常发现问题，怎么好多测试点的执行步骤其实是一样的，只是在不同位置的测试目的不同而已，对，这是正常情况。
测试点一定是我们测试的指导，而不仅仅是作为测试执行阶段的依据这么简单看待。
