自动化测试实践.pdfVIP

自动化测试实践 很高兴今天有机会和大家讨论一下软件测试自动化的实践，今天的话题分为两 个部分：一是软件自动化功能测试；还有一部分会介绍一下软件自动化性能测 试。实践主要包含两个部分：一部分是介绍HP在软件的功能和性能自动化测试 的理念，以及产品和技术在这方面的支持。另一部分是一些实践案例，包括在 国内外哪些用户使用我们的测试工具，他们是如何去做的。 首先是自动化功能测试，我们讨论一下他的适用范围，或使用时机是何时。对 于一个新的项目，比如项目周期很紧的功能测试项目，如果临时分配 30个人， 按测试方案进行手工测试的效率可能要比自动化测试工具录制脚本在测试的效 率好的多。那么自动化测试工具的价值在什么地方？ 我们可以看一下，很多客户如果想增加一些新的功能，或者是修复bug，经常会 推出产品新的版本，在推出的过程中，我们也知道，除了测试修改过的模块外， 每次都要重复测试有关联的模块，这样很多时候会做大量的重复工作，人员很 疲惫也达不到测试效果，自动化功能测试工具就可以创建整个测试生命周期的 可重用模块，同时还能覆盖大部分的系统测试，更主要的是录制好脚本以后， 自动去执行，机器去操作，减少了人为主观的错误，同时使测试人员解脱出来， 专注新的模块。自动化测试最大的价值在于回归测试。在产品提交过来之后要 执行“冒烟测试”，自动化测试工具能够节省时间和金钱。图中是国际上某金 融机构的统计，在过去三年内使用使用自动化测试工具的投资回报率达到 1500%。下面我们看一下自动化测试的原理是什么。 自动化测试发展到现在，很多厂商走的技术路线都是类似的，一是通过录制生 成脚本，业务人员或测试人员按正常的业务执行流程，同时自动化工具录制并 生成脚本，要注意的是，它录制的不是鼠标和键盘的操作，而是对象的操作， 如某个button被click 了一下，或某个文本框输入了数据，这样的好处是当 button位置发生了变化，脚本会根据对象的属性精确定位到对象，然后进行脚 本回放，可以不需要反复修改，来执行自动化测试。当录制好脚本后，可能要 执行测试数据的参数化。 录制的可能是一套数据，如录制登录操作，可能录制的是正确的用户名和密码， 但实际执行测试的时候可能需要很多的组合，比如正确的用户名、错误的密码， 空用户名、空密码等等，这时候你需要对输入的数据进行参数化。那么需要这 种参数表对参数进行定义。接下来第三点是自动化测试以功能测试是否正确作 为结果来判断的，它需要定义正确的检查点，就是说我能够通过对象的属性或 界面的文字去判断我的功能执行是不是正确的。还有一个比较重要的，也是很 多朋友容易忽略的，就是最后的测试报告。测试运行完以后，我需要根据我的 检查点去判断我的运行结果怎样，有的产品的报告可能是文字型的，但实际上 对于很多测试需要图形化的报告，可以看到我的检查点是什么，执行的时候是 什么情况，为什么会出现错误。基于以上这些，我们可以看到当使用软件测试 自动化工具的时候需要考虑什么问题： 1.工具要有对对象很好的识别和维护的能力，支持各种传统和新的技术，象今 界面变化相对不大 • 开发已经基本完成 • 回归测试阶段 • 检查已知错误是否重现 • 发现修改造成的新错误 2.选择合适的案例 • 高业务风险 • 手工测试复杂度高 • 实现自动化测试难度低 • 前期测试发现缺陷比较多 案例评估方法 这个片子是介绍如何评估业务的风险。主要从业务风险评估和技术风险评估两 方面来说。从不同的维度来评估你的业务是不是具有高风险。 3．规模效应，不断完善积累 • 设计先行 • 覆盖率越高，价值越明显 • 覆盖率和投入成正比 • 不要一开始就期望高覆盖率 • 逐步使用，逐步发展，逐步完善 另外一方面，对于自动化功能测试仅仅录制回放是不够的： • 设计自动化功能测试框架 • 业务人员和技术人员的协同工作 • 大批量脚本的调度 • 重用需要实现脚本调度 • 数据驱动的要求 • 界面一旦变化的维护要求 4．自动化功能测试设计框架 这里我们提出的自动化功能测试设计框架应该包含的内容，首先最关键的是中 心管理，我们首先应该有自己的库（Central Management ），去集中管理所有 的自动化测试脚本；上面一层是功能库（Functional Lib ），是一些可以提取 的函数；再上面一层是业务组件（Logic Components ），把被测系统可重用的 组件提取出来；再上面一层是控制器（Controller），可以控制、组织业