自动化
这几年工业4.0的概念很火。若要来总结四次工业革命的话，我会说这是一个通过不断深入自动化来解放人类的过程。
- 第一次工业革命，人类利用水力和蒸汽的力量解决了出力过程的自动化。
- 第二次工业革命，人类使用电力解偶能源采集和能源使用，从而让出力过程自动化扩散开来。
- 第三次工业革命，人类使用电子设备和信息技术解决了调度过程的自动化。
- 第四次工业革命，人类想要解决分析，编排过程的自动化。
程序员是一个很自负的群体，他们号称要把一切能自动化的东西都自动化掉，其结果就是：当把编程也自动化之后，就不再需要程序员了。如果这是什么坏事的话，那也是他们自食其果。因为在那之前，他们已经把很多东西都自动化掉了，也消灭了很多行业。
测试在开发之前
不管是从工业革命的历史来看，还是从逻辑上推理，调度过程的自动化总是先于分析和编排过程的自动化。而测试其实就是一种调度的过程。开发则涉及到一些分析和编排的过程。所以可以得出测试的自动化应该在开发自动化之前。
测试几时会被干掉
马克思分析了资本主义的种种问题，预言中了出现的种种恶果，然后说共产主义是未来。然而已经过去多少年了，共产主义却迟迟不来。不管是基于历史推断，还是纯粹理性逻辑，一个事物应该是怎么样不等于它实际是怎么样。
人类有能力正确预言一个简单事物的发展结果，但如果一个结果是基于其它未确定或稳定的结果，那么人类预言正确的概率通常都不高。所以这里要讨论的不是测试应不应该或者能不能自动化。而是现在自动化测试的条件成熟了没有。
自动化测试的前提
所谓自动化，无非就是让原本需要人来完成的工作由机器来完成。而软件其中一类的功能就是让电脑来完成原本需要人才能完成的工作。所以自动化测试并不存在技术上的不可实现点。
1936年图灵提出了一个抽象计算模型：图灵机。而第一台图灵完全的通用数字计算机出现在8，9年后。而人类建造通天塔的传说更是告诉我们，技术上没有不可实现点，不等于实际上可实现。
软件工程最大的问题在于复杂度的问题，我们假设我们开发的系统是可实现的，那么我们只要论证开发一个自动化测试我们目标系统的测试系统，复杂性不高与我们的目标系统，那么这个自动化测试系统就是可实现的。
系统的复杂度主要有两种，一种是概念上的复杂性，一种是表述上的复杂性。测试系统与目标系统在概念复杂性上是一致的。不管是测试一种行为还是实现一种行为，对行为的概念应该是一致的。在表述复杂性上，测试系统是低于目标系统的。因为目标系统表述的是实现一种行为的过程，而测试系统表述的是对比目标系统的执行结果和预期的结果。所以可以得出测试系统的复杂性低于目标系统。所以对于一个可实现的目标系统来说，它的自动化测试系统也是可以实现的。
上面说的是技术上可以实现，现实中我们要不要做一件事通常考虑的是成本与收益。我们不可能在开发一个系统时（或之前或之后），还要开发一个自动化测试系统，成本不允许。但针对整个软件领域开发一套自动化测试框架是收益大于成本的。所以是值得做的事，所以才有了那么多的测试框架。而自动化测试的前提就是对一个系统进行自动化测试的成本小于自动化测试带来的收益。
如何去做自动化测试
任何有用的系统，都会有输入和输出，但输入输出的表现形式各不相同。所以并不一定所有的系统都适合在目前来做自动化测试。接下来我们讨论的是几种软件系统的自动化测试方案。
web 系统
如果 web 系统是采用比较老的技术栈开发的，那么可以使用一些目前比较成熟的 web 应用程序测试框架。但这些框架通常使用起来不是很方便。成本不低，因为要编写和维护比较复杂的测试脚本。收益不高，因为脚本检测不到很多人一眼就能看到的问题。
如果使用的是现在比较新的技术栈，那么很多组件化框架本身就带了测试框架，使用这些框架可以方便的达到自动化测试的效果。只是需要额外多写一些测试代码，关于值不值的写这些测试代码以及写到什么样的程度，业界一直存在争议。就目前的情况来说，完全有可能使用自动化测试覆盖所有功能性测试。成本不低，也不算高，但收益高。
使用接口访问的系统
使用接口访问的系统是一类比较容易进行自动化测试的系统，无论是通过 webservice 还是 restful 接口，都有比较成熟的测试框架，测试效果甚至优与人工测试，因为人出现失误的机率比电脑高，而且人对时间的敏感性会带有主观因素。
压力测试
不同于功能性测试，压力测试除了测试正确性之外，还需要测试系统的负载，响应时间，可用性等。现在压测的框架不少，问题只在于自动化压测环境的搭建，而这是运维方面的内容，而去运维的自动化目前是走在测试自动化前面的，所以这块并没有什么多说的。
外部条件
软件行业日新月异，新技术，新概念不断涌现，这些年来微服务也是特别火，网上随便搜索一下最近很火的技术文章，不是在说微服务就是在说容器化。
对于微服务产生的原因，以及带来的好处，网上已经讨论的比较多了，但是我几乎没有看见有人说过微服务同时也降低了系统自动化测试的成本。一个好的架构常常就是这样，它在实现自身架构意图的情况下也让别的方面变的更合理了。
点题
自动化运维也是近来比较火的概念，也处于发展飞快的阶段。而测试的全自动化却是被提及的比较少的。比较不火导致了推行上会遇到一些阻力，领导会问：为什么要做，能不能做，值不值得做，有没有成功的案例。下属会问：怎么做，有没有参照系统。
这里我基本描述了为什么要做，能不能做，值不值得做的问题，简单描述了一下怎么做的问题。限于篇幅，很多实现案例只能等有机会时再做介绍。
