TestComplete小技巧

录制用户界面操作之间的实际延迟时间如果你希望脚本执行时按照录制时的速度来回放,那么你需要在录制时记录用户操作之间的实际延迟时间。
 
  有两种方式记录用户操作之间的延迟:1、  录制low-level procedure脚本。以这种方式录制的脚本,TC除了记录鼠标和键盘的事件外,还会记录事件之间的延迟时间。所以用户操作之间的延迟能被正确地复制下来。但是要注意low-level procedure是以绝对坐标的方式录制的,因此,如果被测应用程序改变了窗体大小,这种脚本可能会回放失败。
 
  2、  你可以使用Real-time mode选项。如果激活该选项,TC会通过在脚本中插入BuiltIn.Delay的方法记录用户操作之间的实际延迟时间。
 
  Real-time mode的设置通过Tools | Options -> Engines | Recording 打开后勾选。
 
  Code Completion在编写脚本时,通常很难记住很多对象、方法和属性的确切名称。因此TC提供了Code Completion功能,它能帮助你节省很多查阅联机帮助文档和纠正错误拼写的时间。
 
  Code Completion窗口可通过右键显示出来,也可以使用快捷键来触发,默认快捷键是CTRL+Space,这个快捷键与中文操作系统的输入法切换冲突,所以不能生效,需要改变快捷键的设置。
 
  选择菜单Tools | Customize Keyboard ,在Categories选择Edit,然后选择Code Completion,把快捷键改成你想要的,但是又不与其它快捷键冲突的设置。
 
  Code Templates Code Templates,也叫Code Snippets,允许你把预先定义的代码模板插入到脚本代码中,为你节省很多敲击代码的时间。
 
  默认按快捷键CTRL+J就能展开Code Templates界面,让你可以选择需要的代码片断。默认会提供try、while这些常用的代码框架,你也可以自己定制、增加、删除代码片断。选择菜单Tools | Options,在Panels | Code Editor | Code Templates中就可以做这些操作。
 
  Outlining Outlining让你可以更好地组织代码,让脚本代码的结构更加清晰、可读性更强。
 
  Outlining意味着你可以把一些代码组合成在一个区域里(block),然后可以展开或收起这个区域的代码。当展开时,你可以看到block中的所有代码,当收起时,只能看到block的第一行代码。所以Outlining让你可以把一些暂时不需要看到、不需要编辑的代码片断隐藏起来,这在代码行比较多的情况下会很有用。
 
  Outlining的使用方法很简单,只需要选中需要隐藏的代码行,右键选择Outlining | Hide Selection或Outlining | Hide by Definitions,要展开时,选择相应的Expand项或直接点代码编辑器左侧的+号即可展开。

实战groovy -第三部分

用 Ant 和 Maven 进行测试

这个像 JUnit 一样的框架的美妙之处还在于,它可以把整套测试作为 build 的一部分运行,不需要人工进行干预。随着越来越多的人把测试用例加入代码基(code base),整体的测试套件日益增长,形成一个极好的回归平台(regression platform)。更妙的是,Ant 和 Maven 这样的 build 框架已经加入了报告特性,可以归纳 Junit 批处理任务运行的结果。 Read more

实战groovy -第二部分

享受 GroovyTestCase 的快乐

了解 GroovyTestCase 的能力最好的办法,莫过于实际看到它的效果。在清单 3 中,我已经编写了一个新的 SimpleFilterTest,但是这次我要扩展 GroovyTestCase 来实现它:

Read more

实战groovy -第一部分

例如,对于高性能、事务密集型、企业级应用程序,Groovy 脚本通常不太适合;在这些情况下,您最好的选择 可能是普通的 J2EE 系统。但另一方面,一些脚本 —— 特别是用 Groovy 编写的脚本 —— 会非常有用,因为它能迅速地为小型的、非常特殊的、不是性能密集型的应用程序(例如配置系统/生成系统)快速制作原型。对于报表应用程序来说,Groovy 脚本也是近乎完美的选择,而最重要的是,对单元测试更是如此。

 为什么用 Groovy 进行单元测试?

是什么让 Groovy 比起其他脚本平台显得更具有吸引力呢?是它与Java 平台无缝的集成。还是因为它是基于 Java 的语言(不像其他语言,是对 JRE 的替代,因此可能基于旧版的处理器),对于 Java 开发人员来说,Groovy 意味着一条短得让人难以置信的学习曲线。而且一旦将这条学习曲线拉直,Groovy 就能提供一个无与伦比的快速开发平台。

从这个角度来说,Groovy 成功的秘密,在于它的语法 就是 Java 语法,但是规则更少。例如,Groovy 不要求使用分号,变量类型和访问修饰符也是可选的。而且,Groovy 利用了标准的 Java 库,这些都是您已经很熟悉的,包括 Collections 和 File/IO。而且,您还可以利用任何 Groovy 提供的 Java 库,包括 JUnit。

事实上,令人放松的类 Java 语法、对标准 Java 库的重用以及快捷的生成-运行周期,这些都使 Groovy成为快速开发单元测试的理想替代品。但是会说的不如会做的,还是让我们在代码中看看它的实际效果!

 

JUnit  Groovy

用 Groovy 对 Java 代码进行单元测试简单得不能再简单了,有很多入门选择。最直接的选择是沿袭行业标准 —— JUnit。Unit 的简单性和其功能的强大都是无与伦比的,作为非常有帮助的 Java 开发工具,它的普遍性也是无与伦比的,而且没有什么能够阻挡 JUnit 和 Groovy 结合,所以为什么多此一举呢?实际上,只要您看过 JUnit 和 Groovy 在一起工作,我敢打赌您就永远再也不会回头!在这里,要记住的关键的事,您在 Java 语言中能用 JUnit 做到的事,在 Groovy 中用 JUnit 也全都能做到;但是需要的代码要少得多。

入门

在您下载了 JUnit 和 Groovy(请参阅 参考资料)之后,您将有两个选择。第一个选择是编写普通的JUnit 测试用例,就像以前一直做的那样,扩展 JUnit 令人称赞的 TestCase。第二个选择是应用Groovy 简洁的 GroovyTestCase 扩展,它会扩展 JUnit 的 TestCase。第一个选项是您最快的成功途径,它拥有最多  Java 类似的相似性。而另一方面,第二个选择则把您推进了 Groovey 的世界,这个选择有最大的敏捷性。

开始的时候,我们来想像一个 Java 对象,该对象对指定的 string 应用了一个过滤器,并根据匹配结果返回 boolean 值。该过滤器可以是简单的 string 操作,例如 indexOf(),也可以更强大一些,是正则表达式。可能要通过 setFilter() 方法在运行时设置将使用的过滤器, apply() 方法接受要过滤的 string。清单 1 用普通的 Java 代码显示了这个示例的 Filter 接口: 
清单 1. 一个简单的 Java Filter 接口

 public interface Filter {
        void setFilter(String fltr);
        boolean applyFilter(String value);
}

 

我们的想法是用这个特性从大的列表中过滤掉想要的或者不想要的包名。所以,我建立了两个实现:RegexPackageFilter 和 SimplePackageFilter。

把 Groovy 和 JUnit 的强大功能与简单性结合在一起,就形成了如清单 2 所示的简洁的测试套件:
清单 2.  JUunit 制作的 Groovy RegexFilterTest

 import junit.framework.TestCase
import com.vanward.sedona.frmwrk.filter.impl.RegexPackageFilter
class RegexFilterTest extends TestCase {
void testSimpleRegex() {
    fltr = new RegexPackageFilter()
    fltr.setFilter(“java.*”)
    val = fltr.applyFilter(“java.lang.String”) 

    assertEquals(“value should be true”, true, val)
  }
}

 

不管您是否熟悉 Groovy,清单 2 中的代码对您来说应当很面熟,因为它只不过是没有分号、访问修饰符或变量类型的 Java 代码而已!上面的 JUnit 测试中有一个测试用例 testSimpleRegex(),它试图断言 RegexPackageFilter 用正则表达式 ”java.*” 正确地找到了与 “ java.lang.String”匹配的对象。

 

Groovy 扩展了 JUnit

扩展 JUnit 的 TestCase 类,加入附加特性,实际上是每个 JUnit 扩展通常采用的技术。例如,DbUnit框架(请参阅 参考资料)提供了一个方便的 DatabaseTestCase 类,能够比以往任何时候都更容易地管理数据库的状态,还有重要的 MockStrutsTestCase(来自 StrutsTestCase 框架;请参阅 参考资料),它生成虚拟的 servlet 容器,用来执行 struts 代码。这两个强大的框架都极好地扩展了JUnit,提供了 JUnit 核心代码中所没有的其他特性;而现在 Groovy 来了,它也是这么做的!

与 StrutsTestCase 和 DbUnit 一样,Groovy 对 JUnit 的 TestCase 的扩展给您的工具箱带来了一些重要的新特性。这个特殊的扩展允许您通过 groovy 命令运行测试套件,而且提供了一套新的 assert 方法。可以用这些方法很方便地断言脚本的运行是否正确,以及断言各种数组类型的长度和内容等。

软件测试方法比较

1         白盒测试

  优点:

  ● 迫使测试人员去思考软件的实现;

  ● 可以检测代码中的每条分支和路径;

  ● 揭示隐藏在代码中的错误;

  ● 对代码的测试比较彻底;

  ● 最优化。 Read more

敏捷测试中的系统测试模型

1         引言

系统测试是在将软件产品交付给客户使用之前完成的最终产品测试。此测试一般在完成开发和功能验证测试之后进行。某些入口标准用来确定对于系统测试的代码准备状态(举例来说 , 回归状态,缺陷后备,等等)。必须达到这些标准,从而正式地开始系统测试并要求结果。   在一般的系统测试中,目标是用类似客户的配置在高压下对系统进行类似客户的工作量(举例来说,多平台、多软件版本,等等)。 正式的系统测试执行包含压力、寿命期运行、内存泄漏分析、多应用程序、复杂且各种各样的拓扑、高可用性及中断测试、混合的版本测试、全平台测试、产品集成测试,及文档测试。 Read more

如何正确理解自动化测试技术

谈到自动化测试,一般就会提到测试工具。许多人觉得使用了一、两个测试工具就是实现了测试自动化,这种理解是不对的,至少是片面的。的确,测试工具的使用是自动化测试的一部分工作,但“用测试工具进行测试”不等于“自动化测试”。

       那什么是“自动化测试”? 

       半自动化测试过程,算不算自动化测试?

       是否可以为“自动化测试”给出如下定义?   

       以自动化的方式完成测试?   

        测试过程的自动化?

  将手工测试的过程变成了自动化测试的过程?

  摆脱手工测试的各种途径和方法?

  自动化为测试而存在的,所以自动化测试的真正含义可以理解为“一切可以由测试是相对手计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”。它包含了下列3层含义:

  “一切”,不仅仅指测试执行的工作——对被测试的对象进行验证,还包括测试的其它工作,如缺陷管理、测试管理、环境安装、设置和维护等。

  “可以”,意味着某些工作无法由系统自动完成,如脚本的开发、测试用例的设计,需要创造性,其工作需要手工处理。

  即使由系统进行自动化测试,还少不了人的干预,包括事先安排自动化测试任务、测试结果分析、调试测试脚本等。

  严格意义上,“自动化测试(Automated Testing)”不等于“测试自动化(Test Automation)”。自动化测试,模拟手工测试步骤,通过执行程序语言编制的测试脚本自动地测试软件,自动地实施软件的单元测试、功能测试、负载测试或性能测试等。自动化测试集中体现在实际测试执行(test execution)的过程,也就是由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。自动化测试,强调借助工具(不仅仅是工具,有时包括策略和工件)来完成测试的执行,也就是用工具来帮助或辅助测试,这个执行过程可能是全自动的,也可能是半自动的。  测试自动化的要求高得多,侧重说明将测试用自动化设计和实现的过程,即所有的测试工作都能有计算机系统自动完成,包括: Read more

自动化测试方案选择需要考虑的方面

Bob Galen在名为《Sizing up Automation Candidates – Selecting Which Tests,When To Automate Them,and Which To Take Off the Ticket Entirely》的文章中提到:采用什么样的自动化测试方案,需要考虑以下几个方面的因素:

  1、项目的影响:自动化测试能否帮助你的项目进度、覆盖率、风险,或者让开发更敏捷?

  2、复杂度:自动化是否容易实现,包括数据和其他环境的影响。

  3、时间:自动化测试的实现需要多少时间?

  4、早期需求和代码的稳定性:需求或早期的代码是否能证明是在范围内变化的?

  5、维护工作量:代码是否能长期保持相对稳定?功能特性是否会进化?

  6、覆盖率:自动化测试能否覆盖程序的关键特性和功能?

  7、资源:测试组是否拥有足够的人力资源、硬件资源和数据资源来运行自动化测试。

  8、自动化测试的执行:负责执行自动化测试的小组是否拥有足够的技能和时间去运行自动化测试