1.1.1 什么是自动化测试
1.1.1.1 引言
“自动化测试”，一个耳熟能详的软件测试行业术语、一个绝大部分测试界人员的奋斗目标、一个听上去就很有感觉的名词、一个甚至能牵动未来测试界发展水平快慢的技术。是的，以上说的几点都没有错，它就是软件测试行业中最高端的技术之一，测试自动化技术！它以程序测试程序、以代码代替思维、以脚本的运行代替手工测试。自动化测试同时涵盖各种各样的测试种类，常见的有以下几种：功能（黑盒）自动化测试、功能（白盒）自动化测试、性能测试、压力测试、GUI测试、安全性测试，它们都可以由测试自动化技术来代替手工测试，其实还有很多，作者只是概括了大家都熟悉的软件测试种类，其他的诸如作者曾经收到过这样一个问题，这名测友问：“网络游戏的功能可以引入自动化测试吗？”虽然作者并没有游戏行业的软件开发、测试经验，但是作者确信，网络游戏一样也可以引入测试自动化技术，为什么？因为网络游戏同样是用程序写出来的，只要是一种程序，那么它一定能用程序测试程序、用代码代替思维、用脚本的运行为手工测试代劳！
可以这么说，自动化测试这个术语，每天都索绕在我们的耳边，所以，掌握测试自动化这门技术，对测试工程师来说，是至关重要的，我们并不需要精通每种测试自动化技术，但是，至少我们需要精通其中的一种，只要精通其中一种，相信你在测试这个领域一定会占有一席之地，这门技术能带给你非常大的优势！虽然测试永远脱离不了手工测试，但是，未来测试行业一定会是由自动化测试来引导。这是不争的事实，中国测试行业发展之快也是有目共睹的，如果你现在能掌握这门技术，相信未来的测试路会越走越顺畅，你的测试职业生涯会越来越精彩。
1.1.1.2 自动化测试能做到什么及其优势，你心知肚明吗
万物存在即合理，自动化测试能不断地发展至今，足以证明其在测试领域中有着举足轻重的地位，能切实地帮助项目进度的推动、提高项目的质量和协助测试人员提高工作效率。那么自动化测试究竟有何功能呢？这里归纳了最重要的几点并予以分析。
● 回归测试更方便、可靠。通常来说，这是自动化测试最主要的任务和特点，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的业务流程操作和测试用例是预先完全设计好的，预期结果也是完全在项目人员掌握之中的，将回归测试交给计算机自动运行，可以极大提高测试效率，缩短回归测试时间。这里需要强调一点，上述说的程序修改比较频繁指的是新功能的不断加入，而老功能的逻辑是不变或者很少变化的，不是指整个程序全部或大批量地改动，因为这样是违反自动化测试原理的，在下文也会有类似的讲解。
● 可运行更多、更繁琐的测试，且快速、高效。自动化测试的一个明显好处是，可以在较少的时间内运行更多的测试。我们知道，有很大一部分业务功能由于业务逻辑极其繁琐（暂时不说有多复杂），使用手工测试往往耗费大量的时间，测试1次、2次、3次可以，但是，如果测试10次以上或者更多呢？当一个测试人员测试同一个业务功能10次以上，几乎可以断定，没有一个测试人员会继续耐心地测试下去。所以，此时自动化测试就能发挥作用，自动化测试的耐心是无限大的，而且计算机的执行速度远比人工快！
● 可执行一些对于手工测试来说相当困难或根本做不到的测试。比如，对于大量用户的测试并发，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户并发点击某一功能，从而达到测试的目的。再比如，人工不可能24小时不眠不休地进行测试，但是计算机则不用休息。当然，类似的例子还有很多，无法全部列举出来。
● 更好地利用资源，使资源的使用更有价值。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动化测试，仅适合于手工测试，将可自动化测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。在引入自动化测试后，测试人员的工作很大一部分可以交给计算机，而自己则解放出来，将精力投入新功能或者测试更深的业务逻辑，争取发现更深层次的缺陷，能做到这些，自动化测试可以说功不可没。
● 具有一致性和可重复性的特点。由于测试是机器自动执行的，每次测试的结果和执行的内容与操作的一致性是可以得到保障的，从而达到测试可重复的效果。机器可以按照相同的轨迹不断地执行测试并丝毫没有差错（即使错了也可以自动解决），但是人不能！
● 自动化测试脚本完全具有复用性。由于自动化测试通常以脚本的方式来实现，这样在不同的版本之间，就有可能只需要做少量的维护甚至不做任何修改，实现在不同的测试版本中使用相同的测试脚本执行相同的测试用例。
● 使软件更有信任度。由于测试是由计算机自动代劳的，所以，不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了具有说服力的自动化测试后，软件的信任度一定会大大增加。
● 多环境下测试。我们知道，一个系统往往会被要求能支持各种不同的环境并稳定运行，但是这么多不同的环境，比如常用浏览器有IE6、IE7、IE8、FireFox等，系统有Windows 2003、Windows XP、Windows Vista、Windows 7等，甚至还有杀毒软件，如卡巴斯基、360、诺顿等，那么多的环境组合，如果每一种环境组合我们都需要花人力、物力去把功能测试一遍的话，估计研发周期至少得增加10倍！在这种情况下，自动化测试又可以完全发挥其优势与作用了，由计算机去代劳，在不同的环境组合中执行测试。
1.1.1.3 自动化测试无法做到的事及其劣势分析
当然，自动化测试不是万能的，它的能力仍然是有限的。自动化测试同样有着各种各样的缺点和无法做到的事情。不过，人类是不断在进步的，测试自动化技术随着人类进步的步伐也一定会越来越强大。下面同样归纳了最重要的一些自动化测试的劣势以及它力不能及的事情。
● 永远不可能完全取代手工测试。自动化测试不能完全替代手工测试，这已经是业界中不需要再争辩的事实了。自动化测试无法做到手工测试的覆盖率。不是每个测试用例都适合转换成自动化测试用例的。另外，复杂性极强的操作也只能通过手工测试来完成，如果将这个复杂的操作写成代码那将会是件大麻烦事。还有一个例子也能证明，就是比如我们当前需要验证页面上的布局是否正确，那试问这该如何写成脚本代码呢？
● 无法完全保证测试的正确性。上面也说到了，自动化测试是由测试脚本组成，它的核心仍然是代码，说的简单点，自动化测试就是程序测试程序。我们知道，是程序就一定会有缺陷，所以，不能保证测试工程师开发的脚本就完全100%没有缺陷，如果代码中出现一个小小逻辑错误，哪怕一个条件判断的误写也会导致测试结果完全出错。当然，对于一个有经验和优秀的自动化测试开发工程师来说，大多数的错误还是会在脚本调试中避免的。
● 手工测试能发现的缺陷远比自动化测试多。可以这么说，有85%的缺陷是归功于手工测试，而只有15%的缺陷归功于自动化测试（注意：这个标准并不是随便说的，而是由自动化测试专家共同总结得出的一组数据结论）。而且在这15%中，大约只有0.1%不到的缺陷属于新缺陷。的确，自动化测试几乎是无法发现新缺陷的，自动化测试大多是用来发现曾经发现过的缺陷在每个版本下有没有重新出现。当然，我们情愿自动化测试永远不要找出缺陷！自动化测试更适合缺陷预防而不是发现更多缺陷。请记住，自动化测试最大的用途就是回归……再回归。
● 对测试质量的依赖性极大。自动化测试的运行首先要建立在版本测试质量（在这里基本指手工测试质量）稳定的大条件下，如果当前版本的测试质量不够稳定，运行自动化测试将会非常不顺利，几乎是一种无用功和白白浪费时间的行为。
● 测试自动化可能会制约软件开发。由于自动化测试比手工测试更脆弱，以及脚本维护会受到限制，从而制约软件的开发。
● 自动化测试工具是死的，它本身没有任何想象力。自动化测试是无法做到像人类一样随心所欲地创造的，自动化测试的好坏，完全取决于自动化测试负责人和测试开发工程师的思想与技术，和自动化测试工具没有任何关系，工具是没有思想的，所有的操作全部由人通过输入代码的方式告诉工具它该怎么做。
● 成本投入过高，风险大。自动化测试需要很大的成本投入，并且如果没有良好的成本分析与控制手段以及自动化测试计划与执行过程控制，那么失败的自动化测试案例数不胜数，导致企业白白浪费人力物力还得不到任何回报。
● 自动化测试对测试人员的技术要求较高，对测试工具同样有一定要求。自动化测试对测试工程师来说必须有一定的开发技术背景，开发技术越高则写出来的脚本质量也就越高、越有技术性和想象力。不是每个测试工程师都适合或有能力开发质量好的测试脚本的。同样，也不是每一个测试工具能真正地被使用在真实的项目中并驾驭项目的，也没有听说过有一个自动化测试工具能做到适合每一个项目。
1.1.1.4 何时适合引入自动化测试
在之前的章节中，通过总结和分析，相信读者已经对自动化测试的特性和优劣有了一定的了解，接下来，分析在实际项目中关于自动化测试成败的点点滴滴。
在我们的自动化测试中，必须让读者知道哪些情况下才适合把项目的系统测试交给自动化测试来完成。但是，如果不能善加利用，则给自己或者组织造成的后果还是比较严重的。下面让我们一起认知何时才比较适合做软件测试自动化！
● 项目周期长，系统版本不断。如果你目前所在测试的项目（或系统）是属于一个周期比较长的项目的时候，可以说，的确非常适合引入自动化测试，把大量的回归测试托付给测试自动化是一个比较明智的选择。还有一种根据是从系统的版本数得来的，曾经测试领域专家有过相关的研讨并最后得出结论，一般自动化测试耗费的时间是手工测试的6～10倍，所以，如果你所在的项目（或系统）版本数在10个以上，那么，引入测试自动化也同样非常的睿智，并且和之前的项目周期综合下，时间越长随之而来需要测试的版本就会越来越多，这样，自动化测试可以发挥它最大的作用，给企业带来各方面的利益。
● 需求变更不频繁。当项目的需求非常稳定，不会经常出现变更的时候，此时也很适合引入测试自动化。
● 系统中的测试对象基本可以正常识别。一般来说，自动化测试的基本要求或者说自动化测试工具对系统的基本要求就是对象的识别，一个自动化测试工具的好坏评判最基本的标准就是，是否能够识别更多的系统控件以及对无法识别的控件能否提供各种解决方案或自定义开发各种控件的识别代码。
● 系统中不存在大批量第三方控件。有实际项目经验的读者一定会发现，无论什么系统，B/S架构的也好、C/S架构的也行，多少存在一些第三方控件，但是，如果这些第三方的控件数量不多的话，经过详细的计划与评估后，完全可以引入测试自动化，当然，如果第三方控件数量庞大或者形式种类庞大的话，就会带来很多麻烦，在下文中也会提到。
● 需要反复测试，如可靠性测试需要进行上千次的系统测试。在我们的1.1.1.2项目的第一条例子中，提到过类似的情形。在项目中，如遇到这种情况，从理论上讲是相当适合使用自动化测试策略的，当然，前提条件是有能力把自动化测试做好，如果遇到这种情形，测试自动化实行最后成功的话，一定能给整个项目团队带来“丰功伟业”！
1.1.1.5 何时避免展开自动化测试
在1.1.1.4节中，归纳了自动化测试的适宜条件，但是万物都有另外一面，自动化测试也有很多禁忌，作为一名测试工程师或者未来的自动化测试工程师来说，如果触犯了禁忌还要执着地做下去，后果也只有一个，就是自讨苦吃，给企业、项目团队带来损失，使得领导以后再也不信任自动化测试，使自己对测试自动化技术更加迷茫！接下来，作者以自己多年自动化测试实战经验以及学习经验，一定要告诉读者，在自动化测试中，哪些是犯了大忌的，读者务必吸取前人的教训，扬长避短，如果以后在项目中和以下任何一条有冲突，千万不要开展自动化测试。
● 项目周期短，需求变更频繁。当你的项目周期不是很长的情况下，请不要引入测试自动化，因为这样的话，不但收不回成本，而且会延长产品的发布时间，并且这样的行为是毫无意义的！作者在1.1.1.3小节中的第一条已经提到了。自动化测试的成本计算方式及其计算实际参照，在这里则不再多加阐述。当然，还有一个问题，相信有项目经验的读者一定会碰到过类似的问题，即使这个项目是一个长期的项目，但是客户经常性地更改需求，甚至时常更改老功能的业务逻辑。这种情况下，即使周期再长的项目也最好别引入测试自动化，因为，即使你有再好的自动化测试方案和执行技术，但你始终赶不上客户变更的速度，最终仍然还是会放弃，因为永远在收拾“烂摊子”！
● 在软件版本还没有稳定的情况下。当你准备引入测试自动化时，请先确定你所在的项目，版本功能是否已经稳定，如果版本功能还不是很稳定，主功能或大量的功能有被重新更改的可能性的话，务必暂时缓一缓，不要随意地开始自动化测试之旅。
● 没有明确的项目测试自动化计划、措施和管理。在这里，作者根据多年的项目自动化测试实战经验可以用很确定的态度与语气告诉读者，软件自动化测试和软件开发工程是一脉相传的！作者在此不阐述软件开发工程的基本概念，但是作者一定会强调，在自动化测试的开发过程中，一样需要通过严格的开发计划、版本管理、代码管理等一系列相关措施，兢兢业业地做好每一步工作，踏实地管理和控制好每一个环节。自动化测试脚本不是一次性的，而是需要长时间维护下去的，如果事先没有制定良好的测试方案，实施过程中不严格根据方案执行，开发完毕后又不做任何改进或提出各种优化方案等，那么你说，最后项目自动化测试会成功吗？
● 领导不支持。目前，较多企业，特别是中小型企业的高级管理人员还是没有能力或者没有信心可以将软件测试自动化做好。在这种情况下，首先，作者认为还是先和领导沟通好，取得他们的支持、理解与信任后再引入测试自动化比较妥当；没有领导的肯定与支持，自动化测试之旅一定是无法顺利展开的，最终也达不到终点，多半情况下会中途不了了之，如果这样的话，还不如不要引入测试自动化呢。
● 多数对象无法识别以及脚本维护频繁与艰难，二者有其一，自动化测试注定失败。又一次提到了这个说法，因为它的确太重要了！希望读者能真正地通过作者一次又一次地重复，真切地了解到这个自动化测试的重大问题。根据前文的不断讲述，作者再总结一下，如果项目中存在大量无法识别的控件（这种情况基本是发生在系统中存在大量的第三方控件）或者没有获得相应的对象识别插件，是没有办法写出自动化测试脚本的。当然，对象的识别不一定要靠插件，还有其他解决方法，比如SDK插件扩展，或者让开发人员提供相应的DLL来识别等，但是，如果有一半的插件不能识别，那么再强行为之，耗费的人力、物力将会有多大？估计能够重新开发一个新项目了。脚本维护频繁是直接和前文所述的需求变更频繁有关的，需求一直在变，自动化测试工程师只能跟着将脚本永无止境地变化下去，直到头晕目眩、直到大量测试开发工程师受不了如此的“虐待”而离职。最终，自动化测试正式宣布“失败”！