从用例到代码：用例分析 软件测试
自从1992年 Ivar Jacobson 发表了关于如何使用用例，从系统用户的角度来提取软件需求的方法的论文之后，这种方法已经逐渐流行起来。但是有一个最常见的问题是：当我得到了用例之后，如何才能把他们用代码实现出来?本文由两部份组成，将会用一个实际的案例来说明这一点。如何从用例中提取需求，并加以分析，进一步将其转化为可以直接进行编码的格式。我希望能够把这一过程讲清楚，这样你在当前的，或是下一个软件项目中就可以使用它们了!
IBM Rational Unified Process(RUP) 提倡通过用例来提取系统中可操作的需求。 1 软件需求说明书，即 Software Requirements Specification (SRS)，包括软件的所有需求，其中包括很多相关的文档。用例就是其中的一个重要部分。 SRS主要包括以下几部分：
用例模型，包括：
用例图：可视化的描述系统用户，和系统为用户提供的服务。
角色定义：用文字描述系统功能，和系统所需的服务。
用例描述：用文字描述系统提供的主要功能。
软件补充规格文档：这个文档包括了整个系统相关的各种需求，和一些与对系统用户和用例都不直接相关的隐藏需求。
在RUP方法中，这个需求文档是后续的分析和设计工作的起点。不同的开发方式，对项目的推动力是不同的，也就会产生不同的文档。如果软件发布之后，你还总是在不停的修补缺陷，你很可能根本没有需求文档。只能从Bug报告中看出，软件已经和最开始设计的样子不一样了。如果你在维护或者改进一个软件版本(比如增加一项新功能)，你可能有一两个用例，他们描述了这些新功能和用户之间如何交互，但是你不会有软件补充规格文档，因为这些功能之外的部分并没有改变。
在这里，用一个虚构的软件项目"green-field" 作为例子。这是一个面向对象的软件项目，使用UML来描述系统中的各种概念与关系。读者需要具有对象和类的基础知识，熟悉UML 版本1.x 或者2.0中的类图、顺序图和协作图。
用例分析活动
下面我们讨论一下RUP中的用例分析。如图1所示，将RUP中结构分析的结果整合起来。
图1： 结构分析的工作流程(early Elaboration)
文章来源于领测软件测试网 https://www.ltesting.net/
