软件测试人员须要了解关于自动化的什么（译）

即便你正在使用人工测试，了解关于自动化测试进展如何仍然是重要的。无论你的角色是什么，你的每日工做仍然可能经过使用这篇文章中的至少一些方法被增强。这里，学习一些普通术语的含义和一些他们可能如何别应用在软件开发工厂。

近日来我推特了关于软件测试者须要了解自动化世界正在发生了什么。它获得了一个漂亮的温暖的回复，因此我想我应该要透露个人想法。

这些天来无论你在测试里的角色是什么，你的每日工做将可能经过如下方法的至少其中一些被强化。从最低程度我建议了解这些术语的含义和他们可能被应用在软件开发工厂的一个例子。

持续的集成服务

过去十年来在软件开发领域到来的自动化一个最大的变化是任务自动化。在过去，像构建一个应用的特殊版本，建立文档，或者更新bug报告的状态是人为的。一些团队甚至贡献为了 启动一个版本而负责的“建立人”责任。像这些人为的任务（或者是牢牢地绑定给我的或机器）是消耗时间的，而且建立来为了不瓶颈，好比建立人占据私人的一天并阻碍新版本被完成。

幸运的是，持续集成（CI）工具经过容许任务被标准化和自动化来挽救。持续集成服务重要地安排和执行任务，一个规则的台式电脑能作的任务而且让这些任务在目标机器上执行而不是它本身。回到建立版本的例子，取代让鲍勃为手工在他的机器上建立版本负责，一个持续集成服务能被集成去选择一个目标机器而且在那台机器上执行版本。不只使鲍勃不须要身体上在那台版本机器出现，并且能在任意时刻发生版本建立，不论是已安排的或者是为了响应另外一个动做。

举个例子，测试者爱丽丝可能想要一个基于最新改变的应用程序版本去看一个程序错误是否被修复，并且她能本身发起版本建立。这个不只使资源从作表明性任务中自由运做起来，并且给团队在我的之外和团队流程上给予了更多的控制。你也能够把持续集成任务绑定一块儿给更深的线程一些任务。学习一个持续集成如何工做是对没有放不少编程的重点在自动化上很好的引子。

使用持续集成的一个途径是跑端到端的测试套装。这些测试常常须要跑数分钟甚至数小时。我使用过持续集成去自旋向上和自旋向下测试机器而且发起在那些测试机器上的测试。相对于在你本身机器上跑这些测试这是一个很大的帮助，由于它容许一个测试开发者当测试处处跑的时候去作其余的工做。持续集成的服务器控制着全部这些任务的方方面面。

一些持续集成服务的普通例子是开源工具Jenkins，基于云的Travis CI，和专属工具Bamboo，可是这些也是其余的一些。甚至更低技术是使用一个像克隆或者windows任务分配者的工具为了在单一机器上去使任务自动化。

CI对于开发软件爱好以外的编程是独立的，而且它是一个测试能确实增长价值的一个地方。

现代源码控制

我首先须要指出我爱源码。当编写代码（或者博客！）时，它是一个颇有帮助而不只是工具。对于一个编码的测试员，它是一个无需脑力者。甚至即便一个测试不编码，当测试软件时以现代方法使用源码控制多是一个大的利益。

在现代个人意思是什么？个人意思是使用源码控制1）集成其余工具，好比CI服务器或者问题追踪器，而且2）容许使用好的团队流程习惯，好比基于干线的开发。好的源码控制容许我的去分析变化和更深地挖掘软件工程正在发生什么。

一个接近源码历史和一些基本培训的测试能问出像“在应用里的哪一个文件有最多的开发在它们上面工做？”“哪一个文件有最大的变化？”“哪一个变化的设置包含引发问题的代码？”等待。这个信息有助于找到步调且暗示一些事件的引起。

用CI集成源代码甚至能更加有力。在问题跟踪者的事件能使它们的状态在由开发引发的变化中更新。测试者能要求必要的需求在输入的代码被自动查找出来，好比经过自动测试或者代码模式需求。建构和部署能被改代码发起。当源码控制被很好使用，在这种状况下有不少种可能，这是一个在持续传递后隐含的概念。

举个例子，我在一个使用基于云集成服务的开源项目上工做为了检查每个由提交者提交的交付。在这个项目里，持续集成运行全部的自动化测试而且检查全部为形式和格式增长的代码。假如一个提交形成错误的测试，或者没有知足设置的风格向导，提交失败了而且暗示了提交者和项目维持者去修改提交。这有助于提供项目历史里以统一的风格每个提交而且暗示了提交者在增长或者更新模块中可能的微小错误。

这些目前在源码控制的热点是Git，自由和开放代码的，在它周边有着健壮的生态系统。这些也是一些其余的方面，好比Subversion，Mercurial和微软团队基金会。

遥测和监控

这是一个我并不熟悉的主题，可是它肯定是测试者们感兴趣的。监控是一种方法，今后挂钩被放在一个应用程序里去发回关于软件是如何被使用的信息给软件创造者。这能包含正被使用的后端/服务器应用程序接口函数，而且在哪一个指令，由被使用的由用户界面组成的部分和在什么频率上，等等。

这个目标不是为了发送特殊的用户信息返回给开发团队，更普通的信息是关于一个应用程序正在被用着的和如何被用的部分。这提供了终端用户在作什么的视角，他们实际上如何使用应用程序，而且特定属性如何被获得。安兰培是个微软测试，曾经简短讨论这酷毙事情的他曾作过的经过遥测和监视的一部分。

相似于最小化资源控制历史，监视能帮助你找出答案，从简单的问题中（”上周多少人记录？”）到更特殊的和可视化的问题（“当特性X被发布时用户们如何改变他们的习惯？”）。这些是帮助测试们执行更好的测试策略的种类问题，而且，总的说来，帮助团队对用户作更好的选择。

更多的信息，请检查AB测试播客页面和布伦特詹森。一个主流产品如何使用遥测技术，看一看Mozillla如何经过火狐使用监测技术。

也使用Selenium

最后可是固然不是最少，Selenium WebDriver是一个任一工做在网页应用的测试须要至关熟悉的工具。在这一点上，WebDriver是一个用于自动驱动浏览器行为的标准工具，相似于一我的类用户如何在浏览器中用网站app交互。它有一些语言绑定，和一些主流浏览器工做，而且是一款很是好的能被开发第一组件的可扩展性API的例子。简言之，它是一个优秀的工做。

当被灵活地使用时，WebDriver容许测试和开发去使用户体验性测试获得自动化，这个能够被放在一个持续性的可传递流程。我写了一个简单的基于网页驱动的测试，能够找到像导航到登陆页面的连接的事务，而不是寻找用户名和密码场合（因为坏的部署），或者寻找一个不打开的对话当一个控制被点击成想象的（一个明显的但严重的问题）。这些是很快被找到的事情可是不能被单元测试覆盖。

WebDriver也能被用在写自动化的测试，能够被本地执行去双重检查那些不会以非预定的方式打断重要特性的变化。这些甚至是WebDriver用于扩展功能测试之外的用处。

对于对学习代码感兴趣的测试来讲，WebDriver能提供一个好的学习代码的介绍。自动化测试脚本能是一个容易的方法去熟悉编程而不是深刻挖掘代码语言鸿沟。它提供足够的架构去开始而且仍然使得好的测试工做被完成。

大脑有这些概念，增强测试自动化，不敢你在软件开发中的角色是什么。