事实上，测试的范畴是完全由产品决定的，自动化也是在其中尽其所用。不同的产品和项目测试的范围大都不同，但是大概的思路都差不多——由大而小。这和自动化不同，自动化必须找到突破点走通一条路才能实施。抛开流程不说，范围一般这样去界定：先将产品去进行定位，然后按不同的类别去划分，之后每一个划分都添加对各自的测试约束，比如我现在要制作一款主题浏览器，暂时只有windows版本，支持xp和其之后的所有系统。首先说它是一个windows上的软件，那么就要有安装卸载和升级，性能方面要有各项性能指标的测试（GDI，CPU内存占用，句柄等）和压力测试，内存泄露；作为浏览器，它要实现的自己的功能，这些功能太多需要细化这里不讨论；当然浏览器是JS的宿主环境，对JS的支持也要去测试（流行的HTML5也越来越多的被测试）；用户会使用浏览器进行各种登陆，所以安全性很重要，安全测试上除了用户的个人信息外，一些敏感数据也是重点；有了用户的数据，就需要测试容错和健壮性，崩溃后对用户的数据恢复等；由于支持多个windows平台，所以平台兼容性也是重点；现在的浏览器与一些硬件关系密切，需要测试对硬件的兼容和支持，比如GPU加速，无线网卡，摄像头等（可能会涉及到不同品牌设备）；由于浏览器涉及到安全性，所以需要测试对现有的安全产品的兼容性，比如某山，某斯基，某星，太多某；另外，浏览器产品太多，必须对其进行同类产品的兼容性检测——至少IE系列和其他主流浏览器都要测试；如果浏览器打算提供部分接口供外部网站开发人员进行网站测试，这部分接口开放之前也要进行测试（ms的com，chrome的driver等）；当然还有对操作系统的影响，windows系统很多时候会被一些软件干的千疮百孔，即使我们的软件不做同样的行为，至少需要自行的检测或者修复；其他灰色地带测试等等。所有的这些都是这款软件需要做的测试。这时候的自动化呢，也要进行分而治之，因为并不会有一个大的统一测试架构，每一个范畴都可能要进行小范围的突击。

　　怎么去执行测试管理和自动化测试，同样也可以从操作系统方面得到一起启发。同样，早期的计算机在使用时，需要使用者将自己的纸带装入，越来越多的人开始使用计算机，使得纸带装入和熟悉计算机的花销加大，结果就是在硬件没有提升的前提下，产生了分工——专门有人负责纸带的装入，使用者只需要将纸带交到他手里就可以了，继而有了所谓的流程——不同分工并且有交互，各自负责相关的部分，这时候负责纸带装入的人，发现了把所有的纸带做成纸带卷，可以减少装入的次数提交自己的工作效率，负责写程序的，专注于写出更好的程序来，简单的团队协同工作开始形成。

　　软件测试管理，很大程度上，是处理好团队协作的事情。将测试目标分而治之，流程化到每一个小组，团队间协同工作，不同的人扑在精通的位置上，组内相互可以做到部分backup，这样就是一个较为理想的团队。每个人都是一个线程，每个小组就是一个任务，避免异步产生的锁定，提高资源共享的高效性，才能尽可能发挥团队的战斗力。

　　团队合作中，沟通很重要。一个小小的改变，可能会影响到组内的每一个人。无论一个技术水平很高的高级SDET，还是指执行手工用例的tester，都避免不了对组织的依赖。那么一个团队如何去做决策？反过来，依赖于每一个人。个人的想法直接快速，但是片面容易引发问题；开会投票表决会浪费很多时间，效果也不明显。这时候，除了leader外，团队也需要一个具有测试“架构”决策能力的骨干，做到折中和适当的舍去。有时候我们需要让组内每个人都尝试决策组内的一些事情，慢慢提高大家的整体能力，这和学习技术是一样的。当然免不了一些领导不愿意看到手下人的决策能力变强，一些人也不愿意跟自己同一组的人的能力超过自己，创造合理竞争的气氛和“每个人都是经理”的制度可以在某些程度上缓解这种情况，当然，组员们不能只对工作进行抱怨，当抱怨的同时尽可能拿出自己的建议和可行性的计划，工作上的事情公开，将负面影响降到最低。

　　一些项目的规模，可能达到千人年的庞大，但是每个组的规模却不宜过大，5个人左右为最佳，避免预定会议的麻烦，尽可能减小每个人风格不同带来的影响，而且4、5个人的工作环境，是最佳的——大部分软件工作者在4个人的时候，会最自然的专注到自己的工作上，交谈的情况最少（很奇怪，但是研究是这样的），气氛也相对轻松。

　　如果参与过操作系统的开发，会了解到有两点容易被忽略却极为重要的元素，其中之一也就是我一开始提到过的，尽早的设计全面，在测试中也就是我们常说的尽早测试——当然如果都能像早期程序员一样开始敲代码前大脑里已经将测试逻辑包含进去，那么所谓的测试驱动就是一个说法而已了；另一个就是日志，不管是日志系统，还是简单的调试信息，日志都是不可或缺的，调试的工作量的庞大是很多人不敢想象的，甚至微软一度为一个开发配两个测试，日志这样的机制，在测试管理中，其实是另一个关键的元素和成功的条件，那就是文档。还记得刚进这一行的时候，被问最多的就是文档看的怎么样了，文档写的如何。在测试组干几年，也许你没有见过同事什么样子，也没有听过同事的声音，甚至代码也没有见过，但是文档，是肯定见过的。在测试管理中，文档比用例的重要性要高——他们的区别相当于设计书和产品的区别。哪些需要文档化？操作系统日志中，一般包含系统日志，应用程序日志等等，测试管理的文档化中，依然是要看项目的具体情况，总的来说有一些东西是必须要文档化的，它们有产品说明，产品设计架构，产品测试概况，测试组织结构，测试在不同阶段的测试计划和重点，测试执行约定，各种报告模板，一些特殊测试的内容列表（如兼容性，安全性等），自动化设计架构，自动化接口文档，产品测试流程，用例规范，灰色地带列表等。

　　基本上操作系统在测试上给予的提示都是零零散散的，并没有统一的整体，这也难怪，本来操作系统的发展就是一点一滴来的，只有构建在系统之上的软件和系统，才可以一次就把架构考虑清楚，因为已经站立在巨人之上了。

　　下面还有一些测试管理中的杂项问题，虽然不是主旨，也都可以有些参考。第一个就是自动化测试如何去构建和实施。这里当然不会具体的讨论到某个技术或者某一个产品和系统，只是讨论一些误区和正常的思路。一般所谓的自动化测试架构，是用来解决自动化测试问题的，所以存在一个适用的情况。不管高级的SDET去写，还是开发去写，还是用现成的工具和破解的自动化软件，原则也都只有一个——适用。适用的条件是啥？可行，可操作，够预算。一种自动化方法只有可以解决测试的问题，可以稳定操作，并且在预算之内，才有条件作为适用的方法，选择所有适用的方法，并将其扩展成一个自动化测试架构。和操作系统一样，自动化架构通常包括了操作驱动部分，验证部分，调度部分，日志部分，报告部分，用例开发部分，用例解析部分，其中最难的就是操作驱动和验证部分，也就是适用条件中的“可行”。大部分项目或者产品，自动化的门槛就是找不到“可行”的地方，失去这个突破口，自动化架构中的其他部分也就没有什么存在的意义。“可行”就相当于计算机硬件中的指令，是软硬件的桥梁，没有这个指令，软件就没办法驱动硬件进行工作。实际的测试工作中，一般这个入口可以通过开发时预留接口、开发相关代理、开发配套工具等方法实现——当然指的是那些为了提高某种体验而放弃外部测试接口的项目，通常的项目界面上是标准接口，那么自然不存在“可行”的问题，固定好逻辑就可以很快搭建一套自动化的测试架构；代码的测试相对来说可行的纠结程度并没有那么高，因为大部分都可以通过技术手段解决，单元测试也好，接口测试也好，还是覆盖率测试也好，都有很多可选的已有工具，只要对语言特征很了解，对代码逻辑够熟悉，代码的测试就相对好执行一些，一些专门的白盒测试公司，大多数也是采取模板匹配的方法，相信深谙编译原理的大牛们，肯定对这些不屑一顾。性能测试一般以自动化为主，可能主流的工具用的会相对多一些，某些方面有时候也需要自己去指定，“可行”度一般较高。