使用用例覆盖需求和指导代码实现

前情描述

这两天和团队小伙伴在讨论关于如何使用用例描述需求的问题，通过咱们的激烈讨论和大神的指点以及本身的理解，
简单的总结一下，以备给没有使用过用例描述需求以及使用的有疑惑的小伙伴一点思路，确定有缺陷，互联网不就是讲究迭代吗，
相信有思考，有讨论，有总结总会玩得转的。
咱们团队主要拿着用例作两件事：
1.保证覆盖全部产品的需求，拿着用例和产品去沟通。
2.保证咱们开发人员在开发的时候不用重复思考，由于咱们的用例要作到伪代码级别。
3.自测，演示，内测，公测阶段均可以参考你的用例。
多说一句，写代码的时候不适合思考，写代码就是体力活。有些小伙伴喜欢需求在写代码的时候去推理，每每着急动手，
到后来就会各类重写，各类推翻。不要笑，说的就是你。
言归正传，下面就介绍如何编写用例

1、写描述

用例的两种表达形式一种是用例图，一种是用例描述。
这里咱们使用的是用例描述。
描述用例的要素：
1.参与者（角色）
参与或操做(执行)该用例的角色。
2.动做（活动）
用例每每会体现一个动做，这个动做就是系统须要完成的功能。
3.目的
简要的描述一下本用例的需求(做用和目的)。
格式大体为：咱们一般使用这样一个模板：“做为一个…（角色）我但愿可以…（动做）这样我就能够…（目的）”
好比：做为一个网站注册用户（角色）我能够在网站上张贴简历（动做），这样我就可让招聘者看到个人简历（目的）。

2、前置条件

就是用户使用这个用例以前须要具有的客观条件，不符合就不能使用这个用例。
好比：某个用例在使用以前要求用户必须是付费的，必须登陆的，必须设置过身份证。
这些要求就是这个用例前置条件，咱们在实现这个用例的时候必须考虑到这些前置条件。

3、检查项

检查项是做为咱们是否完成这个用例的尺子，因此它很重要有用例必然要有检查项，谁也不肯意作没有完成结点的任务。
检查项不只从正常的状况思考，还要从严谨，安全，异常的状况去思考。
好比下面的用例：
做为网站的注册用户我能够进行网站登陆操做，这样我就能够作其余的操做。
针对这个用例的检查项：
从产品需求的维度：
1.可使用设置本身我的信息的功能。
2.能够在页面头部看到用户的部分信息如头像，昵称等。
从系统的维度：
1.多中角色互相访问时会出现什么状况。
2.重复操做某一个功能时。
3.有顺序要求的颠倒一下顺序访问时。
4.用户重复登陆的状况要给予提示。
5.暴力破解密码的状况要给予处理。
6.用户没有填写正确的用户名，密码，验证码等。
7.用户在多处登陆用一帐号要将另一个帐号强行退出。
总之检查项能够帮助咱们验证咱们的用例是否完成，完整。

4、写执行步骤：

执行步骤主要从系统角度触发实现这个用例所须要的事情。
这一点和标准的用例有区别，标准的用例只从用户角度描述。
咱们是从系统角度去看找执行步骤。
不论是系统仍是用户角度都是在描述同一件事只不过是关注点不一样。
好比：你老板让你给他倒一杯茶。
对于你老板来讲就是用户，他只关心你是否可以给他倒一杯茶。
对于你来讲你就是系统，你不只要知道倒茶还要考虑如何实现倒茶的细节，
你须要关心哪里有热水，要放什么茶叶，温度合适不，老板的喜爱是浓仍是淡等等。
因此从系统的角度来描述执行步骤其实就是在描述具体的实现，甚至是伪代码。
注意：
在抽取用例执行步骤的时候，请使用统一抽象层次（咱们抽象不超过5个的步骤）。
用例的步骤描述要到伪代码或者原子级别，什么是原子 ：有对象或者对象的属性。

5、后置条件

后置条件:用例执行完毕后的结果或者状态。
咱们将后置条件做为了用例的检查项。

6、分析页面交互：

页面上的功能能够单独写一个用例，不过要做为这个页面的主用例的子用例。

7、预估时间

每个用例保证一到两天可以完成，太大请拆分。
拆分的时候请注意：
保留主用例的检查项，被拆分的用例也要有检查项。

8、使用worktitle编写用例

1、编写用例描述

2、编写前置条件

3、编写用例检查项

4、编写执行步骤