51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2558|回复: 2
打印 上一主题 下一主题

[求助] 请教!测试用例设计方法在实际工作中的应用

[复制链接]
  • TA的每日心情
    慵懒
    2015-1-18 20:44
  • 签到天数: 2 天

    连续签到: 2 天

    [LV.1]测试小兵

    跳转到指定楼层
    1#
    发表于 2011-1-7 15:32:53 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    我在学软件测试,目前在项目的测试用例写作阶段。按照测试用例的写作方法,一个用户名(比如字符型,必填,长度为50)使用等价类和边界值的设计方法,用例就有8个之多,这样下来一个简单的软件就有十分庞大的用例数量。但如果不按照用例设计方法来做,又担心测试不完全。我们老师说实际工作中一般是25个用例/KLOC,如果这样,是不是就对着需求觉得哪里容易出问题就写用例呢?难道用例设计方法就是为了考试面试吗?很迷惑。不知道大家在工作中是怎样做的呢?
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    该用户从未签到

    2#
    发表于 2011-1-10 12:36:00 | 只看该作者
    1.设计用例时,不需要在意测试用例数量,前期尽可能多设计用例。若觉得实际执行时,用例数量过多,可在已设计好的用例组中,筛选出新的用例组来指导执行。
    另,“我们老师说实际工作中一般是25个用例/KLOC”
    注意“一般”二字,“一般”即意味着实际工作中,往往都不是这个数据。话说,这个数据也其实无法评估,因为没有界定测试单元的规模。

    ——————————————————————————————————————————————————

    2.用例是的根本目的是指导测试,并在早期尽可能多得发现风险。(风险不仅仅包括故障,还包括需求不清晰;工作量统计不准确……等)

    ——————————————————————————————
    3.“是不是就对着需求觉得哪里容易出问题就写用例”
    这种思维方式不正确,说法倒勉强是对的....
    以测试角度来说,“怀疑一切”是根本,所以,任何地方都会觉得有问题,即任何地方都得写用例. 这就是所谓的测试覆盖。

    ——————————————————————————————————————
    4.用例实际设计
    如1点所说,设计用例初期,尽量多写用例。写完以后,用于不用,由项目实际进度决定,非用例设计人员可以决定的。
    用例设计可以在编写用例时,仔细填写“用例优先级”属性,以便于在设计测试方案时,能灵活安排测试用例分布。
    ————————————————————————————

    最后,刚开始设计用例时,可生拉硬套各种测试方法。各个测试方法都是测试前辈们的心血结晶,对测试覆盖的提升都有4两拨千斤的功效。
    待日后体会深刻以后,定能明白其中妙处。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2015-1-18 20:44
  • 签到天数: 2 天

    连续签到: 2 天

    [LV.1]测试小兵

    3#
     楼主| 发表于 2011-1-11 19:11:58 | 只看该作者
    非常谢谢版主。
    “写完以后,用于不用,由项目实际进度决定,非用例设计人员可以决定的”我觉得非常好。
    作为用例设计人员,我们的目的就是尽可能全面的设计用例,但是我现在在写的时候就有“怎么这么多的用例呢,是不是太多了”的心态。希望慢慢该变自己的认识。
    谢谢!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-25 18:20 , Processed in 0.068594 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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