如何应用UML用例图描述软件系统的用户需求

用例图当然很好用，不然RUP(Rational Unified Process，统一软件开发过程，统一软件过程)也不会让用例驱动作为核心方法论之一，当然用例图自身也有很多不足，需要其它技术作补充。

?一、优点：?简洁、直观。

是的，确实比较直观，几个小人人、几个椭圆，外加几条不多的线，用一个矩形一框就出来了，了不起再弄个用例描述，系统交互行为很清晰地表达出来。

规范、易理解。

用例图是UML建模里比较常用的一个图，你用，我用，大家都用，并且标识、要素等均符合UML2中的约定，并且不依赖开发语言，所以说它和其它图一样规范因为规范所以对UML建模用户来说是易理解的。

用户导向、描述精准。

用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。

我们不管系统内部实现功能的机制，仅仅把系统看作一个黑盒，然后参与者与其进行交互，也就是用例是基于用户场景的，所以能更精准地表达用户功能需求。

需求与设计分离。

因为用例图是站在系统外的视角描述系统需求的，所以并没有介入到系统内部实现细节，这就让需求和设计工作分离开来，条理清晰。

便于设计测试用例。

用例图描述的就是一个用户场景，测试设计人员正好可以根据用例图设计测试用例。

边界清晰。

一个矩形框把系统边界清晰、明确地表达出来，便于设计人员据此把握系统范围。

敏捷。

用例图允许我们讲故事、写卡片，允许我们比较敏捷地实现功能需求方面的管理与交流。

?二、不足：?不能表达非功能需求。

用例图是描述用户功能需求的工具，对于可靠性、性能等非功能需求无能为力。

对不懂UML的客户或程序员来说难以理解。

对UML支持者来说，用例图可能是规范的、清晰的、简单的、易理解的，但对并未掌握UML建模技术的人来说理解那些椭圆并非易事，再说还有一系列如同伪代码似的事件流。

粗粒度。

是的，用例图不涉及设计实现细节，只是一个功能划分，粒度非常粗，很多细节无从描述，需要用其他工具进行辅助说明。

?三、常见的错误用法和问题：?客户看不懂用例图，又要提供一个高大上（画UML图）的需求规格文档。

这时候怎么办呢？作者建议画客户需要画的，然后把用例图制作成一个个卡片去跟客户讲故事，客户不会连故事都听不懂吧除非你讲故事的水平比画图的水平还拙劣。

架构师或程序员看不懂用例图。

看不懂的话这些用例委实就成了摆设，这时又该怎么办呢？对的，仍旧讲故事，说业务场景并用用例规约加以辅助说明。

用例图涉及到实现细节。

这个要加以避免，如果过早介入系统内部实现细节，过多的系统内部设计描述会让客户和程序员疲惫不堪。

系统边界模糊不清。

建议用例图绘制时从上往下画，比较复杂的子系统可以拆在不同的用例图中。

用例过多。

系统总的用例数不宜超过50个，建议最好是20-30个。

过多的用例必定会有过多的Association、include、extend、generalize等关系，各种关系错综复杂违背了我们使用用例图的初衷。

如何通过测试提高软件质量和可靠性1500字论文

1、软件测试相关概念 （1）软件测试：软件测试是为了发现错误而执行程序的过程。

或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计出一批测试用例，并利用这些测试用例的运行结果来发现程序错误的过程。

（2）软件测试用例：测试用例实际上是对软件运行过程中所有可能存在的目标、运动、行动、环境和结果的描述。

测试用例是测试组织的最小单位，指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并最终形成文档。

软件测试的核心是设计和执行测试用例。

而测试用例的选择问题可以看作是从庞大的输入状态组合中，搜寻哪些可以发现错误的状态组合。

因此需要用抽象的手段来尽量使测试更加有效。

（3）测试用例库：完整的单元测试很少只执行一个测试用例，开发人员通常都需要编写多个测试用例才能对某一软件功能进行比较完整的测试，这些相关的测试用例称为一个测试用例集。

将大量的测试用例收集到测试用例库中，合理的分类后供测试人员选择使用，能够极大地提高软件问题的发现率。

2、提高测试质量的方法 2.1 采用测试性设计技术 软件测试是目前用来验证软件是否能够完成所期望的功能的唯一有效的方法。

但是在测试的实施过程中，由于种种原因导致测试的难度相当大，甚至出现了无法测试的情形。

为了提高软件的可测试性，我们在软件设计时应当遵循测试性设计原则，通过改变设计或代码、为软件增加专门测试结构等方法来提高软件的可测试性。

（1）测试驱动设计。

这种设计就是直接把软件需求变成测试代码。

在确定软件测试性能要求的基础上优先编写测试代码。

先写验收测试，再写单元测试，并在开发过程中不断修正。

（2）每个操作对应一个方法，使方法小型化。

使用小型化方法说明和重载带缺省方法参数的方法，使得测试中调用这些方法变的很容易。

（3）显示与控制分离。

把代码移到GUI视图的外面，各种GUI动作就能成了模型上的简单方法调用。

这样，在修改程序功能不会影响视图，同时通过方法调用测试功能也比间接地测试功能更容易。

（4）对于可能要作为参数的类，做一个接口。

用接口说明外部程序组件或在需要时改变接口形成一个空类作为参数传入。

2.2 选择合适的测试管理模型 模型是系统功能的形式化或半形式化的表示，支持输入状态组合的系统枚举。

基于模型的测试主要考虑系统的功能，可以认为是功能测试的一种。

测试模型体现了被测试系统的最本质的功能关系。

而且要比系统本身更易于开发和分析。

一个可测试的模型要能提供足够的信息用来产生测试用例。

所以可测试的模型必须满足以下要求： （1）必须是某种测试实现的完全准确的反映，模型必须表示要检查的所有特征； （2）是对细节的抽象； （3）可以表示所有事件和所有的动作；⑷可以表示系统的各种状态，以便由可知的方法来确定已达到或没有达到什么状态。