51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

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

[讨论] 如何确定1个测试用例的结果,期望结果可以是多个点吗?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2012-12-5 10:44:36 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
目前组内关于测试用例编写的期望结果有一些分歧,在这里跟大家讨论下。

1个用例,如果有多个检查点,是分开写用例呢,还是写入1个用例?

例如:
需求要求:点击登陆按钮后,显示成功登陆系统的弹窗提示,同时写入1条登陆日志到数据库表AAA中,同时向***系统发送1条接口日志,表示登陆成功。

那么对于这个需求关于成功登陆系统的用例设计,目前组内人员有2种用例设计方式。
第一种:
设计3个用例,且每个用例标题都说明检查点,但是每个用例的步骤都一样,但是期望结果分别是需求描述的3个结果。
如:
用例1、成功登陆后弹出提示窗口;用例二、成功登陆后向AAA表写入一条日志;用例三:成功登陆后向***系统发送1条接口日志

第二种:
设计1个用例,用例标题为:成功登陆系统检查,这个用例的期望结果有3个检查点。1、显示成功登陆系统的弹窗提示
2、写入1条登陆日志到数据库表AAA;3、向***系统发送1条接口日志,表示登陆成功


大家讨论下,到底哪种适合呢?
我目前觉得各有各的好处,说一下我的观点。
用第一中用例设计方法:
优点:用例结构和检查点非常清晰,便于后期维护以及新人学习和执行用例。
缺点:用例数量变的很庞大,执行过程有可能重复做同1个操作步骤,只是检查点变了而已。效率会降低。
用第二种用例设计方法:
优点:用例条数少,review、执行起来都方便。
缺点:
1、通过用例标题不容易看出检查点到底是什么,且对于后期需求变更用例修改和维护不是很方便。
例如:过1个月后,要求去掉向***系统发送接口日志的功能。那么对于第一种用例设计方法就比较方便,直接删除用例即可。
2、用例执行过程中,如果某个检查点失败,则整个用例都失败。不容易看出来到底哪个点有bug。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

该用户从未签到

2#
发表于 2012-12-6 11:16:27 | 只看该作者
那也说一下个人观点
二种确实各有优缺,缺点都需要人为补足,感觉这是必然的,也可以适当混合使用
第一种的话
优点在于便于阅读,并且达到了一对一对应,且不会有分歧,当某一个检查点的步骤独立出来了,可以便于修改。
但是同样缺点在于数量大,而且重复性很大,如果设计变化,操作步骤变了,那同样操作的用例全部都要一起修改,维护也会成为问题。
关于执行的话,同样的步骤用例,人是活的,我认为可以通过人为的操作来简化,当然对第一次来说会有相当的损耗

第二种,跟楼主说的差不多
优点在于,能够提高执行的效率,且能够减少用例的冗余
但是缺点用例不是一对一对应,当一个步骤对应很多检查点,当出错的时候就会涉及到分歧,需要测试人员自己添加备注标明那个检查点错误
当需要修改检查点的时候,因为不是一对一对应,所以要定位用例。
但是相对的,整体步骤修改时,就只用修改一个用例。

个人认为,那一种都可以用,因为看项目的实际情况,包括测试人员的经验,项目的大小等来取舍
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2012-12-6 23:30:23 | 只看该作者
1、对于第1种测试用例,用例管理起来比较的容易;
2、第2种测试用例:给个建议就是在测试用例模板中添加1个对错误Bug的一个简单的说明备注,通常我们几百条的功能测试用例可能只发现几十个缺陷,那样我们可以在工作之余简单抽个时间对Bug进行1个备注,这样就和容易定位执行不通过缺陷以及问题所在:(如:第2种测试用例中第2个操作步骤错误了,你可以对缺陷记录:如:××(Bug编号),添加备注:执行第2步骤出错),也很便于管理;希望可以帮到你!
如果项目比较紧的话可以使用第2种测试用例,如果项目时间允许的话,可以写的稍微详细点,这样对于测试点更加的明确;
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2012-12-7 12:07:52 | 只看该作者
测试用例是可以有多个检查点的。
如果用测试管理工具的话,test case都是有版本管理的。这里很容易看到test case的更新。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2012-12-14 15:17:53 | 只看该作者
个人觉得还是用第二种,这个用例就是验证登陆成功的整个系统的响应,
前台页面、后台日志、数据库;这三种合起来才能算登陆成功;否则不能算登陆成功。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2012-12-14 17:07:43 | 只看该作者
我会选择第2种,用例 的写作,如果步骤一样,结果不同的话,最好是一个,检查点可以使多个的。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2012-12-27 11:18:10 | 只看该作者
需求要求:点击登陆按钮后,显示成功登陆系统的弹窗提示,同时写入1条登陆日志到数据库表AAA中,同时向***系统发送1条接口日志,表示登陆成功。

这三个都是系统行为,写到一个用例的一个预期结果里就完事儿了。三者之间是AND关系,任何一个错误都导致用例执行失败,而缺陷中则应当指出具体错误。

第一种太麻烦,没有任何必要。混淆了用例执行结果和缺陷报告二者的分工。新手拿这玩意儿也无法对系统有一个完整的理解,反而由于预期结果散落在各个用例中而一叶障目。

从你的需求层次来看,是系统级的需求描述,新手不应单纯靠看用例来理解测试对象,而应当对该系统有足够的了解,这又有登录界面,又有后台接口,还有数据库,最起码的系统框架应当先教给他。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2013-1-5 23:02:30 | 只看该作者
这个其实就是测试用例颗粒度的问题,具体就看项目大小,留给测试的时间以及测试用例可复用性等等决定的---
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2013-2-17 20:30:24 | 只看该作者
个人偏向第二种,3个期望结果是同一个操纵下产生的一系列的结果,3者都符合才算是这个操作结果符合预期。

@8楼,用例颗粒度,有没有相关的书给介绍一下?
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-25 19:58 , Processed in 0.076177 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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