51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4669|回复: 12
打印 上一主题 下一主题

[讨论] test case 怎样才能做好了??

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-4-20 14:30:36 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
hi
大家好,我是新手,对于Test case 一点都不了解,而我们老大又要我弄这一项目,所以我想请各位高手教教我,让我向各位学习学习???谢谢,大家帮帮忙吧~~~~~~~~``
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    奋斗
    2024-11-8 12:09
  • 签到天数: 547 天

    连续签到: 1 天

    [LV.9]测试副司令

    13#
    发表于 2010-7-5 16:58:21 | 只看该作者
    TestCase的用法
    TestCase类在整个JUnit框架中处于核心的地位。你可以在junit.framework包中发现TestCase这个类。在JUnit开发人员当中,甚至是在一些高级的程序员当中,都有一个疑惑,那就是测试用例(test case)和TestCase类之间的关系。事实上,这是个命名冲突问题。“测试用例”(test case)这个术语通常指的是单个的测试,通过编码来校验某个特定的行为。那么,将多个测试用例都收集到一个类中,这个类是TestCase的子类,而且每一个测试用例都被实现为TestCase类中的一个方法,这的确有些奇怪。既然这个类包含了多个测试用例(test case),那为什么把它叫成“TestCase”而不是叫做“测试集”之类的名字呢?

    在这里我们给出最好的解释:虽然在编写测试的时候,你需要创建一个“TestCase”的子类,并把每个测试用例都实现为这个新类的方法;但是在运行的时候,每个测试用例都会被当作TestClass子类的一个实例来运行。使用面向对象的术语来说,每个测试用例都是一个TestCase的对象,因此,这个名字还是合适的。不过,一个TestCase包含了很多的测试,这的确引起了术语的疑惑。这也是为什么我们如此小心地区分一个测试用例(test case)和TestCase这个类:前者是单个的测试,而后者则包含了多个测试,每个测试都用不同的方法来实现。为了更清楚的区分这两个概念,我们不会再(尽量做到不再)使用测试用例(test case)这个术语。要么就用测试(test)这个词,要么就用”TestCase”这个类名。在这本书的后面,我们还会把这个“TestCase”类称为“固定器
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2010-5-27 17:43:13 | 只看该作者
    你公司有其他项目的测试用例可以参考吗?
    另外测试用例是需要设计的,
    一般一条测试用例包含如下内容:
    测试用例编号测试项目测试标题重要级别预置条件输入操作步骤预期输出

    设计测试用例的方法为:
    等价类,边界值,判定表,因果图,流程分析法,正交实验法....
    在需求分析阶段就可以进行系统测试的计划和系统测试用例的设计了
    在概要设计阶段就可以进行集成测试的计划和集成测试用例的设计了
    在详细设计阶段就可以进行单元测试的计划和单元测试用例的设计了
    编码完成后,执行单元测试用例,到集成测试用例到系统测试用例。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2010-5-27 09:29:41 | 只看该作者
    根据需求来挖掘测试点,可以用到以下几种用例的设计方法。流程分析,等价类,判定表,状态迁移等等。。。。~另外如果没有需求的话。你可以通过和开发交流,以及看看产品说明书等种种方法知道软件的一些业务知识和其功能
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2010-5-27 04:15:07 | 只看该作者
    小弟想來大大的老闆應該是要請大大做自動測試的test case吧…
    坊間有書可以參考哦…
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2010-5-21 20:19:40 | 只看该作者
    需求来
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-11-8 12:09
  • 签到天数: 547 天

    连续签到: 1 天

    [LV.9]测试副司令

    8#
    发表于 2010-5-10 13:42:35 | 只看该作者
    当需求下来就可以写测试用例了,测试最好是根据测试用例来进行
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
     楼主| 发表于 2010-4-23 14:11:30 | 只看该作者
    哦哦,谢谢你的建议~~~~~~~~~thank you
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2010-4-23 00:28:08 | 只看该作者
    上面说的方法不能保证你的 case 有多好,只能保证你的 case 比较全面,覆盖了系统。

    我想 case 要做好,是一个慢慢积累的过程,测得东西多了,打开一个页面,你就有感觉,觉得哪里容易有问题;还要不断思考,你用2个小时去执行,执行完了,你静静地去看你执行过的页面,看看还有哪里你没考虑到;深入了解业务逻辑,功能测试还是对业务的了解,了解的越多,你想到操作业务的可能性越多,你的用例设计的越有深度。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-4-23 00:22:56 | 只看该作者
    首选的应该是从需求入手,如果你们项目的需求做的足够好的话。

    如果需求不行,就从系统入手。

    1、列出全部的功能点和业务逻辑,比如:
    a.申请的增加功能
    b.申请的修改功能
    c.申请的删除功能
    d.申请的上报功能
    A.已经上报的申请不能删除

    2、拿着功能点和业务逻辑去找需求负责人评审,保证你整理的功能点也业务逻辑能够覆盖整个系统

    3、将功能点和业务逻辑转化为case

    4、进一步熟悉系统和测试过程中会发现新的思路,补充道用例中
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
     楼主| 发表于 2010-4-22 14:42:45 | 只看该作者
    不会吧,只有两步
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2010-4-21 11:28:16 | 只看该作者
    先了解项目咯,然后再编写测试用例咯
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    2#
     楼主| 发表于 2010-4-20 14:46:53 | 只看该作者

    回复 1# 的帖子

    自我顶一下吧~~~~~~~(*^__^*) 嘻嘻……
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-26 21:57 , Processed in 0.097702 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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