《自动化测试最佳实践：来自全球的经典自动化测试案例解析》第0章案例研究反思，本章高度总结了现有经验中需要吸取的最重要的教训。本节为大家介绍自动化测试目标。
第0章 案例研究反思
成功的自动化测试需要智慧和毅力。你的经验可能和本书所描述的有一些相似之处，但每个人的故事都是独一无二的。通向成功的道路并不简单，但是正如书中案例研究所描述的那样，自动化测试已经在各种应用领域、各种环境和项目的各个生命周期中取得了成功。
通过思考，我们根据书中出现的案例和奇闻轶事总结出了一些方法。本章高度总结了现有经验中需要吸取的最重要的教训。你可能会在阅读完后面各个案例研究章节后再次阅读本章。
哪些主要因素促成了自动化测试的成功？导致自动化测试失败最常见的因素有哪些？
对这些问题没有简单而通用的答案，但存在一些公共的要素。我们认为最重要的两个要素是管理问题和测试件架构：
对自动化的管理层支持，包括设置切实可行的目标，以及提供足够合适的资源来取得已计划的ROI。
一个好的自动化测试件架构，拥有正确的抽象层，在降低自动化测试件维护和自动化测试各个方面成本的同时提供灵活性和适应性。
除了共同的要素外，还有其他一些方面，甚至是一些令人吃惊的要素，将它们也考虑进去可以帮助你在自己的自动化测试中取得更大的成功。这是我们写这本书的希望和目的！
在以下的大多数小节中，我们会着重强调一些章节号，并讨论一些特定的主题。这些主题可能也在其他章节涉及，我们会在这里列出各章针对某一特定主题进行的专门讨论。
我们首先在0.1节讨论管理层问题，但经理们也需要注意0.2节描述的技术问题。
0.1 管理层问题
从许多案例研究中可以清晰地了解到，管理层的支持力度关系到自动化测试的成功与失败。举例而言，第4、6、11、17和20章都叙述了管理层支持欠缺导致自动化测试失败的情形。
0.1.1 自动化测试目标
制订一个合适的目标对自动化测试的成功实施至关重要！这似乎是显而易见的，但令人惊讶的是，在没有任何清晰目标或仅仅是只有一些模糊的陈词滥调作为目标（如“更快的测试”、“做得更好”、“节省时间”）的情况下，一个自动化测试就开始了，这类事情经常发生。目标越具体，自动化测试越有可能得到好的评价并取得成功。
将软件测试所要达到的目标与自动化所要达到的目标区分开来是很重要的。自动化是运行测试的一种方法，无论这些测试是好还是坏。一个好的测试目标是发现许多bug。这没有必要成为一个好的自动化测试目标：在近期对项目进行一些改动之后，需要进行回归测试以确保变更的部分不会影响系统的行为，而这类测试很少发现新的错误。这并不意味着自动化测试不成功，只是因为它有了错误的目标。如果一个高层经理感到自动化测试没有达到预期目标（即使这个目标是一种误导），那么资金也可能被撤掉。
0.2.9节讨论了一些能够有效地找到bug的自动化测试示例。一些好的自动化测试目标在第1、2、3、6、7、10、11、12、14、20、21、25、27和29章中讨论。
0.1.2 管理层支持
在一个无法对自动化测试进行精心培育并有效引导的组织中，自动化测试很难成功发展起来。对于个人来说最好先亲自试验一下，如果想要大规模地进行自动化测试，并能收获自动化测试对于产品最终发布所带来的巨大好处，则需要管理层的大力支持。一种“自下而上”的方法并不是通向良好自动化测试的一条长期可持续的道路。
管理层支持对自动化测试的成功至关重要；我们可以在本书的很多案例研究中看到这一点。管理层支持包括多种形式：对工具的资金支持，对于一个试点项目和测试件架构的开发过程的资金支持，以及为此需要付出的时间，管理层还要有兴趣去理解自动化行为以监督成本与回报（参见A.3节的ROI）。
对于经理来说很重要的一点是，对于自动化过程他能够提供什么，以及对要达到期望的结果需要付出时间与努力有着很明确的了解。
在某些案例中，一些高层的经理并不十分了解好的自动化测试意味着什么。这可能是因为他们没有很好地亲自调查，但另一个因素可能是做自动化测试的人员没有积极沟通，虽然沟通是他们本应该做好的事情。
与管理层沟通的重要性主要在第1、4、6、13、20和29章中进行强调，而具体作法则在第16、19和29章中涉及。管理层支持作为示例学习的关键因素在第1、2、6、11、18、21章中进行了强调。
0.1.3 ROI和度量标准
一个普遍的误解是，成功的自动化测试仅仅需要购买相应工具的投资（如果你得到一个开源工具，那就不需要其他任何花费）。如果在自动化方面的投资为0，则其投资回报率可能为负值。简而言之，如果你什么也不投入，你将会陷入麻烦！
要在以下方面进行投资：对于观点的研究和实验；设计和开发一个好的自动化测试件架构；学习和了解失败和成功的因素；找到符合特定情况的解决方案；就自动化测试计划、进度及测试方法进行沟通。
常常在一个自动化测试开始时评估ROI。这是一个很明智的做法：相对于自动化测试的投入，是否获得了更多的收益并节约了资金？执行自动化测试的理由通常是比较执行同一测试手动和自动所花费的时间。尽管这是证明自动化测试有用的方法，但仅仅执行自动化测试并不是全部。实现自动化测试的时间，对自动化测试的维护，分析错误测试的时间以及其他一些可能比手动测试花费更多时间的任务。这些其他任务可能是一个重要的额外开销，也应该考虑。要知道如果你使用一个工具供应商的ROI计算器，这些其他的开销可能不包括在ROI的计算中。
其他需要考虑的因素包括：更高的覆盖率（已经测试过的系统数量），最少的时间推向市场，以及增长的信心。但这些益处在早期的自动化测试实施中可能无法实现。它们会在自动化测试一旦完成之时变成现实。它们同样难以量化，因此也可被看做额外的收益。
一旦一个自动化测试建立，看它能否达到预期也是非常重要的，因此最好定期做这样类似的比较（将所有因素考虑进去），并且将这一信息和负责资金的管理层交流，这是非常重要的。
许多人混淆了收益（benefit）和ROI。收益只是收益，而ROI则是将收益与成本有效地进行比较。
请记住，你决定收集的度量标准可能被误解，也许它没能传达你所希望的意思。也请注意，那些在新的上下文中不再有用的度量标准；第28章描述了自动化测试的职业生涯的影响。
ROI和量化收益在第1、2、9、12、13、18、23、26和29章中讨论。在第9章有一个用来评判投资的基于模型测试的ROI计算器的范例。
0.1.4 在敏捷开发中的自动化测试
随着敏捷开发变得更加普遍，其自动化测试也变得越来越重要。持续的集成就是测试自动化；回归测试每天都要进行，有时候甚至更为频繁。自动化测试也需要在出现变更时能做出响应，就像敏捷开发中那样，于是测试件架构便显得更加至关重要（参见0.2.1节）。自动化测试在传统开发和敏捷开发中都取得了成功，没有自动化测试，敏捷开发就不会成功。
敏捷技术，如测试驱动的开发（Test-Driven development，TDD）可以确保自动化的单元测试，但是对使用敏捷方法开发的系统仍需要进行系统测试。第1章主要讲述的是敏捷开发中的自动化测试；敏捷项目中的自动化测试也在第6、7、17、18、19和21章中提及。
0.1.5 技能
测试人员所需要的技能和自动化测试人员不同，自动化测试人员的角色可以看做测试人员和工具之间的桥梁（参见0.2.1节）。
自动化测试人员的角色有着严格的区分：一类是高层次的自动化设计人员（测试架构师，test architect），另一类是自动化测试件的实现人员，自动化测试人员（test automator）可以用于这两类人员。自动化测试架构师的任务是设计自动化测试的整体结构，或者为了创建好的测试件架构而选择框架，或是将现有框架进行改进以适应新的需求。自动化测试人员的任务是设计、编写、维护自动化测试的软件、脚本、数据、期望结果以及额外的实用工具。自动化测试人员负责实现多个层次的抽象（在0.2.1节中讨论），这使得测试人员不必学会编程就可以使用这些自动化手段。自动化测试人员同样可以帮助测试人员，包括解决技术上的问题、决定花费/ 收益的比率，以及实现新的测试需求等。自动化测试人员必须有好的编程基础。
有这样一种趋势，即测试人员同时也是开发人员。如果测试人员同时还是一名好的程序员，那么这个人既可以成为测试人员也可以成为自动化测试人员——我们讨论的是不同的角色，他们不一定是不同的个人。
然而，很多测试人员并不一定擅长技术，而且他们也不想成为程序员。就如Hans Buwalda说的，强迫一名非技术的测试人员去做程序员，不仅会使你失去一名好的测试人员，还会让你得到一名不称职的程序员。非技术的测试人员也应该参与自动化测试！如果将他们从自动化测试的过程中排除，就不能充分发挥这些测试人员的技能，从而也无法充分挖掘出自动化测试的潜力。
测试人员和测试自动化人员的角色在第10、12、18、19、20、23和29章中讨论。
0.1.6 计划、范围和期望
当自动化测试有好的计划时，它通常更有可能获得成功。计划应当包括，在自动化测试应用于整个项目前花些时间进行一些实验。例如，一个限制时间的试点项目，让你能更清晰地看到如何达到自动化测试长期目标的方法，当然这个项目也要有清晰的目标和足够的资源。
不要期望自动化项目中不会出现任何问题；没有什么事情是没有问题的！应该随时准备应对可能出现的问题。记住即使是最好的计划也仅仅是一项指导——要根据情况去重新审视这些计划。
设定符合实际的目标，即在规定时限内完成任务，并且定义好项目的范围。不要太过于关注细节，否则就无法在公司中获得那些潜在的收益。要关注在早期就能得到的一些有用的结果，而不要以减少有用的自动化测试为代价，去构建过量用于支持测试复用的库。一旦自动化测试开始运行，要继续寻找方法去改进这些自动化测试，并且为自动化测试设立新的目标以减少花费和增加收益。
第1、5、6、11、16、20、25和29章讨论了这些问题，第1、3、23和27章还讨论了如何持续地改进自动化测试过程。
0.1.7 和开发人员的关系
在成功的自动化测试实践中通常有一项因素，即在测试人员、自动化测试人员和开发人员之间保持良好的关系。如果他们的关系不好，那么自动化过程就会更加艰难，即便自动化测试在最后还是会带来一些收益。如果软件在设计时没有考虑到自动化，那么自动化测试就会变得非常困难。例如，如果软件使用了非标准的控件，那么自动化测试就很难和软件进行交互。测试人员或者自动化测试人员或许会对开发人员说：“请仅仅使用标准的控件——这会使得我们的工作更加容易。”但是开发人员的时间很仓促，可能会说：“我们为什么要做一些不会给我们带来好处的事情呢？”这个开发人员并非很无理，这确实是一个相当合理的原因（虽然一些测试人员不会同意这个观点）。
更好的方法是告诉开发人员自动化测试是如何让他们受益的，并且和他们保持良好的合作关系。例如，如果你能够在15分钟内在测试环境中对一个新编码的函数运行测试，你就能够在一定时间内向开发人员提供有用的信息（找到了bug或者测试已经通过），这对他们是极大的帮助。
关于开发人员和自动化测试人员的关系在第1、2、6、9、17、20、27和29章中讨论。
0.1.8 促进项目改变并启动自动化测试的触发器
是什么让一家公司决定它们应该采用自动化测试？有时，因为测试不足所带来的严重问题或者近期的灾难，促使公司做出改变；有时，来自公司外部的观点也会带来更好的解决方案；有时，管理层决定公司需要自动化测试，这甚至决定了公司的生存。人们总是先尝到了苦头，然后才会进行实际的改变。
对于那些打算应用自动化测试的公司，最重要的建议是要从小范围开始应用。试点项目（pilot project）是个好主意，在将自动化测试扩展到更广的范围之前先在小范围内尝试不同的方法，来判断哪种方法最好。
这些问题在第1、9、10、12、17、23、26、27和29章中讨论。
0.1.9 工具和培训
人们经常会问一个问题，哪个工具是最好的？这就像问哪个汽车最好一样。一个人认为最好的车是能够容纳四个小孩和两条狗的车；另一个人可能更关注于车的速度和性能；还有一些人关注哪个车更经济一些。因此，没有完美的工具，但是有很多工具是足以应对某些特定场景的。
事实上，正如第17章讲述的那样，有时可能会选择错误的工具，因此为所要做的工作选择合适的工具是很重要的。在第17章中错误使用的工具却在第7章和第25章中取得了成功。
但是工具不是测试自动化最重要的因素。是的，通常确实需要使用工具来执行测试，但是在大多情况下，好的自动化测试的其他方面远远比因单独工具之间的差异所带来的影响要大得多。拥有好的工具不能保证在测试自动化中取得成功——必须对整个测试框架进行良好地计划、定制和维护，工具仅仅是一小部分。
使用一个工具失败并不意味着使用其他工具就能取得成功；一些公司尝试了一些工具但是在每次尝试中都以相同的方式失败了。遗憾的是，公司经常将这些失败归咎于工具或者个人，而实际原因在于自动化测试项目没有进行足够的计划和管理。
工具的主要用处是为人员提供支持！那些将要使用工具的测试人员应该在如何使用这些工具上有话语权，而且公司应当为工具提供基础设施以支持他们。
无论使用什么工具，培训都是很重要的。那些将会直接使用工具的人应该在早期就接受一些深入的培训，无论是通过工具生产商的课程或者在线教程。如果公司引进组织外部的顾问或者工具生产商的技术支持人员来进行培训，将每次会议的间隔日期进行适当调整，以便在这段时间中测试人员能够吸收这些知识并且对他们所学到的内容有实践的时间。之后，为那些需要使用这个自动化工具的人提供培训，告诉他们自动化测试应该如何进行——这是内部培训，而不是外部培训。良好的培训能够避免浪费很多时间。
关于工具和培训相关的问题会在第1、6、11、12、13、18、19、21、23、25、26和29章中讨论。
0.1.10 行政因素
在自动化过程中，有一些因素是测试人员、测试自动化人员，甚至是经理或者其他利益相关者无法控制的；例如，可能会因为一个主要项目的取消，导致为成功的自动化测试付出的努力也变成徒劳。
很多测试人员和自动化测试人员之所以艰难地进行一些项目，可能仅仅是因为他们经理的一句看起来随意的话。第29章中的奇闻轶事就举了这方面的例子，还有在第4章中，经理的行为“谋杀”（虽然这可能是“过失杀人”，而不是“谋杀”）了自动化测试。第28章举了一个例子，即当自动化测试带来的改进是如此巨大，以致经理都不肯相信这些结果。
行政因素是生活的一部分；做出的决定并不经常像看上去那样合理。
（未完待续...）
最新内容请见作者的GitHub页：http://qaseven.github.io/