测试中常被忽视的UseCase
我们常说测试以需求为依据。那么我到底如何组织我们的测试是最接近需求呢。以下我提到一非常重要因素：UseCase----什么是UseCase呢？在UML的文档中，UseCase的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实UseCase就是对系统功能的描述而已，不过一个UseCase描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。在使用UML的开发过程中，需求是用UseCase来表达的，界面是在UseCase的辅助下设计的，很多类是根据UseCase来发现的，测试实例是根据UseCase来生成的，包括整个开发的管理和任务分配，也是依据UseCase来组织的。啊，UseCase，简直太重要了！
UseCase 由以下元素组成：名称、简单描述、事件流、关系、活动图和状态图、UseCase 图、特殊需求、前条件、后条件。
创建USE CASE的原则：1、用例是短文。2、用例可以是一个场景，包括动作和互交。3、用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。4、用例里不要有系统设计。5、用例里不要有界面设计。6、用例里不要有特性列表。7、用例里不要有测试。8、用例应该描述行为需求。9、用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。10、用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。
总的来说：UseCase 是系统提供的功能块，换句话来说UseCase演示了人们如何使用系统。通过UseCase观察系统，能够将系统实现与系统目标分开，有助于了解最重要的部分――满足用户要求和期望，而不会沉浸于实现细节。通过UseCase 用户可以看到系统提供的功能，先确定系统范围再深入开展项目工作。
那么如何从UseCase 生成TestCase 呢？
从UseCase的角度来考虑TetsCase的设计，重点还是要从业务本身的角度来考虑，比如UseCase中的基本流和不同的备选流组成的不同的业务流程，都可以对应到单独的一个TC中去。但TestCase还会考虑来把用户不同情境的基本流/备选流进行细化组织。 谢谢 ffhhj从UML的角度分析了 Test Case的重要性。如果有几个实例 就更好了 Use Case 是BA写的东西，我就根据它来写过用例，结果发现测试完全没有办法进行下去，你的检查点在产品中可能根本就没有体现，为什么？因为开发人员很少或者根本就不去看Use Case ，悲哀。。。 楼上公司的开发人员不看use case怎么开发的啊？依据呢？太可怕了。。。 有的时候开发人员是不怎么经常看use case的，所以开发出来需求有可能跟实际相差很远sdlkfj7 原帖由 tyler_zhou 于 2007-5-11 09:06 发表 http://bbs.51testing.com/images/common/back.gif
Use Case 是BA写的东西，我就根据它来写过用例，结果发现测试完全没有办法进行下去，你的检查点在产品中可能根本就没有体现，为什么？因为开发人员很少或者根本就不去看Use Case ，悲哀。。。
bug多多啊 怎么没有实例分析呀?
晕!!
sdlkfj4 既然UseCase都已经写出来了,如果事实上做出来的东西跟UseCase不符的话,是不是就应该当作bug来处理呢? 我们没有你说的饿这个环节usecase的实例能给一个吗 先看USECASE，然后具体的流程跟细节去跟所属模块的开发人员去交流 开发一般都凭感觉，很少有人会画流程图之类的
页:
[1]
