51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: 51testing
打印 上一主题 下一主题

如何在有限的时间内编写完整有效的测试用例?(08-04-07)(获奖名单已公布)

[复制链接]

该用户从未签到

61#
发表于 2008-4-25 15:54:12 | 只看该作者
这个问题需要根据各个项目的时间来确定。
如果该项目的时间必须充裕的话应该严格地按照流程来操作,即
输入条件:Requirement & Function Spec经过评估,并且通过。
执行过程:根据Requirement & Function Spec绘制业务逻辑图,罗列测试点,参照测试点编写测试用例。
输入条件:项目小组相关成员对测试用例进行评估,并且通过。(基本条件是Requirement & Function Spec的100%的覆盖。)

如果项目的时间很紧张,则可以把正规的评估过程改为简单的走查,测试用例可以用业务逻辑图来替代。但是在一个项目周期结束之后,应该对测试用例进行整理,编写并备份入库!

另外,测试用例有一个关键地方就是测试用例的更新,因为在软件测试过程中经常使用同一个用例进行测试,软件会增加对该测试用例的”抗性“。因此,我们要对用例进行及时的更新,在一个项目周期结束之后,应该对测试用例的有效性进行评估,该评估准则是测试用例发现的BUG数量/BUG的总数量。对于用例没有发现的BUG应该添加到测试用例中,此外,用户提交的BUG是很宝贵的,也需要添加到测试用例中!

对了测试用例的管理应该纳入到项目的配置管理中!

以上是我个人的一点心得,和大家share一下!
各个公司,各个team的规定和文化的不同,流程也不一样,大家具体问题具体分析!

[ 本帖最后由 lovemiya 于 2008-4-25 16:24 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

62#
发表于 2008-5-3 17:17:25 | 只看该作者

回复 11# 的帖子

兄弟是不是华为的人啊。感觉和做过的华为项目很类似唉
回复 支持 反对

使用道具 举报

该用户从未签到

63#
发表于 2008-5-10 20:49:55 | 只看该作者

确定测试点

在有限的时间内写出完整的用例,是不可能的。但确定有效的和主要的测试点并且把用例写完整是可能的。
接下来的问题是如何确定测试点?
从几个方面考虑:软件将来由谁在用?
                那些功能用户常用?
                软件的卖点在那里?
回复 支持 反对

使用道具 举报

该用户从未签到

64#
发表于 2008-6-5 15:02:40 | 只看该作者

回复 1# 的帖子

首先,得到该软件的需求及设计文档,理解该系统原理及功能。这实际上是熟悉系统,理解需求,找到测试的要点
其次,根据软件理解,选择恰当的测试方法,设计测试例
最后,根据测试中的理解的不断加深,增加测试用例,完善测试方法。
回复 支持 反对

使用道具 举报

该用户从未签到

65#
发表于 2008-6-8 02:26:27 | 只看该作者

回复 14# 的帖子

说人家落后,我看你们才是很落后呢……
回复 支持 反对

使用道具 举报

该用户从未签到

66#
发表于 2008-7-30 17:37:38 | 只看该作者
呵,我们公司比较特别,我是根据功能规范来写测试用例的.公司根本没有需求文档,但在开发前会详细讨论功能点.形成功能规范.我就根据这个来写的.基本上是等产品开发出来,我用例早写好了,只需稍舟增,改一下,执行,结果就行了.
回复 支持 反对

使用道具 举报

该用户从未签到

67#
发表于 2009-2-13 19:29:48 | 只看该作者

ding

zhchi
回复 支持 反对

使用道具 举报

该用户从未签到

68#
发表于 2009-3-10 17:13:32 | 只看该作者

现实是残酷的

并不是每个公司都会给你让你满意的需求规格说明书,同时也不一定有什么check list之类得东东,举个例子,华为的手机项目测试用例是根据UI给的MMI 图来写的。所谓的MMI图其实就是一个界面布局图。上面有很少的功能描述,这些功能描述也只限于对个别不明确或是有特殊定制的功能作出的解释。
那我就有问题了,这样的情况下你如何快速,简捷,全面地挖掘这款手机的功能点?而且类似于这样的界面布局图后期变更的可能性很大。我的方法是根据MMI图画出每个模块的功能树,分出父节点和子节点。让功能点以树的形势节节细化,并且在下层的叶子节点输出用例。如果有更改就去相应模块功能树中修改,并同时修改该节点的用例。
回复 支持 反对

使用道具 举报

该用户从未签到

69#
发表于 2009-3-13 17:17:51 | 只看该作者
原帖由 土土的豆豆 于 2008-4-11 10:51 发表
这个话题要拆分开来分析。
一、编写完整的测试用例
二、有效的测试用例
三、在有限的时间内
第一、个人认为,没有一个测试人员可以做到百分之百“完整”!何为“完整”?是测试路径覆盖率100%么?不是!即便覆盖 ...

请教“用例设计思路”?谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

70#
发表于 2009-5-28 11:51:03 | 只看该作者

回复 13# 的帖子

测试工作的开展最终依据的是需求,测试用例最终还是要追溯需求,根据需求写测试用例~~~
如果没有测试用例,这个测试工作该如何开展???
能够保证测试符合需求吗?
回复 支持 反对

使用道具 举报

该用户从未签到

71#
发表于 2009-5-28 11:55:38 | 只看该作者

回复 14# 的帖子

应该有这个理念,测试应及早介入;
回复 支持 反对

使用道具 举报

该用户从未签到

72#
发表于 2009-6-25 17:42:19 | 只看该作者
没有我啊
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2015-6-26 11:52
  • 签到天数: 5 天

    连续签到: 1 天

    [LV.2]测试排长

    73#
    发表于 2009-10-8 22:08:55 | 只看该作者
    终于看完了每个回复,获益匪浅,谢谢各位!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    74#
    发表于 2009-10-9 14:33:59 | 只看该作者
    学习。。。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    75#
    发表于 2010-5-16 17:54:56 | 只看该作者
    测试用例是否完整有效,就是看在现有的条件下,现有的需求下,能够在有限的时候之类,最大限度的解决需要解决的问题。说测试覆盖率达到100%,那是不可能的事情,只能说是最大限度的趋近完美
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    76#
    发表于 2010-5-22 17:24:21 | 只看该作者
    现在面临的测试需求还没出来就单独拿个类似的产品来写测试用例确实很郁闷,对与用例100%覆盖的问题不知道有没有什么好的建议?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    77#
    发表于 2010-5-22 17:24:54 | 只看该作者
    有什么好的办法来判断用例的覆盖率呢??
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    78#
    发表于 2010-5-22 17:27:15 | 只看该作者

    回复 69# 的帖子

    是的,这样的问题也是我现在面临的,写再详细的用例,功能改了岂不要大动干戈啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    79#
    发表于 2010-5-22 17:27:28 | 只看该作者

    回复 69# 的帖子

    是的,这样的问题也是我现在面临的,写再详细的用例,功能改了岂不要大动干戈啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    80#
    发表于 2010-5-22 17:27:49 | 只看该作者

    回复 69# 的帖子

    是的,这样的问题也是我现在面临的,写再详细的用例,功能改了岂不要大动干戈啊
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-18 08:38 , Processed in 0.079944 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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