需要剖析是开始测试工作的第一步，产品会先产出一个需要文档，而后会组织需要宣讲，在需要宣讲中剖析需要中是否存在问题，而后宣讲完结后，通过需要文档分析测试点并且预估排期。所以对于需要的了解十分重要。
需要文档
产品经理在做完用户需要考察之后，会依据用户需要输入一份需要文档，在文档中会详细描述用户所需的性能和性能实现的成果。文档生成之后，产品经理会和开发测试一起开一个需要宣讲会，解说需要中的内容，并且会对需要中可能存在的问题进行探讨。
需要评审
在需要宣讲的过程中，其实也须要对需要自身进行评审。需要评审能够从以下角度去进行思考。
业务场景角度
站在使用者的角度，思考用户会遇到的各种状况，反观各种状况在需要中是否都能找对对应形容，即用户故事
依据用户故事应该能构建出简略的流程图，各种门路之间的束缚关系，执行条件是否有明确正当的定义，即业务流程图
性能点角度
数据束缚是否全面、正当
存在分支的逻辑、形容是否笼罩所有门路
多状态流程，状态流转形容是否正当且残缺
权限形容是否明确
在评审的时候，能够从这几个角度进行思考，查看产品写的需要是否欠缺。若需要中有不欠缺的中央，要提出问题并和产品开发一起进行探讨。最终的指标是让需要更正当残缺。
需要剖析
等产品经理把需要最终欠缺好之后，就能够具体的去剖析需要文档。需要剖析简略来讲就是把不直观的需要文档简化为直观的需要。
需要剖析步骤
明确测试范畴：把测试流动的边界确定好，因为很多模块都是有关联关系的，在剖析需要文档的时候，须要看要加的性能和之前的性能耦合性高不高，须要不须要对关联的功能模块也进行测试。
明确性能点：把需要文档中的性能点列出来。
明确业务流程：依据业务流程图梳理。
明确输入后果：不便验证。
剖析异样流程：进步零碎的容错性。
预估测试须要的工夫和资源：为测试计划的编写做好筹备。
为了进步需要剖析能力，就须要深刻的了解需要。
如何进步需要理解能力
熟悉业务，理解零碎。任何零碎都有大的业务背景，只有相熟了业务知识能力更无效的应用零碎。任何零碎在应用过程中，都有一个相熟的过程，对系统越相熟，越容易发现零碎问题和业务问题。
用主观的思考形式站在用户的角度剖析。在满足客户要求的根底上，站在业务或者零碎现有实现的角度，给需要和开发人员一些设计上的倡议。
长于总结，乐于分享。把常常见到的用例设计的误区和一些好的需要剖析实例和需要剖析习惯分享给四周的人，这样能够集众人之所长，一直晋升需要剖析能力。