软件测试基本概念-概述

2014-08-05 walter lee 更多博文 » 博客 » GitHub »

软件测试

原文链接 http://www.xiangguo.li/software_test/2014/08/05/software_test1
注:以下为加速网络访问所做的原文缓存,经过重新格式化,可能存在格式方面的问题,或偶有遗漏信息,请以原文为准。


{% include JB/setup %}

软件测试基本概念-概述

1 软件缺陷

1.1 什么是软件缺陷?

  1. 软件未达到产品说明书中已经标明的功能;
  2. 软件出现了产品说明书中指明不会出现的错误;
  3. 软件未达到产品说明书中虽未指出但应当达到的目标;
  4. 软件功能超出了产品说明书中指明的范围;
  5. 软件测试人员认为软件难以理解、不易使用,或者最终用户认为该软件使用效果不良。

1.2 为什么会产生软件缺陷?

  1. 产品需求说明书-56%
  2. 设计方案-27%
  3. 编写代码-7%
  4. 其他-10%

1.3 软件缺陷修复的费用

软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中,都有可能产生和发现缺陷。随着整个开发过程的时间推移,更正缺陷或修复问题的费用呈几何级数增长。

2. 软件测试

2.1 引入

  1. 软件产品质量是企业的重要目标。
  2. 软件缺陷不可能避免
  3. 软件测试是发现缺陷的手段。

2.2 软件测试定义

软件测试是发现并指出软件(包含软件经过建模、需求、设计等阶段所产生的大量输出工件及程序代码)中存在缺陷的过程,这个过程指明和标注问题存在的正确位置,详细记录导致问题出现的操作步骤,及时存储当时的错误状态,以上组合在一起便于测试后问题能够准确再现。

2.3 软件测试模型

2.3.1 V模型

定义

20世纪80年代后期,Paul Rook提出了著名的软件测试的V模型,是瀑布模型的变种,它反映了测试活动与分析和设计的关系,非常明确的表明了测试过程中存在的不同级别,以及各测试阶段与开发过程中的各阶段的对应关系,图中的箭头代表了时间方向,左边下降的是开发各阶段,右边上升的是测试过程的各个阶段。

V模型的优点

  • 单元测试和集成测试应检测程序的执行是否满足软件设计的要求;
  • 系统测试应检测系统功能,性能的质量特性是否达到系统要求的指标;
  • 验收测试确定软件的实现是否满足用户需要或合同的要求.

V模型的缺陷

  • 仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段
  • 忽视了测试对需求分析,系统设计的验证,一直到后期的验收测试才被发现。

2.3.2 加强型V模型(俗称W模型)

定义

Evolutif公司提出了W模型的概念,增加了软件各开发阶段中应同步进行的验证和确认活动,明确了测试与开发的并行性.

W模型的优点

  • 测试伴随着整个软件开发周期
  • 测试的对象不仅仅是程序,需求、设计和功能同样要测试
  • 根据W模型的要求,一旦有文档提供,就要及时确定测试的条件、编写测试用例

W模型的局限性

  • 在W模型中,需求、设计、编码等活动被视为串行的,同时,测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作。
  • 无法支持迭代、自发性以及变更调整。

2.3.3 H模型

定义

这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程。

H模型的优势

  • 软件测试不仅仅指测试的执行,还包括很多其他的活动。
  • 软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发的进行。
  • 软件测试要尽早准备,尽早执行。
  • 软件测试是根据被测物的不同而分层进行的。不同层次的测试活动可以按照某个次序先后进行的,但也可能是反复的。

2.4 软件测试的分类

按照开发阶段划分

  • 单元测试:模块测试,检查每个程序单元嫩否正确实现详细设计说明中的模块功能等。
  • 集成测试:组装测试,将所有的程序模块进行有序、递增的测试,检验程序单元或部件的接口关系
  • 系统测试:检查完整的程序系统能否和系统(包括硬件、外设和网络、系统软件、支持平台等)正确配置、连接,并满足用户需求。
  • 确认测试:证实软件是否满足特定于其用途的需求,是否满足软件需求说明书的规定。
  • 验收测试:按照项目任务或合同,供需双方签订的验收依据文档进行的对整个系统的测试与评审,决定是否接受或拒收系统。

按照测试技术划分

  • 白盒测试:通过对程序内部结构的分析、检测来寻找问题。检查是否所有的结构及逻辑都是正确的,检查软件内部动作是否按照设计说明的规定正常进行。--结构测试
  • 黑盒测试:通过软件的外部表现来发现错误,是在程序界面处进行测试,只是检查是否按照需求规格说明书的规定正常实现。
  • 灰盒测试:介于白盒测试与黑盒测试之间的测试,关注输出对输入的正确性;同时,也关注内部表现,不像白盒那样详细,只是通过一些表征性现象、事件、标志来判断内部的运行状态。

按照测试实施组织划分

  • 开发方测试:开发方通过检测和提供客观证据,证实软件的实现是否满足规定的需求,在开发环境下,开发方对提交的软件进行全面的自我检查。
  • 用户测试:在用户的应用环境中,用户通过运行软件,检测软件实现是否符合自己预期的要求,这里指用户的使用性测试。
  • 第三方测试:介于软件开发方和用户方之间的测试组织的测试。

2.5 软件测试的原则

  • 完全测试是不可能的
  • 软件测试是有风险的活动
    • 如果不选择完全测试所有情况,那就是选择了冒险
    • 把数量巨大的可能测试减少到可以控制的范围
    • 针对风险做出明智的选择,哪些测试重要,哪些不重要
  • 测试无法显示潜伏的软件缺陷和故障(可以报告软件缺陷存在,却不能报告软件缺陷不存在)
  • 充分注意测试中的群集现象(缺陷可能成群出现)
  • 杀虫剂现象(软件测试越多,寻找更多软件缺陷就越困难,金肯能采用多种途径进行测试)
  • 并非所有的软件缺陷都要修复(根据风险决定)
  • 软件测试必须有预期结果
  • 尽早地和不断地进行软件测试
  • 程序员应该避免检查自己的程序
  • 追溯至用户需求
  • 及时更新测试

2.6 常用的停止测试的标准有5类

  • 测试超过了预定的时间,停止测试;
  • 执行了所有测试用例但没有发现故障,停止测试;
  • 使用特定的测试用例设计方法作为判断测试停止的基础;
  • 正面指出测试停止的要求,比如发现并修改70个软件故障;
  • 根据单位时间内查出故障的数量决定是否停止测试。

2.7 软件测试误区

  1. 调试和测试是一样的
  2. 软件测试对象就是程序
  3. 软件测试是测试人员的事情,与开发人员无关
  4. 好的软件质量是通过测试得到的
  5. 把不合格的开发人员安排做测试
  6. 关注于测试的执行而忽略测试的设计
  7. 测试自动化是万能的
  8. 测试是为了证明软件的正确性

参考网站