基于V模型的单元测试,集成测试,系统测试

发表于:2011-11-11来源:未知作者:领测软件测试网采编点击数: 标签:
基于V模型,针对详细设计的单元测试 1)为什么要进行单元测试: 系统测试是一种黑盒测试,也就是不需要了解系统内部结构,只关心外部实现,那么这样发现的问题将不会太彻底,而单元测试是一种白盒测试,只有深入到系统内部,才能对软件内部逻辑

  基于V模型,针对详细设计的单元测试

  1)为什么要进行单元测试

  系统测试是一种黑盒测试,也就是不需要了解系统内部结构,只关心外部实现,那么这样发现的问题将不会太彻底,而单元测试是一种白盒测试,只有深入到系统内部,才能对软件内部逻辑控制结构上的问题进行清除,对发现、定位和解决问题将是最直接,最彻底的方式;在效率方面,单元测试往往是集成测试的2倍,系统测试的3倍;成本方面,一个问题如果遗留到后期阶段解决,那么付的代价将会很高,而且是成倍递增。

  单元测试有效的验证代码是否与设计相符,尽早发现设计和需求中存在的错误,以及在编码阶段引入的错误。

  2)单元测试的内容:

  单元测试首先要理解单元原本是要做什么的,而不是它现在实际做了什么,我们更关心的是:模块或函数是否做了它该做的事情而没有做不该做的事情。

  主要依据详细设计的描述和源程序清单针对五部分内容进行测试:模块接口、局部数据结构、边界条件、出错处理、独立路径。首先模块与周围环境的接口有无差错应首先得到检验,否则其内部的各种测试工作将是徒劳;局部数据结构也是常见的错误来源,对基本控制流进行测试同样也会发现大量的错误;异常处理要给予适当的出错处理对策,以便在程序出错时,能对出错程序重新做出安排,保证其逻辑上的正确性;边界测试,对数据流的测试将是单元测试的最后一步。

  单元测试评估的标准是逻辑覆盖率。

  基于V模型,针对概要设计的集成测试

  1)为什么要进行集成测试,

  集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确,当一个系统还没有完成,设计相应的桩和驱动模块进行集成测试,便于早期发现接口问题以及集成后的功能问题,同时编码不是一个可以一次性通过的过程,对最初的单元测试中一些被忽略和遗漏的BUG,也将会在集成测试阶段被发现。

  2)集成测试的内容。

  概要设计的对象主要为系统,系统子系统,模块,子模块,函数等,通过体系结构进行模块的划分,并进行数据设计、接口设计,遵循高内聚、低耦合的原则,对其进行分解描述,依赖关系描述,接口描述等,并保持模块与需求的对应关系,因此,对集成测试的重点,将主要测试模块之间的接口和接口数据传递关系,以及模块组合后的整体功能。

  确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确,验证接口是与设计相符合?发现设计与需求中存在的错误是集成测试的工作内容。

  通过接口的覆盖率进行集成测试的评估。

  基于V模型,针对需求规格说明书的系统测试

  1)为什么要进行系统测试。

  系统测试是我们传统观念的一种测试方式,也就是一般放在项目功能基本实现后的功能和性能等方面的测试,目前软件测试已由开发的后期介入扩展到了整个生命周期,由基于代码运行扩展到静态走读,由传统的发现错误为目的扩展到了对缺陷的预防。

  2)系统测试的内容。

  系统测试主要验证功能是否符合需求规格定义,是一种在实际环境下的测试,同时也是全面的系统级测试,其内容包括产品功能、性能指标、兼容性、可靠性、容错能力、可维护性、安全性等方面;功能方面主要检查是否有不正确或遗漏了的功能,性能测试目标是度量系统相对于预定义目标的差距,必须要有工具的支持;GUI测试界面实现与界面设计的吻合,以及界面处理的正确性,是直接面对用户的首要条件,因此相对在易用性方面显的较为重要;兼容性,可靠性的、容错性,可维护性,安全性等根据项目要求的不同,具体情况具体分析。

  系统测试评估的标准是对需求规格说明书的覆盖率。

  基于系统测试层面的个人经验总结:

  (一)用例设计、执行、管理、沟通:

  第一:测试用例的设计。在需求分析、概要设计、详细设计阶段均需要设计测试用例测试用例设计的有效性和合理性对整个测试执行起着至关重要的作用,它将直接影响缺陷发现率。如果用例如何设计的不太合理,满足了出口准则,但在发布以后,产生的大量缺陷,将直接影响用户满意度,浪费时间和资源,那么,如何进行测试用例的设计?怎么设计出高效率的测试用例呢?

  1)要明确,对于开发所关心的是功能是否可以被实现和如何具体实施,而对于测试来说,关注的是功能是否被正确实现,而不管这些功能是如何被具体实施的;

  2)在设计用例的过程中,要保证每一个功能点均有相应的用例所对应,保证测试用例对需求100%的覆盖;

  3)测试人员需要对被测软件的需求和业务进行全面了解,否则对被测对象了解不深,只能就被测单元的功能设计用例,而对于该功能点所要执行的流程无法正确保证,此时可与需求分析人员和客户进行交流,以获得更多的业务方面的信息;

  4)采用各种测试用例设计方法,用最适合的方法来达到用尽量少的用例来发现尽量多的BUG,如针对功能测试的等价类,边界值,因果图法,状态迁移图,正交分析法,错误猜测法,场景路径覆盖;针对单元测试的语句覆盖,分支覆盖,条件覆盖,条件组合覆盖,路径覆盖,循环覆盖,针对类的功能性和结构性测试、数据流测试,异常测试,对类的方法的测试等。

  用例的设计是一个长期经验积累的过程,需要我们在工作中多留心,才会有新发现、新思想。

  第二:测试用例的执行。测试用例的执行过程将是缺陷产生和修复的过程,同时也是测试用例进行更新和优化的过程。

  1)缺陷的提交与跟踪;

  测试人员进行测试用例的执行,在执行过程中,做好每日缺陷的提交,测试主管对缺陷进行分配及对修改时限的要求,开发人员进行缺陷的修改,修改完毕后,测试人员进行回归测试,并时刻关注缺陷库缺陷的状态及严重级别较高的缺陷进行及时跟踪。我们在亦庄的项目在这点就做的不错。

  2)缺陷的收集与度量;

  测试人员要保证所描述的缺陷是清楚的、准确的,必要时要配有截图,开发人员修改完毕后,要保证注明原因和解决的办法,有了上述两条的保证,缺陷的收集和度量工作将变的非常容易,对缺陷进行分析如发现缺陷多位于边界值,那么可以根据此项对公司的编程规范进行相应的完善。当对几个项目进行缺陷收集和度量后,具备一定的条件情况下,将可对类似项目进行缺陷的预防工作。

原文转自:http://www.ltesting.net