曹晋的空间

我们一直在努力....

如何把握测试需求

标签: 测试需求

 

  本文如何把握测试需求摘要:测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等于软件需求,它是以测试的观点根据软件需求整理出一个列表,作为测试该软件的主要工作内容。
  测试需求主要通过以下途径来收集:
  1)与待测软件相关的各种文档资料。如软件需求规格、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。
  2)与客户或系统分析员的沟通。
  3)业务背景资料。如待测软件业务领域的相关知识等。
  4)正式与非正式的培训。
  5)其他。如果以旧系统为原型,以全新的架构方式来设计或完善软件,那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。
  在整个信息收集过程中,务必确保软件的功能与特性被正确理解。因此,测试需求分析人员必须具备优秀的沟通能力与分析能力。
  4. 测试需求的分析
  目前不少的书籍与网站资料开始重视测试需求的分析,同时也提出了一些测试需求分析的方法。这里归纳总结下。
  测试需求需要考虑几个层面的因素:
  第一层:测试阶段。
  目前,大多数的测试都会在系统测试中完成,验收测试只是对于系统测试的回归。此种情况也是合理的,关键看测试周期与资源是否允许,以及各测试阶段的任务划分。
  第二层:待测软件的特性。不同的软件业务背景不同,所要求的特性也不相同,测试的侧重点自然也不相同。除了需要确保要求实现的功能正确,银行/财务软件更强调数据的精确性,网站强调服务器所能承受的压力,ERP强调业务流程,驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型,并将其列入测试需求当中。
  第三层:测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解,从而得出 的着重于某一方面的测试,如界面、业务流、模块化、数据、输入域等。目前关于各个焦点的测试也有不少的指南,那些已经是很好的测试需求参考了,在此仅列出业务流的测试分析方法。
  任何一套软件都会有一定的业务流,也就是用户用该软件来实现自己实际业务的一个流程。简单的来说,在做测试需求分析时需要列出以下类别:
  1) 常用的或规定的业务流程
  2) 各业务流程分支的遍历
  3) 明确规定不可使用的业务流程
  4) 没有明确规定但是应该不可以执行的业务流程
  5) 其他异常或不符合规定的操作
  然后根据软件需求理出业务的常规逻辑,按照以上类别提出的思路,一项一项列出各种可能的测试场景,同时借助于软件的需求以及其他信息,来确定该场景应该导致的结果,便形成了软件业务流的基本测试需求
在做完以上步骤之后,将业务流中涉及的各种结果以及中间流程分支回顾一遍,确定是否还有其他场景可能导致这些结果,以及各中间流程之间的交互可能产生的新的流程,从而进一步补充与完善。

更多内容,请留意下篇明确测试需求的优先级.


    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

评论


发表评论

最近访客
关注此文的人们还关注