51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6820|回复: 17
打印 上一主题 下一主题

请教功能测试用例怎么写???

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-2-2 15:58:41 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
比如药品采购入库,有增加新采购单,录入药品,保存数据,执行入库,已存在未执行采购单的修改等操作,
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1

该用户从未签到

2#
发表于 2005-2-2 16:13:57 | 只看该作者

搂主的流程已经出来了!

加一点:执行数据库的检查的操作!!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2005-4-19 17:13:30 | 只看该作者
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2005-4-25 20:49:03 | 只看该作者
看看这个帖子你用不用的上?
http://bbs.51testing.com/viewthread.php?tid=11963&fpage=1

[ Last edited by songfun on 2005-4-30 at 09:48 ]
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2005-4-29 19:59:30 | 只看该作者
问题不在于测试用例该怎么写,而在于想怎么测。先保证自己对业务流程和业务规则的理解和熟悉,然后可以对这部分先思考一下,哪些地方需要测试,需要怎样的测试?如何来施行这些测试?

之后再增加对系统中其他规则、特性和算法的熟悉,继续增加测试的深度和广度。

测试用例的书写无非就是一个把自己的测试思路格式化表达的过程。所以先要保证自己知道该如何去测试,格式反倒是其次了。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2005-4-30 00:00:05 | 只看该作者
同意jackei,如何设计出好的用例才是关键,把对用例的理解表达出来,格式自然出来了,如果只局限于形式,编写用例反而成了一件不断的重复操作和填鸭,痛苦不说也不容易写好。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2005-4-30 20:24:42 | 只看该作者

to Jackei,skinapi:

【不在于测试用例该怎么写,而在于想怎么测。】
【对用例的理解表达出来,格式自然出来了】

呵呵,偶要顶一下,偶不是完全赞同这两句话。用例的理解跟格式没有必然的联系。也没有主次轻重之分。

【先保证自己对业务流程和业务规则的理解和熟悉,然后可以对这部分先思考一下,哪些地方需要测试,需要怎样的测试?如何来施行这些测试?之后再增加对系统中其他规则、特性和算法的熟悉,继续增加测试的深度和广度。】——这句说的很对。

有这么一个公式, 数据结构+算法=程序。
这里类比一下用例设计,jackei和skinapi版主强调的是用例的“算法”,而文档格式是用例的“结构”。

两者的关系是相辅相成,而不是矛盾的(好像在上政治课哈)。

至于说“对用例的理解表达出来,格式自然出来了”,这个境界太高了,不是一般人可以做到的。面对现实的企业应用,做项目的话你会遇到各种各样的情况,要做到“格式自然出来”实在是太……厉害了呵呵。

是这样的:
用例格式相当于一个规范,给你一个结构,一个框架(framework),仅此而已,并不因为你的用例模板而能体现用例的好坏。

所以, “用例怎么写”其实分两个:

用例的“算法”+用例的“结构” (也就是模板)了。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2005-5-7 15:12:47 | 只看该作者
个人观点:
对于测试用例设计,同测试用例模板是否有必然的关系?
嗯,要注意测试用例的模板也会误导测试用例设计者,因为模板中有一部分元素是同测试用例本身相关的,这些部分可以帮助新人了解测试用例应该包括哪些内容,而其他部分是同测试用例管理有关的。

所以,关键不在于模板本身,而在于要可以通过模板表达出设计测试用例的思路,更要让测试用例设计者分清哪些是测试用例设计本身要关注的,哪些是为测试用例管理和测试管理而作的。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2005-5-13 10:25:22 | 只看该作者
个人比较赞同jackei版主的说法
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2005-5-13 10:28:58 | 只看该作者
怎么样写好用例,做好测试,对于更好的执行测试非常之重要,测试计划也一定要写好。在测试计划的时候已经对项目的流程有很详细地了解了,那么在写测试用例的时候确实格式会自然的出来,在尽可能的情况下把覆盖率提高,可以在具体执行测试的时候节省时间。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2005-5-13 10:30:18 | 只看该作者
格式没有什么定式,我很同意。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2005-5-13 15:56:31 | 只看该作者

个人认为

首先,确定测试对象:采购入库
其次,明确功能:新增、修改、删除
再次:明确一些需求或设计上的一些规则或约束。如:被引用后的采购单的修改、删除等。
最后,针对这些规则进行编写测试用例。
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2005-11-8 14:55:22 | 只看该作者

功能测试要这么做

第一步,清晰模块功能;

第二步,选择测试方法(等价类等);

第三步,设计测试用例的操作步骤,及输入;

第四步,列出预期输入.
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2005-11-17 15:29:34 | 只看该作者

峨峨峨峨

不论什么类型的软件 ,都有共同的特点,也就是常识,对于一个新手来说,感到困惑,对于老手,态度漠燃。通用的和常用的就可作为标准。很多是来自于平时测试的积累。可惜的是。很少有留下来的。
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2005-11-18 09:57:34 | 只看该作者
明确测试对象、测试功能。测试对象与功能之间如何发生关系,OK,把这种关系以事例的形式表达出来就是功能测试用例了。不要想得太复杂,很多时候因为测试用例是在你见到软件前写的,总觉得心中没底,但好的需求文档就是程序的剧本,象演电影一样,把剧本研究清楚,就知道该怎么表演了。
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2005-11-22 15:53:49 | 只看该作者
首先明确你要做的功能流程:药品采购入库-新增、修改、删除等功能键都应该是有的;录入药品--这里包括药品的一些参数数据,都要详细的做到;执行入库--这里要有明确的控制,入库出库要有详细的记录与控制;


根据上面的一些功能可以描述测试用例(也就是你的操作),而预期结果也就是你要达到的目的。
回复 支持 反对

使用道具 举报

  • TA的每日心情

    2015-11-3 11:46
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    17#
    发表于 2005-11-30 16:10:53 | 只看该作者
    学到了不少,顶!!!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2012-3-20 17:10:27 | 只看该作者
    学习当中!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-13 19:20 , Processed in 0.085658 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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