测试层次和组织1-基本介绍

测试层次和组织

测试存放地点

测试存放地点取决于测试在何处运行及由何人运行，以下是两个分类

• 自动化构建过程的一部分
• 在开发人员机器上运行

自动化构建

• 自动化构建使团队效率更高，更快得到反馈
• 构建过程是一个逻辑概念，它包含了构建脚本，构建集成服务器，构建触发器以及团队对代码部署集成方式的了解和认同。

构建脚本结构

脚本分为：

• 持续集成脚本，包括所有单元测试和当前代码的调试版本。需要等结果出来再继续开发。
• 每日构建脚本，在持续集成后触发，时间较长，可以不用等结果。
  • 和持续集成无关或者不重要的，就没有包括在持续集成中，而是在每日构建中。
  • 构建内容包括发布版本构建，运行所有长时间测试，部署第二天用的测试环境。
• 部署构建脚本，由持续集成服务器触发，交付到远程服务器上。

触发构建和集成

持续集成服务包括

• 按照指定事件触发构建脚本
• 提供构建脚本上下文及数据，例如版本、源代码、其他构建生成物和构建脚本参数。
• 提供构建历史和指标概览。
• 提供所有活动和非活动构建的当前状态

构建包括：

• 需要执行的命令
• 会有上下文：代码当前的快照，构建脚本使用的环境变量或命令行参数，不同的构建配置中复制生成物
• 有历史信息

单元测试和集成测试

单元测试失败的原因：

• 被测试的代码有缺陷
• 测试本身实现的问题
• 测试不再适用
• 运行测试需要进行配置

推荐把单元测试和集成测试分开，避免因为集成测试中不明的配置需求(上面最后一个)，导致开发认为代码有问题，而不仅仅是配置的问题。

分开单元测试和集成测试为两个区域

• 在单元测试区，只执行单元测试代码，确报测试失败时，是真正的代码问题，而不是配置问题造成的假警报。
• 在集成测试区，隔离长时间的测试，还可以把测试需要的配置文档存放在这里。
• 自动化构建系统可以完成所有配置任务。需要在解决方案或项目中创建一个集成区，如果只运行快速测试，就可以跳过集成区的内容。

测试代码管理

• 测试必须有源代码管理
• 测试代码版本应该和产品代码版本相对应。

测试映射到项目

目标：

• 找到一个项目的所有相关测试
• 找到一个类的所有相关测试
• 找到一个方法的所有相关测试

方法

• 测试项目命名：用被测试项目的名字加上后缀.UnitTests
• 测试类命名：用被测试类的名字加上.UnitTests
• 命名使用复数形式：一个测试类中包含了多个测试
• 每个被测类：对应一个测试类==>最简单和常见的方式，可读性强
• 每个被测的复杂方法：创建单独的测试类
  • 如果发现测试类中的某个测试方法过多，影响了可读性
  • 就单独创建这个方法的测试类
• 测试命名时要包括工作单元的入口方法名，[UnitofWorkName]_[ScenarioUnderTest]_[ExpectedBehavior]

转载于:https://my.oschina.net/zhv/blog/908548