今天我和大家探讨的主题是自动化测试，我把它命名为“自动化测试可以走得更远”，进入这个主题前我还想跟大家交流一些想法，自动化测试我们知道它的提出实际上是和我们传统的测试是一个不对立的概念，也就是说我们国内在2003年之前，绝大多数的测试工作主要是集中在传统的人工测试上，2003年之后我们可以看到自动化的测试工具，从事自动化测试的工程师逐渐的如雨后春笋般的出现，自动化测试在我们业界有一个共识，就是采用自动化测试可以提高我们的测试质量，控制我们的进度，有的时候也可以规避我们的测试风险，降低一些成本等等。但是，自动化测试在国内的应用状况并不是太好。

　　我举两个例子，第一，不管我们的中小型企业还是国内的大型企业，自动化测试程度都非常低，自动化测试开展得不是很好，有一些中小型企业的测试人员根本没有接触过自动化测试，大企业里自动化测试人员也都不是专职的，有一些相关的开发工作，任务重的就交给开发人员去做，没有专职的测试开发人员，这是一个例子。

　　另一个我想说一下现在在自动化测试领域里我们离不开的是工具，这些工具国内自主研发的很少，基本上都是购买国外商品化工具的多。所以，从这两点可以看出来我们自动化程度并没有走出多远，应该说我们还可以走得更远。

　　首先我先跟大家探讨一个比较传统的基础的话题，就是我们测试的模型，这里我们展现的是一个W模型，也就是说在这个模型里我们可以看到我们要求测试和开发同步进行，也就是说以前我们认为产品要上线，系统要上线，赶紧抓紧时间做测试，这是一个大好的时机，对于保证产品的质量至关重要，实际上现在我们可以看到，W模型是两个V模型的组合，显示绿色的V模型是开发的生命周期，显示黄色的V模型是一个测试的生命周期，我们可以看到，实际上在开发的不同阶段，都有可能引入缺陷，这个时候如果说我们对这些缺陷视而不见，等到上线前再去诊断它，再去修复它，我们将会投入的成本很高，甚至很多的缺陷是没有办法再去修复的。所以，我们说现在的测试实际上是和开发紧密配合的一个测试，也就是说比如说我们在做需求分析的时候，我们就应该引入一些需求分析的评估方法，架构设计的时候就应该引入一些架构设计评估的方法，到了编码阶段就应该采取一些单元和集成测试，等等。所以，我们自动化测试技术首先是建立在W模型之上的。根据这个模型我们现在就搭建了这么一个自动化测试的框架，这个框架它其实包含了三个层次，第一个层次我们强调的是我们的测试应该覆盖开发的整个生命周期，大家可以看到，我们有相关的需求和架构，也有到最后执行的运维的测试，刚才刘总谈到的像奥运票务系统已经上线了，但是承受不了大量的负载，宕机之后还得接着卖票，怎么办？我们只能进行运维测试，在生产环节优化，让它满足下一阶段的售票需求，这叫运维测试，也是比较有中国特色的一类测试。

　　接下来为了满足全生命周期的策略，我们产生了不同的测试方法和技术，这个方法在测试发展这么多年变化不大，还是我们理解的白盒子黑盒子方法，这个技术是百花齐放，比如有我们熟悉的功能测试，也有性能测试，还有近些年开展起来的一些可靠性测试，安全测评，稳定性网络测试等等，测试技术还是发展非常快的。在这些技术里，大部分也都实现了自动化的方法，有的自动化程度低一些，比如大家熟悉的功能测试，自动化程度大家知道基本上还是靠我们人工在做，工具起的作用非常小，但是有一些自动化程度很高，比如我们经常提到的负载压力测试，我们的代码测试，它的自动化程度都达到了90%以上。现在我们这里列了一些目前新兴的自对化测试的类型，我们可以看到上面自动化功能测试的框架，刚才我谈到了虽然功能测试的自动化程度低，但是我们并没有放弃这块领域，很多人在这个方向在研究自动化的框架，很多企业也勇敢的去尝试怎么能搭建起适合于自己的框架，把我们的测试人员从传统的人工测试解放出来，更大程度去使用自动化测试。

　　还有我们右侧展示的比如软构建的自动化测试技术，SaaS测试技术，以及宽带无线的测试技术，这都是在近一两年之内提出的一些新型的测试技术，也是发展到现在我们看来未必还特别完善的一些自对化测试技术，还是需要大家在这个方向共同努力，投入很多资源的一项测试技术。

　　也有一些测试技术经过这些年发展以后，从不成熟逐渐发展为成熟，就是左侧展示的，比如可靠性测试，安全攻防测试，以及一些嵌入式测试技术，还有中间展示的下一代互联网技术，就是我们谈到的网络的仿真模拟技术。下面我就想就一些主流的测试技术跟大家共同交流一下目前自动化测试我们可以利用自动化测试能实现哪些目标。

　　首先，谈一下自动化功能测试，自动化功能测试，我们大家知道传统的测试方法是工程师画出要测试的业务流程，然后根据这个业务流程设计用例，工程师给用例配上测试数据就开始人工的界面进行测试。自动化功能测试现在我们是将我们要测试的案例把它通过录制的方式转化成测试脚本，就是大家右下角看到的，这个测试脚本实际上是一种面向对象的编程方法，大家可以看到脚本里包含了被操作对象，操作的动作以及相关的操作值。这是我们提到的自动化功能测试技术里的关键字驱动技术，右侧的环态图是完整的测试流程，从最左侧的测试需求开始，我们一般的要经历这么几个过程，测试需求的制订，测试案例的设计，测试的执行，最后我们对我们测得的缺陷要分析和挖掘。整个的测试过程实际上我们现在已经用自动化的测试的技术和管理把它串起来了。这个时候我们可以看到自动化测试不仅仅替代手工测试，它可以在测试过程的每个环节都体现它的价值。这里面大家看到不光有技术，也有一些管理的因素在里面。

　　这个时候我们可以看到刚才我们说到在整个测试里有几个关键的里程碑阶段，比如我们举个例子，关于用例，大家知道做功能测试我们都需要设计用例，这个时候我们就可以不但利用工具来自动化的设计用例，而且可以讲用例和用例相关的数据管理起来，这里涉及到用例对象的管理，逻辑关系管理，我们数据的自动生成，数据的自动组合生成，等等，这些都已经实现了自动化的方法。同时，我们用例如果我们需要用用例来构成更复杂的业务场景的话，我们也可以在管理工具里来进行不同场景的配置。

　　这个时候有的人就说为什么自动化功能测试走得不远，用得不多呢？主要原因是这么两个情况。左侧展示的一个我们可以看到我们的手工测试人员居多，因为我们的很多测试人员是不具备开发能力的，这是一个。另一个我们国内信息系统发展的一个特点是需求变化的频率很快，这样的话，用自动化方法导致我们维护脚本的工作量很大，这是两个很现实的问题。现在我们怎么来解决这个问题呢？就是右侧这个矩形框展示的一方面我们可以研究和搭建设计框架，把底层的代码技术封装起来，让不熟悉代码的工程师可以绕开这一关，直接使用自动化测试技术，另外一方面，我们用动态脚本来代替静态脚本，来应对这个案例随着需求要不断变化和需求，这么一种现状。这是这样一个情况。