1、.技 术 文 件技术文件名称：MI TestDirector 测试管理工具试用及评估报告技术文件编号： 版 本：V1.0文件质量等级： 共 26 页（包括封面）拟 制 邓巨峰 程琳 张平 陆建浓 谢华 审 核 会 签 标准化 批 准 深圳市中兴通讯股份有限公司.目录目录 21 试点实施的背景 32 试点实施内容和目标 33 试点项目介绍 44 TestDirector 工具简介 54.1 TestDirector 工作流图 54.2 TestDirector 主要组成部分 65 需求（Test Inputs） 75.1 现状描述 75.2 TestDirector 需求管理 .76 测试用例库
2、 116.1 测试用例设计现状描述 116.2 测试用例（Test Case）管理 116.3 自动化测试脚本 136.4 测试规程文档的生成 147 测试执行(Test Set) 157.1 现状描述 157.2 TD 测试执行 158 故障跟踪 189 测试评价 189.1 测试结果日志 189.2 测试覆盖率 189.3 测试报告生成 1810 工具特性 1811 总体评价 1812 典型问题解决方案 1913 试点中存在的问题和解决方案 22.1 试点实施的背景CMM3 对测试组织提出了测试流程一致化、标准化、更高的过程管理的要求。目前我们的测试工作中有几个方面需要提高：1) 测试人员
3、对需求、测试计划与测试设计、测试实施、测试评价这一完整测试生命周期的认识尚不清晰，缺乏统一的测试过程管理平台，导致测试具有一定的盲目性，测试工作开展地较被动；2) 测试效率和测试执行质量完全依赖于个人的技术水平和责任心，测试过程的可控性较差；3) 好的测试设计思想和技术没有被集中地管理起来，测试过程中积累的方法和经验没有被有效地固化下来，不利于测试工作的长远发展。4) 研发流程中系统生命周期各阶段是相互关联的。而目前公司的情况是信息分散，主要以文档的形式存在，使用不方便。有部分阶段也使用了管理支撑工具，但采用的工具分散，不能达到信息的一致性和信息共享。5) 计划安排，进度安排，工作量考虑等没有
4、参考数据。系统质量，系统交付使用时间安排没有量化数据作为支撑。这些也需要有效的测试管理和信息统计功能。因此，测试过程管理势在必行，我们引进了业界著名的测试过程管理工具 Rational TestManage 和 MI TestDirector，将它们分别在 2 个项目中进行试用，期望通过评估的实践，不仅对这两个工具的试用情况做出客观的评估，而且可以从它们中吸取先进的测试过程管理思想，为部门的测试过程管理改进工作提供依据。比较的结果见附件： 经过对比和分析，我们选择了 TestDirector 工具作为我们部门的测试流程管理工具，并在统一网管测试项目中全面采用。下面介绍我们对这个工具使用情况。文
5、后还有TestDirector 工具和 TestManager 工具的详细比较结果供参考。2 试点实施内容和目标1) 描述在 TestDirector 中测试生命周期是如何体现的，以此作为测试过程管理规范化的理论依据，阐明 TestDirector 作为测试管理平台工具的管理特性。2) 制订需求，并建立需求和测试用例的跟踪关系考察 TD 能否简化建立测试用例矩阵工作、能否较方便地维护需求及追踪关系。3) 实现测试用例的设计功能考察 TD 能否满足不同类型系统对测试用例描述的要求。能否使用 TD 对测试规程和用例进行评审和讨论、能否指导实际的测试工作。4) 测试任务制定、分配和执行考察 TD 能
6、否符合实际测试活动的要求，灵活方便的安排测试活动。5) 测试规程等文档的生成考察 TD 能否很方便的自动生成文档管理过程所需的测试规程等文档、并能根据公司的文档模板进行定制。6) 测试过程数据分析与统计功能考察能否使用 TD 对测试设计、执行过程中的所有量化信息进行分析统计，包括测试用例/需求覆盖率统计、测试人员设计测试用例过程数据统计、测试人员执行测试过程数据统计、被测对象的测试结果信息统计等。7) 通过 TD 和现有的需求关联工具 RP、故障管理工具 CQ 等进行集成，考察 TD 是.否能够实现测试部测试工作流程化、制度化，达到 CMM3 所要求的标准流程要求。3 试点项目介绍我们主要在统
7、一网管测试组全面采用 TD 测试管理工具，涉及的项目为网络层网管系统 ZXUMS N100 V1.0.0/V1.0.1/V1.0.2 和网元层网管系统 ZXUMS E100 V1.1.4，后来，ZXA10 和 UAS5000 等项目也开始使用 TD V7.2 版本创建了自己的测试管理流程和测试用例库。.4 TestDirector 工具简介该工具在一个整体WEB系统中提供并集成了需求管理、测试计划、测试日程控制以及测试执行和测试故障跟踪等功能。加速测试流程。建立清晰统一的测试过程管理视图。TestDirector消除组织间、地域间的障碍，让测试人员、开发人员和其它人员通过统一的数据仓库，互通测
8、试信息，将测试过程流水作业，作为统一的界面完成。4.1 TestDirector 工作流图TestDirector工作流支持如下的测试活动： 需求管理 测试计划制定； 测试用例设计； 测试部署和实施； 测试过程执行； 测试过程评价。 测试故障跟踪。以上的每一个活动都有输入、输出项，如下图所示。上述的测试流程描述的一个单次迭代的测试生命周期如下图所示：.图 测试生命周期4.2 TestDirector 主要组成部分TestDirector 主要由几部分组成 需求管理：定义需求条目与范围，定义测试主题与项目，分析需求。 测试用例设计：设计测试计划。定义测试目标与测试策略，将测试计划分组划分为不同部
9、分。设计测试用例，关联自动化测试脚本，将测试用例与需求关联。 测试计划和执行：设计测试任务，分配和部署测试过程，执行测试，分析测试结果。 故障跟踪；增加故障，设置修改级别，修改故障，分析故障数据。 目前我们采用研究所原有的 CQ 作为故障跟踪管理工具，没有采用 TD 本身自带的故障管理流程。.5 需求（Test Inputs）对于完整的系统测试，我们首先需要编制该系统所有待测项目的检查单（checklist），也就是首先必须明确被测系统的功能，明确测试的需求。采用的的途径主要包括：设计原型；软件bulids；功能说明书；需求；虚拟模型； Microsoft excel 电子表单；源代码文件；变
10、更需求等。5.1 现状描述目前公司对需求概念还比较模糊，没有明确规范对需求工作的要求。目前研究所的项目采用RequisitePro作为需求管理工具。在Requsitepro 中建立单独的测试用例库，内容包括的是测试用例的简单列表。也就是说在测试工作流程中还没有关于需求的概念，而直接以开发部建立的需求库作为需求来使用。采用RequisitePro工具的关联功能，靠手工去维护测试用例和需求的关联关系。从我们的实际使用情况看，RP对原始需求、用户需求和系统需求的管理还是比较有效的，但是在RP工具中进行测试用例的管理的效果并不理想。在TD中提出了需求的概念，并在TD 中管理测试用例及其与需求的关联关系
11、。既体现了以需求为依据进行测试用例设计、执行和评估的思想，又便于测试用例在整个测试工作过程中的动态管理，这些优点是RP中所无法实现的。5.2 TestDirector 需求管理在 TestDirector 的工作流程中，将需求管理作为测试流程的起点。系统的需求驱动整个测试过程，指导之后的测试计划的设计、测试用例的设计等等。另外测试人员还可以根据应用需求自动生成测试用例。提供直观的机制将需求与测试用例，测试结果和报告的错误联系起来，确保完全的测试覆盖率。下面分别从不同的方面阐述该工具的需求管理功能。5.2.1 需求管理工作流程a) 定义测试范围：检查应用文档，确定测试范围测试目标、目的和测试策略
12、。b) 创建需求：建立一个覆盖所有需求的需求树（数据可以通过Word、Excel中导入，需要安装相应的宏） 。c) 细化需求：对于需求树上的每一个需求，进行细化。描述每个需求，分配一个优先级，并添加必要的附件。d) 分析需求：生成报告和图表帮助分析你的需求。检查你的需求确保他们满足测试范围。5.2.2 需求的属性和内容对需求内容的描述项目大体有：需求内容描述，需求类型，需求重要程度，需求风险描述，需求状态跟踪，需求所对应测试用例执行状态，需求测试覆盖率情况，需求内容修改日志，使用人日志等描述。我们结合自身项目的情况，对 TD 提供的缺省模板进行少量定制，完全可以达到上述要求。下面是自定义模板的
13、需求内容窗口：.5.2.3 需求信息的管理需求可按照其父子包含关系层次划分,形成需求树。选择需求树上的需求，在窗口的右半部分中自动现实该需求的信息，包括该需求的详细说明，与该需求关联的测试用例，需求关联的各种附件。5.2.4 需求内容的来源 手工输入方式。直接输入需求的名称、内容、优先级等属性。 支持文档导入，TD 提供相应的插件，可以从 Word，Excel 等需求文档中导入需求内容。 支持 RequisitePro 库等第三方需求管理工具信息的集成导入。对于采用 RP进行用户需求、系统需求管理的项目，可以采用这种方式将需求成批导入，再经过分析、整理和补充之后，形成需求。 需求文档可以作为需
14、求内容的附件（Attachment） ，还可以将其它形式的需求内容，例如 File，URL，snapshot 等形式内容作为附件添加到需求内容中。5.2.5 需求与测试用例的关联与跟踪可将需求与测试用例进行关联操作。同时测试用例也和测试故障关联。这样的话，可在测试流程的各阶段跟踪需求。如果需求有改变，可以直接确定哪些测试用例和测试故障有影响，以及哪些人需要负责。操作方式：即可在需求管理模块中，选择测试用例与需求关联。也可在测试计划管理模块中，选择需求与测试计划关联。 提供直观的机制将需求和测试用例，测试结果和报告的测试错误联系起来，确保完全的测试覆盖率。 根据需求自动生成测试用例。测试人员可根
15、据需求自动生成测试用例。即可以根据需求列表自动生成测试计划中测试用例列表，也可以单独生成一个测试用例。.5.2.6 需求状态需求的覆盖状态（Cover status）共有 5 种状态，这些状态是通过是否与测试用例关联，已经所关联的测试用例的状态来自动决定的，设计人员一般不需要人工修改。 未覆盖状态（no covered）：该需求未与任何测试用例关联。 未完成状态（no completed）：与该需求关联的测试用例尚未设计完毕。 未运行状态（no run）：与该需求关联的测试用例尚未运行。 通过状态（passed）：与此需求关联的测试用例执行成功。 失败状态（failed）：与此需求关联的测试用
16、例执行失败。下图显示的为对需求的当前状态进行统计的图表：需求当前状态的统计图表（需求覆盖率统计分析）在上图中点击其中某状态区域，得出该需求关联状态的具体条目，如以下内容是尚未和测试用例关联的属于某测试人员设计的所有需求，查看需求具体属性，进行分析：5.2.7 需求状态变化与跟踪可以统计需求状态在某一时间段内的变化情况。.需求状态随时间变化图.6 测试用例库如果需求是测试设计、执行和评估的依据和输入，那么测试用例库及其中的测试用例就是我们测试工作的核心内容。TD 提供了对测试用例进行管理的强大功能，实现了测试用例的设计、维护、跟踪、统计和分析功能，并和前面的需求、后面的测试执行与评估无缝地关联在
17、一起，充分体现了测试管理过程的连续性、整体性。6.1 测试用例设计现状描述在需求中设计的是关于系统的所有待测项目的检查单（checklist），只是对被测系统功能的简单描述。需要对测试内容作进一步规划，包括对测试进度的安排，测试内容与测试方法的设计，测试用例的设计等。这个阶段的工作作为测试人员的工作，和系统的开发阶段的概要分析阶段可并行进行。随着系统开发和测试的深入，对这些内容作逐步的调整和修改。测试用例是“ 为特定目标而开发的一组测试输入、执行条件和预期结果，其目标可以是测试某个程序路径或核实是否满足某个特定的需求。 ”通俗地说，测试设计阶段的测试用例主要定义已经明确化了的对应需求的测试内容
18、，是对测试计划内容的细化，测试计划回答了要测什么的问题，而测试用例回答了测什么和怎么测的问题。我们目前已经有“测试计划”这样的概念。但是，在现有的工作流程中并没有这样的软实体存在，目前在测试计划阶段中需要做的事情基本上为根据需求说明书，编制测试规程文档，以word文档方式保存。这样存在的问题是测试用例查看不方便，测试用例层次不够清晰，而且测试用例难以做到及时与需求同步更新。目前一部分项目开始在Requsitepro中建立单独得测试用例库，内容包括的为测试用例的简单列表。采用RequisitePro工具的关联功能，靠手工去维护测试用例和需求的关联关系。这样存在的问题是，在Requsitepro中
19、去维护这种关联关系，操作非常繁琐。其中最严重的问题是，它只是测试用例的列表，不能对测试用例进行详细设计。不能和测试执行环境集成，指引真正的测试活动。可以说采用这种方式作测试规程设计只是文档形式的测试规程的另一种存在方式，对于实际的测试活动毫无用处。设计一个清晰简明的测试计划是成功的项目测试的基本要求，设计完善合理的测试用例是成功的项目测试的保证。测试用例设计工作是测试人员的主要工作内容之一。TD提供了很好的测试用例设计开发和管理流程。6.2 测试用例（Test Case）管理6.2.1 测试计划管理工作流程a) 定义测试策略：检查应用程序、系统环境和测试资源，决定测试目标。b) 定义测试主题：
20、将程序划分为多个要测试模块。建立一个测试计划树，这样可以建立分级的测试单元或主题。c) 定义测试：确定每个模块需要的测试类型，为每个测试在测试计划树上增加一个基本定义。d) 创建需求覆盖：将每一个测试用例与相应的需求相链接。e) 设计测试步骤：对于手工测试测试用例，设计测试用例的步骤，测试步骤包括测试操作、检查点和期望输出值，并决定哪些测试可以自动化。f) 自动化测试：对于决定要进行自动化的测试，使用WinRunner 、Visual API、定制或者使用第三方的测试工具生成测试脚本。.g) 分析测试计划：生成报告和图并辅助分析测试计划数据，检查你的测试，决定对于你的测试目标是否合适。6.2.
21、2 测试用例内容完备性由于测试计划中的测试用例是参照需求中内容项产生，设计目标明确，不会有大的遗漏产生。指导测试人员设计出符合实际需求的优秀的测试用例。6.2.3 测试用例的分级管理对于项目的测试，需要根据不同的测试目的，不同的测试内容项，分组分类管理。在 TestDirector 中通过 folder 将测试计划划分为不同的单元（ subject） 。测试用例分属于 subject。建立测试计划树来直观描述测试安排。方便管理。测试用例分级管理6.2.4 测试用例与需求关联关系可将需求与测试用例进行关联操作。同时测试用例也和测试故障关联。这样的话，可在测试流程的各阶段跟踪需求。如果需求有改变，
22、可以直接确定哪些测试用例和测试故障有影响，以及哪些人需要负责。通过设置这种关联关系，更容易追踪出需求的变化导致的测试用例和测试用例实施方法的变化。还可以在测试执行结束后，通过运行报告识别出有测试用例和实施方法的需求，并且标识出已经被运行的测试用例。测试用例与需求是多对多的关联关系。操作方式：即可在需求管理模块中，选择测试用例与需求关联。也可在测试计划管理模块中，选择需求与测试计划关联。6.2.5 测试设计阶段的测试用例状态分析与统计根据测试用例的设计情况，测试用例的设计状态共有： 创建中：测试用例尚未设计完毕。 未评审：测试用例设计完成，但是尚未评审。 使用中：测试用例评审通过，可以分配和执行
23、。 已停用：测试用例停用，处于失效状态。对用例查询统计的作用：. 在测试设计工作过程中可以随时了解当前测试人员的测试进展情况，对测试设计工作及时作出调整； 可作为对测试人员在测试用例设计阶段的工作量考核的参考数据。 还可以利用 TD 工具提供的灵活的查询定制功能，对某项目或者产品当前的所有测试用例进行分类和统计。测试人员的用例设计一览测试用例随时间的状态变化6.3 自动化测试脚本测试用例可以是手工的测试用例，也可以是自动执行的测试用例，及以自动化测试脚本的形式体现。对 TD 用例库中的自动化脚本可以分为下述几种类型： 使用 MI 公司的 WinRunner、LoadRunner 等测试工具的脚
24、本，可以作为用例的属性，直接在 TD 测试用例库中进行管理和直接调用。 对于使用其它工具如 Rational Robot、ProcommPlus、 ScriptCenter 等的脚本，我们.目前的做法是这些脚本由相应的工具自行管理，因为这些工具本身已经有其自身的较适合的管理方式，在 TD 用例库这里只把这些脚本的标识( 如脚本路径名称、脚本 ID 等)作为测试用例的属性进行管理。测试人员在执行这些测试用例的时候，根据脚本的标识，使用相应的工具在其脚本库中打开来运行。 手工的测试是可以逐步转化为自动化测试脚本的。在手工脚本逐步完善之后，为了提高测试的效率和质量，部分手工测试用例可以逐步用自动化脚
25、本来实现。测试用例的属性包括手工用例、自动化用例等等，测试管理人员可根据需要，逐步提高测试用例中自动化用例的比重，并可通过定制的查询了解到当前测试用例库自动化程度的高低。6.4 测试规程文档的生成目前公司要求测试规程文档作为产品基线文档之一，测试规程文档就是覆盖该产品的所有系统需求的测试用例集合的文档化描述。从 TD 中可以根据所选择的测试用例自动生成测试用例集合文档，经过改动之后就可以形成符合公司文档模板要求的测试规程文档。这种方式有如下好处： 从 TD 测试用例库自动生成测试规程文档，解决了困扰我们很久的测试规程文档与当前测试用例不一致、更新慢的问题。 原来的测试规程文档中的测试用例是一个
26、最全、最完整的集合，而我们在具体测试过程中，根据测试的需求与内容不同，实际上每次执行的测试用例内容和数量都不一致，都是测试规程中所有用例的子集，导致我们拿着完整测试规程倒是失去了具体的工作指导。现在我们使用 TD 来管理所有测试用例，在制订具体任务计划的时候才选择和明确需要执行的测试用例（下面会介绍其工作过程） ，而在需要完整的测试规程文档的时候自动生成文档，就显得十分方便、灵活和严谨。 除了测试规程文档，TD 还提供了比较丰富的、可定制的模板，可以生成包括需求、用例、执行、跟踪在内的许多类型的文档。.7 测试执行(Test Set)7.1 现状描述如上所述，目前我们的测试人员在接到一个测试任
27、务的时候，会根据测试申请单中要求测试的功能需求，根据测试规程中的测试用例进行测试。但是测试规程中的用例是对应产品所有需求的所有测试用例的集合，而每个测试任务所执行的测试用例内容和数目均不相同，导致测试的覆盖率和质量难以保证，测试管理者如测试经理也很难了解到测试的相关过程数据，比如本次测试计划执行的测试数目和具体内容、本次测试实际执行的测试用例情况、测试人员执行的具体情况、测试用例执行具体结果等等。7.2 TD 测试执行7.2.1 TD 的测试执行管理功能对比上述的不足，使用 TD 的测试执行管理功能，测试管理者很容易完成下述的工作： 根据测试申请单中列出的需求内容、并根据测试的风险、时间人员等
28、资源因素，在测试用例库中选择相应的测试用例，形成测试任务准备进行测试 为每个具体的测试用例安排相应的测试人员，把执行测试用例的职责具体到人。TD 允许多人合作完成一个测试用例的情况，可通过生成测试用例多个实例的方式来实现 在测试任务制定时，根据测试用例的相互制约情况(如时间顺序上的制约、资源的制约和冲突)，制订测试用例的运行时间，从而实现测试用例在执行时间的安排和分布 根据测试任务中包含测试用例的需求覆盖情况，统计出这些测试用例对测试申请单中需求的覆盖情况。 在测试执行过程中，测试人员只需打开 IE 的 TD 用例执行界面，就可根据按时间顺序安排好的测试用例进行测试，也可根据实际工作情况的变化
29、，灵活选择测试用例进行测试。测试时，由于测试用例的操作步骤、通过准则都描述的十分详细，测试人员可根据用例要求严格进行测试，并记录下测试执行的结果。 在测试过程中，测试人员可随时新增测试步骤和测试数据，并保存在测试用例库中，供评审后复用，解决了以前随机想出来的测试方法和步骤不方便保存和复用的问题 测试过程中，测试人员对某些测试用例可反复执行多次，TD 将如实记录每次测试的过程数据和结果。 测试过程中，TD 会记录每个测试用例执行的实际执行时间。测试管理者可对这些用例执行时间进行分析和统计，对一些执行效率不高、容易给测试工作造成瓶颈的测试用例进行改进，比如转化成自动化测试、通过环境的提前精心准备，
30、解决执行该用例过程中进行环境搭建花费时间太多的问题等等。这个功能为我们改进测试效率提供了很好的量化测量工具。我认为这是 TD 的一个很好的功能。 测试管理者在测试任务执行过程中，可随时查看各测试人员的测试工作执行情况、查看所有测试用例完成情况，以便及时发现问题，及时调整测试工作计划 测试执行结束之后，测试人员和管理者可以方便的统计所有用例的执行结果、用例的故障发现率(即有些用例发现故障的比例比较高，今后测试多采用这些用例；而有的用例比较难发现故障，今后考虑风险因素之后可减少这些用例的使用)。. 测试执行结束之后，管理者可以根据测试人员实际执行测试用例的情况来衡量测试人员的实际工作量和工作效率。
31、7.2.2 测试执行工作流程测试执行工作流程图示：7.2.3 测试任务制定根据测试申请，测试管理者在 TD 中创建测试任务 TestSet 进行用例的安排和人员的分配。包括本次测试任务包含的所有测试用例、测试用例分配给哪位测试人员来执行、测试用例计划执行的时间等信息。Test Set 中包含的测试用例在测试流视图中，还可以设置测试执行中测试用例执行的流程，包括执行的时间进度安排，测试用例之间执行的前后条件约束，执行频率等。下图就是测试流视图的内容：.Test Set 中测试用例执行的流程设置7.2.4 测试体执行测试开始的时候，测试人员打开 IE 终端，通过测试任务的过滤器查看分配给自己执行的
32、测试用例，然后按照安排好的时间顺序来执行测试用例。手工测试用例执行时，弹出人工测试运行窗口，在窗口中显示测试用例的测试步骤与预期结果，测试人员可以按照这些信息指示一步一步的测试。每一步测试完毕后，填写测试的实际结果，并根据实际的测试结果设置是“pass”还是“fail” 。在运行阶段发现测试用例的测试步骤有错误时也可直接作修改，这些修改也将存到测试计划中去。测试用例还可以多次执行。当 Test Set 运行过程中添加可直接添加 test defect，该测试故障直接和该测试用例 test 关联，并且可直接将运行的故障状态作为故障的描述信息提交到故障库中去。这个功能我们目前不采用，测试过程中发现
33、的故障直接通过现有的 CQ 流程提交上去。.人工测试用例的执行8 故障跟踪目前公司和事业部都采用 CQ 作为故障管理工具，而且已经比较成熟了，虽然 TD也有很好的故障管理功能，但是我们就不再采用，所以也没有做深入的研究。9 测试评价9.1 测试结果日志需求，测试用例和测试故障可相互关联。每次测试执行的结果有日志信息供查看。9.2 测试覆盖率在每一阶段，可分析数据并生成数据报表和图形显示。例如：分析需求各种状态的分布，测试用例各状态的分布，相对于不同人员的分布。9.3 测试报告生成 可以生成本次测试所有用例的执行结果情况和统计分析数据。这个统计仅用来分析本次测试设计和执行工作本身的质量，以便于考
34、核和今后工作改进，而对被测对象的质量评估，我们还是从CQ中提交的故障导出。 测试报告的文档，我们还是根据公司模板要求来编写，相关的测试故障还是从CQ中导出。10 工具特性 在每一阶段，可分析数据并生成数据报表和图形显示。 可以定制要显示的数据字段，可以定制查询条件选择显示数据。 任何查看到的数据都可存取保存为 Text ，Word ，excel ，html 格式的文件。 可以保存自己熟悉和喜爱的视图，待下次打开是显示同样的使用视图。Public 类型的 favorite 全部人员都可使用，private 类型 只可创建他的用户使用。 TestDirector 的扩展性：提供开放架构，提供开放
35、COM_base API 开发接口，方便我们进行更灵活的二次开发。 项目可以定制。工作流可以定制。不同角色工作界面、操作权限可以设计。 具有较好的安全管理功能，可设置用户组和用户权限，对用户访问的项目进行限制、对用户的读写操作权限进行控制。 据代理商介绍，全新的 TD V8.0 版本提供了更为强大的安全管理和版本控制功能，对用户所能操作的用例、需求的权限不仅在项目级别进行控制，还可以控制到具体的用例和需求条目。另外，为测试工作产品的更为严格的版本控制需要，对流程中的用例、需求等工作产品进行了 Check in 和 Check out 操作的限制。这些功能在 V7.6 中没有提供。.11 总体评
36、价 数据统一，信息相互关联，方便的跟踪到信息的状态变化，查看到各种覆盖率情况。从中分析出系统的进度情况。查看的方式包括报告形式与图表形式。 作为指导计划的参照数据，工作量分析的参照数据 数据统一，共享。工作成果统一保存。不同角色工作成果的输出直接作为相关角色的工作输入。 指导测试人员的测试活动。12 典型问题解决方案TD 与 TM 工具实际问题回答列表问题 TM 回答 TD 回答1、测试用例的组合顺序与TM 中的用例如何对应？工具本身并不提供用例设计的方法，测试用例可大可小，根据实际情况灵活处理。测试用例的执行顺序可以通过 testsuite 来对应。Testmanager 中的一个 suit
37、e对应做一个用例组合。不同的 suite 可以包含相同的用例，但是这些用例的执行顺序、运行次数、运行的计算机组都各不相同。所以实现了不同目的的用例。同 TM。2、验证测试时提交功能清单，如何与工具联系起来?需要定制。Testmanager 与现在所内的测试申请的管理工具 cq 是一个集成的产品，可能需要Rational 的技术支持。需要定制。如果开发各部门全部使用统一的 TD 项目库，整个流程全部采用 TD，由于 TD 采用一个库，所以保证在提测试申请时选择相关需求，从而可使测试人员在得到测试申请时知道本次测试的全部内容（通过需求的状态改变来得到） 。可能需要在 TD 的需求管理定制类似 CQ
38、 中的测试申请流程，3、CQ 上的质量评价考核单，测试申请等能否与 TM 关联起来?同上 同上4、测试用例中的测试数据如何实现?每个测试用例可以对应一个datapool（testmanager 中测试数据管理工具）数据库。这个数据库可以在生成脚本数据作为用例的一部分存在，以及在自动化脚本中采用DataPool 的形式。.的时候由系统自动生成，也可以由测试设计人员手工编辑。数据库中包括各个字段定义（一般一个字段对应着一个测试数据） 。数据库中的一条记录对应着一套完整的测试数据。5、对同一个测试内容，如何保证前后两次测试的可比性?每个用例的执行都会在testmanager 中生成一条用例的执行日志
39、。同一用例不同的执行，可以通过比较日志来比较测试结果。TD 中可保留每个测试用例的所有测试记录，可以对不同测试进行比较。6、由于工作中的疏漏引起的测试质量问题是最大的问题，工具能够保证测试质量有很大的提高吗？间接支持。Testmanager 是一个测试管理工具，对应测试中每一个环节都提供了细致全面的管理，同时自动将各个环节关连起来，相互之间提供一定的状态标识，提醒操作员各个环节当前的状态。对于一些完全不符合测试流程要求的操作进行了必要的保护。这样可以大大减少测试中的疏漏。间接支持。通过流程改进，运用工具设置一些必要的工作环节，在一定程度上可保证测试人员的责任心7、测试用例设计质量不行，如何知道
40、一个需求需要 5 个用例才能解决问题，但实际只有 3 个？而这点依靠工具同样不能解决。工具本身不能保证，但是它可以提供非常清晰的数据作为决策参考。同 TM。8、工具中能否体现工单的质量问题?在测试用例是经过评审，默认正确、完善的情况下，测试执行结果中显示的用例覆盖率、故障发现情况，可以作为评价工单质量的重要依据。通过故障总数、个人的故障数、测试覆盖率来表现9、引入工具，工作量会大大增加工具必须在测试团队中大范围的使用，大家通过该工具实现工作成果的实时共享、可以大大减少工作上的重复的工作量、确保工作顺利高效的执行。作为工作流程中一个组成部分，在测试活动中随时使用，由于可以资源共享，经验共享，随着
41、推广力度的加大，工作量应是减少10、工具能否体现测试人员的责任心？工作内容透明化，一定程度上可以显现出测试人员的责任心。同 TM。.11、测试质量不可控，同一个规程不同的人测，测出来的结论和故障都不一样；完全相同的测试用例，在外界条件一样的情况下，执行的结果在工具中应该是一样的，可以消除人的差异性。同 TM。12、规程修改缺乏实时性； 需求变化规程也应该发生变化。Testmanager 与需求管理工具 requisitepro 相互关连，当需求变化是自动修改用例中对于的需求标识，提醒测试人员及时修改测试用例。这样该用例下次执行的时候就包含了新的测试内容。Testmanget 是测试人员可以方便
42、快捷的实现测试规程、用例的实时更新。在库里进行即时修改，需求改变相应规程即变化。13、测试人员的测试时间不可控，有人只要 3 天，有人要 5 天，测试经理不好控制。用例确定的情况下，一个测试用例在一定配置测试设备上执行测试的时间是一定的，从而整个测试过程的时间是可预期的。所有用例有测试历史记录，记载该用例以前的测试时间等等数据供测试经理参考14、测试用例增加，但需求未增加的这种情况，该如何处理?直接手工增加新的测试用例，如果有可关联的需求，则关联原来的需求，如果没有需求，则可以先补充再关联。在 TD 中补充可关联的需求，增加新的测试用例。15、分析过程中，测试报告中发现一个小故障现象，可能现象
43、下面隐藏着更大的隐患，而我们却没有发现。开发人员比较关心的是执行什么操作出现的错误，而不是错误本身的现象，流程和工具如果能做到这点就比较好。自动化测试，可以通过分析测试结果日志来查找原因。对于手工测试，工具难以支持。不支持。关于多版本情况的管理。 间接支持，定制实现1:我们可以考虑用添加多个标示字段的方式，也就是说有多少个版本，添加多少个标示字段，通过相应版本字段是否设置值来区别不同的版本。2:该方案适用的前提是版本的数目不要太多（版本太多的话，需添加较多的字段，不方便）。.3:为了避免版本过多的情况：可以只考虑大版本号，对于研发过程中间的测试、调试版本等不作考虑。.13 试点中存在的问题和解
44、决方案从试点的情况看，问题主要存在于与 RP 需求库的同步和一致性问题、文档生成格式的定制问题、以及二次开发的扩展灵活性问题。 用户在使用客户端进行操作时，有时候会提示“RPC 服务无法访问”需要把 IE 升级到 6.0，另外 IE 的代理去掉，发生的频率会少一些。当然如果还是发生了，重启 IE 就可以。 RP 和 TD 的需求库难于实现完全的、随时的同步，可能导致今后两个库的数据不一致，人工维护 TD 测试数据库的工作量加大这的确是个问题。现在用 RP 库来创建测试用例以及建立用例与需求的关系，同样需要人工来实时维护。可以考虑在 RP 中增加查询功能，能查询某个时间段的新增或变化的需求，测试
45、人员根据这些变化，及时地对 TD 的需求库进行变更和维护。当然，如何统计 RP 库中的需求和 TD 的需求的对应关系是解决问题的关键，如果能随时统计 RP 库的需求变化情况和 TD 的需求变化情况关系就更方便了，我们准备和供应商提出要求，试图解决。 RP 和 TD 的同步都是双向的，极有可能导致同步一次之后，RP 中的修改影响到 TD 中需求库的内容，反之亦然。需要进行同步的方向和范围的限制，即只能由 RP 向 TD 同步，反之不可以；只能在项目的系统需求基本建立起来后，对该项目的需求进行一次同步，之后由测试人员来维护 TD 的需求，根据 RP 的变化进行手工维护，而不能再次同步。这一点时我们
46、认为 TD 的一个缺点，当然原因主要是这两个软件的开发商不同，不可能完全向对方公开接口，只能由我们自己来寻找尽量好的解决办法 可在 TD 允许的范围内定制输出的测试用例、需求等文档格式，但是无法按照公司的 WORD 文档模板的要求严格进行定制。只能导出后进行手工格式转化，比较麻烦。考虑可以根据公司文档模板的要求，用 WORD BASIC 宏来实现格式的复杂变换。另外据说 V8.0 的文档和报表定制功能更为强大，效果如何需要了解。 RP 需求库中，不同版本的相似需求，后续版本的需求只包括变化的部分，隐含继承原来相同的部分，而对应这些需求的测试用例库中的测试用例，都是分别对不同版本需求的完全描述，
47、是否不容易维护和更新。个人认为 RP 的这种方式同样存在问题，不同版本的需求本身就是独立的需求，都应该描述完备，而不管其中有部分内容是否相同，因为需求之间的差异有时候很难描述，有时候本身就是相互矛盾而不是递增关系。对应不同需求的用例当然也是独立的完整的用例，个人认为这方面没有问题。 TD 中的 DEFECT 模块一旦替换成了 CQ，需求、测试用例等关联项无法跟踪到底。 可在 TD 中，对每个测试用例增加用例 ID 的属性，以便唯一的标识每一个测试用例，在提交 CQ 故障时，故障的属性中包括发现这个故障所执行的用例 ID ，就.可以实现 TD 用例CQ 故障的关联关系，便于分析和统计。至于 RP
48、 和 TD 的关联，可以通过人工维护 RP 系统需求和 TD 需求来保证。另外建议 RP 与 CQ 集成后，问题的跟踪就直接通过 CQ 进行管理了，不用通过 TD 多走一步。 Rp 与 TD 同步时创建 map 时,一个 map 只能同步一个 project 中的一个 req TYPE.但是 TD 中没有 REQ TYPE 的概念 .同上 RP 与 TD 得同步时,虽然定制了任务,可是实际上并没有执行每多少分钟得同步任务.目前只能手动执行同步操作.或者写一个批处理文件,据说写起来比较复杂.同上 td 只能识别父子需求,RP 中的需求导入 TD 以后，目录结构被改变，原来的文件夹不见了,只有父子
49、关系的需求还存在,且存放于不同文件夹的需求到了 TD 都处于平行状态.无法同步到指定的文件夹下或者将上级文件夹导入。导入 RP 中的需求之后，测试人员要进行整理和归类。 同步 CQ 与 TD 的故障模块 ,提示同步失败,且无日志信息可查.因而无法查找与判断失败原因.不采用 CQ 与 TD 故障模块的同步，直接在 CQ 中提交故障。 CQ 替换 TD 中的故障模块后，一次只能输入一个故障，输入完毕后，系统自动退出 CQ，需要重新登陆。建议需要手工提交的故障在 CQ 中直接提交,由 TD中脚本自动生成的故障通过 TD 与 CQ 的接口提交.imag 公司目前还无法解决这个问题。因而建议直接在 CQ 中提交故障,TD 只是把CQ 中的故障同步过来,不作修改.方法与需求库的同步类似.(只需要同步 cq 中的变更请求一个表格,但是至今仍未成功).
