足企业的这方面的需求。一个集成开发环境会加快脚本的 开发速度和调试速度,但是并不能够加快脚本的执行速度。所以,在一些业界比较优秀的自动化测试框架里面, 并没有提供集成开发环境和调试环境。如果
想开发脚本,使用 UltraEdit, Vim 或者 Emacs 就可以了。调试使 用基本的脚本语言调试出错功能就可以了。 所以我们说,自动化测试框架的开发,也涉及到整个自动化测试活动的开展的绩效评估有冰山效应。如果 不能得到最终的测试报告,IDE环境
设计的再好,也看不到绩效:
从这个角度来说,一个自动化测试框架的设计的成功,应该是重执行和测试结果的收获的生产效率,而不 是偏重开发环境的好坏和脚本开发的生产效率。 是分布式测试框架还是统一的测试框架好? 是分布式测试框架还是统一的测试框架好? 这是自动化测试框架设计中面临了又一个测试抉择。 分布式的测试框架,有点像早期的软件开发,微软的方式,就是每个人一套
软件。每个人一个测试框架。 这个测试框架是由测试人员独享的。他在这个测试框架上执行测试用例,收获测试结果。 统一的测试框架,有点类似于当今 Web2.0 的概念,是以提供服务,而不是软件为主的。整个公司的测试 人员都同意到一个服务器上去提交测试任务,这个统一的测试框架会有自己的任务调度功能,优先级处理功能 等来统一执行提交的测试任务,并把测试结果返回给提交相应测试任务的测试人员。 通常,是有一个 Web 界 面的人机接口。
那么,是一人一套框架好呢?还是大家共用一个框架好呢?在设计原则上,并没有优劣之分。虽然有人说, Web2.0 的方式是大势所趋,云计算已经成为了趋势。一个统一的基于客户端服务器架构的自动化测试框架会 便于管理,便于跟踪,但是,统一的框架需要复杂的进度调度和测试环境的协调(共用使用物理测试环境所造 成的冲突)。 相对来说,一个人一套自动化测试框架的设计方法直接,实现简单,部署容易,管理花费少。可 以让大家很快的用起来,能够早的看到测试结果。而对自动化测试框架来说,越快看到结果(测试结果)越能 得到管理层的支持和投资。 所以,在项目初期的时候,建议可以使用一个测试工程师一套框架的方法,在大家等候使用起来以后,在 把这套框架移植到统一的服务器上去。做一个渐进式的,逐步演化的测试框架,而不是在项目一开始就设计一 个一个高,大,全的自动化测试框架,让大家等的望眼欲穿。 自动化测试框架中API设计原则有哪些? 自动化测试框架中API设计原则有哪些? API设计原则有哪些 API 的封装的好坏涉及到脚本的开发效率和可维护性。有经验显示,相对于设计水平一般的 API,一套好 的自动化测试 API 可以提高自动化脚本的开发效率 2-3 倍,一般来讲,需要进行三层封装:
总的来说,自动
化框架中设计的好的 API 有两个原则要把握: 隐藏测试设备的复杂性,针对测试逻辑提供统一的接口。 熟悉软件测试的工程师都知道,测试当中,是 需要使用很多辅助测试设备的,这些设备,有可能是 PC 上的运行的测试软件,有可能是专用的测试设备。而 很多时候,不同的测试设备往往都是做同样的测试活动。如简单的 Web 页面自动化就可以使用 QTP, Winrunner,Selenium 等。封装的好的 API,应该能够隐藏底层使用的测试工具。而对测试人员提供统一的编 程接口。测试人员只需要下达操作动作,而具体这个动作使用了那些测试工具来实现,是 API 内部的事情, 不需要测试人员分心。 关键字驱动:关键字驱动的意思是 API 的封装的程度要和测试用例描述的程度相同。如测试用例中描述: “
注册是一个新用户,并验证生效”,那么相应的API的设计的关键字就需要有“Register $user_name”这个关 键字,并能够根据返回值来验证动作是否成功。测试人员不需要去担心在那个页面,如何输入等具体的细节。