需求分析[转载]
内容:
一、需求的相关概念
- 根据需求规格说明书内容分为:显性需求和隐性需求
- 显性需求:需求规格说明书中有明确定义的功能需求。
- 隐性需求:需求规格说明书中没有明确定义的功能需求,但是需要考虑的功能需求。
- 根据业务功能划分:功能需求和非功能需求
- 功能需求:明确定义的功能,大部分能够看见,比如:登录。
- 非功能需求:没有明确定义,而且也不容易看见,但需要考虑,比如:性能、易用性、可维护性。
- 根据测试类别来划分:功能、接口、性能、兼容性、安全性、帮助文档测试。
- 根据不同业务层次划分:业务需求、用户需求和功能需求
- 业务需求:也就是公司为什么要开发这套系统(描述公司在这套系统中解决了用户什么问题,如何满足用户的欲望,并利益最大化。重点是商业利益的可用性和最大化),也就是希望达到的目标。
- 用户需求:用户能使用系统,来做什么 、针对与客户解决了那些问题。
- 功能需求:功能需求描述是开发人员需求实现什么。
作者:Xyxtank
链接:https://www.jianshu.com/p/0fb521e38a5e
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
功能概述
通过上述的文档说明,我们知道这个是一个网站的注册功能,用户注册成功后会有一定的操作权限,并且有一定的业务处理流程和规则约束。当我们的研发团队看到这个文档,就能够有效的快速的去分析这个产品的需求,并且制定研发计划;测试团队看到这个文档,就能够制定有效的测试计划和方案。
(2)软件产品原型图
原型图简单的来说是用线条、图形描绘出的产品框架,也称线框图,跟我们最终的产品形态无异,我们可以用Axure这个工具画出产品的原型图,如下所示,这是一个互联网p2p平台的用户账户页面:
原型图相对产品需求文档来说,更具有直观性,因为原型图他会有页面设计以及交互设计,跟最终的产品达成效果相似度非常之高。对于研发团队和测试团队而言,他不再是一个抽象的存在,以更加具体的接近产品的最终形式展现,也能够让我们迅速的理解这个产品的需求,并且能够更好的更快的完成研发和测试。
目标:
梳理清楚产品的功能点以及业务逻辑,不存在二义性和疑惑;
对产品逻辑不清楚不合理的地方进行讨论,并且最终确定好修改方案;
对功能模块进行梯队层划分,优先实现重且关键的功能,后期再对其他梯队的功能进行研发。
如何进行需求分析是我们软件测试工作介入项目的第一步,根据我们自己的需求文档或者是原型图,可以从如下几个方面来进行分析,并找出相关的需求点:
(1)功能需求:产品应该完成的基本功能,一般来说这个都是比较硬性的标准,我们作为测试也必须要弄懂我们即将要测试的基本功能模块是哪些,才能有序的展开后期的测试工作;
(2)非功能性需求:对我们来说,就是隐形需求,可能在我们的需求文档里面不会体现出来,用户也不会明说,但是要让产品更加完善和高质量,可能我就需要去多方面考虑,比如说产品的兼容性、易用性、可靠性、稳定性等;
(3)限制条件:在需求分析中需要考虑一些规则约束等,比如在上面需求文档里面tidied注册功能。
它的限制条件就体现在:图片验证码的输入限制,短信验证码的时间与输入限制,密码的长度与格式限制,这些都需要我们在分析中认真分析,并为我们下一步的测试用例编写做好准备。
不做需求分析或需求分析不到位,可能会产生很严重的问题,比如:
(1) 浪费时间和资源实现了用户不需要的需求;
(2) 遗漏了需求文档中没提到,但很重要的需求,导致客户满意度降低。
(3) 需求分析不到位,错误的估计了测试的工作量,导致延误发布周期,可能会降低发布质量。
需求跟踪矩阵
需求存在频繁变更,要早发现、早讨论、早决定、早调整,早处理,对需求版本进行控制(做好需求版本控制,做优先级)
怎么做需求分析
- 根据SRS提出独立的功能测试点,确定测试范围;
- 对独立的功能点分析,确定各独立功能测试点;
- 对业务场景即功能点组合分析,提供业务场景的测试点;
- 对非功能性进行分析,了解所需测试的非功能特性。
对系统接口进行分析。
三步法:原始测试需求分析->测试项分析->测试子项分析
1、 通过需求文档了解需求的实现背景
拿到一个需求后,我们首先应该通读需求文档,先通过需求文档,对要做的需求的背景有个整体的了解,其实这个过程也是对需求文档测试的过程,对需求整体的了解后,我们可以先记录自己的一些疑惑,为后面需求的分析做一个准备工作,这个环节我们应该更多的了解一些需求的目的和一些用户的使用场景。
例:3.3版本大立案流程需求,需求文档中对于业务场景给了一个流程图
保密要求-图片忽略
从需求示意图中我们大致可以了昆明大立案的整个流程,使用的法院只有中院与基层院,主要是一个案件在基层院与中院的流转过程,使用的人员主要是法院的立案庭的人员,但是我们不知道涉及的案件主要有哪些,以及出现这样的场景是基于哪些业务逻辑,这些都是我们接下来要和需求人员了解的,这是我们分析这个需求和设计用例的基础,也是我们分析需求合理性的依据。
2、 分析需求合理性
可以通过业务知识来分析需求的合理性,而不是单单通过系统是怎样实现的来判断需求是否合理,这也是测试人员必备的技能之一,即需要我们有深厚的业务功底,然后在通过结合系统现有的实现来分析需求的合理性。
在我看来需求是否合理主要包括两个方面:第一,满足客户需求。第二,在系统原有的基础上,尽量减少改动成本。
3、 确定测试的范围和优先级
通过以上对需求的分析,我们就可以确定测试的范围和优先级了。首先我们要确定好这个需求所涉及的全部测试点,然后通过分析,分析出测试范围的优先级。
4、 细化测试点并确定测试方法
确定了测试范围和优先级后,就可以对各模块进行细化,可以用MindManager列出个模块下的测试点,各模块或大的测试点需要写出对应的测试方法,或测试策略。是否需要性能测试、白盒测试,是否需要提前准备数据,或会遇到什么样的测试难点,采取怎样的应对措施。
5、 确定哪些工作测试人员可以提前介入
根据以往的经验我们都知道,在开发一个比较复杂的需求的周期中,测试的前期准备工作通常都是比较充足的,当然特殊情况除外,因此在确定了测试范围和优先级后,测试人员和测试负责人应该先确定一下哪些需求测试是可以提前介入的,比如,15FB新增新案件来源和新结案方式字段的需求,前期的新旧关系对应文档,测试就是可以提前进行介入,在需求完成了对应关系文档后,测试在进行重新梳理一下,这样既提高了文档的可靠性,也相当于测试提前介入测试了,规避了后面的测试的进度风险和质量风险。
6、 查缺补漏
做完了需求的细化后,要对自己做的需求分析从头到尾在捋一遍,查看有没有什么遗漏的,因为需求也又可能遗漏的地方。主要关注有没有场景需求没有考虑全面, 涉及的修改范围被遗漏了,以及一些特殊的关联配置没有考虑到的,另外如果需求做了一些变动也要及时补充需求分析,主要是分析变动可能带来的风险,以及准备哪些应对之策。
四、如何提高需求分析能力
1、熟悉业务,了解系统
任何系统都有大的业务背景,只要熟悉了业务知识才能更有效的使用系统。
任何系统在使用过程中,都有一个熟悉的过程,对系统越熟悉,越容易发现系统问题和业务问题。
2、用客观的思考方式站在用户的角度分析
作为测试人员如果想提升需求分析能力,首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么,至于这个需求该不该做,那是需求人员的职责,这个需求做起来复不复杂那是开发人员的事情,作为测试人员需要考虑的事就是在满足客户要求的基础上(这个很重要),然后在站在业务或者系统现有实现的角度,给需求和开发人员一些设计上的建议,换句话说就是如果抛开客户,你这个需求做的在高大上,在酷炫,都是没有意义的。
3、多思考,不要拘束于惯性思维
我们知道一个人做一个工作时间越久,也就是我们说的经验越丰富,可能这个思维方式就会越被限定住。比如,测试的统计表多了,当拿到一个新增的统计表的时候,首先想到的是公用用例上所列的测试点基本上就是最全的了,我都不用思考,直接用就行了。
其实这是一个误区,公用用例的目的是帮助我们减少一些不必要的内耗,但是我们的思维不要被它所限定,如果公用用例中某个点是错的,那我们岂不要一错再错了。所以作为一个测试人员如果想要提升自己的需求分析能力,一定要多思考,不要被这种惯性思维束缚,不要被所谓的经验束缚。
4、不要闭门造车,利用好网络资源
提升需求分析能力,多思考是非常重要的,但是不是让你傻思考,当你的进步遇到瓶颈的时候,不要闭门造车,做井底之蛙,要充分利用网络上的学习资源,学习一些前辈的经验,并把这些运用到实际的需求分析中去。山外青山楼外楼,多浏览和关注一些关于需求分析的网站或者微信公众号,广开言路,相信会对你的需求分析能力有非常大的提升。
5、善于总结分享
基于以上四点我们还要做到善于总结,乐于分享,把经常见到的用例设计的误区和一些好的需求分析实例,和需求分析习惯分享给周围的小伙伴,这样可以集众人之所长,不断提升我们的需求分析能力。
成果: