收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
软件测试 > 用例设计 > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

跨出编写300个用例的第一步

来源:互联网 日期:2014-01-25 16:30

  接到一个项目,一个大日常,跨很多应用,形成了标准的开发测试N:1,满心欢喜觉得自己终于可以独当一面了。可是当拿到N个UC的时候,就有种瞬间傻眼的感觉。

  但是由于越觉得这个工程很庞大,越想早点开始启动自己的工作,遂会好不容易找到一个突破口就急于开始写用例。

  刚冥思苦想出第一个文件夹的名字后,在这个模块下,想到什么写什么,想不出来的时候,又开始想第二个文件夹的名字,想下一个模块要写什么。当写到第十几个文件夹的时候突然想起第N个文件夹中好像少了一个用例,又每个文件夹,点开看里面的内容,回顾这个文件夹大致覆盖了哪些用例,看看缺少的这个用例该怎么补。也许庆幸的是,找到了那个文件夹补充好这个用例,但是当你写到第几十个文件夹时,过了几天以后,想到好像漏覆盖了什么功能点,那可能不是就仅仅浪费几分钟去找这个文件夹,而是可能会花上大段的时间去回想自己写了什么,这个时候的思路打断就会让你觉得不知道下一步该怎么走,思路越来越乱,下面的用例到底应该以什么纬度进行下去,还有多少的用例被遗漏掉了,什么用例是不需要写,什么用例是需要覆盖的,突然就会对用例有种不可控的感觉。

  但是,如果一个测试人员对自己的用例都无法控制,那还有谁可以来了解用例的覆盖度,用例的纬度。后面的回归测试同学,如何来有序的进行回归,用例的迁移该会是多么痛苦的一件事。

  其实每个人的测试思路会不同,测试习惯也会不同,所以用例可能就会用不同的方式来写。这些都固然没错,但是用例必须要有个纬度划分,有个整体的一个流线。有利于测试,也有利于用例的review及评审,思维可以顺着下来。

  老人是一个很好的灯塔,他可以指引你怎么前进,有时候自己真的一点没有头绪的时候,可以看看以前的用例以怎样的纬度划分,找个较熟悉该应用的老大,问问如果是你,会怎么着手写这些用例。千万不要在自己没有头绪的时候就开始写第一个用例,有可能会越写越乱,写到最后漏了一大片,冗余了一大片。先确定好用例大体以怎么样的几个大方向来写,比如,按照应用来分,sell一块,mickley一块,forest一块;按照测试顺序,先后台建类目,再前台发布,等等。

  确定一个方案还不够的,这个只是个骨架,这些只是好让你定好一级的文件夹名字。不要就开始写用例了,要不然你定好了几个文件夹名字后又会开始不知道怎么入手了,文件夹下要测试哪些东西呢?所以下面的测试设计很重要,列好几个一级文件夹,对照UC看下一级文件夹是什么,一直设计到叶子文件夹要写哪些功能点。最好可以进行测试设计评审,让开发和老人一起评估下,有没有测试用例覆盖漏掉的点,这个时候修改方向,补充漏写的点,很容易,一目了然。

  虽然这可能会花去你一天的时间,你会觉得很可惜,但是这对后面的工作将会有很大的作用,对功能点已经比较熟悉,对用例编写的思路也很清晰,只要对照设计一步一步往下写就可以了,就不用说动不动就停下来绞尽脑汁在想要写什么东西,尤其是对新人来说,对已有的用例也不熟悉,不知道到底应该写哪些用例,需要测试哪些点,这个就尤为重要了。

  300个用例并不可怕,但是不可控的100个用例就会让人很昏头转向。定好方向,做好设计,建好层级,个个攻破,500个用例都将是可控的。

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的!
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号