1.什么是需求
需要的东西、是确定系统必须完成哪些工作。例如：微信、QQ等，整明白用户需要什么需求，如何去使用这个操作系统（web、app、嵌入式），才能写好测试用例继而去执行测试。
测试需求分析是测试工作的第一步，经过需求分析，对原始需求列表中列出的每一个需求点，找到我们需要测试的测试要点；针对所确定的测试要点，分析测试执行时对应的测试方案/方法。
需求分类：显性需求与隐性需求
显性需求：需求规格说明书有明确定义的功能
隐性需求：需求规格说明书未明确定义但是需要考虑到的功能
需求分类（功能性需求，非功能性需求（性能、易用性、可维护性））
要了解需求这些是必须要知道的
需求的本质是：解决用户问题
测试的本质是：发现缺陷
什么是缺陷：根据需求规格说明书需要检验功能预期结果与实际结果不相符称BUG，也就是平时大家说的缺陷
2.用户需求分解：
用户需求：描述了用户使用产品必须完成的任务，需求文档需要描述明确
业务需求：反映了组织机构或客户对系统、产品高层次的目标要求
功能需求：定义了开发人员必须实现的软件功能。
界面需求:用户体验，界面优化、
3.了解需求的方式
1. 与开发人员、项目（产品）经理，【总之就是能解决你问题】交流
2. 直接与客户交谈。如果分析人员生有足球评论员的那张“大嘴”，就非常容易侃出需求有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行家。有些高手真的很厉害，你还没有开始问，他就能讲出前因后果。让你感到“听君一席言，胜读十年书。”
3. 有很多需求可能客户与分析人员想都没有想过，或者想得太幼稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。前人既然付了学费，后人就不要拒绝坐享其成。
4.咋做需求分析
1）功能分析方法
那怕是天下最无能的市长或书记，都知道在作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B、C、D、E；需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题。
功能分析法功能分解法以系统提供的功能为中心来组织系统。首先定义各种功能, 然后把功能分解为子功能, 同时定义功能之间的接口。数据结构是根据功能/子功能的需要设计的。 其基本策略是以分析员的经验为依据, 确定新系统所期望的处理步骤或子步骤, 然后, 将问题空间映射到功能和子功能上。
2、数据流方法
周末，小明一觉醒来突然想吃红烧肉，那想得口水直流，于起床，穿好衣服，打开钱包一看空的，好吧，先去银行取钱，然后去菜那买了一肉、各种配料，然后回家，开火，各种材料往锅里一放，开始小火慢炖，半个小时后，小明终于吃上了美味可口的红烧肉。这是一个典型的流程，如果把它看成一个系统功能的话，那么小明吃到红烧肉是这个功能的目的，那么中间要经历许多环节，起床穿衣—取钱—习材料—-制作完成。而且各个功能（步骤）之间是相互联系的，小明总不能不穿衣服直接去取钱吧。
数据流法也叫结构化分析, 其基本策略是研究问题域中数据如何流动以及在各个环节上进行何种处理, 从而发现数据流和加工。 问题域被映射为由数据流、加工以及文件、端点等成份构成的数据流图(DFD) , 并用数据字典对数据流和加工进行详细说明。这种方法的关键是动态跟踪数据流动。
5.为什么要做需求分析
1、需求分析的必要性
如果把测试活动比作软件生命周期，测试需求分析就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求，所以需求分析是整个测试活动必不可少的环节。
2、不做需求分析的后果
不做需求分析或需求分析不到位，可能会产生很严重的问题，比如：
（1） 浪费时间和资源实现了用户不需要的需求；
（2） 遗漏了需求文档中没提到，但很重要的需求，导致客户满意度降低。
（3） 需求分析不到位，错误的估计了测试的工作量，导致延误发布周期，可能会降低发布质量。
以上的几个问题，在实际开发中是比较常见的，主要的原因就是需求分析不到位，会导致影响客户的满意度。
6.怎么做需求分析
1） 通过需求文档了解需求的实现背景
拿到一个需求后，我们首先应该通读需求文档，先通过需求文档，对要做的需求的背景有个整体的了解，其实这个过程也是对需求文档测试的过程，对需求整体的了解后，我们可以先记录自己的一些疑惑，为后面需求的分析做一个准备工作，这个环节我们应该更多的了解一些需求的目的和一些用户的使用场景。
2） 分析需求合理性
可以通过业务知识来分析需求的合理性，而不是单单通过系统是怎样实现的来判断需求是否合理，这也是测试人员必备的技能之一，即需要我们有深厚的业务功底，然后在通过结合系统现有的实现来分析需求的合理性。
在我看来需求是否合理主要包括两个方面：第一，满足客户需求。第二，在系统原有的基础上，尽量减少改动成本。
3） 确定测试的范围和优先级
通过以上对需求的分析，我们就可以确定测试的范围和优先级了。首先我们要确定好这个需求所涉及的全部测试点，然后通过分析，分析出测试范围的优先级。
4） 细化测试点并确定测试方法
确定了测试范围和优先级后，就可以对各模块进行细化，可以用MindManager列出个模块下的测试点，各模块或大的测试点需要写出对应的测试方法，或测试策略。是否需要性能测试、白盒测试，是否需要提前准备数据，或会遇到什么样的测试难点，采取怎样的应对措施。
5） 确定哪些工作测试人员可以提前介入
根据以往的经验我们都知道，在开发一个比较复杂的需求的周期中，测试的前期准备工作通常都是比较充足的，当然特殊情况除外，因此在确定了测试范围和优先级后，测试人员和测试负责人应该先确定一下哪些需求测试是可以提前介入的。模块与模块之间没有必要的衔接关系的时候，开发将这个功能模块做完后没就可能你要接收去测试。
6） 查缺补漏
做完了需求的细化后，要对自己做的需求分析从头到尾在捋一遍，查看有没有什么遗漏的，因为需求也又可能遗漏的地方。主要关注有没有场景需求没有考虑全面， 涉及的修改范围被遗漏了，以及一些特殊的关联配置没有考虑到的，另外如果需求做了一些变动也要及时补充需求分析，主要是分析变动可能带来的风险，以及准备哪些应对之策。
最后在说公司再小，哪怕只有你一个测试的时候更得去做需求分析。可能以上的经验比较适合大公司，但根据自己所在公司的规模、资源分配情况适当进行增删。
软件需求规格说明书，是需求分析阶段得出的最主要的文档，如果没有怎么办？
我们公司呢是小公司，项目经理很明确的告i诉我们说我们是小公司，是不会花时间写需求文档的，这种情况真的是想骂街，WHAT！！！！，真的是年轻气盛，因为没有需求我们仍然要测试
1、自主研发项目。主动了解做这个功能的背景，意图，要去解决一个什么样的问题， 这个可以找产品或者开发要，或者谁要求做这个功能的人要，知道这些后，测试的时候才心中有数，知道功能实现对不对
2、 因为没有需求说明书，可以参考原型为依据，采取这样思路操作，测试的时候边测试边记录测试的点，然后组内把这些测试点评审下，看看是否还有遗漏的地方，然后着手开始编写测试用例。