测试策略

 1软件测试策略
  1.1 软件测试策略概述
  测试活动需要采用各种不同的策略。这些策略表明了为确保软件质量而采用了不同的出发点、不同的事例、不同手段和测试方案。我们通常用的较多的方法有:静态方法和动态方法;单元测试,集成测试,确认和系统测试;下面的重点将介绍各种测试方法的应用。
  1.2 单元测试策略
  1.2.1 什么是单元测试?
  单元测试是对软件基本组成单元进行测试,这里的基本单元不一定是指一个具体的函数(FunctionProcedure)或一个类的方法,单元具有一些基本属性,如:明确的功能、规格定义,明确的接口定义,可清晰地与同一程序的其它单元划分开来。
  在纯C语言的代码中,为了操作方便期间,我们一般认为一个函数就是一个单元。
  1.2.2 单元测试的主要目的:
  1. 验证代码是与设计符合的
  2. 跟踪需求和设计的实现
  3. 发现设计和需求中存在的错误
  4. 发现在编码过程中引入的错误
  1.2.3 何时开展单元测试
  一般地,在编码阶段就应开展单元测试,边写程序边测试是一个好习惯。一个组织不要孤立的划分出编码和单元测试两个阶段,也不要等代码都写完了才开始单元测试。
  有时候需要将单元测试时间推后到集成阶段,甚至系统完成阶段。
  单元测试可以分为计划、设计、实现、执行几个阶段。计划是作好人和时间的安排。设计确定采用什么样的测试方法,达到一个什么样的覆盖率标准等。实现是设计生成各个测试用例。执行包括驱动和桩函数的设计实现,测试数据准备,测试结果验证等等。
  1.2.4 单元测试所遵循的原则
  对于测试来说,我们应当尽早地和不断地进行软件测试。对于单元测试来说我们需要遵循一定的单元测试规范,根据公司CMM规范中的规定,我们列出了一些原则但是这些并不是足够的。
  1. 仅对全新的代码或修改过的代码进行单元测试
  2. 被测试的对象为实现一组相关功能的代码(一个或一组函数)
  3. 单元测试根据单元测试方案进行,排除测试的随意性
  4. 项目管理者保证测试用例经过审核
  5. 当测试用例的测试结果与预期结果不一致时,单元测试的执行人员需记录实际的测试结果
  6. 对被测试单元需达到的一定的代码覆盖率要求muhdpe合金管
  7. 以车代磨当程序进行了修改,由测试执行人员执行回归测试以保证对发现错误的修改没有引入新的错误
  测试技术组总结的《单元测试过程与结果验收指导书》在这方面给出了比较详细的说明,大家有时间可以看一下。
  在做单元测试的时候有时会遇到这样一种现象:既设计人员在设计测试用例的时候或者在调试测试脚本的时候发现了详细设计或者代码中错误,并且改正了这些错误。因此在单元测试用例最后执行的时候发现的问题变少了。这不能表示单元测试的效果变差了。因为在单元测试过程中,通过单元测试方法发现的问题也是属于单元测试发现的问题。单元测试发现的问题不能局限于单元测试用例执行时发现的问题。
仅考虑被测单元的语句覆盖率并不是足够的。语句覆盖100%这是公司硬性的规定,但是不是除此以外我们就不需要兼顾其他覆盖率了呢?不是!有很多错误不是通过达到一定的语句覆盖就能发现的。我们还必须考虑一定的判定覆盖,条件覆盖甚至路径覆盖。一般来说要完全达到路径覆盖几乎是不可能的。但是我们可以考虑McCabe提出的圈路径或Z路径覆盖情况。
  同时单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用。单元测试必须是可重复的,无论是在软件修改,或是移植到新的运行环境的过程中。因此,所有的
蚀刻因子测试都必须在整个软件系统的生命周期中进行维护。
  在VV测试中有一个致命的弱点,也就是它把测试的阶段划分的太明显。其实在实际开发过程中你无法在时间点上严格的结束任何一种测试,因此说单元测试什么时候结束是没有意义的,如果一定要划分,我们可以认为我们的工作重点有单元测试进入另一种测试的标准。
  1.2.5 正规检视和代码走读
拉线抱箍  一般在单元测试期间,我们会同步启动一些测试活动,例如代码走读,正规检视,以进一步保证代码质量。
  正规检视和代码走读属于同行评审中的两中评审类型,正规检视有严格的流程和纪律,发现错误的效率比较高,但工作量很大,一般一次正规检视的代码量不要超过500行代码。正规检视参与的人员来自于不同领域的人,可以从各个不同的角度去发现代码或文档中深层次的错误。
  走读相对来说是比较自由的,没有严格的流程,参与人员一般都是来自于同项目组的人。
走读的工作量相对来说是比较小的,一般用于寻一些浅显的错误。同时走读也作为一种技术交流或理解代码和文档的手段。
  单元测试的工作量介于走读和正规检视之间,单元测试是由开发人员完成的,通过设计测试用例来寻代码中存在的错误。测试用例设计的好坏直接影响单元测试的结果。单元测试比较正规检视和走读的最大不同是单元测试可以通过代码的运行来发现错误,而这是正规检视和走读做不到的。单元测试不可缺少,因为有很多错误只有在运行时才能发现得了。
  在代码进行单元测试之前应当先进行代码走读和正规检视,它们的侧重点不同。CMM过程规范要求至少40%的代码必须经过正规检视。单元测试的代码+走读的代码+正规检视的代码 >= 总的代码。
  总结:
  单元测试是一种白盒测试
  有数据显示,进行适当的单元测试可以发现一个程序中多达70%的缺陷。因此,越早启动
单元测试,效果越好。
山药去皮机  正规检视、代码走读和单元测试一起进行,可以起到良好的效果。
  1.3 集成测试策略
  集成测试策略就是在测试对象分析的基础上,描述软件模块集成(组装)的方式、方法。
  集成测试的基本策略比较多,分类比较杂,一般来说,可以按测试过程中组合模块的方式,分为增式、非增式和衍变式集成等策略。
  (1)非增式集成方式: 也称整体组装。 首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。
  (2)增殖式集成方式: 也称渐增式组装。 首先对一个个模块进行单元测试,然后将这些模块逐步组装成较大的系统,在组装的过程中, 边连接边测试,以发现连接过程中产生的问题,最后通过增殖逐步组装成为要求的软件系统。 增殖式集成方式有三种实现方式: 自顶向下的增殖方式,感应门制作 自底向上的增殖方式和混合增殖方式。
  (3)衍变式集成方式:结合非增式集成方式和增殖式集成方式,包括,衍变的自顶向下的增殖测试,自底向上-自顶向下的增殖测试等。
  总结:
  集成测试关注的是模块间接口的正确性。
  选择良好的集成方式能减少大量的测试工作量。
  1.4 验证和确认测试(Verfication and Validation
  在广义上,软件测试是验证和确认VERFICATION AND VALIDATION VV〕。验证指保证软件正确地实现了一特定功能的一系列活动。确认是指保证所生产的软件可追溯到用户需求的一系列活动。BOEHMVV的解释是:
  VEIFICATION:"Are we building the product right?"
  VALIDATION:"Are we building the right product?"
  V&V的定义包含了许多活动,即软件质量保证SQA
1.4.1 确认测试(Validation Testing)
  确认测试又称为效性测试。它的任务是验证软件的功能
  和性能及其特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中已经明确规定。在软件需求规格说明中描述了全部用户可见的软件属性,其中有一节叫做有效性准则,它包含的信息就是软件确认测试的基础。集成测试完成以后,分散开发的模块被联接起来,构成完整的程序。其中各模块之间接口存在的种种问题都已消除。于是测试工作进入最后阶段--确认测试(Validation testing)。什么是确认测试,说法众多,其中最简明、最严格的解释是检验所开发的软件是否能按顾客提出的要求运行。若能达到这一要求,则认为开发的软件是合格的。因而有的软件开发部门把确认测试称为合格性测试(qualification testing)。这里所说的顾客要求通常指的是在软件规格说明书中确定的软件功能和技术指标,或是专门为测试所规定的确认准则。

本文发布于:2024-09-21 04:31:37,感谢您对本站的认可!

本文链接:https://www.17tex.com/tex/4/231589.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:测试   单元测试   软件
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2024 Comsenz Inc.Powered by © 易纺专利技术学习网 豫ICP备2022007602号 豫公网安备41160202000603 站长QQ:729038198 关于我们 投诉建议