第二章-软件测试原理

• ==2.1 软件测试原则==
• 2.2 软件测试的分类
• • 按==测试阶段==分类
  • 按==是否执行被测软件==分类
  • 按==是否需要查看代码==分类
  • 按==测试执行是否需要人工干预==分类
  • 其他测试类型
• 2.3 软件测试的流程
• 2.4 软件测试的过程模型
• • V模型
  • W模型
  • H模型
  • X模型

2.1 软件测试原则

1．所有的测试都应追溯到用户需求
2．应当把“尽早测试和不断地进行软件测试”作为软件测试者的座右铭
3．Pareto原则（二八原则）应用于软件测试

缺陷群集现象：测试发现的错误中的80%很可能源于程序模块中的20%

4．测试应从“小规模”开始，逐步转向“大规模”
5．穷举测试是不可能的

测试出口条件参考标准：
①遗留缺陷数量低于10个，其中严重的缺陷少于5个
②测试用例的执行率为100%，通过率为95%
③对单元测试，关键模块语句覆盖率为100%，判定覆盖率为85%

6．为了达到最佳效果，应该由独立的第三方来构造测试
7．不充分的测试是不负责任的，过分的测试是一种资源的浪费，同样也是一种不负责任的表现

2.2 软件测试的分类

按测试阶段分类

可分为单元测试、集成测试、确认测试、系统测试、验收测试。

1. 单元测试（模块测试）：对软件中的最小可测试单元进行测试。目的是检查每个单元是否能够正确实现详细设计说明中的功能、性能、接口和设计约束等要求，发现各个模块内部可能存在的各种缺陷。

优点：实现测试从“小规模”向“大规模”转变，减轻调试的难度，提供同时测试多个单元的可能。
主要依据：程序代码 详细设计文档
测试时间：代码通过编译后
测试人员及方法：开发人员 交叉测试(结合白盒与黑盒测试方法)

2. 集成测试（组装测试）：在单元测试的基础上，按照设计要求，将通过单元测试的单元组装成系统或子系统而进行的有序的测试，目的是检验不同程序单元或部件之间的接口关系是否符合概要设计的要求，能否正常运行。

测试时间：与单元测试同步进行。
主要依据：单元测试的单元 概要设计文档
测试人员：白盒测试工程师或开发人员
在不断地集成过程中，功能集成的稳定是需要解决的主要问题，在每个版本提交时，应先进行冒烟测试(版本验证测试)，来验证主要功能是否能正常执行。

3. 确认测试：确认测试检测与证实软件是否满足软件需求说明书中规定的要求。
4. 系统测试：在真实或模拟系统运行的环境下，检查完整的程序系统是否能和系统正确配置、连接，并满足用户需求。

测试人员：黑盒测试工程师
测试时间：集成好后进行
主要依据：需求规格说明文档
步骤：①前期：系统功能是否满足需求（功能测试）②后期：系统运行是否满足要求，以及系统在不同的硬件软件环境中的兼容性等（性能测试、兼容性测试、用户界面测试等）

5. 验收测试（接受测试）：

测试时间：系统测试后期
测试人员：用户或有测试人员等质量保证人员共同参与；由用户或其他权威机构来决定是否可以接受产品的验证性测试
主要依据：软件需求规格说明文档 验收标准
测试用例：可以直接采用内部测试组所设计的系统测试用例的子集，也可由验收人员自行设计。
分类：①α测试：开发方测试，开发方通过检测和提供客观证据，证明软件运行是否满足用户规定的需求。
②β测试：内部测试之后的外部公开测试，是将软件完全交给用户，让用户在实际使用环境下进行的对产品预发布版本的测试。

按是否执行被测软件分类

可分为静态测试和动态测试。

• 静态测试（静态分析）：不实际运行被测软件，而是直接分析软件的形式和结构，查找缺陷。
  特点：高效但费时，节约成本
  对象：代码，程序界面，文档（SRS）

源代码：
（1）容易产生错误的代码
（2）控制流图和模块调用关系图
（3）代码规则（风格、命名规范）
程序界面：一致性
文档：
（1）需求说明书
（2）设计文档

途径：代码检查，静态分析
方法：手工，自动化
静态测试是采用走查、同行评审、会审等方法来查找错误或收集所需度量数据的。
静态分析的查错和分析功能是其他方法所不能替代的，静态分析能发现文档中的问题（也只能通过静态测试发现）。

• 动态测试（动态分析）：需要实际运行被测软件，通过观察程序运行时所表现出来的状态、行为等发现软件缺陷，发现程序所表现的行为与设计规格或客户需求不一致的地方。

动态测试的局限性：
· 往往需要借助测试用例来完成
· 需要搭建软件特定的运行环境
· 不能发现文档问题，问题发现滞后

2.4 软件测试的过程模型

V模型——强调在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；仅针对程序，没有明确指出对需求、设计的测试，忽略了测试的对象。
W模型——补充V模型中忽略的内容，强调测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明，不能支持迭代，自发性以及变更调整。
H模型——强调测试是独立的，只要测试准备完成，就可以执行测试 ，可以根据被测物的不同而分层次进行。

V模型

局限性：
①W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。
②软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一阶段。这样就无法支持迭代、自发性以及变更调整。

H模型

将测试活动完全独立出来。