软件自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
前提条件
实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：
1）软件需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护 本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失 败的。
项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
2）项目周期足够长
自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
3）自动化测试脚本可重复使用
如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。
另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。
适用场合
通常适合于软件测试自动化的场合：
（1）回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；
（2）此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；
（3）采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；
（4）自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖；
随着测试流程的不断规范以及软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本期所要讨论的话题。
目前，软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化（如单元测试、功能测试以 及性能测试方面）。在这两个领域，与手工测试相比，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立 和开发，从而提高测试覆盖率；其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试生命周期内可以得到复用，这个特点在功能测试和回归测 试中尤其具有意义；此外，测试流程自动化管理可以使机构的测试活动开展更加过程化，这很符合CMMI过程改进的思想。根据OppenheimerFunds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500%。
方案选型六大原则
然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢？也不尽然，任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴 切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台；或同一应用的不同版本之 间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。
以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则，这些原则是从笔者实际工作中凝练而成的，它包括以下六个方面的建议：
●选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本；
●测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求；
●在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑；
●在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性；
●尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持；
●应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。
过程
自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分 析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测 试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。
1）自动化测试需求分析。
当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。
2）自动化测试框架的搭建。
所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。
而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：
（a）公用的对象。
不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。
（b）公用的环境。
各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。
（c）公用的方法。
当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。
（d）测试数据。
也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。
在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。
探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
对探索性测试最直白的定义是：同时设计测试和执行测试。探索性测试有时候会与即兴测试（ad hoc testing）混淆。即兴测试通常是指临时准备的、即兴的Bug搜索测试过程。从定义可以看出，谁都可以做即兴测试。由Cem Kaner提出的探索性测试，相比即兴测试是一种精致的、有思想的过程。
在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。
探索性测试
探索性测试强调测试设计和测试执行的同时性，这是相对于传统软件测试过程中严格的“先设计，后执行”来说的。测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多的关于测试的主意。
探索性测试的基本过程
探索性测试识别软件系统的目的；
识别软件系统提供的功能；
识别软件系统潜在的不稳定的区域；
在探索软件系统的过程中记录关于软件的信息和问题；
探索式软件测试一共分为*式探索式测试、基于场景的探索式测试、基于策略的探索式测试和基于反馈的探索式测试。下面将详细介绍4种类型的应用场景。
一：*式探索式测试
*式探索式测试指的是对一个应用程序的所有功能，以任意次序、使用任何如数进行随机探测，而不考虑哪些功能是否必须包括在内。*式测试没有 任何规则和模式、只是不停的去做。很不幸，很多人认为所有的探索式测试都是*式的，从长远的观点来看，这种看法低估了探索式测试技术的能力，我们在随后 将看到这类测试的一些变种。
一个*测试用例可能会被选中成为一个快速的冒烟测试，用它来检查是否会找到重大的崩溃或者严重的软件缺陷，或是在采用先进的技术之前通过它来 熟悉一个应用程序。显然，*式探索式测试无需也不应该进行大量的准备规则。事实上，它更像是“探索”而不是“测试”，所以我们应当相应的调整对它的期望 值。
*式测试不需要多少经验或者信息。但是，同以下提到的探索式技术相结合后，它将成为一个非常强大的测试工具。
二：基于场景的探索式测试
基于场景的探索式测试和传统的基于场景的测试有类似之处。两者都涉及到一个开商店，就是用户故事或者是文档化得端到端场景的开始之处，那也是我 们所期望的最终用户开始执行应用程序的地方。这些场景可以来自用户研究、应用程序、以前版本的数据等，并作为脚本用于测试软件。探索式测试对传统场景测试 的补充吧脚本的应用范围扩大到了更改、调查和改变用户执行路径的范畴。
使用场景作为指导的探索式测试人员经常会修改他感兴趣的输入或者是追寻一些并没有包括在脚本中的潜在副作用。不过，由于最终的不表是完成给出的场景，这些测试上的弯路、最终总是会回到脚本文件记载的用户主要执行路径。
三：基于策略的探索式测试
将*式测试探索式与具有测试老手的经验、技能和感知融合在一起，就成为基于策略的探索式测试。它属于*式的探索，只是他是在现有的错误搜索 技术下引导完成的。基于策略的探索式测试应用所有的已知技术（如边界值分析或组合测试）和未知的本能（如异常处理往往容易出现软件缺陷），来指导测试人员 进行测试。
这些已知的策略是基于策略的探索式测试成功的关键，存储的测试知识越丰富，测试就会更有效率。这些策略缘于积累下来的知识，它们指导软件缺陷隐藏在哪里，如何综合人工输入数据，那些代码路径常常出现故障。
基于策略的探索式测试结合了测试老手的经验和探索型测试人员的随机性。
四：基于反馈的探索式测试
基于反馈的探索式测试缘于*式测试，但是随着测试历史的形成，测试人员们就会利用反馈来指导今后的探索。“覆盖”就是典型的例子。一名测试人 员通过咨询那些覆盖指标（代码覆盖、用户界面覆盖、特性覆盖、输入覆盖或者其中的某一些组合）来选中新的测试用例，以使这些覆盖指标得以提高。覆盖指标只 是收录反馈信息的标志之一。我们也会看其他标志，如代码改动数量和软件缺陷密集程度等。
基于反馈的探索式测试时一种“上一次测试”：在上一次我根据应用程序的最后状态选了每某一个输入之后、下一次我就会选中另外一个输入。或者是，在上一次遇到这个界面时我用A属性，这一次我就会用B属性。
基于反馈的探索式测试工具是非常有价值的，它可以是测试人员保存、搜索测试历史并据此采取实时行动。不幸的是这样的工具很少。
自动化测试（AT）与探索性测试（ET）
自动化测试在目前得到了越来越普遍的应用，自动化测试的优势也越来越明显。对于需求比较固定的功能，使用自动化测试工具通过编写自动化测试代 码。可以在以后得到多次的使用。这给回归测试带来了极大的方便性。也为持续集成（CI）的提供了很好的基础。看来自动化测试是软件测试领域中一项重大的革 命。
然而，自动化测试毕竟考虑时间有限，并且受到了一定的测试思想的制约，不可能在一次的测试设计中就能够就能够设计得很全面。另外自动测试对于测 试正常流程往往考虑的比较周全，而对于异常流程往往考虑得不是十分的充分。而对于一个有经验的测试工程师来说，bug往往在处理异常流程的时候被经常发 现，另外好些缺陷往往在一些怪异的，不确定的操作后出现。所以有了自动化测试脚本作为支撑，探索性测试（ET）的作用不可忽略。保证一个产品好的质量，既 要依赖自动化测试工具，另外人工为主的探索性测试也不可以遗漏，这样软件的质量才可真正得到保障。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/