软件工程毕业设计（论文）-基于Web的测试管理--谈TestDirector在某金融系统中的应用.doc

第 1 页 共 29 页 装 订 线 基于 Web 的测试管理 谈 TestDirector 在某金融系统中的应用 软件工程 指导教师 【摘要】软件质量是软件的生命，软件测试是软件质量保证的重要手段。本文结合风险系统介绍 软件测试在软件质量保证过程中的重要性，介绍软件测试的基本概念，分析了风险系统的测试生 命周期。重点结合风险系统分析基于 Web 测试管理工具 TestDirector 在测试管理过程中需求管理 、测试计划、测试执行以及缺陷跟踪的运用， 给出风险系统测试管理过程中的规范流程，同时简 要介绍自动化测试工具在测试开发过程中的核心作用。 【关键词】软件质量保证 软件测试 测试管理 测试计划 测试工具 自动化 缺陷 【abstract】Software quality is the life of a software, software test is a important method of software quality assurance. In this paper, associated with risk system, the importance of software testing in software quality assurance process is introduced. Then the basic concept of software test is introduced and the testing life cycle of risk system is analyzed.Based on the risk system, the usage of web-based test tool Test Director in requirements management, test plan, test execution and defects tracing of test manage process is analyzed, the standard test process in risk system is introduced. Meanwhile, the core role of automation test tool in development and test process is introduced. 【keywords】Software quality assurance(SQA) Software Testing Test Management Test Plan Test Tool Automatic Defect 第 2 页 共 29 页 装 订 线 目录目录 1 1 引言引言 .4 4 1.1 测试基本概念.4 1.1.1 软件测试定义.4 1.1.2 软件测试目的.5 1.1.3 测试与质量的关系.5 1.2 风险系统中测试的生命周期.5 1.3 小结.9 2 2 系统简介系统简介 .9 9 2.1 项目背景.10 2.2 功能强大的 TESTDIRECTOR.10 2.2.1 需求管理.11 2.2.2 测试计划.11 2.2.3 测试执行.12 2.2.4 缺陷管理（BUG 跟踪） .12 2.3 测试开发的核心WINRUNNER.12 2.4 小结.15 3 3 测试管理测试管理 .1616 3.1 需求管理.16 3.2 测试计划.18 3.3 测试执行.21 3.3.1 测试开发.21 3.3.2 测试执行.22 3.3.3 测试评估.26 3.4 缺陷跟踪.27 3.4.1 BUG 基本知识 .27 3.4.2 风险系统 BUG 管理.28 3.5 小结.30 4 4 结束语结束语 .3030 致谢致谢 .3131 第 3 页 共 29 页 装 订 线 主要参考文献主要参考文献 .3232 第 4 页 共 29 页 装 订 线 1 引言 在60年代计算机发展初期，程序设计是少数聪明人干的事。他们的智力与技能 超群，编写的程序既能控制弱智的计算机，又能让别人看不懂、不会用。那个时期 编程就跟捏泥巴一样随心所欲，于是他们很过分地把程序的集合称为软件，以便自 己开心或伤心时再把程序捏个面目全非。人们就在这种美滋滋的感觉下热情地编程， 结果产生了一堆问题：程序质量低下，错误频出，进度延误，费用剧增。这些 问题导致了“软件危机”。 在1968年，一群程序员、计算机科学家与工业界人士聚集一起共商对策。通过 借鉴传统工业的成功做法，他们主张通过工程化的方法开发软件来解决软件危机， 并冠以“软件工程”这一术语。三十年余年来，尽管软件的一些毛病如人类的感冒 一样无法根治，但软件的发展速度超过了任何传统工业，期间并未出现真正的软件 危机。这的确是前人的先见之明。由此出现了软件工程这门学科。 如今，软件以无以伦比的速度侵蚀着整个工业界，随时随处都闪现着软件的身 影。网络时代的到来，给熊熊燃烧的软件产业又浇了一壶油，各式各样的语言、构 架、技术、技巧铺天盖地，终于满足了人们的好奇心与欲望，使大家都能做一把 “少数聪明人干的事”。与此同时，软件工程也开始在历史舞台扮演重要角色，它 所提倡的降低成本和提高质量逐渐掩盖技术的光芒，成为业界关注的新焦点。 随着软件规模的膨胀，软件也越来越复杂，软件的质量问题也越来越受到重视。 软件测试是软件开发的重要、必要部分，是通过找出缺陷和问题评估产品质量并间 接改进产品质量的手段。因而，软件测试开始了蓬勃的发展。从软件生产发达国家 来看，20 世纪 60 年代，软件测试主要以代码调试为主，70 年代主要以演示软件系 统的正确性为主，80 年代到 90 年代中期，主要以检查程序错误为主，90 年代中期 以后，软件测试则开始更注重软件质量特性的整体评估。 狭义上讲，软件测试是对软件产品质量的检验和评价。它一方面检查软件产品 质量中存在的质量问题，另一方面对产品质量进行客观的评价。测试可以发现尽可 能多的缺陷，从而期望消灭缺陷来提高软件质量。 1.1 测试基本概念 1.1.1 软件测试定义 IEEE（Institute of Electrical and Electronics Engineers）把软件测试 定义为:从通常是无限大的执行域中恰当地选取一组有限测试用例，对照程序已经 定义的预期行为，动态地检验程序的行为。 第 5 页 共 29 页 装 订 线 1.1.2 软件测试目的 软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找 出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。 如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该 直接针对在实际应用中会经常用到的商业假设。 The Art of Software Testing的作者 Grenford J.Myers 提出了以下观点： 软件测试是为了发现错误而执行程序的过程； 测试是为了证明程序有错，而不是证明程序无错误。 一个好的测试用例是在于它能发现至今未发现的错误； 一个成功的测试用例是发现了至今未发现的错误的测试。 因此，测试只能证明缺陷存在，而不能证明缺陷不存在。测试的目标是想以最 少的时间和人力系统地找出软件中潜在的各种错误和缺陷。测试的附带收获是，它 能够证明软件的功能和性能与需求说明相符合。 1.1.3 测试与质量的关系 需要指出：测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。 如同考试时做完试卷后进行的检查有助于提高分数，但获得高分数不能依赖于答完 试卷后的检查。 虽然软件的高质量依赖于初始的设计，对需求的把握，但是只有在测试过程中 才能发现软件中存在的错误和缺陷，所以测试对软件的质量起着至关重要的作用。 对一个软件而言，需求分析则是它的“先天期” ，设计、编码则是“后天成长期” ， 测试的任务就是根据先天的特征更有效更合理的检验后天成长，并及时的指出错误 和缺陷。所以，应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭， 在软件开发中及早的引入软件测试，这样才能在开发过程中尽早发现和预防错误， 提高软件的质量。 1.2 风险系统中测试的生命周期 编程大师说：“任何一个程序，无论它多么小，总存在着错误。 ” 初学者不相信大师的话，他问：“如果一个程序小得只执行一个简单的功能，那会 怎样？” “这样的一个程序没有意义， ”大师说， “但如果这样的程序存在的话，操作系统最后 将失效，产生一个错误。 ” 但初学者不满足，他问：“如果操作系统不失效，那么会怎样？” “没有不失效的操作系统， ”大师说， “但如果这样的操作系统存在的话，硬件最后将 第 6 页 共 29 页 装 订 线 失效，产生一个错误。 ” 初学者仍不满足，再问：“如果硬件不失效，那么会怎样？” 大师长叹一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想 让那个程序做一件不同的事，这件事也是一个错误。 ” 没有错误的程序世间难求。James 1999 没有错误的程序世间难求。有错误就需要通过测试来发现，一个有效的测试流 程可以找到更多的错误，节约更多的成本。在实践过程中，人们逐渐总结出了软件 测试的生命周期： 图 1 软件测试生命周期 软件测试贯穿于整个软件开发过程，而对于不同主题的开发模式，软件测试在 其生命周期内的表现形式也有所不同。笔者实习时所参与研发的风险分析与绩效评 估系统（以下简称为风险系统）采用用例驱动开发模式，因此具有其特有的生命周 期。 用例驱动，是以体系结构为中心，迭代、增量开发过程。用例分析技术为软件 第 7 页 共 29 页 装 订 线 需求规格化提供了一个基本的元素，并且该元素可验证、可度量。在风险系统中， 用例是整个项目计划、进度控制、测试管理等环节的基础。用例分析主要包括下面 几部分，参与者、用例、事件流。就像类对应于对象一样，一个用例的实例就是使 用场景，用例就是对场景进行抽象的总结。事件流是整个用例的核心，一般需要编 写前置条件、后置条件、基本事件流、扩展事件流。基本事件流描述用例中常规、 预期路径，扩展事件流主要对异常情况、选择分支进行描述。 图 2 风险系统中某子系统需求用例 对应于用例驱动开发模式，风险系统中测试的生命周期如下图所示，以每个模 块的需求用例为依据，并行式的增量测试，解决了时间紧迫并且任务繁重的测试要 求。 第 8 页 共 29 页 装 订 线 图 3 风险系统测试的生命周期 1.3 小结 统计表明，开发较大规模的软件，有 40%以上的精力被耗费在测试上，即使富 有经验的程序员，也难免在编码中发生错误。在软件开发过程中，分析、设计与编 码等工作都具有建设性，唯独测试是带有破坏性，测试可视为分析、设计和编码 3 个阶段的最终复审，在软件质量保证中具有重要地位。 软件测试贯穿于整个软件开发过程，其生命周期与软件开发模式密切相关。在 说明了软件测试的基本概念以及风险系统的测试生命周期之后，下文将会首先介绍 风险系统所运用的测试管理工具 TestDirector 和自动化测试工具 Winrunner，然后详 细讨论基于 Web 的测试管理工具 TestDirector 在风险系统中的具体应用。 2 项目测试系统简介 在 SQA（Software Quality Assurance）测试过程中，一个系统的测试被划分为 五个部分：测试计划、测试设计、测试开发、测试执行和测试评估。风险系统的测 试实施则依据 SQA 测试理论和测试管理工具 TestDirector 以及自动化测试工具 Winrunner。 第 9 页 共 29 页 装 订 线 2.1 项目背景 风险分析与绩效评估系统是在规范基金投资和控制风险的背景下，以最新的金 融工程理论为基础，以我国资本市场参与方（基金公司、托管银行、证券公司等金 融机构）的实际需求为依托，建立的一套高水平、高质量的投资组合风险管理和绩 效评估体系。它以监控、风险提示、风险策略、风险处置、绩效评估为核心，能定 量地分析基金的投资风险，并能够管理和预测投资风险，提高监管水平，进一步提 升金融机构的综合管理水平与质量，增加对投资者的服务，使其工作更安全、更可 靠、更高效。 风险系统非常复杂，其功能点有数百个之多，数据处理十分频繁，数据交换吞 吐量较大。在客观条件下，整个数据处理中心的局域网和数据采集的广域网络系统 必须在较大数据量的情况下同时保持快速的实时响应能力，以保证系统的通畅运行。 同时由于是监控系统，数据的完整、准确、及时性必须得到保证。在风险系统研发 过程中，项目组采用测试管理工具 TestDirector，有效的提高了工作效率和执行力。 2.2 功能强大的 TestDirector TestDirector 是 Mecurcy Interactive 公司的系列产品之一。在 Mecurcy Interactive 公司关于 TestDirector 的广告上有一个很大的标语：全球测试管理系统。 TestDirector 是业界第一个基于 Web 的测试管理系统，它可以在公司组织内进 行全球范围的协调。通过一个整体的应用系统中提供并集成了测试需求管理、测试 计划、测试日程控制以及测试执行、缺陷跟踪等功能，TestDirector 极大的加速测试 过程。 在风险系统中，整个项目 100%由缺陷跟踪管理工具 TestDirector 驱动。项目经 理可以在 TestDirector 中查看存储的所有信息，包括测试需求、测试用例、测试脚 本、测试报告以及 BUG 报告等等。需求人员根据需求在 TestDirector 中及时建立测 试需求，来指导测试用例的开发。测试人员直接在 TestDirector 中编写测试用例， 设计测试用例集，录入测试过程中发现的 BUG。开发人员每天定时从 TestDirector 中下载“属于”自己的 BUG，并及时修改 BUG 的状态。发布人员则根据 BUG 状 态来决定是否重新发布新版本并通知测试人员。在 TestDirector 中分别对以上各种 角色授予不同的权限，来确保流程的顺利执行。在该模式下，依赖于工具（制度） 的管理方式比依赖于人的管理方式执行力和效率更高。 第 10 页 共 29 页 装 订 线 图 4 风险系统 TestDirector 驱动图 2.2.1 需求管理 程序的需求驱动整个测试过程，TestDirector 的 Web 界面简化了这些需求管理 过程，测试人员可以根据需求自动生成测试用例。提供一个直观机制将需求和测试 用例、测试结果和报告的错误联系起来，从而确保完全的测试覆盖率。 2.2.2 测试计划 测试计划为整个测试提供一个结构框架。TestDirector 的 Test Plan Manager 在测 试计划期间，为测试小组提供一个关键要点和 Web 界面来协调团队间的沟通。在 Test Plan Manager 中，可以把各种类型的测试汇总在一个可折叠式目录树内，可以 在一个目录下查询到所有的测试用例。TestDirector 还可以为每一项测试连加附属文 件，如 Word, Excel, HTML，用于更详尽的纪录每次测试用例。 2.2.3 测试执行 一旦测试计划建立后，TestDirector 的测试实验室管理为测试日程制订提供一个 基于 Web 的框架。在网络中任何一台主机空闲，测试可以彻夜执行于其上。 TestDirector 的 Smart Scheduler 自动分辨是系统还是应用错误，然后将测试重新安排 到网络上的其它机器。用 Winrunner, QuickTest, LoadTest 或 LoadRunner 来运行测试， 第 11 页 共 29 页 装 订 线 无论成功与否，测试信息都会被自动汇集传送到 TestDirector 的数据存储中心。同 样，人工测试也以此方式运行。 2.2.4 缺陷管理（BUG 跟踪） TestDirector 的 BUG 管理直接贯穿作用于测试的全过程，提供管理系统终端 终端的缺陷跟踪从最初的问题发现到修改错误再到检验修改结果。 TestDirector 基于浏览器的特征，使缺陷管理能让多个用户何时何地都可通过 Web 查询出错跟踪情况。利用缺陷管理，测试人员只需一个 URL，就可汇报和更新错误， 过滤整理错误列表并作趋势分析。 2.3 测试开发的核心Winrunner Winrunner 是企业级自动化测试工具，能够自动捕获、检测和重复用户交互操 作。它可以轻松创建测试、插入各种检查点、检验数据、运行测试并与 TestDirector 集成来分析测试结果。 风险系统中采用 Winrunner 进行测试脚本的开发，主要流程为： 图 5 风险系统测试脚本开发流程 Winrunner 中 GUI Map 分为两种模式，Global GUI Map File mode 和 GUI Map File per Test mode，区别在于前者可以为整个软件创建一个 GUI map 文件，或者为 每个窗体创建一个 GUI map 文件，而后者在每次创建新的测试时自动创建相关的 GUI map 文件。风险系统中统一采用创建全局 GUI map 文件，优点是占用空间小， 且效率高，修改方便。 创建测试步骤为： 确定测试的功能点，决定测试脚本中使用的检查点和同步点。 第 12 页 共 29 页 装 订 线 在测试属性对话框中把测试相关信息文档化。 选择录制模式（Context Sensitive 或 Analog）并录制。 Winrunner 中提供 GUI、位图、数据库三种检查点和三种同步方式，可以有效 的完成功能性测试用例的测试脚本。 调试脚本时，可以在 Winrunner 的 IDE 界面中选择 Debug 模式。调试过程中， 主要检验各检查点处脚本是否衔接，当需要循环某些步骤时可以手工增加数据驱动 测试（例如在验证界面中控件输入字符的合法性时需输入多种情况） 。 执行测试过程比较简单，只需发送执行命令，Winrunner 则会自己按部就班运 行，中间不需要人的干涉，一切都是自动化进行。 当测试脚本执行完毕后，Winrunner 会自动弹出测试报告，如下图所示。 图 6 Winrunner 生成的测试报告 图中显示为风险系统中模拟交易模块测例 TC2002 的测试脚本采用 Winrunner 执行完毕后的测试报告。在右下方显示了脚本中所有检查点的测试情况，黑色代表 第 13 页 共 29 页 装 订 线 执行通过，红色表示执行未通过，双击任何一行，可以看到更详细的执行信息。 在 Winrunner 的测试报告中，可以直接添加 BUG 到 TestDirector 中，极大地方 便了测试人员的工作。 风险系统中测试管理结合使用了 TestDirector 和 Winrunner，它们之间的集成特 性为系统的测试带来很多便利之处。 首先，在 TestDirector 中可以直接建立基于 Winrunner 的测试用例，同时在 TestDirector Server 中存储 Winrunner 形式的测试脚本。 其次，Winrunner 在执行完测试脚本后可以直接添加 BUG 到 TestDirector 的中 心数据库中，使的 BUG 录入简单明了。 再次，在 TestDirector 中的 Test Lab 面板中可以查看测例执行的历史记录，每 次的测试报告都可以通过 Winrunner 来重现。 第四，在 TestDirector 中执行整个测例集，只需在 TestDirector 中发送指令，则 参数信息通过 DCOM 协议传递给 Winrunner，Winrunner 会自动按部就班执行测例 集中所有的测试脚本，而不需要执行每个脚本时分别发送执行指令。 2.4 小结 在风险系统中，我们采用缺陷跟踪管理工具 TestDirector 和自动化测试工具 Winrunner，事实证明，采用它们能更容易的实施 SQA 测试过程，更好的进行团队 协调，从而提高产品质量和节约成本。 测试管理在以往的做法中，运作模式往往是“依赖于人” ，在这种模式下，有 人提出成功测试管理的几大经验，例如为工作雇佣最好的员工，每周与小组成员谈 话，重视结果而非时间，计划测试，承认自己的错误等等。这些经验也是人性化管 理的最好总结。 在风险系统测试过程中，运作模式为“依赖于工具” ，即在以往的经验中又加 入了一条：为工作选择最适当的工具。正是这条经验，改变了测试管理的运作模式， 使整个测试过程在一个规范的流程中有序而高效的进行，减少因为个人的延期而导 致计划的变更，减少因为人员变动而对项目进度所产生的影响，提高流程作业能力， 提升团队合作力。 依赖于工具，可以把“机械性的活” 、 “体力活”交给工具来做，在执行流制定 完毕之后，测试人员只需做“脑力活” ，处理最核心的任务。能移交给工具的尽量 托付于工具，毕竟在处理速度和机械性劳动方面，人们达成过一个共识：电脑远远 强于人脑。 在测试管理中，提倡依赖于工具，使流程化的规约来提升执行力，把人员从繁 杂的琐碎任务中解脱出来，让他们处理工具所不能胜任的工作，优化资源配置，提 第 14 页 共 29 页 装 订 线 高生产率。 3 风险测试管理 3.1 风险系统需求管理 风险系统中，采用用例驱动模式开发。用例分析为系统的需求规格提供了一个 基本元素，并且用例作为整个项目计划、测试的基础。用例具有很强的扩展性，在 写测试需求时，遵循下列流程： 图 7 风险系统测试需求创建流 测试需求的来源全部来自于需求用例，在实际开发中，一旦需求用例评审通过 后，对应的测试需求会迅速被需求人员添加到 TestDirector 中，以保证随后测试计 划、测试用例的顺利进行。下图是风险系统模拟交易子模块的测试需求图。 第 15 页 共 29 页 装 订 线 图 8 风险系统模拟交易测试需求 直观的，TestDirector 的 Requirements 面板就是一棵测试需求树。在需求树中， 可以看到风险系统模拟交易子模块涵盖的功能点，这些功能点与实际的需求用例一 一对应，而需求用例则以对应功能点附件的形式保存在 TestDirector 中。 Requirements 面板中，TestDirector 提供了 Document 和 Coverage 两种视图， Document 视图中，可以清晰的看到需求编号，需求是否有所对应的测试用例，测试 优先级等等，以确保测试的 100%覆盖率，同时，还可以查看对应测试用例的执行 状态（未执行、未完成、不通过、通过） 。Coverage 视图中，直接显示测试需求所 对应的测试用例，以及测试用例的类型（手工执行、自动执行）和执行状态，并且 可以根据需要随时新增或者减少该需求所对应的测例数目。 上图是 Document 视图，可以看出模拟交易模块中功能点对应的测试用例执行 情况。同时，通过双击测试状态，还可以方便的查看该用例的测试历史和测试报告。 3.2 风险测试计划 依赖于 TestDirector 的测试管理中，测试计划主要体现在对测试用例的设计和 处理。测试用例是测试计划的重头戏，在整个 SQA 测试过程中也处于核心地位。 测试用例是软件质量保证中最有价值的资产之一。Dianne L.Runnels(CQA,CSTE) 第 16 页 共 29 页 装 订 线 描述一个好的测试用例所具有的特性： 精确性（Accurate） 测试计划内的测试内容 经济性（Economical） 不需要冗余的测试步骤 重用性（Reusable） 可以重复使用 追踪性（Traceable） 追踪需求 适当性（Appropriate） 对现有测试环境、测试人员适用 独立性（Self standing） 不依赖于其它测试用例和设计者 自清洁性（Self cleaning） 测例执行完后的状态与执行前系统状态保 持一致（含数据库） 需要指出，在用例驱动开发模式下，测试用例和需求用例并不具有一一对应关 系，需求用例的出发点是一个功能点，而测试用例的出发点是测试一个功能的一种 执行方式。通常，一个需求用例总会对应多个测试用例（在风险系统的模拟交易模 块中，共有需求用例 11 个，有测试用例 32 个） ，但是在极少数情况下，由于功能 点的复杂性，一个大功能点可能需要由几个需求用例来描述，对应的测试用例却可 以执行整个功能，这是则会出现多个需求用例对应一个测试用例的情形（在风险系 统的基金评级模块中，有一个测试用例贯穿两个需求用例） 。 风险系统测试设计过程中，流程如下： 图 9 风险系统测试设计流 从图中可以看出测试用例的理论依据来自于需求用例，因此则有一个原则：测 试用例只对需求用例负责。另一方面，测试用例的质量也被高度重视，测试用例直 接决定后期的测试开发和测试执行，以及测试评估的准确性。测试用例在整个 SQA 测试过程中处于核心地位。 风险系统中由需求用例推动测试用例，那么测试用例是如何由需求用例所推动 呢？下图为建立测试用例的一般流程。比如在基金评级模块中，共有需求用例个数 六个，所定义的测试策略是以新建一个基金并对其进行评级为主线，逐一验证系统 功能。为该模块建立了十九个测试用例，在每个测例前添加了必须的描述，而后逐 一完成测例的具体步骤和测试脚本。 第 17 页 共 29 页 装 订 线 图 10 风险系统测试用例创建流程 在 TestDirector 中直接由需求对应来开发测试用例，系统会提供四种模式供选 择：手工测试、Winrunner 测试、QuickTest 测试、VAPI 测试。手工测试指没有测 试脚本只有测试步骤的测例，Winrunner/QuickTest 测试指可以用专业的自动化测试 工具来完成测例对应得测试脚本，而 VAPI 测试模式则可以使测例被 TestDirector 的 可视化 API 执行工具来运行。风险系统中的测试用例皆是 Winrunner 测试模式。 风险系统中利用 TestDirector 所建立的每个测试用例，包括下面几个部分： 用例名称：实际是用例编号，用来唯一标识一个测例，以 TC 起头，4 位 数字结尾，例如 TC0027。 创建日期：说明测例的编写时间，在 TD 中可以设定组别权限来控制该编 辑框是否可被编辑（不可编辑时，默认值为系统当前时间） 。 设计者：说明测例的编写者，在 TD 中同样可以设定该编辑框是否可被编 辑（不可编辑时，默认值为登录用户） 。 测例状态：说明用例是否完成。风险系统采用四个值来确定测例状态， Design,Imported,Ready,Repair,只有在测例状态为 Ready 时执行才有效。 描述：风险系统的测例在描述中涵盖测试名称，测例主要测试点和测例执 行的前置条件。 测试步骤：对每个步骤地描述和该步骤执行完成后的期望结果。 附件：风险系统中测例附件分为两部分，一类是用来执行测例初始化的数 据库脚本，另一类是执行测例过程中的数据文件（Excel 文件存储） 。 需求覆盖：这个主要采用 TestDirector 所支持的需求和测例对应得功能， 能够防止遗漏功能点，以达到 100%的测试覆盖率。 风险系统中所建立的测试用例，利用了 TestDirector 关于定制测例的功能。通过 TestDirector 的筛选器，系统中的测例略去测试类型（手工测试、Winrunner 测试等） 、 测试预测时间等内容，使得测例更简洁。由于 TestDirector 默认的字段已能够满足 风险系统测例的详细度要求，因此风险系统得测例中并没有自己添加其它字段信息。 但是 TestDirector 本身提供该功能，比如说可以自定义测例版本、测试平台等等。 权限分配也使测试设计多样化。在风险系统中，沿用 TestDirector 中默认的五种 第 18 页 共 29 页 装 订 线 组别，TDAdmin，Project Manager，QATester，Developer，Viewer。不过对其中权 限作出一定的修改，修改后的权限如下： Viewer，可以查看 TestDirector 中所记录的需求、测试、测试执行、BUG 资料，但不能添加、修改、删除任何数据。 Developer，在 Viewer 权限基础上可以添加 BUG，修改 BUG 状态，添加 BUG 修改说明，添加 BUG 附件，删除自己添加的 BUG 附件，但修改 BUG 状态时必须遵循系统所定义的 BUG 流程。特别强调的是，风险系统 中取消了 Developer 可以删除 BUG 的权力（删除自己所添加的 BUG） ，这 样保证了跟踪和管理 BUG 的完整性，避免 BUG 的丢失。 QATester，在 Developer 权限基础上可以添加、修改、删除（自己创建） 测试需求，可以添加、修改、删除（自己创建）测试用例，可以开发测试 脚本，创建测试集，配置测试执行条件。同样，风险系统中取消 QATester 删除 BUG 的权限，并且不允许 QATest 清除相关历史记录。 Project Manager，比 QATester 多处两个特权，第一可以删除 BUG，第二 可以清除需求、测例、BUG 等信息的历史记录。Project Manager 拥有添加、 修改、删除、查看项目资料的所有权限。 TDAdmin，管理 TestDirector 的账户和配置信息，设置项目的 BUG 状态流， 需求工作流，以及邮件信息。 3.3 风险测试执行 3.3.1 测试开发 测试用例完成之后，就能够根据测例的步骤来开发测试脚本。由于 TestDirector 本身并不提供开发测试脚本的功能，但它可以与其它测试工具很好的集成，因此风 险系统中采用自动化测试工具 Winrunner 来开发测试脚本。 风险系统中测试脚本通常的开发模式为： 图 11 风险系统测试脚本开发流程 由于采用 TestDirector，风险系统的测试用例与测试需求相对应，而每个测试用 例又唯一对应一个测试脚本，这保证风险系统测试脚本的 100%覆盖率。 第 19 页 共 29 页 装 订 线 在创建测试用例时，选择测试类型为 Winrunner 测试，则 TestDirector 会为该 测例创建一段默认的执行代码： # This test script was created by TestDirector status=0; passed=0; failed=1; 风险系统中所有的测试用例都是 Winrunner 测试类型，因此在创建测试用例时 TestDirector 为该测例的脚本指定了位置，方便了后面的脚本开发。实际过程中，四 台安装 Winrunner 的机器都可以作为开发机，它们可以通过 URL 访问 TestDirector 服务器，开发的脚本被保存在 TestDirector Server 中，因此并不局限于在一台机器上 开发。这一性能在风险系统中表现不是十分突出，但是如果开发人员分布在楼上楼 下，或者两地之间，那么这项特性将使得测试开发非常方便，如同本地开发一般。 除了 TestDirector 提供的接口为风险系统的测试开发带来很大便利之外， Winrunner 本身的易用性和灵活性也使得风险系统测试脚本开发效率大大提高。实 际开发中，我们利用 Winrunner 首先根据测试用例步骤来录制脚本，然后回放，对 不能运行的地方编辑测试指令，一般只需少量修改便可以完成整个脚本。 3.3.2 测试执行 在测试脚本开发完成后，就可以利用 TestDirector 来执行测试。在风险系统中 执行测试用例步骤分为：测试过程准备、运行初始化过程、执行测试、验证预期结 果、调查突发结果。 可以看出，在测试执行完毕，会出现两种可能情况：正常结束、异常结束。反 映在 TD 中，则对应执行完毕的两种状态：Passed、Failed。Passed 说明和预期结果 相吻合，Failed 则说明有相关检查点出现错误或者测试脚本抛出异常而无法进行下 去。 第 20 页 共 29 页 装 订 线 图 12 风险系统测试执行流程 在测试过程准备中，主要依赖于 TestDirector 所提供的 Test Lab。Test Lab 里定 义了系统的测例集，其过程如下： 图 13 风险系统测例集创建流程 在风险系统模拟交易模块中，依据测试策略共创建了三个测例集。在买入卖出 测例集中共对应 26 个测试用例。 这时，就有必要为各个测例来安排执行时间表，通常在注资执行成功后才能撤 资，在买入后再卖出等等。对于测例 TC2013 来说，指向它的测例有 TC2012 和 TC2010，这意味着当 TC2010 passed 并且 TC2012 finished 才会执行 TC2013。安排 测例执行时间表可以更方便的执行测试，在发送测试整个测例集命令后， TestDirector 会按照顺序来给 Winrunner 发送消息来执行测试脚本。虽然每个测例都 安排了执行的前置条件，但 TestDirector 中默认还是会执行下面测例，例如注资执 行失败，系统仍然会执行撤资的测试脚本，不过执行结果自然是 failed。有些测例 需要在特殊的时间执行，比如在股票交易日，或者开盘、收盘时刻测试才有意义， 第 21 页 共 29 页 装 订 线 TestDirector 的 Test Lab 同样可以满足这些功能，比如可以设定买入测例在交易日执 行，卖出测例在非交易日执行，这样来检测系统的功能。 第 22 页 共 29 页 装 订 线 图 14 风险系统模拟交易测例集 测试执行安排好之后，在 TestDirector 的 Test Lab 面板中可以直接发送测试指 令，既可以选中某一个测例来执行，也可以执行整个测例集。如下图中是执行一个 测例，可以看出，在设定测试时，还可以指定测试机和测试日志等。 第 23 页 共 29 页 装 订 线 图 15 风险系统模拟组合测例运行 选择执行整个测例集，和执行单个测例类似，不过效率更高，可以在所以配置 设定好完全依靠机器来处理。在上图中发送“Run”指令，TestDirector 启动 Winrunner，通过 DCOM 协议传递相关参数给 Winrunner，从而使 Winrunner 来执行 测试脚本。 测试执行完毕的同时，TestDirector 中记录了测试相关信息，即相关的测试报告。 下图为风险系统测例 TC2002 的测试属性，可以看出，该测例被执行过两次，但都 未通过。 图 16 TC2002 测试历史 第 24 页 共 29 页 装 订 线 在测试属性面板中，可以通过点击“View Report”查看当前或者历史测试记录 的测试报告，测试报告中详细记录每一步的执行情况，包括 GUI checkpoint, bitmap checkpoint, database checkpoint 的测试结果。同时，在测试属性面板中也可以直接提 交 BUG，及时将错误记录在 TestDirector 的数据库中。 3.3.3 测试评估 风险系统的测试评估中，初始数据来源于 BUG 的数目和严重级别， TestDirector 提供了多种视角来进行 BUG 的统计。可以按照 BUG 的优先级别、严 重程度、提交人、版本等来分别显示数据，风险系统中的测试报告则分别统计