将自动Web测试集成到构建过程中

Question

我正在寻找改进网站功能测试自动化过程的建议.这是我过去尝试过的.

我以前有一个使用WATIN的测试项目.您可以有效地编写类似"单元测试"的内容,并使用WATIN自动化浏览器点击您的网站等.

当然,您需要运行一个站点.所以我让测试实际上将我的web项目中的代码复制到本地目录,并在任何测试运行之前启动指向该目录的Web服务器.

这样,有人可以从我们的源代码控制中获取最新信息并运行我们的构建脚本,并查看所有测试的运行情况.他们也可以简单地从IDE运行所有测试.

我遇到的问题是我花了很多时间来维护代码来设置测试环境而不是测试.更不用说由于所有复制而花了很长时间才能运行.此外,我需要测试各种方案,包括安装,这意味着我需要能够将数据库设置为各种初始状态.

我很好奇你已经做了什么来自动化功能测试来解决其中的一些问题并且仍然保持简单.

更多细节 由于人们要求更多细节,这里是.我正在使用Visual Studio和Cassini(内置的Web服务器)运行ASP.NET.我的单元测试在MbUnit中运行(但这不是那么重要.可能是NUnit或XUnit.NET).通常,我有一个单独的单元测试框架运行我所有的WATIN测试.在AssemblyLoad阶段,我启动Web服务器并在本地复制我的所有Web应用程序代码.

我对任何平台的解决方案感兴趣,但我可能需要更多关于每个东西的含义的描述.:)

Answer 1

菲尔,

自动化可能难以维护,但您使用自动化进行部署的次数越多,您就可以将其用于测试设置(反之亦然).

坦率地说,当使用构建工具时,更容易发展自动化代码,将其分解并将其重构为特定的小功能单元,这
不仅仅是驱动静态编译的,预先分解的功能单元,就像NAnt和MSBuild的.这就是许多像NAnt这样早期用户的人已经转移到Rake的原因之一.Rake可以自由地将构建代码视为任何其他代码 - 以共同演变其内容和形状.使用Rake可以轻松快速地在自动化工件中使用相同的停滞,并且在Rake中编写脚本比使用NAnt或MSBuild更容易.

因此,你的斗争的某些部分固有地与工具联系在一起.为了保持自动化的合理性和维护性,您应该警惕像NAnt和MSBuild这样的静态构建工具所带来的障碍.

我建议你不要将你的测试环境从装配负载中绑定.这是一种由内而外的耦合,只是为了简单方便.在从IDE或命令行运行测试之前,或者从交互式控制台(例如C#REPL)运行测试之前,执行构建环境的构建任务没有任何错误(并且可能一切正常) Mono项目,或来自IRB.

测试数据设置有时只是一个痛苦的对接.必须要做.

您将需要一个可以调用的库来创建和清理数据库状态.您可以从测试代码中直接进行这些调用,但我个人倾向于避免这样做,因为测试数据或示例数据控制代码的使用不止一次.

我从HTTP驱动所有示例数据控件.我用专门用于控制样本数据的操作编写控制器,并通过Selenium发出GET以对抗这些操作.我使用它们来创建和清理数据.我可以将GET组合成这些操作来创建设置数据的常见场景,并且我可以将数据的特定值作为请求参数传递(或者如果需要,可以传递表单参数).

我把这些控制器放在我通常称之为"test_support"的区域.

我部署网站的自动化不会部署test_support区域或其路由和映射.作为部署验证自动化的一部分,我确保test_support代码不在生产应用程序中.

我还使用test_support代码自动控制整个环境 - 用假货替换服务,关闭子系统以模拟故障和故障转移,激活或停用与这些方面无关的功能测试的身份验证和访问控制等.

控制Web应用程序的示例数据或测试来自Web的数据具有很大的次要价值:在演示应用程序时,或者在进行探索性测试时,您可以通过针对已知(或可猜测)URL发出一些获取来创建所需的数据方案在test_support区域中.真正做出有纪律的努力,坚持宁静的路线和资源导向将真正得到回报.

这个功能自动化(包括测试,部署,演示等)还有很多,所以这些资源设计得越好,你在长长的大厅里维护它们的时间就越多,你找到的机会就越多.以不可预见但有益的方式利用它们.

例如,在网页的语义模型上编写域模型代码将有助于创建更易理解的测试代码并降低脆弱性.如果你做得好,你可以使用那些具有各种不同驱动程序的相同模型,这样你就可以在压力测试和负载测试以及功能测试中利用它们,以及从命令行使用它们作为探索工具.顺便说一下,当你使用静态语言时,你没有被绑定到驱动程序类型时,这种事情会更容易.有许多领先的测试思想家和实干家在Ruby中工作的原因,以及为什么Watir是用Ruby编写的.重用,组合和表达在Ruby中比C#测试代码更容易实现.但这是另一个故事.

让我们赶上一些时间再谈谈其他90%的东西:)