（计算机应用技术专业论文）用户界面自动化测试的研究与实现.pdf

中南民族大学硕士学位论文 i 摘 要 将传统观念中模糊的“测试” 概念在软件的开发过程中明确化、规范化， 提出了软件设计、软件编码和软件维护分别与测试设计、测试编码和测试维护同 步的思想。详细分析了测试用例的定义、分类和粒度的把握以及在不同类型的测 试中具体的测试要求和环境依赖。 提出了软件测试中一个急需解决的问题； 如何有效地实现用户界面的自动化 测试并且能根据用户界面的更改及时更新测试代码来保证自动化测试的可用性。 指出了目前用户界面的自动化测试所采用的录制技术存在的不足， 针对不断 变化的用户界面， 测试代码很难维护和扩展的问题， 采用基于对象捕捉的 picasso 技术，设计了以 picasso 为基础的三层结构模型，实现了高度灵活并易于扩展的 用户界面自动化测试。测试结果表明，这种方案在对人工测试的模拟上是非常智 能的，测试效率和测试质量都很高。 在自动化测试的实施中，在分析了自动化的运转所必需的多种技术支持：源 代码和测试代码的管理、编译机制、控制机制、测试用例的管理和调度、运行结 果的存储与发布等机制。 在测试的维护方面，给出了系统重构和角色划分 2 种方案，保持了在不断变 化的产品中测试代码的可用性，从而保障了产品的质量。 最后，本文给出了目前工作中存在的不足(在多机并发自动化的实现中遇到 的困难及需要研究和解决的问题)，对下一个阶段的工作进行了展望。 关键字：关键字：软件测试；自动化；测试用例管理；用户界面；测试框架 用户界面自动化测试的研究与实现 ii abstract testing is always an intangibly concept applied in software development. this paper gives test an explicit place in the scheme of things provides more visibility to that amorphous half of the labor that often goes under the name “test and debug”. testing should be explicitly identified. instead of “design, code, test, and debug” the process should be described as: “design, test design, code, test code, test debugging, test execution, program debugging, testing.” one of the hardest problems in testing software today is how to effectively automate ui testing, and be able to keep such tests up to date. that means to be able to modify them easily as soon as ui changes. this paper aims at the obvious deficiencies of recording technique; adopt object-oriented capturing technique named picasso, designed three-layer architecture framework and implemented ui automation testing, largely proved agility of test code. then analysts the necessary techniques which are required in automation run such as source code and test code management, daily building mechanism, controlling mechanism to run test case and manage test case, running results logging and reporting. in order to increase maintenance of test code, two strategies which are refactor and splitting role are given at the end of the paper, they provide the most effective methods to guarantee validity of test code in endlessly updating system. at last, the paper shows the deficiency of current workthe troubles in multi-boxes concurrent automation. keyword: software testing; automation; tcm; ui; testing framework 中南民族大学中南民族大学 学位论文原创性声明学位论文原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取 得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任何其 他个人或集体已经发表或撰写的成果作品。 对本文的研究做出重要贡献的个 人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律后果 由本人承担。 作者签名： 日期： 年 月 日 学位论文版权使用授权书学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学 校保留并向国家有关部门或机构送交论文的复印件和电子版， 允许论文被查 阅和借阅。 本人授权中南民族大学可以将本学位论文的全部或部分内容编入 有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本 学位论文。 本学位论文属于 1、保密，在_年解密后适用本授权书。 2、不保密。 （请在以上相应方框内打“” ） 作者签名： 日期： 年 月 日 导师签名： 日期： 年 月 日 中南民族大学硕士学位论文 1 第第 1 章章 绪论绪论 1.11.1 软件测试的背景和意义 软件测试的背景和意义 随着社会的不断进步和计算机技术的快速发展， 许多行业都和计算机以及通 讯网络高效地联系到一起。在这些系统中，软件的失效可能会带来很大的经济损 失甚至人身危害。而在整个软件开发过程中，从需求分析到系统设计直到代码实 现，都会出现或多或少的问题，那么如何保障软件的质量，软件测试就成为关键 的技术。 测试是一种旨在评估一个程序或系统的属性或能力， 确定它是否符合其所需 结果的活动1。测试是所有工程学科的基本组成单元，是软件开发的重要组成部 分。统计表明，在典型的软件开发项目中，软件工作量往往占软件开发总工作量 的 40%以上。而在软件开发的总成本中，用在测试上的开销要占 30%-50%。 软件对于我们来说总会存在一定的虚幻性，它不像硬件那样是真实存在的， 如果软件本身就是看不见摸不着的，那么软件测试的效果表现的就更不直观。测 试看起来很浪费时间，特别是我们经过一番测试之后没有把错误充分地暴露出 来。软件测试的最终目的是要提交用户一个高可用性产品。为了尽可能多地找出 错误，给最终用户提供具有一定可信度的质量评价，测试的重点应该是逻辑实现 比较复杂的地方和出错比较多的地方以及在实际的应用中经常使用的业务规则。 1.2 软件中的生产和质量 1.2 软件中的生产和质量 在制造业中，产品设计阶段的成本比起大批量生产的开销要小得多。如果在 产品投入生产的某个阶段才发现问题， 那么已经生产出来的某些部件就被丢弃并 重做。在质量保证与生产中有一个成本的平衡，测试做得不充分，产品的不合格 率就升高，产品的生产成本就会上升；如果测试做得非常充分，把所有的问题都 暴露出来，将生产成本的损失降为零，那么测试成本肯定会提高。测试和质量保 证在产品生产的成本中所占的比重在不同的行业中相差很远， 大概在百分之二到 百分之八十之间。像在太空船、航行器之类的制造中，如果测试做得不够，付出 用户界面自动化测试的研究与实现 2 的可能是生命的代价。 在软件的生产中，质量保证和生产的关系与在制造业中是不一样的。比起刻 制光盘的成本，软件生产的主要代价是耗费在开发中。软件维护的意义和硬件维 护也有所不同， 它通常是在需求的不断改变和增加的情况下对软件进行扩展性的 开发，在使用中不断发现问题并纠正。软件生产中的一个很大的开销是检测软件 中存在的错误并纠正错误。 我们设计测试用例并实施测试用例来捕捉软件中存在 或有可能存在的错误是在软件的开发中进行的，因此，质量和生产在软件制造中 是密不可分的。 1.3 软件测试的发展阶段 1.3 软件测试的发展阶段 根据不同的测试目的，测试的发展经历以下四个阶段。 (1) 调试：在二十世纪七十年代之前，软件测试还没有作为一门科学出现的 时候， 测试和调试并没有什么区别， 在软件发展的初期， 计算机资源稀少且宝贵， 对于小规模、规范性不强的低成本软件，测试的概念就是调试。这种测试文化放 在今天，则是保证软件高质量的严重思想障碍。调试并不是有效的测试，不能保 证软件质量。 (2) 验证软件的正确性：在七十年代末期，人们开始意识到测试和调试是有 区别的。代码在语法和语义上没有错误的软件并不代表软件本身没有错误。要保 证软件的可用性，需要对软件功能的正确性进行测试。这个测试过程与软件设计 的初衷是一致的，将设计者要实现的具体内容一一验证。这意味着，测试的越多 越具体，所能发现的问题就越多，软件的质量提高。 (3) 错误性测试： 当一个与软件设计初衷相背离的操作使得软件无法处理并 影响正常工作甚至使软件崩溃，这是再充分的正确性测试都不能弥补的。在保证 软件功能的实现与设计相一致的同时，为了提高软件的可用性及容错性，我们需 要设计一些有启发性的测试，当没有按照设计者的意愿进行操作，会出现什么样 的反应，在不期望的情况下软件会怎样处理。在这种启发性的测试中，我们同样 会不断地发现问题，但是永远都不知道还有多少潜在的问题没有发现，永远不知 道这种测试何时停止。 (4) 质量管理：质量管理在软件测试中的认可，标志着测试的发展逐步迈向 中南民族大学硕士学位论文 3 成熟。之所以说“认可”而不是“实施”是因为将质量管理统计方法学应用在软 件测试还需要不断地探索。在某种程度上，我们发现了问题，然后解决了问题， 在不断地测试中，软件质量在提高；但是，如果我们所做得许多测试并没有发现 问题，所有的测试结果和期望的都是一样的，从统计学的角度来讲，软件的质量 仍然是在提高，尽管我们没有发现问题，没有改进。我们所做的测试，无论结果 是成功还是失败，测得越全面，软件存在隐患的风险就越小。当我们的测试越来 越苛刻，仍然没有出现问题，软件本身虽然没有变，但在我们的意识里，它的质 量确实在提高，至少我们对它的信心在提高。 1.4 软件测试的目标 1.4 软件测试的目标 测试计划和测试实施作为质量保证的一部分，不仅要检测问题，更要考虑如 何防止问题的出现，在某种程度上，测试的实施并不能防止问题的出现，但是， 从发现的问题中可以看到一些潜在的问题或其它征兆。测试需要提供详细、清晰 的诊断方案来检测错误，使它们较早地被更正。 测试的第一目标是错误的预防2。预防一个错误的发生比发现错误并更正要 好，这样，就不需要去修改代码，也不需要对修改的部分重新验证，更不会因为 没有预料到的状况去更新进度表。因此，比测试更重要的是测试计划的制定，在 测试计划中设计有效的测试任务， 会使开发人员在编码之前就考虑问题的解决方 案，将问题及时排除。理想的测试是将测试计划融合在编码的设计中，把系统中 可能出现的问题全部考虑到，并将解决方案作为设计的一部分。将所有的问题都 在设计的阶段预防，真正的实施并不需要。尽管我们为这个目标付出很多努力， 但它只是一个理想，我们并不能将问题完全预防。 如果第一个目标不能实现， 我们就要努力实现第二个目标实施有效的测 试检测问题来保证软件的质量2。 在一般情况下， 问题并不是那么容易被发现的， 测试实施中要详细的写出测试的环境、 条件和测试步骤以及测试预期的结果和实 际出现的现象。由于不同的错误可能会表现出同样的现象，一个错误可能会带来 很多隐患， 对于每一个问题和征兆我们只能通过一系列小的测试用例一步步地测 试。 用户界面自动化测试的研究与实现 4 1.5 章节安排 1.5 章节安排 本文的结构安排如下： 第 1 章：介绍了软件测试的背景和意义、发展阶段以及软件测试的目标。 第 2 章：给出自动化测试的概念、优势和质量指标以及测试在整个软件开发 周期中的活动；详细阐述了测试用例的定义、分类和粒度的把握以及在不同类型 的测试中具体的测试要求和环境依赖。 第 3 章： 提出如何有效地实现用户界面的自动化测试是目前软件测试中一个 急需解决的问题。 针对被普遍采用的录制技术实现用户界面自动化测试的明显不 足，本文采用基于对象捕捉的 picasso 技术，设计出以 picasso 为基础的三层结 构模型，并在 picasso 提供的解决方案的基础上，在框架层进行了扩展，使界面 元素的自动化捕捉更加智能，灵活、有效地实现了用户界面的自动化测试。 第 4 章：阐述了自动化测试的实施所必需的技术支持：包括源代码、测试代 码管理器，编译机制，控制机制，测试用例的管理和调度、运行结果的存储与发 布，详细分析了原文件管理库和测试用例管理器的体系结构。 第 5 章：为了保障测试代码在不断变化的系统中有效性，本章介绍了系统重 构和角色划分两种策略来实现在不断发展中的系统中测试代码的维护。 在本文的 结尾，给出了目前工作中存在的不足(在实现多机并发自动化测试中遇到的困难 和尚未解决的问题)，展望了下一阶段的研究方向。 中南民族大学硕士学位论文 5 第第 2 章章 软件自动化测试软件自动化测试 软件测试的工作量很大并具有一定的重复性。 在测试后期所进行的回归测试 中大部分测试工作是重复的，回归测试就是要验证已经实现的大部分功能，这种 情况下，只是为了解决软件缺陷、需求变化，代码修改很少，针对代码变化所做 的测试相对比较少。而为了覆盖代码改动所造成的影响需要进行大量的测试，虽 然这种测试找到软件缺陷的可能性小，效率比较低，但又是必要的。比如，如果 设计文档、需求文档具有固定、合理、可理解的结构，那么从这些文档生成测试 数据和相关程序的操作就完全可以程序化实现， 并根据自动化运行的日志信息实 现测试结果的评估。 2.1 自动化测试的概念及优势 2.1 自动化测试的概念及优势 所谓自动化软件测试是指把软件测试中的部分或全部工作程序化的实现。 对 于任何软件系统，测试者希望通过有限的测试用例发现软件中的大部分缺陷。自 动化测试使得所取得的测试用例得以重复测试， 并能保障测试的科学性、 严密性、 组织性。 测试可以分为多个阶段和层次。 对应的自动化软件测试也可以分为多个阶段 和层次。简单地说，测试可分为 3 个步骤：准备测试用例和执行测试用例的辅助 程序、执行测试用例、评估测试结果。这 3 个步骤中的部分或全部在某预定义程 序帮助下程序化的实现的测试就可称为自动化软件测试。 测试人员在进行手工测试时，存在着一定的局限性，例如：无法做到覆盖所 有代码路径、对于机械性、重复性的测试工作量大、测试可以发现错误，并不能 表明程序的正确性等等。 如果将测试工具和软件测试自动化结合起来，可以解决手工测试的局限性， 并且具有以下优势： 缩短软件开发的测试周期。 测试效率高，充分利用硬件资源。可以在运行某个测试工具的同时运行另一 个测试工具， 也可以在一面运行某个测试工具一面思考新的测试方法或设计新的 用户界面自动化测试的研究与实现 6 测试用例，能够把大量测试用例分配到各台机器上同时运行，从而节省大量的时 间节省人力资源，降低测试成本。 增强测试的稳定性和可靠性。通过测试工具运行测试脚本，能保证测试用例 100%执行。 提高软件测试的准确度和精确度。软件测试自动化的结果都是数量化，能够 同所预期结果或规格说明书规定的标准进行量化对比。 软件测试工具使测试工作相对比较容易，但能产生更高质量的测试结果。 手工不能做的事情，软件测试自动化能做，如负载、性能测试。 软件测试实行自动化进程，绝不是因为厌烦了重复的测试工作，而是因为测 试工作的需要，更准确地说是回归测试和系统测试的需要。 2.2 自动化测试的质量指标 2.2 自动化测试的质量指标 自动化测试的质量主要根据以下 5 个方面来衡量：可靠性、可重复性、健壮 性、高效性和可维护性3。 可靠性：测试结果不应该为假阳性或假阴性，也就是说，测试结果标示为成 功意味着这个测试确实是通过的；反之，如果测试结果标示失败，则这个失败是 由于自身的原因产生的，而不是受其他的测试影响造成的失败。 可重复性：在测试用例的运行环境没有发生变化的条件下，测试行为是可以 重复的，即一个测试用例运行一遍或是运行一百遍应该产生相同的结果。 健壮性：测试代码对于环境合理的改变应该具有相当的免疫能力。比如，在 网络阻塞、内存容量不够，或是 sql 、iis 等服务无法获得等等，遇到这些情况 应该很好的处理，而不会抛出未处理的异常。 高效性：一个规模较大的产品会包含成千上万个测试用例，所以测试代码的 运行要花尽可能短的时间来完成。 可维护性：测试的可维护性体现在 3 个方面。(1) 当开发代码发生变化时， 测试代码所受到的影响应该尽量的小。(2)工程运转、维持的代价尽可能的小。 (3)产品发布之后故障的解决应该尽量的容易。 为了达到以上测试目标，需要确定测试所包含的所有领域，并为每个领域制 定指导方针和最优方法并确保各个测试组都依据测试计划来实施。 中南民族大学硕士学位论文 7 2.3 自动化测试术语 2.3 自动化测试术语 测试用例测试用例：为了测试某个特性或特性的一部分而设计的一组逻辑操作。 测试用例管理器：测试用例管理器：管理测试用例的环境。 测试任务：测试任务：在测试环境中被执行的特定的操作或命令。 suites：由多个测试用例和测试任务组成来完成多个特性或功能的测试。 testharness4：通过调度 suites 来运行测试用例的驱动。 bvt：基本功能性测试。 idw：高于基本性功能的测试。 源代码管理器：源代码管理器：包含项目所必需的开发和测试的源代码库。 checkin：改变源代码库中文件状态的操作。 buildbreak：编译不能正常进行的状态，这个状态通常是又错误的 checkin 造成的。 sku：指的是产品的版本。比如：测试版、标准版、企业版。 smoke test：轻量级、低成本的测试。 测试用例的级别测试用例的级别3： ： level0(验收测试，也相当于 bvt 测试) l0 级别的测试用例能够通过意味着产品有被进一步测试的价值，这个级别 的测试是产品质量的基本保证，而且测试的难度相对较小，所以 l0 中典型的测 试用例要求全部实现自动化。 level1(有效性测试) l1 级别的测试用例可以通过意味着对于内部的用户来说是一个有效的产 品，在这个阶段，需要验证一些深层次的正确性的测试用例以及一些简单的集成 性测试，这个阶段结束后，产品进行 beta 版发布，让用户对产品进行公测。 level2(错误性及边界条件的测试) l2 级别测试用例的通过标志着对于内部用户与合作伙伴来说该阶段的产品 不仅是有价值的，而且是健壮的，它可以很好的处理非法行为和操作。这个阶段 需要验证错误性条件、边界条件以及扩展集成的测试用例，这个阶段的结束，意 味着产品进行 rc(release candidate)版的发布。 level3(极端健壮性测试) 用户界面自动化测试的研究与实现 8 l3 级别测试用例的通过标志着对产品真正高质量的保证。这个阶段主要是 对产品进行稳定性、容错能力、极端压力下苛刻的测试。 2.4 测试在产品整个生命周期中的活动 2.4 测试在产品整个生命周期中的活动 具体的测试活动是因项目而异的，下面总结的是在产品的整个开发周期中， 测试在每一个阶段中的任务。 产品定义阶段：开发人员进行早期的产品计划；测试人员主要策划两方面的 问题： (1) 该产品基于哪些新技术。 (2) 产品面对的消费群体。 需求阶段： 开发人员确定产品的功能说明书； 测试人员计划测试采用的标准、 方法和需要使用的工具，做出测试的资源评估。 设计阶段：开发人员设计代码框架并编写开发文档；测试人员设计测试代码 框架编写测试文档，制定出详细的测试计划，包括 bvts 和自动化的设计，安全 性测试的设计、全球化 本地化测试的设计以及性能测试的设计。 实施阶段：开发人员的代码的编写完成；测试人员所有的 bvts 自动化代码 全部完成并且运行全部通过。基本的端到端测试通过。并设计 bvts 级别以上的 测试用例。 验收阶段：开发人员稳定产品代码；测试人员稳定测试代码。在这个阶段， 所有的自动化代码全部完成，安全测试、全球化 本地化的验证、初步的性能测 试通过，评估测试代码的覆盖率，并在需要的地方增加测试用例。 评估阶段：测试人员重新评估测试覆盖率，并在需要的地方增加测试集合。 将自动化代码扩展到其他的平台运行(比如，在 32 位机器上和 64 位机器上运行 有什么不同)，并且通过用户的支持发现产品中存在的问题。 产品发布：测试人员为技术支持做准备。 产品的批量生产阶段：测试人员为产品维护工程师作技术支持。 2.5 测试用例 2.5 测试用例 在测试计划阶段，需要对测试用例进行详细而准确的定义，并要把握好测试 中南民族大学硕士学位论文 9 用例的粒度和分类以及结果的划分，它们对产品的测试质量有着直接影响。 (1)测试用例的定义测试用例的定义 测试用例的定义应该具有独立性，就是说，测试用例的定义需要包含具体的 相关信息，比如，完整的操作步骤、环境及条件。测试用例需要为测试者传达正 确的测试意图。 例如：定义向导 x 第五页中“连接”按钮有效性的测试用例。 好的定义：1 打开向导 x。 进入连接页面。 填入页面必需的数据。 点击“连接”按钮。 通过验证以下信息来确认“连接”按钮的有效性。(具体验证信息略) 差的定义：1 打开向导 x 进入第五页。 验证“连接”按钮是否正常工作。 好的测试用例的定义需要列出详细的操作步骤来传达信息给测试者如何去 做，同时还需要完整的验证过程以及验证信息来正确的描述测试意图。这样就使 得测试人员能够快速、正确的理解测试用例。由于产品在开发阶段是在不断改变 的，向导的页数可能会改变，名字改变的可能性较数字小，所以使用名称来表示 对象比数字更准确。另外，测试用例运行的环境以及一些配置信息都不属于测试 用例定义的一部分，也就是说，测试用例并不局限于一种特定的环境或平台，可 以通过标识的属性信息在不同的环境下测试。 (2)测试用例的粒度 (2)测试用例的粒度 测试用例的粒度要掌握好，不能太小，也不能太大。对于一个给定的特性， 测试用例太少(每一个又包含很多功能的测试)不合理；如果太多，显得很烦琐。 比如，要测试一个 api：loadfile(string filename)，导入不同编码类型(unicode, utf-8 等)的文件将它们定义为不同的测试用例，不需要合并在一起。或者，将 导入一个包含 5 行数据的文件和导入一个包含 10 行数据的文件分成两个测试用 例也是没有必要的。 (3)测试用例的结果类型 (3)测试用例的结果类型 测试用例运行的返回结果可以是 pass 、fail 或 check。check 状态表 用户界面自动化测试的研究与实现 10 示运行结果不确定，需要进行验证。测试用例的运行结果不能是以上三种状态之 外的其他状态，如果一个测试用例在运行过程中超时了，运行测试用例的环境需 要将它的状态设置为 fail，被置为 check 状态的测试用例通过验证最终的结 果也被转为 fail 或是 pass。 (4)测试用例的分类 (4)测试用例的分类 根据测试用例所实现的测试意图，它们被划分为 l0、l1、l2 和 l3 四种级 别。虽然这种划分看起来不难，正确的划分是非常重要的而且并不是很容易。比 如，几乎所有 l0 级别的测试用例都会被归为 bvt suites，当 bug 被解需要被验 证时，一贯的做法就是去运行 bvt suites，因此，所有验证基本功能的测试用例 都需要实现自动化并放入 bvt suites 中。同样，每一个阶段也是以每种级别的 测试用例通过的百分比来定义的。 测试用例的错误分类会导致无效的阶段性发布 标准，产品发布的质量会受到影响。 2.6 测试要求 2.6 测试要求 在产品的测试周期中，不同阶段测试的侧重点是不一样的，对产品多方面特 性的测试类型也是多样的，本文给出以下的测试类型的具体要求。 (1)性能性能 / 压力测试压力测试 性能测试5是检测产品在给定的条件下是否可以正常的工作。一个关于性能 的测试用例的运行结果是否成功取决于其在给定的压力下是如何实现相应的功 能的。产品性能方面发布的标准需要被有关性能的测试用例一一验证。 性能测试是要展现产品所具有的真实的性能，因此，测试代码要能够正确地 衡量哪方面的测试是有意义的以及需要测试到什么程度。 报告性能测试用例的运 行结果比一般的测试用例要求要高， 不仅仅是给出基于一个明确给定的标准下它 的运行结果是成功还是失败， 还要提供与结果相关的详细信息来诊断产品的工作 特性是怎样的。对性能测试而言，数据显示的分析结果是非常有意义的，我们在 进行性能测试时要明确以下几点： (1)测试的目的是什么？我们为什么要这样做？ (2)我们要达到一个什么样的主要效果？与发布标准和客户要求是如何关联 起来的？ 中南民族大学硕士学位论文 11 (3)对于一个具体的操作是否是一个有意义的性能测试？(比如：潜在吞吐 量) (4)测试的瓶颈会出现在哪里？测试执行的具体上下文是什么？(单用户、 多 用户或是当前用户) (5)资源占用情况？(包括处理器、硬盘、输入输出设备、内存消耗、网络吞 吐量等等) (6)取得的硬件参数是什么？需要什么样的硬件配置？ 压力测试6的目标是发现产品中稳定性、健壮性方面的问题，在给定的负载 条件下表现出与常规各种不一致的问题，比如资源泄漏、死锁等现象。 多数情况下，压力测试需要用到更多的诊断工具，比如调试器、页堆栈、性 能监视器、必要的跟踪及日志信息，这些对开发人员和测试人员分析最终的结果 是非常重要的7。产品特征的有效性验证是压力测试的一个重要部分，在给定的 负载条件下去保证系统行为的一致性和正确性；在正确的测试行为下，产品可以 很好的去完成它需要处理的事情， 那么在错误的行为下呢？会导致它的不稳定甚 至崩溃吗？错误的测试条件在压力测试中也是不可少的， 通过各种错误行为的验 证来确保产品在不期望的条件下如何去完美的处理所遇到的问题， 加强产品的健 壮性。 (2)端到端的测试 (2)端到端的测试 端到端的测试是将系统的各个模块作为一个整体来进行测试。 端到端的测试场景需要从功能说明书中用户的实际操作中抽取， 端到端的测 试作为产品发布标准的一部分，它的测试数据除了使用数据产生工具生成的之 外，还要模拟真实世界中的用户数据进行测试。另外，用户配置、安全部署也要 尽量与真实的用户环境相近； 用一个端到端的测试用例将系统的所有模块都包括 是很不现实的，通过一系列的测试用例来覆盖系统的所有部分。理解产品的集成 点(模块与模块之间的接口)是非常重要的8，接口之间的测试采用什么样的顺 序。 所以这个部分的测试要做好， 需要对产品各个模块的结构有一个深入的理解， 这样才能设计出高质量的测试用例来发现产品深层次的问题。 (3)回归测试 (3)回归测试 回归测试是指在产品以前的版本上出现过并且已经解决的问题在新的版本 用户界面自动化测试的研究与实现 12 上是否运行正常。由于回归测试并没有完全实现自动化，所以确认回归测试用例 集很重要。回归测试用例集根据不断增加的问题及时更新，并且统计出有多少实 现了自动化，有多少需要手动测试。对于已经实现自动化的回归测试用例集，需 要将它们反复地运行在不断更新的版本上， 确保以前发现的问题在新版本上已经 解决。回归测试一般在产品发布的前期进行大量、反复的运行。 2.7 环境依赖 2.7 环境依赖 由于产品所面向的用户非常多，且不同的用户有不同的需要。我们需要通过 一系列典型的测试用例来测试产品的配置与部署。 详细的配置信息来自于对用户 需求的理解及相关的需求说明书。需要考虑的问题包括以下几部分。 (1)软件依赖 (1)软件依赖 对于整个产品或是用户所需要的一些具体的功能特性依赖什么样的软件，对 于某些具体的功能是否必须特定的版本， 在不同的环境下产品的执行情况会有哪 些不同，这方面的测试怎样合理地安排在测试计划中。 (2)硬件环境 (2)硬件环境 我们需要考虑测试用例在不同的硬件环境下运行会导致不同的结果。比如， 在单处理器下运行没有出现问题， 但是在多处理器下运行时就会捕获一些由于竞 争条件设置不合理而产生的异常；评估内存大小、硬盘速度、网络速度等硬件参 数对产品的影响，根据重要性程度的划分，确保产品在不同的硬件参数组合下都 能正常运行；评估最低的硬件需求，保证产品在最低的配置下性能不受影响。 (3)机器配置 (3)机器配置 单机配置相对简单， 在一个域中， 使用的是否是域用户？或在一个工作组中， 使用的是否是本地用户？如何连接到指定的网络等等；对于多机的配置，除以上 考虑之外， 还需要考虑将产品的不同模块配置到不同的机器上运行与在单机上运 行有什么差异？哪些模块可以在不同的机器上单独安装？拆分的粒度有多大？ 如何去配置模块的作用域？如何考虑容错处理？对用户的权限由什么样的要 求？(必须是域用户？或者本地用户也可以？)需要考虑哪些安全问题？支持哪 些命名规则等等。 (4)地理分布 (4)地理分布 中南民族大学硕士学位论文 13 如果客户端处于不同的区域或时区，信息的显示格式以及数据在客户端和服 务器间传送的过程中，时间的处理。如何支持多语、多地域的配置等。 (5)安全性 (5)安全性 系统有没有设置防火墙？哪些端口需要被打开？允许哪些协议进行通讯？ 系统是否被指定的一系列测试用例一一验证？ 用户界面自动化测试的研究与实现 14 第第 3 章章 用户界面自动化测试的实现用户界面自动化测试的实现 在软件的开发过程中，大量的测试用例需要被不断的运行来及时地发现存在 的问题以保证软件的质量。为了提高测试效率，一些录制技术被应用到用户界面 的测试中，它们会把用户的每一步操作记录下来，自动生成测试脚本，测试人员 只需要将每一个测试用例手工操作一遍，就可以生成对应的测试脚本，通过运行 这些测试脚本来自动地测试每一个测试用例。 这种自动化测试方法在用户界面不 发生变化的情况下是可行的， 将生成的测试脚本反复运行来及时地发现软件中存 在的问题。 3.1 录制技术在用户界面自动化测试中的不足 3.1 录制技术在用户界面自动化测试中的不足 在正常的软件开发过程中，测试并不是在开发完全结束后才进行的，在测试 的过程中，用户界面是在不断地变化的。脚本的录制过程是根据具体的界面、具 体的操作来生成脚本的，所以脚本的执行界面一旦发生改变，脚本的运行就会出 现异常，甚至仅仅是被操作对象位置的改变都会造成用户界面自动化测试的失 败；另外，脚本录制的过程是固定的，所以脚本的运行会完全按照操作步骤，不 会发生任何改变。这样的测试质量并不一定高。比如：如果要测试一个数据集中 每一个字段都是可排序的，由于每一个测试用例都会反复地运行，为了提高测试 效率，每次只需要随机的选择一个字段进行验证，而不需要将每一个字段都验证 一遍，但是录制出来的脚本是固定的，每次运行，它不会聪明地随机选择，而是 反复的验证被录制下来的某一个字段，其他字段的验证并没有被覆盖到，这并不 是我们所期望的；如果每一次都将每一个字段验证一遍，又会降低测试效率，并 且，在这个过程中，每一个字段的位置、顺序都不能有任何变化，不然脚本运行 同样会失败，每当用户界面发生改变时，我们都需要重新录制脚本。由此可见， 通过录制脚本来实现自动化测试是很难维护的， 它的不易改变性给测试带来了很 大的不方便。 中南民族大学硕士学位论文 15 3.2 手工编写测试代码思想的提出 3.2 手工编写测试代码思想的提出 在目前的软件测试中， 一个备受关注的问题是如何高效地实现用户界面的自 动化测试，并且使测试代码具有很强的灵活性，当用户界面发生变化时，测试代 码能很快地进行更新，对用户界面的变化有很强的适应能力。当测试脚本被录制 下来之后，根据用户界面的改变，脚本也可以做相应的修改。对于自动生成的脚 本可读性并不强，与其把时间浪费到对脚本的不停修改中，还不如手工编写测试 代码。手工编写代码的灵活性很高，可以根据自己的意愿添加录制所不能实现的 测试逻辑，另外，代码的可读性较高，为代码的更新和维护带来了很大的方便。 通过以上分析， 我们所选用的这种新的实现自动化测试的方法是从手工编写测试 代码开始的。 3.3 采用的技术方案 3.3 采用的技术方案 编写测试代码需要考虑如何在代码中定位需要被验证的用户界面元素的解 决方案。较常用的一种方法是根据元素在界面的坐标来定位，这种方法实现起来 比较简单， 但是只要元素在界面上的位置发生变化， 或者屏幕的分辨率有所改变， 元素的定位就会失败。由于我们的目标是实现自动化，希望在尽量减少人为干预 的情况下，使代码有较强的适应性和智能性。对于用户界面上的每一个元素，都 可以把它当作一个对象，我们把这些对象转化为所设计的自动化对象，然后再对 它进行操作。 本文采用 picasso 技术9作为底层的技术支持。picasso 为测试组进行用户界 面的自动化测试提供一个通用的框架，实现自动化对象的生成、定位以及与系统 事件的交互。 使用 picasso 提供的 dll 中的抽象类和接口进行被测试的具体用户界 面的封装，来实现基于对象捕捉的用户界面自动化测试。 这种方案虽然很灵活，但实现起来比坐标定位要复杂。在将用户界面上的元 素转化为自动化对象时，需要传递必要的参数信息，而这些信息在用户界面上是 不可见的，比如控件的名字、类型、位置、可见性、可选性及可编辑性等等，为 了方便自动化代码的编写，picasso 还提供与编成接口配套的可视化反编译工具 accexplore,这些信息可以通过 accexplore 来获取。如图 3-1 所示。 用户界面自动化测试的研究与实现 16 图 3-1 picasso 提供的可视化反编译工具界面信息图 在用户界面自动化测试的开发过程中，我们以 picasso 技术提供的抽象类和 接口为基础，通过可视化的反编译工具获取需要的控件信息，实现界面元素类的 封装，并为模拟多种界面的操作提供丰富的接口，搭建基于 picasso 的自动化测 试的框架，在此框架的基础上，实现测试用例的自动化。 因此，基于 picasso 的自动化测试的实现主要分为三层。 picasso 层：picasso 所提供的抽象类、鼠标类、键盘类和事件等待类。 框架层：在 picasso 技术的基础上，进行所要测试的用户界面元素的封装， 为模拟用户的自动化操作提供丰富的接口。 测试层：利用框架层提供的方法实现测试用例的自动化。 3.4 picasso 层 3.4 picasso 层 用户界面的自动化测试要解决的核心问题是如何正确有效地进行界面元素 的操作。在操作对象之前，首先需要解决怎样定位目标元素，然后通过鼠标、键 盘事件触发一定的操作，当事件之间有顺序关联性时，要自动化地实现在正确的 时间做相应的操作。根据以上分析，至少需要四个类来完成以上要求。它们分别 是：界面元素类、事件等待类、鼠标类和键盘类。这就是 picasso 所提供的四大 基础类：abtractobject 类，waiter 类，mouse 类和 keyboard 类 中南民族大学硕士学位论文 17 3.4.1 界面元素类用户界面中控件元素的抽象界面元素类用户界面中控件元素的抽象 在用户界面上存在有多种不同的控件类型，例如：菜单、按钮、工具拦、列 表框和对话框等等。不同类型的控件，实现也是不同的。picasso 用一个统一的 类把它们抽象出来，进行统一的操作。picasso 实现对界面元素检索和定位以及 捕捉控件对象的状态等机制又以下几部分实现。 (1)枚举标识 (1)枚举标识 我们为这个抽象的类定义出三种枚举类型的成员变量来标识对象的相关信 息，它们分别是：选择标记、角色和状态。根据在定义列表中的不同选项来执行 不同的功能操作。 通过构造函数或调用定义的静态方法来获取运行界面中第一个被检索到的 控件元素。 (2)构造函数 (2)构造函数 定义的构造函数如下： abstractobject(int windowhandle)对于一个正在运行的用户界面程序， 它所包含的窗体句柄是可以获得的， 将窗体句柄信息作为参数传递给构造函数可 以将要获取的控件对象转化为抽象出来的自动化对象。 abstractobject(string winclassname,string name)在程序的运行阶段，如 果可以获得控件窗体的类型名以及控件本身的名字， 可以通过参数形式传递给构 造函数将要获取的控件对象转化为被操作的自动化对象。 (3)静态方法 (3)静态方法 getfocusedwindow()返回当前获得焦点的自动化对象窗体， 获得焦点状 态的窗体可以接收所有来自键盘的消息。 gettopforegroundwindow()返回出现在屏幕最前方的窗体。与前面一种 返回对象的区别是这个窗体是一个叠加的窗体，也就是说在这个窗体的里面，还 包含若干个小窗体(每一个控件都可以看作是一个窗体)。 getformpoint()返回在屏幕上包含某个坐标点的窗体，在用鼠标点击这 用户界面自动化测试的研究与实现 18 个坐标点时，这个窗体对象能够处于获得焦点状态。 (4)属性定义 (4)属性定义 string name当前用户界面元素的名字 string value当前用户界面元素的值 rectangle position当前用户界面元素在显示屏的位置 roles role当前用户界面元素的类型 int childcount当前用户界面元素所包含的子控件的个数 abstractobject children当前用户界面元素包含的所有子控件对象 abstractobject parent当前元素的父窗体对象 int windowhandle当前元素的窗口句柄 string windowclassname当前元素所属窗体类型的名字 bool issimpleobject如果当前元素属于简单对象，则不包含任何子控件 (5)成员函数的定义 (5)成员函数的定义 abstractobject findchild(xxx)这是自动化对象最经常使用的一个方 法，定义了多个重载函数，可以根据不同的参数进行具体对象的查找。它的功能 很强大，不仅可以查找直接路径中的子元素，而且可以检索到任意深度层次和路 径的子元素。除此之外，它还具有两个特殊的功能：如果自动化对象被定义为应 用程序的主窗体，而当前出现在屏幕最前面的是另一个窗体，并且要查找的元素 处于屏幕最前方的窗体中。例如：在应用程序的主窗体中，打开“打开文件”对 话框，可以通过主窗体定位到“打开文件”对话框中的子元素；另一个特性是在 父窗体是可见的条件下，要查找的子窗体同样具有可见性。例如，在查找列表框 中的某一项时，如果这一项存在但在列表框中是不可见的，此方法会自动定位被 查找项，甚至可以拖拉滚动条将它显示出来。目前，只有一部分控件实现了这个 特性，比如：列表框、组合框和树状视图，对于其他控件的操作，我们可以根据 类似的方法自己封装。 bool checkstate(states state)一个界面元素同时可以包含多个状态，比 如，对于一个控件，它既是可选的，又是可编辑的，而且是可见的等等。使用这 个方法可以很方便的检查自动化对象具有的状态信息。 中南民族大学硕士学位论文 19 bool select(selectflags)选择自动化对象，并作选择标记，可以同时选择 多个对象。 bool avtivate()当我们不确定所要操作的自动化对象是否处于激活状态 时， 可以使用它来获取焦点。 当然， 对于不同的控件， 激活的效果也是不一样的。 例如：激活一个编辑框可以使它获得焦点；激活一个对话框可以使它的某一个子 控件获得焦点。 bool dodefaultaction()对于不同的界面元素，默认行为是不一样的。如 果自动化元素是一个按钮对象，默认行为可以设计为用鼠标左键单击它。默认行 为是根据控件自身的特点设计出最符合它的特征的行为。 3.4.2 waiter 类类 在系统的进程类中定义了一个叫做 sleep()的休眠方法，在进行某些操作之 前必须等待必要的资源或等待其它操作的完成或等待要操作对象的出现及结束。 这些时候，系统会通过调用 sleep()方法进行相关的协调，在用户界面的自动化 测试实现中，由于具体情况下等待的类型并不相同，对它们分别进行处理是非常 必要的。 bool waitforstatechange(abstractobject ao,abstractobject.states state) 在进程之间的交互中，这个方法是非常有用的。比如：当服务器进程结束时，它 所对应的用户进程也将变得失效，受机器性能的影响，可以根据用户界面状态的 变化来判断用户进程何时失效，这样即使服务器进程已经