一个好的构建过程
自动化测试的引入在"构建团队"上加入了一些约束。为了实现自动化测试的高利用率(回归测试),要求具有一个高的构建频率。每周仅仅运行自动化的测试不是好的自动化测试的使用率。将回归测试增加到每天一次将帮助快速的发现新的问题并使开发人员更加容易的发现问题的根源,因为对测试的反馈时间是比较短的(开发人员能够记住他们昨天做了什么)。
所有权
不同的测试库的所有权的定义是重要的。一个好的方案会将测试库的组织划分为三个级别:
级别 1 - 全局的
这个一个通常的级别。被存储在这个级别的测试功能能够被所有的项目访问。通用的和通常的功能象登陆、创建一个用户都是这个级别很好的候选者。
级别 2 - 项目
在这个级别的测试功能是与特定的测试项目相关的,但是通常在项目中有用的比一定在项目外是有用的。通常级别 2 是级别 1 的功能的提供者。
级别 3 - 脚本
功能被直接关联到特定的测试脚本。 I在这个级别中,通常一个测试功能的第一个版本是被开发的。在新的测试脚本的创建期间已有测试功能的重用性被发现,并被移到了级别 2 中。
在这个级别上尽量最小化功能的数量,因为它将增加维护工作量。
还有很多有关测试框架的问题,但是这里所提及的是一些基本的要被解决的问题。
3. 在哪里使用自动化测试
有很多的情况下使用自动化的测试可以降低测试成本。我将尽量的突出在自动化测试中的不同的测试技术
技术 | 描述 | 备注 |
单元测试/组件测试 | 这个测试工作通常是开发人员的职责,很多不同的方法能够被使用,比如"测试先行",它是一个测试框架,开发人员在编写代码前编写不同的单元测试。当测试通过时,代码也被完成了。 | 通过使用正式的单元测试,不仅能够帮助开发人员产出更加稳定的代码而且能够是软件的整体质量更加的好。 |
冒烟测试 | 冒烟测试是一般验证别测试系统的功能性测试用例的集合。冒烟测试背后的思想是确保基础是可以工作的,以便"大的"测试工作能够开始。 | 在构建过程能够确保构建已经为测试准备好时,冒烟测试通常是自动化的运行。 |
功能/集成测试 | 这里测试的工作关注在验证在不同的组件之间的集成上。 | 这些类型的测试通常是被测试系统的更加复杂测试的基础,大量的边缘测试被合并以制造出不同的错误处理测试。 |
系统测试 - 用例测试 | 这种测试是通过执行用户场景模拟真实用户使用系统以证明系统具有被期望的功能的测试。 | 这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的,因为系统的环境是恒定不变的。 |
回归测试 | 回归测试实际上是重复已经存在的测试。通常如果是手工完成的化,这种测试只在项目的结尾执行执行一到两次。 | 这里完全有潜力应用自动化的测试。你能够在每次构建完成后执行自动化的回归测试,以验证被测试系统的改变是否影响了系统的其他功能。 |
性能测试 |
性能测试包括以下不同测试形式: - 负载测试 - 压力测试 - 并发测试 -..... |
如果没有自动化的测试工具,你将不能执行通过模拟用户的负载实现的高密集度的性能测试。 |
4. 什么时候使用自动化测试
我对什么时候应该使用自动化测试和什么时候应该使用手工测试进行了一个概要的总结:
使用自动化测试 | 使用手工测试 |
|
|