2.5. 测试框架
测试框架对于产生成功的测试自动化的适当基础是重要的。很多考虑必须被解决以使测试自动化更加有效地被使用。重点必须在:
- 维护成本
维护成本是成功的使用自动化测试的最重要的问题之一。维护成本直接联系到前面已经提到过的自动化测试的成熟度。组织或者项目必须至少要在成熟度的 3 级使用高度的测试库才能使维护和更新测试功能变得容易。 - 测试数据
什么样类型的数据将被使用?要为每一个测试用例生成测试数据还是使用在被测试应用中已有的数据。在很多的情况下一个测试数据被创建了,删除他们是不可能的。 - 可测试性
自动化测试方案能够有效的测试吗?例如,被适当命名的对象(不仅仅是索引 Id)。一个简单的例子是所有的对话框都有相同的 #id 和相同的标题,所不同的仅仅是显示的文字信息。当测试应该覆盖多种语言的方案时,对话框的测试就是一个挑战。 - 测试人员的技能
被包括在自动化测试的创建中的人员应该具有什么样的技能呢?如果他们具有良好的开发背景,那么成熟度 3 级是足够了。如果他们有很少的或者根本没有开发的经验,我们被迫使找到或者培训一个自动化测试专家的小组,并直接到达成熟度 5 级,在成熟度 5 级测试的创建与实际的测试执行被分离开。 - 一个好的构建过程
自动化测试的引入在"构建团队"上加入了一些约束。为了实现自动化测试的高利用率(回归测试),要求具有一个高的构建频率。每周仅仅运行自动化的测试不是好的自动化测试的使用率。将回归测试增加到每天一次将帮助快速的发现新的问题并使开发人员更加容易的发现问题的根源,因为对测试的反馈时间是比较短的(开发人员能够记住他们昨天做了什么)。 - 所有权
不同的测试库的所有权的定义是重要的。一个好的方案会将测试库的组织划分为三个级别:
- 级别 1 - 全局的
这个一个通常的级别。被存储在这个级别的测试功能能够被所有的项目访问。通用的和通常的功能象登陆、创建一个用户都是这个级别很好的候选者。 - 级别 2 - 项目
在这个级别的测试功能是与特定的测试项目相关的,但是通常在项目中有用的比一定在项目外是有用的。通常级别 2 是级别 1 的功能的提供者。 - 级别 3 - 脚本
功能被直接关联到特定的测试脚本。 I在这个级别中,通常一个测试功能的第一个版本是被开发的。在新的测试脚本的创建期间已有测试功能的重用性被发现,并被移到了级别 2 中。
在这个级别上尽量最小化功能的数量,因为它将增加维护工作量。
- 级别 1 - 全局的
还有很多有关测试框架的问题,但是这里所提及的是一些基本的要被解决的问题。
3. 在哪里使用自动化测试
有很多的情况下使用自动化的测试可以降低测试成本。我将尽量的突出在自动化测试中的不同的测试技术
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/