1. 软件测试理论知识

1.软件缺陷

软件中:

• 某种破坏正常运行能力的问题、错误

• 隐藏的功能缺陷

最终表现为:

• 用户所需要的功能没有完全实现
• 不能(全部）满足用户的需求。

1. 为什么会有缺陷？

• 人为因素
• 辐射/电磁场/硬件老化，污染

那么我们要怎么找到缺陷呢？-答案是通过测试。

2. 缺陷类型

产品说明书类：

• 未实现

  • 要求的功能。
  • 虽未明确提及但应该实现的功能。

• 出现/实现了

  • 说明书不应该出现的错误。

  • 未提到的功能。

测试人员角度类：

• 软件难以理解、不易使用、运行缓慢

2. 测试

• 为了发现程序中的错误而执行程序的过程

1. 测试对象：

软件测试不仅仅是对程序的测试，而是贯穿于软件定义和开发的整个过程。

软件开发过程中产生的:

• 需求分析、概要设计、详细设计

• 编码等各个阶段所得到 的文档

  • 包括需求规格说明、概要设计说明、详细设计规格说明

  • 以及源程序

都是软件测试的对象。

2. 怎么测试：

• 根据软件的功能规范说明和程序实现
• 利用各种测试方法
• 生成有效的测试用例
• 对软件进行测试。

3. 怎么停止：

判断是否需要停止，主要可以根据以下的因素和标准判断：

1. 考虑因素：

• 是否成功地采用了具体的测试用例设计方法；

• 每一类覆盖的覆盖率情况；

• 故障检测率低于指定的限度。

  • 即每一单元测试时间内检测出的故障数

• 检测出故障的具体数量或消耗的具体时间等。

2. 标准：

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

4. 测试原则：

首先我们需要明白测试依据。测试依据的定义如下：

• 所有的测试都应追溯到用户需求

由此，测试重点应该放在与用户实际需求密切相关的质量要素上。定义哪些质量要素是最重要的就尤为重要。

1. 测试应该尽早介入：

• 应该在测试开始之前的相当长时间，就制定出测试计划

2. 集群现象80-20原则：

• 测试发现的错误中80%很可能起源于20%的模块中
• 测试应该从“小规模”开始，并逐步进行“大规模”测试

3. 重视测试风险评估：

• 穷举测试是不可能的
  • 用最少的用例覆盖更多的功能点
  • 在测试成本、风险和收益之间求得平衡。

4. 杀虫剂原则

• 同样的测试用例被重复使用多次，将不能发现新的缺陷
  • 为了达到最佳的测试效果，应该由独立的第三方来从事测试工作

5. 测试活动需依赖测试对象的背景

• 比如安全性相关的测试对象和一般的商业对象，测试活动是不完全一样的；

6. 不存在缺陷并不代表是有用的系统

5. 测试分类：

1. 按开发阶段划分

• 单元测试

  • 通常由开发者负责完成

• 集成测试

• 系统测试

  • 由独立的测试人员或专门的测试机构进行

• 验收测试

2. 按测试计算划分：

1. 白盒测试（需要知晓内部逻辑结构）

按照程序内部的逻辑测试程序，检验程序中的每条通路是否都能按预定要求正确工作，又称为结构测试

2. 黑盒测试（只是黑盒）

在程序接口进行的测试，它只检查程序功能是否能按照规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，又称为行为测试。

3. 按实施组织划分：

• 开发方测试
• 用户测试
• 第三方测试

4. 按是否执行程序划分

• 动态测试

• 静态测试（只用看代码就好了）

  • 代码审查
  • 代码走查
  • 桌面检查

3. 软件测试与质量保证区别

1. 定义：

• 软件测试：寻找缺陷的策略，关注工作产品

• 质量保证：预防缺陷的策略，关注过程的管理和控制

2. 目标：

软件测试：

• 尽早、尽可能多地发现软件系统中存在的缺陷及问题；

质量保证：

• 通过监控软件开发过程来保证产品质量；
• 保证软件和开发过程符合相应标准与规范；
• 保证软件产品、软件过程中存在的问题得到处理，必要时将问题反映给高级管理者；
• 确保项目组指定的计划、标准和规范适合项目组需要，同时满足评审和审计需要；

3. 工作内容：

软件测试：

• 编写测试计划
• 评审开发工作产品
• 编写和执行测试用例
• 测试结果分析和总结
• 测试数据收集和度量

2. 开发过程及模型

3. 软件测试过程管理