需求管理
需求管理我放在了理论的最后一部分来说，也是我觉得最难的地方。需求管理的难在于它对测试很重要但是又离测试工作很远。在前面我们说过用例，特别是系统测试用例非常依赖于需求文档，因为用例的期望值也就是最终结果，是通过需求来确定的。所以用例是否正确其实很多时候依赖于需求是否正确。
记得有这样一句英文非常的经典：
Are we build the right product?
Are we build the product right?
这里可以很好的说明到底用例重要还是需求重要。优秀的测试人员往往可以保证product right但是没有正确的需求哪里有rightproduct?所以一个产品没有bug但是不好用、不好卖，其实测试也有一定的责任在里面！
那么需求管理里面有什么呢？我这里会从三个角度来谈需求管理：
1.需求开发
2.需求管理
3.测试需求管理
需求开发
每个人都有自己的需求，在看这篇文章的你也会有需求，只是有些需求是显式的有些需求是隐式的。好比经常问朋友“你找对象有啥要求”，回答总是“没啥要求啊，人好就行”，背后的潜台词就是，看的顺眼的！而所谓看的顺眼的就是自己还挑的，没想清楚条件的，那么等想清楚再说吧。
对于软件开发的客户来说也存在着同样的问题。客户想要的东西，和你理解的东西，到你有能力做出来的东西存在着很大的差距，而导致这个问题的关键就是沟通。
1.BA业务分析人员与客户的沟通
2.开发人员与业务分析人员的沟通
3.测试人员与业务分析人员的沟通
4.测试与客户的沟通
在这里存在着实现能力与客户需求的错位及沟通中的技术衔接模糊，最终导致软件会这样或那样的走样。虽然需求开发是业务分析人员的责任，但是作为一个优秀的测试，为了保证质量，那么也需要有相应的能力走在需求分析人员身边，给他们提供技术和业务逻辑上的一些支持。
想要有能力帮助需求分析人员对需求进行测试，那么作为测试的你必须要么走在客户这边能站在客户的角度分析问题，要么你走在技术这端告诉需求分析人员这个东西技术能实现么，实现了怎么验证。
需求开发涉及到很多技术的内容，最直接的就是在于业务描述上。在业务描述上存在的技术包括业务写作（一般就是写文档）和业务建模（常见是指原型设计），这里常用的工具不但包括一些传统的类似UML的建模工具，还需要像Axure这样的原型设计工具，甚至更专业的UI设计工具，来让用户和开发人员更加简单清楚的知道到底要做什么。
需求管理
对于需求管理来说主要管理需求的内容和关系。内容上可以说的不多，但是需求也会有其规定的格式，尽量保证需求信息的完整性。对于需求的关系，这可能是需求管理中比较重要的内容，何为需求的关系，这里先举个列子：
假如在微信朋友圈你发了个需求你需要一只笔，那么会有很多人看到你的需求，也许他们都有条件帮助你，于是都给你寄了一支笔，然后你就发现笔太多了你要么退回笔要么就需要一个笔筒来放笔，接着你再发一个需求给大家，既然大家给我那么多笔，那么再给个笔筒？悲剧可能会继续轮回。
这里的问题在于：
1.需求的落实可能由很多人来实现，如果没有一个控制策略，每个人都来落实一下需求，可能会导致需求被过分实现，并且导致资源的浪费。（送老奶奶过马路做好事的笑话不知道大家还记得不）
2.需求被落实后带来的后续影响如何控制和维护？当一个需求被实现或者被改变，那么所有下级和相关内容都可能受到影响，如何评估影响的范围以及成本是非常重要的。
在大多数公司遇到的问题都和需求管理有关，问题就是在于对于需求的控制能力，这个控制能力指如何有效的评估需求变更所带来的影响（需求管理的能力越强那么对后续研发测试的影响就小，否则要期待相关部门的能力足够强大了）
一般来说需求管理都是将需求层次化的过程，可以简单理解成类似于二叉树的情况。通过这样的线索关系，可以简单的知道每个需求下的子集需求的数量。工具在这方面可以很好的帮助我们管理这些内容，但是工具无法解决本质上的需求对主需求的覆盖比例维护，并不是说一个需求下有多个需求就一定能够完全分解主需求并且有效覆盖主需求，一旦出现需求遗漏，那么就意味着开发会遗漏而同时测试也会遗漏这个点。
所以本质上工具可以帮助有想法的人更好的管理和处理问题，但是工具并不会让没想法的人多做点啥，反而会被表面所蒙蔽，过多的迎合工具的使用。在需求管理上，这并不是一个测试人员需要过多涉及的泥潭，但是却又是一个优秀测试工程师需要尝试的新天地，因为只有走在前面的人才能真正的把握质量，提高质量。
测试需求管理
前面我们谈到了离测试工作距离比较远的需求管理。那么现在我们来聊一下与测试工作息息相关的测试需求管理。
什么是测试需求？大多数小白们都会把测试需求与需求直接划等号。其实不然，测试需求来源于需求，它是测试人员对于需求的理解归纳与总结。或许可以这么说，好的测试需求提取是测试用例框架设计的重要部分，而好的测试用例框架可以有效地提高整个测试工作的执行效率。特别是针对需求变更频繁或者是业务逻辑复杂的项目，效果尤为明显。
如果你要问如何进行测试需求提取，那么我只能说，每一个项目都有其特殊性，需要对应不同的测试需求提取工作。那么究竟该如何做好测试需求管理？除了以上我们在需求管理中所说的方法及使用的工具，需要大家在工作中不断实践总结。通俗的来说，多写测试用例，多修改测试用例，你会渐渐有了用例框架的概念，也就明白该如何做好测试需求提取及管理工作了。
到这一章为止，关于测试的一些基本理论章节就告一段落了，回顾前面说到的关于测试基础、缺陷管理、用例管理、配置管理到今天的需求管理，力争用最简单朴素的语言来介绍关于那些测试中必须要了解的点点滴滴，让正在阅读的你不觉得枯燥也不会觉得太过简单。
在了解了一些基本理论后，在下一章开始，我将会带着大家来看看关于具体做事的一些点点滴滴了。