以下内容分别来自：
http://www.cnblogs.com/itogo/p/5635629.html
http://blog.csdn.net/u010504064/article/details/71173041

Queue是python标准库中的线程安全的队列（FIFO）实现,提供了一个适用于多线程编程的先进先出的数据结构，即队列，用来在生产者和消费者线程之间的信息传递

基本FIFO队列

class Queue.Queue(maxsize=0)

FIFO即First in First Out,先进先出。Queue提供了一个基本的FIFO容器，使用方法很简单,maxsize是个整数，指明了队列中能存放的数据个数的上限。一旦达到上限，插入会导致阻塞，直到队列中的数据被消费掉。如果maxsize小于或者等于0，队列大小没有限制。

举个栗子：

1
2
3
4
5
6
7
8
9

import Queue

q = Queue.Queue()

for i in range(5):
    q.put(i)

while not q.empty():
    print q.get()

输出：

1
2
3
4
5

0
1
2
3
4

LIFO队列

以下内容插件的运用是关键。

这是我在从事网站自动化测试的工作当中构建出的一个“生态系统”。“生态系统”这个概念是我从公司的前辈身上学到的，他一直以来都认为自动化测试人员不应仅仅局限于编写测试代码，还应该让整个自动化测试的过程（测试代码的持续集成、分发、执行等）都自动化，形成一个“系统”，这个系统的自动化程度越高，自动化测试人员就越省力。

一、概念

这里我画了一张示意图：

之所以称之为“生态系统”，是因为建成之后需要的人为干涉很少，其余的时间都是系统内部循环运作。作为自动化测试人员的你只需要提交代码，之后便可以在AutomationDashboard上看到运行的结果了，其余的事情都由系统内部消化。当然，结果的分析还是需要人来完成，机器还没有聪明到可以灵活分析出各种各样让case fail掉的原因。

我们可以把整个系统看作一个黑盒子，那么上面的图可以变成：

实际上这里画的人不仅限于自动化测试人员，也可以是：

（1）产品的管理者，比如产品经理需要从自动化回归测试知道这次release有无推迟风险；

（2）团队的管理者，比如开发经理、QA经理需要从自动化的daily/weekly regression知道最近的代码质量如何；

（3）开发人员，他们也许会想通过quick regression（提交的产品代码被部署到测试环境之后运行的测试）知道自己刚提交的代码有没有破坏系统的基本功能；

（4）其他帮忙做自动化测试的开发人员、刚刚开始学习编写自动化测试代码的手动测试人员，他们不必关心生态系统的内部实现。

二、实现

说完概念，接下来该说说具体实现了。我这里讲的是我认为最适合我所测试的产品的实现，工具不止一种，方式不止一种。Jenkins可以用TeamCity或其它CI替换，git也可以是svn或tfs，AutomationDahsboard可以用.NET、SpringMVC、ROR等等实现，运行测试的slave可以是Windows/Linux/Mac（土豪！），总之选择一种最适合你所测试的产品的实现。还有一点就是自动化测试代码是用关键字驱动思想实现的，这是另外一个话题了，有时间另外写篇文。

好，进入正题。依次说说系统的每个重要组成部分吧：

1、SCM（Source Code Management）。我选的是git，可以是git服务器（公司自己搭建了一个git server），也可以是一个bare repo（http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/） 。

2、CI（continuous integration）。我选的是部署方便、插件丰富的Jenkins。

它的职责是：

1. 背景

先理一下自动化测试的概念，从广义上来说，一切通过工具(程序)的方式来代替或者辅助手工测试的行为都可以成为自动化。从狭义上来说，通过编写脚本的方式，模拟手工测试的过程，从而替代人工对系统的功能进行验证。

有赞是一家互联网行业的创业公司，测试起步较晚，发布非常频繁，就算每次只回归核心功能，对人数极少的几个测试人员来说工作量巨大，且基本是重复劳动，极其枯燥，持续时间长了也容易出错。

所以初期我们测试自动化切入的思路非常简单：从实际用户的角度出发，模拟真实的操作，替代现有的手工测试用例的执行。这样一来，每次重复的工作就可以用自动化来替代，测试人员只需要关注每次发布的增量需求即可。

随着脚本数量的增加，这种自动化覆盖的方式的弊端也逐渐暴露：

虽然我们在测试框架和工具层面通过结合selenium-grid实现了脚本并发执行和失败用例重试机制以提高执行效率和降低误报率，但是这种方式只能缓解问题，并不能从根本解决覆盖不全的问题。

正好赶上公司的SOA服务化进程，测试这边也开始配合的做自动化方面的转变，从原来的黑盒系统级自动化测试向分层自动化测试转变。

2. 分层自动化测试

在谈分层测试之前，先回顾几个概念：

接下来我们谈谈有赞是如何随着系统拆分SOA服务化推进分层自动化测试的。先来看看经典的测试金字塔： 其中Unit代表单元测试，Service代表服务集成测试，UI代表页面级的系统测试。分层的自动化测试倡导产品的不同层次都需要自动化测试，这个金字塔也正表示不同层次需要投入的精力和工作量。下面我会逐层介绍有赞的分层自动化实践。

2.1 Unit-单元测试

在系统拆分之前，有赞只有一个庞大的巨无霸系统，单元测试极度缺失。在系统逐渐SOA服务化的过程中，我们逐渐提出了对单元测试覆盖率的要求。

我们的单元测试会分别做DAO层和服务层的测试。DAO层的单元测试主要保障SQL脚本的正确性，在做服务层的单元测试时就可以以DAO层是正确的前提进行用例编写了。

为了做细粒度的测试，需要解决单元测试的外部依赖。系统和模块之间的依赖可以通过Mock框架(Mockito/EasyMock)解耦，同时可以结合h2database解决对数据库的依赖，使得测试用例尽可能做到可以随时随地运行。

这一层发现并解决问题付出的成本相对来说最低，自动化用例的维护成本也不高，总的来说自动化测试的投入产出比最高。

单元测试的责任主体一般来说是开发人员，写单元测试也是开发人员对自己的代码进行检查的一个过程。

2.2 Service-服务集成测试

我们在服务层的测试首要考虑的是各系统(子系统)的集成测试。因为在经过单元测试这一层的保障之后，在服务层我们更关注的是某个系统的输入输出功能是否正确，以及若干个系统间的交互是否和业务场景的要求一致。

先来看看我们系统拆分之后的SOA系统应用架构图：

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。简单地来说，就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程，开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

以下内容转自：http://www.ituring.com.cn/article/265237
当我们谈到 DevOps 时，可能讨论的是：流程和管理，运维和自动化，架构和服务，以及文化和组织等等概念。那么，到底什么是”DevOps”呢？

什么是DevOps

随着软件发布迭代的频率越来越高，传统的「瀑布型」（开发—测试—发布）模式已经不能满足快速交付的需求。2009 年左右 DevOps 应运而生，简单地来说，就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程，开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

关于 DevOps 是什么，DevOps 的合著者 John Willis 写了一个非常好的帖子，在这里.

Devops 的好处与价值

在2016 DevOps 新趋势调查报告显示，74% 的公司在尝试接受 DevOps，那么 Devops 有哪些好处与价值呢？

以上可以看出，DevOps 的好处更多基于在于持续部署与交付，这是对于业务与产品而言。而 DevOps 始于接受 DevOps 文化与技术方法论，它是部门间沟通协作的一组流程和方法，有助于改善公司组织文化、提高员工的参与感。

Devops与持续集成

DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。

纵观各个 DevOps 实践公司的技术资料，最全面最经典的是 flickr 的10+ deploys per day最佳实践提到的 DevOps Tools 的技术关键点:

1

1.Automated infrastructure（自动化，系统之间的集成） 2.shared version control（SVN共享源码） 3.one step build and deploy（持续构建和部署） 4.feature flags（主干开发） 5.Shared metrics 6.IRC and IM robots（信息整合）

以上的技术要点由持续集成/部署一线贯穿，主干开发是进行持续集成的前提，自动化以及代码周边集中管理是实施持续集成的必要条件。毫无疑问，DevOps 是持续集成思想的延伸，持续集成/部署是 DevOps 的技术核心，在没有自动化测试、持续集成/部署之下，DevOps就是空中楼阁。

我们做了一款 Hosted 持续集成产品—— flow.ci ，它融入了 workflow 机制的持续集成（CI）服务，也可以理解为自动化流程平台，除了集成代码、编译、测试之外，还可以集成常用的工具、灵活自定义流程，帮助你们塑造一个更优秀智能的 DevOps 环境。

DevOps 的技术栈与工具链

一、appium是什么？

Appium 是一个自动化测试开源、跨平台工具。它允许测试人员在不同的平台（iOS，Android）使用同一套API来写自动化测试脚本，这样大大增加了 iOS 和 Android 测试套件间代码的复用性。支持 iOS 平台和 Android 平台上的原生应用，web 应用和混合应用。
所谓的“移动原生应用”是指那些用 iOS 或者 Android SDK 写的应用。
所谓的“移动 web 应用”是指使用移动浏览器访问的应用（Appium 支持 iOS 上的 Safari 和 Android 上的 Chrome）。
所谓的“混合应用”是指原生代码封装网页视图——原生代码和 web 内容交互。比如，像 Phonegap，可以帮助开发者使用网页技术开发应用，然后用原生代码封装，这些就是混合应用。

二、Appium的基本原理

基础依赖

Appium 真正的工作引擎是第三方自动化框架。使用以下的第三方框架：
- iOS: 苹果的 UIAutomation
- Android 4.2+: Google’s UiAutomator

• Android 2.3+: Google’s Instrumentation. (Instrumentation由单独的项目Selendroid提供支持 )
• Selenium WebDriver等第三方包，点此参考java依赖包

C/S 架构

Appium使用客户端-服务端的架构，它 的核心是一个 web 服务器，它提供了一套 REST 的接口， 指定了客户端到服务端的协议。 (JSON Wire Protocol)。
我们可以使用任何语言来编写客户端，向服务端发送恰当的 HTTP 请求。它收到客户端的连接，监听到命令，接着在移动设备上执行这些命令，然后将执行结果放在 HTTP响应中返还给客户端。事实上，这种客户端/服务端的架构给予了许多的可能性：比如我们可以使用任何实现了该客户端的语言来写我们的测试代码。比如我们可以把服务端放在不同 的机器上。比如我们可以只写测试代码，然后使用像 Sauce Labs 这样的云服务来解释命令。

Session

自动化始终围绕一个session进行，客户端初始化一个seesion（会话）来与服务端交互，不同的语言有不同的实现方式，但是他们最终都是发送为一个POST请求给服务端，请求中包含一个JSON对象，被称作“desired capabilities”。此时，服务端就会开启一个自动化的 session，然后返回一个 session ID，session ID将会被用户发送后续的命令。

Desired Capabilities

Desired capabilities 是一些键值对的集合 (比如，一个 map 或者 hash），客户端将这些键值对发给服务端，告诉服务端我们想要怎么测试。比如，我们可以把platformName capability 设置为 iOS，告诉 Appium 服务端，我们想要一个iOS 的 session，而不是一个 Android 的。我们也可以设置 safariAllowPopups capability 为 true，确保在 Safari 自动化 session 中，我们可以使用 javascript 来打开新窗口。参见 capabilities 文档，查看完整的 capabilities 列表。

Appium Server

Appium server 是用 Node.js 写的。我们可以用源码编译或者从 NPM 直接安装。

Appium客户端

Appium 客户端端有很多语言库 Java, Ruby, Python, PHP, JavaScript 和 C/#，这些库都实现了 Appium 对 WebDriver 协议的扩展。当使用 Appium 的时候，你只需使用这些库代替常规的 WebDriver 库就可以了。 你可以从这里看到所有的库的列表。

本人使用Linux的shell脚本对公司测试及生产代码的自动构建发布进行了开发工作，并实际运用到工作当中，显著提高了代码发布的效率，减少了人工发版出错的概率。但是，公司迭代速度非常快，开发进度十分聊得，敏捷的模式下，研发提交代码，再到发布到测试环境的频率很高，由于我负责维护和使用这套东西，在解决bug的过程中，个人的生产力大部分被发版占据。痛定思痛，本人打算将shell脚本升级到更加自动化的程度，解放我的生产力。这便引入了jenkins，强大的自动构建部署服务。
安装过程此处略过。
使用了jenkins的open blue ocean，学习了很久如何在pipline中使用groovy的脚本，并研读了官网教程，没有办法的是，所预想的脚本始终run不成功，基本都是语法错误,而且对于jenkinsFiles的语法，除了看到别人写的知道什么意思外，基本达成不了自己预期的。所以，退而其次，我把所有的功能都写到了shell脚本里，只借助jenkins去执行就好了。
参考jenkins的构建流程，shell脚本分为：

使用jenkins新建了如下job:

其中，pull code的job每一个小时拉取代码一次，自动引发自动编译job（build auto），但不发布。也就是代码是自动拉取并编译的。

pull code 的pipline script:

1
2
3
4
5
6
7
8

node {
   def mvnHome
   stage('Preparation') { // for display purposes
      // Get some code from a Git repository
      sh "~/ci/pull.sh"

   }
}

pull.sh内容：

1
2
3
4
5
6
7
8
9

#!/bin/bash
githome="/home/admin/gitCode/"
#设置环境变量
source /etc/profile
cd ${githome}
#git reset --hard HEAD^
echo "git分支名称："+`git status |awk '{print $4}' |head -1`
echo "拉取当前分支代码"
git pull origin `git status |awk '{print $4}'|head -1`

build auto 的pipline script: