51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

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

[原创] 如何评审测试用例

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-9-7 15:30:24 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
在评审测试用例时:
1、什么样的人员参加用例评审比较合理
2、如何检测用例存在的漏洞和不足

由于目前测试流程正在规范,很多细节的问题不知道如何进行,希望得到帮助
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-9-7 16:05:59 | 只看该作者
我想先问一下:
1、在这个项目中有多少测试人员系统的了解软件及其操作流程?
2、这个项目的有没有专门与客户沟通的人员?了解最真实的客户需求?
3、有没有个开发人员,对软件所有的开发模块都比较了解?

如果有这些人参加估计就差不了多少了,最关键的是想办法让他们签字画押!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2007-9-9 01:29:52 | 只看该作者
1、客户代表:这类人物直接与客户打交道,客户的需求相对来说他们是最清楚的,而测试用例本
             身就是为了验证项目是否满足客户需求
   开发人员:最清楚软件实现功能和操作、处理流程,哪些方面比较弱心里也是最有底,针对其
             弱处去测能更好的提高用例的有效率
   测试系统工程师:更能站在测试的角度去考虑测试用例
   相关领域专家:从以往评审来看,这类人士更能从本质上指出用例缺陷
2、评审过程中参考前期需求列表、测试规格结合一定的测试工程方法分析,是不错的防止测试用例不足和漏洞的方法
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2007-9-10 10:12:47 | 只看该作者
感谢楼上两位的回复!
结合公司的实际情况测试用例的评审需要项目负责人、开发人员和有经验的测试人员来参加用例的评审。
对于目前来讲,关键的问题在于第2个,因为i公司从来没有进行过用例的评审,用例写完后就成为了一堆废纸,我认为在评审过程中关键的人员还是测试人员代表,他要能快速地指出用例存在哪些不足和漏洞,这本身就要求这个人员在用例设计方面很突出。但是公司目前没有这样的人员,也基本都没有怎么写过测试用例的,这种情况下又该如何进行呢
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2007-9-11 09:47:53 | 只看该作者
矮子里选将军,总得要做做样子吧?
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2014-2-13 10:04:09 | 只看该作者
百度里面抄的,个人感觉不错:
1:评审的过程
A:开始前做好如下准备
    1、确定需要评审的原因
    2、确定进行评审的时机
    3、确定参与评审人员
    4、明确评审的内容
    5、确定评审结束标准
    6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
    7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容,并记录相关的疑问,以便在评审会议上提出。
    8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问,以便在会议上提出。
B:开始评审
    1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议,同时进行详细的评审记录。
    2、 通用邮件与相关人员沟通
    3、 通用IM工具直接与相关人员交流
    4、根据评审内容进行评审

2:评审内容
    1、 用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。
    2、 优先极安排是否合理。
    3、 是否覆盖测试需求上的所有功能点。
    4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;期待结果是否有明显的验证方法。
    5、 是否已经删除了冗余的用例。
    6、 是否包含充分的负面测试用例。充分的定义,如果在这里使用2&8法则,那就是4倍于正面用例的数量,毕竟一个健壮的软件,其中80%的代码都是在“保护”20%的功能实现。
    7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
    8、 是否简洁,复用性强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

3:参与评审人员(这里会分为多个级别进行评审)
    1、 部门评审,测试部门全体成员参与的评审。
    2、公司评审,这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
    3、 客户评审,包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    难过
    2015-7-6 15:31
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    7#
    发表于 2014-2-17 16:44:30 | 只看该作者
    用例很大程度上还是依赖于业务场景,对业务熟悉了测试用例的遗漏也就有参照点了。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2014-2-21 15:09:11 | 只看该作者
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2015-11-11 11:16
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    9#
    发表于 2014-4-3 15:42:42 | 只看该作者
    回复 4# Erin_gy


        我觉得如果是测试团队里成员测试用例编写水平在较低的一个线上,首先要做的不是推动测试用例评审流程,而是如何培养测试人员的用例编写水平;测试用例评审,至少要在编写水平达到一定程度,才好推行吧
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-25 16:14 , Processed in 0.082436 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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