阿里一线大牛花7天肝出的这份620页 “Xmind写测试点” 太清晰了

Posted 2021-08-07 程序员二黑

引入：

既然我们这篇要说《Xmind写测试点》，那么先来回顾一下，什么情况下才写测试点，而不写测试用例。

其中就有写测试点的前提条件：

测试人员少而上线时间紧；

紧急的小型任务；

需求频繁变化，测试用例的更新速度永远跟不上需求的变化速度，每天都在改用例；

团队所有测试人员技能均衡，对业务也都熟，测试点能充分覆盖需求。

如果你测试的业务符合以上4点中任意一项，那么，用Xmind写测试点吧。

一、Xmind写测试点的两种格式

Xmind，大家一般叫它脑图。脑图用来拆解需求，一层一层往下写，的确是很给力，但是相比Excel，用它来写测试点的话，就不太容易下手了。用Excel写测试用例，格式已经规定好了：用例编号、功能模块名称、前置条件、操作步骤等等。但是用Xmind写测试点，正因为没人规定怎么写，所以才不好落地。所幸经过n多Tester的实践，最终确定出两种风格。

Eg：给产品添加“敏感词检测”的功能，多个敏感词用英文逗号隔开。系统检测到敏感词会弹窗提示并建议修改。

第一种格式，一个分支上所有节点串在一起，才是一条完整的测试点，前面的节点是后面节点的前置条件。

第二种格式，按照测试维度划分，逐级细化，测试点越来越明晰，每个分支的最后一个节点就是一个完整的测试点。

推荐使用第二种格式。这种格式的用例，在做用例评审时，方便确认需求覆盖率，而且对于用例执行者比较友好，执行者可以只关注用例的最后一个节点，按照指定策略执行就行了，如果是第一种格式，需要每次都从头看到尾，很容易出错。

注意：分类是为了让众多测试点更清晰易懂，不要在分类标准的选取上纠结，最后面的测试点才是重点。不要在分类条件的选取上钻牛角尖，如果选不出来概括性完美的分类标准，也可以不分类，或者选一个能概括大部分测试点的分类条件即可，时间要花在刀刃上。

二、如何写测试点（按照上述第二种格式-分类）

1.尽量不要把用例步骤写到测试点里面，要突出测试目的。操作步骤可以放在备注里。

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

拿到需求后，先要整体了解产品需求和实现逻辑，然后决定每一个层级的分类标准，比如是按照质量模型的角度进行分类，或者按照修改点进行分类，前面层级的划分标准，直接决定了接下来子节点的划分标准。

三、几个注意事项

1.写测试点的前提

写用例和执行用例的人，对需求要非常的清楚，如果忽略这个前提，我们写出来的测试点很清晰，但是可读性会很差。在项目有参与人只是纯执行角色时，可以通过补充测试点备注的方式来完善对测试点的说明。

2.测试点是测试的指导，而不是用来做无脑执行

如果直接无脑执行，那么目前用分类写出的测试点确实无法顺利执行，就算加上简要的测试步骤描述，执行的过程中也会经常发现问题，怎么好多测试点的执行步骤其实是一样的，只是在不同位置的测试目的不同而已，对，这是正常情况。

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

最后为方便大家学习测试，特意给大家准备了一份13G的超实用干货学习资源，涉及的内容非常全面。

包括，软件学习路线图，50多天的上课视频、16个突击实战项目，80余个软件测试用软件，37份测试文档，70个软件测试相关问题，40篇测试经验级文章，上千份测试真题分享，还有2021软件测试面试宝典，还有软件测试求职的各类精选简历，希望对大家有所帮助……

关注我公众号：【程序员二黑】即可获取这份资料了！

推荐阅读

高薪程序员也躲不过35岁这一关…当能力与年龄脱节，我们该如何自救

大学毕业开始销售…不甘于现状，转行测试的自救之路

从销冠到失业，最后选择软件测试，回头看看这段路，我很幸运！