当自动化测试受到各种挑战时，我们要静下心来，结合项目的实际情况和团队的实际能力，将自动化测试的目标定义清楚，理清自动化测试的过程，将自动化测试很好地融入到整个软件开发过程中。如果自动化测试过程是不合理的，引入自动化测试只会给软件组织或者项目团队带来更大的混乱。我们应该建立正确的自动化测试目标，制定有效的测试策略，有计划、有步骤地实施合理的测试过程，这样才能确保自动化测试获得所期望的效益。
目标和策略
由于软件测试自动化在前期的投入要比手工测试的投入大得多，包括人员培训费用、开发和维护测试脚本等，所以有必要关注测试自动化的投入和产出，不断调整测试自动化的目标和策略，这样有助于提高测试自动化的效率，达到事半功倍的效果。
自动化测试的策略就是确定哪些测试实行自动化测试，以及何时采用自动化测试。自动化测试其中一个重要目的就是解脱测试人员的重复劳动，使他们能够从事更具创造性的工作，但是，如果测试自动化脚本的测试覆盖率较低，不但不能使测试人员解脱，反而增加了他们的工作量，以及进一步降低对自动化测试的信心。因为自动化测试提供的帮助很少，还要完全依赖手工测试，这样测试人员要同时做两件事——自动化测试和手工测试，手工测试的工作量丝毫未减少。只有覆盖率高的自动化测试脚本才是真正有效与需要的。但不能走向另外一个极端，否则会走进一个新的误区——“尽可能实现所有测试的自动化，即追求百分之百的自动化结果”。通常，人们认为，使用测试工具越多，自动化测试程度越高，我们从中获取的投资收益就越大。实际上，在不同的自动化水平或阶段，结果可能不同。
1) 低水平，自动化测试的覆盖率在10%～30%水平的时候，自动化测试的收益很低，甚至是负收益，即投入大，而收益小。
2) 中等水平，自动化测试的覆盖率在40%～80%水平时，自动化程度越高，带来的效益越大。这时候，大部分功能测试的工作都由工具完成，可以显著地提高测试效率，缩短测试周期。
3) 高水平，自动化测试覆盖率在90%～100%水平时，自动化程度越高，效益看起来也越高，但投入很大。覆盖率特别高时，每前进一步都很难。从管理的角度来说，100% 只是理论上可能达到的自动化目标，但是实际上达到100% 的自动化的代价是十分昂贵的。根据实际经验看，自动化测试甚至不可能达到100%。
自动化测试所带来的优势也是明显的，例如提高测试效率、增强测试人员对测试工作的兴趣等，但我们不能忘记，测试的最根本的目的是保障质量。所以，自动化测试的收益还应该体现在改进测试质量上，而且这还是一个重要的衡量指标。从质量这个角度分析，我们也可以为自动化测试设定相应的目标，例如：
1) 自动化测试能否帮助测试人员尽早地发现缺陷？这似乎不可能。
2) 能否帮助我们提高测试覆盖率？这是可能的，例如可以通过EMMA工具来度量测试覆盖率，并能准确地确定那些没有被测试的代码，从而改进测试用例，再进行度量，直至满意为止。
3) 能否为持续集成、持续测试的开发过程提供有力的支持？答案也是肯定的。
不要追求百分之百地实现自动化测试，而是关注那些可以快速建立的、可以反复利用的自动化测试，寻找能够带来最大回报的部分。部分地采用自动化测试，或采用自动化测试操作和手工测试结果分析相结合的方式，可能是最有效的。那么，如何确定自动化测试项或范围？一个基本的原则，即自动化测试的核心策略，是选择那些最能获得投资回报的测试项，例如：
1) 测试重复次数最多的测试用例，包括不同支撑平台（操作系统、浏览器等）的测试；
2) 手工耗时最长的测试用例、能够最大程度地缩短测试周期的测试任务；
3) 能最大程度地提高工作效率的地方，如每天都需要执行的冒烟测试；
4) 最有可能减少风险的领域，如大量数据的测试，手工测试容易出错；
5) 最能够提高测试精度的测试，如性能测试须要准确地模拟负载，获得系统资源使用率的数据等；
6) 最单调的测试，如有些测试就是不断地敲键盘或点击鼠标按钮。
最后，就自动化测试团队建立的两种策略做些讨论。
1) 成立独立的测试自动化团队（TA Team），即设立专业的TA工程师。TA工程师可以专心致志地进行自动化测试工作，而且具有较高的编程能力，有助于保证脚本的质量，但问题是，人为地将自动化脚本的开发和测试设计、执行等隔离开来，增加了沟通和知识转换的成本，甚至给全面推广自动化测试带来很大的障碍。
2) 不设立独立的自动化测试团队，而是将测试自动化融入一般测试过程中，每个测试工程师都承担自动化测试的责任，将需求文档审阅、产品规格说明书审阅、测试用例设计、脚本开发和运行等集于一身。这是值得推荐的一种策略，能更好地保证测试脚本开发的正确性、有效性和效率。
实施过程
自动化测试的过程，从不同的方面看，可能会有不同的理解，而且也要求我们从不同的方面去考虑，从而综合考虑影响自动化测试过程的因素，找出相应的对策，以确保自动化测试过程的顺利实施，最大限度地发挥测试自动化的作用。自动化过程可以看作由下列由3部分组成。
1) 自动化测试，首先可以看作一个项目，那么自动化测试的过程就是一个项目的实施过程，经过计划、执行、评估与总结而不断提高的过程。
2) 自动化测试，可以看作软件开发的过程，经过测试需求的分析、自动化测试框架的设计、测试脚本的开发和验证、测试脚本的运行等流程。而且测试脚本的管理和源代码的管理也是一样的，须要通过CVS、SubVersion等工具进行配置管理，包括版本分支和合并、变更控制等。
3) 自动化测试过程，依然是一个测试过程，从测试需求出发，设计和执行测试用例、报告缺陷，并自动生成测试报告。
1. 自动化测试需求分析
当接受一个新的项目时，必须针对测试项目的具体情况进行具体可行性分析，确定一个软件系统测试中哪些范围、哪些任务是适合自动化测试的而哪些是不适合的。如果对不适合的测试任务实施自动化工作，不仅耗费过多的人力，而且效果也不一定好。
然后，根据测试任务的特点并结合自动化测试框架的要求，确定正确的自动化测试目标和策略，选择合适的自动化测试工具，逐步开展自动化测试工作。
2. 选定测试工具
不可能有单一的测试工具能满足测试的所有需求。不同的测试任务会选用不同的测试工具，如单元测试须要选用单元测试工具，性能测试须要选用性能测试工具；
针对不同的应用，也要选择不同的工具，如针对Web应用，可以选择Selenium和WebLoad等工具，而针对客户端应用，则要选择AutoIT等工具。
在选择测试工具时，要清楚测试目标和需求，确定适用的技术环境及自动工具可支持的各种测试，分析测试工具与被测软件系统的互操作性和兼容性，考虑工具的易用性、工具学习曲线或培训成本，特别是要考虑工具本身所要求的测试脚本，是否支持数据驱动、关键字驱动，以及是否容易编写、调试和维护等。
3. 开发自动化测试脚本
自动化测试脚本的编写，和产品的软件代码编写是异曲同工的，须要遵守编码规范，包括脚本的层次、命名等。如前面所说，将（测试）数据层、（系统）操作层和（业务）逻辑层分开，不仅构造结构化的脚本，而且构造程序对象映射、建立对象库和关键字函数库等，全面支持测试数据驱动、关键字驱动的脚本，有利于脚本的开发和维护。测试脚本的开发，和软件产品本身的开发还有许多相似之处，例如：
1) 如果在开发编码之前，对测试自动化作了整体设计，将有助于测试自动化开发的顺利开展；
2) 自动化测试代码须要跟踪和维护，因此，要采用源代码管理；
3) 测试自动化也会出现缺陷，因此，须要有计划地跟踪缺陷，并且对修改后的缺陷进行验证；
4) 用户须要知道如何使用工具和脚本，因此要提供用户使用手册。
在脚本开发中增加冗余设计，即使降低一定的性能，也要保证测试执行的稳定性。如果测试可以在无人值守情况下运行，那么测试的执行效率就不是大问题了。
验证点的脚本实现最有效的方法是使用标准文件。首先，捕获被测试程序的输出，并检视程序的输出，然后把输出信息文档化并归档，作为标准文件。在脚本中，我们可以将自动化测试的执行结果与标准文件作比较，从而达到结果校验的目的。
脚本写完了，并不代表脚本开发工作已结束，还须要调试。只有脚本运行稳定，执行的测试结果符合测试要求，才能说明测试脚本开发工作告一段落。通常来说，测试脚本的调试工作量和编写工作量接近，脚本写完了，意味着工作只完成一半。当然，理想的方式是一面编写，一面调试、运行，脚本编写结束，调试也结束，同时运行也非常稳定，这和软件开发中“持续集成、持续测试”的思想是相通的。
4 测试结果分析
在自动化测试中，常常出现“多米诺骨牌”效应，当一个测试执行失败，会导致后续一系列测试失败。
自动化测试结果一般被分为3种情况——通过（pass）、失败（failed）和不确定/没有被执行（TBD/unexecuted）。针对测试自动化执行结果，主要集中分析那些没有通过（failed）的结果。首先，分析是不是软件产品本身存在缺陷导致测试执行失败？是不是上面某个测试执行失败而导致其他大量的测试执行没通过？如果不是，再查看测试环境。如果产品和测试环境都没有问题，就要检查自动化测试脚本，是不是测试脚本误报信息？还是脚本的验证点设置不对？有时候，测试执行全部通过，也可能存在问题——脚本的验证点不够或太粗，从而错过许多验证点，给我们一个假象(ps：英雄所见略同，经验告诉我是有风险的，但一般不会)。
为了更好地进行测试结果分析，一方面，尽量记录下测试过程中的重要信息，即存储好的测试执行日志（log）；另一方面，提供规范的测试结果报告格式，使结果一目了然，并在失败的用例提供链接，点击链接，就能直接查看相应的测试用例和执行的log。
开发流程的调整
刚开始启动自动化测试时，由于还是试探性的工作，流程无须做什么改变。但如果在软件开发项目中全面开展自动化测试，这时须要考虑对软件开发流程（包括测试流程）做适当调整。例如，在多数公司是由开发人员完成单元测试，如果没有流程来规范开发人员的行为(ps：说实话测试人员的也要规范其行为，捂脸)，在项目进度压力比较大的情况下，开发人员很可能会有意识地不使用测试工具，来逃避问题。所以，有必要在开发和测试的流程中明确定义测试工具的使用。
首先，自动化测试须要开发大量的测试脚本，而此前的需求评审、设计评审等工作不能省略，测试计划和测试用例设计的工作量基本没有改变。在测试用例的设计中，虽然可以省去部分文字工作，但这个过程依旧需要，依旧要考虑业务逻辑变化、软件使用场景、输入/输出数据处理方式等各项内容。这样，测试脚本开发所需要的时间在开发流程中要考虑，而测试执行的时间可以相应减少，最终软件开发的总体时间可能会增加或不变。
其次，在项目计划过程中，必须充分考虑构建自动化测试所需的时间，将自动化测试计划融入项目的总体计划中，例如须要考虑下列影响自动化测试的因素：
1) 对项目成员进行自动化测试工具和脚本开发的培训；
2) 创建自动化测试框架，制定测试脚本开发的规范；
3) 软件代码的可测试性，这种可测试性是针对测试工具来衡量的，也就是要求测试验证点准确，验证点的期望结果是可以度量的，即能通过脚本进行描述；
4) 自动化测试环境的建立、配置等；
5) 其他基础设施如何支持自动化实施。
再者，引入自动化测试后，测试人员须要和开发人员密切沟通。自动化测试的工作须要更多地了解软件系统的构成和实现，包括技术设计文档和代码。只有充分地了解软件内部的结构和具体代码，测试的脚本才更具有针对性，开发效率才可得到进一步的提高。理想情况下，开发人员在编码之前就定义好相应的类、对象名称、ID和相应的属性等，在开发人员写代码的同时，测试人员就可以并行开发测试脚本。为了实现自动化测试的高利用率，自动化测试可和每日构建结合起来，每天自动运行回归测试。
最后，测试脚本也是“代码”，要并入软件配置管理的体系中，例如用CVS或SubVersion来统一管理各类测试脚本，包括版本分支、合并的控制。
走向成功
不管是手工测试和自动化测试，关键是测试流程的建立和测试用例的设计，只有在良好的测试用例基础上开发测试脚本，测试脚本的质量才有保证，最终保证自动化测试的执行效果。为了更好满足测试脚本开发的需求，可以将测试用例转化为决策表、矩阵图, 帮助实现脚本的结构化、脚本的数据驱动方式。
在软件测试自动化实施过程中，可以从简单的测试任务开始，例如一些应用程序接口（API）测试的自动化实现，比较容易些，也比较容易做到90%以上。然后，向性能测试、普通的功能测试等，一步一个脚印，不断向前推进，逐步获得成功。在这个过程中，需要组织的支持，须要制定正确的策略，需要人才，从各个方面来保证自动化测试的成功。在这个过程中，没有捷径，须要不断实践、思考、改进、再实践、再思考、再改进……只要肯付出艰辛的努力，最终就一定能获得成功。
但同时，我们可以遵循一定的操作步骤，将自动化测试融入整个开发过程，建立适合自动化测试的流程，并选择合适的测试工具，建立相应的测试环境和对测试人员进行充分的培训，有效地帮助我们以更小的代价、更早地获得自动化测试的成功。
正确的认识：测试人员直至整个软件组织要树立一个客观辩证的自动化测试思想，充分掌握自动化测试和手工测试的各自特点和应用范围，清楚软件测试自动化绝不能代替手工测试，而是相互补充。当手工测试执行时，通常假定由一个有头脑、善于思考、具有观察力的测试人员来完成。 如果采用自动化，测试执行是由一台不会说话的计算机完成的，我们必须告诉计算机什么样的情况下测试执行是失败的。工具本身并没有想象力和灵活性，自动测试只能发现15%～30%的缺陷，而手工测试可以发现70%～85%的缺陷。
定义清楚需求：清楚自动化测试的目标，在组织内就衡量自动化成功的标准达成一致意见，例如侧重于获得最大的回报，而不是试图完成软件每个部分的自动化测试。针对软件的不同组件或不同的测试任务，应定义不同的自动化目标。
改进自动化流程以适应自动化测试的需要，例如测试过程是清晰的，每个测试阶段的进出标准是可量化的，而且测试过程充分保留了测试脚本开发的时间，特别是在软件产品的第1个版本开发的时候。
快速的可行性论证：自动化测试实施时，须要进行可行性验证，但要尽早、尽快地认证测试自动化的可行性，例如选用软件系统中一、两个典型模块，快速构建有效的测试套件，使用候选工具来完成相应的测试任务，如图形界面的功能测试、不同平台的兼容性测试等。
确保产品可测试性：组织内明确定义规范，将软件产品的可测试性作为产品的基本需求。例如，在产品设计中，认真考虑可测试性，增加命令行接口（CLI）或应用程序接口（API），解决一些图形用户界面给自动化测试所带来的障碍。
可持续发展策略：测试脚本的开发，不能图一时方便，而要从长期可维护性的需求出发，来设计和编写测试脚本，避免由于脚本不可维护而放弃测试自动化的努力。例如，脚本录制能快速生成测试脚本，但这样的脚本一般不具有可维护性，所以要尽量摒弃直接使用所录制的脚本，而是将录制的脚本作为参考，或在部分录制的脚本基础上进行修改、重构等。可持续性发展的脚本应具有高可读性、规范性 、层次性、独立性和复用性等特征。
持续运行：写完一段脚本就运行，每天都要运行已完成的测试脚本，及时发现问题，及时纠正或调整，这样，一旦脚本完成，就能提供一套稳定的、成熟的自动化解决方案。不要等所有脚本完成后，才开始运行它们，到那时问题可能太多，无从下手，从而对大家实施自动化测试的信心产生较大的打击。
本文来自朱少民老师的《轻轻松松自动化测试》，如有侵权，请通知后删除