编写有效用例

我可以说，我终于看完了吗...这本书我两天看了两遍。总得来说，收获一般，一方面是因为翻译，感觉就像是机器翻译的，看着那翻译我能推出原文的结构，看着文字就是它认识我我不认识它；另一方面，是因为和预想的有点不大一样，就我目前的经历来说，很多地方看起来还没啥感觉，也许过两年就有感觉了。

1. 我为什么要看这本书

我做了4年的需求分析，唯一写过的用例就是测试用例。写这本书之前，我以为这本书是关于怎么通过写测试用例来检验需求质量的，结果发现只对了一半。但是总的来说，还是学到了不少东西，对以后写需求文档会有帮助。

2. 从书中获得比较大的收获是什么

对于我而言，要充分把这本书用起来，就要想想如果让我做一个新的架构，或者是做一个新的功能模块，我要怎么着手，从0做到1. 以下是我从书里摘抄出来的，比较有用的。

1. 概要用例是描述整个系统或者整个模块要做什么事情。只需最简洁的语言，确保所有项目相关人员都明白我们在做什么，并且确定大家都同意接下来要做的事情。

2. 在描述用例的时候，其实一共要描述四个部分：概要，主功能场景，失败情况，失败处理情况。这其实是四个层次，要先描述第一层，做完第一层之后再做第二层。不要马上开始深入讨论主要场景或者失败处理情况，这样很浪费精力，也容易精疲力尽，更重要的是，当上层用例出现问题的时候，前面的功夫就全部白费了。

3.在描述的时候，把一些用户用例紧密联系在一起，显示它们是如何与业务方针相配套的。它描述了关闭，清除和获得一个申请的过程，而该项目中的许多人对这些内容都不太了解。尽管其中有一些步骤并没有为编程人员做什么工作，但是它们还是处理申请事务情节中的一部分。对于每位读者来说，他们都是很重要的信息。

4. 在编写用例的时候，一定要考虑两种情况：最小保证和成功保证。最小保证是指当用例失败的时候，对项目相关人员的保护，实现对他们的最低承诺。常常容易被忽略的最小保证即是系统将其执行进度情况记入日志。而成功保证则是说明项目成功之后，项目相关人员的哪些利益会得到满足。

5. 我们在描述场景的时候，经常会从系统内部来看并描述外部世界。这个其实是不对的，应该是俯视，这样才能看清项目相关人员与系统的交互，并了解相关人员的目标。

比如，我们经常会写成“读取ATM卡和PIN号码，并从账号余额中扣除一定数量”，但是正确的俯视的写法是：用户插入ATM卡并输入PIN。

用例是什么

三个重要概念

重要定义