自动化测试实践

很高兴今天有机会和大家讨论一下软件测试自动化的实践，今天的话题分为两个部分：一是软件自动化功能测试；还有一部分会介绍一下软件自动化性能测试。实践主要包含两个部分：一部分是介绍HP在软件的功能和性能自动化测试的理念，以及产品和技术在这方面的支持。另一部分是一些实践案例，包括在国内外哪些用户使用我们的测试工具，他们是如何去做的。

首先是自动化功能测试，我们讨论一下他的适用范围，或使用时机是何时。对于一个新的项目，比如项目周期很紧的功能测试项目，如果临时分配30个人，按测试方案进行手工测试的效率可能要比自动化测试工具录制脚本在测试的效率好的多。那么自动化测试工具的价值在什么地方？

我们可以看一下，很多客户如果想增加一些新的功能，或者是修复bug，经常会推出产品新的版本，在推出的过程中，我们也知道，除了测试修改过的模块外，每次都要重复测试有关联的模块，这样很多时候会做大量的重复工作，人员很疲惫也达不到测试效果，自动化功能测试工具就可以创建整个测试生命周期的可重用模块，同时还能覆盖大部分的系统测试，更主要的是录制好脚本以后，自动去执行，机器去操作，减少了人为主观的错误，同时使测试人员解脱出来，专注新的模块。自动化测试最大的价值在于回归测试。在产品提交过来之后要执行“冒烟测试”，自动化测试工具能够节省时间和金钱。图中是国际上某金融机构的统计，在过去三年内使用使用自动化测试工具的投资回报率达到 1500%。下面我们看一下自动化测试的原理是什么。

自动化测试发展到现在，很多厂商走的技术路线都是类似的，一是通过录制生成脚本，业务人员或测试人员按正常的业务执行流程，同时自动化工具录制并生成脚本，要注意的是，它录制的不是鼠标和键盘的操作，而是对象的操作，如某个button被click了一下，或某个文本框输入了数据，这样的好处是当button位置发生了变化，脚本会根据对象的属性精确定位到对象，然后进行脚本回放，可以不需要反复修改，来执行自动化测试。当录制好脚本后，可能要执行测试数据的参数化。

录制的可能是一套数据，如录制登录操作，可能录制的是正确的用户名和密码，但实际执行测试的时候可能需要很多的组合，比如正确的用户名、错误的密码，空用户名、空密码等等，这时候你需要对输入的数据进行参数化。那么需要这种参数表对参数进行定义。接下来第三点是自动化测试以功能测试是否正确作为结果来判断的，它需要定义正确的检查点，就是说我能够通过对象的属性或界面的文字去判断我的功能执行是不是正确的。还有一个比较重要的，也是很多朋友容易忽略的，就是最后的测试报告。测试运行完以后，我需要根据我的检查点去判断我的运行结果怎样，有的产品的报告可能是文字型的，但实际上对于很多测试需要图形化的报告，可以看到我的检查点是什么，执行的时候是什么情况，为什么会出现错误。基于以上这些，我们可以看到当使用软件测试自动化工具的时候需要考虑什么问题：

1.工具要有对对象很好的识别和维护的能力，支持各种传统和新的技术，象今

天上午的调研报告里反映的，很多朋友也都关心自动化测试工具是否支持一些新的技术，另外，还需要统一的对象库，脚本可以基于对象库统一管理对象，当对象库的某一对象发生变化时，如中文版的button上是“确定”，英文版可能就是“ok”，可以更改对象库中对象的属性，就不需要打开每个脚本进行修改，还有一个比较重要的是对象库的图形化操作，可能会有些对象库的合并、分拆等等。

2.就是脚本要易于修改和维护，不仅仅是脚本的语言，更主要的是要提供脚本图形化的编辑。虽然测试人员很多是从开发人员转换过来的，但测试人员不等于开发人员，那么工具的使用是要易于理解和掌握，像有的用户甚至是业务人员和开发人员一起录制脚本，这时候工具对于业务人员要易于理解和掌握，要能够知道工具是如何用的。还有就是离线编辑，不用起应用也能够进行脚本编辑。

3.测试数据的驱动，数据表要易于编辑和维护，数据参数化操作。

4.检查点，支持多种检查点，如对象、文本、位图。

5.结果报告，刚才我们也提到，结果报告的图形化也是很有必要的，而且要易于浏览。下面我们看看惠普提供的相关功能测试套件，上午的调研报告中我很高兴的看到，对自动化测试工具在企业中应用的调查结果，WinRunner是排在第一位的，但实际上HP同时还有另外一个自动化测试工具产品，就是Quit Test Professional，即QTP。目前，HP是把WinRunner和QTP作为整体的功能测试套件提供。WinRunner比较关注传统的应用，如早期的Delphi、PowerBuilder；QTP关注新兴技术，如.NET、新的WebService、无线、VMWare 桌面支持的测试，QTP 都可以支持。同时这两个产品又有通用的覆盖面，包括像Web、VB、Activex等等，但我们向用户推荐QTP，因为它具有灵活、易用、简单的特性。它不仅提供脚本语言的编辑，同时还提供关键字视图界面。在界面中它对每一个对象进行梳理、提取，同时下面又提供数据表和实时的捕捉，这样用户可以很方便的编辑。同时也可以把对象选择进来，离线编辑脚本。另外还提供ActiveScreen技术，可以界面快照，然后对快照添加验证点、测试步骤，甚至离线编辑。

下面是我们在长期的工作过程中总结的自动化功能测试的原则：

•就是选择合适的被测应用；

•就是要选择合适的案例；

•设计自动化功能测试框架；

•自动化测试实际上是这种规模效应，覆盖率达到一定规模，他的效果才能体现出来，同时也是要不断积累和完善的。

1．选择合适的被测应用：

•工具对应用界面开发技术的支持程度

•生命周期长，但是经常变更和升级

•界面变化相对不大

•开发已经基本完成

•回归测试阶段

•检查已知错误是否重现

•发现修改造成的新错误

2.选择合适的案例

•高业务风险

•手工测试复杂度高

•实现自动化测试难度低

•前期测试发现缺陷比较多

案例评估方法

这个片子是介绍如何评估业务的风险。主要从业务风险评估和技术风险评估两方面来说。从不同的维度来评估你的业务是不是具有高风险。

3．规模效应，不断完善积累

•设计先行

•覆盖率越高，价值越明显

•覆盖率和投入成正比

•不要一开始就期望高覆盖率

•逐步使用，逐步发展，逐步完善

另外一方面，对于自动化功能测试仅仅录制回放是不够的：

•设计自动化功能测试框架

•业务人员和技术人员的协同工作

•大批量脚本的调度

•重用需要实现脚本调度

•数据驱动的要求

•界面一旦变化的维护要求

4．自动化功能测试设计框架

这里我们提出的自动化功能测试设计框架应该包含的内容，首先最关键的是中心管理，我们首先应该有自己的库（Central Management），去集中管理所有的自动化测试脚本；上面一层是功能库（Functional Lib），是一些可以提取的函数；再上面一层是业务组件（Logic Components），把被测系统可重用的组件提取出来；再上面一层是控制器（Controller），可以控制、组织业务组