任何事情都是先知道自己要什么，然后再想着要去怎么实现、得到自己要的东西。当然软件开发也不另外。作为测试人员，虽然我们不需要像产品经理一样挖空心思的去寻找需求，大多数时候我们都是被动的接受需求。但是，是不是产品给什么需要，开发就研发什么需求，测试就测试什么需求呢？答案肯定：不是的。我们常说：测试不应该只是一个tester，而应该是一个QC（Quality Control），QC需要对每一阶段或者关键点的产出物进行检测，评估产出物是否符合预计的质量要求。另外，需求是我们的目标，如果目标都不够详细清楚，那在保证这个目标这个过程中就会存在很多问题。所以在前期我们测试人员一定要非常清楚需求是什么？怎么实现？实现结果是怎样？
首先，我们把需求按来源进行分类：
确认需求类型后，再根据需求类型进行分析，接下来就先谈谈我对需求的分析的一些理解及方法。
一、需求产出物----需求文档是否符合书写要求？
需求是我们软件开发的第一阶段，需求文档便是这第一阶段的产出物。做为一个QC是需要从这一阶段开始保证质量。因为需求文档不仅是测试的依据也是后来者了解产品的依据。但就目前很多公司实际情况来看，大多数产品经理给出的需求文档是不完整详细的，尤其是敏捷开发模式下。想要一份完整详细的需求文档，往往因‘时间来不及’而不了了之。但如果没有一份详细完整的需求文档，那么接下来的需求理解中就会出现因人而异的理解。
例如，添加修改手机号功能。产品经理提出需求就只是一句话说：在某个页面增加一个修改手机号的入口及功能。面对这样的需求文档。我们测试是无法确定该需求具体是要做成什么样的，比如说，已实名用户与未实名用户都是走同一流程去修改手机号吗？修改手机号后会影响哪些原来业务呢？等等不明确的问题。所以我们根据检测需求文档是否完善的标准项，进行逐条检查。
当这些内容要求清楚了后，我们可以让产品方按要求提供需求文档，并且提供的内容是完整，明确的。尤其需求评审后，要根据评审结果进行补充完整。在项目比较赶时，我们可以再根据需求大小进行灵活安排，大的复杂的业务需求，则按原要求提供。小的需求则可以适当放宽，但不能缺少业务关键内容。
在这个阶段，我们测试也不能单纯的根据这些项来检查否是，目的是需求够明确，所以我们在需求评审前尽量能够根据需求文档进行梳理，如：根据自己的理解画出业务逻辑脑图等，有不明确的标注出来，在需求评审时进行确认，需求评审后也根据评审结果进行补充完善。
二、需求评审流程
我们进行需求评审的目的是确认需求的明确性、完整性、可行性。需求风险常常是软件开发过程中最大的一个风险，要降低需求阶段带来的风险，就要把需求评审做好。而需求评审做不好的后果是：需求变更，需求不明确，需求不可测，需求不可实现。导致后续工作难于开展或经常出现变更，造成效率低下，浪费人力、时间等。
例如，团队中经常会出现这种情况：产品提出需求到发出评审会议，中间都不会给参与需求评审的人员预留了解分析需求文档的时间，导致在评审期间整个评审会议变成了一个需求培训会议。而实际上我们参与评审应该是带着问题而来的。此外，我们因基本每个人会有多个项目，在需求评审的时候会出现时间冲突。出现谁有空谁去参加评审。对参与需求评审的人没有一个合理的安排等等,而实际上我们应该首先要保证使不同类型的人员的都要参与进来，在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，选择有经验的，而不是有时间的人。主要执行人员必须参加。因此，我们应该一个可参考的流程去确保我们的需求评审是有效的：
流程制定后，可以在项目组同步，让项目参与人员都参与到这个制定的流程中来。争取流程得到遵守，从而保证需求评审是有效。此时测试人员在中间做为重要参与者，对必要流程未执行时可起主导作用。
三、需求的实现方法
我们一直强调测试人员要了解需求的实现方法才能更深入的理解需求，制定出更完善的测试方案。我们只有在清楚的知道需求怎么实现的，采用的是什么方法，运用了哪些逻辑。在清楚这些后，我们的测试就不会只停留在简单的输入，输出结果上了。
比如说，我们上述的需求：增加修改手机号功能。那我们的开发可能用RN去研发，也可能是用Native，还可能是H5。那如果我们去了解清楚开发用的是哪种方法，那我们就可以根据这不同的实现技术去制定不同的测试方案。比如，用RN研发我们就不需要IOS，Android两个系统都测试一遍业务逻辑了，而且如果是用Native则需要两个系统都测试一遍业务逻辑且保证两个系统的一致性。再比如，修改手机号流程中判断新手机号与原手机号是否一致，是再次请求一个数据库的结果进行比对，还是直接拿本地缓存的手机号进行比对？这个时候我们测试的注意项又有所不同了。
对于了解需求实现方法这一项，我们可以在需求评审的时候了解清楚，也可以研发阶段私下线下向开发人员了解清楚。对于需求实现方法这块，很多人会放到单元测试、白盒测试阶段时候去了解。这里我建议尽量提前了解，因为提前了解对我们的测试策略制定及用例编写有很大的参考价值。
四、需求的衍生影响
我们在需求评审的时候就强调参与评审的人最好是对系统有足够了解的，且有经验的人员参与进来。目的就是为了评估、明确需求的衍生影响。我们很多项目需求都是在原有的需求上进行研发，改进。甚至有些需求是不会动到原有业务逻辑，只是做一些代码重构优化或者框架升级、性能升级等。此时业务需求及其它非业务需求的需求分析就大不相同了。
[if !supportLists]1.[endif]首先我们看业务需求的衍生影响确认：业务需求大多数为新增或修改需求，都会影响到原有的业务逻辑。就像我们刚刚说的修改手机号，PC端直销银行与客户端手机银行的账号是可共用的，那么客户端手机号修改成功后是否会同步到PC端呢？从业务上讲，修改手机号成功后其它如首次充值，消息通知等有用到手机号的功能是否有同步到新的手机号呢。这些都是新需求带来的衍生影响，且都是需要我们进行回归测试验证的。因此，我们在业务需求分析的时候一定要明确需求的衍生影响并罗列出来，进行回归补充测试。保证新需求实现的同时不影响其它功能的使用。
[if !supportLists]2.[endif]非业务需求很多时候是不会影响原有逻辑，但不排除像构架升级需求是去掉某个中间服务，变成直接调用类的需求时就会影响到后端业务逻辑的变化。此时我们可以让开发提供架构图，测试时就不仅要回归前端相关业务，还要关注后端是否是按升级后的进行处理的。甚至有的是需求根据架构图从日志中才能验证的。还比如一些安全性的需求，如登录密码加密方法升级，衍生影响就涉及原有数据、本地才加密方法的缓存数据等。测试的时候就不仅是检查登录密码是否按新的加密方法进行加密传输，还要测试缓存数据在升级后是否还能正常解析可用。对于非业务性需求，我们往往是不能在明确感受到业务逻辑的变化的。所以在需求分析上也要考虑接口调用，日志记录等等非业务方的影响。
下面简单罗列了一些分析方法可供参考。
