考试首页 | 考试用书 | 培训课程 | 模拟考场 | 考试论坛  
全国  |             |          |          |          |          |         
  当前位置:软件水平 > 心得技巧 > 文章内容
  

计算机软考编写测试用例的一点小结软件测试

 [ 2013年5月1日 ] 【
首先我们写用例的依据有几种,其中之一就是需求设计及相关文档,有人说UC有很多问题,UC不可靠,我个人觉得这种说法是不对的,虽然UC有问题,但是我们还要依靠UC,总不能说今天中午的午饭不好吃,我们自此不再吃午饭吧。同样的道理,UC有问题,我们要想办法解决这些问题,而不是因噎废食。

  同样,一个好的UC不仅仅节约测试的时间,也节约开发人员的时间,一个书写简单的UC虽然编写的时候节约时间,但是在以后的过程中需要不停的修改,测试也需要为一些小的问题不停的找开发人员确认,你烦我烦大家都很烦。一个好的UC让大家都一劳永逸。

  其次用例的编写还依赖于与开发组交流对需求的理解。这点就要求开发和测试之间建立良好的沟通,即使CHECK发现的各种问题。有问题及时解决,及早避免南辕北辙离题千里的尴尬境地。

  最后我们写用例的依据还来自原型界面,以此次用例PK为例,我们不可能为了进行PK让开发那边再重新编写用例,而且我们对于发布宝贝的过程都是很熟悉的,再重新写UC显然是不切实际的。

  现在,我们有了编写用例的依据,那么先就需要做好用例设计,在我们公司用的是流程图,让UC上的文字更加直观。但是不仅仅是将这些主流程文字搬上去就可以了,我开始画设计图的时候每次注释的时候直接贴上一大块文字,后来发现,其实这个只是把UC上的文字挪个窝而已。

  对于一些输入项,比如说是必填项完全可以用判断符号来判断是否填写,总比旁边的注释框中的必须输入四个字直观得多。另外,画设计图的时候是详细了解流程的时候,如果设计图画的流程不正确,即使你纠缠于细节,每个边界值设定都非常正确。只能说当你发现你错误的时候,会很很很抓狂滴~~~

  最后到了写设计用例的时间了,有人说,写设计用例是很痛苦的个过程,确实有点,很长一段时间总是纠结在长度类型,边界值,和特殊符号中……但是,我不知道是不是支持这种方法,我开始写用例的时候是老老实实的一个个的写的,然后就发现有些用例是有共通之处的,比如说对于名称的校验,无非是长度,类型,在各种名称的校验中都是换汤不换药的,所有建立一个模板总汇,直接COPY就好了,当然记得COPY后要修改下。

  我发现用模板编写的效果除了效率变高外,还可以保证格式上的一致。格式一致的好处就不多说了,至少看起了也好看不是。

  但是我担心的一个问题是过于依赖于模板,导致有些细节的地方没有挖掘出来,毕竟一个个编写用例的同时,我们也许会偶尔灵感一现。于是我们就有另一个方法,先搭建整体的框架,先整体考虑出那些框框条条的内容,最后的过程就是填空啦。

  其实说来简单,在编写用例的过程中总会遇到很多的问题,比如说需求变更,但是也许唯一不变的就是变化,如果变更了这么办?拥抱变化,跟着变更呗,但是,这里有个问题是:测试组最无奈的事情是——开发人员变更了需求,但是测试这里却不知道。如果再给我一个机会,我一定要在项目开始之前就和测试组约定好!

本文纠错】【告诉好友】【打印此文】【返回顶部
将考试通添加到收藏夹 | 每次上网自动访问考试通 | 复制本页地址,传给QQ/MSN上的好友 | 申请链接 | 意见留言 TOP
关于本站  网站声明  广告服务  联系方式  站内导航  考试论坛
Copyright © 2007-2013 中华考试网(Examw.com) All Rights Reserved