测试基础系列之需求分析
一、前言
半年前，就准备开始写博客来分享我在测试中的点点滴滴，也是记录下我自己的足迹。但由于工作太忙，一直没有开始。“万事开头难”，现在终于开始写了，所有的观点均是个人理解，有什么不对地方，希望大家能指出。
测试基础系列是基于我理解的测试流程来写的，软件测试流程在我的另一篇文章（聊聊测试管理（管事篇））中：http://www.cnblogs.com/weientesting/p/5227572.html 有详细说明。
二、需求分析的意义
相信每一位入行的测试工程师都听过这样一句话：“站在用户的角度去测试”。
所谓的用户的角度，其实就是需求。而需求分析就是要弄清楚用户需要的是什么功能，用户会怎样使用系统。这样我们测试的时候才能更加清楚的知道系统该怎么样运行，才能更好的设计测试用例，才能更好的测试。
三、为什么要进行需求分析
1、把不直观的需求-----转变为-----直观的需求（流程图/思维导图）
- 需求文档通常是图片加文字，很多规则只看文字很难理解的透彻
- 通过流程图/思维导图的形式展现更加直观，更容易理解
2、把不明确的需求-----转变为------明确的需求
- 明确其功能点对应的输出、处理和输出;
- 很多时候产品给出的需求文档不一定非常详细，有很多需求点是需要去跟产品确定的
3、把不能度量的需求----转变为-----可度量的需求
- 将测试范围变成可度量，有利于计算测试用例的覆盖率，从而降低测试风险
- 测试过程中也能清晰的知道，哪些已经测试通过，哪些还没有测试通过
四、如何进行需求分析（两图一文档）
1、明确需求范围
- 了解该需求是为了解决用户的什么问题
- 功能性需求：产品必须有的功能
- 非功能性需求：是否美观，用户体验，稳定性，易用性等
- 最容易忽略的一点：明确的需求背后所隐藏的需求（例如登录，明确的需求是，正确输入用户名，密码，才能登录。隐性需求：用户名字符类型，长度，是否可为空；密码字符类型，长度等）
- 将问题在需求阶段暴露的成本最小
2、画业务流程图（流程图）
- 根据需求中规定的业务流程
- 各业务流程分支的确定
- 由于业务原因规定不可使用的业务流程
3、功能点整理（思维导图）
- 业务功能：需求中所定义的实际业务直接相关的功能
- 数据约束：主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。
- 易用性需求：便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。
- 编辑约束：在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。
- 权限需求：不同的权限所能操作的功能点的不同
4、提取测试点（测试需求文档）
根据整理的思维导图，去提取每一个功能点中的细节需求，例如新增员工，在思维导图中，最小的颗粒度就到新增员工了，但是新增员工这个功能仍然有很多的需求点，员工姓名唯一性判定，手机号码是否必填等，这些更细的需求点组合起来就形成了测试需求文档
5、确定测试范围
- 需求的确定，并不代表测试范围就是该需求的范围，很有可能一个需求分多个软件版本来实现，最后确定哪些需求是需要测试的。
- 明确哪些测试目标优先级高，哪些目标优先级低
- 要完成哪些相应的测试任务才能确保目标的实现
五、结语
需求分析的越详细，对业务的理解程度就越高，对设计测试用例的帮助就越大。测试的过程中就更有目的性。“磨刀不误砍柴工”，需求分析花的时间越多，之后测试的时间就越少。因为测试其实已经从需求阶段开始了。
