软件测试之自动化测试的实践案例
很高兴今天有机会和大家讨论一下软件测试自动化的实践，今天的话题分为两个部分 ：
一是软件自动化功能测试；还有一部分会介绍一下软件自动化性能测试。
实践主要包含两个部分：一部分是介绍HP在软件的功能和性能自动化测试的理念，以及产品和技术在这方面的支持。另一部分是一些实践案例，包括在国内外哪些用户使用我们的测试工具，他们是如何去做的。
首先是自动化功能测试，我们讨论一下他的适用范围，或使用时机是何时。对于一个新的项目，比如项目周期很紧的功能测试项目，如果临时分配30个人，按测试方案进行手工测试的效率可能要比自动化测试工具录制脚本在测试的效率好的多。那么自动化测试工具的价值在什么地方？我们可以看一下，很多客户如果想增加一些新的功能，或者是修复bug，经常会推出产品新的版本，在推出的过程中，我们也知道，除了测试修改过的模块外，每次都要重复测试有关联的模块，这样很多时候会做大量的重复工作，人员很疲惫也达不到测试效果，自动化功能测试工具就可以创建整个测试生命周期的可重用模块，同时还能覆盖大部分的系统测试，更主要的是录制好脚本以后，自动去执行，机器去操作，减少了人为主观的错误，同时使测试人员解脱出来，专注新的模块。自动化测试最大的价值在于回归测试。在产品提交过来之后要执行“冒烟测试”，自动化测试工具能够节省时间和金钱。图中是国际上某金融机构的统计，在过去三年内使用使用自动化测试工具的投资回报率达到1500%。下面我们看一下自动化测试的原理是什么。
自动化测试发展到现在，很多厂商走的技术路线都是类似的，一是通过录制生成脚本，业务人员或测试人员按正常的业务执行流程，同时自动化工具录制并生成脚本，要注意的是，它录制的不是鼠标和键盘的操作，而是对象的操作，如某个button被click了一下，或某个文本框输入了数据，这样的好处是当button位置发生了变化，脚本会根据对象的属性精确定位到对象，然后进行脚本回放，可以不需要反复修改，来执行自动化测试。当录制好脚本后，可能要执行测试数据的参数化。录制的可能是一套数据，如录制登录操作，可能录制的是正确的用户名和密码，但实际执行测试的时候可能需要很多的组合，比如正确的用户名、错误的密码，空用户名、空密码等等，这时候你需要对输入的数据进行参数化。那么需要这种参数表对参数进行定义。接下来第三点是自动化测试以功能测试是否正确作为结果来判断的，它需要定义正确的检查点，就是说我能够通过对象的属性或界面的文字去判断我的功能执行是不是正确的。还有一个比较重要的，也是很多朋友容易忽略的，就是最后的测试报告。测试运行完以后，我需要根据我的检查点去判断我的运行结果怎样，有的产品的报告可能是文字型的，但实际上对于很多测试需要图形化的报告，可以看到我的检查点是什么，执行的时候是什么情况，为什么会出现错误。
基于以上这些，我们可以看到当使用软件测试自动化工具的时候需要考虑什么问题：
1．工具要有对对象很好的识别和维护的能力，支持各种传统和新的技术，象今天上午的调研报告里反映的，很多朋友也都关心自动化测试工具是否支持一些新的技术，另外，还需要统一的对象库，脚本可以基于对象库统一管理对象，当对象库的某一对象发生变化时，如中文版的button上是“确定”，英文版可能就是“ｏｋ”，可以更改对象库中对象的属性，就不需要打开每个脚本进行修改，还有一个比较重要的是对象库的图形化操作，可能会有些对象库的合并、分拆等等。２．就是脚本要易于修改和维护，不仅仅是脚本的语言，更主要的是要提供脚本图形化的编辑。虽然测试人员很多是从开发人员转换过来的，但测试人员不等于开发人员，那么工具的使用是要易于理解和掌握，像有的用户甚至是业务人员和开发人员一起录制脚本，这时候工具对于业务人员要易于理解和掌握，要能够知道工具是如何用的。还有就是离线编辑，不用起应用也能够进行脚本编辑。３．测试数据的驱动，数据表要易于编辑和维护，数据参数化操作。４．检查点，支持多种检查点，如对象、文本、位图。５．结果报告，刚才我们也提到，结果报告的图形化也是很有必要的，而且要易于浏览。下面我们看看惠普提供的相关功能测试套件，上午的调研报告中我很高兴的看到，对自动化测试工具在企业中应用的调查结果，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．自动化测试实际上是这种规模效应，覆盖率达到一定规模，他的效果才能体现出来，同时也是要不断积累和完善的。
1．选择合适的被测应用： ? 工具对应用界面开发技术的支持程度 ? 生命周期长，但是经常变更和升级 ? 界面变化相对不大 ? 开发已经基本完成 ? 回归测试阶段 ? 检查已知错误是否重现 ? 发现修改造成的新错误 2.选择合适的案例 ? 高业务风险 ? 手工测试复杂度高 ? 实现自动化测试难度低 ? 前期测试发现缺陷比较多案例评估方法这个片子是介绍如何评估业务的风险。主要从业务风险评估和技术风险评估两方面来说。从不同的维度来评估你的业务是不是具有高风险。 3．规模效应，不断完善积累 ? 设计先行 ? 覆盖率越高，价值越明显 ? 覆盖率和投入成正比 ? 不要一开始就期望高覆盖率 ? 逐步使用，逐步发展，逐步完善 ? 设计自动化功能测试框架 ? 业务人员和技术人员的协同工作 ? 大批量脚本的调度 ? 重用需要实现脚本调度 ? 数据驱动的要求 ? 界面一旦变化的维护要求 4．自动化功能测试设计框架这里我们提出的自动化功能测试设计框架应该包含的内容，首先最关键的是中心管理，我们首先应该有自己的库（Central Management），去集中管理所有的自动化测试脚本；上面一层是功能库（Functional Lib），是一些可以提取的函数；再上面一层是业务组件（Logic Components），把被测系统可重用的组件提取出来；再上面一层是控制器（Controller），可以控制、组织业务组件，形成一个个业务流程；再上面是调用的脚本（Load Scripting），实现脚本的调度。下面我们来看一下，传统的自动化功能测试是序列化的，从登录、创建订单、查看订单到退出，是一步步做的，数据往往和脚本是捆绑在一起的，对脚本的调用还是需要用写代码的方式来维护。而HP的业务流程测试（Business Process Testing）—基于Web的无测试脚本的功能测试，它与传统的自动化功能测试的区别是： ? 使业务人员参与自动化功能测试的设计和使用，及早进行测试规划 ? 业务人员使用自然语言定义组件；测试人员脚本实现 ? 使用应用界面流和数据创建测试案例 ? 大量减少自动化测试案例维护时间 ? QTP/WR与TD for QC集成实现外面的展厅中，我的同事会有一些实时的demo展示，大家如果感兴趣可以在间歇的时候去看一下，业务流程测试怎么样方便的帮助用户实现自动化功能测试的框架。这个图是HP的质量中心的框架图，在软件质量管理讲演中会对它详细介绍，这里我就不详细介绍了。
第二部分给大家介绍软件自动化性能测试。讲解之前，我首先问大家一个问题，有多少人用过LoadRunner？好，我本来想如果用的人多的话我就着重介绍一些新的特性，现在看来大家用的不多，我还是详细介绍一下。前面我们介绍的是功能测试，主要是在功能上看产品和业务的对应情况，能不能满足业务需求。但同时我们也知道产品的使用往往不是一两个人，少则几十，多则上千，那么产品上线以后是不是能够支撑这么多用户，因此要做性能测试，他与功能测试还有个区别是，功能测试还是可以靠人力去做，但性能测试往往无法靠人力做的，因为没有办法做到这么多人同时做一个操作，并计算响应时间。作为性能测试，我们往往面临一些问题：
1．性能测试目标不明确；2．业务部门和测试团队缺乏通用语言；3．脚本能否录制和回放；4．场景如何接近真实地模拟；5．瓶颈定位。
HP LoadRunner作为业界领先的自动化压力测试工具，它具有很多功能：
1．使用成百上千的虚拟用户代替真实用户；2．从单一控制点对系统产生精确的，可测量和可重复的负载，并且提供无代理的监控；3．强大的分析器，协助查明系统瓶颈。然后我们可以看一下LoadRunner如何工作? ? 将业务流程录制为自动化脚本，例如股票交易应用中的 “买入”； ? 添加事务, 参数化输入数据, 添加验证点； ? 模拟用户行为，例如网络连接类型，频率等…
文章来源于领测软件测试网 https://www.ltesting.net/
