首页 考试吧论坛 Exam8视线 考试商城 网络课程 模拟考试 考友录 实用文档 求职招聘 论文下载 | ||
2011中考 | 2011高考 | 2012考研 | 考研培训 | 在职研 | 自学考试 | 成人高考 | 法律硕士 | MBA考试 MPA考试 | 中科院 |
||
四六级 | 职称英语 | 商务英语 | 公共英语 | 托福 | 雅思 | 专四专八 | 口译笔译 | 博思 | GRE GMAT 新概念英语 | 成人英语三级 | 申硕英语 | 攻硕英语 | 职称日语 | 日语学习 | 法语 | 德语 | 韩语 |
||
计算机等级考试 | 软件水平考试 | 职称计算机 | 微软认证 | 思科认证 | Oracle认证 | Linux认证 华为认证 | Java认证 |
||
公务员 | 报关员 | 银行从业资格 | 证券从业资格 | 期货从业资格 | 司法考试 | 法律顾问 | 导游资格 报检员 | 教师资格 | 社会工作者 | 外销员 | 国际商务师 | 跟单员 | 单证员 | 物流师 | 价格鉴证师 人力资源 | 管理咨询师考试 | 秘书资格 | 心理咨询师考试 | 出版专业资格 | 广告师职业水平 驾驶员 | 网络编辑 |
||
卫生资格 | 执业医师 | 执业药师 | 执业护士 | ||
会计从业资格考试(会计证) | 经济师 | 会计职称 | 注册会计师 | 审计师 | 注册税务师 注册资产评估师 | 高级会计师 | ACCA | 统计师 | 精算师 | 理财规划师 | 国际内审师 |
||
一级建造师 | 二级建造师 | 造价工程师 | 造价员 | 咨询工程师 | 监理工程师 | 安全工程师 质量工程师 | 物业管理师 | 招标师 | 结构工程师 | 建筑师 | 房地产估价师 | 土地估价师 | 岩土师 设备监理师 | 房地产经纪人 | 投资项目管理师 | 土地登记代理人 | 环境影响评价师 | 环保工程师 城市规划师 | 公路监理师 | 公路造价师 | 安全评价师 | 电气工程师 | 注册测绘师 | 注册计量师 |
||
缤纷校园 | 实用文档 | 英语学习 | 作文大全 | 求职招聘 | 论文下载 | 访谈 | 游戏 |
编写测试用例的一点小结 软件测试
首先我们写用例的依据有几种,其中之一就是需求设计及相关文档,有人说UC有很多问题,UC不可靠,我个人觉得这种说法是不对的,虽然UC有问题,但是我们还要依靠UC,总不能说今天中午的午饭不好吃,我们自此不再吃午饭吧。同样的道理,UC有问题,我们要想办法解决这些问题,而不是因噎废食。
同样,一个好的UC不仅仅节约测试的时间,也节约开发人员的时间,一个书写简单的UC虽然编写的时候节约时间,但是在以后的过程中需要不停的修改,测试也需要为一些小的问题不停的找开发人员确认,你烦我烦大家都很烦。一个好的UC让大家都一劳永逸。
其次用例的编写还依赖于与开发组交流对需求的理解。这点就要求开发和测试之间建立良好的沟通,即使CHECK发现的各种问题。有问题及时解决,及早避免南辕北辙离题千里的尴尬境地。
最后我们写用例的依据还来自原型界面,以此次用例PK为例,我们不可能为了进行PK让开发那边再重新编写用例,而且我们对于发布宝贝的过程都是很熟悉的,再重新写UC显然是不切实际的。
现在,我们有了编写用例的依据,那么先就需要做好用例设计,在我们公司用的是流程图,让UC上的文字更加直观。但是不仅仅是将这些主流程文字搬上去就可以了,我开始画设计图的时候每次注释的时候直接贴上一大块文字,后来发现,其实这个只是把UC上的文字挪个窝而已。
对于一些输入项,比如说是必填项完全可以用判断符号来判断是否填写,总比旁边的注释框中的必须输入四个字直观得多。另外,画设计图的时候是详细了解流程的时候,如果设计图画的流程不正确,即使你纠缠于细节,每个边界值设定都非常正确。只能说当你发现你错误的时候,会很很很抓狂滴~~~
最后到了写设计用例的时间了,有人说,写设计用例是很痛苦的个过程,确实有点,很长一段时间总是纠结在长度类型,边界值,和特殊符号中……但是,我不知道是不是支持这种方法,我开始写用例的时候是老老实实的一个个的写的,然后就发现有些用例是有共通之处的,比如说对于名称的校验,无非是长度,类型,在各种名称的校验中都是换汤不换药的,所有建立一个模板总汇,直接COPY就好了,当然记得COPY后要修改下。
我发现用模板编写的效果除了效率变高外,还可以保证格式上的一致。格式一致的好处就不多说了,至少看起了也好看不是。
但是我担心的一个问题是过于依赖于模板,导致有些细节的地方没有挖掘出来,毕竟一个个编写用例的同时,我们也许会偶尔灵感一现。于是我们就有另一个方法,先搭建整体的框架,先整体考虑出那些框框条条的内容,最后的过程就是填空啦。
其实说来简单,在编写用例的过程中总会遇到很多的问题,比如说需求变更,但是也许唯一不变的就是变化,如果变更了这么办?拥抱变化,跟着变更呗,但是,这里有个问题是:测试组最无奈的事情是——开发人员变更了需求,但是测试这里却不知道。如果再给我一个机会,我一定要在项目开始之前就和测试组约定好!
相关推荐:考试吧策划:2010年软件水平考试完全指南北京 | 天津 | 上海 | 江苏 | 山东 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
广东 | 河北 | 湖南 | 广西 | 河南 |
海南 | 湖北 | 四川 | 重庆 | 云南 |
贵州 | 西藏 | 新疆 | 陕西 | 山西 |
宁夏 | 甘肃 | 青海 | 辽宁 | 吉林 |
黑龙江 | 内蒙古 |