首先，我们回顾一下软件测试的定义，

1979年Fred Mayer发布的测试经典 《软件测试的艺术》(The art of software testing )，它将软件测试定义为“带着发现错误的目的，执行被测软件”，简单的说就是通常人说的：软件测试就是找缺陷，找Bug。

1995年Stephen H.Hank 写过一本书(《软件质量工程的度量和模型》) metrics and models in software quality engineering，它用工程的方法引入软件质量度量和软件质量周期的管理，质量度量包括代码覆盖率，测试用例的覆盖率和执行情况，用户满意程度，运维的质量管理等等。

2007年 微软的几个资深测试人员写了一本书"The Practical Guide to Defect Prevention "(《质量缺陷预防实践指南》 讲的就是如何通过在软件过程，方法和技术上，预防软件缺陷的产生。

2008年 喜欢数据说话的Caper Jones 推出了 "Global Analysis of Productivity and Quality"《全面分析生产率和质量》, 从经济学，软件流程等的方面分析了生产率和软件质量之间的关系，其中也包括一些好的实践。

然后，我们再看一看软件公司的变化

微软：比尔 盖茨说过 “微软是一个测试公司”，可以说微软是非常重视软件测试的，在有些团队，软件测试人员数量超过开发人员。在光盘发布软件的时代，修复Bug的成本是非常高的。随着，Internet 应用的发展，应用软件有了更加快速的发布周期，服务器端修复Bug成本降低了很多，同时通过引入Testing In Production。微软也在引入一些变化，微软的开发人员有更多的责任，进行质量保证，包括单元测试，产品中缺陷的支持等，软件测试人员更加注重E2E的测试，测试框架，提高整个软件的开发效率等。

谷歌：谷歌的开发和测试人员的比例是10:1，同时测试人员属于Productivity的部门，测试团队大部分是由丰富经验的测试人员，能够在新项目刚开始的时候，帮助建立测试框架，将其他项目好的测试经验带到这个项目中，项目执行起来以后，开发人员来编写，执行测试用例，并且对产品的缺陷直接负责。

动物学家达尔文说过 ”世界上进化下来的动物，并不是那些最强大的动物，也不是那些最聪明的动物，而是那些最能够适应变化(Responsive to change)的动物”，例如说老鼠，人，蚂蚁等等。软件系统也一样，能够传承发扬的软件，能够快速适应变化化。

TiP的核心思想就是通过在生产环境里面测试，最小化产品风险，加快发布节奏。TiP通过暴露新代码给有限用户，减少缺陷可能带来的负面影响，通过在产品中暴露这些新代码，可以快速获得这些新代码的反馈，这些反馈来之于真实的用户，而不是少量的测试人员和有限的测试用例。另外，一旦发现新代码有严重的缺陷，那么TiP需要快速修复这些缺陷，通过发布新版本或则滚回到老版本。

那么这是不是对软件质量的一种妥协呢？ 我觉得不是，相反在生产环境中测试可以更好的满足用户,它是传统发布前测试的一个积极的补充。例如，TiP可以帮我们提高测试覆盖率，找到一些平时无法测试到的场景。

我相信，所有的互联网软件都需要支持TiP，这是互联网软件的特性决定的：灵活的软件架构，快速的发布周期。

考虑一下几个问题可以帮助我们思考什么类型的软件最适合TiP方法。

• 用户体验和经济利益影响的程度
• 如果产品有问题，是否有能力快速检查产品中的问题，并且快速回退到没有问题的版本？
• 软件发布的频率?
• 进行TiP 所带来的成本和收益

这里有几个TiP的例子

1) 微软：在互联网的产品开发过程中，微软也大量利用了TiP的方法

a. 很多用户场景的改进，都是通过A/B测试获得最好的效果

b. 算法实验，在灵活的平台中进行算法的调优和筛选

2) Facebook : Facebook如何发布代码的 Link

a. Facebook有多个级别的代码部署 (内部的，少量外部的，全部外部的等等..),

b. 如果有问题出现，工程师马上修复问题；然后重新发布

c. Ops负责部署的实际过程，包括检测产品的健康状态（错误日志，CPU，内存，甚至包括用户的行为变化等）

3) Google： 非常善于做A/B测试

a. 谷歌在算法改进方面，就是利用在产品中的实验平台。一个搜索结果中可能包括多个算法的结果，另外不同的搜索可能触发不同的算法。最后通过用户的反馈，对算法进行评价和挑选。

一些参考资料：

人物：
Seth Eliot 微软测试经理，Testing in Production的倡导者 Blog

参考文章:

1) Testing in Production, Your key to Engaging Customers, Seth Eliot （QASIG 2011 论文：Link

2) Why testing in production is a common and costly technical malpractice （IBM Mahesh Rathi, Link）
我总结一下他的主要观点，详细的请看Link:

1） 需要一个专用的测试环境进行测试，并且尽量模拟产品环境，否则容易引起产品的灾难性

2） 在生产环境中测试的复杂性和不可控性

3） 注意：他所谈的更多的传统的软件企业(ERP,MIS)，并非真正的需要快节奏的互联网企业。

1) *.VSmdi中的所有测试用例需要手工加入到列表
2）如果多人需要访问测试列表文件，其管理会变得很不方便

VS2010出来了，它通过测试分类（Test Category)，很好的解决了这个问题。其原理也很简单，通过给每个测试用例，可以设置不同的标签，在运行用例时，可以通过过滤标签的属性来运行。其方法如下：

步骤一:

为每个测试用例设置测试分类属性（Test Category），在方法的属性中增加。

[TestCategory("Nightly"), TestCategory("Weekly"), TestMethod()]
public void TestMethod1()
{
    //
    // TODO: Add test logic here
    //
}

步骤二:

通过测试分类，运行测试用例

1)从UI中，选择测试用例运行

2)通过命令行运行

mstest /testcontainer:MyTestprojectName.dll /category:"Nightly&Weekly"

在条件选择时候，可以使用&或则|作为操作条件；但是在VS2010中，只能用一种操作符号

VS2010是一个集成的开发环境(IDE)，大部分的操作都能通过界面的操作完成，通常你不需要了解文件的细节。但是读懂这些文件，能帮助你更好的理解整个测试框架，以便使用一些高级的测试功能和做一些自定义的扩展。

首先我们来看看一个典型的解决方案，通常放啊

在这个解决方案里面，我们有以下一些重要的文件和项目：

1）应用程序项目（被测试的应用，开发人员负责）

2）测试项目（测试人员负责）

3)*.testsettings文件；
在VS 2010中，自动产生两个，一个是TraceAndTestImpact.testsettings用于调试的测试设置，另外一个本地缺省的测试设置。VS2008只有本地缺省设置。

多说两句*.testsettings，这是运行测试的环境参数和运行参数，包括以下内容：
a) 用例运行前后执行的脚本
b) 是否启用数据分析（代码覆盖率，测试影响分析，模拟网络，录制视频，智能跟踪等等）很多功能都是VS2010独有的，
c) 运行机器是本机还是远程机器
d) 测试超时时间等

 
VS2010 增强了测试监控功能，例如智能跟踪(IntelliTrace)和视频录制（Video Recoder)，测试影响分析(Test Impact)等等

4）*.vsmdi文件，用于管理测试用例的列表(Test List).
*.vsmdi文件是管理Test List的，在VS 2010中虽然支持，但是不推荐使用了。主要原因是*.vsmdi非常不灵活，很难集中维护。取而代之的是更加自然的测试分类（Test Category)：通过给每个测试用例设置标签，运行的时候通过标签选择需要运行的测试用例。

为了兼容问题，VS2010 还是支持*.vsmdi。下面是*.vsmdi的一些基本格式。

其内容基本上包括一个树状内容的Test List 列表，各个节点通过ParentListID相连，其中包括一个特殊根节点。另外，在每个TestList中，一个TestLink代表一个测试用例，TestLink的ID是通过测试方法名，测试类名和包名等，通过MD5计算而得(而非任意值），我以前就写过一个程序，自动生成*.vsmdi文件。

运行测试

写好测试用例就可以运行，Ctrl F5,就这么简单，能够得到测试用例运行的结果。很容易在IDE看到，测试结果，那么如何读懂后面的文件呢？

一次测试运行结果的目录：

我们一步一步来解释。重要的文件有*.trx文件.

在多说两句，运行结果目录。其中有In, Out 和每个TestCase的详细结果。

虚拟化技术很早就提出来了，但是真正走向市场是从2005年以后，那时候AMD和Intel公司都开始推出支持虚拟化技术的CPU。简单的说，虚拟机就像一个软件容器，可以安装操作系统和应用软件，像一台物理机一样运行，其有如下特点。

• 操作系统和软件无法辨别其主机是否是虚拟机。
• 多台虚拟机器像应用程序一样可以运行在主机上

2) 虚拟化技术的优势

2.1) 提高硬件的利用率

      根据调查数据，通常测试实验室的硬件的使用率是很低的，平均只有10%，通过虚拟化技术可以使利用率提高到80%。

* IDC 的数据中心趋势调查，2007 年。

 2.2) 低碳生活
降低数据中心的成本（省电/空间），能源成本降低 80%。大部分机器5-15%时间处于使用状态，而空闲状态耗电量为满负荷60%以上。

 2.3) 高管理性

通过虚拟化技术，计算机的管理（虚拟机）的管理变得更加简单，创建、修改一个计算机的操作可以瞬间内完成。这种高管理型有助于推动基础设施服务化（Infrastructure as Service）的发展。目前，有很多云计算的基础设施都是大规模使用了虚拟技术。

大家可能对SaaS都比较熟悉，这里我解释一下IaaS和PaaS。
基础设施作为服务（IaaS):计算机资源通过服务的方式提供出来，包括处理能力，存储和网络能力等等。

平台作为服务(PaaS):平台和工具能通过平台或API方式提供出来，提供更加高层次服务，例如数据库存储服务，J2EE服务，.NET平台等。

3. 虚拟化给软件测试带来的好处

通过虚拟化技术，软件测试可以获得很多好处，以下就是一些例子；

3.1）测试实验室(Test Lab)的建立

• 空间
• 时间
• 电力

如图所示的一个例子:168 台式机，被12个服务器主机代替。省空间，省电，方便管理，大大降低了测试实验室建设的成本。

大部分的测试环境对测试机器的性能要求都不是很高（性能测试除外），那么对于这种情况，虚拟机是非常适合的解决方案。虚拟机可以用于测试实验室(Test Lab)的构建，支持自动化测试，也可以为远程的测试和开发人员提供机器服务。

举例来说，一个网站的测试，需要10个手工测试人员进行，那么我们可以创建10个虚拟计算机，那么只需要１－２个主机就行了，并且支持远程工作，那么这些手工测试人员可以在家里进行工作。

3.2) 软件快速部署和连续集成

虚拟机的管理是非常方便，这大大促进了快速部署（Fast Deployment)和连续集成(Continual Integration)。举例来说，在连续集成的时候，往往需要大量机器，并且快速恢复到某个系统的初始状态。虚拟化技术的高管理性能够很好满足这些需求，同时成本比物理机器要低很多。

3.3）测试用例失败后的调查
在测试用例失败后，通过保存机器状态，可以方便问题的调查。如果使用物理机器，这些机器就需要被占用，一直到问题调查完毕。而且，调查的状态具有不可恢复性。如果使用虚拟化技术，计算机状态可以被保持到到文件；在需要调查问题时，随时可以把虚拟机文件恢复到虚拟机进行调查；同时机器的状态可以随时保存，随时恢复，这给一些不容易重现的问题提供了有利的调查方法。

3.4）虚拟硬件的使用
虚拟化不仅仅可以模拟软件，也可以模拟硬件，包括网卡，光驱，USB接口等等。特别是USB接口的虚拟化，使得在很多USB设备驱动的测试提供了便利。另外一个例子是虚拟光驱，Vista开发出来后，安装以前的方法要制作DVD光盘来进行最后的验证。按照传统的做法，需要180张DVD光盘，需要花2个星期。而使用虚拟化解决方案，制作ISO 映像，只需要2天时间。

4 虚拟化过程中一些好的实践

4.1 仔细设计网络拓扑结构
  对于一些对网络特别要求的实验室，需要仔细设计网络Top结构，特别是IP地址的数量

4.2 选购主机，注意扩展性
主机的选购需要考虑内存的扩展能力，内存大小很容易成为增加虚拟机的一个瓶颈。当机器映像很多的时候，磁盘空间也容易出现紧张。网络速度也是需要考虑。

4.3) 仔细考虑一些特殊需求的测试
a) USB/驱动 b) 3D效果  c)能源管理 d)性能测试结果的分析应该考虑到虚拟的使用的范围和局限性。

4.4) 自动保持闲置的虚拟机
实验室中有长期不用的虚拟机，可以定时自动保存起来，需要时以后可以再恢复。这样可以提高系统的效率，降低能耗。保存和恢复机器都是需要时间的，其性能和网络的存储位置有很大关系。

总结，虚拟化作为一个重要的技术，不仅仅可以节省成本，而且可以帮助我们保护蓝天，何乐而不为呢？

中国古代很多聪明的人都是天文学家，他们有祖冲之，沈括，郭守敬等等，因为天文是一门魅惑的学科，蕴含着无数的简单的和复杂的规律。天文历法是天文学家可以直接将研究结果贡献社会的最好方式。让我们看看这些天文学家和他们的历法，最后总结一些其中关于测试的思考。

祖冲之，南北朝人，大家都知道他是著名数学家，将圆周率精确到小数点后7位，他的精度在1000年以后才有人打破。其实，他也是一位卓越的天文学家，他创建了《大明历》，将一年的精度误差缩小到50秒之内，并且在日历中引入岁差方法，大明历是历史上第二次历法改革。另外，据说指南车也是祖冲之发明的。

祖冲之

北宋的沈括是中国古代最博学的科学家，他”博学善文“，不仅仅文科很好（他是北宋的进士），而且他所著作的《梦溪笔谈》涉及到天文，数学，水利，生物，农学，医学等等。在天文方面，他积极推行平民出生的天文学家卫朴的《奉元历》（已经失传），据说此新历比旧历有很多的创新，而且对人民日常生活也一定的影响。，新历法只推行了18年，就因为反对派的阻挠而失败了。在梦溪笔谈中，沈括还提出了一个新历法，其内容和现在的阳历基本一样，一年分为12个月，每月30天或者31天，总共是366天，一年分为三季，孟，仲和季。另外他还是设备专家，对当时复杂的浑天仪做了改进，简化了其结构，提高了设备的可用性。

博学善文的沈括

另外一个是我非常敬佩的郭守敬，他是元朝天文学家，数学家和水利学家。北京的通惠河就是郭守敬主持修建的，现在还在造福北京的通州人民。他最大成就在天文学上，他制定了《授时历》，该历法定义的年与现代科学计算出来的年只相差26秒，是当时世界上最精确的历法。在修订新历法的4年过程中，他在全国东西南北建立了27个观测站，通过坚持不断的观察，终于制作出高水平的《授时历》。同时，他还根据《授时历》，执行了中国第四次天文历法改革，并且使得该历法沿用至以后700多年，现在所说的农历基本上就是《授时历》的延续。

郭守敬纪念馆，北京

话说这三人推行的天文历法改革，两次次成功，一次失败，这是为什么呢？我感觉新历失败的原因可能是”用户体验不好“，给人们生活带来太多的变化和冲击。另外，尝试穿越一下，如果你是这三种历法的测试人员，你会不会考虑如下的问题？

１）如何确保天文历法的精确性？ 有些预测的数据，需要很多年，甚至数百年才能预测，如何验证新历法的准确性？

2）如何确保新历法对农业生产没有负面的影响？人们是否愿意接受新历法？ 虽然，我们可以在小范围内做些调研，但是人们实际上无法预测一个社会现象真正带来的社会影响。

VS 2010是微软即将推出的最新开发工具套件，全球的正式发布时间将定于4月12日。在过去半年内，本人一直使用VS 2010，从Beta 1到Beta2，以及现在使用的RC版本，可以说是陪着VS 2010一起孕育，同时期待着它的正式发布。可以非常肯定的说，VS 2010对软件测试的支持力度，远远超过以前的任何VS 版本，并且在很多方面有革命性的改变。同时，作为一个集成的产品，对软件开发周期有了非常完整的支持。下面，我就从一个测试人员的角度，看看它提供了哪些实用的功能。

1）VS 2010的基本信息

VS 2010 主要分为3个版本，Professional版本，Premium版本和Ultimate版本。 Professional对于测试的支持非常有限，Premium支持除了性能测试之外的各种测试，Ultimate版本是一个全集。详细版本信息,请看这里.这里有个图可以做参考。

2）Coded UI Test(可编程的界面测试)
它提供了QTP或WinRunner类似的功能。支持录制和回放功能来创建测试用例，内建软件对象模型(Object Modeling)，录制的脚本可以为不同的.NET语言，例如VB,C#等。以下是简单的支持应用列表。

对象管理：提供了树状结构的对象管理，每个对象有很多属性可以配置，用于查找对象和验证对象。功能很强大。

3)  机房管理(VS Lab Management Team) (工作组连接)

VS 内置的机房管理软件，可以管理物理机器也可以通过SCVM管理虚拟机。主要功能包括：
a) 创建和管理物理机器或虚拟机
b) 创建和恢复测试环境，支持快速保持和恢复环境快照(snapshot)，方便Bug调试和重现。
c) 将机器表示为不同的测试环境，例如“开发环境”，“系统集成环境”，“性能测试环境”等等，在管理机器时，可以通过环境的力度管理机器，例如恢复初始状态，创建环境快照等。

快照例子:

4) 增强版本的负载测试(Load Test)

Load Test可以用于性能测试(Performance Testing)和压力测试(Stress Testing)，此功能仅仅包括在VS 2010 Ultimate 版本中。以下是一些主要功能，包括一些新功能。

测试模式图例: 支持不同的测试模式。

1）公司的文化(Company Culture)

每个公司都有自己的文化，公司通常喜欢利用自己以往成功经验，来指导新项目的开发。例如，一个公司以前是按照3：1的比例进行配置，产品获得成功了，那么他们在下一版本，或则其他产品，也容易按照这个比例进行。因为，大家习惯了这种比例，包括测试人员和开发人员，这些员工习惯了在这种比例下的进行工作分工，当这种比例有重大变化的时候，在初期，开发和测试人员往往会不知所措，不知道如何界他们的工作责任。在微软，开发测试比例通常在1:1~ 3：1左右（Link)，而在很多互联网公司，在创业的时候通常没有专职的测试人员，在公司成功之后，也会演习这种很高的开发测试比例，例如Google这种比例会达到7:1，甚至更高。

2) 软件产品性质和市场需求(Business Needs)

软件产品的性质也影响着这个比例。对于企业计费软件，工程控制软件，这些对于产品质量有严格的要求，测试人员比会多一些。对于一些UI集中的软件，比如网络游戏，测试人员的数量也相对较多。有些互联网企业，为了快速提供新功能，而开发一些对于一些原型性质的功能，有时候会标志为Beta，通常这些项目的测试人员通常较少。

3) 开发、测试团队的组成(Team)

在一个项目中，开发和测试人员的经验也会影响着比例的安排。总体来说，软件测试为了达到所需要的质量，需要做一系列的工作任务，有些任务需要开发人员做（例如设计和代码编写），有些需要测试人员做(例如测试计划），除了这些需要较多专业的背景的任务外，其他的很多任务(例如测试用例的实现，测试工具的编写..)实际上既可以由测试人员做，也可以由开发人员做。这种灵活的任务分配往往需要开发团队有较强的开发经验，否则会影响任务的完成。

在很多测试博客中也有开发/测试比例的讨论，例如 Google V.S Microsoft Dev Test Ratio(james_whittaker),  Test to Developer ratios(Alan Page)