开发与测试–制衡
在中国的文化中，制衡之道往往是诸多治国明君都必须掌握的策略，不论是太平盛世也好，车马乱世也罢，如果希望能够延续自己统治，管理好一个国家，一 座城池乃至一个村镇，都离不开制衡；其原因在于我们永远生活在矛盾之中，那么生存的守则就是要平衡这些矛盾，这就是制衡之道。纪晓岚诚然是好官，但是没有 和珅帮衬，很多事情乾隆也一样做不到。制衡之道中最关键的一点是如何能够引导矛盾双方的冲突为我所用，在总体上获得好的结果。
项目管理也是一样，不同角色之间的划分，往往就是希望形成最优化的分权制，以便在角色的冲突中将问题暴露，实现透明，最终改进和保证质量。任何的软 件开发团队都离不开两个基本角色：开发与测试。你可以没有项目经理，可以没有架构师，也可以没有设计师；但是不能没有开发，否则没有人可以帮你实现产品； 也不能没有测试，否则没有人可以决定你的产品是否能够交付。这就好像你往杯子里面倒水必须要用眼睛看着，没有眼睛反馈的信息，你永远不知道何时该停下来， 也不知道停在那里；我们不希望水太少，更不希望水溢出来。眼睛与手的反馈循环就是我们实现倒水这一动作高质量的必要系统，而开发和测试的有效循环就是我们 实现高质量软件的必须环节。
但是开发和测试本身的角色的局限性造成了他们往往没有办法有效地形成循环，比如我们经常会听到这样的抱怨：
- 测试：这个软件需要的环境太复杂，没有办法为每种情况都创建测试环境；
- 测试：我没有办法保证测试的一致性，因为环境在不停地变化，恢复到原来的状态很麻烦；
- 开发：你是怎么测出这个Bug的，我怎么没法重现？测试：我忘记步骤了。
其实这些问题都和测试人员本身的定位有关系，测试人员的首要目标是发现软件中的问题，要做到这一点他们往往专注于软件的反应而忽视了造成这种响应的 原因，如：硬件软件环境，系统配置情况，操作一致性等等；而这些正是开发人员修复Bug最需要的内容。但是测试人员不关心，或者没有更多的精力来关心这些 内容，造成了非常多的“不可重现”的Bug的出现。
借助微软的虚拟化技术平台和工具，配合Team Foundation Server所提供的测试和实验室管理器（Test and Lab Manager）功能，我们可以有效地协助测试人员来完成这些繁琐的数据收集工作，从而改善测试与开发的交互能力，实现无缝的反馈循环，最终达到提高质量 的目的。
测试环境
测试人员遇到的第一大难题就是环境的架设问题，没有统一的环境，再好的测试人员和再好的测试用例也测不出正确的结果；测试环境必须满足以下两个条件才算好的环境：
- 统一性：测试环境必须在不同测试迭代和不同测试人员之间保持统一，首先测试用例的设计应该是相互独立的，可以独立执行的，那么就需要每次 启动测试用例的运行之前，系统能维持在一个统一的状态才能保证每次测试结果的可比性；如果是团队开发，每个测试人员之间也同样要保证这样的可比性才能保证 测试本身的质量，也就是测试结果的可信度。
- 易用性：测试人员的工作核心永远是执行测试用例，验证产品的质量；为了能够专注于这个核心，必须降低测试环境搭建的成本，特别是重复搭建的成本，这样才能实现测试的高效率。
以上两个条件正是微软实验室管理平台所解决的首要问题：
图1：微软TFS实验室管理平台架构
实验室管理平台通过集成Team Foundation Server和Hyper-V虚拟化平台来实现，主要由以下3个模块组成：
- 测试用例管理模块：这部分主要通过测试管理器（Microsoft Test Manager）来完成需求导入，测试计划，测试用例设计以及测试环境的配置；其目的是实现应用生命周期管理中（ALM）的项目管理和测试管理的衔接。
- 虚拟机管理模块：这部分主要通过System CenterVirtual Machine Manager （SCVMM）来实现测试环境的搭建，以及状态快照和回复的能力。
- TFS生成管理模块：这部分主要是一个工作流引擎，通过Workflow Foundation 4.0的工作流引擎来驱动不同的操作；将以上模块所提供的内容（也就是软件产品本身）放入生产线进行生产，典型的流程包括：
- 从源代码管理器获取特定版本的代码
- 编译代码，构建版本进行打包
- 部署版本到测试环境
- 测试代理执行测试用例
- 恢复测试环境到基线状态
- 采集测试结果
- 对测试环境进行快照
- 部署版本到生产或者准生产环境
解决统一性问题
微软虚拟化平台的特点就是可以创建所需环境的模板，并根据模板自动复制环境。
图2：使用实验室管理器创建新的测试环境模板定义
图3：配置测试环境
图4：激活自动化部署和测试执行能力，并根据需要启用网络隔离能力
以上的测试自动执行能力和版本自动部署能力不言而喻，而对于测试最有意义的还是网络隔离能力。
网络隔离能力对于测试环境的统一性非常重要，如果有多名测试人员执行统一产品版本的测试，我们希望每个测试人员所使用的环境都是一样的，比如：服务 器IP地址，名称等等；但是这样的系统部署在同一网络中会造成冲突。通过网络隔离我们让多个测试人员在同样的测试环境的副本上同时执行测试。
自动化测试流程
敏捷开发中非常重要的一个工程方法就是持续集成，简单的理解就是自动化生成+自动化测试；普通的持续集成一般使用单元测试来作为自动化测试的单元， 所以不存在恢复测试环境的问题（因为单元测试本身应该具备隔离性和独立性）。但是如果我们希望将集成测试或者负载测试放入到持续集成中，那么环境的统一性 就变得非常重要了。
图5：在TFS生成中使用快照恢复测试环境到统一状态
图6：部署完成后，对测试环境创建快照，以便测试人员可以快速恢复某一版本的测试基线
通过以上两个操作，我们解决了将集成测试自动化中的主要问题，使得我们的持续集成可以突破单元测试的限制，扩展到集成测试。
图7：通过实验室管理器查看正在自动化运行的测试用例
消除不可重现的Bug
虚拟化平台可以帮助我们解决的另外一个问题就是消除不可重现Bug。由于测试环境和开发环境是隔离的独立环境，开发人员往往很难直接获得定位Bug 所需的数据和信息，而测试人员又很难保持自己的测试环境处于正确的状态以便开发人员可以使用。利用以上所提到的虚拟机快照技术，我们就可以将出现问题的测 试环境原封不动的发送给开发人员进行问题定位，最大化的解决了不可重现Bug的问题。
图8：测试人员使用快照将处于问题状态的环境发送给开发人员
下一步
实现了测试环境的完整流程自动化后，下一步就是将最新版本推送给生产环境，将持续集成推广成持续部署。这样做的好处是我们可以最快的获得用户反馈，以便改进我们开发迭代中的需求。
下图就是利用持续部署推送到生产环境的SSW公司官方网站。注意最下面一行小字，是由TFS的持续部署脚本自动生成的。这种持续部署的方式，再配合内部的虚拟化测试平台，就可以保证变更以最快的速度进入生产环境。
图9：SSW公司的网站使用持续部署进行快速部署，每次部署的间隔不超过24小时
总结
开发和测试的制衡之道就是通过工具使他们都可以专注于自己的核心价值，同时能以最少的额外投入给对方提供必要的信息；这样开发和测试可以在交互过程中消除摩擦，产生默契，加快迭代的速度；最终实现高质量的研发团队并递交高质量的产品。