qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

如何使用思维导图更高效的设计软件测试用例?

 有时候项目很紧,我们没有时间来把用例都设计好并写到用例管理系统中,使用思维导图是一种比较好的方式,而且越来越受到人们的追捧。但是在实施过 程中,可能会有一些问题,比如A同学设计的用例只有他能看明白,B同学就很难看懂,这也不难理解,因为它就像人的大脑,他的思维是独一无二的,脑子里怎么 想,这个就是怎么设计的。但是既然是用例,我们就需要保证其可读性及重用性,便于评审以及给他人复用。今天我就把自己工作中的一些经验分享出来给大家。

  使用思维导图设计用例的注意事项:

  1、分级:

  第一级:按测试的类型划分,如功能测试,交互测试,性能测试(可以是如懒加载,异步加载等内容涉及到性能改进的),异常测试(也可以放入功能测试下)等。对于功能涉及面广的一定要严格区分出来,并且需要特别重视异常测试的内容;

  第二级:按照需求的测试点划分,一般可以划分为多个测试点;

  第三级:如果测试点可以细分到测试子项,就把测试子项作为第三级,否则直接在测试点后面写用例。

  2、对于功能测试下的分级:

  可以按照组件,功能流程,数据层面,UI层面及异常情况等来进行分级。

  3、对于具体测试用例的编写,注意逻辑性及条理性:

  1)如果好几条用例是在某个条件下完成的,是属于控制和被控制的关系,则可以放入该条件的节点下;

  2)如果用例是属于某个功能点下的,属于包含与被包含的关系,那也放到它下面;

  3)如果用例之间执行有顺序要求,则标记好序号1,2,3;

  4)保证同级之间的用例是相互平行,互不影响的,如果有相互间的影响,那肯定得有层级关系;

  5)书写用例时每条最好是说明一件事情,而且得出的是肯定或否定的结论,不要出现“是否,有可能,可否”等等 字样,结果必须确定;

  6)用例中最好不要出现操作步骤,这个属于具体用例中的内容,但如果不多可以使用括弧备注。

  总之,思维导图是指导我们的思维过程,但是所有的思维发散都要有一个模型,在模型基础上进行发散思维,这样子,我们思考时候才是有条理的,进行测试时也才有条理性,没有条理性的用例迟早会出乱子,有遗漏。

  我画了个示例图。以简单的邮件订阅为例:

  以这张图来说,会比较有条理性,即使给其他人看也能明白,当然,这里面对邮箱格式的测试,其实不用这么啰嗦,可以直接对开发人员使用的正则表达式进行测试即可,关于正则表达式如何帮助我们更高效的测试,不是本文的重点,以后可以找个专题来说。

版权声明:本文出自 zzzmmmkkk 的51Testing软件测试博客:http://www.51testing.com/?258885

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

posted on 2013-05-24 11:52 顺其自然EVO 阅读(897) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年5月>
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜