我们不得不佩服冯诺依曼和早期的计算机科学家们，不只是因为计算机这个伟大产物的诞生和发展，更主要的是，这个行业中的任何分支都似乎有无尽的可能性，让一些大牛们终其一生去探究。当然，让我佩服的是，无论表现上多么的丰富，无论这一行业如何的变化和发展，它的原始方式却依旧没有变化，早已经被早期的计算机科学所限定（事实上不是限定，而是被证明为有效）。这像大多数程序员都知道的一个道理，技术的发展速度越快，对那些基本原理的理解越为重要。事实上不仅在技术上，即便是计算机和软件行业的管理上，依然遵循着这些计算机的科学的基本原理。这行业本身是实业，当然也是服务行业，没有行业背景，不尊重行业规则的管理，从严格的行业市场来说，是失败的——这里自然不包括我国国企和政府部门这种有足够预算保障的项目，当然也不包括如某些外包行业中的中国人擅长的“人”的管理。这里只是简单的从操作系统角度上讨论一下测试项目中和自动化测试中一些可以借鉴的地方。

　　早的测试其实和早的编程是一样的——不仅在出现的时间上，在力度和思维方式上也是一样的，因为它们本来是一个整体。计算机发展的早期，珍贵的是资源，并不像现在大部分的软件开发一样在堆积木。发明计算机的那段时期，几乎是不断测试不断调整的过程，和计算机科学的发展是一样的。事实上一个像模像样的操作系统基础代码几千行而已。甚至早期程序员在写代码前必须考虑的清清楚楚，简简单单的代码所带来任何效果和影响，都要理解透彻，着手写代码的时候，事实上测试的思路已经同时指定出来（早的测试驱动开发？呵呵）。当然那时候不该叫做开发，只能叫做编程，因为还没有达到可以工厂化生产的程度。当软件达到了可以工业化生产的程度，代码和工程的量级爆炸般的增长，质量参差不齐的从业人员不断增加，才不断的靠经验的积累，形成了所谓的项目管理。实际的工作中，这样的管理包括项目和人。当然，IT行业是服务行业（至少我一直这么认为），测试更是服务中的服务，也是说，测试的根本，还是在于对项目和人的管理和提供的服务。自动化是手段，并不是目的，不管自动化的地位多高，它的根本目的没有改变，测试是它的载体。绕到一开始提到的，测试和开发在计算机发展的一开始，是一个整体，现在来讲，也依然说的通，只是无论了开发还是测试，都因为工厂化的发展规模庞大，所以很多时候需要各自的管理或者“小组作战”。微软的测试投入力度很大，很多大公司的测试投入也很大，无论技术还是人员，但是有一些公司如facebook没有所谓的测试人员，只能说，概念上的质量保证以不同的方式和逻辑分布到了不同的地方，和项目管理一样，无论有再多抽象的模型和流程，事实上适合自己的测试管理，只有看自己的项目才能决定。

　　自动化的提出，也没有明确的时间界线，事实上跟“云”这个概念是一样的，几十年前有这样的思想，只是硬件的发展成了当代的云发展。每次硬件的发展都会带来软件的革命，窗口，鼠标，网络，移动，触屏，体感，这些不只促生了软件技术和管理发展，测试管理和自动化也同样与时俱进。刚入行的时候，总是认为向往一些很牛的东西，当时感觉ole和com这些已经是早的自动化，随着不断的沉淀，才了解到这些也都是发展的产物。如果让我现在说自动化的开始是什么时候，我的回答是刚发明计算机的时候。当然也许几年后我的答案也跟着发展，但是现在是这个。刚开始有计算机的时候，必须手工的将纸带装入，之后机器才能进行运行，但是处理器太珍贵了，不能让处理器等待手工的装入；另外，随着硬件的发展，机器运行效率提高，手工的装入耗时却没有改变，也意味着手工操作占的时间比率越来越高，机器等待的相对时间越来越多——所以才有了分工，才有了程序来管理“装入”，才有了程序管理任务作业，这些构成的整体，其实是操作系统。所以自动化，也是自动代替手工的过程，本身是操作系统的一个目的，也是为什么我认为自动化是在计算机发明的时候已经产生了。

　　测试的目的呢？它到底是一个什么样到角色呢？如果产品和项目的质量有标准，那是质量保证和评估（需求），如果质量没有标准，那是产品和项目发展的一种手段和必需到途径。软件所存在的问题，无论从设计上还是从开发上，大都来自三个地方，个人问题（个人开发和设计问题），人和人之间的问题（沟通和合作），环境问题（软件和所处环境）。我一开始提到的早期的程序员（很）和他们到思维方式，能解决这三个问题中第一个和第三个的大部分问题，第二个人和人的问题也能解决一部分——如果这样到话，那么是不是大多数的软件问题都可以通过程序员的工作解决呢？这是不现实的，因为工厂式生产中，有更多大前提，时间，预算，各种约束等，我们真正需要的，是在预算和时间到允许下，将产品交付和完成，测试和质量保证自然也要达标，而且产品的开发和测试并不是脱节的，相互约束并可以相互促进，因为本来没有严格到界限，分开只是某些时候更适合某种管理方式。所以这时候再说测试管理和自动化测试，思路相对清晰了：给定的时间和财力预算的情况下，给项目大程度的质量方面到支持，并尽可能验证和改进项目开发方式和以及流程——看起来好像把什么都占了，其实确实是这样，只是从质量和保证的角度而已。所以整体上来说，测试的价值并不在于创造，而是保证，优化和更新。至于自动化呢，当然它只是测试的一个子集（尽管如测试驱动开发和自动化架构方面会不同程度的深入到产品和项目中），自动化不是测试的目的，是测试的一种手段和途径。如果自动化没有在缩减预算（或者折中）的前提下提高软件的质量，那么自动化毫无意义，这样的折中在不同项目中权值不高，力度当然也不尽相同，一些武器系统或者航天系统中，不允许任何一点失误的出现，这种时候小于一定研发资金份额的测试投入都是允许的，因为一次失败意味着整个投入打了水漂；典型的大型超市中UNIX+oracle的系统，必须有容错的处理，不能因为小的插曲影响整体的运作，这也意味着允许出现预期内的错误，那么投入在这部分中的预算的必要性，没那么强了。这两种极端的方式，当然采用自动化去测试更为方便和合理，自动化适用的范围有多大？什么时候适用呢？

　　一般来说不同的公司情况不同，对测试和自动化的理解也都不相同，通常来说，自动化用在：

　　1、反复操作的相对稳定的系统或软件中（迭代、回归等）；

　　2、手工难以模拟的运行环境（压力、负载等）；

　　3、一些对高精度的测试结果或者手工难以获取的数据的测试（性能、评测等）。当然这里并不包括一些辅助工具和一些环境部署方面的自动化，因为它们并非针对产品质量的，但是却同样属于自动化的一部分。