测试之道 首页 测试文章 测试资讯 查看内容

测试基础系列之需求分析

2016-3-7 21:17| 发布者: laura| 查看: 3055| 评论: 0

摘要: 一、前言   半年前,就准备开始写博客来分享我在测试中的点点滴滴,也是记录下我自己的足迹。但由于工作太忙,一直没有开始。“万事开头难”,现在终于开始写了,所有的观点均是个人理解,有什么不对地方,希望大 ...


一、前言

  半年前,就准备开始写博客来分享我在测试中的点点滴滴,也是记录下我自己的足迹。但由于工作太忙,一直没有开始。“万事开头难”,现在终于开始写了,所有的观点均是个人理解,有什么不对地方,希望大家能指出。


  二、需求分析的意义


  相信每一位入行的测试工程师都听过这样一句话:“站在用户的角度去测试”。


  所谓的用户的角度,其实就是需求。而需求分析就是要弄清楚用户需要的是什么功能,用户会怎样使用系统。这样我们测试的时候才能更加清楚的知道系统该怎么样运行,才能更好的设计测试用例,才能更好的测试。


  三、为什么要进行需求分析


  1、把不直观的需求-----转变为-----直观的需求(流程图/思维导图)


  需求文档通常是图片加文字,很多规则只看文字很难理解的透彻


  通过流程图/思维导图的形式展现更加直观,更容易理解


  2、把不明确的需求-----转变为------明确的需求


  明确其功能点对应的输出、处理和输出;


  很多时候产品给出的需求文档不一定非常详细,有很多需求点是需要去跟产品确定的


  3、把不能度量的需求----转变为-----可度量的需求


  将测试范围变成可度量,有利于计算测试用例的覆盖率,从而降低测试风险


  测试过程中也能清晰的知道,哪些已经测试通过,哪些还没有测试通过


  四、如何进行需求分析(两图一文档)


  1、明确需求范围


  了解该需求是为了解决用户的什么问题


  功能性需求:产品必须有的功能


  非功能性需求:是否美观,用户体验,稳定性,易用性等


  最容易忽略的一点:明确的需求背后所隐藏的需求(例如登录,明确的需求是,正确输入用户名,密码,才能登录。隐性需求:用户名字符类型,长度,是否可为空;密码字符类型,长度等)


  将问题在需求阶段暴露的成本最小


  2、画业务流程图(流程图)


  根据需求中规定的业务流程


  各业务流程分支的确定


  由于业务原因规定不可使用的业务流程


  3、功能点整理(思维导图)


  业务功能:需求中所定义的实际业务直接相关的功能


  数据约束:主要是用于控制在执行功能时,数据的显示范围、数据之间的关系等。


  易用性需求:便于功能操作使用的一些细节,比如快捷键就是典型的易用性需求。


  编辑约束:在功能执行时,对输入数据项目的一些约束性条件,比如只能输入数字。


  权限需求:不同的权限所能操作的功能点的不同


  4、提取测试点(测试需求文档)


  根据整理的思维导图,去提取每一个功能点中的细节需求,例如新增员工,在思维导图中,最小的颗粒度就到新增员工了,但是新增员工这个功能仍然有很多的需求点,员工姓名唯一性判定,手机号码是否必填等,这些更细的需求点组合起来就形成了测试需求文档


  5、确定测试范围


  需求的确定,并不代表测试范围就是该需求的范围,很有可能一个需求分多个软件版本来实现,最后确定哪些需求是需要测试的。


  明确哪些测试目标优先级高,哪些目标优先级低


  要完成哪些相应的测试任务才能确保目标的实现


  五、结语


  需求分析的越详细,对业务的理解程度就越高,对设计测试用例的帮助就越大。测试的过程中就更有目的性。“磨刀不误砍柴工”,需求分析花的时间越多,之后测试的时间就越少。因为测试其实已经从需求阶段开始了。

14

鲜花

握手

雷人

路过

鸡蛋

刚表态过的朋友 (14 人)

相关阅读

最新评论

©2011-2016 测试之道 京ICP备15015883号-1 京公网安备号  

关于我们| 加入我们| 联系我们| 免责声明
返回顶部