“推动测试到上游”指的是将测试的执行推动到开发和设计阶段。持续集成是一种“在上游执行测试”的方法，这种方法用定期（以天或小时为单位）的方式或是代码提交触发的方式对提交的代码进行验证，能够及时地向开发工程师提供代码质量反馈。这种方式可以保证尽早发现缺陷，且由于测试的执行者和修正者是同一个人，可以极大减少沟通带来的开销。在我看来，类似于持续集成的方式是自动化测试能带来大收益的做法。但要想将测试推动到上游，并非建立一个持续集成框架都足够，如果开发工程师需要花费巨大的精力来创建、执行和维护测试，显而易见，他们是不会接受这种“在上游执行测试”的理念的。Android和iPhone都提供了自动化测试框架（Android上的Instrumentation和iOS上的UI Automation），理论上来说，开发工程师可以完全自己来创建、执行和维护针对自己应用的自动化测试。但如果考察下开发工程师在执行这些测试时的成本，会发现，由开发工程师自行维护Android和iPhone上应用的自动化测试，实在是很难被开发工程师接受。以iOS上的自动化测试为例，如果开发工程师想要在真实的设备上执行测试，他/她必须首先找到一台iPhone设备并连接到自己的机器，编译好需要被测试的应用，用iTunes将需要被测试的应用同步到iPhone设备，然后打开UI Automation的IDE环境，加载测试脚本，执行测试，人工检查测试结果是否正确??我敢打赌，除非是独立开发者，否则没有哪个开发工程师能坚持用这种方式执行自动化测试超过一周的时间，开发工程师一定会像扔掉烫手的山芋一样把这个工作扔给测试团队。那，怎么样才能在这种情况下把测试推动到上游？这里的主要瓶颈在于测试执行的消耗太大，如果能够建立一个移动设备的实验室，将iPhone和Android的测试执行统一为一个命令行，只要指定了被测试应用的binary、需要运行测试的设备、需要运行的测试脚本、结果存放的地方，可以通过这个命令行直接告诉开发工程师测试的执行结果??在这种情况下，与自动化测试的维护和创建成本相比，自动化带来的收益要远远高于投入（能够得到立即的反馈，能够重复不断的快速执行测试）。“将测试推动到上游”并不是具体的自动化测试技术，但却是非常值得尝试的自动化测试方向。在上面的iPhone和Android测试的例子中，“创建可以让测试执行成本降低的自动化测试执行环境”在这种状况下是“将测试推动到上游”的佳选择，在其他情况下可能需要解决的是其他的问题。不管怎么说，秉承“将测试推动到上游”的观点，并通过自动化测试创造推动到上游的可能性，在我看来，是自动化测试的一个可以持续带来收益的途径。

　　自动化测试不是的，但没有自动化测试是万万不能的。和金钱一样，自动化测试不可或缺，越多越好，但也不能期望用自动化测试解决掉所有的问题。什么问题不适合用自动化解决呢？自动化测试技术是依靠机器的能力进行测试执行和验证，因此，凡是不适合使用机器执行和验证的都不适合使用自动化测试技术：例如，某些需要人工体验的操作，对音视频的流畅性的判断等等；另外，从收益上来说，还没有稳定下来的需求和UI，不适合对其进行自动化测试；又或者，在敏捷开发的环境下，测试者需要通过使用软件和探索软件等方式对每个迭代的新功能进行探索和学习。在这些情况下，我们通常需要依赖于手工测试的手段，使用探索性测试等技术帮助我们了解应用、在脚本之外发现应用中的缺陷、以及填补自动化测试无法达到的空缺。

　　该在什么地方进行自动化测试？一个简单的帮助你决定是否要在某个地方引入自动化测试的判断方法是：

　　1、从技术上来说，这里可能被自动化吗？

　　2、如果引入自动化测试，能带来收益吗？

　　如果两个答案都是yes，那毫不犹豫的开始你的自动化吧。