咨询热线:

时时彩网上投注平台 > 需求测算 >

测试需求分析总结

2019-08-04 02:45 来源: 震仪

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

  测试需求分析是测试工作的第一步,经过需求分析,对原始需求列表中列出的每一个需求点,找到我们需要测试的测试要点;针对所确定的测试要点,分析测试执行时对应的测试方案/方法。

  如果要成功的做一个测试项目,首先必须了解测试规模、复杂程度与可能存在的风险,这些都需要通过详细的测试需求来了解。所谓知己知彼,百战不殆。测试需求不明确,只会造成获取的信息不正确,无法对所测软件有一个清晰全面的认识,测试计划就毫无根据可言,只凭感觉不做详细了解就下定论的项目是失败的。

  测试需求分析越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,就更有把握保证测试的质量与进度。

  如果把测试活动比作软件生命周期,测试需求分析就相当于软件的需求规格,测试策略相当于软件的架构设计,测试用例相当于软件的详细设计,测试执行相当于软件的编码过程。只是在测试过程中,我们把”软件”两个字全部替换成了”测试”。这样,我们就明白了整个测试活动的依据来源于测试需求,所以需求分析是整个测试活动必不可少的环节。

  (3) 需求分析不到位,错误的估计了测试的工作量,导致延误发布周期,可能会降低发布质量。

  以上的几个问题,在实际开发中是比较常见的,主要的原因就是需求分析不到位,会导致影响客户的满意度。

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

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

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

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

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

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

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

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

  任何系统在使用过程中,都有一个熟悉的过程,对系统越熟悉,越容易发现系统问题和业务问题。

  作为测试人员如果想提升需求分析能力,首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么,至于这个需求该不该做,那是需求人员的职责,这个需求做起来复不复杂那是开发人员的事情,作为测试人员需要考虑的事就是在满足客户要求的基础上(这个很重要),然后在站在业务或者系统现有实现的角度,给需求和开发人员一些设计上的建议,换句话说就是如果抛开客户,你这个需求做的在高大上,在酷炫,都是没有意义的。

  我们知道一个人做一个工作时间越久,也就是我们说的经验越丰富,可能这个思维方式就会越被限定住。比如,测试的统计表多了,当拿到一个新增的统计表的时候,首先想到的是公用用例上所列的测试点基本上就是最全的了,我都不用思考,直接用就行了。

  其实这是一个误区,公用用例的目的是帮助我们减少一些不必要的内耗,但是我们的思维不要被它所限定,如果公用用例中某个点是错的,那我们岂不要一错再错了。所以作为一个测试人员如果想要提升自己的需求分析能力,一定要多思考,不要被这种惯性思维束缚,不要被所谓的经验束缚。

  提升需求分析能力,多思考是非常重要的,但是不是让你傻思考,当你的进步遇到瓶颈的时候,不要闭门造车,做井底之蛙,要充分利用网络上的学习资源,学习一些前辈的经验,并把这些运用到实际的需求分析中去。山外青山楼外楼,多浏览和关注一些关于需求分析的网站或者微信公众号,广开言路,相信会对你的需求分析能力有非常大的提升。

  基于以上四点我们还要做到善于总结,乐于分享,把经常见到的用例设计的误区和一些好的需求分析实例,和需求分析习惯分享给周围的小伙伴,这样可以集众人之所长,不断提升我们的需求分析能力。

Copyright © 2002-2019 时时彩网上投注平台 版权所有