随笔-60  评论-117  文章-0  trackbacks-0

         经常有这样的经验:想要学一样东西,有一本关于它的厚厚的书摆在我面前。快速的翻了翻之后,又将它合上。然后无奈的叹了口气。是啊,到底该怎么下手呢?可当得知明天就要考这本书的时候,再打开,发现它们突然变得简单了。只是自己想学的太多,时间有点不够用……
软件测试
定义:测试是为了发现错误而执行程序的过程。

目的:

  • 为了寻找错误,并尽可能地为修正错误提供更多的信息。
  • 为了证明软件有错误,而不是证明软件没有错误。

作用:

  • 发现并管理缺陷
  • 度量质量
    • 评价工作效率和效果
    • 与其项目风险

原则:

  • 座右铭:“尽早地和不断地进行软件测试”。
  • 测试用例应由测试输入数据和对应的语句输入结果这两部分组成。
  • 程序员应避免检查自己的程序。
  • 在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。
  • 充分注意测试中的群集现象。经验表明,测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
  • 严格执行测试计划,排除测试的随意性。
  • 应当对每一个测试结果作全面检查。
  • 妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。
  • 所有的测试都应可追溯到客户的需求。
  • 应该在测试工作开始之前的较长时间就进行测试计划。
  • pareto原则:测试发现的错误中80%很可能起源于20%的模块中。
  • 测试从“小模块”开始,逐步转向“大规模”。
  • 穷举测试是不可能的。

对象:

  • 软件包括程序、数据和文档,软件测试并不等于程序测试。
  • 软件测试应贯穿于软件定义与开发的整个其间。
  • 开发过程所得到的文档,都应成为软件测试的对象。
  • 验证与确认都属于软件测试,它 包括对软件分析、设计以及程序的验证和确认。
    • 验证:是保证软件符合产品描述的过程。
    • 是保证软件满足用户要求的过程。

缺陷:

  • 软件未达到产品描述表明的功能。
  • 软件出现了产品描述指明不会出现的错误。
  • 软件功能超出产品描述指明范围。
  • 软件未达到产品描述虽未指出但应达到的目标。
  • 软件测试人员认为软件难以理解、不易使用、运行速度缓慢、或者最终用户认为不好。

缺陷产生的原因:

  • 编写代码
  • 设计
  • 编写产品描述
  • 其他

特征:

  • 软件测试具有一定的风险:完全测试是不可能的,如果决定不去测试所有的情况,那就是选择了风险。
  • 软件缺陷的寄生虫性:找到的软件缺陷越多,就说明软件缺陷越多。
  • 软件测试的杀虫剂现象:软件测试越多,其免疫力越强的现象。
  • 软件测试的不修复原则 :并非所有软件缺陷都能修复。有些缺陷不需要修复:*没有足够的时间*不算真正的软件缺陷* 修复的风险太大*不值得修复。

软件测试方法、技术和策略
框架:

  1. 静态测试方法
    1. 人工测试方法
    2. 计算机辅助静态分析方法
  2. 动态测试方法
    1. 白盒测试方法
    2. 黑盒测试方法

静态测试:
基本特征

  • 对软件进行分析、检查和审阅,不实际运行被测试的软件。
  • 静态测试约可找出30-70% 的逻辑设计错误 。

比如说:对需求规格说明书、软件设计说明书、原程序作检查和审阅。



动态测试:
基本特征:
通过运行软件来检验软件的动态行为和运行结果的正确性。
两个基本要素:

  • 被测试程序
  • 测试数据(测试用例)

动态测试方法流程

  • 选取定义域有效值,或定义域外无效值
  • 对已选取值决定预期的结果
  • 用选取值执行程序
  • 执行结果与对已选取值决定预期的结果相比,不吻合程序有错。

白盒测试:

  • 结构测试(玻璃盒测试)
  • 对软件的过程性细节做细致的检查
  • 可利用程序内的逻辑结构,设计或选择测试用例,对程序的逻辑罗景警醒测试。

 白盒测试方法:

  • 逻辑覆盖
    • 语句覆盖:被测程序中每个语句至少执行一次
    • 判定覆盖:使每个判定的真假分支都至少执行一次
    • 条件覆盖:每个语句至少执行一次,切实判定表达式中的每个条件都取到各种可能的结果
    • 判定/条件覆盖:判定每个条件的所有可能条件至少执行一次,同时每个判定的所有的可能判定结果至少执行一次。
    • 条件组合覆盖:所有可能的条件去之组合至少执行一次
  • 控制结构测试
    • 基本路径测试:通过分析由控制构造的环路的复杂性,导出基本路径集合,从而设计测试用例,保证这些路径至少通过一次
    • 条件测试:是检查程序模块中包含的逻辑条件。
    • 循环测试:专注于测试循环结构的有效性
      • 简单循环
      • 嵌套循环
      • 串接循环

黑盒测试:

  • 功能测试(行为测试)
  • 数据驱动测试
  • 注重测试软件的功能性需求
  • 在程序借口进行测试,只检查程序功能是否按规格说明书的规定
  • 不深入代码细节的测试

测试方法:

  • 等价划分
  • 边界值分析
  • 错误推测
  • 其他方法

等价划分:
基本思想:
将所有可能的输入数据(有效的和无效的)划分成若干个等价类,从每个等价类中只取一组数据作为测试数据。
基本步骤:

  • 划分输入数据的等价类(有效和无效)
    • 等价类:指某个输入域的子集合,在该子集合中,个个输入数据对于揭露程序中的错误是等效的。
  • 涉及测试方案
    • 不断地覆盖所有的有效等价类
    • 不断地覆盖所有的无效等价类

划分等价类的规则:

  1. 如果输入条件规定了取值范围,可定义一个有效等价类和两个无效等价类。
  2. 如果输入条件代表集合的某个元素,则可定义一个有效等价类和一个无效等价类。
  3. 如规定了输入数据的一组值, 且程序对不同输入值作不同处理,则每个允许的输入值是一个有效等价类,并有一个无效等价类(所有不允许的输入值的集合)。
  4. 如果规定了输入数据必须组遵循的规则,可确定一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。
  5. 如已划分的等价类各元素在程序中的处理方式不同,则应将此等价类进一步划分成更小的等价类。

 边界值分析:
通过关注于在某等价类的“边缘”的数据而扩展了等价划分。
与等价划分的区别:

  • 边界值分析不是从某等价类中随便挑一个作为代表, 而是使这个等价类的每个边界都要作为测试条件。
  • 边界值分析不仅考虑输入条件,还要考虑输入空间产生的测试情况。

边界值分析的步骤:
确定边界情况:

  • 输入等价类和输出等价类的边界,就应该着重测试的程序边界的情况。
  • 选取的测试数据应刚好等于,刚好小于鹤岗好大于边界值。
  • 联合使用等价划分和边界值分析两技术。

因果图:

  • 描述对于多种条件的组合,相应产生多个动作的形式。适合于检查程序输入条件的各种组合情况。

使用因果图设计测试用例:

  • 考虑了多个输入之间的相互组合,相互制约关系。
  • 能够帮助我们按一定步骤,高效率地选择测试用例,同时还能为我们指出, 程序规格说明描述中存在着什么问题

利用因果图导出测试用例的一般步骤

  • 分析程序规格说明的描述中,哪些是原因,哪些是结果。
  • 分析程序规格说明的描述中语义的内容,并将其表示城连接各个原因与各个结果的因果图
  • 在因果图上使用若干个特殊的符号表明特定的约束条件
  • 把因果图转换成判定表
  • 把判定表中每一列表示的情况写成测试用例

错误推测:
基本思想:

  • 列举程序中可能有的错误和容易发生的特殊情况,并且根据他们选择测试方案

软件测试模型:

  • v模型:按时间顺序进行:用户需求,需求分析与系统设计,概要设计,详细设计,编码,单元测试,集成测试,确认测试与系统测试,验收测试
    • 它是最具具有代表意义的测试模型
    • 它是软件开发瀑布模型的变种,它反映了测试活动与分析和设计的关系。
    • 从左到右,描述了基本的开发过程和测试行为,非常明确的表明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
    • 箭头代表了时间方向 ,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即个测试过程的各个阶段。
  • w模型
    • v模型存在一定的局限性,它仅仅把测试过程作为在需求分析,概要设计,详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段,主要是针对程序进行测试徐兆错误,而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现。
    • 在v模型中曾家软件各开发阶段应同步进行的测试,被演化为一种w模型。
    • 开发是v,测试也是与此相重叠的v。
    • 相比于v模型,w模型更科学。w模型可以说是前者自然而然的发展,它强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求,功能和设计同样要测试。
    • 测试与开发是同步进行的,从而有利于仅在地发现问题。与需求为例,而不是等到最后才进行针对需求的验收测试。
    • 测试不仅仅是评定软件的质量,测试还可以尽可能早的找出缺陷所在,从而帮助改进项目内部的质量。
  • x模型

 软件测试技术:
静态测试的技术主要有:代码走查,技术评审,代码审查。
黑盒测试的技术主要有:功能测试,性能测试,攻击测试。
回归测试:程序修改或者版本更新以后,为了确保以前正确的能能和其他指标仍旧正确,而重新进行的测试。
测试过程分为:

  • 单元测试:
    • 检验程序最小单元有无错误。接口、数据结构、边界、覆盖、逻辑。检验单元编码与设计是否吻合。
    • 时机:编码完成后,首先要实施的测试。
    • 方法:静态测试,白盒测试
    • 责任:开发工程师
  • 集成测试:
    • 目标:检验组成系统的模块节后有无错误。代码实现的系统设计与需求定义是否吻合。
    • 时机:主要的单元测试完成后,经常与单元测试同步进行。
    • 方法:黑盒测试
    • 责任:开发工程师,测试工程师
  • 系统测试:
    • 目标:检验组成整个系统的代码、以及系统的软硬件配合有无错误
    • 代码实现的系统与用户需求是否吻合
    • 检验系统的文档等各种是否完整、有效
    • 模拟验收测试的要求,检察系统是否符合用户的验收标准
    • 时机:多数集成测试完成后
    • 方法:黑盒测试
    • 责任:测试工程师
  • 系统测试----稳定期测试
    • 目标:度量是否可以结束测试
    • 时机:传统的系统测试完成后
    • 方法:黑盒测试
    • 责任:测试工程师
  • 验收测试:
    • 目标:使客户验收签字,系统是否符合事先约定的验收标准。
    • 时机:系统测试完成后,在项目组开来开发和测试工作已经全部完成,可以交付使用。
    • 方法:黑盒测试
    • 责任:产品经理或其他高级经理,开发工程师,测试工程师,用户。
  • 回归测试:
    • 目标:验证程序修改或者版本更新以后,以前正确的功能和其他指标仍旧正确。
    • 时机:每次错误修改之后,或者版本更新之后。
    • 方法:白盒测试,黑盒测试
    • 责任:开发工程师,测试工程师
  • 缺陷跟踪:
    • 目标:确保所有发现的错误被正确记录、分发、评估、关闭、统计
    • 时机:从错误发现开始到错误关闭为止,每次错误装袋修改之后。
    • 方法:缺陷跟踪系统
    • 责任:开发工程师,测试工程师,测试经理,用户

 

posted on 2007-04-28 08:55 静儿 阅读(829) 评论(1)  编辑  收藏

评论:
# re: 关于软件测试 2007-10-19 08:53 | bigboy
写的很好,收藏了  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: