我们常说测试以需求为依据。那么我到底如何组织我们的测试是最接近需求呢。以下我提到一非常重要因素: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 用户可以看到系统提供的功能,先确定系统范围再深入开展项目工作。
use case应当细到相当的程度,起码应当细到让一个对业务逻辑不了解的人看过之后能够了解整个业务过程,只有达到这种程度的设计,具体的编码人员才能按照你的设计思想去填写代码。就像盖楼一样,建筑工人是不用(也不太可能)去考虑图纸是如果画成的。
use case 大量用来描述系统和外部的交互,而不是把什么都用USE CASE来做.如果那样,还要时序图,状态机等等干什么呢?总的来说use case是从高层来描述系统的,你甚至可以用一个USE CASE来描述你的系统,但大多数情况下是使用多个小的USE CASE来构成用例模型.
use case是一种UML吗 答案是--不是。 但是use case可以用UML符号来说明 当然也可以不用。use case是一种格式化的文档。它是是由用户和系统在一次对话中执行的一个特殊事务序列 。当然我观察这里大多数人都在说use case的时候 其实他们是在说use case diagrams 。
use case需要写的很详细吗 ? 其实这个问题如果这样问,use case 需要一开始就写的很详细吗? 还有所有的use case都需要在开始的时候就写的很详细吗? 我认为这会由于你是不是支持迭代而有所不同 。 而统一的答案是没有的 。
那么能详细到什么程度呢 实际上对use case描述的详细程度一直是一个没有统一答案的问题 有各种各异的说法 当然可能在瑞理那里你会得到的答案是统一的 但是你记住use case不是瑞理私有的一种技术 所以你应该可以建立起符合自己组织实际情况的一套标准 而你这里说的详细标准 我看是指的说明的详细程度 而不是对use case粒度划分的程度 这不是大问题 其实我看只要你可以把你的业务流程表叔清除 而没有角色和动作的遗漏就可以了 当然不要忘记前置和后置条件
use case实际上是一种需求的分析工具 而且它之停留在系统的外部 而不应该试图去用它来说明系统内部的运行情况。系统内部的运行情况是你的设计工作所要解决的问题 所以你不管对use case书写多么详细 也不可能代替你的设计 不可能会发生coder看着use case直接向里面填写代码的事情发生 但是我不知道你指的复杂的逻辑角色是什么 如果你指的是系统运行时候参与的角色 那么我认为你必须在需求中解决这个问题 也就是你必须在use case中把它们表达清除 而具体如何通过对它们的计算得到最后的结果 则不是use case所包括的必然部分 当然你给出解决方法(可能是客户现在的解决方法 也或许是你从什么地方找到的方法)会有好处
还有我不认为你可能把use case书写到一个对业务完全不懂的coder看过你的use case就能了解业务了 这是不太可能的 当然我不排除有这样的例子 但是如果你试图这样做你就要准备把你的use case书写成一部业务手册 其实use case还是要和客户的现场答疑 顾问的咨询 业务资料的研读等多种方法结合才可能使coder对业务有一个大概的了解 当然即使是这样你依然部可能要求他们吃完领域专家
最后说说用例的粒度问题 这是一个老话题 我在这个地方就回答过多次 我现在依然认为use case的粒度划分没有一个绝对的标准 你只是要做到适合自己使用就可以了 如果你认为增加记录可以是一个use case 那么就是一个use case好啦 这是你的选择 你只是需求对你划分粒度所带来的后果做成评估
在使用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 用户可以看到系统提供的功能,先确定系统范围再深入开展项目工作。
use case应当细到相当的程度,起码应当细到让一个对业务逻辑不了解的人看过之后能够了解整个业务过程,只有达到这种程度的设计,具体的编码人员才能按照你的设计思想去填写代码。就像盖楼一样,建筑工人是不用(也不太可能)去考虑图纸是如果画成的。
use case 大量用来描述系统和外部的交互,而不是把什么都用USE CASE来做.如果那样,还要时序图,状态机等等干什么呢?总的来说use case是从高层来描述系统的,你甚至可以用一个USE CASE来描述你的系统,但大多数情况下是使用多个小的USE CASE来构成用例模型.
use case是一种UML吗 答案是--不是。 但是use case可以用UML符号来说明 当然也可以不用。use case是一种格式化的文档。它是是由用户和系统在一次对话中执行的一个特殊事务序列 。当然我观察这里大多数人都在说use case的时候 其实他们是在说use case diagrams 。
use case需要写的很详细吗 ? 其实这个问题如果这样问,use case 需要一开始就写的很详细吗? 还有所有的use case都需要在开始的时候就写的很详细吗? 我认为这会由于你是不是支持迭代而有所不同 。 而统一的答案是没有的 。
那么能详细到什么程度呢 实际上对use case描述的详细程度一直是一个没有统一答案的问题 有各种各异的说法 当然可能在瑞理那里你会得到的答案是统一的 但是你记住use case不是瑞理私有的一种技术 所以你应该可以建立起符合自己组织实际情况的一套标准 而你这里说的详细标准 我看是指的说明的详细程度 而不是对use case粒度划分的程度 这不是大问题 其实我看只要你可以把你的业务流程表叔清除 而没有角色和动作的遗漏就可以了 当然不要忘记前置和后置条件
use case实际上是一种需求的分析工具 而且它之停留在系统的外部 而不应该试图去用它来说明系统内部的运行情况。系统内部的运行情况是你的设计工作所要解决的问题 所以你不管对use case书写多么详细 也不可能代替你的设计 不可能会发生coder看着use case直接向里面填写代码的事情发生 但是我不知道你指的复杂的逻辑角色是什么 如果你指的是系统运行时候参与的角色 那么我认为你必须在需求中解决这个问题 也就是你必须在use case中把它们表达清除 而具体如何通过对它们的计算得到最后的结果 则不是use case所包括的必然部分 当然你给出解决方法(可能是客户现在的解决方法 也或许是你从什么地方找到的方法)会有好处
还有我不认为你可能把use case书写到一个对业务完全不懂的coder看过你的use case就能了解业务了 这是不太可能的 当然我不排除有这样的例子 但是如果你试图这样做你就要准备把你的use case书写成一部业务手册 其实use case还是要和客户的现场答疑 顾问的咨询 业务资料的研读等多种方法结合才可能使coder对业务有一个大概的了解 当然即使是这样你依然部可能要求他们吃完领域专家
最后说说用例的粒度问题 这是一个老话题 我在这个地方就回答过多次 我现在依然认为use case的粒度划分没有一个绝对的标准 你只是要做到适合自己使用就可以了 如果你认为增加记录可以是一个use case 那么就是一个use case好啦 这是你的选择 你只是需求对你划分粒度所带来的后果做成评估