Use Cases的工业接受
Use Cases第一次被正式的描述是在6年前（1992年），从那以后它就被最主要的面向对象的方法采用，同时作为描述现在和将来的操作模式的有用技术被商业再生工程团体（Business Process ReEngineering Community）采用。
Use Cases最近它们自己取得在UML（Unified Modeling Language）中有效的地位和位置而得到了突出的进步。UML已经被OMG（对象管理组织）计划做为对象系统的标准语言。
什么是Use Cases？
Use Cases本身是用户或其它系统与正在设计的系统的一个交互，是为了达到一个目标。术语Actor（行为者）是用来描述有这个目标的人或系统，这个术语是用来强调有这个目标的任何人或系统。目标的本身是用行为动词开始的短语表达的，如：“Customer : place order”、“Clerk : reorder stock”等。
情节的角色
在Use Cases中不同的情节显示了目标怎样成功或失败，成功的情节是目标达到了，失败的情节是目标没有达到。这个的好处是因为目标总结了系统的各种使用的意图，用户能看到被设想怎样地使用这个系统，并且不必等到出现第一个原型或是比较糟糕的等到系统被开发出来才发现什么时候系统并不全面地支持他们的目标。
Use Cases将做成多大？
试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的情节不容许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。
对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。
Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。
给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。
文章来源于领测软件测试网 https://www.ltesting.net/
