实现数据驱动的CodedUI Test

昨天介绍了如何创建一个简单的CodedUI Test。我们也知道,依靠录制回放产生的自动化测试是非常不可靠的,那些在微软的大牛们肯定也早就知道了。虽然用VSTS录制一个自动化测试脚本的过程不是那么友好,也不是很方便,不过它产生的测试代码修改起来还是比较容易的。下面我们就看看如何把一个简单的CodedUI Test改造为数据驱动脚本。

对于每一段录制的操作,VSTS都可以把它抽象成一个方法,它会把这些操作以静态方法的形式存放在一个叫RecordedMethods的类里面。可以对这些方法做任意的修改,我就把给需要输入的方法增加一个输入的参数。

public class RecordedMethods
{
	public static void FirstClick(TestContext testContext, string first)
	{
		//第一个输入
	}

	public static void Operation(TestContext testContext, string operater)
	{
		//操作符
	}

	public static void SecordClick(TestContext testContext, string second)
	{
		//第二个输入
	}

	public static void GetResult(TestContext testContext)
	{
		//按那个等于号
	}
}

Continue reading “实现数据驱动的CodedUI Test”

自动化测试中需要避免“诡异”的测试脚本

什么是“诡异”的测试脚本呢?就是这个脚本在多次运行的情况下,测试结果并非每次都是一致,例如运行10次,有9次是通过的,有1次是失败的,那么这个测试究竟算是通过呢,还是失败呢?答案是:It depends

在某些情况下,那一次失败,的确抓住了程序的某个BUG。原因可能是:

  • 程序在运行一段时间后会出错
  • 程序会出错,但错误不是每次都发生
  • 在某些特殊输入下把错误暴露出来

但是在某些情况下,那1次失败的测试其实只是告诉测试的人,你写了一个“诡异”的测试脚本,实现了一个诡异的测试(Flakey Test)。不幸的是,导致一个自动化测试的行为变得诡异的原因实在太多太多。下面是一些常见的:

  • 竞争条件
  • 测试数据选择不当
  • 测试的前置条件不受控

当发现一个诡异的自动化测试脚本,必须要下决心去改掉它:

  • 使用一些常见有效的用例设计模式,例如“准备,执行,断言(Arrange, Act, Assert)”
  • 使用MOCK技术

总之,当出现一个诡异的测试(Flakey Test)的时候,总是很郁闷的,但是为了以后不要遇到更大的郁闷,我们要尽早发现并且改掉那些诡异的测试。

开源自动化测试框架WatiN 2.0 CTP2已经发布

WatiN是一个开源自动化测试框架,在一些中小型的项目中可以取代昂贵的商业工具,例如QTP。今天WatiN发布了第二个社区预览版(CTP)。这个版本的详细release note还没有出来,但是我已经发现了一个非常好的改进,就是抽象出了IBrowser接口,IE和Firefox这两个类都实现了IBrowser接口,真的可以实现写一次代码,在若干个不同的浏览器中运行自动化测试了。

写一个简单的方法,这个方法要做的就是浏览MySpace聚友网的主页,然后检查一下有没有“关于我们”这段文字(但是即使不存在也没事,这个例子只是意思意思)。
Continue reading “开源自动化测试框架WatiN 2.0 CTP2已经发布”