{% 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. 测试是为了证明软件的正确性

参考网站

• http://www.51testing.com
• http://www.testage.net
• http://www.ltesting.net