软件测试自动化研究与应用

姓名：岳媛申请学位级别：硕士专业：软件工程指导教师：王保保;张吉龙

20080101

摘要软件测试在软件的整个开发过程中占有非常重要的地位，是保证软件质量、提高软件可靠性的关键。随着软件设计技术的发展，软件规模的增加，软件开发周期的缩短，软件测试工作量的增大，使用软件测试自动化技术提高软件测试的速度和效率，缩短软件开发周期，降低测试成本就成为了软件测试发展的必然趋势。因此，开发有效的、可重复的、操作简便的自动化测试工具是很有价值的。本文以ｇｃＭｕｌｔｉＲｏｗ５．０产品为背景，深入研究基于该产品的自动测试技术，指出了测试与自动测试的区别及测试的一般过程。随后分析市场上的软件测试工具，并针对它们的局限性研究和开发了一个自动化测试工具。考虑到基于．Ｎｅｔ控件产品的实际特点，该工具能够根据测试用例自动测试ｇｃＭｕｌｔｉＲｏｗ５．０产品的各种功能，并且可以存储生成的测试结果。关键词：软件测试自动化测试用例自动化测试工具ＡｂｓｔｒａｃｔＴｈｅｓｏｆｔｗａｒｅｔｅｓｔｐｌａｙｓａｌｌｉｍｐｏｒｔａｎｔｒｏｌｅｉｎｔｈｅｗｈｏｌｅｄｅｖｅｌｏｐｍｅｎｔｐｒｏｃｅｓｓｏｆｓｏｆｔｗａｒｅ．Ｉｔｉｓｔｈｅｋｅｙｔｏｋｅｅｐｔｈｅｑｕａｎｔｉｔｙａｎｄｉｍｐｒｏｖｅｔｈｅｒｅｌｉａｂｉｌｉｔｙｏｆｓｏｆｔｗａｒｅ．Ｗｉｔｈｔｈｅｄｅｖｅｌｏｐｍｅｎｔｏｆｔｈｅｓｏｆｔｗａｒｅｄｅｓｉｇｎ，ｔｈｅｉｎｃｒｅｍｅｎｔｏｆｔｈｅｓｏｆｔｗａｒｅｓｃａｌｅ，ｔｈｅｓｈｏｒｔｅｎｏｆｔｈｅｓｏｆｔｗａｒｅｄｅｖｅｌｏｐｍｅｎｔｌｉｆｅｃｙｃｌｅ，ｔｈｅａｕｇｍｅｎｔｏｆｔｈｅｗｏｒｋｌｏａｄｏｆｓｏｆｔｗａｒｅｔｅｓｔ，ｉｔｉｓｔｈｅ岫ｅｖｉ诅ｂｌｅｔｒｅｎｄｏｆｔｈｅｅｖｏｌｕｔｉｏｎｏｆｓｏｆｔｗａｒｅｔｅｓｔｔｅｃｈｎｏｌｏｇｙｔｈａｔｕｓｉｎｇｓｏｆｔｗａｒｅｔｅｓｔａｕｔｏｍａｔｉｏｎｔｅｃｈｎｉｑｕｅｆｏｒｉｍｐｒｏｖｉｎｇｔｈｅｓｐｅｅｄｓａｎｄｅｆｆｉｃｉｅｎｃｉｅｓｏｆｓｏｆｔｗａｒｅｔｅｓｔ，ｓｈｏｒｔｅｎｉｎｇｔｈｅｓｏｆｔｗａｒｅｄｅｖｅｌｏｐｍｅｎｔｌｉｆｅｃｙｃｌｅ，ａｎｄｒｅｄｕｃｉｎｇｔｈｅｃｏｓｔｏｆｓｏｆｔｗａｒｅｔｅｓｔ·ｎｅｒｅｆｏｒｅ．ｉｔｉｓｖｅｒｙｖａｌｕａｂｌｅｔｈａｔｄｅｖｅｌｏｐｉｎｇａｌｌａｕｔｏｍａｔｅｄｔｅｓｔｔｏｏｌｗｈｉｃｈｉｓｅｆｆｅｃｔｉｖｅ，ｒｅｕｓａｂｌｅ．ａｎｄｍａｎｅｕｖｅｒａｂｌｅ．ＴｈｉｓｐａｐｅｒｉｎｔｈｅｂａｃｋｇｒｏｕｎｄｏｆｇｃＭｕｌｔｉＲｏｗ５．０ｇｏｅｓｄｅｅｐｉｎｔｏｔｈｅｔｅｃｈｎｏｌｏｇｙｏｆｔｅｓｔａｕｔｏｍａｔｉｏｎ．Ｉｔａｎａｌｙｚｅｓｔｈｅｄｉｆｆｅｒｅｎｃｅｂｅｔｗｅｅｎｍａｎｕａｌｔｅｓｔａｎｄａｕｔｏｍａｔｅｄｔｅｓｔａｎｄｔｈｅｇｅｎｅｒａｌｐｒｏｃｅｓｓｏｆｓｏｆｔｗａｒｅｔｅｓｔ．Ｔｈｅｎｉｔａｎａｌｙｚｅｓｔｈｅｓｏ胁ａｒｅｔｅｓｔｔｏｏｌｓｏｎｔｈｅｃｕｒｒｅｎｔｍａｒｋｅｔ．Ａｉｍｉｎｇａｔｔｈｅｉｒｄｉｓａｄｖａｎｔａｇｅ，ｉｔｄｅｖｅｌｏｐｓａｆｕｌｌｙａｕｔｏｍａｔｅｄｔｅｓｔｉｎｇｔ００１．Ｃｏｎｓｉｄｅｒｉｎｇｒｅａｌｉｓｔｉｃｃｈａｒａｃｔｅｒｉｓｔｉｃｓｏｆｃｏｍｐｏｎｅｎｔｐｒｏｄｕｃｔｂａｓｉｎｇｏｎ．Ｎｅｔ，ｔｈｉｓｔｏｏｌｔｅｓｔｓｄｉｆｆｅｒｅｎｔｆｕｎｃｔｉｏｎｓｏｆｇｃＭｕｌｔｉＲｏｗ５．０ａｕｔｏｍａｔｉｃａｌｌｙｂａｓｅｄｏｎｔｅｓｔｃａｓｅ．ａｎｄｉｔｓｔｏｒｅｓｔｅｓｔｒｅｓｕｌｔａｆｔｅｒａｕｔｏｍａｔｅｄｔｅｓｔ．Ｋｅｙｗｏｒｄ：ＳｏｆｔｗａｒｅＴｅｓｔＡｕｔｏｍａｔｉｏｎＴｅｓｔＣａｓｅＡｕｔｏｍａｔｅｄＴｅｓｔＴｏｏｌ创新性声明本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含其他人已经发表或撰写过的研究成果；也不包含为获得西安电子科技大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均己在论文中做了明确的说明并表示了谢意。申请学位论文与资料若有不实之处，本人承担一切相关责任。本人签名：关于论文使用授权的说明本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。本人保证毕业离校后，发表论文或使用论文工作成果时署名单位仍然为西安电子科技大学。学校有权保留送交论文的复印件，允许查阅和借阅论文；学校可以公布论文的全部或部分内容，可以允许采用影印、缩印或其它复制手段保存论文。日期型墨：圣！苎日期沁弓工日期一邶哆Ｌ第一章绪论第一章绪论１．１项目背景在ＩＴ产业迅速发展的今天，人们对于硬件在质和量方面的飞速发展有着深刻的印象。虽然软件在量的方面的发展同样的迅速，上千行的大型系统软件以及百万行的应用软件已经屡见不鲜。但相对而言，软件的质量却一直是一个存在的问题。随着软件规模的扩大，对于质量的保证已经成为了一项艰苦的工作。这无疑是一种挑战，人们面对这种挑战，提出了很多软件过程方法，力图通过一系列的开发过程保证软件的质量。这些努力当然是创造高质量软件产品的有效方法。但迄今为止，对软件进行测试依然是保证软件质量最重要和最有效的方法。软件测试在软件的整个开发过程中占有非常重要的地位，是保证软件质量、提高软件可靠性的关键。软件测试的工作做得怎样，直接决定着软件产品的好坏。大量统计资料表明，软件测试阶段投入的成本和工作量往往要占软件开发总成本和总工作量的４０％到５０％甚至更多［１１。随着软件规模的增加，测试工作量的增大，软件开发周期的缩短，原本的手工测试已经不能够满足需要。使用软件测试自动化技术提高软件测试的速度和效率就成为了软件测试发展的必然趋势。使用软件测试自动化技术能够完成很多手工测试无法实现或难以实现的测试。正确、合理的实施自动化测试，能够快速、彻底的对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。另外，自动化测试还能排除一些人为的因素（如遗漏，手误等）。今天，市场上已经拥有很多的软件测试工具，这些工具也具有一定的自动化（执行反向工程和编写测试脚本），但是对于具体的产品项目依然存在不足。因此，针对它们的不足，以及结合具体的项目需求，本课题研究新的软件测试自动化工具。目前，在软件测试研究领域，虽然取得了一些成果，但对具体的开发环境下开发的特定领域的软件系统应采取怎样的测试方法对其进行全面的，完整的测试，依然没有具体的标准可以遵循。并且软件测试的自动化技术还无法跟上当今软件项目的复杂性和先进技术。完全自动化的软件测试工具，即能够完成自动生成测试脚本、构成测试案例、报告测试结果等一系列的测试任务，还需要进一步的研究。软件测试自动化研究与应用１．２项目来源ｇｃＭｕｌｔｉＲｏｗ项目的ｇｃＭｕｌｔｉＲｏｗ５．０产品面向日本市场，是．Ｎｅｔ平台下拥有强大功能的控件产品。在产品的开发过程中，为了保证质量，软件测试占了很重要的作用。而且由于ｇｃＭｕｌｔｉＲｏｗ５．０产品的复杂性和重复性，产品提供给客户的属性、方法和事件很多，如果全部用手工测试具有一定的局限性，因此自动化测试就成为了最佳选择。采用自动化测试，首先可以提高测试效率，使测试工程师更加专注于新的测试模块的建立和开发，从而提高测试覆盖率；其次，自动化测试使测试资产的管理数字化，并使测试资产得以在整个测试生命周期内得到复用，这个特点在功能测试和回归测试中尤其具有意义；此外，通过测试流程的自动化管理使机构可以通过流程的关键绩效指标（ＫＰＩ，ＫｅｙＰｅｒｆｏｒｍａｎｃｅＩｎｄｉｃａｔｏｒ）来衡量测试过程的有效性，从而实现了从软件质量保证向软件质量管理（ＳＱＭ，ＳｏｆｔｗａｒｅＱｕａｌｉｔｙＭａｎａｇｅｍｅｎｔ）的进化。根据ＯｐｐｅｎｈｅｉｍｅｒＦｕｎｄｓ的调查，在２００１年前后的３年中，全球范围内由于采用了测试自动化手段所实现的投资回报率更高达１５００％。最近，Ｒａｔｉｏｎａｌ、ＩＢＭ和其它一些公司开展了一个开发源码的项目，其目标就是要把这两个百分数颠倒过来。该项目被命名为Ｈｙａｄｅｓ，取自Ｅｄｄｉｎｇｔｏｎ用来校验爱因斯坦理论的星云的名字，并由Ｅｃｌｉｐｓｅ．ｏｒｇ负责。它的目标也包括加强实验性观察，测试过程及软件度量，最终实现更具实用性的测试自动化。对于使用Ｅｃｌｉｐｓｅ的开发人员和测试工程师来说，Ｈｙａｄｅｓ既是一种集成测试及跟踪，也是环境监控程序。Ｅｃｌｉｐｓｅ为整个测试过程提供了标准、工具和互操作性，以使测试能更早地移植到应用生命周期中去。对ＡＳＱ提供商和集成商来说，Ｈｙａｄｅｓ为自动化测试、跟踪、预定义、监控和资源管理提供了一个可扩展的架构和平台。和目前的测试与跟踪工具所不同的是，Ｈｙａｄｅｓ将提供一个统一数据模型（实现了ＵＭＬ测试预定义），这是一种标准的用户工作的流程，包括一套统一的ＡＰＩ及相关工具，可以在排列的目标项之间连续地工作。虽然目前市场上已经拥有很多软件测试工具，这些工具也具有一定的自动化（执行反向工程和编写测试脚本），但是它们经常呈现出以下不足：＞测试脚本经常需要调试。＞不能独立的完成整个测试过程。＞测试执行的过程与待测试软件设计不相一致。＞反向工程过程与测试脚本的生成相分离。为了弥补这些不足，根据ｇｃＭｕｌｔｉＲｏｗ５．０产品的实际情况和特点，需要研究软件测试自动化技术，并提出ｇｃＭｕｌｔｉＲｏｗ５．０的自动化测试方案。第～章绪论１．３项目期间主要完成任务的工作本次课题的内容是根据葡萄城ｇｃＭｕｌｔｉＲｏｗ５．０产品的特点，在熟悉产品功能的基础上，分析测试中存在的自动化测试的问题，并有针对性的进行解决。在解决过程中遵循软件测试的原则，按照测试项目组的建议，设计合理的自动化测试工具。该工具采用．Ｎｅｔ平台、Ｎｕｎｉｔ框架和ＵＩ测试自动化技术。将软件测试自动化的一些相关理论方法应用到实际开发过程中去，保障了整个产品的质量。本文的研究内容是ｇｃＭｕｌｔｉＲｏｗ５．０产品自动化测试方面的重要部分，本文作者主要完成以下几个方面的工作：一、项目开始前期。阅读有关软件测试技术书籍、自动化测试书籍、Ｃ拌编程书籍和．Ｎｅｔ框架设计书籍。了解国内外关于自动化测试的一些情况。阅读ｇｃＭｕｌｔｉＲｏｗ原有自动化测试工具的有关文档和代码。二、研究产品的功能，对自动化测试进行需求分析，与测试团队的工程师们一起对自动化测试工具进行设计，确定自动化测试应具有的功能，然后参考上一版本的自动化测试工具的成功进行框架设计。三、和测试团队的工程师们一起开发出自动化测试工具，并运用该工具对产品进行自动化测试，分析自动化测试结果，提交测试出来的所有ｂｕｇ。１．４章节安排本论文主要对软件测试自动化技术研究和实现。第一章：绪论本章介绍了论文研究背景、内容和组织安排。第二章：软件测试自动化概述本章介绍了软件测试自动化的相关知识，并对软件测试自动化的优缺点进行了介绍。第三章：软件测试自动化工具概述本章首先介绍了软件自动化测试生存周期，紧接着对市场上现有的测试工具作了详细的介绍，在此基础上，提出自动化测试工具的任务和挑战。第四章：软件测试自动化工具的技术原理本章对ＡｕｔｏＴｅｓｔｅｒ自动化测试工具进行了总体描述，讨论了该工具的技术原理，以及具体的应用。第五章：软件测试自动化的应用本章详细阐述了ＡｕｔｏＴｅｓｔｅｒ自动化测试工具的实现情况，并对测试方法和测试４软件测试自动化研究与应用结果做了详细的介绍。第六章：结束语本章主要介绍了自动化测试工具的完成后情况以及下一步需要改进的地方。第二章软件测试自动化概述第二章软件测试自动化概述软件工程的重要环节就是软件测试。它在软件生存期中占有非常突出的重要位置：它直接关系到软件的质量、开发速度和成本。随着软件设计和编码技术的快速的发展，软件设计和编码的效率得到非常大的提高。然而软件测试的工作量与过去相比并未减少。相反，在整个软件生命周期中，所占比例呈不断上升趋势。为提高软件开发的效率和软件质量，将测试自动化替代一部分手工测试是实现这一目标的非常有用的方法。自动化测试就是希望能够通过自动化测试工具或是其他手段，按照测试工程师的预定计划进行自动的测试，其目的是减轻手工测试的劳动量，同时达到提高软件质量的目的：它涉及到测试流程、测试体系、自动化编译、持续集成、自动发布测试系统以及自动化测试等方面。２．１自动化测试定义与标准２．１．１自动化测试定义什么是自动化测试？根据软件质量工程协会关于自动化测试的定义：自动化测试就是利用策略、工具等，减少人工介入非技术性（ｕｎｓｋｉｌｌｅｄ）、重复性（ｒｅｐｅｔｉｔｉｖｅ）、冗长（ｒｅｄｕｎｄａｎｔ）的测试活动。其实，软件自动化测试就是执行用某种程序设计语言编制的自动测试程序，控制被测试软件的执行，模拟手动测试步骤，完成全自动或是半自动测试。全自动测试就是指在自动测试过程中，根本不需要人工干预，由程序自动完成测试的全过程。半自动测试就是指在自动测试过程中，需要由人工输入测试用例或选择测试路径，再由自动测试程序按照人工制定的要求完成自动测试【３１。与其它产品相同，软件在给消费者使用之前必须先进行测试。随着软件复杂性的增长，测试的数量也随之增长。由于相同的测试必须被经常的重复，并且手工执行测试本身也占用大量的时间。因此越来越迫切的需要测试的自动化。在实际中，为了保证软件的质量，必须按照软件工程的方法，在软件生命周期的各个阶段进行有效的管理和度量，而软件测试是软件生命周期的重要阶段。目前软件测试普遍采用传统的测试方法，即白盒测试和黑盒测试【４ｌ。在测试工具上大多采用手工测试，或编制一些简单的测试程序进行测试，既耗时间又不规范。更大的隐患在于当将软件分发给用户使用时，常常会发生问题，严重时导软件测试自动化研究与应用致系统瘫痪。自动测试技术目的在于消除手工测试中人为的错误，加快测试循环，有效利用资源，提高工作效率。同时，使测试具有一定的规范性，提高测试的可重复性。２．１．２软件测试自动化标准要成功的实现软件测试自动化，需要周密的计划和大量艰苦的工作，软件测试自动化的开发人员首先必须清楚地认识到应该自动化什么。以下几条可以作为自动化软件测试的标准（５】：１．自动化回归测试从软件测试自动化的目的知道，软件测试自动化所获得的好处来自于自动化测试工具的重复使用，所以应该把回归测试作为自动化的首要目标。软件自动化测试的设计和开发人员应该自动化那些在每个软件的ｂｕｉｌｄ版都要进行的测试。也就是基于自动化那些需要重复进行的测试，一次性的测试是不值得自动化的。２．自动化对稳定的应用的测试在自动化某一个应用的测试之前，首先应该确定该应用是否稳定。如果应用发生改变，相应的自动测试代码就要随之改动，这样一个在将来可能发生变化的应用的测试进行自动化是没有必要的。所以，应该只自动化稳定的应用的测试。３．自动化没有时间依赖性的测试不要自动化与复杂的时间问题相关联的测试。自动化一个与复杂的时间问题相关联的测试的工作量是自动化不具备时间依赖性的测试的工作量的许多倍，并且最后的结果也很难满足测试的要求。作为软件自动化的开发人员必须清楚的认识到：如果一个测试很难自动化，那就应该把它留给手工测试。１００％的自动化并不是追求的目标，把一些过于复杂的测试仍然用手工方式进行是合理的。４．自动化重复性测试如果一个测试经常重复使用，并且使用这个测试不方便，那么就应该考虑自动化这个测试。５．自动化已经实现的手工测试用例在对软件测试自动化前，通常已经有了很多实现的详细的手工测试用例，从中选择可以自动化的手工测试用例自动化。６．合理限制自动化的范围上面提到１００％的自动化测试并不是追求的目标。过大追求自动化的范围只会取得适得其反的后果。软件测试自动化的开发人员应该在一个合理的可以进行自动化的范围内投入精力，在能力许可的情况下，逐步扩大测试自动化的范围。第二章软件测试自动化概述２．２自动化测试的意义２．２．１手工测试和自动测试比较手工测试的目的在于发现新缺陷，而自动化测试则是在于发现老缺陷。软件测试可以采用手工测试和自动测试的方法。在传统的手工测试方法中，测试工程师根据测试大纲中所描述的测试步骤和方法，由手工的输入测试数据，记录测试结果。手工测试的特点是能详细的测试软件的各个功能，测试速度由人来控制，能够完整而从容的观察软件的运行情况并立即报告测试结果。手工测试无法保证测试的科学性与严密性，这是因为：＞测试工程师要负责大量文档、报表的制定和整理工作，会变得力不从心。＞受到软件开发周期、开发成本以及开发人员、资源等诸多方面因素的限制，难以进行全面的测试。＞如果修正缺陷所花费的时间相当长，回归测试将变得异常困难。＞对测试过程中发现的大量缺陷缺乏科学、有效的管理手段，责任变得含糊不清，没有人能向决策层提供精确的数据以及度量当前的工作进度和效率。＞反复测试带来的倦怠情绪以及其他人为因素使得测试标准前后不一致，测试花费的时间越长，测试的严格性也就越低。＞组织一次多用户的测试如同打一场战役，但效果不明显。＞难以对不可视对象或对象的不可视属性进行测试。正是由于手工测试的局限性，因此，自动测试成为了解决问题的最佳方案。对于那些步骤与方法相对固定的测试可以采用自动测试方法。自动测试可以大规模的提高测试效率，减少测试工作量，具有可重复性，可以精确的再现以前的测试步骤，有利于进行回归测试，可以降低人为的操作失误和对测试工程师的技术要求，从而降低测试成本，大大节约软件产品整个开发周期的费用，提高软件的质量。以一个典型的软件产品来考虑，尽管开发自动测试会有一定的开销，但只要进行２．３次以上的测试，自动测试方法将会降低软件测试总的开销。从图２．１可以直观的看出自动测试是如何降低测试的总开销的１１２１。自动测试方法的根本目的就是有计划的设计测试过程，自动地对软件产品在各种环境和状态下的执行进行测试，排除影响测试的人为因素，从而降低花费在测试上的开销。自动测试方法的意义在于使测试过程变得更加系统化、有计划的过程，能够被更迅速、更正确、更经济的完成。软件测试自动化研究与应川圈２１手工测试与自动剽试在软件测试开销上的对比因此，测试是重要的，而不仅仅是需要的。实践汪明，若采用了自动化测试程序的可靠性和质量都会得到提高，在一定程度上也减少了开发的成本。２２２测试和自动化测试的联系根据ＩＥＥＥ的定义（１９８３）ｍ１，软件测试是使用人工或自动手段来运行或测定某个系统的过程，其目的神一于检验它是否满足规定的需求或弄清预期结果和实际结果之问的差别，尽可能发现存在的缺陷它的目标是以较少的测试用例、时间和人力找出软件中潜在的各种错误和缺陷以确保系统的质量。软件测试是由一系列有序活动组成的，始丁测试计划，着重测试开发。软什测试自动化是针对这一系列活动及其管理的自动化，包括软件测试过程规范管理的自动化和软件测试活动的自动化。测试策划是建立测试目标以及实现日标的测试策略。通常．测试开发是指对软件测试用例的开发，包括５个不同活动：即标泌测试需求条件、设计测试用例、建立测试（软件、脚本、数据等）、执行测试用例和比较结果（如图２．２）。第二章软件测试自动化概述标识测试条件和测试优先级设诤渊试瑚傀建立测试（设计脚本、数据镎）执行铡试片ｊ德：ｌ｛ｆ测试用馕的输晰结果与划塑输出比较图２．２测试开发过程的活动１．标识测试条件标识测试条件确定测试“什么＂，并最好定义好这些测试条件的优先顺序。测试条件是被测环境的描述，可以用不同的方法来描述，如简单语言描述表格形式世号手０测试条件取决于被测试的系统。一个系统可能有许多不同的测试条件，并且测试不同的方面，如功能测试、性能测试和安全性测试等。２．设计测试用例设计测试用例确定“怎样’’测试。测试用例是按一定顺序执行的与测试目标相关的一系列测试。测试用例设计将产生测试所需要的输入值、期望结果以及其它任何运行测试的相关信息。期望输出包括应输出或建立的内容、应修改或更新的内容和应删除的内容。期望输出集可以是一个很大的集合。３．建立测试用例建立测试用例包括准备测试脚本、测试输入、测试数据以及期望输出。测试脚本是具有正规语法的数据和指令的集合，在测试执行工具中，通常以文本形式存在。一个测试脚本可以实现一个或多个测试用例。测试脚本可以手工也可以非手工执行。测试输入和期望输出可以包括在脚本中，也可以以脚本外的文件或数据库的形式存在。４．执行测试用例在被测软件运行时使用测试用例。对于手工测试来讲，测试者按事先准备好的测试过程手工进行测试。测试者输入数据、观察输出、记录发现的问题。软件测试自动化研究与应用５．将测试结果与期望结果比较对每次测试的事件输出进行分析研究，判断软件功能是否正确。这种验证以是非正式的测试者的判断。也可以是输出结果和期望结果的正式比较。一般情况下，如果软件实际输出与期望输出一致，则通过测试；如果不一致，则没有通过测试。当然这个规则有点简单，实际输出与期望输出不一致有很多原因。比如软件不正确、测试顺序不对、期望输出的结果不正确、测试环境设置不正确等。所以，在实际中，还需要仔细分析结果不一致的原因，然后作出判断。测试开发过程中的５个活动具有各自的特点，这些特点也就决定了哪些测试可以作为自动化测试，哪些不可以。这５个活动的特点体现在图２．３中。适＇甩ｊ：自动化图２．３测试开发过程中５个活动的特点根据图２．３中所示，测试开发的前３个活动主要是依赖于软件测试工程师的创造性智慧，这些智力活动在软件测试过程中只执行１次，对这部分活动只能实现一定程度的自动化，尤其应引起高度重视的是，这些活动的质量决定测试用例的质量。为了有效地提高软件测试质量，必须提高测试工程师的技术水平、综合质量和实践经验。而测试开发的后２个活动是需多次执行的机械活动，其测试自动化容易实现，但有时也必须实现。对于那些手ＩＮ试很难完成的测试（如压力测试、并发测试、大数据量测试、多次执行的回归测试、测试数据的动态生成与输入、测试用例的实时调度与管理、测试结果的动态获取与记录等）就必须测试软件或测试工具进行自动管理控制，以实现软件测试工作的可行和高效。２．３自动化测试的原则软件测试自动化不能解决测试中的所有问题，也不意味着任何软件测试都可以自动化。要成功的实现软件测试自动化，需要周密的计划和大量艰苦的工作，软件测试自动化人员应该根据实际情况，弄清楚自动化的对象和目的，然后做出第二章软件测试自动化概述相应的选择。所有的测试活动都可以手工进行，正如测试工程师多年所做的那样。所有的测试活动也在某种程度上由于工具的支持而获得益处，但是应该将最可能获利的活动进行自动化。在前面所述的五个测试活动中，测试活动的前两个，即标识测试条件和设计测试用例，主要是智力活动，它们决定着最终测试用例的质量，就整体而言只执行一次，并不适合进行自动化；而后两个活动，即执行测试用例和检查测试结果，主要是机械活动，一般要执行多次，比较适合进行自动化。此外，测试执行和比较活动要重复多次，而标识测试条件和设计测试用例一般只执行一次。例如，测试中发现软件有错误，软件修改后要重新执行测试和检查测试结果。当软件修改时，为确保不引起其他错误，需要进行回归测试。回归测试将重复测试执行和比较（也可能包括测试建立）。总之，对重复的活动进行自动化是合适的［９，２０ｌ。在进行自动化测试前，首先要建立一个对软件测试自动化的认识观。软件测试工具能提高测试效率、覆盖率和可靠性等，自动化测试虽然具有很多优点，但它只是测试工作的一部分，是对手工测试的一种补充。那种不稳定软件的测试、开发周期很短的软件、一次性的软件等不适合自动化测试。因此，自动化测试并非是和所有的公司、所有的项目。自动化测试绝不能代替手工测试，它们各有各自的特点，其测试对象和测试范围都不一样。多数情况下，手工测试和自动化测试应该相结合，以最有效的方法来完成测试任务。２．４软件测试自动化的优缺点２．４．１自动化测试的优点自动化测试的优点是同手工测试比较所体现出来的。与手工测试相比，自动化测试具有手工测试无法比拟的优点，且可以执行一些手工测试不可能或很难完成的测试。＞有些非功能性方面的测试。压力测试、并发测试、大数据量测试和崩溃性测试，用手工测试是不可能达到的。例如，对于１００个用户的联机系统，用户手工进行并发操作是几乎不可能的，但自动测试可以模拟来自１００个用户的输入。＞提高测试的效率，尤其是运行冗长而复杂的测试时，自动化是必需的。软件测试自动化研究与应用．某些测试序列可能包括成百甚至上千条测试消息，这样的测试用手工设置和评价，常常是不可行的。为了能够准确地重复一个冗长序列，必须实现测试自动化。自动化测试不需要测试工程师每次都重复相同的过程。当自动化测试建立起来后，就可以多次重复执行，大大提高测试的效率。测试工程师从繁重的测试执行中解脱出来，可以投入更多的精力来设计更多更好的测试用例。＞提高测试的准确性，降低对测试工程师的技术要求。手工测试需要测试工程师理解测试步骤和被测软件，并按照测试步骤一步一步地执行。在执行过程中，面对大量的测试数据，测试工程师难免会犯错误，这些都会影响测试的准确性。而自动化测试建立起来之后，测试工程师只需要执行自动测试用例并在必要时对输出结果进行一定的检查即可。另外，对测试结果和期望结果进行自动比较也是自动测试的范畴，而且自动比较评价是大量输出的唯一可重复而有效的方法。可见，自动化测试大大提高了测试的准确性，同时也降低了对测试工程师的技术要求。＞可实现无人照看测试，更好地利用时间资源。理想的自动化测试能够按计划完全自动地运行，可以实现无人照看测试。在开发人员和测试工程师不可能实行昼夜工作的情况下，自动化测试可以胜任这个任务，完全可以在周末和晚上执行测试，充分利用了休息时间，也避免了开发和测试之间的等待。因而自动化测试可以更加合理地利用测试资源，进行更多的测试。＞具有一致性和可重复性。由于每次自动化测试运行的脚本是相同的，可以利用自动测试重复多次相同的测试，所以每次执行的测试具有一致性，而人是很难做到的。由于自动化测试的一致性，很容易发现被测软件的任何改变，而这在手工测试中是很难得到保证的。＞利于进行回归测试、适应性测试、可移植性测试、性能测试和配置测试。回归测试、适应性测试、可移植性测试、性能测试和配置测试均要求自动的、可重复的测试包。回归测试往往需要重复以前进行过的测试，自动化测试具有良ｌＯ年前，应用系统很少是针对不同的平台设计和开发的，而今天，应用通常＞缩短测试的时间。一旦实现了测试自动化，就可以比手工测试更快地执行测试，缩短测试的时好的可重复性，使得回归测试比较容易进行。使用自动测试包，测试工程师可以确保同样的测试用于一个应用的不同版本或配置上。都支持几种ＧＵＩ、网络、操作系统和数据库。在这种情况下，跨平台的自动测试是使测试操作的唯一方法。第二章软件测试自动化概述间，可以更快地将软件推向市场。＞有利于解决测试与开发之间的矛盾。通常在开发的末期，进入集成测试阶段，由于发布一个版本的初期，测试系统的错误比较少，这时开发人员有等待测试工程师测试出错误的时间。事实上在迭代周期很短的开发模式中，存在更多的矛盾，但自动化测试可以解决其中的主要矛盾。＞从经济上考虑，自动测试通常比手工测试有优越性。自动测试的开销只是手工测试的一小部分。第一次自动执行相同的测试用例时，由于在自动化上花费了较多的功夫，其经济性较低。但是当自动测试运行多次后，就比手工执行相同的测试要经济得多。这可以从图２．１中很清楚地看出来。＞与手工测试相比，自动测试的修改性比较低。在自动测试中必须要增加额外的维护开销，以对修改后的测试用例重新进行自动化。因此，自动测试的修改性相对比较低。２．４．２自动化测试的缺点自动化测试好处虽然很多，但并不是万能的，也存在着一定的局限性．。自动测试的缺点如下：≯软件自动测试并不能代替人的工作，尤其是带有智力性质的手工测试。工具本身不具有想象力，不能像手工测试一样进行发挥，不要期望将所有的测试活动进行自动化。软件测试工具不能发现所有的问题，测试工程师还需要做大量的工作。＞软件测试自动化可能降低测试的效率。当测试工程师只需要进行很少量的测试，而且这种测试在以后的重用性很低时，花大量的精力和时间去进行自动化的结果往往是得不偿失。因为自动化的收益一般要在多次重复使用中才能体现出来。＞自动测试并非像测试工程师所期望的那样能发现大量的错误。测试首次运行时，可能发现大量错误。当进行过多次测试后，发现错误的机率会相对比较小，除非对软件进行了修改或在不同的环境下运行。事实证明新错误越多，自动化测试失败的机率就越大。发现更多的新缺陷应该是手工测试的主要目的。测试专家ＪａｍｅｓＢａｃｈ经过总结得出结论，８５％的错误靠手工发现，而自动化测试只能发现１５％的错误。＞缺乏测试经验。如果测试的组织差、文档较少或不一致，则自动测试的效果比较差。＞测试自动化不能提高测试的有效性和仿效性。软件测试自动化研究与应用无论是自动测试还是手工测试都不影响测试的有效性和仿效性。如果测试用例本身是失败的，那么无论测试自动化程度有多高，测试的结果也是毫无意义的。自动测试只对测试的经济性和修改性有影响。＞技术问题、组织问题和脚本维护。毫无疑问，商用测试工具是软件产品，作为第三方的软件产品，不具备解决问题的能力和技术支持。同样的原因，测试工具和其它软件的互操作性也是一个严重的问题，技术环境变化如此之快，使测试工具很难跟得上。自动化测试的推行有很多阻力，如组织是否重视，是否成立这样的测试团队。对于测试脚本的维护工作量也很大，是否值得维护等问题都必须考虑。因此，软件自动化测试应该有正确的认识：它并不能完全代替手ＩＮ试。不要期望有了自动化测试就能提高测试的质量。如果测试工程师缺少测试的技能，那么测试也可能会失败。综合上述自动测试的优、缺点，相信经过自动测试经验的不断积累和自动测试工具性能的不断提高，自动测试能替代手工测试的工作会越来越多，从而自动测试成为对手工测试的有利补充。合理的运用自动化测试可以大大提高工作效率，反之则会是噩梦。无论测试自动化多么强大，在现阶断依然是以手工测试为主。第三章软件测试自动化工具概述第三章软件测试自动化工具概述３．１自动化测试原理和方法软件测试自动化实现的基础是可以通过设计的特殊程序模拟测试工程师对计算机的操作过程、操作行为，或者类似于编译系统那样对计算机程序进行检查。软件测试自动化实现的原理和方法主要有：直接对代码进行静态和动态分析、测试过程的捕获和回放、测试脚本技术、虚拟用户技术和测试管理技术。３．１．１代码分析代码分析类似于高级语言编译系统，一般针对不同的高级语言去构造分析工具，在工具中定义类、对象、函数、变量等规则、语法规则；在分析时对代码进行语法扫描，找出不符合编码规范的地方；根据某种质量模型评价代码质量，生成系统的调用关系图等。３．１．２捕获回放代码分析是一种白盒测试的自动化方法，捕获和回放则是一种黑盒测试的自动化方法。捕获是将用户每一步操作都记录下来。这种记录的方式有两种：程序用户界面的像素坐标或程序显示对象（窗口、按钮、滚动条等）的位置，以及相对应的操作、状态变化或是属性变化。所有的记录转换为一种脚本语言所描述的过程，以模拟用户的操作。回放时，将脚本语言所描述的过程转换为屏幕上的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。捕获和回放可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。录制手工测试可以很快得到可回放的测试比较结果；捕获和录带调试输入可以自动产生执行测试的文档，这样可提供审计追踪的功能，准确了解所发生的事件；录制手工测试可以对大量的文件或数据库进行相同的修改和维护；另外还可以用于演示。１６软件测试自动化研究与应用３．１．３录制回放目前的自动化负载测试解决方案几乎都是采用“录Ｎ／回放＂的技术。所谓的“录Ｎ／回放＂技术，就是先由手工完成一遍需要测试的流程，同时由计算机记录下这个流程期间客户端和服务器端之间的通信信息，这些信息通常是一些协议和数据，并形成特定的脚本程序（Ｓｃｒｉｐｔ）。然后在系统的统一管理下同时生成多个虚拟用户，并运行该脚本，监控硬件和软件平台的性能，提供分析报告或相关资料。这样通过几台机器就可以模拟出成百上千的用户对应用系统进行负载能力的测试。录制回放的测试事例脚本过程如图３．１所示。测试工具读取测试脚本，激活被测软件，然后执行被测软件。测试工具执行的操作以及有效输入到被测软件中的信息和测试胭本中描述的一样。在测试过程中，被测软件读取初始阅读文档中的初始数据，在执行过脚本中的命令后将最后结果输出到编辑文档中。测试过程中，日志文件也随之生成，里面包括测试运行中所有重要信息，通常日志文件包括运行时间、执行者、比较结果以及测试工具按照脚本命令要求输出的任何信息。终端屏幕图３．１录制回放脚本不意图商用工具的脚本语言功能基本相同，但脚本的具体形式取决于所使用的测试工具。和所有的编程工具一样，所有的测试工具的脚本语言都允许客户在脚本中插入注释。但编写注释代码必须注意语法规则，以免编译程序把注释当测试脚本执行。第三章软件测试自动化工具概述３．１．４脚本技术脚本是一组测试工具执行的指令集合，也是计算机程序的一种形式。脚本可以通过录制测试的操作产生，然后再做修改，这样可以减少脚本编程的工作量。当然也可以直接用脚本语言编写脚本。脚本语言和编程工具语言非常相似，更接近于网页脚本语言。它有自己的语法规则、保留字等，也遵循着软件工程的原则，需要考虑结构化设计和文档的健全编写。对比编程工具语言，测试脚本语言也可分为：线形脚本、结构化脚本、共享脚本、数据驱动脚本和关键字驱动脚本。脚本中包含的是测试数据和指令，一般包括如下信息：＞同步（何时进行下一个输入）。＞比较信息（比较什么，比较标准）。＞埔获何种屏幕数据及存储在何处。＞从哪个数据源或从何处读取数据。＞控制信息。脚本技术可以分为以下几类：＞线性脚本：是录制手工执行的测试用例得到的脚本。＞结构化脚本：类似于结构化程序设计，具有各种逻辑结构（顺序、分支、循环），而且具有函数调用功能。＞共享脚本：是指某个脚本可被多个测试用例使用，即脚本语言允许一个脚本调用另一个脚本。＞数据驱动脚本：将测试输入存储在独立的数据文件中。＞关键字驱动脚本：是数据驱动脚本的逻辑扩展。３．１．５自动比较既然软件测试是检验软件功能、性能等的软件开发活动，那么比较在软件测试中的作用当然是重要的。以此推之，软件测试自动化中的自动比较在自动化中也是关键的。测试工具的技术核心也在于自动比较是如何实现的，不同的测试自动化工具的技术是不尽相同的。比如说图像的比较，有的测试工具是按象素逐位进行比较；而有的工具则是先对图像进行处理，然后对处理后的图像按基线比较；更有巧妙的测试工具是把两个图像的象素点异或运算，如果两个相同的话，则产生一片空白的第三个图像。比较技术不同，比较的质量和效率也是不一样的。在自动化比较之前的活动是准备期望输出，根据输入计算或估计被处理的输软件测试自动化研究与席用Ａ所产生的输出，然后在期望输出和实际输出之脚进行比较。在这里，产生比较错误的～个可能就是期墨输出中有错误．这样测试的部分报告会显示比较结果中此处仃比较差，这是测试错误，而非软件错误。另外自动比较不如手工比较灵活，每次自动测试，都会盲目的以相同方式重复相同的比较。如果软件发生变化，则必须相应更新测试事例，这样的维护费用就很高了。但因为比较大量的数字、屏幕输出、磁盘输入或其他形式的输出是非常繁琐的事情．使用自动比较代替人工比较足个很好的捷径，就如汽车车间的焊接一般都是机器人完成的一样。总结Ｆ，自动比较包括：≯静态比较和动态比较。＞简单比较和复杂比较。≯敏感性测试比较和健壮性测试比较。≯比较过滤器。３．２软件自动化测试生存周期在软件测试Ｊ＝程师决定执行自动化测试之后，他们对于怎样执行自动化测试并不十分清楚。由ＥｌｆｒｅｉｄｅＤｕｓｔｉｎ提出的自动化测试生命周期方法学（ＡＴＬＭ·ＡｍｏｍａＩｃｄＴｅｓｔｉｎｇＬｉｆｅｃｙｄｅＭｅｔｈｏｄｏｌｏｇｙ）”Ｉ很好地解决了这一问题，指导测试工程师如何进行自动化测试（圈３．２）。图３．２自动化测试生命周期方法学（ＡＴＬＭ）根据图３．２所示，ＡＴＬＭ所述的各个阶段具体内容如下：Ｉ决定自动化测试在这一阶段，对于测试团队来说，重要的是要进行坝４试计划，知道自动化测试的预期结果和列出在正确执行自动化测试后的益处。同时，需要列出自动化测第三章软件测试自动化工具概述１９试工具的备选方案，这对于获得管理层的支持是非常有帮助的。２．选择测试工具这个阶段指导工程师对自动化测试工具进行评估，并确定使用的测试工具。由于测试工具应支持公司大部分测试需求，测试工程师应评审系统环境的其他部门的需要，给出测试工具评估的标准。测试工程师需定义一个评估的范围来使用这些测试工具，然后测试工程师跟厂家确定所需使用的测试工具。３．自动化测试引入阶段这个阶段概括了成功引入自动化测试到一个新的项目中所必须的步骤，测试过程分析和测试工具考虑。４．测试计划、设计和开发测试计划，在这个阶段中，测试团队应制定测试步骤和标准，包括测试环境所需的软件、硬件和网络，还有测试数据需求，测试的日程安排，性能指标，以及缺陷追踪流程和所使用的工具。测试设计，该阶段需要确定所要执行的测试，以及执行这些测试的方法和条件，同时，还应定义测试设计的标准。测试开发，为了使自动化测试可重用、可维护，必须定义和遵循测试开发的标准。５．测试执行和管理测试团队必须根据测试的日常安排来执行测试脚本，并改善这些脚本。在这个过程中还必须评审测试的结果，以避免错误的结果。系统的问题应通过系统问题报告记录在案，并帮助开发人员理解和重现这些问题。最后，测试团队需要进行回归测试来追踪和关闭这些问题。６．测试项目评审测试项目的评审必须贯穿于整个自动化测试生命周期，以利于测试活动的不断改进，必须有相应的标准来衡量评审的结果。通过运用ＡＴＬＭ中所概括的系统的方法，一个测试团队就能在测试资源受限的情况下利用这一途径组织和执行测试活动，并且达到使测试覆盖率最大的目的。很明显，强调自动化测试是软件工业的一个很大转变。这种转变不仅包括应用程序工具和测试自动化，它还贯穿于系统开发的整个生命周期。ＡＴＬＭ和系统的开发生命周期是同步进行的。要使软件专业人员转到自动化测试上来，结构化的方法是必须采用的。因此，ＡＴＬＭ是革命性的，它代表了一种结构化的方法，规定了确定测试方法和执行测试的流程，使得软件专业人员能进行可重复的软件测试。这种结构化的方法能够使测试工程师避免经常犯的错误，如实现了自动化工具的使用而没有一个正规的流程，结果是测试项目变得很杂乱不可重复，也不可测量；实现了测试设计而没有遵循任何的设计标准，结果是测试脚本是不可重复的，因软件测试自动化研究与应用此也不能够重用等。用来辅助自动化测试工具的ＡＴＬＭ集成了多个阶段过程。该技术支持详细的相互关联的活动，这些活动可以用来确定要不要使用自动化测试工具。它还包括如何引进并使用自动化测试工具、测试开发、测试设计，如何进行测试执行和管理。ＡＴＬＭ强调了在前期进行测试需求分析、测试计划和测试设计等制定测试策略的投入是非常重要的。它规范了测试工作，提高了测试工作的总体效率和测试质量，因此，在很大程度上决定了一个自动化测试项目成败的关键，同时也是实现和提高测试自动化程度的重要基础。３．３自动化测试工具近年来，软件已经成为商业的重要组成部分。减少软件开发费用和增强软件质量已经成为了软件业的重要目标。为此，软件组织也付出了很大的努力，并且许多公司也已经成功地开发了一些软件测试工具。３．３．１自动化测试工具的特征一般来说，一个好的自动化测试工具一般应具有以下几条关键特征：１．支持脚本化语言这是最基本的一条要求，脚本语言具有与编程语言类似的语法结构，可以对已经录制好的脚本进行编辑修改。具体来讲，应该至少具备以下功能：＞支持多种常用的变量和数据类型；＞支持数组、列表、结构、以及其他混合数据类型；＞支持各种条件逻辑（ＩＦＣＡＳＥ等语句）。脚本语言的功能越强大，就越能够为测试开发人员提供更灵活的使用空间，而且有可能用一个复杂的语言写出比被测软件还要复杂的测试系统。所以，必须确信脚本语言的功能可以满足测试的需求。２．对程序界面对象的识别能力测试工具必须能够将测试程序界面中的所有对象区分并标识出来，录制的测试脚本才具有更好的可读性、灵活性和更大的修改空间。如果只通过位置坐标来区分对象、它的灵活性就差很多了。对于用一些比较通用的开发工具写的程序，如：ＰＢ、Ｄｅｌｐｈｉ和ＭＦＣ，大多数测试工具都能区分和标识出程序界面里的所有元素，但对～些不太普及的开发工具或是库函数，工具的支持会比较差。因此，在开发测试工具时对开发语言的支持是很重要的一项。第三章软件测试自动化工具概述２１３．支持函数的可重用如果支持函数调用，可以建立一套比较通用的函数库，一旦程序做了改动，只需要把原来脚本中的相应函数进行更改，而不用把所有可能的脚本都修改，可以节省很大的工作量。测试工具在这项功能上的实现情况有两点要注意的：首先要确保脚本能比较容易地实现对函数的调用；其次还要支持脚本与被调函数之间的参数传递。比如：对于用户登录函数，每次调用时可能都需要使用不同的用户名和口令，此时就必须通过参数的传递将相关信息送到函数内部执行。４．支持外部函数库除了针对被测系统建立库函数外，一些外部函数同样能够为测试提供更强大的功能，如Ｗｉｎｄｏｗｓ程序中对文件的访问，Ｃ／Ｓ程序中对数据库编程接口的调用等。举一个很简单又很实用的例子，完成向数据库中插入一条记录的操作，程序可以提示己插入成功，但数据是否正确写入数据库中，通常需要手工去数据库中进行检查，以确认功能的正确实现，如果能够在测试脚本中插入检查点，通过调用数据库提高的编程接口检查刚才的操作是否执行正常，这样就无需人工检查，测试程序可以自动的完成一些校验的功能。５．抽象层抽象层的作用是将程序界面中存在的所有对象实体一一映射成逻辑对象，帮助减少测试维护工作量。有些工具称这一层叫”ＴｅｓｔＭａｐ”、”ＧｕｉＭａｐ”或”ＴｅｓｔＦｒａｊｎｅ＇’。举个简单的例子来看看抽象层的作用，如：一个用户登录窗口，其中需要输入两条信息，程序中对这两条信息的标识分别叫’＇Ｎａｍｅ”和”Ｐａｓｓｗｏｒｄ＇’，而且在很多脚本里都要做登录操作。但是，在软件的下一个版本中，登录窗口中两条输入信息的标识变成了”ＵｓｅｒＮａｍｅ”和”Ｐｗｏｒｄ”，这时候只需要将抽象层中这两个对象的标识进行一次修改就可以了。脚本执行时通过抽象层自动会使用新的对象标识。通过测试工具支持程序界面的自动搜索，建立所有对象的抽象层，当然也可以手工建立或进行一些定制操作。在了解测试所涉及的内容后，测试方法和采用相对应的自动化测试工具是至关重要的。自动化的测试工具意味着在测试活动中减少一部分开销，同时，有些测试活动是靠手工方式难以实现、难以度量的。在对自动化的测试工具做成本效益分析时，应当考虑到项目的预期时间和人工消耗，一些测试用手工来做，可能由几个人需要几个星期甚至更长时间来完成，而采用自动化的测试工具可能只需要几个小时或者几分钟：像基于Ｃ／Ｓ的负载测试或者是基于Ｗｅｂ系统的测试，要用手工测试来完成是很困难和不现实的。所以，在测试活动中选择自动化的测试工具是非常必要的。软件测试自动化研究与应用３．３．２自动化测试工具的作用和优势软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作。部分的测试工具可以实现测试用例的自动生成，但通常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较。如果采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。因此，自动化测试工具的作用如下所示：＞确定系统最优的硬件配置。＞检查系统的可靠性。＞检查系统硬件和软件的升级情况。＞评估新产品。而自动化测试工具的优势主要体现在以下几个方面：＞记录业务流程并生成脚本程序的能力。＞对各种网络设备（客户机或服务器、其它网络设备）的模仿能力。＞用有限的资源生成高质量虚拟用户的能力。＞对于整个软件和硬件系统中各个部分的监控能力。＞对于测试结果的表现和分析能力。３．３．３自动化测试工具的分类实际运用中，测试工具可以从两个不同的方面去分类：＞根据测试方法不同，自动化测试工具可以分为：白盒测试工具和黑盒测试工具。＞根据测试的对象和目的，自动化测试工具可以分为：单元测试工具、功能测试工具、负载测试工具、性能测试工具、Ｗｅｂ测试工具、数据库测试工具、回归测试工具、嵌入式测试工具、页面链接测试工具、测试设计与开发工具、测试执行和评估工具和测试管理工具等。根据以上的分类，下面就来具体的介绍这些测试工具。１．白盒测试工具白盒测试工具一般是针对被测源程序进行的测试，测试所发现的故障可以定位到代码级。根据测试工具工作原理的不同，白盒测试的自动化工具可分为静态测试工具和动态测试工具。＞静态测试工具是在不执行程序的情况下，分析软件的特性。静态分析主要第三章软件测试自动化工具概述集中在需求文档、设计文档以及程序结构方面。按照完成的职能不同，静态测试工具包括以下几种类型：（１）代码审查；（２）一致性检查：（３）错误检查；（４）接１：３分析；（５）输入输出规格说明分析检查；（６）数据流分析；（７）类型分析；（８）单元分析；（９）复杂度分析。＞动态测试工具是直接执行被测程序以提供测试活动。它需要实际运行被测系统，并设置断点，向代码生成的可执行文件中插入一些监测代码，掌握断点这一时刻程序运行数据（对象属性、变量的值等），具有功能确认、接口测试、覆盖率分析和性能分析等性能。动态测试工具可以分为以下几种类型：（１）功能确认与接口测试：（２）覆盖测试；（３）性能测试：（４）内存分析。常用的动态工具有：Ｃｏｍｐｕｗａｒｅ公司的ＤｅｖＰａｒｔｎｅｒ和ＩＢＭ公司的ＲａｔｉｏｎａｌＰｕｒｉｆｙ。２．黑盒测试工具黑盒测试工具是在明确软件产品应具有的功能的条件下，完全不考虑被测程序的内部结构和内部特性，通过测试来检验软件功能是否按照软件需求规格的说明正常工作。按照完成的职能不同，黑盒测试工具可以分为：＞功能测试工具——用于检测程序能否达到预期的功能要求并正常运行。＞性能测试工具——用于确定软件和系统的性能。常用的黑盒测试工具有：Ｃｏｍｐｕｗａｒｅ公司的ＱＡＣｅｎｔｅｒ和ＩＢＭ公司的ＲａｔｉｏｎａｌＴｅａｍＴｅｓｔ。３．测试设计与开发工具测试设计是说明被测软件特征或特征组合的方法，并确定选择相关测试用例的过程。测试开发是将测试设计转换成具体的测试用例的过程。测试设计和开发需要的工具类型有：＞测试数据生成器。＞基于需求的测试设计工具。＞捕获／回放。＞覆盖分析。４．测试执行和评估工具测试执行和评估是执行测试用例并对测试结果进行评估的过程，包括选择用于执行的测试用例、设置测试环境、运行所选择的测试用例、记录测试执行过程、分析潜在的故障，并检查测试工作的有效性。评估类工具对执行测试用例和评估测试结果过程起到辅助作用。测试执行和评估类工具有：软件测试自动化研究与应用＞捕获／回放＞覆盖分析＞存储器测试５．测试管理工具测试管理工具用于对测试过程进行管理，帮助完成制定测试计划，跟踪测试运行结果。通常，测试管理工具对测试计划、测试用例、测试实施进行管理，还包括缺陷跟踪管理等。测试管理工具包括以下内容：＞测试用例管理。＞缺陷跟踪管理（问题跟踪管理）。＞配置管理。常用的测试管理工具有：ＩＢＭ公司的ＲａｔｉｏｎａｌＴｅｓｔＭａｎａｇｅｒ。面对市场上的这些不同的测试工具，测试工程师在选择和使用自动化测试工具时，可以从以下角度来考虑：＞按照用途选择匹配的测试工具。＞在适当的生命周期选择测试工具。＞按照测试工程师的实际技能选择匹配的测试工具。＞选择一个可提供的测试工具。３．３．４市场上的自动测试工具在今天的市场上，己经有各种各样的软件测试工具。这些工具的制造商包括ＩＢＭＲａｔｉｏｎａｌＳｏｆｔｗａｒｅ、ＭｅｒｃｕｒｙＩｎｔｅｒａｃｔｉｖｅｓ（ＭＩ）和ＳｅｇｕｅＳｏｆｔｗａｒｅ。也有来自其它厂商的工具，而且有些测试工具是开放源码的，如ＪＩＪｎｉｔ、Ｃａｃｔｕｓ和ＨｔｔｐＵｎｉｔｏ。其中，ＭＩ公司和Ｒａｔｉｏｎａｌ公司的产品占了主流。虽然这些测试工具不像被期望的那样自动化和有效，但是它们对寻找ｂｕｇ保证软件质量起到了不可磨灭的作用。下面将对它们进行简短介绍。１．Ｍｅｒｃｕｒｙ（美科利）质量中心提供一个全面的、基于Ｗｅｂ的集成系统，可在广泛的应用环境下自动执行软件质量管理和测试。其主要产品如下：＞Ｗｉｎｒｕｎｎｅｒ：是一种企业级的用于检验应用程序是否如期运行的功能性测试工具。通过自动捕获，检测和重复用户交互的操作，ＷｉｎＲｕｎｎｅｒ能够辨认缺陷并且确保那些跨期可靠运行。越多个应用程序和数据库的业务流程在初次发布就能避免出现故障，并且保持长第三章软件测试自动化工具概述≯Ｌｏａｄｒｕｎｎｅｒ：是～种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，ＬｏａｄＲｕｎｎｅｒ能够对整个企业架构进行测试。通过使用ＬｏａｄＲｕｎｎｅｒ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。＞ＴｅｓｔＤｉｒｅｃｔｏｒ：是基于Ｗｅｂ的测试管理解决方案，它可以在公司内部进行全球范围的测试协调。ＴｅｓｔＤｉｒｅｃｔｏｒ能够在一独立的应用系统中提供需求管理功能，并且可以把测试需求管理于测试计划、测试日程控制、测试执行和错误跟踪等功能融合为一体，因此极大地加速了测试的进程。ＴｅｓｔＤｉｒｅｃｔｏｒ提供完整且无限制的测试管理框架，实现对应用测试全部阶段的管理与控制。＞ＱｕｉｃｋＴｅｓｔＰｒｏｆｅｓｓｉｏｎａｌ：是一个功能测试自动化工具，主要应用在回归测试中。ＱｕｉｃｋＴｅｓｔ针对的是ＧＵＩ应用程序，包括传统的Ｗｉｎｄｏｗｓ应用程序，以及现在越来越流行的Ｗｅｂ应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。２．Ｒａｔｉｏｎａｌ公司产品如下：＞ＲａｔｉｏｎａｌＴｅｓｔＲｅａｌＴｉｍｅ：支持嵌入式和实时的跨平台软件的组件测试和运行时分析。通过分析源代码，自动生成测试驱动（ＴｅｓｔＤｒｉｖｅｒ）和模板（＇ｒｅｓｔＳｔｕｂ）。开发人员只需要在该测试脚本的基础上指定测试输入数据、期望输出数据以及桩函数逻辑。测试执行后自动生成测试报告和各种运行时候报告。测试报告展示通过或没通过的测试用例，而运行时分析报告包括代码覆盖分析报告，内存分析报告、性能分析报告和执行追踪报告１１９Ｉ。＞ＲａｔｉｏｎａｌＦｕｎｃｔｉｏｎａｌＴｅｓｔｅｒ：对Ｊａｖａ、Ｗｅｂ和基于ＶＳ．ＮＥＴＷｉｎＦｏｒｍ的应用程序进行高级自动化功能测试。＞ＲａｔｉｏｎａｌＭａｎｕａｌＴｅｓｔｅｒ：使用新测试设计技术来改进人工测试设计和执行工作。＞ＲａｔｉｏｎａｌＰｅｒｆｏｒｍａｎｃｅＴｅｓｔｅｒ：检查可变多用户负载下可接受的应用程序响应时间和可伸缩性。＞ＲａｔｉｏｎａｌＰｕｒｉｆｙｆｏｒＷ＇ｍｄｏｗｓ：为Ｗｉｎｄｏｗｓ提供了内存泄漏和内存损坏检测。＞ＲａｔｉｏｎａｌＰｕｒｉｆｙＰｌｕｓｆｏｒＷｉｎｄｏｗｓ：为基于Ｗｉｎｄｏｗｓ的Ｊａｖａ、Ｃ／Ｃ＋＋、ＶｉｓｕａｌＢａｓｉｃ和托管．ＮＥＴ开发提供了运行２６软件测试自动化研究与应用时分析。＞ＲａｔｉｏｎａｌＲｏｂｏｔ：客户机／ＪＪ眨，务器应用程序的通用测试自动化工具。可以对使用各种集成开发环境（ＩＤＥ）和语言建立的软件应用程序，创建、修改并执行自动化的功能测试、分布式功能测试、回归测试和集成测试。３．４自动化测试工具的局限性相当长一段时间内，软件测试一直都是由人工操作，即手工地按照预先定义的步骤运行应用程序。自从软件产业开始以来，软件组织对自动化软件测试过程做出了很大的努力。许多公司己经成功地开发出了一些软件测试工具，这些工具在产品发布之前就能发现并确定ｂｕｇ。现在市场上有非常多的自动化测试工具，上一节中仅列出了它们其中的一部分。这些测试工具有很多已经涵盖了软件测试生命周期的各个阶段。然而，它们对生成或编写测试脚本却有着相似的被动架构，即遵循手工指定待测试产品，指定待测试方法，编辑和调试生成测试脚本的模式。这些测试脚本通常是由三种方式编写，即由测试工程师手工编写，由测试工具使用反向工程生成和由捕获／回放工具生成。无论由哪一种方式编写测试脚本，调试都是一个可能伴随的步骤。比较前一节中的测试工具之后，将会发现这些测试工具要求专用化并包含不一致性，简单有效的标准化的测试技术还相当缺乏。另外，这些测试工具的开发通常都落后于新开发技术的发展与应用。所有的测试工具，包括著名ＭｅｒｃｕｒｙＩｎｔｅｒａｃｔｉｖｅ公司的ＷｉｎＲｕｎｎｅｒ，Ｃｏｍｐｕｗａｒ。公司的ＤｅｖＰａｒｔｎｅｒＳｔｕｄｉｏ．ＲａｔｉｏｎａｌＳｏｆｔｗａｒｅ的ＳＱＡＳｕｉｔｅ和开放源代码的Ⅲ血对新产品的快速上市，新技术的进步，新设计过程的采用，和第三方组件的完美整合都存在一定的风险。当前的软件测试工具基本上都存在《软件测试不充分架构的经济影响》一书中指出的不足，即：＞缺乏引导彻底测试能力；＞缺乏集成测试和互操作性测试的能力；＞缺乏自动生成测试脚本的机制；＞缺乏决定何时产品足够完善可予以发布的严格测试；＞缺乏简单有效的性能衡量标准和测试测量规程。为了填补这些不足，专家们强烈建议软件开发组织开发他们自己的自动化软件测试工具。本文提出了一种测试方法，它具有一定的引导彻底测试能力和集成测试能力，并能够完成对ｇｃＭｕｌｔｉＲｏｗ５．０产品的自动化测试。第四章软件测试自动化工具的技术原理２７第四章软件测试自动化工具的技术原理上章已经介绍了市场上的一些自动化测试工具，并提出了自动化测试工具的局限性。本章接着介绍用于ｇｅＭｕｌｔｉＲｏｗ５．０产品自动化测试的ＡｕｔｏＴｅｓｔｅｒ工具的技术原理。４．１ＡｕｔｏＴｅｓｔｅｒ自动化工具概述ＡｕｔｏＴｅｓｔｅｒ是根据ｇｃＭｕｌｔｉＲｏｗ５．０控件产品的特点开发出的一款自动化测试工具。它是基于．Ｎｅｔ，利用Ｎｕｎｉｔ构架的自动测试工具。由于ｇｃＭｕｌｔｉＲｏｗ５．０是一款控件产品，用户通过控件的图形用户界面（ＧＵＩ）与系统进行交互。因此需要一个支持ＧＵＩ行为的自动化工具。４．１．１单元测试的改进ＡｕｔｏＴｅｓｔｅｒ工具是基于Ｎｕｎｉｔ的框架，而Ｎｕｎｉｔ是一款开源的Ｃ群单元测试工具。Ｎｕｎｉｔ使用断言来判断待测试代码是否返回正确的结果，在编写测试用例的过程中，需要有一个正确的值作为依据，与测试代码返回的值进行比较。而ＡｕｔｏＴｅｓｔｅｒ正是利用这种原理实现了测试自动化。由于Ｎｕｎｉｔ是一个与它的先祖们（其它的ｆｒａｍｅｗｏｒｋ）非常不一样的版本。其它的ｘｕｎｉｔ家族版本通常都有一个基础类，写的测试用例都必须继承自这个基础类。这样对很多的程序语言造成很大程度的限制。比如说，ｊａｖａ和蒯就只能允许单一继承。如果想要重构程序代码的话，会遇到一些的限制：除非引进一些复杂的ｉｎｈｅｒｉｔａｎｃｅｌｌｉｅｒａｒｃＫｅｓ（类别继承层级）。但是有了．Ｎｅｔ之后一切都不同了，．Ｎｅｔ引进了一个新的程序开发概念：ａｔｔｒｉｂｕｔｅｓ（属性）。彻底解决了这个烦人的问题。Ａｔｔｒｉｂｕｔｅｓ可以在程序代码之上再加入元数据。一般来说，ａｔｔｒｉｂｕｔｅｓ不会影响到主要程序代码的执行，其功能是在所写程序代码之上添加了额外的信息。Ａｔｔｒｉｂｕｔｅｓ主要使用在注释程序代码上，但是ａｔｔｒｉｂｕｔｅｓ也可以用来提供有关ａｓｓｅｍｂｌｙ的额外信息，其它的程序就算没有见过这个ａｓｓｅｍｂｌｙ，也可以使用这些信息。这样子的话，在此框架下构建的自动化测试工具ＡｕｔｏＴｅｓｔｅｒ，可以主动地寻找待测试程序集中所有要测试的方法。当给ＡｕｔｏＴｅｓｔｅｒ工具指定待测试程序集之后，它能够生成一个测试脚本来测试所有的构造器、方法、属性和包括从基类继承的软件测试自动化研究与应用方法。因此，它为彻底地测试做出了努力。４．１．２识别待测程序集中的类、方法和属性识别出待测试程序集中的命名空间、类和方法已经被认为是件相当繁琐的工作。在实际的测试过程中，如果要测试一个给定的程序集，通常都需要用测试工具识别出所有的命名空间和类型类。这些命名空间和类型类是很好地测试一个程序集的必要信息，也是在开始测试待定程序集前必须了解的。另外，它们还是编写测试脚本的必要前提。对于任何测试组织来说，识别待测试程序集都是一项相当高的花费１２２１。然而，通过使用．ＮＥＴ类库中Ｓｙｓｔｅｍ．Ｒｅｆｌｅｃｔｉｏｎ类和方法，自动测试工具却能大幅度地减少这些过高的花费。Ｒｅｆｌｅｃｔｉｏｎ命名空间能够动态地发现类型，把给定程序集的类和方法区分成类型与成员。Ｓｙｓｔｅｍ．Ｒｅｆｌｅｃｔｉｏｎ命名空间提供了在运行时帮助载入程序集并发现与ＩＬＤａｓｍ．ｅｘｅ发现的相同的信息。（注：ＩＬＤａｓｍ．ｅｘｅ是．ＮＥＴＦｒａｍｅｗｏｒｋＳＤＫ附带的ＭＳＩＬ反汇编程序。它可以分析任何．ＮＥＴＦｒａｍｅｗｏｒｋ的．ｅｘｅ或ｄｎ程序集，并以可读的格式显示信息。ＩＬＤａｓｍ．ｅｘｅ不只是显示Ｍｉｃｒｏｓｏｆｔ中间语言（ＭＳＩＬ）代码，它还显示命名空间和类型，包括其接口。）然后，它获得一个包含给定模块的所有类型的清单，包括方法、字段、属性、枚举和事件定义。另外，它也能编程地发现给定类（或结构）支持的接口集，方法的参数，和其它相关的信息（如：基类、命名空间信息等）。这些恰恰是在测试任务开始之前必须准确了解和进行诸多考虑的细节。ＡｕｔｏＴｅｓｔｅｒ自动测试工具完美地整合了Ｓｙｓｔｅｍ．Ｒｅｆｌｅｃｔｉｏｎ命名空间，因而可以很轻易地识别待测试程序集。ＡｕｔｏＴｅｓｔｅｒ自动测试工具使用ＴｙｐｅＵｎｄｅｒＴｅｓｔ窗体中的ＣｈｅｃｋｅｄＬｉｓｔＢｏｘ列举待测试程序集中所有有效的类型。有时候可能没有要求用一次运行来测试整个程序集的所有类型，ＣｈｅｃｋＬｉｓｔＢｏｘ则有能力仅选择感兴趣的测试类型。这是很有用的，特别是当一个给定程序集有很长的类型清单的时候。当然，如果想用一个测试脚本测试所有的类型，可以选中ＳｅｌｅｃｔＡｌｌ选择框。用一个测试脚本测试一个应用程序的优势是很明显的，它使测试脚本简单并且易于管理。如果仅仅是对待测试程序集进行识别，而不能动态地对其中的类型进行实例化访问和调用，那么自动化测试工具也是无法完成的，或至少这个测试工具不能算是完全自动化的。ＡｕｔｏＴｅｓｔｅｒ工具能够使用后期绑定技术在运行时动态地确定给定的类型及其成员（并非在编译时）。一旦确定类型存在，ＡｕｔｏＴｅｓｔｅｒ工具就能够动态地调用给定实体的任何方法，访问任何属性和操作任何字段。第四章软件测试自动化工具的技术原理４．１．３编程语言的选择前面提到在市场上已经有许多可用的测试工具，并且测试组织使用这些工具也取得了很大地成功。一些测试工具用ＶｉｓｕａｌＳｔｕｄｉｏＢａｓｉｃ６．０编写测试脚本，并在ＶｉｓｕａｌＩＤＥ中执行它。也有一些工具是用Ｊａｖａ来编写，如ＪＵｎｉｔ和Ｐｒｏｂｅ。还有为运行在Ｕｎｉｘ、Ｌｉｎｕｘ和其它平台上的软件产品编写测试脚本的工具。但是，当前可用的测试工具在测试用．ＮＥＴ平台和Ｃ撑语言开发的产品时却缺乏能力。期望自动化的测试工程师不得不开发他们自己的工具来完成任务。Ｃ撑是一种高级编程语言。虽然它不是被设计作为一个测试工具，但是它却有很多方法能被用于测试过程，如．ＮＥＴＲｅｆｌｅｃｔｉｏｎ命名空间能映射一个程序集，．ＮＥＴＣｏｄｅＤｏｍ命名空间能为脚本编写代码，动态绑定技术等。Ｃ撑是一种完全面向对象的编程语言。使用Ｃ拌开发工具在重用性、扩展性和维护性方面都有很大的优势。另一方面，Ｃｊｆｌ｝很容易通过ＣＯＭ的互操作性进行ＭＳＥｘｃｅｌＡＰＩ编程；基于以上特点，本文中将使用ＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＳｔｕｄｉｏ．ＮＥＴ环境的Ｃ捍作为开发ＡｕｔｏＴｅｓｔｅｒ工具和生成测试脚本的编程语言。４．１．４框架介绍根据测试活动的过程，首先必须编写自动化测试的脚本。为了识别待测程序集中的方法和属性，编写测试脚本就有一定的要求，这就是脚本的框架。它包含以下的结构：＞【ＴｅｓｔＦｉｘｔｕｒｅ】，标记。＞ｐｕｂｌｉｃｃｌａｓｓＭｕｌｔｉＲｏｗＳｍｏｋｉｎｇＴｅｓｔ，类名。＞【Ｔｅｓｔ］，标记。＞ｐｕｂｌｉｃｖｏｉｄｇｃＭｕｌｔｉＲｏｗＳｃｒｏｌｌＢａｒＭｏｄｅ＿＿０１０，方法名。＞Ａｓｓｅｒｔ．ＡｒｅＥｑｕａｌ（ｏｂｊｅｅｔｅｘｐｅｃｔｅｄ，ｏｂｊｅｃｔａｃｔｕａｌ［，ｓｔｒｉｎｇｍｅｓｓａｇｅ］），在测试方法中的结果比较。这是个简单的框架，它仅仅展示了开始使用该框架的最小要求。除此之外，还必须添加下面的需求：＞在脚本开头添加ＡｕｔｏＴｅｓｔｅｒ．Ｆｒａｍｅｗｏｒｋ．ｄｌｌ。＞在文件开头加入ｕｓｉｎｇＡｕｔｏＴｅｓｔｅｒ．Ｆｒａｍｅｗｏｒｋ的引用。＞在待测试的类前面添加属性：【ＴｅｓｔＦｉｘｔｕｒｅ】Ａｔｔｒｉｂｕｔｅ。＞在待测试的方法前添加属性：【Ｔｅｓｔ】Ａｔｔｒｉｂｕｔｅ。软件测试自动化研究与应用在框架完成后，就可以开始编写脚本。然后编译这些写好的脚本，如果通过就会产生一个待加载的．ｄｌｌ。这个时候启动ＡｕｔｏＴｅｓｔｅｒ工具，新建项目，将上述项目目标文件．ｄＵ加入，就可以开始执行自动化测试。在本节定义的框架结构里面有一些常用的属性，这些将在下节介绍。４．１．５常用属性在上节的框架结构中，出现了两个非常重要的属性ＴｅｓｔＦｉｘｔｕｒｅ和Ｔｅｓｔ。接下来将对这些重要的概念进行介绍。＞【ＴｅｓｔＦｉｘｔｕｒｅ］Ａｔｔｒｉｂｕｔｅ本属性标记一个类包含测试，当然ｓｅｔｕｐ和ｔｅａｒｄｏｗｎ方法可有可无（关于ｓｅｔｕｐ和ｔｅａｒｄｏｗｎ方法在后面介绍）。做为一个可以被测试的类还有一些限制：１．必须是Ｐｕｂｌｉｃ，否则自动化工具看不到它的存在。２．它必须有一个缺省的构造函数，否则是自动化测试工具不会构造它。构造函数应该没有任何副作用，因为自动化测试工具在运行时经常会构造这个类多次。如果构造函数有副作用，就会发生混乱。＞【Ｔｅｓｔ］ＡｔｔｒｉｂｕｔｅＴｅｓｔ属性用来标记一个类（已经标记为ＴｅｓｔＦｉｘｔｕｒｅ）的某个方法是可以测试的。为了和先前的版本向后兼容，头４个字符（“ｔｅｓｔ”）忽略大小写。Ｔｅｓｔ所标记的方法没有任何参数。其实测试方法必须没有参数。如果定义方法不对，这个方法不会出现在测试方法列表中。．也就是说，在自动化测试工具界面左边的工作域内，看不到这个方法。还有一点就是这个方法不返回任何参数，并且必须为Ｐｕｂｌｉｃ。一般来说，有了上面两个属性，就可以做基本的事情。４．１．６测试的组成一个［ＴｅｘｔＦｉｘｔｕｒｅ］ａｔｔｒｉｂｕｔｅ标记的类（简称ｔｅｓｔｆｉｘｔｕｒｅ）包含一个或多个测试方法，每个方法包含一个或多个断言。一个程序集可包含多个ｔｅｓｔｆｉｘｔｕｒｅ。在一个测试方法中如果有一个断言测试失败，则其他的断言就不能执行了，也就是说该测试方法没有成功。但如果二个测试方法失败了，并不影响其他的测试方法。所以，可通过ＡｕｔｏＴｅｓｔｅｒ工具来选择执行某个ｔｅｓｔｆｉｘｔｕｒｅ或某个测试方法。ＡｕｔｏＴｅｓｔｅｒ工具还提供了多种运行测试的方式，它可以将几个测试类组合起来一起测试，也可以将测试的方法分类分开测试等。第四章软件测试自动化工具的技术原理３１一次运行几个测试类，对于这种情况，可以使用【Ｓｕｉｔｅ］特性。也就是一个ＴｅｓｔＳｕｉｔｅ类，它表示将一组测试类组合起来一起测试。例如：［Ｓｕｉｔｅ］ｐｕｂｌｉｃｓｔａｔｉｃＴｅｓｔＳｕｉｔｅＳｕｉｔｅ｛ｇｅｔ｛ＴｅｓｔＳｕｉｔｅｓｕｉｔｅ＝ｎｅｗＴｅｓｔＳｕｉｔｅ（”ｔｅｓｔＴｃｓｔ”）；ＴｅｓｔＬａｒｇｅｓｔｔｌ＝ｎｅｗＴｅｓｔＬａｒｇｅｓｔＯ；／／ｓｕｉｔｅ．Ａｄｄ（ｎｅｗＴｅｓｔＬａｒｇｅｓｔｌ０）；ｓｕｉｔｅ．Ａｄｄ（ｔ１）；ｒｅｔｕｒｎｓｕｉｔｅ；）｝测试类有一个［Ｓｕｉｔｅ］标记，用来返回一个ＴｅｓｔＳｕｉｔｅ对象，这个对象通过Ａｄｄ０方法将希望一起测试的类添加到了一起。这些类也都是用［ＴｅｓｔＦｉｘｔｕｒｅ］包含起来的测试类。自动化测试工具框架会自动寻找每一个测试类，并测试每一个测试方法。４．１．７测试方法的初始化和资源释放函数在早期给的ｔｅｓｔｆｉｘｔｕｒｅ定义里，ｔｅｓｔｆｉｘｔｕｒｅ的测试是一组常规运行时的资源。在测试完成之后，或是在测试执行中，或是释放或清除之前，这些常规运行时的资源在一确定的方式上可能需要获取和初始化。而且对于不同方法的测试产品的不同功能，彼此之间不能够产生影响。因此，需要在测试方法执行之前释放和清除被占有的资源，并重新获取和初始化。这时候，可以使用２个额外的属性：ＳｅｔＵｐ和ＴｅａｒＤｏｗｎ。它们可以实现这种常规的初始化／清除。＞［ＳｅｔＵｐ】和［Ｔｅａｒｄｏｗｎ】Ａｔｔｒｉｂｕｔｅｓ在写测试用例的时候，有时会需要在执行每一个测试方法之前（或之后）先作一些预备或善后工作。当然，可以写一个ｐｒｉｖａｔｅ的方法，然后在每一个测试方法的一开头或最末端呼叫这个特别的方法。或者可以使用【ＳｅｔＵｐ］及［Ｔｅａｒｄｏｗｎ］Ａｔｔｒｉｂｕｔｅｓ来达到相同的目的。和这两个Ａｔｔｒｉｂｕｔｅｓ名字的意思一样，有［Ｓｅｔｕｐ］Ａｔｔｒｉｂｕｔｅ的方法会在该ＴｅｘｔＦｉｘｔｕｒｅ中的每一个测试方法被执行之前先被ＴｅｓｔＲｕｎｎｅｒ所执行，而有［Ｔｅａｒｄｏｗｎ］Ａｔｔｒｉｂｕｔｅ的方法则会在每一个测试方法被执行之后被ＴｅｓｔＲｕｎｎｅｒ所执行。软件测试自动化研究与应用一般来说，［Ｓｅｔｕｐ］Ａｔｔｒｉｂｕｔｅ及［Ｔｅａｒｄｏｗｎ］Ａｔｔｒｉｂｕｔｅ被用来预备一些必须的对象，例如ｄａｔａｂａｓｅｃｏｎｎｅｃｔｉｏｎ等。＞ＴｅｓｔＦｉｘｔｕｒｅＳｅｔＵｐ和ＴｅｓｔＦｉｘｔｕｒｅＴｅａｒＤｏｗｎ这两个属性用在ＴｅｓｔＦｉｘｔｕｒｅ里面，其作用是提供一组函数执行任何测试运行之前（ＴｅｓｔＦｉｘｔｕｒｅＳｅｔＵＰ）和最后一个测试执行后（ＴｅｓｔＦｉｘｔｕｒｅＴｅａｒＤｏｗｎ）。每一个ＴｅｓｔＦｉｘｔｕｒｅ只能有一个ＴｅｓｔＦｉｘｔｕｒｅＳｅｔＵｐ方法和ＴｅｓｔＦｉｘｔｕｒｅＴｅａｒＤｏｗｎ方法。如果一个以上的ＴｅｓｔＦｉｘｔｕｒｅＳｅｔＵｐ和ＴｅｓｔＦｉｘｔｕｒｅＴｅａｒＤｏｗｎ方法，可以通过编译但是不会执行。值得注意的是一个ＴｅｓｔＦｉｘｔｕｒｅ可以拥有一个ＴｅｓｔＦｉｘｔｕｒｅＳｅｔＵｐ和一个ＳｅｔＵｐ，也可以拥有一个ＴｅｓｔＦｉｘｔｕｒｅＴｅ：ａｒＤｏｗｎ和一个ＴｅａｒＤｏｗｎ方法。而ＴｅｓｔＦｉｘｔｕｒｅＳｅｔＵｐ和ＴｅｓｔＦｉｘｔｕｒｅＴｅａｒＤｏｗｎ被用在不方便使用ＳｅｔＵｐ和ＴｅａｒＤｏｗｎ方法。其实，一般情况使用ＳｅｔＵｐ和ＴｅａｒＤｏｗｎａｔｔｒｉｂｕｔｅｓ。４．１．８属性总结基于Ｎｕｎｉｔ框架的自动化测试工具使用Ａｔｔｒｉｂｕｔｅ（如上面所介绍的［Ｔｅｓｔ】）来描述测试用例的，也就是说掌握了Ａｔｔｒｉｂｕｔｅ的用法，也就基本学会如何使用ＡｕｔｏＴｅｓｔｅｒ工具。表４．１对比了ＮＵｎｉｔ和ＶＳＴＳ的标记。表４．１ＮＵｎｉｔ和ＶＳＴＳ的标记ｕｓａｇｅＶＳＴＳＮＵｎｉｔａｔｔｒｉｂｕｔｅｓａｔｔｒｉｂｕｔｅｓ标识测试类ＴｅＳｔＦｉｘｔｕｒｅ１’ｅｓｔＣｌａｓｓ标识测试用例（ＴｅｓｔＣａｓｅ）ＴｅＳｔＴｅｓｔＭｅｔｈｏｄ标识测试类初始化函数ＴｅｓｔＦｉｘｔｕｒｅＳｅｔｕｐＣｌａｓｓＩｎｉｔｉａｌｉｚｅ标识测试类资源释放函数ＴｅｓｔＦｉｘｔｕｒｅＴｅａｒＤｏｗｎＣｌａｓｓＣｌｅａｎｕｐ标识测试用例初始化函数ＳｅｔｕｐＴｅｓｔｌｎｉｔｉａｌｉｚｅ标识测试用例资源释放函数ＴｅａｒＤｏｗｎＴｅｓｔＣｌｅａｎＵｐ标识测试用例说明Ｎ／ＡＤｅｓｃｒｉｐｔｉｏｎ标识忽略该测试用例ＩｇｎｏｒｅＩｇｎｏｒｅ标识该用例所期望抛出的异常ＥｘｐｅｃｔｅｄＥｘｃｅｐｔｉｏｎＥｘｐｅｃｔｅｄＥｘｃｅｐｔｉｏｎ标识测试用例是否需要显式执行Ｅｘｐｌｉｃｉｔ标识测试用例的分类Ｃａｔｅｇｏｒｙ正确的掌握这些标记，就可以熟练的使用自动化测试的框架编写自动测试脚本。对于自动化测试工具的使用也是有好处的。第四章软件测试自动化工具的技术原理３３４．２ＡｕｔｏＴｅｓｔｅｒ技术原理依照ＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＳｔｕｄｉｏ．ＮＥＴ的开发者所述：．ＮＥＴＲｅｆｌｅｃｔｉｏｎ命名空间能够映射一个给定的程序集；．ＮＥＴＣｏｄｅＤｏｍ命名空间能够动态地编写测试脚本；后期绑定技术能够调用一个方法测试数据和测试结果可以使用ＸＭＬ和ＭＳＥｘｃｅｌ电子表格呈现。因此，利用．ＮＥＴ编程和ＭＳＥｘｃｅｌＲｅｆｌｅｃｔｉｏｎ，．ＮＥＴＣｏｄｅＤｏｍ，后期绑定技术，ＸＭＬＡＰＩ编程，实现完全自动化软件测试过程是完全可能的。ＡｕｔｏＴｅｓｔｅｒ工具完美地整合了这些技术并用六个步骤来展示自动化测试过程，如图４．１所示。图４．１自动化软件测试的六个步骤在开发生命周期内，代码是经常被添加和更改的，为了保证添加和更改的正确性并且没有引入副作用，频繁地测试是很必要的。图４．１中的迭代体现出了这一特征。另外，生成的测试脚本也可以用于回归测试。待测试程序集与．ＮＥＴＲｅｆｌｅｃｔｉｏｎ命名空间之间的关系犹如日光和棱镜之间的关系。棱镜把日光映射到它的波长光谱之内：同样地，ＮＥＴＲｅｆｌｅｃｔｉｏｎ命名空间把一个程序集反汇编成类、属性和方法成员１２１１。因此，ＡｕｔｏＴｅｓｔｅｒ工具开发能够使用它自动地完成信息收集过程。这个过程类似于测试工程师花时间了解产品。在信息被收集之后，．ＮＥＴＣｏｄｅＤｏｍ开始涉入。ＣｏｄｅＤｏｍ命名空间具有在运行时建立定制应用程序和输出多编程语言源代码的能力。最后，ＡｕｔｏＴｅｓｔｅｒ工具开发将使用这个命名空间来编写基于．ＮＥＴ本。Ｒｅｆｌｅｃｔｉｏｎ命名空间反汇编信息的测试脚联合．ＮＥＴＲｅｆｌｅｃｔｉｏｎ和．ＮＥＴＣｏｄｅＤｏｍ，工具能够以与最小的交互把信息收集和脚本编写过程相结合。软什测试自动化研究与应用为了能够存储测试结果，测试工具使用ＸＭＬ文档作为数据储存。ＸＭＬ己经被许多工业标准广泛地接受，使用ＸＭＬ数据存储可提高软件测试自动化。另外，它也还能够被应用到不同的开发环境和平台。在ＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＳｔｕｄｉｏ．ＮＥＴ集成开发环境（ＩＤＥ）中，程序集是由ＭＳＩＬ汇编程序构建。为了运行测试脚本，可以使用后期绑定技术动态地调用测试。后期绑定技术是一种能在运行时识别给定对象潜在的类型，属性和方法及调用这些方法的技术。使用后期绑定技术将使自动化测试工具更有效。因此，在ＭＳ．ＮＥＴ编程环境的协助下，完全自动化测试工具是可以实现的。４．３ＡｕｔｏＴｅｓｔｅｒ工具的应用ＡｕｔｏＴｅｓｔｅｒ工具的显著特点是能够编写可以保存的测试脚本，并且每当更改代码时都可以重新运行该测试脚本。因此不仅可以更容易地检测到代码中的缺陷，而且最终能够交付更好的应用程序。而这一特点正好符合极限编程（）（Ｐ）的特征。ＫｅｎｔＢｅｃｋ创建了极限编程（ＸＰ），在他的书中，极限编程被解释为：接受变化【２２１。根据他的定义，ＸＰ是一种把风险软件项目的重点放在编码上的轻量级技术。它避开详细的规格说明并把每个任务视为一个简单的编程。为了要完成一个复杂的问题，它得依赖于频繁的迭代和开发者，测试者，用户之间的通信。自动化测试是使用ＸＰ开发成功的关键。由于需求、规格说明和代码经常改变，当添加，更改和删除代码的时候，测试是必须的。代码通常是被持续改变和改进的，而且有时候开发者也没有意识到所发生的改变。仅仅通过频繁的测试才能使程序员了解到代码的改变是有效的。不像在其它开发模型中创建代码，ＸＰ代码是处于一种易变状态。它能被重新设计、重新编制、删除和完全重做。最后，测试将确保系统仍然正常工作。ＸＰ需要为类和组件的公共接口进行反复的测试。系统的执行是在系统遵守接口约定，自动化测试有效的情况下动态改变的。只有在新的或修改的特征被测试有效后，它才能被整合。可能潜伏缺陷的所有事物必须被测试。本文的ＡｕｔｏＴｅｓｔｅｒ工具将会很好地帮助ＸＰ团队进行自动化测试。４．４验证，确认和测试结果表达自动化测试工具完成从收集测试信息，且测试脚本已经完成后，测试脚本是如何使用测试结果验证待测试程序集的执行，如何确认测试结果，如何报告测试结果的呢？传统的验证包括审查和评估代码逻辑。ＡｕｔｏＴｅｓｔｅｒ工具中的验证是由计算机软硬件和测试脚本执行之间的接口来完第四章软件测试自动化工具的技术原理３５成的，它测定以下各项：＞待测试类成员是否按预期执行；＞执行是否与指定的硬件和软件配置相兼容：＞执行是否捕获异常；＞执行是否生成错误提示信息。验证回答了代码是否按预先定义的系列正确地执行。确认发生在验证完成之后，它包括真实的测试。确认能被定义为在测试结束时评估软件产品以确保正确的输出和顺从软件需求的过程。最后，测试报告呈现验证和确认的测试结果。４．４．１自动验证使用ＡｕｔｏＴｅｓｔｅｒ工具，测试脚本能够引导验证过程并返回结果，这些返回结果验证待测试产品是否符合所需的代码逻辑。在每个测试方法中，存在断言比较语句，如果初始化成功了而且确保没有来自代码执行的逻辑错误，那么测试结果报告中报告该类的构造函数成功通过了测试。执行失败了，那么就在测试结果报告中指明该类的构造函数没有通过测试并报告没通过的原因。为了验证测试目标属性，通常也设计断言的比较，如果期望值和实际值一致，则通过了测试。当然，一些属性可能是只读的，即只有ｇｅｔ方法。这就需要提前判断测试数据值。可以看出验证之后，断言语句能够发现ｂｕｇ并指明没通过的原因。因此，这个验证测试服务于以下目的：１．为产品的质量和有效地执行提供数据。２．告知开发者缺陷。３．增进软件测试的有效。４．帮助软件测试工程师提高软件的设计标准。测试工程师通常是按照特定的步骤来确定所发现的问题是否是一个缺陷。然而，自动化测试工具却是基于方法的调用来做出判断。在方法调用期间，它发现错误和缺陷。但是，自动化工具是否能够验证所有的测试任务都已经执行了呢？答案依赖于测试团队的需求和软件项目的架构。ＡｕｔｏＴｅｓｔｅｒ工具实现的是～般地测试目的。这些方法的基本原理也可以应用到其它的测试工具开发中。基于一般测试需求的性质，这个ＡｕｔｏＴｅｓｔｅｒ工具目前能够执行如下测试任务：１．单元测试开发者和测试者能够使用这个工具为待测试程序集中的所有组件生成测试脚本代码。软件测试自动化研究与应用２．集成测试的测试工具能够接收对象作为方法的参数，即能够测试应用程序的组合模块。３．白盒和黑盒测试在．ＮＥＴＲｅｆｌｅｃｔｉｏｎ命名空间的帮助下，ＡｕｔｏＴｅｓｔｅｒ工具本身执行了程序集方法的白盒测试。另一方面，生成的测试脚本能够在客户端计算机系统上运行。此时对这个工具的用户来讲，它又是一个黑盒测试。４．兼容性测试工具能够测定在给定的硬件和软件环境中应用程序运行得如何。因此，它能确保最后代码行添加到产品中之后，所有的代码至少测试过～次。４．４．２自动确认软件测试的目的是尽可能早和尽可能多的找出ｂｕｇ，然后开发者根据测试报告确定ｂｕｇ。虽然测试／确定过程对软件开发项目是不断发生的，但是没人敢保证他们的软件没有ｂｕｇ。难度是很明显的。举例来说，当测试一个接受整数值作为参数的方法的时候，测试所有有效的整数和测试各种条件下这个整数参数工作的组合是不可能的。再加上处理器可能使用其它模块来操作那些超出了测试代码控制的整数。ＡｕｔｏＴｅｓｔｅｒ工具使用相同边界条件策略来处理这些问题。为了在自动化测试工具中使用边界条件策略，测试工程师需要完成以下事情：１．彻底地审查生成的测试数据存储并理解好每一块信息；２．给测试数据存储赋值那些能发现缺陷的高概率数据，而不是程序正确工作的数据；３．给测试数据存储赋值那些有效数据和无效数据来测试待测试方法是否返回期望的结果和错误信息；４．利用预期的返回值验证测试结果；５．使用其它测试方法执行相同的测试案例；６．使用边界和攻击性方法发现缺陷保证产品质量。ＡｕｔｏＴｅｓｔｅｒ工具的目的是找出软件产品中数据和算法方面的ｂｕｇ。对于单元测试，一方面，ＡｕｔｏＴｅｓｔｅｒ工具是基于测试数据存储中取回的数据来验证测试的。另一方面，这个工具能够以预定的方式重新运行生成的测试脚本来进行回归测试。回归测试的结果将决定更改后应用程序的执行是否仍然符合所有的需求。除此之外，测试不需要人的干预就能连续地执行。当发现缺陷的时候，工程师将会及时地被告知结果。ＡｕｔｏＴｅｓｔｅｒ工具的这个特征是很有用的并且使回归测试很容易管理。对于集成测试，确认的作用域包括下列各项：＞模块是否彼此之间有不利地影响；第四章软件测试自动化工具的技术原理３７＞整合其它类型作为参数的方法是否返回预期的结果；＞通过对象传递参数是否影响执行的准确度和精度。在软件开发项目期间，它需要一个熟练的管理员来保持跟踪并确保所有必需的测试都被执行。对于一个大而复杂的项目，这通常是相当困难的任务。ＡｕｔｏＴｅｓｔｅｒ工具的使用将会大幅度地减少难度并确保满足如下标准：１．所有的测试脚本都已经执行；２．通过重新运行测试脚本，所有发现的错误和缺陷己经被纪录而且得到满惫地解决；３．所有变化都及时的地作了重新测试。ＡｕｔｏＴｅｓｔｅｒ工具保证对程序集的所有方法都经过了测试并对测试结果有一个完全地复制备份，它还记录了测试日期和时间。测试结果不仅清楚地报告哪些方法通过了测试和哪些方法没有通过测试，而且还陈列出测试条件以便人工查看。日期和时间戳则用来报告测试进展对自动化回归测试的影响。最后，这个测试的结果将确认代码逻辑、商业逻辑和表示层是否都被正确地整合。第百章软件测试自动化应州第五章软件测试自动化应用５１编写自动测试脚本ＡｕｔｏＴｅｓｔｅｒ工具不使用日前流行的捕获／Ｍ放方法编写测试脚本。与那些被动的测试工具相反，ＡｕｔｏＦｅｓｔｅｒ工具使用一种方法米｛动地彻底地搜寻整个待测试程序集，首先找出要测试的所有成员。然后根据已发现的成员和组建好的测试用例，一个测试脚本就可以生成了。最后把测试脚本编译成个动惫链接库（ｄ１１）。ＤＬＬ程序集通过后期绑定技术在后来的自动化测试『『＝其中调用。因此，通过点击几个按钮，测试工程师就能完成以下事情：＞给自动化测试＿［其传人待测试的程序集：≯检告测试结果，＞撇告发现的缺陷；＞用ＸＭＬ格式存储测试结果。５１１为测试脚本创建工程在ＭｉｃｒｏｓｏＲＶｉｓｕａｌＳｔｕｄｉｏＮＥＴ中，创建一个新的Ｔ程。选择Ｖｉｓｕａｌｃ＃１’程作为Ｉ稃类型，ＣｌａｓｓＬｉｂｒａｒｙ作为模板。将工程命名为ＭｕｌｔｉＲｅｗＳｍｏｋｉｎｇＴｅｓｔ，图５１是个描述奉步骤的ＶｉｓｕａｌＳｔｕｄｉｏＮＥＴ。幽５Ｉ刨建卟工样４０软件测试自动化研究与应用从图５．１中可以看出，创建了一个类库用作测试类。而且该ｎａｍｅｓｐａｃｅ的名字是：ＭｕｌｔｉＲｏｗＳｍｏｋｉｎｇＴｅｓｔ。５．１．２添加引用在ＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＳｔｕｄｉｏ．ＮＥＴ里创建这个测试脚本时，需要增加ｆｒａｍｅｗｏｒｋ和Ｆｏｒｍ的引用，如下：＞ｕｓｉｎｇＧｒａｐｅＣｉｔｙ．ＡｕｔｏＴｅｓｔ．Ｆｒａｍｅｗｏｒｋ．Ｔｅｓｔ使用ＡｕｔｏＴｅｓｔｅｒ工具来识别待测试程序集之前，必须在被测试类应用中加入该引用，该命名是：ＧｒａｐｅＣｉｔｙ．ＡｕｔｏＴｅｓｔ．Ｆｒａｍｅｗｏｒｋ．Ｔｅｓｔ。＞ｕｓｉｎｇＧｒａｐｅＣｉｔｙ．ＡｕｔｏＴｅｓｔ．Ｆｒａｍｅｗｏｒｋ．Ｉｎｔｅｒａｃｔｉｏｎ添加该Ｆｒａｍｅｗｏｒｋ的引用，结合上面的引用，都是为了完善对ＡｕｔｏＴｅｓｔｅｒ工具的使用。＞ｕｓｉｎｇｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ．Ｆｏｒｍ由于在测试产品中存在一些ＵＩ操作，如：点击控件，输入数据，鼠标移动等，因此需要添加Ｆｏｒｍ的引用。这些ＵＩ的操作都是在ｆｏｒｍ上进行的。如果不添加，在自动测试的过程中，由于缺少界面，测试用例将全部产生错误。但是，在图５．１中创建的类库中并没有Ｆｏｒｍ的引用，所以需要特别添加。５．１．３为工程添加脚本在已经创建好的工程中添加脚本，需要包含在产品的５．０版本中的所有自动化测试的测试用例。脚本的组织结构如图５．２所示。图５．２脚本组织结构图这些脚本都是定义在ＭｕｌｔｉＲｏｗＳｍｏｋｉｎｇＴｅｓｔ的ｎａｍｅｓｐａｃｅ中，根据图５．２，具第五章软件测试自动化应用４ｌ体来分析ＭｕｌｔｉＲｏｗＧｒｉｄＴｅｓｔ下的所有结构，它包括：１．Ａｐｐｅａｒａｎｃｅ主要测试产品的界面，风格，样子等。它包含以下类：》ＣｅｌｌＢｏｒｄｅｒＴｅｓｔ＞ＣｅｌｌｌｂｏｌＴｉｐＴｅｓｔ》ＣｏｍｍｏｎｓＴｃｓｔ＞ＬｏｏｋＡｎｄＦｅｅｌＴｅｓｔ＞ＭａｒｇｉｎＡｎｄＰａｄｄｉｎｇＴｅｓｔ＞ＯｗｎｅｒＤｒａｗＴｅｓｔ＞ＴｅｘｔＡｌｉｇｎｍｅｎｔｓ＿Ｔｅｓｔ》ＴｈｅｍｅＴｅｓｔ２．Ｂｅｈａｖｉｏｒ主要测试产品的行为，如鼠标和键盘的操作、选择、剪切、复制和粘贴等。它包含以下的类：》ＡｕｔｏＳｉｚｅＴｅｓｔ＞ＣｅｌｉＡｃｔｉｏｎｓＴｅｓｔ＞ＣｏｍｍｏｎｓＴｅｓｔ》ＣｕｒｒｅｎｔＣｅｌｌＴｅｓｔ＞ＦｉｌｔｅｒＴｅｓｔ＞ＦｒｅｅｚｅＴｅｓｔ＞ＨｉｔＴｅＳｔＴｌｅｓｔ＞ＲｅｓｉｚｅＴｅｓｔ＞ＲｏｗＡｃｔｉｏｎｓＴｅｓｔ＞ＳｃｒｏｌｌＴｅｓｔ＞ＳｈｏｒｔＣｕｔＫｅｙＴｅｓｔ》ＳｏｒｔＴｅｓｔ＞ＳｐｌｉｔＴｅｓｔ＞ＵＩＣｕｔＣｏｐｙＰａｓｔｅ＿Ｔｅｓｔ＞ＵＩＥｄｉｔＴｅｓｔ＞ＵＩＳｅｌｅｃｔｉｏｎＴｅｓｔ＞ＶｉｅｗＭｏｄｅＴｅｓｔ＞ＺｏｏｍＴｅｓｔ３．Ｃｏｍｍａｎｄ对产品中一些命令的测试，例如打印，插入等命令。它所包含的类如下：４２软件测试自动化研究与应用＞ＤａｔａＴｒａｎｓｌａｔｉｏｎＴｅｓｔ≯ＥｒｒｏｒＴｅｘｔ乃ｓｔ＞ＩｎｓｅｒｔＲｅｍｏｖｅ—Ｔｅｓｔ＞Ｐｒｉｌｌｔ１ｒｅｓｔ４．ＤａｔａＢｉｎｄｉｎｇ主要是进行数据邦定方面的测试，它包含的所有类如下：＞ＡｕｔｏＡｄｄＤｅｌｅｔｅＲｏｗＴｅｓｔ＞ＣｏｍｍｏｎｓＴｅｓｔ＞ＤａｔａＢｉｎｄｉｎｇ＿Ｔｅｓｔ＞ＵｎＢｏｕｎｄＴｅｓｔ＞ＶｉｒｔｕａｌＭｏｄｅＴｅｓｔ５．Ｃｅｌｌｓ主要测试产品中所有的ｃｅｌｌ类型，它的每一个类都代表一个类型的ｃｅｌｌ，它包括：＞ＢａｓｅＣｅｌｌＴｅｓｔ＞ＢｕｔｔｏｎＣｅｌｌＴｅｓｔ＞ＣｈｅｃｋＢｏｘＣｅｌｌＴｅｓｔ＞ＣｏｍｂｏＢｏｘＣｅｌｌＴｅｓｔ＞ＤａｔｅＴｉｍｅＰｉｃｋｅｒＣｅｌｌＴｅｓｔ＞ＬａｂｅｌＣｅｌｌＴｅｓｔ＞ＬｉｎｋＬａｂｅｌＣｅｌｌＴｅｓｔ＞ＭａｓｋｅｄＴｅｘｔＣｅｌｌＴｅｓｔ＞ＮｕｍｅｆｉｃＵｐＤｏｗｎＣｅｌｌＴｅｓｔ＞ＰｉｃｔｕｒｅＢｏｘＣｅｌｌＴｅｓｔ＞ＰｒｏｇｒｅｓｓＢａｒＣｅｌｌＴｅｓｔ＞ＲａｄｉｏＧｒｏｕｐＣｅｌｌＴｅｓｔ＞ＴｅｘｔＢｏｘＣｅｌｌＴｅｓｔ以上所有的类在定义的时候都需要标识测试类，具体声明为：＞【ＴｅｓｔＦｉｘｔｕｒｅ】Ｐｕｂｌｉｃｃｌａｓｓ＜ｃｌａｓｓｎａｍｅ＞ＡｕｔｏＴｅｓｔｅｒ工具要求每个测试类都必须添加ＴｅｓｔＦｉｘｔｕｒｅ的Ａｔｔｒｉｂｕｔｅ，并且携带一个ｐｕｂｌｉｃ无参构造函数。这样子，这些方法都能够在ＡｕｔｏＴｅｓｔｅｒ自动测试工具中被识别。第五章软件测试自动化应用５１．４编译测试脚本当测试脚本写完之后就会进行编译，如果该ｓｏｌｕｔｉｏｎ编译成功会自动生成ＭｕｌｔｉＲｏｗＳｍｏｋｉｎｇＴｅｓｔｄｌｌ。这个就是可以加载到自动化测试工具里的特测程序集，编译后存在于ｂｉｎ／ｄｅｂｕｇ文件夹中。５．２运行自动测试工具５．２１执行自动测试工具为了启动该自动测试工具，系统需要如下配置：≯ＶｖｑｎｄｏｗｓＮＴ／２０００／ＸＰ≯ＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＳｔｕｄｉｏＮＥＴＦｒａｍｅｗｏｒｋ＞ＭｉｃｒｏｓｏｆｌＶｉｓｕａｌＳｔｕｄｉｏＮＥＴＩＤＥＡｕｔｏＴｃｓｔｅｒ运行后，出现窗体如图５．３，它打开时没有加载任何程序集。５．３运行ＡｕｔｏＴｅｓｔｅｒＡ－具打开ＡｕｔｏＴｅｓｔｅｒ后，首先熟悉一下它的布局。ＡｕｔｏＴｅｓｔｅｒ工具虽上面的主菜单有：Ｆｉｌｅ，Ｔｅｓｔ，Ｒｅｓｕｌｔ，Ｔｏｏｌｓ，Ｈｅｌｐ１Ｆｉｌｅ主菜单有以下内容：＞Ｎｅｗｅｒｏｊｅｃｔ软件测试自动化研究与应用允许创建一个新工程。工程是一个测试程序集的集合。这种机制可以组织多个测试程序集，并把他们作为一个组对待。＞Ｌｏａｄ加载一个新的测试程序集，或一个以前保存的ＡｕｔｏＴｅｓｔｅｒ工程文件。＞Ｕｎｌｏａｄ关闭现在加载的测试程序集或现在加载的ＡｕｔｏＴｅｓｔｅｒ工程。＞Ｒｅｌｏａｄ强制重载现有测试程序集或ＡｕｔｏＴｅｓｔｅｒ工程。ＡｕｔｏＴｅｓｔｅｒｉ自动监测现加载的测试程序集的变化。当程序集变化时，测试运行器重新加载测试程序集。当测试正运行时，现在加载的测试程序集不会重新加载，只有在测试运行之间测试程序集才可以重新加载。而且不能忘记这个忠告：如果测试程序集依赖另外一个程序集，测试运行器不会观察任何依赖的程序集。对测试运行器来说，强制一个重载使全部依赖的程序集变化可见。＞ＲｅｃｅｎｔＦｉｌｅｓ说明５个最近在ＡｕｔｏＴｅｓｔｅｒ中加载的测试程序集或ＡｕｔｏＴｅｓｔｅｒ工程（这个列表在Ｗｉｎｄｏｗｓ注册表，由每个用户维护，因此如果共享ＰＣ仅看到该用户的测试）。＞Ｅｘｉｔ退出。２．Ｔｏｏｌｓ菜单有这些项：＞ＬｏａｄＡｓｓｅｍｂｌｙ／ＣｌｏｓｅＡｓｓｅｍｂｌｙ加载／关闭程序集。＞Ｏｐｔｉｏｎｓ可以定制ＡｕｔｏＴｅｓｔｅｒ的行为。３．Ｒｅｓｕｌｔ菜单有下面的项：＞Ｅｘｐｏｒｔ作为ＸＭＬ文件保存运行测试的结果。＞Ｉｍｐｏｒｔ输入测试结果。图５．３中，底部有一个状态条，它表示下面的状态：＞Ｓｔａｔｕｓ说明了现在运行测试的状态。当所有测试完成时，状态变为Ｃｏｍｐｌｅｔｅｄ。运行测试中，状态是Ｒｕｎｎｉｎｇ：＜ｔｅｓｔ－ｎａｍｅ＞（＜ｔｅｓｔ．ｎａｍｅ＞是正在运行的测试名称）。＞ＲｕｎＣａｓｅｓ已经完成的测试个数。Ｃａｓｅｓ到目前为止，所有测试中失败的个数。＞Ｆａｉｌｅｄ第五章软件测试自动化应用≯ＣｏｎｓｕｍｅｄＴｉｍｅ显示运行测试时问（以秒计）５．２２加载待测程序集当第一次开始ＡｕｔｏＴｅｓｔｅｒ，它打开时没有测试加载。从Ｆｉｌｅ菜单选择Ｏｐｅｎ，浏览ＭｕｌｆｉＲｏｗＳｍｏｋｉｎｇＴｅｓｔｄｌｌ的路径。加载此测试的程序集，测试运行器为加载的程序集的测试产生一个可见的表现。所有的测试脚本都将在中间的面版中出现，测试程序集的结构如图５．４所示。在５Ｓｃｒｏｌｌ１３节中，介绍了所有脚本的结构关系。本次测试就以Ｂｅｈａｖｉｏｒ下的Ｔｅｓｔ类为例子。图５．４测试程序集的测试在Ａｕｔｏ晰中的视图在图５．４中，该程序集有很多的测试用例，都是以１ｈｅⅥｅｗ的形式展现出来，在默认情况下，所有的测试用例都将被选择。当然，也可以根据自己的需要选择要测试的测试用例。程序集中的任意钡４试用例都可以单独执行。现在展现出来的是ＭｕｌｔｉＲｏｗＧｒｉｄＴｅｓｔ下的Ｂｅｈａｖｉｏｒ里面的ＳｃｒｏｌｌＴｅｓｔ类，这个类中包台许多个测试方法，可以用来测试所有的Ｓｃｒｏｌｌ行为。举个例子，现在任意选择两个测试用例运行，选择图５．４中的ＧｃＭｕｌｔｉＲｏｗＳｅｒｏｌｌＢａｒＭｏｄｅ０１和ＧｃＭｕｌｔｉＲｏｗＳｃｒｏｌｌＢａｒＭｏｄｅ０２两个测试方法。然后按Ｒｕｎ按钮运行这两个测试用例之后，所选择树的节点变为绿色。具体见图５５。软件测试自动化研究‘ｊ席削幽５．５运行已选择的测试用例从图中可以非常容易发现，选择的树结点变成绿色，左下角有个进度条也变成了绿色，绿色代表成功通过。运行的测试用例的个数，失败的个数以及运行所耗费的时间都会在计算并显示出来。在这个例子中，２个例子全部成功，耗费的时间为：３４５３秒。在运行完自动化测试后，ＡｕｔｏＴｅｓｔｅｒ工具的右边还可以显示具体的出错信息，由于上例的结粜都是正确的，因此右边的面板内没有任何信息。当然，运行后，可能会出现另一种情况，如罔５．６所示：图５，６测试用例运行的另外一个效果第五章软件测试自动化应用对比图５．５和图５．６，从图中可以非常容易发现，左下角是个状态条的颜色是不一样的。图５．６是红色的，而图５．５是绿色的。为什么会这样呢？因为如果所有测试用例运行成功，状态条就为绿色；反之如果有一个不成功，则为红色，并且也存在有黄色。具有来说，进度条的颜色反映了测试执行的状态：＞绿色：描述目前所执行的测试都通过。＞黄色：意味某些测试忽略，但是这里没有失败。＞红色：表示有失败。图５．６中，ＡｕｔｏＴｅｓｔｅｒ工具右边的ＦａｉｌｅｄＴｅｓｔＣａｓｅｓ面板描述了所有失败的测试，当鼠标点击到任意一个失败的测试（即红色的结点）的时候，具体的信息就出现在ＦａｉｌｅｄＴｅｓｔＣａｓｅｓ面板的下部。这里给出了ＣａｓｅＥｒｒｏｒＭｅｓｓａｇｅ，就是测试用例失败的信息是期望值和实际值不一致。而且还列出具体失败的测试用例是在脚本的多少行。这样子就可以根据测试的结果追查是什么地方出现了问题，以及软件发生了什么样的缺陷。品：５．３影响测试结果的属性上节中的不同的图是测试用例的不同结果，在实际的过程中，有很多的属性可以影响到它们。本节就来具体说明这些影响测试结果的属性。５．３．１Ｉｇｎｏｒｅ属性在上节的图５．６中，一些树的节点是红色的。除此之外，还会存在一些黄色的节点。从上节的内容可以知道，黄色意味着某些测试忽略，但是没有失败。之所以出现这种节点，是因为在测试的过程中，由于种种原因，有一些测试用例并不想运行。当然，这些原因可能包括：这个测试还没有完成：这个测试正在重构之中；这个测试的需求不是太明确。即使如此，如果不想破坏整体的测试，也不想花费过多的时间等待全部测试完成，这个时候可以使用Ｉｇｎｏｒｅ属性。这样子的话，既可以保持测试，又不运行那些不想运行的测试。要忽略一个测试方法，需要标记该测试方法为Ｉｇｎｏｒｅ属性，即在该方法前面标记：＞［Ｉｇｎｏｒｅ（”ｇｃＭｕｌｔｉＲｏｗ＿ＳｃｒｏｌｌＢａｒＭｏｄｅ＿Ｏ１ｉｓｉｇｎｏｒｅｄ！”）】括号里面描述该忽略的测试方法的信息，当自动化运行该测试方法后，在面板中会出现括号中描述的信息。软件测试自动化研究与应用Ｉｇｎｏｒｅ属性可以附加到一个独立的测试方法，也可以附加到整个测试类（ＴｅｓｔＦｉｘｔｕｒｅ）。如果Ｉｇｎｏｒｅ属性附加到ＴｅｓｔＦｉｘｔｕｒｅ，所有在ｆｉｘｔｕｒｅ的测试都被忽略。５．３．２ＥｘｃｅｐｔｅｄＥｘｃｅｐｔｉｏｎ属性当然在测试的过程中会有异常的出现。这种异常有两类：一种是不可预测的异常，ＡｕｔｏＴｅｓｔｅｒ所采取的框架可以自动处理。另一种是测试中某些操作抛出的异常。例如，在实例中增加除法，某个操作被０除，就会抛出异常。这个异常和．ＮＥＴ文档描述的一样，此时，需要在这个测试方法里验证这个假设的异常的时候，可以添加ＥｘｃｅｐｔｅｄＥｘｃｅｐｔｉｏｎ属性。在会抛出异常的测试方法前面标记：＞［ＥｘｐｅｃｔｅｄＥｘｃｅｐｔｉｏｎ（ｔｙｐｅｏｆ（ＤｉｖｉｄｅＢｙＺｅｒｏＥｘｃｅｐｔｉｏｎ））】ＥｘｐｅｃｔｅｄＥｘｃｅｐｔｉｏｎ属性可以在执行过程中捕获期望的异常类型，例如在本例就是ＤｉｖｉｄｅＢｙＺｅｒｏＥｘｃｅｐｔｉｏｎ。如果这个方法在没有抛出期望异常的情况下完成了，这个测试方法将会出现失败的结果。当然，如果要正确标记这个属性就必须在自动化测试该测试方法前确切知道抛出的异常类型。例如本例就是ＤｉｖｉｄｅＢｙＺｅｒｏＥｘｃｅｐｔｉｏｎ异常，如果标记的异常类型不正确，也会出现失败的结果。５．３．３Ｅｘｐｌｉｃｉｔ属性在执行程序集的过程中，有的测试用例——有关性能测试的测试用例，执行一次要花很长的时间，并不需要（也无法忍受）每次自动化测试时都去执行这样的测试用例，使用Ｅｘｐｌｉｃｉｔ标记可以让这个测试用例只有在显示调用下才会执行：＞［Ｔｅ％Ｅｘｐｌｉｃｉｑ这个属性同样也是标记在测试方法名的前面，当自动化的运行该测试方法后，该节点会变成黄色，和Ｉｇｎｏｒｅ属性的节点颜色一致。５．３．４Ｃａｔｅｇｏｒｙ属性也许会有这样的情况，类似上节中耗时的测试用例在整个测试工程中可能有数十个，或许更多。这个时候就需要把这些测试用例都组织起来，就可以一起运行或者不运行。使用Ｃａｔｅｇｏｒｙ标记可实现此功能：＞【Ｔｅ巩Ｅｘｐｌｉｃｉｔ，Ｃａｔｅｇｏｒｙ（”ＬｏｎｇＴｅｓｔ”）】这样，只有当显示选中ＬｏｎｇＴｅｓｔ分类时，这些测试用例才会执行。当选择需要运行的测试类目录，或选择除了这些目录之外的测试都可以运行。在命令行环第五章软件测试自动化应用４９境里／ｉｎｃｌｕｄｅ和／ｅｘｃｌｕｄｅ来实现。而在ＡｕｔｏＴｅｓｔｅｒ工具界面的环境下，就更简单了，选择左边工作域里的ＣａｔａｇｏｒｉｅｓＴａｂ，选择Ａｄｄ和Ｒｅｍｏｖｅ既可以了。５．４比较测试结果为了检测产品某些属性、方法是否正确，就需要对测试结果与正确的结果进行比较。这个时候，需要在测试方法中加入断言。断言用于帮助确定某个被测试函数是否工作正常。通常一个测试方法中会有多个断言，当一个断言失败时，该测试方法就会终止。可使用Ａｓｓｅｒｔ或Ａｓｓｅｒｔｉｏｎ调用断言函数。由于ＡｕｔｏＴｅｓｔｅｒ工具是用Ｎｕｎｉｔ框架，而ＮＵｎｉｔ提供了一个断言类ＮＵｎｉｔ．Ｆｒａｍｅｗｏｒｋ．Ａｓｓｅｒｔ，可用来进行简单的ｓｔａｔｅｂａｓｅｔｅｓｔ。但在实际使用中，往往需要自己编写一些高级断言。这些常用的断言如表５．１所示。表５．１常用的断言ｍｅｔｈｏｄｕｓａｇｅｅｘｐｅｃｔｅｄ，ｅｘａｍｐｌｅＡｓｓｅｒｔ．ＡｒｅＥｑｕａｌ（ｏｂｊｅｃｔ验证两个对象是否相等验证两个引用是否指向同意对象Ａｓｓｅｒｔ．ＡｒｅＥｑｕａｌ（２，１＋１）ｏｂｊｅｃｔａｃｔｕａｌ［，ｓｔｒｉｎｇｍｅｓｓａｇｅ］）Ａｓｓｅｒｔ．ＡｒｅＳａｍｅ（ｏｂｊｅｃｔｅｘｐｅｃｔｅｄ，ｏｂｊｅｃｔｅｘｐｅｃｔｅｄ＝ｎｅｗｏｂｊｅｃｔＯ；ｏｂｊｅｃｔａｃｔｕａｌ＝ｅｘｐｅｃｔｅｄ；Ａｓｓｅｒｔ．ＡｒｅＳａｍｅ（ｅｘｐｅｃｔｅｄ，ａｃｔｕａｌ）ｏｂｊｅｃｔａｃｔｕａｌ［，ｓｔｒｉｎｇｍｅｓｓａｇｅ］）Ａｓｓｅｒｔ．ＩｓＦａｌｓｅ（ｂ００１）验证ｂｏｏｌ值是否为ｆａｌｓｅＡｓｓｅｒｔ．ＩｓＦａｌｓｅ（ｆａｌｓｅ）Ａｓｓｅｒｔ．ＩｓＴｒｕｅ（ｂ００１）验证ｂｏｏｌ值是否为ｔｒｕｅＡｓｓｅｒｔ．ＩｓＴｒｕｅ（ｔｒｕｅ）Ａｓｓｅｒｔ．ＩｓＮｏｔＮｕｌｌ（ｏｂｊｅｃｔ）验证对象是否不为ｎｕｌｌＡｓｓｅｒｔ．ＩｓＮｏｔＮｕｌｌ（ｎｅｗｏｂｊｅｃｔＯ）Ａｓｓｅｒｔ．ＩｓＮｕｌｌ（ｏｂｊｅｃｔ）验证对象是否为ｎｕｌｌＡｓｓｅｒｔ．ＩｓＮｕｌｌ（ｎｕｌｌ）；表５．１中的这些断言来比较测试结果，具体应用方法是：＞Ａｓｓｅｒｔ．ＡｒｅＥｑｕａｌｓ（ｅｘｐｅｃｔｅｄ，ａｃｔｕａｌ［，ｓｔｒｉｎｇｍｅｓｓａｇｅ】）Ｅｘｐｅｃｔｅｄ是被测试代码的期望值，ａｃｔｕａｌ是被测试代码的实际值，ｍｅｓｓａｇｅ是一个可选的消息，在二个值不一致时报告错误。Ｅｘｐｅｃｔｅｄ和ａｃｔｕａｌ可以是一个对象。对于浮点数的比较，使用ＡｒｅＥｑｕａｌｓ（ｅｘｐｅｃｔｅｄ，ａｃｔｕａｌ，ｔｏｌｅｒａｎｃｅ【，ｓｔｒｉｎｇ轼件测试自动化研究与应川ｍｅｓｓａｇｅｌ）。］￡中，ｌｏｌｅｒａｎｃｅ表不精度，００ｌ表示仪比较小数后＿位。这是经常使用的断言，但是也存在世问题。比如它只能处理基本的数据类型和ＯｂｊｅｃｔＥｑｕａｌｓ接口的对象的比较。而对于自定义对象的比较，通常需要编写高级断言。在本文的脚本中，使Ｈｊ这些基础的断言。当测试结果山玑问题时，ＡｕｔｏＴｅｓｔｅｆ工具将锓示Ｅｘｐｅ＿【ｃｄＶａｌｕｅ和ＡｃｔｕａｌＶａｌｕｅ不同的值。５．５存储测试结果为了便Ｊ一进行随后的测试工作，保存所所有自动化测试的结果是很有必要的。ＡｍｏＴｅｓｔｅｒｆ．具采用ＸＭＬ文档存储数据，点击Ｒｅｓｕｌｔ菜单，选择Ｅｘｐｏｒｔ选项（或７。者按），存储界面见图Ｓ刚５．７存储删试结果界面自动化测试的日的也是为了发现更多的ｂｕｇ并节省时间。自『：么，在自动化结束后，如何呈现测试结果并为开发者提供确定缺陷的信息呢｝ＡｕｔｏＴｅｓｔｅｒ工具通过ＸＭＬ文档在测试结果报告中写入了阿种测试结果：种是报告测试执行通过的百分牢；另一种是报告执行时实际返同值与期望返回值不一样的测试用例。在前面的圈５４中，选择ｒ类ＳｃｒｏｌｌＴｅｓｔ中的两个删试方法：ＧｃＭｕｌｆｉＲｏｗ０ｌ和ＧｃＭｕｌｔｉＲｏｗ０２ｅｄｏＭｒａＢｌｌｏｒｃＳ＿ＳｃｒｏｌｌＢａｒＭｏｄｅ测化动白行进试，全部自动化运行次需婴０５７８秒，全部正确。运行后得到的结果以ＸＭＬ文第五章软件测试自动化应用档的形式存储，然后用网页的形式察看如图５．８。ＡｕｔｏｍａｔｔｏｎＧｅｍｅｒａｌ：ｃｓＴｅｓｆ：ｉｎｇＲｅｐｏｒｔＬａｎｇｕａｇｅ：ｃｈ讷ｅ∞（ｐｅｏｐｌｅ＇ｓＤＩＩＶｅｆ＇ｓｉｏｎ：ｔ，ｆｔａ－ｏｓｏＲ＂Ｗ呐ｄｏｗｓ岍’置】．２６００ｓ】巴ｒ蚪∞Ｐｄ豳ｃｋ＂２Ｒｅｐｕｂｌｉｃａ｝Ｃｈｉｎｅ｝Ｌａｎｇｕａｇｅ：ａ研瓷讧（Ｐｅｏｎ＇ｓ凡印Ｉｆ断ｏｆｄ曲哪ＣｏｒｅＳｏｕｒｃｅ：仞ｎ伽ｅ’，汨ｎＩ¨，ｏｒ科砘Ｉ￡ｏ丁毒ｓ圻ｌｅｉｓ．ｏ¨曲删北殆鲥，蟹、了椒呐巧ｃ懈Ｉｓｍｏｆ＝ｌｎｇ协￡Ｉ射ｎＩＤｅ６叩、朋ⅣｄＲｃ嘲州咖矿ｔ吐删。Ｔ｜稿Ｆｒｘ抽ｒｅ：伽棚Ｒ甜喀ｍｏ＾如删啪．陬棚Ｒ鲥ｒＧ啊碱目嘲ｍ和ｎｓ∞醒Ｔ高矿Ｔｏｔａｌ＝２Ｆ－●ｌｃｄＣ－－ｅ‘＝Ｏｌｇｌｎｏｒｅｄ懈：＝ＯＥｘｅｃｗｔｅｄＴｉｍｅ＝２００８－１－ＩＩ２１：￥７：３ａＴｏｔａｌ（ｏｓｔｅｄＴｉｍｅ：Ｏ．５７８ｓｓＲｅｆｃｒｅｆｌｃｅ＾，ｓ咖ｂ¨１ｅ５｛Ｉ缸蛐ｍｓｃ甜ｌｉｂ，～：。。Ｖｅｆ■ｏａ１．０．０．０２．Ｏ．Ｏ．Ｏ５．Ｏ．Ｏ．０１．０．２７２５．２０７７９２．Ｏ．Ｏ．Ｏ２．Ｏ．Ｏ．Ｏ２．Ｏ．Ｏ．Ｏ２．１．０，０２．Ｏ．ｏ．ＯＦＵｅＶｅｌ＿ｍｌ，要ＭｕＩｔｉＲｏｗＳｒｎｏｋ］ｎｇＴｅｓｔＧｒａＤｅＣｉｔｙ．Ｗｉｎ．ＮｕｌｔｉＲｏｗ５．０．０２７１．０６２１０ＧｒａｐｅＣ３ｔｙ．ＡｕｔｏＴｅｓｔ．巳ｃ【ｅｎ鲥叽Ｈｕ恬如Ｗ（２００６）【Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗ＝．ＦｏｒｒｒｍＳｙｓｔｅｍ．ＤａｔａＳｙｓｔｅｍ．ＤｒａｗｉｎｇＧｒａｐｅＣＪＷ．ＡｕｔｏＴｅｓｔ．ＦｒａｍｅｗｏｒｋＳｙｓｔｅｍ１１１ｅｒｅ皓１１０ｆａｉｌｕｒｅ！图５．８测试结果的形式图５．８中，测试结果报告按如下布局呈现测试结果：＞第一行描述了操作系统和语言环境。＞第二行标明加载．ｄｌｌ程序集的路径。＞第三行是ＴｅｓｔＦｉｘｔｕｒｅ，记录所测试的属于哪个测试类。这两个方法所属的类是：ＭｕｌｔｉＲｏｗＳｍｏｋｉｎｇＴｅｓｔ．Ｖ５０．ＭｕｌｔｉＲｏｗＧｒｉｄＴｅｓｔ．Ｂｅｈａｖｉｏｒ．ＳｃｒｏｌｌＴｅｓｔ。＞第四行是自动化测试最基本的信息，包括总的测试用例，失败的测试，忽略的测试，执行日期和总共花费的时间。＞下面是一个ＲｅｆｅｒｅｎｃｅＡｓｓｅｍｂｉｌｅｓ，它是以表格的形式记录所有版本的信息。＞最后就是具体的测试结果，所有失败的测试用例以表格的形式描述。由于这里两个测试用例都是正确的，所以显示的是“ＴｈｅｒｅｉｓｎＯｆａｉｌｕｒｅ！”。如果存在没有通过的测试用例，它的信息必须包括以下内容：＞从测试数据存储中获取的被测试方法名称。＞测试方法调用的结果。＞给出错误信息，即测试Ｆａｉｌ时，说明Ｆａｊｌ的原因。＞列出测试后的实际返回值，这个实际返回值用于检查是否匹配期望返回值。根据测试结果报告，不仅测试工程师可以找出ｂｕｇ，而且开发者也可以依此确定缺陷。这些都遵循传统测试团队的工作模式。软件测试自动化研究与应用５．６分析自动化测试报告在ｇｃＭｕｌｔｉＲｏｗ５．０产品的开发后期，一共设计测试用例５９４０２个，实现自动化的测试用例有２０１３０个，占总比例的百分之三十多，基本符合自动化的理论——即现阶段接近百分之三十的测试可以实现自动化。为ｇｃＭｕｌｔｉＲｏｗ５．０产品编写的自动化测试和手工测试的测试用例个数和比例分析如表５．２。表５．２手工测试和自动化测试统计表测试测试用例（个）所占比例手工测试３９２７２６６．２％自动化测试２０１３０３３．８％共计５９４０２１００％根据上表，可以清楚地看出：ＡｕｔｏＴｅｓｔｅｒ工具已经达到基本的自动化测试水平，但是手工测试也是必不可少的。这是由于ｇｃＭｕｌｔｉＲｏｗ５．０产品需要智力性质的手工测试。而工具本身不具有想象力，不能像手工测试一样进行发挥，所以不能期望将所有的测试活动进行自动化。在软件开发后期，测试用例已经趋于完善，测试进入了非常重要的阶段。由于到了发布一个版本的后期，测试系统的错误比较少，测试用例的数量却有很多，如果手工执行测试会占用大量的时间。用表５．２中所有测试用例的数量来说明问题，如果仅仅所有的自动化测试用例（２０１３０个）全部改用手工测试的方式，一个熟练的软件测试工程师，每天工作８小时，完成全部则需要２０天／人。而且在这段时间内，必须保证该名软件测试工程师保持同一的测试速率和良好的工作状态，也要排除个人的一些错误（如遗漏，手误等）。相对与此，自动化测试非常的方便和简单，在工具中点击开始按钮后便由系统自动运行。在运行的过程中，也不要浪费任何的人力，很明显的，手工测试的效率远远低于自动化测试，会产生的错误率和成本也远远高于自动化测试。ＡｕｔｏＴｅｓｔｅｒ工具本身不需要任何更改就可以根据最近的版本或是最新的脚本进行测试。运行自动化测试工具ＡｕｔｏＴｅｓｔｅｒ后，ＡｕｔｏＴｅｓｔｅｒ会从ｓｅｒｖｅｒ上获取产品的最新版本，然后加载最新的动态连接库对最新的版本进行自动化测试，当然，也可以根据实际情况选择需要的产品版本进行自动化测试。现在改用自动化的方式替代手工方式测试所有的自动化测试用例。前面已经提到，总的测试用例中，实现测试自动化的用例一共有２０１３０个。改用ＡｕｔｏＴｅｓｔｅｒ工具测试全部运行完毕需要花费１４３０２．２１９秒，失败５６５个，忽略７个。具体的自动化测试的结果如表５．３。第五章软件测试自动化应用表５．３测试自动化结果统计ＣｏｎｔｒｏｌＳｕｃｃｅｓｓＦａＨｅｄＩｇｎｏｒｅｄＰａｓｓＲａｔｅＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ａｐｐｅａｒａｎｃｅ．ＴｅｘｔＡｌｉｇｎｍｅｎｔｓ１３０４６１Ｏ９５．５３１％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｂｅｈａｖｉｏｒ．ＣｅｌＩＡｃｔｉｏｎｓ６９８０８９．６１０６％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｂｅｈａｖｉｏｒ．Ｆｉｌｔｅｒ２４０６１８２０９２．９６８％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｂｅｈａｖｉｏｒ．Ｆｒｅｅｚｅ１４０９４０９９．７１７％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｂｅｈａｖｉｏｒ．ＲｏｗＡｃｔｉｏｎｓ１３９２０Ｏ８７．４２１％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｂｅｈａｖｉｏｒ．Ｓｃｒｏｌｌ９０ＯＯ１００％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｂｅｈａｖｉｏｒ．ＳｈｏｒｔＣｕｔＫｅｙ９４６０９４％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｂｅｈａｖｉｏｒ．Ｓｏｒｔ１１８１０９９．１６０％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｂｅｈａｖｉｏｒ．Ｓｐｌｉｔ９６ＯＯ１００％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＢｕｔｔｏｎＣｅｌｌ９７９４０９９．５９３％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＣｈｅｃｋＢｏｘＣｅｌｌ１１５８１２７９８．９７４％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＣｏｍｂｏＢｏｘＣｅｌｌ１１００４８Ｏ９５．８１８％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＤａｔｅＴｉｍｅＰｉｃｋｅｒＣｅｌｌ１０５３１７０９８．４１１％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＩｍａｇｅＣｅｌｌ４８３３３Ｏ９３．６０５％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＬａｂｅｌＣｅｌｌ７０５２０Ｏ９７．２４ｌ％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＬｉｎｋＬａｂｅｌＣｅｌｌ１０３８３０９９．７１２％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＭａｓｋｅｄＴｅｘｔＣｅｌｌ１１２ｌ１６Ｏ９８．５９３％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＮｕｍｅｒｉｃＵｐＤｏｗｎＣｅｌｌ１０２３２０Ｏ９８．０８２％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＰｒｏｇｒｅｓｓＢａｒＣｅｌｌ１０５１１１Ｏ９８．９６４％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＲａｄｉｏＧｒｏｕｐＣｅｌｌ９７５３０９９．６９３％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＲｉｃｈＴｅｘｔＣｅｌｌ３９８３６Ｏ９１．７０５％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｅｌｌｓ．ＴｅｘｔＣｅｉｌ１００８５４Ｏ９４．９１５％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｏｍｍａｎｄ．ＤａｔａＴｒａｎｓｌａｔｉｏｎ５２２０９６．２９６％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｏｍｍａｎｄ．ＥＦｒＯｒｌ’ｅ斌４３４２０９９．５４１％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｏｍｍａｎｄ．１ｎｓｅｒＲｅｍｏｖｅ５６７２０９９．６４８％ＭｕｌｔｉＲｏｗＳｈｅｅｔ．Ｃｏｍｍａｎｄ．Ｐｒｉｎｔ７９０Ｏ１００％当自动化测试发现缺陷没有通过，仅仅选择有问题的结点在相同的条件下重新测试，ｂｕｇ可以重现，并且可以用手工测试重现。因此，不仅说明ＡｕｔｏＴｅｓｔｅｒ工具的确对发现产品缺陷很有帮助。而且ＡｕｔｏＴｅｓｔｅｒ工具可以代替部分手工测试，解放软件测试工程师的部分工作，同时也减少测试的时间和提高效率。在项目时间紧张的时候，可能开发人员没有太多的时间等待测试人员的测试软件测试自动化研究与应用结果。这个时候，自动化测试可以胜任这个任务，完全可以在周末和晚上执行测试，充分利用了休息时间，也避免了开发和测试之间的等待。在产品实现了测试自动化后，相对于手工测试来说，多次的重复使用，很实用也很方便。而且实践证明，自动化工具重用性越高，即越多次的使用，就越能够提高软件测试的速度和效率，缩短软件开发周期，降低测试成本。综上所述，ＡｕｔｏＴｅｓｔｅｒ工具基本实现了原定的测试自动化的方案，对产品进行了测试自动化，节省了测试时间和资源，并且能够及时地发现缺陷。第六章总结与展望５５第六章总结与展望目前国内从事专门软件测试，特别是软件自动测试的不多，实用阶段的更少。从目前国外软件测试自动化的情况来看，据统计有近８０％的软件自动测试工作没有取得预期的效果。本文针对当前软件测试的现状，对软件测试自动化技术进行了分析，此归纳总结出自动测试的一般技术和实用技术。并且在此研究基础上开发ｇｃＭｕｌｔｉＲｏｗ５．０产品的自动化测试工具ＡｕｔｏＴｅｓｔｅｒ。本文使用ＭｉｃｒｏｓｏｆｔＶｉｓｕａｌＳｔｕｄｉｏ．ＮＥＴ环境的Ｃ撑作为开发工具和生成测试脚本的编程语言，利用Ｎｕｎｉｔ框架，设计和实现自动化测试工具ＡｕｔｏＴｅｓｔｅｒ。该工具可以主动地彻底地搜寻整个待测试程序集。首先找出要测试的所有成员。其次根据已发现的成员和组建好的测试用例，生成一个测试脚本。ＤＬＬ程序集通过后期绑定技术在后来的自动化测试工具中调用。从最后的实例验证结果来看，ＡｕｔｏＴｅｓｔｅｒ工具的确方便了测试，提高了测试的效率，为进行更多的测试赢得了时间。另外，测试的结果也达到了预期的目标。软件测试自动化是一个比较新的研究方向，而且由于本人经验和水平有限，在设计和实现中都还存在不足指出，这都需要在今后的工作中加以改进。同时，因为国内专门生产控件产品的公司并不多，因此这个自动化测试工具还需要进一步的改进，以适用更多的公司；由于功能的复杂性，脚本还没有实现完全自动的编写，这也是下一步工作改进的重点。致谢致谢值此论文完成之际，衷心地向曾给予我帮助和关心的老师、同学和亲人表示感谢。我要特别感谢我的导师王保保教授。这不仅在于他对我的指导和关心，更有他严谨的治学态度和做人原则，这些都深深地影响着我。王老师崇高的敬业精神、乐观的态度、平易近人的待人处世和一丝不苟的工作态度是我毕生学习的榜样。感谢朱晶老师这两年来对我的工作和生活给予的关心和帮助。感谢葡萄城给我提供了大量的实践和锻炼的机会，使我在实际动手能力和社会阅历等方面均有长足的进步，在此祝愿葡萄城的明天更美好。感谢一起合作的各位同学在工作和学习中给予我的非常热情的帮助，愿他们在今后的人生之路上大显身手，早日建功立业。最后感谢我的家人，他们无私的爱护与恒久的支持，是我学业得以顺利完成的坚强后盾。由于作者资历、学识有限，对课题的研究不够深入，恐难以达到众位师长的期望，本文不妥之处，敬请批评指正。参考文献５９参考文献［１】朱鸿，金陵紫．软件测试和质里保障技术．北京：科学出版社，１９９７．【２】张湘辉．软件开发过程与管理．清华大学出版社，２００５．【３】张茂林．软件目动测试的研究与程序实现．北京航空航天大学学报，１９９７．【４】张克东，庄燕滨．软件工程与软件测试自动化教程．电子工业出版社，２００２．【５】ＭａｒｋＦｅｗｓｔｅｒ，ＤｏｒｏｔｈｙＧｒａｈａｍ．舒晓露等译．软件测试自动化技术与实例详解．北京：电子工业出版社，２０００．【６】洪帆，刘群．软件测试的应用研究与分析．华中理工大学学报，２０００年，１１期．【７】ＳｉｍｏｎＲｏｂｉｎｓｏｎ，，ＣｈｒｉｓｔｉａｎＮａｇｅｌ．李敏波译．Ｃ＃高级编程．北京：清华大学出版社，２００５．［８】宋艳芳，苏折明，史永辉．自动化软件测试应用科技．２００１．４【９】ＢｒｉａｎＭａｒｉｋ．ＷｈｅｎｓｈｏｕｌｄＶ０１．２８Ｎｏ．４．ＴｅｓｔＢｅＡｕｔｏｍａｔｅｄ．ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔｍａｎａｇｅｒ．ｃｏｍｃｎ／．【１０】郑人杰．计算机软件测试技术．清华大学出版社，１９９０．【１１】姚砺，东永安．软件测试自动化关键技术的研究．安徽大学学报（自然科学版），２００４．６Ｖ０１．１８Ｎｏ．２－－－１２．【１２】赵晖，王刚．软件自动测试方法浅谈．雷达与对抗．１９９７．【１３］ＥｌｆｒｉｅｄｅＤｕｓｔｉｎ．．ＴｈｅＡｕｔｏｍａｔｅｄＡｄｄｉｓｏｎＴｅｓｔｉｎｇＬｉｆｅＣｙｃｌｅＭｅｔｈｏｄｏｌｏｇｙ（ＡＴＬＭ）．ＷＥｓｌｅｙ．．２００１．Ｔｅｓｔ【１４］ＤａｎｉｅｌＪ．Ｍｏｓｌｅｙ，ＢｒｕｃｅＡ．Ｐｏｓｅ），．．邓波，黄丽娟等译．ＪｕｓｔＥｎｏｕｇｈＳｏｆｔｗａｒｅＡｕｔｏｍａｔｉｏｎ．北京：机械工业出版社，２００３．【１５］Ｒ０ｎＰａｔｔｏｎ．ＳｏｆｔｗａｒｅＴｅｓｔｉｎｇ（２ｎｄＥｄｉｔｉｏｎ）．Ｓａｍｓ，２００６．【１６】朱少民．全程软件测试．北京：电子工业出版社，２００７．【１７】赵斌．软件测试技术经典教程．科学出版社，２００７．【１８】陆路，王柏勇．软件自动化测试技术．清华大学出版社，北京交通大学出版社，２００６．【１９］ＤｉｏｍｉｄｉｓＳｐｉｎｅｌｌｉｓ．ＣｏｄｅＲｅａｄｉｎｇ．２００４．１１２０］麦克卡佛瑞．．ＮＥＴ软件测试自动化之道．北京：电子工业出版社，２００７．１１２１］ＳｉｍｏｎＲｏｂｉｎｓｏｎ，ＣｈｒｉｓｔｉａｎＮａｇｅｌ．李敏波译．Ｃ撑高级编程．北京：清华大学出版社，２００５．【２２］Ｂｅｃｋ，．Ｋｅｎｔ．ＥｘｔｒｅｍｅＰｒｏｇｒａｍｍｉｎｇＥｘｐｌａｉｎｅｄ．Ｂｏｓｔｏｎ，Ｍａｓｓ：Ａｄｄｉｓｏｎ－Ｗｅｓｌｅｙ，２０００．【２３】崔启亮，胡一鸣．国际化软件测试．电子工业出版社，２００６．【２４］ＲｏｂｅｒｔＶ．Ｂｉｎｄｅｒ，．华庆一，王斌君，陈莉译．面向对象系统的测试．人民邮电６０软件测试自动化研究与应用出版社，２００１年，４月．【２５］ＨｕｎｇＱ．Ｎｇｕｙｅｎ．冯学民，唐映，杨海燕等译．ｗｅｂ应用测试．电子工业出版社，２００３．［２６］施凡，李永伦，谭颖华等．Ｃ＃和．ＮＥＴ２．０实战．人民邮电出版社，２００７．【２７］ＡＣｏｍｐｒｅｈｅｎｓｉｖｅＦｒａｍｅｗｏｒｋＦｏｒＴｅｓｔｉｎｇＧｒａｐｈｉｃａｌＵｓｅｒＩｎｔｅｒｆａｃｅ．ｈｔｔｐ：／／ｗｗｗ．ＣＳ．ｕｍｄ．ｅｄｕ／ａｔｉｆ／ｄｉｓｓｅｒｔａｔｉｏｎ．ｐｄ￡［２８］ＡｕｔｏｍａｔｅｄＧＵＩＴｅｓｔｉｎｇＩｓｓｕｅＶＩ．ＲＩ．ＭＩＪａｎｕａｒｙ．１９９９．【２９］ＫａｒｌｉＷａｓｏｎＣｈｒｉｓｔｉａｎＮａｇｅｌ．ｃ＃入门经典．清华大学出版社，２００６．【３０］Ｌｉｂｅｒｔｙ．Ｊ．刘基诚，李愈胜，刘卫卫译．ＰｒｏｇｒａｍｍｉｎｇＣ＃中文版（第四版）．电子工业出版社，２００７．软件测试自动化研究与应用

作者：

学位授予单位：

岳媛

西安电子科技大学

本文链接：http://d.g.wanfangdata.com.cn/Thesis_Y1431659.aspx