在最近几次活动中使用的"mongochess"演示中，我有一个web应用程序，它公开了一组REST服务，我想要一种简单的方法来验证接口行为在构建过程中没有改变。有一些优秀的自动化测试工具可以处理这些交互（例如，我们在SOASTA的朋友有他们的Web测试自动化技术），但是我需要一些非常简单的东西，我认为这是一个很好的例子，可以展示在Jenkins构建管道中构建定制集成测试是多么容易，并且可以利用CloudBees PaaS来运行他们。通过顺便说一句，如果你对应用程序本身感兴趣，那么源代码在GitHub上，这里有一个简短的概述它在我的博客"持续部署移动应用"中起作用，你可以查看实际的Jenkins配置。对于这个博客，我只对后端管道感兴趣，它包括构建chess服务器和运行一组简短的集成测试。如果您查看mongo-chess集成作业的Jenkins配置，您将看到构建阶段有三个部分：，每个插件都使用一个特定的插件：从另一个项目复制工件（使用Copy Artifact插件）部署到CloudBees（使用CloudBees部署器插件）执行Shell（使用XShell插件）构建作业被设置为在实际构建应用程序的mongo chess作业之后运行，而Copy Artifact插件复制.war文件由那个项目产生的。下面是一个截图，显示了配置：下一个构建中的步骤使用CloudBees部署器插件来部署女人。战争向云蜂报到运行@CloudPaaS运行时。请注意，应用程序检查系统环境中的特定属性（mongochess_mongoURI），该属性用于指定用于连接到MongoDB的mongoURI，我已经使用Override environment按钮（单击Advanced…）来设置此属性，以指定我要用于测试的名称/值对。这是a s克伦肖：一旦应用程序已经部署并运行在CloudBees上，我使用XShell插件运行三个单独的脚本，针对正在运行的应用程序执行一些简单的集成测试。脚本存储在项目工作区的/scripts文件夹中，您可以在这里看到它们。它们使用curl点击REST服务来创建游戏，记录移动，然后回放结果。在mongochess的演示中，我包括了两个短测试和一个长测试，这两个测试是在一个游戏中运行的（Spassky v.Fischer，1972年雷克雅未克世界锦标赛第13场比赛，为国际象棋爱好者准备的！）。看看这个脚本：有几点需要注意：shell脚本将运行在一个轻量级的JEOS（刚好足够的操作系统）Linux上，因此您不应该依赖于标准实用程序之外的包。这就是为什么我使用简单的awk/sed命令，而不是使用jsawk这样的命令：当然，您可以使用附加的实用程序或库，但是您需要确保它们存在于工作区中，并且脚本设置shell环境没错。记得吗脚本中的最后一个命令（这里是diff）将把结果代码返回给Jenkins，从而决定构建步骤的成功与否。我忘记了这一点，并添加了一行清理代码（删除临时文件）：结果是构建总是成功的，即使diff输出显示集成测试没有正确完成。就我们这里的目的而言，实际值和期望值之间的差异不会导致diff返回零，而Jenkins则将其视为成功，否则将导致失败。我有点懒惰，因为我已经将服务的URL端点硬连接到包含curl命令的模板文件中：显然，这是我应该从配置中动态获取的内容。我将在后续的博客中回到这一点，因为这里有几个问题我想进一步探讨细节。最后，这里您可以看到成功生成的输出，而这里是失败的生成。在后一种情况下，我将mongchess_mongoURI环境变量设置为无效值，导致第一个测试脚本失败，因为应用程序无法连接到后端数据库。如果您在工作区中（在"脚本"下），您可以看到实际运行的生成文件（例如。tmpSpasskyFischer.sh)以及我正在测试的预期输出（例如。tmpSpasskyFischer.out).Mark Prichard，产品管理高级总监cloudbeesmark Prichard是CloudBees的Java PaaS宣传员。他在BEA Systems和Oracle工作了13年后来到CloudBees，在那里他是WebLogic平台的产品经理。马克毕业于剑桥圣约翰学院和剑桥大学计算机实验室，为加州洛斯阿尔托斯的CloudBees工作。通过他的博客cloud，Bees和Blogs关注Mark。