软件测试用例覆盖需求和指导代码实现

软件测试用例覆盖需求和指导代码实现

前情描述

这两天和团队小伙伴在讨论关于如何使用用例描述需求的问题，经过我们的激烈讨论

和大神的指点以及自己的理解，

简单的总结一下，以备给没有使用过用例描述需求以及使用的有疑惑的小伙伴一点思路，肯定有缺陷，互联网不就是讲究迭代吗，

相信有思考，有讨论，有总结总会玩得转的。

我们团队主要拿着用例做两件事：

1.保证覆盖所有产品的需求，拿着用例和产品去沟通。

2.保证我们开发人员在开发的时候不用重复思考，因为我们的用例要做到伪代码级别。

多说一句，写代码的时候不适合思考，写代码就是体力活。有些小伙伴喜欢需求在写

代码的时候去推理，往往着急动手，

到后来就会各种重写，各种推翻。不要笑，说的就是你。

言归正传，下面就介绍如何编写用例

一、写描述

用例的两种表达形式一种是用例图，一种是用例描述。

这里我们使用的是用例描述。

描述用例的要素：

1.参与者（角色）

参与或操作(执行)该用例的角色。

2.动作（活动）

用例往往会体现一个动作，这个动作就是系统需要完成的功能。

3.目的

简要的描述一下本用例的需求(作用和目的)。

格式大致为：我们通常使用这样一个模板：“作为一个…（角色）我希望能够…（动作）这样我就可以…（目的）”

比如：作为一个网站注册用户（角色）我可以在网站上张贴简历（动作），这样我就

可以让招聘者看到我的简历（目的）。

二、前置条件

就是用户使用这个用例之前需要具备的客观条件，不符合就不能使用这个用例。

比如：某个用例在使用之前要求用户必须是付费的，必须登录的，必须设置过身份证。

这些要求就是这个用例前置条件，我们在实现这个用例的时候必须考虑到这些前置条件。

三、检查项

检查项是作为我们是否完成这个用例的尺子，所以它很重要有用例必然要有检查项，

谁也不愿意做没有完成结点的任务。

检查项不仅从正常的情况思考，还要从严谨，安全，异常的情况去思考。

比如下面的用例：

作为网站的注册用户我可以进行网站登录操作，这样我就可以做其他的操作。

针对这个用例的检查项：

正常：

1.可以使用设置自己个人信息的功能。

2.可以在页面头部看到用户的部分信息如头像，昵称等。

异常：

1.用户重复登录的情况要给予提示。

2.暴力破解密码的情况要给予处理。

3.用户没有填写正确的用户名，密码，验证码等。

4.用户在多处登录用一账号要将另外一个账号强行退出。

总之检查项可以帮助我们验证我们的用例是否完成，完整。

四、写执行步骤：

执行步骤主要从系统角度触发实现这个用例所需要的事情。

这一点和标准的用例有区别，标准的用例只从用户角度描述。

我们是从系统角度去看找执行步骤。

不管是系统还是用户角度都是在描述同一件事只不过是关注点不同。

比如：你老板让你给他倒一杯茶。

对于你老板来说就是用户，他只关心你是否能够给他倒一杯茶。

对于你来说你就是系统，你不仅要知道倒茶还要考虑如何实现倒茶的细节，

你需要关心哪里有热水，要放什么茶叶，温度合适不，老板的喜好是浓还是淡等等。所以从系统的角度来描述执行步骤其实就是在描述具体的实现，甚至是伪代码。

注意：

在抽取用例执行步骤的时候，请使用统一抽象层次（我们抽象不超过5个的步骤）。用例的步骤描述要到伪代码或者原子级别，什么是原子：有对象或者对象的属性。

五、后置条件

后置条件:用例执行完毕后的结果或者状态。

我们将后置条件作为了用例的检查项。

六、分析页面交互：

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

七、预估时间

每一个用例保证一到两天能够完成，太大请拆分。

拆分的时候请注意：

保留主用例的检查项，被拆分的用例也要有检查项。