Xmind写测试点 – 吉提 – 博客园 -Mikel

Xmind写测试点 – 吉提 – 博客园

2020年5月26日 分类: C#

来源: Xmind写测试点 – 吉提 – 博客园

引入:

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

之前写过一篇《测试用例-20问20答》,没看过的朋友戳这里:,其中就有写测试点的前提条件,我摘录出来:

  1. 测试人员少而上线时间紧;
  2. 紧急的小型任务;
  3. 需求频繁变化,测试用例的更新速度永远跟不上需求的变化速度,每天都在改用例;
  4. 团队所有测试人员技能均衡,对业务也都熟,测试点能充分覆盖需求。

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

目录:

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

二.如何写测试点

三.几个注意事项


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

 

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

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

 

  • 第一种格式,一个分支上所有节点串在一起,才是一条完整的测试点,前面的节点是后面节点的前置条件。
  • 第二种格式,按照测试维度划分,逐级细化,测试点越来越明晰,每个分支的最后一个节点就是一个完整的测试点。

 

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

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

 

 

二.如何写测试点(按照上述第二种格式-分类)

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

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

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

 

 

三.几个注意事项

1.写测试点的前提

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

 

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

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

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


标签:
本文的评论功能被关闭了.
备案信息冀ICP 0007948