用 Selenium 自动化验收测试

如何使用 Selenium 测试工具对 Ruby on Rails 和 Ajax 应用程序进行功能测试

Christian Hellsten, IT 专家, IBM

简介：验收测试（也称功能测试）是用来测试手工任务的功能的，但是手工测试这些任务可能很花时间，并且容易出现人为的错误。在本文中，作者为架构师、开发人员和测试人员展示了如何使用 Selenium 测试工具来自动化验收测试。通过自动化测试，可以节省时间，并消除测试人员所犯的错误。文中还给出了一个例子，以演示如何将 Selenium 应用到现实中使用 Ruby on Rails 和Ajax 的项目上。

Web 应用程序的验收测试常常涉及一些手工任务，例如打开一个浏览器，并执行一个测试用例中所描述的操作。但是手工执行的任务容易出现操作人员人为的错误，也比较费时间。因此，尽可能将这些任务自动化，以消除人为因素，这是一种很好的做法。于是 Selenium 之类的测试工具就有了用武之地。Selenium 帮助您自动化验收测试，从而可以构建经过更严格测试、因而更为可靠也更易于维护的软件。

验收测试也称黑盒测试和功能测试，是测试和检验应用程序是否能按照涉众（stakeholder）的功能性需求、非功能性需求和其他重要需求来运行的一种方法。验收测试是单元测试和组合测试的补充，后两者通常是使用 xUnit 框架编写的。验收测试也可以使用编程语言来编写，但是 Selenium 和其他类似的工具，例如 Fitnesse，也支持用特定于工具的文档格式编写测试。

验收测试与单元测试和组合测试有以下不同之处：

?应用程序是作为一个完整的端到端实体来测试的，而不是像单元测试和组合测试那样，只是测试一个类或一组类。

?验收测试是在用户界面（例如一个浏览器）上执行的，而不是在 Web 应用程序界面上执行的。

?编写测试用例的人不一定知道应用程序的内部结构，因此也被称作黑盒测试。非技术性用户也可以编写验收测试。

背景知识

在讨论 Selenium 之前，我要介绍关于以下三个话题的一些背景知识，因为这些话题虽然不是本文的主题，但是和本文密切相关：

?持续集成

?Ajax

?Ruby/Ruby on Rails

持续集成

持续集成的目标是自动化构建和测试过程，以便每天自动运行一次或多次这些过程，而不是每个月手动地运行一次。使用持续集成的最大好处是，代码的更改会定期地自动被集成。如果系统受损，没有构建成功，Apache Continuum 和Luntbuild 之类的持续集成工具可以自动通过发送电子邮件通知团队（见参考资料）。

Ajax

Ajax 是 Asynchronous JavaScript and XML 的缩写，这是为相当老的技术新创造的一个术语。Ajax 背后的主要思想是，由于只需更新部分页面而不是整个页面，所以 Web 应用程序可以更快地对用户操作做出响应。

Ajax 将更多的复杂性引入到 Web 应用程序中，这一点也反映在测试中。这是因为 Ajax 就像它的名称所表明的那样，使用 JavaScript 和异步 HTTP 请求来更新页面内容。每个浏览器在实现中与其他浏览器相比有一些小小的不同。Selenium 是测试和检测这些差异的很好的工具，因为它在大多数流行的浏览器中都能够运行。

Ruby/Ruby on Rails

Ruby 是一种开放源码的解释型脚本语言，用于快捷、容易地进行面向对象程序设计。它提供了大量的库，而且简单易用，还具有可扩展性和可移植性。该语言是由Yukihiro “Matz” Matsumoto 创造的，目的是让程序员将更多的注意力放在手头的任务上，摆脱语法的烦恼。

Rails 是由 David Heinemeier Hansson 创造的一种全栈的（full-stack）、开放源码的 Ruby Web 框架。Rails 的目标是使现实中的应用程序编写起来需要的代码更少，并且比 J2EE 和 XML 之类的语言更容易。所有层都能够无缝地一起工作，因此可以使用一种语言编写从模板到控制流乃至业务逻辑的各种东西。Rails 使用 YAML 而不是 XML 配置文件以及注释形式的反射和运行时扩展。这里不存在编译阶段——程序修改后将直接运行。

回页首

什么是 Selenium？

Selenium 是 ThoughtWorks 专门为 Web 应用程序编写的一个验收测试工具。据Selenium 主页所说，与其他测试工具相比，使用 Selenium 的最大好处是：

Selenium 测试直接在浏览器中运行，就像真实用户所做的一样。Selenium 测试可以在 Windows、Linux 和 MacintoshAnd 上的 Internet Explorer、Mozilla 和 Firefox 中运行。其他测试工具都不能覆盖如此多的平台。

使用 Selenium 和在浏览器中运行测试还有很多其他好处。下面是主要的两大好处：

?通过编写模仿用户操作的 Selenium 测试脚本，可以从终端用户的角度来测试应用程序。

?通过在不同浏览器中运行测试，更容易发现浏览器的不兼容性。Selenium 的核心，也称browser bot，是用 JavaScript 编写的。这使得测试

脚本可以在受支持的浏览器中运行。browser bot 负责执行从测试脚本接收到的命令，测试脚本要么是用 HTML 的表布局编写的，要么是使用一种受支持的编程语言编写的。

Selenium 适用于以下浏览器：

Selenium 命令

通过 Selenium 命令，脚本编写者可以描述 browser bot 在浏览器中所执行的操作。可以将这些命令分成两类——操作（action）和断言（assertion）：

?操作模拟用户与 Web 应用程序的交互。例如，单击一个按钮和填写一个表单，这些都是常见的用户操作，可以用 Selenium 命令来自动化这些操作。

?断言验证一个命令的预期结果。常见的断言包括验证页面内容或当前位置是否正确。

在 Selenium 网站上可以找到可用命令的完整列表（见参考资料）。

Selenium 模式

可以按两种模式来使用 Selenium：test runner和driven。这两种模式在复杂性和编写方式方面有所不同。driven 测试脚本编写起来往往要更复杂一些，因

为它们是用编程语言编写的。但是如果使用 Python 或 Ruby 之类的高级动态编程语言，那么这种复杂性方面的差异就很小。

两种模式之间最大的不同点在于，如果使用 driven 脚本，测试有一部分在浏览器之外运行，而如果使用 test runner 脚本的话，测试是完全在浏览器中运行的。

不管是 test runner 还是 driven 测试用例，都可以与持续集成工具集成。

test runner 模式

Selenium test runner 脚本，也称测试用例（test case），是用 HTML 语言通过一个简单的表布局编写的，如清单 1所示。

清单 1. Selenium 测试用例的结构

test runner 脚本通常与所测试的应用程序（AUT）部署在同一个服务器上。这是因为 browser bot 使用 JavaScript 来模拟用户操作。这些脚本在一个受限制的沙箱环境中运行。如果需要绕过这些限制，可以使用一个代理。

test runner 脚本使用与 xUnit 框架相同的测试套件（test suite）和测试用例概念。测试用例和命令按照它们在测试套件和测试用例中出现的顺序依次执行。在清单 1中：

?第一列包含命令或断言。

?第二列包含命令或断言的目标（target）。这里可以用多种受支持的组件定位符中的一种来指定目标。通常使用的是组件的 ID 或名称，但 XPath 和 DOM 定位符也是受支持的。

?第三列包含用于为命令或断言指定参数的值。例如，当使用 type 命令时，这一列可能就是一个文本域所期望的值。

即使对于非技术人员来说，test runner 脚本也易于阅读和编写。当在一个浏览器中打开清单 1中的例子时，将得到类似这样的一个表：

接下来，我将描述如何使用命令和断言编写一个简单但是完整的测试用例。

测试用例实例

执行清单 2中的测试脚本时，它将执行以下操作：

1.通过进入 /change_address_form.html 打开变更地址页面。

2.在 ID 为 address_field 的文本框中输入 Betelgeuse state prison。

3.单击名为 Submit 的输入区。注意，这里使用 XPath 找到Submit按钮，

这导致表单数据被发送到服务器。

4.验证页面是否包含文本 Address change successful。

清单 2. 在测试用例中使用命令和断言的例子

测试套件

要达到对应用程序的完全测试覆盖，通常需要不止一个测试用例。这就是Selenium 使用测试套件的原因。测试套件用于将具有类似功能的一些测试用例编成一组，以便让它们按顺序运行。

测试套件和测试用例一样，都是用简单的 HTML 表编写的。Selenium 执行的缺省测试套件的名称是 TestSuite.html。清单 3展示了一个测试套件，该套件像通常的用户一样测试应用程序。注意，测试套件使用一个只包含一列的表，表中的每一行指向一个包含某个测试用例的文件。

清单 3. 测试套件示例

接下来我将把目光转移到 driven 测试脚本。

driven 模式

driven Selenium 脚本是用多种受支持的编程语言中的一种编写的——目前可用的有 Java、Ruby 和 Python 驱动程序。这些脚本在浏览器之外的一个单独的进程中运行。驱动程序的任务是执行测试脚本，并通过与运行在浏览器中的browser bot 进行通信来驱动浏览器。驱动程序与 browser bot 之间的通信使用一种简单的特定于 Selenium 的连接语言 Selenese。

driven 脚本比 test runner 脚本更强大、更灵活，可以将它们与 xUnit 框架集成。driven 脚本的缺点（与 test runner 脚本相比）是，这种脚本编写和部署起来更复杂。这是因为驱动程序必须执行以下任务：

?启动服务器。

?部署所测试的应用程序（AUT）。

?部署测试脚本。

?启动浏览器。

?发送命令到 browser bot。

?验证 browser bot 执行的命令的结果。

driven 脚本更依赖于应用程序运行时环境。例如，Java 驱动程序使用一个嵌入式 Jetty 或 Tomcat 实例来部署所测试的应用程序。目前，已经有人在致力于将 Selenium 集成到 Ruby on Rails 中，但是在我撰写本文之际，这个集成版本还没有被发布。

清单 4摘自一个使用 Ruby 驱动程序的 driven 测试脚本。注意，我省略了用于启动服务器和浏览器的步骤，这个测试脚本代码几乎和 test runner 脚本一样简单。

清单 4. 使用 Ruby 驱动程序的例子

.

.

puts selenium.open('/logout.html')

puts selenium.verify_location('/index.html')

.

.

现实中的需求

在接下来的两节（现实中的需求和现实中的用例）中，我将描述如何在现实场景中使用 Selenium，并针对用 Ruby on Rails 和一点儿 Ajax 技术编写的一个简单的股票报价查看器应用程序编写 Selenium 测试用例。虽然这个应用程序是用 Ruby on Rails 编写的，但是也可以将这个例子应用于任何 Web 应用程序，因为测试脚本是按 test runner 模式以 HTML 编写的。这个示例应用程序是用Ruby 1.8.3 和 Ruby on Rails 0.14.2 测试的，但是它也可能可以使用更旧的或更新的版本。

如果有 Linux，那么发行版中通常已经包括了 Ruby。在命令提示符下运行 ruby -v，检查您所拥有的版本。对于大多数平台，都可以在

https://www.wendangku.net/doc/3717430053.html,/上找到一个 Ruby 发行版。

接下来的步骤是通过 RubyGems 打包系统安装 Ruby on Rails。为此，只需执行gem install rails --include-dependencies。在某些平台上，必须执行一些额外的步骤，所以请访问Ruby on Rails网站，以获得更多细节。

在我撰写本文之际，目前可用的 Selenium 版本是 0.6。我已经将它集成在示例应用程序中（见下载小节），我的做法是从

https://www.wendangku.net/doc/3717430053.html,/下载 Selenium Core 包，然后将名为selenium 的文件夹复制到用于静态内容的文件夹。在 Ruby on Rails 应用程序中，这个文件夹的名称是 public。在 J2EE Web 应用程序中，可以将 selenium 文件夹放在 Web 应用程序的根目录或 WAR 归档文件中。

最后一步是下载示例应用程序。从下载小节中获得这个包。解压应用程序，并打开一个命令提示符。然后转入应用程序被解压到的那个目录。为了启动应用程序，运行 ruby script/server。应该看到 Rails 成功启动了，如图 1所示。

图 1. 从命令提示符下运行 Ruby on Rails

现实中的用例

在本节中，我将列出示例应用程序的用例。通过这些简化的用例，可以编写模拟用户所执行步骤的验收测试，并验证这些步骤的结果是否与预期相符。股票报价应用程序实现了以下四个用例：

?登录

?查看股票

?查看股票细节

?退出

实现这些用例的代码已经编写好了；可以在 app 目录中找到该代码，测试用例在 public/selenium/tests 文件夹中。

登录用例

大多数人都知道登录页面是如何工作的——输入用户名和密码，然后将数据提交到服务器。如果凭证有效，就可以成功登录，并看到受安全保护的资源。在示例应用程序中，这个测试用例包含以下用户操作和断言，必须将它转换成一个Selenium 测试用例：

1.单击登录链接。

2.验证系统是否要求用户进行登录。

3.输入用户名。

4.输入密码。

5.按下登录按钮。

6.验证是否登录成功。

图 2展示了用于这些需求的 Selenium 测试用例。注意，我是在运行测试之后截取屏幕快照的。绿色箭头表示成功地通过验证的断言。

图 2. 登录和查看股票测试用例

查看股票测试用例

查看股票页面显示一个公司列表。用于这个页面的测试用例非常简单，所以被包括在前一个测试用例的后面。该测试用例验证当前位置是否为

/main/list_stocks，以及页面是否包含文本 Click on a company name to view details。

查看股票细节用例

查看股票细节用例是在查看股票页面上触发的。用户在一个公司名称上单击鼠标时，就触发了到服务器的一个 Ajax 请求。服务器的响应包括该公司的详细信息，这些信息将插入到当前页面中，而不必重新装载完整的页面。用于这个用例的测试用例执行以下用户操作：

1.单击公司名称 Acme Oil。

2.验证页面上是否显示该公司的详细信息。

3.单击公司名称 Acme Automotive。

4.验证页面上是否显示该公司的详细信息。

由于使用了 Ajax，请求是异步发生的。在一般的 Web 应用程序中，所有东西通常都是同步的，因此这一点提出了一种不同的挑战。可以像测试其他功能一样来测试 Ajax 功能。惟一的不同是，必须让 Selenium 暂停，等待 Ajax 命令完成。为此，可以使用 pause 命令来等待 Ajax 命令的完成。另外，Joseph Moore 在他最近的 blog 贴中提到，还可以使用 waitForValue 和 waitForCondition 命令代替 pause 命令（见参考资料）。

图 3展示了被转换成 Selenium 用例的需求。

图 3. 查看股票细节测试用例

注意 pause 命令：必须使用这些命令，以便等待异步请求完成和更新页面内容。如果没有 500 毫秒的暂停，测试将失败（如图 4所示）。

图 4. 失败的查看股票细节测试用例

pause 命令还测试 Ajax 功能的非功能性需求。500 毫秒对于 pause 命令是一个很好的值，因为 Ajax 请求应该快速地执行和完成。可以试着去掉 pause 命令，看看结果如何。如果测试在您的机器上失败，那么试着将这个值增加到 1000 毫秒。

退出用例

退出用例很容易实现，简单来说只有以下两步：

1.单击退出链接。

2.验证是否成功退出。

图 5展示了最后这个测试用例。

图 5. 退出用例

所有测试都被添加到图 6左侧显示的缺省测试套件中。

图 6. 示例应用程序的测试套件

执行测试套件

最后要做的是在 Mozilla Firefox 和 Microsoft Internet Explorer 中执行测试套件。为此，在浏览器中打开

http://localhost:3000/selenium/TestRunner.html，然后单击图 6中所示的All按钮。失败的测试用例和断言将被标记为红色，但是这里，在两个浏览器中所有用例都应该可以成功完成（同样见图 6）。注意，我使用的是 Mozilla Firefox 1.0.7 和 Internet Explorer 6.0。

还可以单步调试测试套件，这意味着 Selenium 将很慢地执行测试套件，这样当测试套件在浏览器中执行时，就可以看到它的每一步。

Selenium 是软件工程师、设计人员和测试人员的工具箱中又一个有用且重要的工具。通过将该工具与持续集成工具相结合，团队就可以将验收测试自动化，并构建更好的软件，因为他们可以更容易、更早、更频繁地发现 bug。Selenium 的另一个优点是可以节省时间，使开发人员和测试人员不必将时间花在本可以（也应该）自动化的手工任务上，从而让团队将精力放在更有价值的活动上。

描述名字大小下载方法Sample application wa-selenium-ajax-example.zip 286KB HTTP

参考资料

学习

?您可以参阅本文在 developerWorks 全球站点上的英文原文。

?查看可用Selenium 命令的完整列表。

?参阅 Wikipedia 对验收测试的定义。

?看看在这个集体讨论会中大家如何看待Selenium 到 Ruby on Rails 的集成。

?参阅 Wikipedia 对Ajax的定义。

?尝试 Selenium 的 waitForValue 和 waitForCondition 命令——Joseph Moore 提出的 pause 命令的替代品。

?钻研 developerworks 上的这些 Ajax 参考资料：

o Build apps with Asynchronous JavaScript with XML, or Ajax （2005 年 11 月) 演示了如何用 Ajax 构建支持实时验证的 Web

应用程序。

o面向 Java 开发人员的 Ajax: 构建动态的 Java 应用程序（2005 年 9 月）是关于使用 Ajax 开发应用程序的指南。

o AJAX 及使用 E4X 编写 Web 服务脚本，第 1 部分（2005 年 4 月）是关于 Ajax 的初级读物。

o面向 Java 开发人员的 Ajax: 结合 Direct Web Remoting 使用Ajax（2005 年 11 月）演示了如何自动化 Ajax 的繁重工作。

?阅读归档的诊断 Java 代码系列（developerWorks，2001 年），包括作为最佳编程实践和调试实践的测试任务的自动化。

?在 developerWorks 上查看所有Ruby 和 Ruby on Rails 文章，包括以下难得的资料：

o教程使用 Ruby 进行 socket 编程讲解 Ruby 的基础知识，并给出了用 Ruby 语言开发基于套接字的网络应用程序所用的一些最

重要的类（2005 年 10 月）。

o使用 Ruby on Rails 快速开发 Web 应用程序（2005 年 6 月）描述了用 MVC 模式进行快速开发的一个框架。

o Ruby on Rails 和 J2EE：两者能否共存？（2005 年 7 月）将 Ruby on Rails 与 J2EE 做了比较。

?查看 developerWorks 上的所有Python 文章。

获得产品和技术

?获取关于Selenium工具的详细信息，该工具是 ThoughtWorks 根据用于企业软件开发的敏捷开发方法而创造的。

?访问Ruby on Rails主页和Ruby language主页，以获得为掌握这些技术所需的各种资料。

?查看用于构建基于 Java 的项目的持续集成服务器Continuum。

?研究Luntbuild，这是一个强大的构建自动化和管理工具，用于自动化构建，并充当构建管理系统。

?尝试用Fitnesse作为验收测试框架。

?获取Mozilla Firefox浏览器。

?获取Selenium Recorder，这是一个 Firefox 扩展，通过它可以记录Selenium 测试脚本。

智能运维：浅谈持续集成( CI)、持续交付(CD) 和软件测试

导读：浅谈CI/CD 和软件测试 知其然，知其所以然。相较于DevOps而言，CI/CD是一个相对具象的概念。在IT 企业中，CI/CD的应用愈加广泛，成为推动软件研发活动的重要基础设施服务，同时推动DevOps 模式的实际落地。 什么是CI/CD 在实践CI/CD 相关内容之前，我们有必要先认识下什么是CI/CD。 一般传统或者狭义、普遍的CI/CD，是指持续集成（Continuous Integration，CI）和持续交付（Continuous Delivery，CD）。而更加广义、全面的理解，是指持续集成（Continuous Integration，CI）、持续测试（Continuous Testing，CT）、持续交付（Continuous Delivery，CD）和持续部署（Continuous Deployment，CD）四个方面。通常，一个软件开发的流水线如下图所示。 ?Design：这一阶段完成软件开发的需求分析和设计。 ?Develop：这一阶段完成软件开发的功能代码，一个最佳实践是采用测试驱动开发（TDD）的方法，测试代码和功能代码的编写同时 进行。需要注意的是，在Develop 阶段也会运行单元测试和其他 小型测试。 ?Test：这一阶段完成软件的各项大型或专项测试，比如界面测试、API 测试、性能测试和系统测试等。

?Release：这一阶段完成软件产品的发布，并交付给用户使用。 持续集成（Continuous Integration） 随着敏捷开发的发展，持续集成在软件项目活动中也日益成为主流。顾名思义，持续集成是指每日频繁地（比如一天多次）将代码集成到主干分支中。强调通过集成和测试的速度，快速给出一个集成的结果（是失败还是成功），在代码集成之前，必须先通过自动化测试验证，只要有一个测试用例失败，就不能集成。 Martin Fowler 说过，“持续集成并不能消除Bug，而是让它们非常容易被发现和改正”。这也正是持续集成的真谛所在。 敏捷开发的核心是指整个软件开发活动被划分成一系列短的迭代过程，每个迭代完成一定数量的功能，迭代周期应该尽量短。在软件开发需求已经确定的情况下，迭代应该由测试驱动开发（TDD）和集成反馈来驱动。只有这样，才能为质量持续改进奠定一个良好的基础。

Selenium安装以及简单的自动化测试用例

Selenium安装以及简单的自动化测 试用例 中科软科技股份有限公司 2013年4月 V1.0.0

关于本文档 说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；

目录 目录 (3) 1.Selenium介绍 (3) 2.相关组件 (3) 3.启动seleniumRC (4) 4.简单测试用例 (4) 4.1在火狐浏览器上下载并打开selenium IDE (5) 4.2录制测试用例 (6) 4.2.1 录制 (6) 4.2.2 检查 (6) 4.2.3 语言转换 (6) 4.2.4 准备Eclipse环境 (7) 4.2.5 运行 (9) 1.Selenium介绍 Selenium是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE、Mozilla Firefox、Mozilla Suite等。 功能： ●测试直接在浏览器中运行，就像真实用户所做的一样，从终端用户的角度测试应用程序。 ●使浏览器兼容性测试自动化成为可能。 ●使用简单，可生成多种语言的用例脚本。 2.相关组件 ●Selenium IDE：一个Firefox插件，可以录制用户的基本操作，生成测试用例。随后可以 运行这些测试用例在浏览器里回放，可将测试用例转换为其他语言的自动化脚本。

●Selenium Remote Control (RC) ：支持多种平台(Windows，Linux，Solaris)和多种浏览器(IE， Firefox，Opera，Safari)，可以用多种语言(Java，Ruby，Python，Perl，PHP，C#)编写测试用例。 ●Selenium Grid ：允许Selenium-RC 针对规模庞大的测试案例集或者需要在不同环境中 运行的测试案例集进行扩展。 3.启动seleniumRC 官网下载：https://www.wendangku.net/doc/3717430053.html,/download/。打开cmd，进入RC存放文件夹。在命令行输入：java –jar selenium-server.jar 。 启动成功。 注意在启动RC前，确认电脑上安装JDK版本高于1.5 4.简单测试用例 以OA系统登录为例：

持续集成测试

一、概念引入 持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。 在敏捷开发中，有一个很重要的实践叫做持续集成。而什么是持续集成呢？简单来说，持续集成是频繁、持续的在多个团队成员的工作中进行集成，并且给与反馈。一个典型的持续集成周期包括以下几个步骤： 1.持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有 更新。 2.如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码。 3.等代码完全更新以后，调用自动化编译脚本，进行代码编译。 4.运行所有的自动化测试。 5.进行代码分析。 6.产生可执行的软件，能够提供给测试人员进行测试。 测试是持续集成流程中重要的一环，也是区别去传统的软件开发流程中的一个重要的标志。为什么要有持续集成测试呢？ 每天，程序开发人员将各自开发的代码上传到配置管理工具（如SVN、VSS）中，而配置管理工具会记录下谁在什么时间上传了什么代码文件。随后，持续集成工具会定期（可以是几个小时、半天，或者一天，由使用者自己定义）向配置管理工具询问，从上一周期到现在是否有代码上传。如果有，则下载到持续集成工具中进行集成。之后，持续集成工具会调用构建工具代码编译、自动化测试，以及执行静态代码检查。如果这几项工作执行成功，则打包复制到应用服务器（如Weblogic）上执行重新发布，并形成代码检查与测试等报告；如果执行失败，则及时通过邮件通知管理者，并记录相关日志。 配置管理工具 毫无疑问，配置管理工具对持续集成工具来说是绝顶重要的，它是所有最新代码的来源。持续集成工具会定期向配置管理工具询问代码是否有更新。只有有了更新，持续集成工具才会去完成后续的工作，否则就没有了意义。目前在Java开发项目中，最主流的无疑是Subversion（简称SVN）。SVN是对CVS的升级，它通过插件的形式被集成到开发工具中，并且提供了更加方便的上传下载操作，使开发人员最厌恶的上传下载操作变得简便。SVN的另一个巨大贡献是改变了VSS 那样的串行修改模式。众所周之，VSS的版本管理思路就是串行修改模式，即对于同一个文件只能一个人修改，其他人不能修改。这样的模式对应大规模团队开发来说无疑是非常蹩脚的。SVN改变了这种模式，同一个文件可以多人并行操作，但同时SVN又提供了强大的版本冲突处理机制，当并行操作的多人各自提交版本时，通过版本冲突处理机制可以顺利的合并版本，使最终形成统一版本。

持续集成与测试自动化

持续集成与测试自动化 https://www.wendangku.net/doc/3717430053.html,原创作者：黄良生 一、背景 我从毕业到现在, 曾在大小不同的三个公司就职: 有民营的、有外资的、也有上市公司。但以前大多都是做项目，从事软件开发工作，绝大部分公司对测试都不重视，即使有也没有成规模，更谈不上建立测试体系。总之，重开发轻测试的管理思想在中国延续了几十年、并且还要继续，看看他们给测试工程师开的低工资和老师在课堂上讲到测试时一笔带过就知道测试被中国的老板所忽略。 最近两年,我从事CRM软件产品的测试、项目管理工作。由于公司对软件的质量要求特别高，这必然引起了大家对测试工作的重视，不但要求有强大的测试团队，该团队必须具备在业务方面、测试技能方面的专业水平，而且在软件开发过程方面经常由于测试而作持续不断地调整。 幸运的是，随着软件开发技术和工具的提高，软件工程和软件过程实践的推广，软件测试日益得到重视和专业化。我从事测试工作期间，一直研究CMM、测试理论、自动化测试工具，并建立了一套完整的测试体系。 在此并不介绍整个测试体系，而是介绍测试方面最值得探讨的部分：持续集成与测试自动化。目的是与大家共同进步。当然已经有很多关于持续集成和自动化测试方面的介绍,但我要介绍的不只是持续集成,也不只是自动化测试,而是测试如何的自动化. 二、测试自动化 自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，目的是减轻手工测试的劳动量，从而达到提高软件质量的目的。自动化测试的目的在于发现老缺陷。而手工测试的目的在于发现新缺陷。 测试自动化涉及到测试流程、测试体系、自动化化编译、持续集成、自动发布测试系统以及自动化测试等方面整合。也就是说要让测试能够自动化，不仅是技术、工具的问题，更是一个公司和组织的文化问题。首先公司从资金、管理上支持您，其次要有专门的测试团队去建立适合自动化测试的测试流程、测试体系；其次就是把原代码从受控库中取出、编译、集成、发布可运行系统、进行自动化的单元测试和自动化的功能测试的过程。 （一）、自动化测试的好处 1、对新版本执行回归测试－－测试每个特征 对于产品型的软件，每发布一个新的版本，其中大部分功能和界面都和上一个版本相似或完全相同，这部分功能特别适合于自动化测试，从而可以让测试达到测试每个特征的目的。 2、更多更频繁的测试－－沉闷、耗时 我们的产品向市场的发布周期是3个月，也就是我们的开发周期只有短短的3个月，而在测试期间是每天/每2天都要发布一个版本供测试人员测试，一个系统的功能点有几千个上万个，人工测试是非常的耗时和繁琐，这样必然会使测试效率低下。 3、替代手工测试的困难－－300个用户有些非功能性方面的测试：压力测试、并发测试、大数据量测试、崩溃性测试，用人来测试是不可能达到的。在没有引入自动化测试工具之前，为了测试并发，研发中心的一、两百号人在研发经理的口令：1－、2－、3！，大家同时按下同一个按钮。回想起这中情景也蛮有意思的。 4、具有一致性和可重复性 由于每次自动化测试运行的脚本是相同的, 所以每次执行的测试具有一致性, 人是很难做到的. 由于 自动化测试的一致性，很容易发现被测软件的任何改变。 5、更好的利用资源－－周未/晚上 理想的自动化测试能够按计划完全自动的运行, 在开发人员和测试人员不可能实行三班倒的情况下, 自动化测试可以胜任这个任务, 完全可以在周末和晚上执行测试. 这样充分的利用了公司的资源,也避免了

构建robotium+jenkins+TMTS可持续集成自动化测试

Windows下构建robotium+jenkins+TMTS可持续集成自动化测试 前言 TMTS是淘宝的自动化测试构架，优缺点都较为明显 优点：最主要的就是已经实现出错截屏并提供日志 缺点：比较小众化，遇到问题也无人解答 自动化测试终究是要能够持续集成才能有更大的意义的，利用 robotium+jenkins可以实现集成测试，但此时要想得到出错截屏加日志就麻烦了。 TMTS主要由三部分组成 1.TmtsFramework进行自动化用例编写 2.TmtsToolkit进行出错截屏与获取日志报告 3.hudson进行apk包的自动打包、安装，并进行用例执行 TmtsFramework编写用例其实与robotium编写用例一样都是基于instrument 的，因此想用robotium编写用例，而同时又想得到出错截屏与日志报告 就完全可以使用robotium+TmtsToolkit 因此就可以用robotium+jenkins+TmtsToolkit构建可持续集成自动化测试Windows下环境搭建 软件安装 1.安装jdk 2.安装tomcat https://www.wendangku.net/doc/3717430053.html,/download-70.cgi 3.安装ant https://www.wendangku.net/doc/3717430053.html,/bindownload.cgi 4.安装jenkins https://www.wendangku.net/doc/3717430053.html,/ 下载war包，放于tomcat的webapps目录下，启动tomcat将自动部署 5.安装Android SDK

https://www.wendangku.net/doc/3717430053.html,/sdk/index.html 搭建android开发环境，包括eclipse，ADT等 6.下载TMTS架构中的athena-1.1.jar、ddmlib.jar包 https://www.wendangku.net/doc/3717430053.html,/p/TMTS/src/branches/V1.1/trunk/android/AthrunTe st/ 当然最好把整个TMTS下载下来 环境变量PATH添加 \java\apache-ant-1.8.2\bin\ \java\android-sdk-windows\tools\ \java\android-sdk-windows\platform-tools\ \Java\jdk1.6.0_07\bin\ 添加ANDROID_HOME 添加JAVA_HOME 添加ANT_HOME 有什么命令找不到了就加下PATH变量 tomcat启动 运行\java\apache-tomcat-7.0.8\bin\startup.bat jenkins配置 浏览器访问 http://localhost:8080/jenkins 插件安装 Hudson Subversion Plug-in，jenkins的svn插件 Android Emulator Plugin，android模拟器插件 JUnit Attachments Plugin，junit测试报告附件插件 Email-ext plugin，邮件扩展插件。此处说明下，默认Jenkins只会发送构建失败的邮件，我们需安装此插件才能自定义不同场景 除了这些之外还可以安装其它一些插件，那样可以使得Jenkins非常强大，需要什么安装什么 构建build.xml文件，使用ant自动打apk包，构建build.xml文件及ant打包可以参考其它文章 构建任务 1.使用jenkins新建任务时，填入任务名称，选择“构建一个自由风格的软件项目”，以后新建类似任务时则可以选择“复制现有任务”

开源自动化测试工具selenium的使用

开源自动化测试工具selenium的使用 (玉米猫) 一Selenium概述： Selenium是现在使用最为广泛的一款开源自动化测试工具，也是非商业支持的稳定性易用性最好的一款自动化测试工具。和由HP提供强大商业支持的QTP相比，selenium不仅在软件投资上有比较大的优势，在针对web测试的稳定性上也有绝对的优势。以下介绍的内容会通过和QTP在各方面的比较中进行，并针对简单的测试样例，对基本的使用进行简单说明。 二Selenium的组成： 和QTP等其他工具类似，selenium也有几个组件组成，同时在使用的时候还需要一些开发的IDE平台进行支持。 对于初步的简单使用，需要先掌握seleniumIDE，RC的基本使用，以及对象识别方式Xpathe的基本知识。 1)seleniumIDE： selenium和QTP类似，同样需要先进行一定的脚本录制工作，而它默认支持的录制浏览器是firefox，IDE就充当了一个脚本记录的工作，它的表现形式为firefox的一款插件。 它可以记录准备过程中，用户在firefox上的制定网址下所做的一切操作，并转化为自己需要的一种开发语言，包括：java、perl、PHP、C#、Ruby等等。 2)RC： RC是selenium的特色组件，它通过从底层向不同的浏览器发出动作指令，达到用脚本控制web的效果，和QTP的activeX驱动的模式有着本质的不同，只要浏览器的动作指令原理不发生本质性的变化，就可以利用selenium达到自动化测试的效果，不会由于出现新的浏览器，还要等待HP重新开发相应的activeX控件。

3)其他： 由于selenium的非商业支持，所以很多类似于QTP中的组件都使用了firefox插件的办法得到了补充。 Firebug：帮助用户对页面上的对象进行识别，它可以准确捕捉到任何一个可见元素和不可见元素，同时支持由对象找代码和由代码找对象的使用方法，非常类似于QTP的spy 和控件高亮显示功能。 Xpather：帮助用户利用xpath标记对象的位置信息，根据xpath的实现方式，可以将页面上的每一个控件元素做唯一性标识，非常类似于QTP的对象库，区别在于Xpath只记录元素的位置样式属性，不会记录截图。 三Selenium的简单使用： 1)测试的准备工作： 这里所说的准备工作，只一个自动化测试的准备，预计基本的测试用例等内容已经准备完成。 假如被测系统为ADCPX： 首先：用firefox打开被测系统的首页，启动IDE插件。 需要注意的是，IDE的baseUrl一定是当前要测试的web首页，默认生成的第一个testcase 的名称可以通过属性进行更改。一个IDE中可以录制或生成多个testcase。

持续集成：自动化测试篇

持续集成：自动化测试篇 前言 如果组件A\B\C的可靠性都为90%，是否说明了A\B\C组成的系统整体可靠性为90%？其实不是，实际结果是90% * 90% * 90%* = 73%。大部分软件系统都由几百个甚至几千个对象组成，如果包含了100个组件的线性系统，每个组件的可靠性均为99%，那么整个系统的可靠性只有37%。 如果想要构建一个在服务层面承诺到达100%或接近100%的软件系统，则必须在单个对象层面上确保可靠性。如果不能从最低层面确保并测量可靠性，就不可能在系统层面上达到要求。 这就要求我们在每当系统发生变更时测试都必须执行，并且这些测试不单单是单元测试，还应包括组件测试、系统测试等，在日常的开发过程中，反复进行多种测试无疑是枯燥乏味的，在CI系统中包含持续测试则能让你轻松解决这一烦恼。 自动化单元测试 “单元测试”是验证软件系统中所有小元素的行为，这些小元素通常都是一个类。有时单元测试和被测试的类之间一对一的关系也会被放大，因为一些测试的类耦合程度较高。 单元测试没有外部依赖关系，不会依赖于文件系统和数据库。因为编码和看到单元测试之间的时间很短，所以单元测试是一种有效的除错方法。在进行持续集成过程的单元测试时，可以利用NUnit或JUnit单元测试框架，让单元测试自动化。 真正的单元测试应该少于1秒的时间内完成。如果花费的时间较长就需要检查一下，它是否失败了，或者它实际是一个组件级测试。配置自动化测试需要一些代价，但是执行这些测试的资源代价可以忽略不计。

自动化组件测试 “组件测试”或“子系统测试”验证的是系统的各个部分，可能需要安装整个系统或某些外部依赖关系，如数据库、文件系统、网络终端等。 典型的组件测试需要底层数据库支持，甚至可能跨越架构边界，这些测试涉及更多对象，每个测试的代码覆盖率也更大，通常比单元测试需要花更长的时间，如果用到数据库可以使用DbUnit\NDbUnit实现自动化。 组件测试执行的时间比较长，可以作为次级构建的一部分来执行或定期执行。 自动化系统测试 “系统测试”允许整个软件系统，需要完整安装系统，系统测试比组件测试执行时间更长，通常涉及多个组件。 如果事先已成功执行单元测试和组件测试，则已解决一些底层问题，只需要计划定期执行这个耗时较长的测试就可以。也可以作为次级集成构建的一部分，在下班后或夜间执行。 自动化功能测试 “功能测试”也称为“验收测试”，从用户的角度测试应用程序，意味着测试将模仿用户行为，通常是自动化测试套件中执行时间最长的。 开发者测试分组 通过将测试分组，按不同的时间间隔来执行较快（如单元测试）和较慢的（如组件测试）测试，顺序可以设置为：单元测试、组建测试、系统测试、功能测试。 可以“告诉”CI系统在恰当的时候执行每一类测试，构建次数完全可管理，测试定期执行，而不是当它们需要很长时间执行时就抛弃它们。 为缺陷编写测试

持续集成是什么

持续集成是什么 互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称CI）。 本文简要介绍持续集成的概念和做法。 一、概念 持续集成指的是，频繁地（一天多次）将代码集成到主干。 它的好处主要有两个。 （1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 （2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。" 与持续集成相关的，还有两个概念，分别是持续交付和持续部署。 二、持续交付 持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。 三、持续部署 持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。 持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别，可以参考下图。

（图片来源） 四、流程 根据持续集成的设计，代码从提交到生产，整个过程有以下几步。 4.1 提交 流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。 4.2 测试（第一轮） 代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。 测试有好几种。 单元测试：针对函数或模块的测试 集成测试：针对整体产品的某个功能的测试，又称功能测试 端对端测试：从用户界面直达数据库的全链路测试 第一轮至少要跑单元测试。 4.3 构建 通过第一轮测试，代码就可以合并进主干，就算可以交付了。 交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。 常用的构建工具如下。 Jenkins Travis Codeship Strider Jenkins和Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。 4.4 测试（第二轮） 构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。 第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测

selenium自动化测试的框架

selenium 自动化测试的框架 自动化测试的框架 软件自动化测试 style="font-family: 宋体 ;mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin;mso-fareast-font-family: 宋体 ;mso-fareast-theme-font: minor-fareast;mso-hansi-font-family:Calibri;mso-hansi-the me-font:minor-latin"> 个阶段。 自动化测试的框架 软件自动化测试的框架和工具的发展大致将经历以下4个阶段。

浅谈持续集成构建在互联网软件测试项目中应用与分析

浅谈持续集成构建在互联网软件测试项目中应用与分析the Application of Continuous & build Integration in Internet Software Testing Project and Analyzing 阿里巴巴（中国）网络技术有限公司王亮 Alibaba（Chinia）Technology Co.,Ltd. Jonas.Wong 【摘要】：本文将介绍持续集成在互联网软件项目中的应用及案例分析，主要针对互联网行业软件项目过程中的软件测试效率和质量的研究与实践；在当前Web2.0时代，笔者抓住互联网行业的软件测试特性，在软件项目的开发过程中运用持续集成构建的思想来统一规范、流程和管理，不仅提升项目在提测之前的软件版本质量，也有利于软件项目过程的效率和质量风险控制。在浅谈持续集成及工具在项目中的应用同时，也结合笔者从事互联网软件测试的工作经验，进一步阐述与总结在软件测试过程的持续集成带来的益处与不足。 笔者会先介绍当前互联网的软件测试与传统的软件测试区别与联系，然后针对互联网软件测试的特性再结合持续集成工具思想的运用，最后将比较详细的介绍Hudson持续集成构建平台在项目中的实践与分析，从而解决了在多个项目并行开发的软件项目中应该如何应用持续集成以保持项目整理开发过程的高质量和高效率问题。 【关键词】：软件测试持续集成互联网软件项目构建自动化统一代码Web2.0 ABSTARCT: A perception on constant integration application of network software testing project and analyzing, The content is mainly about constant integration application of IT software project and focus on software project testing with quality research in network line. Presently it is the time for Web 2.0, the writer grasps network feature , adopts constant integration methods unify criterion、procedure and management. Which not only enhances software version quality, but also to the benifit for software project efficiency and quality risk control. While application of constant integration and project tools, combined with writer years experience in network testing, this content will summarize advantage and shortage occuring in the constant integration procedure. Writer will show us the difference between tradition and modern methods in software testing, and software testing feature combined with the applicating on constant integration methods. Finally it is detailed introduction for Hudson constant integration adopted in projects practicing and analyzing，It solves the problems of many items application in concurrent development software testing involved how to apply constant integration to keep item procedure high quality and efficienc. KEYWORDS：software testing Constant Integration Internet software project Build Automation Uniform Code Web2.0 一、引言 在互联网信息时代，随着Internet的快速增长及Web应用的不断发展，使其快速渗透到商业、电子商务、军事、工业、教育等领域和个人生活的各个方面，对我们的生活及工作产生了深远的影响。在当今市场需求和Internet技术进步的不断推动下，Web应用日益增加，互联网的软件规模不断扩大，复杂性增加，操作易用性降低，面对互联网的用户也越来越多，因此软件的质量越来越成为人们共同关注的问题，作为保证软件质量和可靠性的重要手段，软件测试已成为互联网软件项目开发过程的重要环节。 在整个软件生命周期中每个环节都存在软件测试的活动，软件测试伴随着软件开发，以检验每一个阶段性的成果是否符合质量要求和达到预先定义的目标，尽可能早的发现问题并

Selenium自动化测试用例设计注意事项

Selenium自动化测试用例设计注意事项 UI元素映射 元素验证 等待加载 日志记录 结果收集 Selenium自动化测试用例设计注意事项（一） 自动化测试设计简介 我们在本章提供的信息，对自动化测试领域的新人和经验丰富的老手都是有用的。本篇中描述最常见的自动化测试类型，还描述了可以增强您的自动化测试套件可维护性和扩展性的“设计模式”。还没有使用这些技术的、有经验的自动化测试工程师会对这些技术更加感兴趣。 测试类型 您应该测试应用程序中的哪些部分这取决于您的项目的各种影响因素：用户的期望，时间期限，项目经理设置的优先事项等等。但是，一旦项目边界定义完成，作为测试工程师，你必须做出要测试什么的决定。 为了对Web应用的测试类型进行分类，我们在这里创建了一些术语。这些术语并不意味着标准，但是这些概念对web应用测试来说非常典型。 ● 测试静态内容 静态内容测试是最简单的测试，用于验证静态的、不变化的UI元素的存在性。例如： → 每个页面都有其预期的页面标题这可以用来验证链接指向一个预期的页面。 → 应用程序的主页包含一个应该在页面顶部的图片吗 → 网站的每一个页面是否都包含一个页脚区域来显示公司的联系方式，隐私政策，以及商标信息→ 每一页的标题文本都使用的

标签吗每个页面有正确的头部文本内吗 您可能需要或也可能不需要对页面内容进行自动化测试。如果您的网页内容是不易受到影响手工对内容进行测试就足够了。如果，例如您的应用文件的位置被移动，内容测试就非常有价值。 ● 测试链接 Web站点的一个常见错误为的失效的链接或链接指向无效页。链接测试涉及点各个链接和验证预期的页面是否存在。如果静态链接不经常更改，手动测试就足够。但是，如果你的网页设计师经常改变链接，或者文件不时被重定向，链接测试应该实现自动化。 ●功能测试 在您的应用程序中，需要测试应用的特定功能，需要一些类型的用户输入，并返回某种类型的结果。通常一个功能测试将涉及多个页面，一个基于表单的输入页面，其中包含若干输入字段、提交“和”取消“操作，以及一个或多个响应页面。用户输入可以通过文本输入域，复选框，下拉列表，或任何其他的浏览器所支持的输入。 功能测试通常是需要自动化测试的最复杂的测试类型，但也通常是最重要的。典型的测试是登录，注册网站账户，用户帐户操作，帐户设置变化，复杂的数据检索操作等等。功能测试通常对应着您的应用程序的描述应用特性或设计的使用场景。 ● 测试动态元素 通常一个网页元素都有一个唯一的标识符，用于唯一地定位该网页中的元素。通常情况下，唯一标识符用HTML标记的’id’属性或’name’属性来实现。这些标识符可以是一个静态的，即不变的、字符串

Selenium自动化测试框架设计指南

TAS Design Guide Author: peng gong Table of Contents 1 TAS模型介绍 (2) 1.1 Jenkins (2) 1.2 Python (3) 1.3 Selenium (3) 1.4 脚本代码管理：svn (3) 1.5 TAS运行环境：Linux+window (3) 2 TAS Frameworks (3) 2.1 测试管理：Jenkins (4) 2.2 脚本语言：Python (4) 2.2.1 Python2.7 (4) 2.2.2 Nose (4) 2.2.3 proboscis (5) 2.3 Web驱动：selenium (5) 3 TAS部署和要求 (5) 3.1 TAS环境要求 (5) 3.2 Jenkins和selenium安装 (5) 4 TAS运行和测试 (6) 4.1 测试运行 (6) 4.2 开发调试 (6) 4.3 开发调试工具 (6) 5 Code Frameworks (7) 5.1 Code结构 (7) 5.2 team模块举例 (7) 5.3 编码规范: (7) 5.4 A Simplest Example Script (8)

1.2 Python Python最大优点就是比其他语言更简单易学。同时Python自带的和大量开源的测试框架使得TAS系统架构更简单和便捷。TAS Frameworks使用了python自带的unittest拓展的开源nose和proboscis模块。 1.3 Selenium Selenium selenium是跨平台的web测试工具包。TAS选择selenium的原因在于： Selenium具有跨平台，跨浏览器的特点。 Selenium支持多种编程语言和测试框架。 Selenium工具包 TAS中使用了selenium RC驱动Web，开发工程师在开发script过程中可以使用selenium IDE和firebug等工具。 selenium运行 TAS中selenium有两种工作方式：服务器端和QA客户端。selenium运行在服务器端Jenkins和Selenium 交互，后者启动浏览器完成测试，返回结果给Jenkins。selenium运行在QA客户端的好处在于可以并行运行多个TAS测试任务。 1.4 脚本代码管理：svn TAS系统的脚本代码使用svn进行管理。测试中，Jenkins上配置svn的路径，Jenkins job开始构建时从svn中checkout最新版本进行测试。 1.5 TAS运行环境：Linux+window TAS系统的Jenkins安装在Server端的Linux/Ubuntu中，同时selenium也可以部署在Server上。测试工程师的PC上部署的selenium一般用于debug调试使用。 2 TAS Frameworks TAS框架主要由4部分组成，测试集成管理的Jenkins,Python脚本以及python 包,Selenium驱动模块和版本管理svn。详细模块拓扑图如下：

持续集成(第二版)

持续集成（第二版）* Martin Fowler(英)雷镇(中) 持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他 们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成 会经过自动构建（包括自动测试）的检验，以尽快发现集成错误。许 多团队发现这种方法可以显著减少集成引起的问题，并可以加快团 队合作软件开发的速度。这篇文章简要介绍了持续集成的技巧和它 最新的应用。 我还可以生动记起第一次看到大型软件工程的情景。我当时在一家大型英国电子公司的QA部门实习。我的经理带我熟悉公司环境，我们进到一间巨大的，充满了压抑感和格子间的的仓库。我被告知这个项目已经开发了好几年，现在正在集成阶段，并已经集成了好几个月。我的向导还告诉我没人知道集成要多久才能结束。从此我学到了软件开发的一个惯例：集成是一个很耗时并难以预测的过程。但是事实并非总是如此，我的ThoughWorks同事所做的项目，以及很多其它遍布世界各地的软件项目，都不会把集成当回事。任何一个开发者本地的代码和项目共享基准代码的差别仅仅只有几小时的工作而已，而且这只要几分钟的时间就可以被集成回去。任何集成错误都可以很快被发现，并被快速修复。这鲜明的差别并非源于昂贵和复杂的工具。其中的精华蕴含于一个简单的实践：使用统一的代码仓库并频繁集成（通常每天一次）。 当我向别人介绍持续集成方法时，人们通常会有两种反应：“这（在我们这儿）不管用”和“做了也不可能有什么不同”。但如果他们真的试过了，就会发现持续集成其实比听起来要简单，并且能给开发过程带来巨大的改变。因此第三种常见的反应是：“我们就是这么做的，做开发怎可能不用它呢？” *本文选自https://www.wendangku.net/doc/3717430053.html,/(英),https://www.wendangku.net/doc/3717430053.html,(中).修改日期:2010-03-17.