TD系统与功能简介（8）

最新推荐文章于 2024-11-24 16:30:12 发布

Hexene...

最新推荐文章于 2024-11-24 16:30:12 发布

阅读量1.2k

点赞数 15

分类专栏：软件自动化测试学习笔记文章标签：前端 javascript 服务器测试工具测试用例 TD

本文链接：https://blog.csdn.net/m0_67519714/article/details/138134213

版权

软件自动化测试学习笔记专栏收录该内容

15 篇文章

订阅专栏

TD系统与功能简介（8）

2. Site Administrator

3. Add-ins Page

4. ReadMe

1. 2 TestDirector 的业务框架

2. Test Set Properties

一、实验目的

1)了解TD平台

2)掌握TD的业务框架

3)掌握TD测试过程管理平台的使用方法

二、实验的步骤和方法

1. 1 TD 的启动

Test Director 是基于 Web 的测试管理系统，客户端不需要安装单独的软件，通过浏览器就可以随时随地的访问，Test Director 访问入口的 URL 地址为：

http://[TestDirector server name or IP address ]/[ virtual directory name]/default.htm

如果在客户端访问 Test Director, 只需直接在 IE 地址栏中键入上面的 URL。如果想在 Test Director的 Web 服务器上访问，除了前面用 IE 浏览的方式外，还可以通过 TestDirector 的程序组进人, 执行【开始】|【程序】|【TestDirectors.0】|【Test Directors.0】

命令即可，系统会打开 TD的启动界面，如图 7-1 所示。

在 Test Director 的启动窗口中有 4 个链接。

1. Test Director

这是 Test Director 主界面的入口，点击该链接后系统提示“项目选择”页面，如图 7-2所示。

Test Director 使用域 (Domain) 来管理项目. 每个域对应着文件系统中的一个目录,

每个域中可以包含多个项目 (Project)。用户必须选择一个项目登录后，才能根据自己的权限进行相应的操作，如对测试需求、测试计划、缺陷管理的增删改等。关于域和项目的配置及管理将在后面章节介绍。

页面左侧的链接列表部分内容和启动窗口中相同, 如【SiteAdministrator】和【Add-ins Page】会在后面介绍。另外两项如下。

(1) Mercury Interactive on the Web：链接到 MI的站点。

(2) About TestDirector：关于所安装的版本和 License 信息。

本书使用系统自带的项目 Test DirectojDemo作为演示案例，Test Director Demo 所属的域为 DEFAULT。以管理员 (Adminisiralor) 的身份登录 (默认口令为空)，可以进入 Test Director 测试管理的主页面，如图 7-3 所示。

测试人员每天的大部分操作都是在这个页面中进行的，如制定需求、制订测试计划、安排测试执行和缺陷跟踪管理等。

2. Site Administrator

点击链接【SiteAdministrator】并登录后，进人站点管理平台，如图 7-4 所示。

3. Add-ins Page

系统插件下载页面。首次运行 Test Director 时，系统自动下载部分必须的插件，用

以保证 Test Director 的正常运行。

4. ReadMe

查看 Test Director 的发布信息。

1. 2 TestDirector 的业务框架

TestDirector 为应用程序发布之前的测试提供了一个管理的框架，能够完成从需求管理到缺陷跟踪的整个过程：需求管理测试计划测试执行缺陷跟踪。

1. 需求管理

需求驱动整个测试过程。TestDirector 能够捕获并跟踪首次发生的需求，协助测试计
划的完成，从根本上指导测试过程的实现。需求管理包括如下几个方面。
根据被测软件的相关文档定义测试范围. 将产品需求转换为测试需求。
通过一棵需求树来定义被测软件的全部需求。
针对需求树中的每一个功能点，提供详细的需求描述，包括粘贴附件等方式。
自动生成统计图表，便于测试管理者分析需求。

2. 测试计划

虽然需求驱动整个测试，但是对于测试组来说，测试计划的制订却是测试过程中至关
重要的环节，它直接影响测试的进度和质量。在测试计划阶段将要完成如下工作。
根据被测应用的测试范围和系统环境定义测试目标和测试策略。
按功能点或技术模块分解应用程序，将被测软件分解为不同层次的知识点，并建
立包含各个功能点的测试计划树。
确定每个功能点的测试方法。
将每个功能点连接到需求上，使测试计划覆盖全部的测试需求。
针对手工测试的部分，描述每个功能点的测试步骤。
指明需要进行自动测试的功能点，使用Mercury Interactive的自动测试工具或第三方的工具创建相应的测试脚本。
采用 TestDirector 提供的图表方式分析测试计划。

3. 测试执行

测试计划建立后，TestDirector 的测试实验室管理就可以帮助测试人员制定测试日程。在测试执行阶段，TestDirector 能够帮助测试人员完成以下工作。
将测试过程分成不同的组，称为一个个测试集合。比如回归测试、新增功能测试等。测试人员可以在这里安排每个测试集合所包括的测试内容。
为每个测试人员制定测试任务和测试日程安排。
运行自动测试。
以图表的方式分析测试结果.

4. 缺陷跟踪

定位和优化缺陷是测试过程中最基本的一个步骤，TestDirector 的缺陷管理贯穿于测试的全过程，从最初的发现问题到修改缺陷，直至检验修改结果。
在测试过程的任何阶段，测试人员、项目经理、开发人员和最终的用户都可以随时将缺陷记录到系统中。
相关技术负责人查看新增加的缺陷，并确定哪些是需要修正的。
相关技术人员修改缺陷。
针对修改后的缺陷，测试人员进行回归测试，如仍不符合要求，则重新提交给技术人员修改，直到缺陷被关闭。

1.3 TD 测试过程管理平台

Test Director 是一个全面的软件测试管理平台，它保存了企业所有与质量相关的重要数据。例如，测试需求、测试用例、测试脚本等各种缺陷。特别是企业在长时间使用rst

Director 后积累了大量的信息，因此 Rst Director 也成为一个软件度量积累的仓库。lest Director 除了 Site Administrator 后台配置管理程序外，另一个重要功能就是 Kst Director 测试过程管理平台。也就是广大测试和开发人员经常使用的测试管理及缺陷跟踪平台。

如图 7-6 所示，该平台包括 Requirements 测试需求管理、Test Plan 测试计划管理、Test Lab 测试执行管理、Defects 缺陷管理 4 大模块。测试人员日常工作都是围绕 Requirements, Test Plan、Test Lab 模块展开工作的. 测试闭队和开发团队则是围绕 Defects 模块进行组间交流及合作的。

TD 提供了一个比较直观的界面将测试需求、测试用例、测试脚本、程序的缺陷、测试的结果以及测试报告联系起来，并且可以使测试人员很容易地了解到每次测试所达到的测试覆盖率。用户可以直接将测试需求转化为测试用例, 降低了测试人员的工作量并且保证测试需求和测试用例的一一对应，测试人员可以根据测试需求来完成相应的测试用例和测试脚本。TD 测试执行功能的目的就是使用最少的机器完成更多的自动化测试。当自动化测试完成后，软件测试人员可以将发现的缺陷提交 TD 并通知相应的开发人员，测试人员和开发人员就可以使用缺陷管理工具进行沟通和协调并对缺陷进行跟踪。在项目的最后阶段测试人员可以通过 TD 提供的多种图表和报表对项目过程中所发现的各种缺陷进行统计分析，帮助项目组对生产质量进行总结。

1. 3. 1 Requirements

测试人员需要将开发需求转换为测试需求，并将测试需求逐级拆分至功能点。这里测试需求还可以直接转换为测试用例。需求是具有层次关系的，一个大的需求可以分解为众多小的需求，而这些小的需求还可以进一步分解，直到需求是明确的可控的为止。通常情况下要拆分到功能点一级。Test Director 中的 Requirement 模块就给测试人员提供了一个拆分、管理测试需求的场所，以便测试人员对需求进行更好的理解。另外软件测试人员在这里可以对每次测试结果的覆盖率进行分析，以便更好地评估测试效果。

用户登录 Rst Director 后单击【Requirements】选项卡。在界面T.具栏上单击当按钮来创建新的需求。如果选择了一个已经存在的需求，则可以单击

按钮来对其进行修改。

Requirements 模块的主页面以列表形式显示各个需求的信息。单击

按钮. 如图 7-7所示，在弹出的对话框中可以自定义该列表中显示的内容。

测试需求是可以和测试用例关联的.。当每晚自动化回归测试完成后，单击工具栏上的底按钮. 如图 7-8 所示，从弹出的对话框中可以了解到回归测试的覆盖情况和各个测试用例及脚本的运行结果。

为了方便测试人员浏览测试需求. Test Diretor 提供了 3 种浏览 Requirements 的界面。用户可以根据需要通过工具栏上的【DocumentView】下拉列表进行选择。

如图 7-9 所示, 【Document Reviewl】以树形结构显示 Requirement 的详细信息, 以及各个 Requirement 之间的从属关系。

如图 7-10 所示，在【CoverageReview】中可以通过【TestsCoverage】选项卡将测试项与测试需求关联起来。在【Details】选项卡中显示测试需求的详细信息. 并且可以在[Attachments】选项卡中添加测试需求的相关附件。

如图7-11 所示, 在【CoverageAnalysis Review】中可以在回归测试后对各个功能点的覆盖率进行分析。

在 Test Director 的许多地方都有添加附件的功能，其提供的常川附件有以下几种。

“文件类型”附件是最常使用也是最普通的一种。单击

按钮，如图 7 -12 所示，在弹出对话框中可以选择需要添加的附件。

"URL” 类型附件其实就是一个网页地址的快捷方式。单击

按钮，如图 7-13 所示，在弹出对话框中输人 URL 地址并将其作为附件进行保存。

测试人员在描述缺陷时往往需要截图辅助对缺陷进行详细说明，【Snapshot】就是通

过 TestDirector 提供的一种快速截图工具。单击

按钮，在图 7-14 所示的弹出的对话框中拖动

图标对当前屏幕进行截图，然后单击【Attach】按钮，截下的图片将直接作为附件进行保存。

用户在【Attachments】选项卡的列表中选择任意一种类型的附件, 如图 7-15 所示，在 Description 区域内可以为其添加描述信息。

1. 3. 2 Test Plan

Test Director 提供的 “Test Plan” 功能主要是管理测试用例和各种自动化测试脚本，这里将测试用例和自动化测试脚本统称为测试项，如图 7-16 所示。它也是以树型结构方式展现，通常 “Test Plan” 的结构是从 “Requirements”| 中转换过来的，这样每一层的测试需求和 “Test Plan”中的测试项就可以对应起来，便于每晚自动化回归测试后在 “Requirements” 中检查覆盖率和测试的结果。

"lest Plan" 是使用文件夹方式对各种测试项进行分类并管理的。打开【Test Plan】界面后单击工具栏上的

按钮就可以创建文件夹。用户选择一个文件夹然后单击工具栏上的

按钮，如图 7-17 所示，在该文件夹下就可以创建各种测试项。测试项分为手动测试用例和自动化测试脚本两大类。

Design Steps 有了测试需求后测试人员就要根据测试需求编写测试用例，然后在按照审核通过后的测试用例编写自动化测试脚本。测试用例的三要素就是“输入的测试数据”、“测试步骤”以及“期望的结果”。如图 7-18 所示，在【Test Plan】模块中的【DesignSteps】选项卡内编写测试用例。

单击工具栏上的

按钮可以逐步创建测试用例，如图 7-19 所示。在【Description】文本框中填写该步骤以及所需要输入的测试数据；在【ExpectedResult】文本框中填写该步骤所期望输出的结果。

通过以上方式逐一添加测试步骤来完成对整个测试用例的编写工作，同样也可以单击工具栏上的

按钮对已有的测试步骤进行修改。如果发现测试步骤的名称排列顺序混乱，那么可以单击

按钮对该测试用例下的所有测试步骤进行重新编号。

当编写测试用例时。如果需要引用另外一个测试用例作为本测试用例的一个测试步骤，那么可以单击

按钮来调用其他测试用例。

当一个测试用例编写完毕后，可以通过单击工具栏上的

按钮，将其转化为所需要的自动化类型的测试脚本。这时单击【TestScript】选项卡，如图 7-20 所示，可以浏览自动化测试脚本的详细内容，但此功能只能将测试项的类型进行转换，并不能直接将【Design Steps】中编写的测试用例转换为自动化测试脚本中的代码。该功能的作用是可以在 Test Director 中直接浏览自动化测试脚木，而不再需要打开相应的测试工具进行浏览。

当测试用例编写完毕后，需要将该测试用例与相应的测试需求关联起来，以便在每晚回归测试后分析功能点的覆盖率及测试结果。如图 7 -21 所示，打开【ReqsCoverage】选项卡，单击

按钮可以添加该测试用例与测试需求的对应关系。

1. 3. 3 Test Lab

"Test Lab" 是 Test Director的另一核心功能, 测试人员可以通过 “Test Set" 将众多测试用例组合起来模拟某个场景。如图 7-22 所示，“Test Lab” 可以根据设定的时间和指定的测试服务器进行自动化的测试。

单击工具栏上的

按钮来创建一个文件夹存放测试集合 “Test Set”，然后单击工具栏上的

按钮来创建测试集合。当测试集合创建完毕后可以单击

按钮为该集合添加测试用例。

如图 7-23 所示，在界面右边【ExecutionGnd】中显示测试用例在执行时所需要记录的各种属性。例如：执行结果、计划执行的时间、实际执行的时间、所使用测试服务器等。Execution Grid 中每一列的含义如表 7-3 所示。

1. Execution Flow

单击【Execution Flow】选项卡，如图 7-24 所示，“Test Director” 提供了图形化的界面供浏览各测试用例之间的调用关系。

在 “Execution Flow” 图形中，右击某个测试用例，然后在弹出的快捷菜单中执行【Test Run Schedule】命令，如图 7-25 所示，在弹出对话框中单击【New】按钮，可以设置添加该测试用例运行的前置条件。

如图 7-26 所示，可以在【Test】下拉列表框中选择一个测试用例作为该用例的前置用例；在 “is” 下拉列表框中选择当前用例的启动条件，例如在其前置用例执行完毕后，并且前置用例的运行结果符合 “is” 列表中的状态，那么当前的用例方可运行。这样"Test Lab" 就可以按照顺序将众多测试用例组合起来进行测试。

2. Test Set Properties

“Test Lab" 在运行测试脚本或测试用例时，还可以配置每个 “Test Set" 在执行过程中的属性。例如，当运行过程中网络出现问题时 TD 应该自动发 Email 通知相关人员等。单击【Notifications】按钮可以进行设置，如图 7-27 所示。

Any test in the Execution dialog box finishes with status "Failed"：在测试过程中当测试用例执行结果为失败时系统将自动发送 Email。

Environmental failure (network problems, hardware failure, etc.)：在测试过程中当出现网络或硬件错误时系统将自动发送 Email。

All tests in the Execution dialog box have finished their runs：在测试过程中当所有测试用例执行完毕时系统将全部自动发送 Email。

To：指定接收该 Email的相关人员。

单击【OnFailure】按钮，如图 7-28 所示，设置当测试失败时 “Test Lab” 可以采取的应对措施。

If an automated test fails, rerun the test up to：用户可以设置当测试脚本失败时Test Director 会自动重新运行该测试用例。

On final filature of any test in test set：Test Director 提供了几种选项供用户设置当测试用例最终失败时应该如何应对的措施。

(1) Do nothing：什么都不做。

(2) Stop the test set：停止执行测试。

(3) Rerun the test set：再重新运行多少测试。

3. Host

在进行自动化测试时可以将测试用例分散在各台测试服务器上运行，可以通过

【Host】菜单来对这些服务器进行管理。执行【Host】 |【HostManage】命令，如图 7-29所示。在弹出对话中单击

按钮【TestLab】会自行查找网络中的所有计算机并将其名称显示在 “Avaliable Hosts" 列表中。也可以单击

按钮手动向 Test Direc¬tor 中添加一个计算机。为了便于对众多计算机进行管理，【TestLab】提供了对计算机进行分组的功能，可以单击

按钮在弹他对话框中创建一个计算机组。

4.执行手动测试

在学习 "Test Plan" 时可以了解至IJ Test Director 提供了两种类型的测试项，一种是手动测试用例. 另一种是自动化类型的测试脚本。其中手动测试用例乂是由一个个测试步骤组成的，因此在 “Test Lab” 中运行手动测试用例时需要逐个步骤地执行，以检验每个测试步骤所期望的结果和其实际结果是否相同, 并在执行过程中对每一步骤的结果进行标记，必要时可以将测试过程中发现的缺陷提交到缺陷管理中心。

步骤 I：在 “Test Lab" 的 Execution Grid 中选择一个手动类型的测试用例. 然后单击工具栏上的

按钮，如图 7-30 所示，在弹出执行对话框中单击

按钮准备开始对该测试用例进行执行。

步骤 2：如图 7-31 所示，在系统弹出对话框中显示了该手动测试用例的所有测试步骤。根据当前测试步骤 “Description” 中的描述执行相应的测试，并将测试结果填写到“Actual” 中。如果该测试步骤的结果与 “Expected” 中期望的结果相同，那么则单击

按钮进入下一测试步骤，否则单击

按钮。待所有测试步骤执行完毕后，单击

按钮结束该测试。

5. 执行自动测试

可以通过［Test Labl 直接运行 MI 公司不同类型的自动测试脚本，以实现自动化的回归测试。可以选择立即运行或者在【Execution Grid】中设置计划执行的时间并且，预先指定执行该脚本所使用的机器【TestLab】会依据以上设置自动执行。

在【TestLab】界面的【Execution Grid】列表中选择某种类型的自动化测试脚本，然后单击工具栏上的运行按钮，如图 7-32 所示，在打开的对话框中如果选择了【Run All Tests Locally】选项，那么该测试脚本将在本地机器上运行，否则自动化测试脚本将按照【Execution Grid】中事先指定的机器上运行。

单击