前一段时间一直在忙于编写用例，这着实让我体味了一把编写好的用例的不易。
用例代表着系统中各个项目相关人员之间就系统的行为所达成的契约。在面向对象的需求分析中，得到系统的功能需求最方便的方式就是识别用例，而且这些用例扮演着很重要的角色（看看RUP吧）。因此我们将着重讨论在作为系统功能性需求的用例，而不涉及其它种类的用例。
也许你应该抽空阅读一下这篇文章《用例建模指南》。你将对用例的编写有一个全面的认识。而下面将给你更详细的建议：
1． 用例之间要保持独立。不要让用例之间存在依赖关系和前后顺序。
2． 一个完整的用例必须完整的描述执行结果。基本流和备选流一个都不能少。
3． 在用例中不要描述设计。用例应该着重于what而不是how。比如“系统将结果保存到xml中……”这就掺杂了设计的成分在里面了，也许这样会更好些——“系统保存结果……”
4． 在用例中不要涉及GUI。
5． 使用序号和题目来标注用例中的基本流程。
6． 在基本流中不要引用备选流。基本流中引用了备选流，说明基本流的成功执行会受到备选流的影响，这肯定是不合理的。也许你的基本流囊括了太多的东西，也许是你将一个独立的用例塞到了备选流里面。
7． 备选流中要描述是从基本流中哪个步骤或者其它备选流中开始的。
8． 备选流中要描述触发的原因。
9． 不要编写CRUD用例。CRUD即对数据库的读写改查，不建议为每一个操作创建一个用例。而是作为一个用例来写。在基本流中会有类似与例子中的语句：
系统展示功能给管理员，有新建合同、编辑合同、查询合同、删除合同，管理员选择编辑合同……
而在备选流中，相应的要创建剩余的其它流程：新建合同、查询合同、删除合同……
当然，有些时候将其拆分到单独得用例中是有意义的。比如权限问题的限制。而大多情况下那只会让用例数量剧增，并影响你的心情。
系统展示功能给管理员，有新建合同、编辑合同、查询合同、删除合同，管理员选择编辑合同……
而在备选流中，相应的要创建剩余的其它流程：新建合同、查询合同、删除合同……
当然，有些时候将其拆分到单独得用例中是有意义的。比如权限问题的限制。而大多情况下那只会让用例数量剧增，并影响你的心情。
10． 用例中要体现出必要的重复过程。例如“管理员可以重复3-6步骤，直至满意为止”。忽略了这句话可能会影响页面流的设计。
11． 不要编写重复的用例。当两个用例中都有大段的过程重复，也许你应该考虑将其独立出来作为一个include用例（关于include、extend的区别请看《RUP之用例间的关系》）。
12． “如果”的使用。先看下面的例子：
X.X 关闭设计界面
如果设计人员未对设计内容进行修改，则系统直接关闭界面；否则保存设计人员修改后的数据并关闭设计界面。
X.X 关闭设计界面
如果设计人员未对设计内容进行修改，则系统直接关闭界面；否则保存设计人员修改后的数据并关闭设计界面。
这里面使用如果来判断执行条件。这很类似于程序设计的风格，但是可能难于跟踪、实现和测试。好了，让我们去掉如果的判断：
X.X 关闭设计界面
设计人员未对设计内容进行修改，系统直接关闭界面。
设计人员未对设计内容进行修改，系统直接关闭界面。
Y.Y 关闭设计界面并保存修改数据
系统保存设计人员修改后的设计数据并关闭设计界面。
这就好理解多了，也容易跟踪了，但是你的用例中会多出很多繁琐的流程。
这就好理解多了，也容易跟踪了，但是你的用例中会多出很多繁琐的流程。
那到底用不用如果语句呢？这还要由你的团队来决策（就上面的例子而言，我更倾向于使用如果语句）。
13． 流程的顺序真的考虑全面了？你想过没有，用户为什么非要在第四步才开始访问数据库，而不是在一开始。如果这是可行的，那你就漏掉了一种场景。而这就可能影响到后续的设计。不要想当然的将它放在第四步，而是在用例中将可选的情况描述清楚。
14． 记得给你的用例分配权重。用例之间没有顺序，但是却存在着优先级。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=784995
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=784995
