51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3825|回复: 4
打印 上一主题 下一主题

[讨论] 测试用例漫谈

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-12-5 10:54:06 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
一点小的经验总结,拿出来大家讨论一下。
1.什么是测试用例

      测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求的描述,是判定的依据,也是软件测试的核心。所以,不能没有测试测试,测试用例也不能没有预期结果


2.测试用例的来源是什么

      所谓来源,也可以认为是输入,测试用例的主要来源是以下方面:用户需求分析文档和需求验证文档、系统设计文档、概要设计文档、详细设计文档,已成界面,相关行业的规范等等,这些可以参考W模型中的定义,此外,测试用例中还需要考虑以下方面:以前版本中发生的错误、某些可能需求分析中可能遗漏的地方(如破坏性测试用例)。同时,测试用例也应该进行细分,如,功能测试用例,性能测试用例,单元测试用例等等。还有一部分应该来自和自己团队和开发人员的讨论,适当的头脑风暴以及评审是很重要的。

3.测试用例的格式是什么

      作为一个测试用例并没有标准格式,但是至少应该包含以下信息:测试用例编号,测试用例优先级别,测试用例名称,测试用例所属类型,所属产品,所属版本,测试目的,测试前置条件,测试执行步骤,预期结果,实际结果,备注。

      对于预期步骤中,应该适当的详细描述,从而保证任何一个对此产品略有了解的人员都能执行。

4.测试用例怎么维护

      这里牵涉到测试用例的保存问题,在目前国内很多公司中,都还是把测试用例保存在Word文档中,如果仅一个工程师使用的话,或许还行,但是如果多人进行测试,任何一个任在对测试用例进行修改,删除等等行为的时候,可能就会引起冲突从而导致信息的丢失和不全。纵然可以使用版本管理软件进行管理,但是,这个毕竟是非文本的,在冲突的时候,版本管理软件也无能为力。同时,Word的统计性也很糟糕,比如总共有多少case,执行了多少,正确的多少,错误的多少,都需要靠人去数,实在是很笨的方法。也有一些公司使用了Excel,在统计上有比较大的进步,但是仍旧不容易进行版本管理。

      在市场上,有MI公司的TD等软件,确实是不错的选择,集中式数据库管理的方式把上述的两个问题都解决了,只是留下了一个问题:钱的问题。这个问题也很大。

      还有一种解决方案就是使用论坛写Case,在维护上不错,但是统计上有缺陷,可以自己再做一些二次开发,从而达到目的。我也曾经自己试着用ASP开发了一个测试用例管理系统,虽然和TD相比差距很大,不过也能解决上述的两个问题,只是在Case的维护上还有一些硬伤,但是养成良好习惯的话,应该还是能有一些方便的。

6.测试用例怎么和产品关联

      其实这里也是和用例的维护有关系,因为同一个产品,版本在不停的变化,功能也在不停的变更,对于同一个case,可能在上个版本有效,这个版本无效,也可能是上个版本无效,这个版本有效。在数据库中维护的时候,不可能所有的case都重复添加N次,每次仅对应一个版本,这种做法非常的不理智,而且也同样会引起维护的问题。正确的方法是,在数据库中有一张表放所有的case,这些case都用功能大项来进行分类,每个case都有唯一的id,用另外一张表维护所有的产品,然后产品里面有一个属性用来存本产品的所有的caseid。

7.测试用例的执行和记录

      在一般情况下,测试用例是根据版本,进行一轮一轮的执行的,所以应该在测试用例管理中,根据每轮执行的情况进行记录,比如结果描述中就应该存在,第一轮,CASE错误,实际结果为XXX,上报了BUGXXX,并给一个链接到bugzilla或者类似的管理系统中去。如果有自动化执行系统,则需要采集日志,以便分析之用。对于条件不满足的case,可以置为未执行状态,在每轮执行完毕后,应该生成相关统计,如执行了多少case,未执行多少,正确的多少,错误的多少,上报了bug多少。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2006-12-5 16:00:25 | 只看该作者
楼主真是解释的很详细了,要是能有一个例子就更好了,不过还是多谢了!支持一下!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2006-12-5 19:17:13 | 只看该作者
1.个人觉的用例应该分类型的.比如功能测试的用例\性能测试的用例\单元测试用例......  不同类型的用例格式可以不同    ,但要素必须全面.什么编号\测试目的\预置条件\级别\输入\预期输出...
2.甚至不同项目的用例格式完全可以不同,还是一句话,格式可以不同,但要素必须全面 呵呵

最重要的是方便,可以提高维护和执行的效率. 不应该一个模板套到底,有时候你会觉得写起来很累

3.关于 试用例的执行和记录  个人觉得用例中关键字设置 要和BUG的描述联系起来考虑. 有些公司把执行记录和用例完全融合在一起   比如说实际结果\测试结果 是否通过\执行人\执行日期等等   如果你BUG中描述的够详细.那么用例中有些字段可以省略  比如实际结果
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-4-6 15:15:14 | 只看该作者
sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2007-4-7 22:35:58 | 只看该作者
好文章,支持一下
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-8 13:42 , Processed in 0.079731 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表