需求分析是开始测试工作的第一步,产品会先产出一个需求文档,然后会组织需求宣讲,在需求宣讲中分析需求中是否存在问题,然后宣讲结束后,通过需求文档分析测试点并且预估排期。所以对于需求的理解非常重要。
需求文档
产品经理在做完用户需求调查之后,会根据用户需求输出一份需求文档,在文档中会详细描述用户所需的功能和功能实现的效果。文档生成之后,产品经理会和开发测试一起开一个需求宣讲会,讲解需求中的内容,并且会对需求中可能存在的问题进行讨论。
需求评审
在需求宣讲的过程中,其实也需要对需求本身进行评审。需求评审可以从以下角度去进行考虑。
业务场景角度
- 站在使用者的角度,考虑用户会遇到的各种情况,反观各种情况在需求中是否都能找对对应描述,即用户故事
- 根据用户故事应该能构建出简单的流程图,各种路径之间的约束关系,执行条件是否有明确合理的定义,即业务流程图
功能点角度
- 数据约束是否全面、合理
- 存在分支的逻辑、描述是否覆盖所有路径
- 多状态流程,状态流转描述是否合理且完整
- 权限描述是否明确
在评审的时候,可以从这几个角度进行考虑,检查产品写的需求是否完善。若需求中有不完善的地方,要提出问题并和产品开发一起进行讨论。最终的目标是让需求更合理完整。
需求分析
等产品经理把需求最终完善好之后,就可以详细的去分析需求文档。需求分析简单来讲就是把不直观的需求文档简化为直观的需求。
需求分析步骤
- 明确测试范围:把测试活动的边界确定好,因为很多模块都是有关联关系的,在分析需求文档的时候,需要看要加的功能和之前的功能耦合性高不高,需要不需要对关联的功能模块也进行测试。
- 明确功能点:把需求文档中的功能点列出来。
- 明确业务流程:根据业务流程图梳理。
- 明确输出结果:方便验证。
- 分析异常流程:提高系统的容错性。
- 预估测试需要的时间和资源:为测试计划的编写做好准备。
为了提高需求分析能力,就需要深入的理解需求。
如何提高需求理解能力
- 熟悉业务,了解系统。任何系统都有大的业务背景,只要熟悉了业务知识才能更有效的使用系统。任何系统在使用过程中,都有一个熟悉的过程,对系统越熟悉,越容易发现系统问题和业务问题。
- 用客观的思考方式站在用户的角度分析。在满足客户要求的基础上,站在业务或者系统现有实现的角度,给需求和开发人员一些设计上的建议。
- 善于总结,乐于分享。把经常见到的用例设计的误区和一些好的需求分析实例和需求分析习惯分享给周围的人,这样可以集众人之所长,不断提升需求分析能力。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!