51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3920|回复: 8
打印 上一主题 下一主题

[讨论] 关于测试用例的一些想法

[复制链接]
  • TA的每日心情
    奋斗
    2014-12-25 11:52
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    跳转到指定楼层
    1#
    发表于 2007-11-1 14:46:55 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    “测试用例”软件测试人员必备技能之一。
    目前国内应该没有几家公司能够规范的按照软件工程的流程来生产软件产品。
    对于“测试用例”部分我常常遇到的窘境:
    1、项目时间紧,没有“详细设计”甚至“概要设计”阶段。
    2、软件界面,小功能点变化大,往往反复维护用例。
    3、人员配备不足,人员素质参差不齐。
    4、测试时真正按照执行用例的少。

    我常常想“要是没有测试用例多好啊”,我自己也知道很愚昧的想法。

    想了一个办法,针对中小企业,测试制度不健全、人员、时间不充裕的情况。减少“测试用例”编写、维护,同时保证产品质量。
    前提:
          测试组中一定要有业务高手。
          测试组一定要参与到需求中。
    方法:
         测试组人员要对常规测试方法了如指掌,常规窗体,控件,界面测试不写用例。
         只写主要业务流程的测试用例(主要业务流程一般不会变)。

    大家觉得怎么样,提提意见。
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    该用户从未签到

    2#
    发表于 2007-11-1 17:08:54 | 只看该作者
    每次开需求讨论会我们测试人员都必须要参加!

    对整个系统、对每个功能点要做到比开发人员更熟悉!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2007-11-2 09:31:51 | 只看该作者
    对测试经验较少的人员,不可能一下做到对常规测试方法了如指掌,最好能有一个测试检查对照单.
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2014-12-25 11:52
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    4#
     楼主| 发表于 2007-11-2 11:20:19 | 只看该作者

    回复 3# 的帖子

    要看分工了,可以让新人作一些简单的界面测试,如看错字,界面是否统一之类的。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2014-12-25 11:52
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    5#
     楼主| 发表于 2007-11-2 11:21:29 | 只看该作者
    拖拉机:
    你们是所有测试人员都参加还是相关的测试人员参加。
    如果中途有人员变更咋办?
    我很头疼这事
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2007-11-2 14:08:01 | 只看该作者
    我觉得应该是适人而用,对于新人应该让多学多问!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2014-12-25 11:52
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    7#
     楼主| 发表于 2007-11-6 17:06:22 | 只看该作者

    回复 6# 的帖子

    是啊,应该这样,但是有时候会担心质量出问题,毕竟新手的能力有限,需要付出代价。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2007-11-7 14:40:26 | 只看该作者
    如果经常有人员变更就需要有测试用例的指导,否则项目的质量就无从谈起。
    如果时间比较紧,所有功能模块的用例不可能完全写好,这样我认为是可以先只写项目主要的业务流程的。但就有这样的问题,一个项目经过几个版本下来,主要的流程基本没变,因此经过多个版本的磨练,按照测试用例来测试的话紧本上是找不到问题的。所以测试前还需要把握每一版本每一轮的测试重点,重点测试新加的功能和改动过的地方。如果时间紧完成不了案例,可以针对项目先编写测试需求点,将所有测试点都要覆盖。这样,测试的步骤就可以靠测试人员来发挥了。
    另外,楼主说的“测试组人员要对常规测试方法了如指掌,常规窗体,控件,界面测试不写用例”想法是可以,但关键是怎么实现。给个建议,平时可以在测试没那么忙时总结一下测试经验,如总结一下UI测试的指导书,通过长期的积累,就可以做到不写案例,测试人员都指导该如何去测试了。
    都只是个人意见,欢迎交流。。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2014-12-25 11:52
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    9#
     楼主| 发表于 2007-11-14 10:28:03 | 只看该作者

    回复 8# 的帖子

    我也是才有这个想法,没有付诸实践,毕竟更改测试流程需要谨慎。但是目前我公司的情况来看,按照软件工程那么干,根本不现实。只能出此下策。

    还请大家多多指导我。项目紧,没有详细设计阶段,如何去保证测试用例?
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-9 02:03 , Processed in 0.076374 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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