下载掌阅APP，畅读海量书库
立即打开
自动化测试与其他技术工作相比有着自己的独特性，它不同于纯开发或者测试，在有工作量投入的前提下就必定有对应的产出，所以在正式学习这项技术之前，有必要对其进行一番真切的认识，让我们不仅能够学习这门技术，更能把这门技术运用到正确的项目中。
开发的直接产出、最终产出都是代码。测试的直接产出、最终产出都是测试覆盖的程序。自动化测试的直接产出是脚本，而最终产出却是效率。所以如果自动化测试没有产出效率则表示没有最终产出，此时的直接产出就没有意义了。这正是自动化测试的特殊之处。
因此，本书在一开始就针对如何更好地运用自动化测试技术展开了一番论述，把以前踩过的坑、趟过的河以及行业内的共同认知进行了整理归纳；希望能让新人在以后的项目中尽量避免这些误区，少走些弯路，这样才能让自动化技术真正地发挥它本来的作用。
近些年来作为一名软件测试人员，掌握一门过硬的自动化技术是必不可少的。无论是UI自动化、接口自动化还是性能自动化，至少需要掌握一种技术。对于此前以手工测试为主或者应届大学生而言，怎样才能学好自动化技术则是首要问题。由于本书主要介绍UI和API的自动化，所以接下来所讲的方法也是针对这些方面的。
首先，在学习自动化之前要有足够的意愿和信心，也就是说为了提升自己而主动学习，而非外力压迫去学习。这样在学习的过程中即使有困难和不顺你都可以坚持和跨越过去，否则可能一个小小的挫折就让你放弃甚至厌恶学习自动化。学习自动化技术是一件需要坚持的事情，只有不忘初心，才能方得始终！
其次，需要掌握一些编程基础，例如一门编程语言，如Python、Java、C#、Ruby等。具体需要掌握哪种语言主要取决于选择的自动化技术。例如，如果使用QTP则需要掌握VBS，使用Watir则需要掌握Ruby，而使用Selenium则上面提到的几种语言都可以。此外，可能还需要掌握数据库的基本使用方法，知道如何通过自己熟悉的语言去操作各种不同的数据库。还需要掌握一些基本的操作系统知识、基本算法等。
再次，需要了解所测试的对象使用的一些技术，例如，要对Web项目进行自动化测试，那么需要掌握HTTP、HTML、JavaScript、CSS等Web开发的相关知识，理解它的运行机制和原理，这样才能在进行自动化学习的过程中平稳而顺利地前进；否则，可能遇到很多莫名其妙、不得其解的现象或问题。
最后，如果满足了上述基本要求，那么恭喜你已经可以开始自己的自动化测试之旅了。可以从最开始的环境搭建，到demo样例，再到常用函数的学习、简单场景的实现、多个场景的实现、批量运行、框架设计等，一步步学习。这期间每一次的运行成功都会提升你的自信心，而每一次的执行失败则考验着你能否最终进阶到自动化测试工程师。在这里作者希望读者在学习时不要害怕、厌恶过程中出现的错误和问题，要积极主动地找到问题的原因并最终解决问题。每当解决一个问题之后，离成功就更进一步了。另外，如果你身边有技术大牛，可以向他请教学习，但切记不要一遇到问题就去寻找帮助，需要给自己一个思考的机会，也需要适度地消费技术大牛们的耐心和时间。
尽管软件测试人员对自动化技术趋之若鹜，但自动化技术本身不是万能的，并不是所有的项目都适合自动化测试；所以在进行自动化项目选项的时候就需要进行一下条件筛选，看下是否满足进行自动化的条件，这样不仅能让我们的自动化技术有施展的空间，也能让自动化测试技术带来实实在在的效益。下面就列出一些符合自动化测试技术应用的项目特点。
即项目本身是一个长期规划的，而不是短期的或者是新项目，因为开发测试脚本也是需要时间的，这个投入就需要在后期反复回归测试时补回来，如果项目周期不是足够长的话，可能脚本没有开发完项目就结束了；需求稳定指的是项目在长期的进行过程中不会大量或者频繁地修改需求，因为一旦需求改变了，意味着之前的测试脚本都将不可用，也就无法完成测试脚本的积累，最终也可能导致项目结束但脚本却没写完，或者真正在执行测试的脚本少之又少。
编写自动化脚本目的是提高测试效率，只有测试脚本被反复使用时，测试效率才能最大化地提升；试想如果测试脚本只被使用几次，即使效率提高了也是很有限的，但是开发脚本的成本却是很高的，所以被测试项目对功能模块回归的需求很大程度上决定了实施自动化测试的意义。
这里主要指的是某些特殊场景可能在人为的情况下很难实现，或不易完成的场景，例如，快频次的反复操作、大量的文本输入、精确的单击、大量的数字计算操作等。这些操作场景有些人为做不到，有些人为易出错，但是使用自动化技术则可以很容易实现这样的需求。如果项目中有大量这样的场景，那么自动化测试技术则是不二选择。
上面只是从一个宏观的角度来审视一个项目是否适合自动化。接下来就从细节上来阐述下如何才能更好地实施自动化，在具体的自动化执行过程中需要关注哪些点，从而避免误入自动化测试的陷阱里。这里总结了10条参考建议。
成本效益即通常所说的RIO（Return On Investment，投资回报率），在自动化测试中这个概率必须要牢记，因为自动化测试的初衷是为了提高效率和节约成本，如果最终都没能达成则表示自动化是失败的。因此在考虑是否要进行自动化测试的时候，需要优先核算RIO而不能误入为了自动化而自动化的陷阱。
自动化测试的投资主要为测试脚本开发、维护的人力成本，而自动化测试的回报为每次执行脚本所节约的人力成本；做一个简单的计算就是脚本开发和维护的总成本不应大于自动化测试所能节约的总成本。可以简单地理解为如下公式：
自动化测试工程师总人天数<自动化单次平均节约人天数×执行次数
从公式中可以得出如下结论。
从这里可以得出为什么项目周期需要足够长，且项目功能需要稳定；因为项目周期越长、可回归的次数越多，则自动化脚本执行的次数就越多，自动化测试得到的回报就会越高，自动化测试才能真正地发挥价值。那么问题来了，如果你的老板或上司需要你开展自动化测试，你应该怎么跟他保证呢？
提示 这里需要辩证地对待这个问题，既不能打包票也不能一味儿推脱，因为UI自动化测试的风险还是有的，并不是任何一个项目都是适合进行UI自动化，所以一旦遇到类似的情况，我们需要询问在下面的几个场景中，作为自动化测试的效果来看，最低可以接受的选项是哪个？
针对提示中提到的选项，相信大多数人的期望都是第4项，而实际的测试项目中能达到第4项的项目并不多，但是这并不意味着达不到这个效果就直接放弃掉UI自动化测试。因为有时候我们是需要付出成本来换取时间，例如，为了缩短项目的回归周期；有时候是需要付出成本来提高产品测试覆盖率，例如，银行系统的准确性。使用不同的需求来裁定自动化测试是否有效，才是正确的投资回报的体现。
正如前面所提到的广义的自动化测试包括很多：功能、性能和安全等，不同的自动化类型需要选择不同的测试工具。即便是本书中重点讲解的功能自动化也是如此，针对不同的项目类型需要进行最佳工具的选择。
功能自动化测试工具有很多，从是否收费来分可以分为：商业、开源工具；从被测对象来分可以分为：Windows、Web工具；从测试阶段来分可以分为：白盒、接口、GUI工具。因此，项目的诉求不同、类型不同、阶段不同，所选取的工具是不一样的。
如果是公司没有购买工具的预算，则开源工具是首选；如果是Windows的程序，则可能会考虑QTP、Rational、UIAutomation等；如果是Web程序，则大多会选择Selenium、Watir等；如果是接口测试，则可以选择SoapUI；正常情况下，都是可以选择到一款合适的测试工具的。
在选择工具的时候，除了上面提到的项目属性之外，还需要考虑工具的脚本开发语言、可扩展性、支持的外部接口、与其他工具的集成度等方面的因素。
在自动化测试领域有一个很出名的模型：倒三角模型，如图0-1所示。
图0-1 测试倒三角
图0-1中把自动化测试依据不同的测试阶段分为：单元测试、集成测试、验收测试；每个阶段自动化测试的维护成本是递增的，而奇怪的是我们通常的自动化覆盖程度也是递增的。即单元测试维护成本最低，它的覆盖率（阴影面积）也是最低的；虽然这是实际中经常发生的情况，但却不是所希望的情况。
正常情况应该是维护成本越低的层次，其覆盖率越高越好；理想的不同阶段测试覆盖率的关系如图0-2所示。
图0-2 测试黄金三角
这就是分层测试的原型，我们在对项目进行自动化实施之前，都应该考虑分层测试的可能性和必要性，尽可能把需要测试的内容放在底层测试阶段，只有少部分的测试在上层的测试阶段，这样不仅提高了整体测试的稳定性和测试效率，同时也降低了自动化测试的难度。
通常情况下，一个系统是否可测不仅取决于所采用的自动化测试技术，同时也取决于系统架构和开发对可测性的支持；对于标准的控件而言，需要开发人员在设计和编码阶段提供良好的自动化命名规范，例如，Web控件添加ID属性；而对于大量使用非标准化控件的系统来说，如果要让它可以支持自动化测试，可以部分地考虑开放API，部分使用GUI操作结合起来使用。
除了上述提到的被测系统本身的可测性，还有就是通过增强测试技能来提高系统的可测性。例如，测试某个系统的多线程读写同步，常规的自动化工具一般不支持这样的功能，那就要测试人员自己编写多线程读写的程序来调用被测试系统，通过控制线程的读写顺序来验证预期的结果。又如，被测场景是一个很多步骤之后才会出现的，如果按照正常操作会大大增加测试的不稳定性，这时可以利用一些HACK的方式绕过前面步骤，直接到达被测场景进行测试。
因此广义上的提高可测性是指能够使原本不容易测试、不可测试的系统变得可测所使用的一切方法和技术。
很多时候刚开始使用自动化测试技术的测试人员都会掉进一个怪圈，认为做自动化测试理所应当就应该尽量全部地自动化，哪怕某些场景即使不是特别适合自动化。例如，某些场景的结果是动态变化的，或者某些场景需要跨越多个平台操作，这些就不适合自动化去进行测试。
人有人的优势，机器有机器的优势，在进行项目测试的时候也要辩证地考虑这个实际问题，不要一味地追求完全的自动化，而要酌情考虑哪些工作更适合机器去做，哪些工作更适合人去进行。例如，重复的固定流程、反复的单击操作等就比较适合自动化，而对于变化的或者需要思考逻辑的场景就需要测试人员来进行。
对于单一的自动化用例而言，可能觉得执行的不是很慢，即使在用例中还使用了延时等待的技术；但是当自动化测试用例数量变得庞大的时候，就会发现自动化测试的执行时间开始成为瓶颈；因为总是希望尽可能早地获取到自动化测试的反馈结果，而当我们一旦完成了主功能的自动化之后，再加上对平台的兼容性的支持，那么自动化用例的数量就会成倍地增长，这时自动化用例的执行速度就会显得比较重要。
总而言之，不论对于大的系统还是小的系统，自动化用例一次回归执行时间不应大于一个昼夜的长度；通常就是下班前启动自动化测试的执行，到第二天早上上班后能收到自动化测试的测试报告邮件。对于用例数量较少的情况，通常都是很容易办到的，而对于用例数量较大的系统又该怎么办呢？
提示 提高执行脚本的效率可以从宏观和微观两个方面来考虑；宏观指的是从用例的执行策略上考虑，微观指的是从单个用例上来考虑。下面的优化项可以用来参考。
正常情况下人工执行测试时都是按照正常的业务场景来进行的，如果到达被测场景需要执行10步操作，我们就会完整地走完这10步；这种方式对于手动测试来说是没有任何问题的，因为测试人员会有能动性，他们会把前面9步走到场景全部顺带都测试一遍，然后到达第10步的场景。而我们在编写自动化脚本的时候就不能这样写代码，那样的话一个自动化用例就会变得很大，既不利于后期的维护，也不利于用例的顺利执行，因为如果执行没有一次性全部通过，整个用例就会中断后面的执行。
因此每一个自动化用例都是一个独立的场景，用例自身的失败不会干扰其他用例的正常执行；也因此导致很多场景的冗余和重叠，通常我们都是作为公共的业务场景进行提取出来，这样在代码层面上是可以理解的；但是在执行时冗余的场景还是会被不断重复执行，这样一方面会导致执行时间变长，另一方面也增加了用例执行的不稳定性；所以在设计自动化测试用例的时候，在保证覆盖了手工场景的前提下，要以最少的步骤进入到正式的被测场景。
在上面提到的几条里面都有一个基本的前提，那就是用例的持续执行，因为如果不进行用例的持续执行，就不会知道执行的总体时间有没有超时，也不会知道哪些场景比较稳定，甚至都不会知道用例在批量执行的情况下能不能顺利地执行完。
所以自动化用例的持续执行与自动化用例的开发一样重要，如果只是开发了自动化脚本而没有持续的执行，那么工作最多只完成了30%；后面更多的调试、维护工作才是自动化测试能否成功的关键所在，而一旦脱离了持续执行，那么一切将无从谈起。
持续地执行自动化测试的目的是为了尽早发现用例在运行时可能出现的问题，如果发现了问题，那么接下来要做的就是快速修复问题，毕竟有问题不修复其危害性就等同于没有持续地执行自动化测试。
持续执行自动化测试其实就是在分阶段地去发现问题，而跟它配套的就是紧跟之后的快速修复，它们的目的就是持续地一点儿一点儿发现问题并解决掉问题，从而避免一次性地突然来了很多的问题，导致整个自动化在需要执行的时候不能顺利地执行。
最后需要提到的就是当读者在埋头开发自动化脚本的时候，也要偶尔照顾下周边人的感受，也需要让测试、开发、产品等相关人员了解并知道读者的自动化测试进度及效果，因此一个简洁明了的自动化测试报告可以说是必不可少的，报告的内容不需要复杂和华丽，只需要把相关的统计数据、错误提示信息等收集起来就可以了，最好是能做到可以追溯历史。
当然，上面提到的这10条总结只是大多数项目会经常遇到的情况。除此之外，不同的项目可能还会有各自的一些特征，需要根据项目自身的特点来规划和调整。