测试用例入门（五）-如何进行需求分析

== 本篇文章已在同名公众号【软件测试必备技能】发布，关注并发送【测试用例】可免费阅读。 ==

需求文档对于测试用例来说，就是测试可以通过的标准之一。

• 需求文案是一份产品说明书，用来定义软件是什么样的。
• 所以需求文档是测试用例的标准中的最重要的一项，我们大部分用例设计的目的，首先就要满足需求文档的设计。
  

一、需求评审

在开始提炼测试点时，首先要对需求进行审查，这其实也是我们平时常说的需求评审：

1. 需求审查并不是拿到需求就立马开始扣细节，而是站在一个高度上进行审查——是否存在根本性的问题、疏忽和遗漏之处。特别是持续迭代的产品，很有可能存在因未考虑旧版本功能，而造成的遗漏。
   • 就像以前在学校时老师教的，“考试，拿到试卷不要立马开始做题，先把整张卷子看一遍，要对整张试卷有一个大致的印象”
2. 其次应该要了解这个需求，知道在这个需求后诸多的为什么和怎么做，这样在设计用例时，才能设计出更符合业务逻辑的用例。
   • 虽说测试是要站在用户的角度思考，但其实并不完全是这样的。举个例子，应用中的广告无疑是降低用户体验的功能，但对于业务来说却是一个收益来源，在这种情况下测试用例的设计应该以业务优先。
3. 再来看需求文档的细节，描述上是否有不准确的地方、或是自相矛盾的地方，甚至是漏洞、bug。
   • bug的发现的时间越早，修复成本就越低，如果能在需求评审时，就可以修复软件的缺陷，无疑成本是非常低。
4. 还要考虑需求的可测试性，有没有不可测试的情况，以及这个需求的测试量能否满足工期安排。

二、从需求中提炼功能点

• 首先要明确一点，万物皆可测。在做需求分析时，不仅要会分析熟悉的业务，也要能够分析陌生的业务需求，甚至不是软件的需求都要能够进行需求分析。

• 测试点提炼第一步，明确待测的目标。目标可能是输入框、是按钮或是状态、流程。
• 目标明确后，第二步，再提炼功能点：
  • 如果待测目标是应用内的数据
    1. 边界，比如手机号限制11位；
    2. 类型，还是比如手机号是由纯数字组成；
    3. 来源，比如账号中心页面用户的昵称，来源于用户设置时的昵称；
    4. 属性，比如是否必填；
    5. 格式，比如日期显示的格式是 xxxx-xx-xx还是xxxx.xx.xx；
    6. 规则，比如数据的默认值，或是注册时，手机号必须是没有注册过的手机号
    7. 容错处理，比如，手机号只有11位，当超出11位或不