软件测试如何达到一定的覆盖度是个非常重要的问题,它是我们软件测试分析和测试设计工作的基础和出发点。在白盒测试中,我们可以用逻辑覆盖(语句覆盖、分支覆盖、条件覆盖、路径覆盖)等来指导我们的测试分析和设计,并用来评价我们软件测试工作的充分性,但在黑盒测试中,我们所追求的是需求要达到一定的覆盖度,那么如何衡量需求被覆盖的程度呢?又如何保证去达到一定的需求覆盖呢?请结合您的思考和实践,畅所欲言,希望各种观点在碰撞中产生火花。

  主要要做好测试需求分析测试需求分析分两步:

  1,测试需求的获取需求的来源:

  显式需求

  (1)原始需求说明书

  (2)产品规格书

  (3)软件需求文档

  (4)有无继承性文档

  (5)经验库

  (6)通用的协议规范隐式需求:用户的主观感受,市场的主流观点,专业人士的评价分析

  2,需求的分析 ,产生测试需求文档将不同的需求来源划分成一个个需求点,针对每一点进行测试分析

  (1)界定测试范围

  (2)利用各种测试设计的方法产生测试点。

  目前测试对需求的覆盖程度已经作为判断测试质量的一个标准,但不同的测试类型和需求类型如何判断测试的覆盖程度?

  1、一般来说,非功能性测试的覆盖程度比较好判断,如性能和压力测试,可根据需求中明确的性能指标进行测试分析和设计,另外也可通过分析系统在生产中实际使用情况,来分析一些隐含的需求,如系统是否需要连续运行、系统故障后恢复的级别、并发访问的程度等。

  2、功能性测试的覆盖程度是比较难判断的,用例数不能完全说明对需求的覆盖,因为用例数和测试点的力度划分相关,测试点划分的越细,用例数量越大,但不能说明覆盖程度高。

  我们的做法一般是先根据用户需求确定测试优先级,重点需求测试点划分的比较详细,测试用例要覆盖所有的情况,如正常值、边界值、特殊值等;一般性需求测试用例覆盖所有的正常等价类;测试用例设计上划分为单功能测试用例和测试场景设计,单功能测试覆盖的需求中的功能点,测试场景覆盖需求中的业务逻辑;另外测试设计全面与否,很大程度取决于需求的质量,取决用户是否真正明白自己想让系统做什么。

  看了上面高手的分析,真是受益匪浅啊~!~我也同意首先要透彻理解需求文档,把不明白的地方与开发人员、设计人员沟通。

  理解完需求后,我们就得开始写测试需求了,在测试需求了,我们将对软件或项目进行庖丁解牛的手法,将其功能模块细分出来,然后将模块中的功能点分解出来,我们得保证最后的功能点为最小分子,不能再进行下一步分解拉。(当然我们可以借助一些测试需求编写工具拉)测试需求细分出来后,剩下的就是编写测试用例了。每个最小分子需求对应写一个测试用例,用例中要将能想到的方法步骤全部写出来,大家开会讨论,不漏掉。执行“不抛弃任何一个方法、不放弃任何一个idea”。至于相关联的功能模块之间,我们也得考虑设计测试用例。(这些只针对黑盒测试的功能测试)
  
  ......

本文转载自51Testing软件测试网,查看全文:http://www.51testing.com/html/67/n-222667.html