毕业设计（论文）-大型邮件系统中黑盒测试的实践改进.doc

毕业设计（论文）报告纸 共 页 第 1 页 装 订 线 大型邮件系统中黑盒测试的大型邮件系统中黑盒测试的 实践改进实践改进 Improvement of black box testing in large mail system 同同济济大学大学软软件学院件学院 2004-5-20 毕业设计（论文）报告纸 共 页 第 2 页 装 订 线 【摘要】伴随着软件工程的发展与成熟，软件测试也越来越受人关注。黑盒测试是软件测试中最 接近用户观点的，也是处于最无序混乱状态的测试。本文主要介绍了黑盒测试特点及相关的理论 与方法，并结合实际项目中存在的问题与得到的教训，提出测试过程中的改进方法。包括测试过 程中测试执行的管理，bug 的管理等。同时结合一种测试工具 SilkTest，介绍了自动化黑盒测试 的特点和实施原理，同时也结合前面提到的项目，介绍它的实际使用，重点讨论了利用自动化工 具进行 web 测试自动化框架的建立。最后讨论了手工测试和自动化测试各自的利弊及相互间的不 可替代性。 【关键词】 软件测试 黑盒测试 自动化测试 【Abstract】With the development of software engineer, people make more and more importance on software testing. Black box testing is the most closest testing method to users opinion, and is also the most discrete testing. This paper introduces the characteristic of black box testing , the theory and method related. And some improvements are put forward based on the problems and lessons in project. which involves the management of testing execution and bug during the testing process. This paper also introduces the characteristic and the principle of black box testing automation through one kind of testing tool-SilkTest., and tries to take it into that project, emphasis on the construction of the framework of web automated testing by automation tool. Last, this paper discusses the advantage , disadvantage, unsubstitutableness between hand-testing and automated testing. 【Keywords】 software testing black box testing automated testing 毕业设计（论文）报告纸 共 页 第 3 页 装 订 线 绪论绪论 .4 1软件测试与项目概述 .5 1.1软件测试介绍 .5 1.2项目概述 .5 1.3测试三要素 .5 2手工测试及存在的问题 .7 2.1测试流程 .7 2.2测试用例 .7 2.2.1测试用例结构 .7 2.2.2测试用例的生成 .8 2.2.3测试用例的执行 .9 2.3BUG 的管理与跟踪 .9 2.3.1bug 的跟踪管理流程.9 2.3.2及时有效地报告 bug.10 2.4测试状态报告 .10 2.5手工测试存在的问题 .11 2.5.1重复测试 .11 2.5.2可重用的测试数据 .12 2.5.3腐朽的测试用例与探索性测试 .12 2.5.4管理在黑盒测试中的重要性 .13 3自动化测试 .14 3.1测试自动化的绩效 .14 3.2商业测试工具实现方式 .14 3.3关于 SILKTEST.15 3.3.1SilkTest 介绍 .15 3.3.2SilkTest 的主要特点.15 3.4自动化测试在项目中的运用 .16 3.4.1建立 SilkTest 项目 .16 3.4.2捕捉 GUI 信息 .16 3.4.3测试脚本的结构 .18 3.4.4自动恢复系统 .19 3.4.5测试脚本的编写与执行 .19 3.4.6测试结果 .22 毕业设计（论文）报告纸 共 页 第 4 页 装 订 线 4自动化测试与手工测试的比较 .23 4.1测试自动化要考虑的因素 .23 4.2手工测试的不可替代性 .23 5结束语 .24 毕业设计（论文）报告纸 共 页 第 5 页 装 订 线 绪论绪论 随着软件进入人类生产与生活的方方面面，软件的缺陷所带来的影响也越来越 引人关注。与此同时，软件的功能越来越多，程序的结构越来越复杂，程序员们也 越来越难以编写不会出错的程序。 于是，软件质量得到了人们的重视。迄今为止，软件质量仍然主要靠软件测试 来验证和确认，而且由于测试工作特别耗费资源，在软件开发的总成本中，用在测 试上的开销要占 30%到 50%。在极端的情况下，例如在关系到人的生命安全的软件 中（如飞机控制或核反应监控等软件） ，测试费用可能相当软件生存周期所有其它 阶段费用总和的三到五倍。此外，据美国工业界的统计，对商品化的程序来说，测 试在时间和费用两方面的花费都要占整个软件开发周期总开销的 50%左右。而由测 试员完成的系统测试又是整个软件测试过程中的最后一道关卡，足见其重要性。 要保证测试项目的成功，最重要的一点就是要遵循规范。但是在很多企业内部， 由于缺乏对软件测试的重视，也没有一套流程和规约。所以很多情况下，测试的过 程就像是摸着石头过河。 本文结合一个邮件系统的系统测试项目来介绍黑盒测试的相关技术以及手工测 试后的自动化过程，并且分析解决测试过程中产生的各种各样的问题。 毕业设计（论文）报告纸 共 页 第 6 页 装 订 线 1 软件测试与项目概述软件测试与项目概述 1.1 软件测试软件测试概述概述 广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。关于 软件测试类型的描述，根据是否关心程序的实现过程可分为：黑盒测试，白盒测试， 灰盒测试；根据测试的阶段可分为：单元测试，组合测试，集成测试，系统测试和 验收测试。 本文所涉及的测试是针对某邮件系统的系统测试。所谓系统测试，即是以产品 需求为依据，将所有模块，环境，数据等组合起来进行测试，需要检查整个系统的 功能，性能，安全性，兼容性，容错性等内容。显然，系统测试中采用的是黑盒测 试技术，即不关心程序的实现过程，不检查程序的源代码。整个测试工作简单的说 就是进行输入，接受输出并检查结果。 1.2 项目概述项目概述 本项目是针对一个邮件系统的系统测试项目。主要任务就是根据测试用例文档 (文档以 excel 文件形式存在)，测试该产品的各项功能（包括发送邮件，管理联系 人等） 。该产品有两种语言(英语和日语)的版本，提供了两种连接方式(server connection 和 network connection)，分成企业和个人两个版本，并且用到了 4 种邮件服务器(Domino5, Domino6, Exchange 5.5 和 Exchange 2000)。 由于是外包的测试项目，整个测试过程分为和客户确定测试计划，产生测试用 例，安排测试人员，执行测试用例，向客户报告测试结果，这几个阶段。 1.3 测试三要素测试三要素 在进行测试过程中，测试组经常会面对很短的测试时间和很繁重的测试工作量 的压力，这个时候，需要对测试工作的内在规律有一个清醒地认识，做到“有所为， 有所不为” 。 测试工作中存在三个要素，分别是质量，时间和成本。对这三个要素的要求程 度的相互关系可以用下面的三要素的要求程度模型图来表示 毕业设计（论文）报告纸 共 页 第 7 页 装 订 线 质量要求 时间要求成本要求 图 1 三要素的要求程度模型图 在测试中，永远无法实现时间，成本和质量的三赢，为其中任何两个目标所作 的努力都必须以付出第三个目标的损失作为代价。如上图所示：增加了对时间和成 本的要求，必须以降低对质量的要求作为代价。 在本项目中，同样面临着这样的问题。实际执行过程中，采用保证优先级高的 测试用例以高质量完成的方法来实现质量，成本，时间的最大化。 毕业设计（论文）报告纸 共 页 第 8 页 装 订 线 2 基于邮件系统的手工系统测试及存在的问题基于邮件系统的手工系统测试及存在的问题 2.1 系统测试流程系统测试流程 本项目中的系统测试计划由客户制定，所以本文不涉及测试计划的有关工作。 根据测试计划描述的测试流程，测试工作包括：根据客户提供的产品说明和需 求规约编写测试用例-安排测试人员执行测试用例-如果发现 bug 提交 bug 并跟踪 -按期提交测试状态报告。 2.2 系统测试用例系统测试用例 2.2.1测试用例结构测试用例结构 ANSI/IEEE829 标准称测试用例说明为“编写用于输入的实际数值和预期结果” 。 测试用例还须明确指出在执行具体测试用例时任何关于被测程序方面的限制。 该标准还指出其他应该包括在内的信息有标识符，测试项，输入说明，输出说 明，环境要求，特殊要求，测试用例之间的依赖性等。 由于本项目中对于系统的操作是简单易懂的，环境却多而复杂，所以实际的测 试用例存放于电子表格中（EXCEL 文件） ，列分为用例 ID，测试输入步骤说明，预 期测试结果，用例优先级，注释，每种测试环境下对应的结果这样几项。 为了表示出用例之间的依赖性以及方便测试员执行测试用例，将每一个功能模 块的测试用例组织在一起，并按每项功能的操作步骤排列测试用例。 毕业设计（论文）报告纸 共 页 第 9 页 装 订 线 图 2 测试用例示例 2.2.2测试用例的生成测试用例的生成 测试用例的目的在于使测试执行人员了解测试的流程，因为人脑很惧怕重复性 劳动并且很健忘，所以需要将一些测试的流程写下来，按照正常的流程途径和非正 常的流程途径来组织测试。 本项目中以用户角度来看待和执行程序，然后根据产品说明和需求文档编写测 试用例。具体采用一点多例的方法，即对于一个功能点从多个方面进行测试。 如发送邮件就可以从发送邮件时需要填写的各部分内容（邮件标题，收信人地 址，邮件内容等）分别进行测试，每部分内容又可以通过输入各种合法或非法的值 来进行测试。 这样看来似乎编写测试用例是越详细越好，可以降低随意性，使测试能够很好 地重复，但其实会花费相当多地时间和精力，无形中也增加了测试用例的维护代价 和升级难度。此外由于用例细节繁多，使执行测试时间变长。 因此可以看出，测试用例的粒度与覆盖度也是一对矛盾。所以为了降低测试用 例的数量，但又不对测试覆盖度与质量产生大的影响，常用的方法就是采用等价划 分和边界值分析。 1. 等价划分根据系统的输入集合进行分析，从而选择测试用例。 在本项目中，作为邮件系统，界面并不复杂，比较重视的地方是输入内容的准 确性。例如对于邮件地址的测试用例，等价区间就可以有合法字符，非法字符，合 法长度，过长长度等几个区间。对于合法字符区间又可以根据是否包含英文字符， 毕业设计（论文）报告纸 共 页 第 10 页 装 订 线 数字，特殊字符来划分子区间。 当然，不可避免的是，这种方法理论上是会增加漏掉软件缺陷的风险的，而且 等价划分也因人而异并不客观。但实际上只要足以覆盖测试对象，这种风险是微乎 其微的。 2. 边界值分析是对等价划分技术的一种补充，它在等价划分的基础上针对每个 等价类的边界值作为参考指标来设计测试用例，在实际运用中还要对输出值的边界 进行一些考虑。 在实际设计黑盒测试用例的过程中，应当首先进行等价类的划分，之后根据边 界值分析设计测试用例。例如对于邮件标题这个测试点可以从邮件标题长度的最大 值，最小值，临界最大值，临界最小值（如空标题）出发。这是一种比等价类划分 更能有效降低测试用例数量的方法。同时如果要选择在等价划分中包含哪些数据， 也可以根据边界作为基准来选择。 基于测试的实际情况看，如果利用多缺陷和单缺陷的规则，似乎可以把多种情 况合并起来测试。如对于英文，日文，数字，特殊字符，高位 ASCII 码的显示测试， 可以将其组合起来，写成一个测试用例。但是这样给测试人员却带来了很大的不确 定性，对于 bug 的定位也带来了困难。最好的方法也是在本项目中采用的方法是将 其分开单列几个测试用例，最后在组合在一起作为一个测试用例。这样测试用例看 上去整齐，也比较易于管理。至于实际执行测试用例时，可以让测试人员自己来判 断。测试新手应该严格按照测试用例来执行，而有经验的测试人员在有把握的情况 下就可以只执行最后一个组合的测试用例就可以判断出所有的测试结果，节省时间 与资源。 2.2.3测试用例的执行测试用例的执行 有了测试用例之后，余下的就是要执行这些测试用例了。 测试执行是测试过程中技术要求最低，但却是最难控制的一部分，也是实际操 作过程中最容易碰到问题的一部分。 执行的流程图如下： 毕业设计（论文）报告纸 共 页 第 11 页 装 订 线 图 3 测试流程图 上面的流程图只是一般的测试执行的流程。在本项目中，还采用制定测试判定 规则的方法控制测试结果的规范和正确性；使用问题报告机制来统一解决测试中遇 到的环境问题与用例存在的问题；使用 bug 的报告规则来控制 bug 流程的规范。 2.3 bug 的管理与跟踪的管理与跟踪 测试用例执行完后，如果发现 bug 就要提交。本项目采用客户提供的 bugzilla 作为 bug 跟踪管理平台。 对 bug 的跟踪管理是测试工作的一个重要组成部分，特别是对于外包的测试项 目，bug 的跟踪管理实际上就是与客户的沟通，尤其需要引起注意。 2.3.1bugbug 的跟踪管理流程的跟踪管理流程 测试的目的就是为了及早发现软件系统中的缺陷，因此，对 bug 进行跟踪管理 以确保每个被发现的 bug 都能及时得到处理，同时，这也是一套复杂的流程，涉及 到测试员，项目数据库，程序员三方的交互。 bug 跟踪管理的起始动作是测试员选择一个测试用例开始测试，当测试员发现 测试结果和预期结果不符合的时候，就发现了一个 bug；并执行流程第二步-填写 测试实际结果，当测试员向 bug 跟踪管理系统(本项目中是 bugzilla)提交 bug 时， 系统将该 bug 保存至“项目数据库”中，系统会发一封邮件给该 bug 的最终负责者； bug 负责者收到这样的 bug 报告后，可以去查询该 bug 的详细信息，当修复 bug 的 动作完成后，就将该 bug 的状态转换成“fixed” ，系统会再发一份邮件给测试员； 测试员对 bug 进行确认测试，如果该 bug 正确被修复则关闭它，如果该 bug 依然存 在问题，则整个动作回复到 bug 跟踪管理的起始处。 提交 bug 是为了改正软件的缺陷，所以 bug 报告中要提供详细的操作步骤以及 完整的环境信息，否则程序员无法重现这个 bug，又会向测试人员询问，这样只会 延误时间，可以在提交 bug 前，重现和优化错误步骤。同时有经验的测试人员还可 以进行推测，帮助开发人员迅速定位 bug。总之要提供尽可能清晰详尽的信息，必 要时可以附上清晰的截图。 2.3.2及时有效地报告及时有效地报告 bugbug 提交 bug 首先要及时，根据笔者经验，如果等到第二天提交，就有可能漏掉细 节，拖延越久，细节遗漏得就越多。而且一旦拖延时间后，在提交 bug 之前就必须 重新测试一遍这个功能点，以免这个潜在的缺陷已经修复而提交了无用的 bug。这 样既浪费了时间，也影响了整个项目的流程。 提交 bug 之前一定要首先查询该 bug 是否已经存在，报告重复的 bug，既浪费 资源，也会让程序员生厌。对于本项目而言，所测的产品已经是 6.3 版了，在数据 库中已经有不少 bug 信息，提交之前可以参考里边的信息。如果觉得自己掌握的信 息更丰富，也可以在旧的 bug 里边增加自己的描述，因为这样可以使实现人员更简 毕业设计（论文）报告纸 共 页 第 12 页 装 订 线 单，更迅速地修复 bug。 2.4测试状态报告测试状态报告 本项目中采用自己用 VBA（Visual Basic for Application）开发的工具，来 自动统计测试执行的结果，继而生成测试状态报告。测试状态报告见下图 图 4 测试状态报告示例 由状态报告可以看出完成的测试用例比率，以及通过与失败的测试用例比率等 详细的完成情况。 2.5 手工测试存在的问题手工测试存在的问题 以上的整个测试流程的实现是基于手工的，存在一些不足之处，分析如下。 2.5.1重复测试重复测试 由于环境的复杂性，造成了配置方面花费了很多的工作量与成本，也使得同样 一个测试用例，不考虑发现 bug 后的重新验证测试，假设所有用例全部通过，也要 测试 2*2*2*4=32 遍。作为手工测试，对于测试人员来讲，重复测试很容易增加测 试人员的厌烦度，导致测试质量下降。 重复测试还有一个弊病就是导致测试员太专，如果这位测试员离开，会给测试 小组带来很大的知识漏洞，给接下去的测试工作带来很大的困难。 在项目执行过程中发现，轮换测试任务是解决上述弊端的一个很好的方法。两 个测试员会以不同的方式分析同样的功能。由于黑盒测试并没有很系统的方法论， 所以测试员们会使用不同的查错方法，并发现不同的缺陷。当一个测试员对程序的 一个重要部件的质量有信心又对这个点的测试开始产生厌烦情绪时，可把该测试员 毕业设计（论文）报告纸 共 页 第 13 页 装 订 线 调离当前的任务。而且所指派的新测试员还有可能发现前一个测试员从来没有发现 过的缺陷。 但是担心专业化带了的风险同时，也要认同专业化的重要性。从增加测试效率 角度来考虑，会让测试人员始终对项目的某一组功能进行测试。而且程序中的有些 功能组特别大，可能需要花费很大的时间去阅读产品文档才能有所了解，继而进行 有效的测试。这种情况下工作轮换过于频繁会使测试员的工作效率降低很多。 所以在遇到被测功能复杂或有关知识超出测试员能力之外的情况下，可以通过 让某方面的专家和其他测试员结对完成工作。例如请专门的翻译人员进行页面上的 语法检查，请专门的 IT 人员协助进行有关使用代理服务器方面的测试。 2.5.2可重用的测试数据可重用的测试数据 在测试执行中，第一步就是进行输入。从可重用性方面考虑，同时也为了提高 回归测试的效率，测试数据的准备，管理与维护就显得尤为重要。 测试数据可以包括执行测试用例需要用到的数字，文字，图片，文件等等。值 得注意的是测试数据也未必都是正确的数据，也有可能是非法数据，供容错性检查 时使用。所以测试数据不是对被测软件有用的数据，而是对测试有用的数据。 例如在本项目中，测试用例用到了以各种各样的文字组合作为文件名的文件和 各种类型，各种大小的文件。预先准备好这些文件并加以保存共享可以大大加快测 试速度。 另外有些测试用例还涉及到与其他软件的交互(本项目中有 Microsoft Exchange, Lotus Domino 等等)，其中的测试数据可以通过编写小的程序来生成。 无论是用何种语言，只要动用一切可用的资源，发挥最大的想象力就可以使整个测 试团队受益。当然编写程序也需要工作量，如果是测试人员编写的话，要严格控制 好工作量和机会成本，毕竟这些都是手段，测试的最终目的还是帮助程序员发现和 消除 bug。 2.5.3腐朽的测试用例与探索性测试腐朽的测试用例与探索性测试 为了能够很好地测试软件，测试员就必须了解它，研究它。这是一种探索过程。 探索并不是浪费时间，而是指有目的的漫游，但没有预先确定的路线，包括不 断的学习和实践。在黑盒测试中，探索性测试也是一种缺乏项目文档的时候进行黑 盒测试的方法。而且即使已经有了软件产品的完美描述，仍然要探索问题。在整个 测试项目过程中，探索性思考在寻求最大化测试价值时起作用。 在测试项目中有一个比较普遍的问题就是测试用例的落后与不正确性。有的时 候是产品功能说明产生偏差，有的时候是编写测试用例时出现问题。而如何在这些 可以说是腐朽的测试用例下尽可能地进行完善地测试呢？探索性测试就在这里有了 用武之地。对于产品功能说明所造成的测试用例问题可以同客户沟通解决，也可以 根据同类产品进行探索性测试；对于在测试用例的编写时出现的问题，因为测试用 例中的输入已经失效，需要更加详细地阅读产品的说明，对测试用例给出合适的判 毕业设计（论文）报告纸 共 页 第 14 页 装 订 线 定和注释，以便以后更新这部份测试用例。 探索性测试要求发挥测试人员的主观能动性。有的时候需要像无经验的用户一 样去使用软件，抛开关于软件应该如何工作的想法；有的时候又需要拿出专业素质， 如在已经找到软件缺陷的地方集中轰炸(有一个规律：找到的软件缺陷越多，就说 明那里的软件缺陷越多)；有的时候又要凭借直觉和经验来测试， “经验是人们对错 误行为的称谓” ，而测试员又是成天与错误为伴，这方面是很重要的。 并非每个测试员都是有经验的，对软件知识很丰富的，但是可以凭借直觉，可 以凭借预感，记录下执行过程中的灵感，不用在意测试用例有没有包含自己的思路， 但是要注意不要轻易修改本次执行任务。 2.5.4管理在黑盒测试管理在黑盒测试中的重要性中的重要性 由于黑盒测试特别是测试执行本身并没有多少技术含量，管理得好与坏就成了 项目成功的一大关键因素。 首先，就是制定规则。明确什么情况下测试通过，什么情况下测试失败，什么 时候测试延后；没有明确的判定规则，测试员碰到无法理解测试用例，认为测试用 例有误，以及由于 bug 致使无法执行该测试用例等情况，将不知所措或胡乱填写结 果，这都会导致项目到后期无法控制。误判也许隐藏了 bug，也许会导致重复提交 bug。这都是些危险的结果。然而，对于大多数团队，特别是没有经验的团队，在 测试执行前很少会考虑制定规则，即使考虑到，也很难做到完整。所以随着项目的 进行，也要随时更新规则并做好记录。总之，xp 开发中有句名言“测试先行” ，而 在黑盒测试执行过程中，应该做到“规则先行” ，否则最后的测试用例就成了狼藉 一片。 其次，是管理测试用例和执行过程。绝大部分的黑盒测试项目中都使用电子表 格作为管理测试执行过程的工具。可以通过使用 vba 语言进行 office 开发来制作 一些控件，用来跟踪测试用例执行情况，而不是仅仅充当一个测试用例的容器。 测试执行过程好比是装配线，需要有一整套流程来控制。bug 的报告，意外的 解决，就连探索性这种看似随意的步骤也都要有流程控制。为了不影响进度，意外 的解决可以专门派有经验的测试员去处理，一般的测试员在一定时间内无法解决问 题，就应该向上级或他人寻求解决方案；而探索性测试需要严格的时间控制，在一 定的时间内无法取得成果就应该向客户报告。 最后，是定期状态报告。工作状态的报告一方面是控制项目进度，另一方面也 是与客户的沟通。从某种角度看，测试是一种服务，所以真正的力量来自沟通。整 个测试过程中，QA(Quality Assure),测试团队领导者，测试员，程序员与项目经 理之间每时每刻都存在着交流。 在工作状态的报告和测试员的 bug 跟踪中都包含着和客户得沟通。相比而言， 状态报告相比测试员的 bug 跟踪而言，更易于管理，也是传递自己信息的重要工具。 如果没有使用专门的过程管理工具，也可以开发一些轻量级的统计工具。最重要的 是要注意格式的统一，报告的频度，内容的简练以及数字的精确。 毕业设计（论文）报告纸 共 页 第 15 页 装 订 线 3 基于邮件系统的基于邮件系统的自动化测试自动化测试 3.1 测试自动化的绩效测试自动化的绩效 以上所讨论的黑盒测试都是建立在手工测试的基础上的，对于步骤复杂的测试 用例，在回归测试阶段，一遍一遍地执行是非常麻烦枯燥的一项工作，况且人对于 同样的操作是有相当的厌烦度的，很容易影响测试进程与结果。所以一种做法是让 不同的测试人员交叉完成测试用例来保持新鲜感，但是当所有的人员都执行过所有 的测试用例后呢？所以手工测试一遍之后，就可以考虑自动化，并且在回归测试阶 段正是自动化大显身手的时候。 当然，建立自动化测试比建立手工测试花费的前期工作要多得多。自动化测试 在开始阶段没有捷径，必须执行所有手工测试要执行的相同步骤。 自动化测试的基本目的是一旦需求确认后，验证后继构建版本或被测试程序的 修改版本是否正确实现了需求。而且，因为自动化测试减少了执行回归测试所需的 时间，所以这是它最被认可的好处。 对于本项目，主要采用 GUI（Graphic User Interface）测试，需要书写脚本 代码来驱动，如此消耗的工作量是手工测试一次的几倍。 因此在本项目的自动化测试阶段使用商业自动化工具的 GUI 播放/重放工具跟 踪人与产品的交互操作，由自动化工具自动录制界面和产生界面。但是，当自动化 测试过程出现了错误，测试人员就要开始捕捉前置的测试条件，以验证和分析这些 错误可能出现的具体位置，这些都意味着自动化执行方式将付出更多的资源开销， 累积在一起就会变成很大的资源消耗。 又因为变化会导致一些测试的失效，有的时候即使简单的界面变化也会导致需 要重新捕捉界面。所以，对于自动化测试的效果，稳定的产品会带来很大的收益。 3.2 商业测试工具实现方式商业测试工具实现方式 大部分商业黑盒测试工具都具备了脚本自动录制/回放的功能，这些功能保证 了以相对低的资源耗费，全自动执行软件测试计划。工具的功能强大但并非完美， 根据测试工具的脚本自动录制/回放的不同实现特性，可以区分对象识别模式和动 作识别模式两类。 对象识别模式： 部分工具测试运行期间使用的对象识别技术，类似于人类的个体识别行为，测 试工具第一次运行时，它首先对被测试对象环境进行登记，然后准确记录环境中被 识别的对象特征。在后续的测试期间，测试工具就会自动寻找已经登记的存在对象， 并且把这个对象的某些特征和当初录制它的特征进行完全匹配。只要被测试对象和 其环境不发生变化，那么这种识别机制永远是有效的，这实际上就是测试工具的精 确对象识别机制。 毕业设计（论文）报告纸 共 页 第 16 页 装 订 线 但是精确并不在任何场合都是有效的，比如每一个对象创建时，都会产生一个 唯一的标识符，一旦唯一标识符发生了变化，就会导致测试失败。而人脑与电脑一 个很大的区别也是优势就在于人脑能够在模糊地情况下作出准确判断。因此，测试 工具也使用了一些模糊对象识别机制。针对这种情况，测试工具使用了运行时间范 围匹配，对象属性模糊匹配等机制来回避这种失败。 动作识别模式： 动作识别模式回避了对象识别模式的部分局限性，即对所有的操作动作进行记 录。测试工具的自动脚本对每个对象操作动作的位置作了记录。比较适合于测试作 图软件等。 两种模式的缺陷： 对象识别模式最大的缺陷就是对象不能正确识别，从而导致整个测试环境的失 败，动作识别模式最大的缺陷就是动作不精确录制导致测试环境失败，并且在录制 过程中产生大量的废脚本，影响对测试脚本的维护。如果对象识别模式和动作识别 模式能够结合寄来，就会加强测试工具的灵活性和适应能力，但是这两种机制在当 前仍然无法做到高层次的整合，也就是说总有一种模式作为主体在测试工具中加以 体现。这些警告了测试人员，大部分黑盒测试工具只能在一种趋向于平静和完美的 环境中，以半自动的方式辅助测试工作，而并不能完全替代传统的手工测试作业。 3.3 关于关于 SilkTestSilkTest 3.3.1SilkTestSilkTest 介绍介绍 本项目的自动化测试使用的工具是 SilkTest，相比于市场占有率较高的 WinRunner，它在国内还处于推广的起步阶段。首先来介绍一下这个工具 SilkTest 属于 Segue 公司的 silk 产品系列。 SilkTest 是业界领先的、用于对企业级应用进行功能测试的产品，可用于测 试 Web、Java 或是传统的 C/S 结构。SilkTest 提供了许多功能，使用户能够高效 率地进行软件自动化测试。这些功能包括：测试的计划和管理；直接的数据库访问 及校验；灵活、强大的 4Test 脚本语言，内置的恢复系统(Recovery System)；以 及具有使用同一套脚本进行跨平台、跨浏览器进行测试的能力。 3.3.2SilkTestSilkTest 的主要特点的主要特点 1. 内置的自动恢复系统(Auto Recovery System) 这是 SilkTest 独有的一个特点。它能够检测到运行时的错误，执行必要的清 理工作。这样就能够进行全天候测试(24 x 7 x 365)，以更好地利用资源。例如， 有些测试用例执行起来很花时间，可以在上班时间完成测试脚本的开发，而等到下 班时间或周末执行测试脚本。 2. 支持数据驱动的测试 将测试逻辑分离于测试数据。这样就能够提供用大量数据测试商务逻辑，减少 由于被测程序更新而引起的测试脚本维护工作，提供大量的测试条件，增加测试覆 毕业设计（论文）报告纸 共 页 第 17 页 装 订 线 盖率。 3. 抽象 GUI 元素成为测试脚本中的对象 SilkTest 提供用户界面元素的表象和位置与它在测试代码中的定义的完整分离。 这样可以增强测试代码的可维护性和可重用性。 4可扩展的，高便携性，易于维护的脚本语言(4Test Language) SilkTest 的 4Test 是面向对象的第四代语言，特别适用于复杂测试。 SilkTest 中的所有测试案例，无论是录制生成或是脚本生成，均使用 4Test 语言 创建。4Test 语言提供了大量的命令、数据类型和函数。也可以在测试用例中包含 例外处理，从而保证脚本的强壮性。 5用于完全模拟最终用户行为的独立代理技术(Agent) SilkTest 使用代理来模拟真实用户所产生的一系列事件与动作。代理是一个独 立的进程，它产生各种各样的输入来让被测程序来处理。 6可使硬件资源有效使用的分布式测试 SilkTest 的分布式测试结构，可以同时跨越 Windows 和 Unix 前端、浏览器以 及基于 Java 的网络系统环境运行同一个测试。SilkTest 是唯一的可以检验测试工 作流、完成并发测试并保证跨平台测试准确性的工具。不过这项技术在本项目中并 没有用到。 3.4 自动化测试在项目中的运用自动化测试在项目中的运用 本项目自动化测试阶段使用的测试用例基本上还是之前手工测试时使用的用例 文件。主要是对于 MAIL 这一部分进行自动化测试。 自动化测试首先要建立一个测试框架，框架包括一些文件，可以作为一个测试 项目的起点。 3.4.1建立建立 SilkTestSilkTest 项目项目 SilkTest projects 存储着关于这个项目的相关信息，例如对于 plan,script 等文件的引用,以及一些项目级的设置信息。这样保证用户只需要设置一次，在项 目之间切换只需要打开某个 project，运行属于它的测试脚本就行了。 SilkTest 将项目相关信息存放在两个文件中： Projectname.vtp 存放了项目使用到的文件名和位置，使用的是绝对路径。 Projectname.ini 是项目的初始化文件，存放了项目的设置信息，例如，如果 是 web 测试项目，里面会存放所使用的浏览器的信息。 本文中讨论的测试的项目是一个 web 测试项目，所以在正式编写测试脚本前要 先设置好 runtime 和 extension 信息，不需要在文件中手工键入，只需要在 option 菜单里的 runtime 和 extension 中选择测试时用到的浏览器(internet explorer 5.x 或者 internet explorer 6 或者 netscape 7 等等)即可。 毕业设计（论文）报告纸 共 页 第 18 页 装 订 线 3.4.2捕捉捕捉 GUIGUI 信息信息 在开始记录测试脚本之前，首先要为被测程序记录 Test Frame。 Test Frame 是支持脚本文件的骨架。它是一个 inc 文件，包含了关于主窗口和 它的所有菜单的声明。然而，捕捉这些信息没有这么简单。通常情况下，为了脚本 的可维护性与可重用性，都需要手动修改工具所捕获的窗口信息。以下是自动捕获 的某一个被测页面的信息。 - window BrowserChild Acme2kInbox tag acme2k Inbox parent Browser - HtmlTable WelcomeDaniel2 + multitag Welcome, Daniel #1 - HtmlColumn WebAccessAcme2k - multitag Web Access ? acme2k ? acme55 ? acme50 #1 + HtmlText WebAccess1 + multitag Web Access #1 和 c+，java 等面向对象的语言类似，对于页面上的每一种控件，SilkTest 也 定义了一个类的概念。每一个类都表明了被声明的 GUI 对象的类型，但是要注意的 是这是 SilkTest 内建的 4Test 语言的类，不是界面内部使用的类。比如 4Test 将 所有无法编辑和响应动作的字符串都定义为 StaticText，而不是 label,text 等。 SilkTest 中类和面向对象中的类的概念相同，每个类也有自己的属性和行为。 例如，如果记录了一个 ok 按钮，在测试用例中此按钮就可以用 click 这样的方法， 因为按钮是一个 pushbutton 类，click 方法已经定义好了，这样手工编写测试用例 也能获得和面向对象语言中一样的好处。 1 1 标识符标识符 当记录测试脚本 时，SilkTest 使用 Window Declarations 为每个 GUI 对象产 生一个完整标识符，系统产生的完整标识符由该对象的标识符和其父类的标识符组 成。用这种方式记录下来的 4Test 指令，在执行测试用例时才能正确地对对象进行 操作。 下表表示完整的标识符名是如何产生的： 表 1 GUI 对象和标识符 GUI 对象完整标识符例子 主窗口主窗口的标识符 TextEdit.SetActive () 对话框对话框的标识符 Find.SetActive () 对话框里的控件对话框的标识符 和控件的标识符 Find.Cancel.Click () 菜单项主窗口，菜单和 TextEditor.File.Open.Pick 毕业设计（论文）报告纸 共 页 第 19 页 装 订 线 菜单项的标识符 () 由于主窗口和对话框的完整标识符的父类是关键字 window，所以不需要包括父 类的标识符。 标识符本质上就是 GUI 对象的逻辑名。默认地，SilkTest 从对象的标签或标题， 除去里边的空格和特殊字符产生标识符。例如，Save As 标签会变成标识符 SaveAs。 假如对象没有标签或标题，SilkTest 通过将对象的类名和该对象的序号组合 起来作为标识符。 序号是同一类中各个对象在界面上的排列次序(自左向右，自上向下)。 例如，一个文本框没有标题，如果它是界面上第一个文本框的话，默认的标识 符就是 TextField1。 标识符是让脚本开发人员编写脚本时使用的，所以完全可以由开发人员自己命 名，如果默认的标识符太长就可以改掉它。不过通常一个页面捕捉到的 GUI 对象非 常多，一个个修改也是不现实的，只需要修改几个编写脚本时候常用的就可以了 2 2 标签标签 标签是 GUI 对象的实际名称，和作为逻辑名称的标识符不同。SilkTest 在记录 和执行测试用例时，使用标签来标识程序的各个对象。而在测试脚本中， 用标识 符而不是用标签来引用对象。 简而言之，标签就是 SilkTe