51Testing软件测试论坛

标题: 如何确定1个测试用例的结果，期望结果可以是多个点吗？ [打印本页]

作者: fengzhulin 时间: 2012-12-5 10:44
标题: 如何确定1个测试用例的结果，期望结果可以是多个点吗？
目前组内关于测试用例编写的期望结果有一些分歧，在这里跟大家讨论下。

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。

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

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

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

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

作者: yazi0127 时间: 2012-12-7 12:07
测试用例是可以有多个检查点的。
如果用测试管理工具的话，test case都是有版本管理的。这里很容易看到test case的更新。

作者: qvbfnsc 时间: 2012-12-14 15:17
个人觉得还是用第二种，这个用例就是验证登陆成功的整个系统的响应，
前台页面、后台日志、数据库；这三种合起来才能算登陆成功；否则不能算登陆成功。

作者: qianwange 时间: 2012-12-14 17:07
我会选择第2种，用例的写作，如果步骤一样，结果不同的话，最好是一个，检查点可以使多个的。

作者: willyenillye 时间: 2012-12-27 11:18
需求要求：点击登陆按钮后，显示成功登陆系统的弹窗提示，同时写入1条登陆日志到数据库表AAA中，同时向***系统发送1条接口日志，表示登陆成功。

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

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

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

作者: 没翅膀的飞鱼 时间: 2013-1-5 23:02
这个其实就是测试用例颗粒度的问题，具体就看项目大小，留给测试的时间以及测试用例可复用性等等决定的---

作者: 骷髅行走lby 时间: 2013-2-17 20:30
个人偏向第二种，3个期望结果是同一个操纵下产生的一系列的结果，3者都符合才算是这个操作结果符合预期。

@8楼，用例颗粒度，有没有相关的书给介绍一下？

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)