操作系统角度谈测试管理和自动化测试
我们不得不佩服冯诺依曼和早期的计算机科学家们，不只是因为计算机这个伟大产物的诞生和发展，更主要的是，这个行业中的任何分支都似乎有无尽的可能性，让一些大牛们终其一生去探究。当然，最让我佩服的是，无论表现上多么的丰富，无论这一行业如何的变化和发展，它的原始方式却依旧没有变化，早已经被早期的计算机科学所限定（事实上不是限定，而是被证明最为有效）。这就像大多数程序员都知道的一个道理，技术的发展速度越快，对那些最基本原理的理解就越为重要。事实上不仅在技术上，即便是计算机和软件行业的管理上，依然遵循着这些计算机的科学的基本原理。这行业本身就是实业，当然也是服务行业，没有行业背景，不尊重行业规则的管理，从严格的行业市场来说，是失败的——这里自然不包括我国国企和政府部门这种有足够预算保障的项目，当然也不包括如某些外包行业中的中国人擅长的“人”的管理。这里只是简单的从操作系统角度上讨论一下测试项目中和自动化测试中一些可以借鉴的地方。
最早的测试其实和最早的编程是一样的——不仅在出现的时间上，在力度和思维方式上也是一样的，因为它们本来就是一个整体。计算机发展的早期，最珍贵的是资源，并不像现在大部分的软件开发一样在堆积木。发明计算机的那段时期，几乎就是不断测试不断调整的过程，和计算机科学的发展是一样的。事实上一个像模像样的操作系统基础代码几千行而已。甚至早期程序员在写代码前必须考虑的清清楚楚，简简单单的代码所带来任何效果和影响，都要理解透彻，着手写代码的时候，事实上测试的思路就已经同时指定出来（最早的测试驱动开发？呵呵）。当然那时候不该叫做开发，只能叫做编程，因为还没有达到可以工厂化生产的程度。当软件达到了可以工业化生产的程度，代码和工程的量级爆炸般的增长，质量参差不齐的从业人员不断增加，才不断的靠经验的积累，形成了所谓的项目管理。实际的工作中，这样的管理包括项目和人。当然，IT行业是服务行业（至少我一直这么认为），测试更是服务中的服务，也就是说，测试的根本，还是在于对项目和人的管理和提供的服务。自动化是手段，并不是目的，不管自动化的地位多高，它的根本目的没有改变，测试是它的载体。就绕到一开始提到的，测试和开发在计算机发展的一开始，就是一个整体，现在来讲，也依然说的通，只是无论了开发还是测试，都因为工厂化的发展规模庞大，所以很多时候需要各自的管理或者“小组作战”。微软的测试投入力度很大，很多大公司的测试投入也很大，无论技术还是人员，但是有一些公司如facebook没有所谓的测试人员，只能说，概念上的质量保证以不同的方式和逻辑分布到了不同的地方，和项目管理一样，无论有再多抽象的模型和流程，事实上最适合自己的测试管理，只有看自己的项目才能决定。
自动化的提出，也没有明确的时间界线，事实上就跟“云”这个概念是一样的，几十年前就有这样的思想，只是硬件的发展成就了当代的云发展。每次硬件的发展都会带来软件的革命，窗口，鼠标，网络，移动，触屏，体感，这些不只促生了软件技术和管理发展，测试管理和自动化也同样与时俱进。刚入行的时候，总是认为向往一些很牛的东西，当时感觉ole和com这些就已经是最早的自动化，随着不断的沉淀，才了解到这些也都是发展的产物。如果让我现在说自动化的开始是什么时候，我的回答就是刚发明计算机的时候。当然也许几年后我的答案也跟着发展，但是现在是这个。刚开始有计算机的时候，必须手工的将纸带装入，之后机器才能进行运行，但是处理器太珍贵了，不能让处理器等待手工的装入；另外，随着硬件的发展，机器运行效率提高，手工的装入耗时却没有改变，也就意味着手工操作占的时间比率越来越高，机器等待的相对时间越来越多——所以才有了分工，才有了程序来管理“装入”，才有了程序管理任务作业，这些构成的整体，其实就是操作系统。所以自动化，也就是自动代替手工的过程，本身就是操作系统的一个目的，也就是为什么我认为自动化是在计算机发明的时候就已经产生了。
测试的目的呢？它到底是一个什么样到角色呢？如果产品和项目的质量有标准，那就是质量保证和评估（需求），如果质量没有标准，那就是产品和项目发展的一种手段和必需到途径。软件所存在的问题，无论从设计上还是从开发上，大都来自三个地方，个人问题（个人开发和设计问题），人和人之间的问题（沟通和合作），环境问题（软件和所处环境）。我一开始提到的早期的程序员（很优秀）和他们到思维方式，能解决这三个问题中第一个和第三个的大部分问题，第二个人和人的问题也能解决一部分——如果这样到话，那么是不是大多数的软件问题都可以通过优秀程序员的工作解决呢？这是不现实的，因为工厂式生产中，有更多大前提，时间，预算，各种约束等，我们真正需要的，是在预算和时间到允许下，将产品交付和完成，测试和质量保证自然也要达标，而且产品的开发和测试并不是脱节的，相互约束并可以相互促进，因为本来就没有严格到界限，分开只是某些时候更适合某种管理方式。所以这时候再说测试管理和自动化测试，思路相对就清晰了：给定的时间和财力预算的情况下，给项目最大程度的质量方面到支持，并尽可能验证和改进项目开发方式和以及流程——看起来好像把什么都占了，其实确实是这样，只是从质量和保证的角度而已。所以整体上来说，测试的价值并不在于创造，而是保证，优化和更新。至于自动化呢，当然它只是测试的一个子集（尽管如测试驱动开发和自动化架构方面会不同程度的深入到产品和项目中），自动化不是测试的目的，是测试的一种手段和途径。如果自动化没有在缩减预算（或者折中）的前提下提高软件的质量，那么自动化就毫无意义，这样的折中在不同项目中权值不高，力度当然也不尽相同，一些武器系统或者航天系统中，不允许任何一点失误的出现，这种时候小于一定研发资金份额的测试投入都是允许的，因为一次失败就意味着整个投入打了水漂；典型的大型超市中UNIX+oracle的系统，必须有容错的处理，不能因为小的插曲影响整体的运作，这也就意味着允许出现预期内的错误，那么投入在这部分中的预算的必要性，就没那么强了。这两种极端的方式，当然采用自动化去测试更为方便和合理，自动化适用的范围有多大？什么时候适用呢？
一般来说不同的公司情况不同，对测试和自动化的理解也都不相同，通常来说，自动化用在：1.反复操作的相对稳定的系统或软件中（迭代、回归等）；2.手工难以模拟的运行环境（压力、负载等）；3.一些对高精度的测试结果或者手工难以获取的数据的测试（性能、评测等）。当然这里并不包括一些辅助工具和一些环境部署方面的自动化，因为它们并非针对产品质量的，但是却同样属于自动化的一部分。
事实上，测试的范畴是完全由产品决定的，自动化也是在其中尽其所用。不同的产品和项目测试的范围大都不同，但是大概的思路都差不多——由大而小。这和自动化不同，自动化必须找到突破点走通一条路才能实施。抛开流程不说，范围一般这样去界定：先将产品去进行定位，然后按不同的类别去划分，之后每一个划分都添加对各自的测试约束，比如我现在要制作一款主题浏览器，暂时只有windows版本，支持xp和其之后的所有系统。首先说它是一个windows上的软件，那么就要有安装卸载和升级，性能方面要有各项性能指标的测试（GDI,CPU内存占用，句柄等）和压力测试，内存泄露；作为浏览器，它要实现的自己的功能，这些功能太多需要细化这里不讨论；当然浏览器是JS的宿主环境，对JS的支持也要去测试（流行的HTML5也越来越多的被测试）；用户会使用浏览器进行各种登陆，所以安全性很重要，安全测试上除了用户的个人信息外，一些敏感数据也是重点；有了用户的数据，就需要测试容错和健壮性，崩溃后对用户的数据恢复等；由于支持多个windows平台，所以平台兼容性也是重点；现在的浏览器与一些硬件关系密切，需要测试对硬件的兼容和支持，比如GPU加速，无线网卡，摄像头等（可能会涉及到不同品牌设备）；由于浏览器涉及到安全性，所以需要测试对现有的安全产品的兼容性，比如某山，某斯基，某星，太多某；另外，浏览器产品太多，必须对其进行同类产品的兼容性检测——至少IE系列和其他主流浏览器都要测试；如果浏览器打算提供部分接口供外部网站开发人员进行网站测试，这部分接口开放之前也要进行测试（ms的com，chrome的driver等）；当然还有对操作系统的影响，windows系统很多时候会被一些软件干的千疮百孔，即使我们的软件不做同样的行为，至少需要自行的检测或者修复；其他灰色地带测试等等。所有的这些都是这款软件需要做的测试。这时候的自动化呢，也要进行分而治之，因为并不会有一个大的统一测试架构，每一个范畴都可能要进行小范围的突击。
怎么去执行测试管理和自动化测试，同样也可以从操作系统方面得到一起启发。同样，早期的计算机在使用时，需要使用者将自己的纸带装入，越来越多的人开始使用计算机，使得纸带装入和熟悉计算机的花销加大，结果就是在硬件没有提升的前提下，产生了分工——专门有人负责纸带的装入，使用者只需要将纸带交到他手里就可以了，继而有了所谓的流程——不同分工并且有交互，各自负责相关的部分，这时候负责纸带装入的人，发现了把所有的纸带做成纸带卷，可以减少装入的次数提交自己的工作效率，负责写程序的，专注于写出更好的程序来，简单的团队协同工作开始形成。
软件测试管理，很大程度上，是处理好团队协作的事情。将测试目标分而治之，流程化到每一个小组，团队间协同工作，不同的人扑在精通的位置上，组内相互可以做到部分backup，这样就是一个较为理想的团队。每个人都是一个线程，每个小组就是一个任务，避免异步产生的锁定，提高资源共享的高效性，才能尽可能发挥团队的战斗力。
团队合作中，沟通很重要。一个小小的改变，可能会影响到组内的每一个人。无论一个技术水平很高的高级SDET，还是指执行手工用例的tester，都避免不了对组织的依赖。那么一个团队如何去做决策？反过来，依赖于每一个人。个人的想法直接快速，但是片面容易引发问题；开会投票表决会浪费很多时间，效果也不明显。这时候，除了leader外，团队也需要一个具有测试“架构”决策能力的骨干，做到折中和适当的舍去。有时候我们需要让组内每个人都尝试决策组内的一些事情，慢慢提高大家的整体能力，这和学习技术是一样的。当然免不了一些领导不愿意看到手下人的决策能力变强，一些人也不愿意跟自己同一组的人的能力超过自己，创造合理竞争的气氛和“每个人都是经理”的制度可以在某些程度上缓解这种情况，当然，组员们不能只对工作进行抱怨，当抱怨的同时尽可能拿出自己的建议和可行性的计划，工作上的事情公开，将负面影响降到最低。
一些项目的规模，可能达到千人年的庞大，但是每个组的规模却不宜过大，5个人左右为最佳，避免预定会议的麻烦，尽可能减小每个人风格不同带来的影响，而且4、5个人的工作环境，是最佳的——大部分软件工作者在4个人的时候，会最自然的专注到自己的工作上，交谈的情况最少（很奇怪，但是研究是这样的），气氛也相对轻松。