通过需求文档了解需求的实现背景

拿到一个需求后，我们首先应该通读需求文档，先通过需求文档，对要做的需求的背景有个整体的了解，其实这个过程也是对需求文档测试的过程，对需求整体的了解后，我们可以先记录自己的一些疑惑，为后面需求的分析做一个准备工作，这个环节我们应该更多的了解一些需求的目的和一些用户的使用场景。

例：3.3版本大立案流程需求，需求文档中对于业务场景给了一个流程图

保密要求-图片忽略 

从需求示意图中我们大致可以了昆明大立案的整个流程，使用的法院只有中院与基层院，主要是一个案件在基层院与中院的流转过程，使用的人员主要是法院的立案庭的人员，但是我们不知道涉及的案件主要有哪些，以及出现这样的场景是基于哪些业务逻辑，这些都是我们接下来要和需求人员了解的，这是我们分析这个需求和设计用例的基础，也是我们分析需求合理性的依据。

2、     分析需求合理性

可以通过业务知识来分析需求的合理性，而不是单单通过系统是怎样实现的来判断需求是否合理，这也是测试人员必备的技能之一，即需要我们有深厚的业务功底，然后在通过结合系统现有的实现来分析需求的合理性。

在我看来需求是否合理主要包括两个方面：第一，满足客户需求。第二，在系统原有的基础上，尽量减少改动成本。

3、     确定测试的范围和优先级

通过以上对需求的分析，我们就可以确定测试的范围和优先级了。首先我们要确定好这个需求所涉及的全部测试点，然后通过分析，分析出测试范围的优先级。

4、     细化测试点并确定测试方法

确定了测试范围和优先级后，就可以对各模块进行细化，可以用MindManager列出个模块下的测试点，各模块或大的测试点需要写出对应的测试方法，或测试策略。是否需要性能测试、白盒测试，是否需要提前准备数据，或会遇到什么样的测试难点，采取怎样的应对措施。

5、     确定哪些工作测试人员可以提前介入

根据以往的经验我们都知道，在开发一个比较复杂的需求的周期中，测试的前期准备工作通常都是比较充足的，当然特殊情况除外，因此在确定了测试范围和优先级后，测试人员和测试负责人应该先确定一下哪些需求测试是可以提前介入的，比如，15FB新增新案件来源和新结案方式字段的需求，前期的新旧关系对应文档，测试就是可以提前进行介入，在需求完成了对应关系文档后，测试在进行重新梳理一下，这样既提高了文档的可靠性，也相当于测试提前介入测试了，规避了后面的测试的进度风险和质量风险。

6、     查缺补漏

做完了需求的细化后，要对自己做的需求分析从头到尾在捋一遍，查看有没有什么遗漏的，因为需求也又可能遗漏的地方。主要关注有没有场景需求没有考虑全面， 涉及的修改范围被遗漏了，以及一些特殊的关联配置没有考虑到的，另外如果需求做了一些变动也要及时补充需求分析，主要是分析变动可能带来的风险，以及准备哪些应对之策。