第三章 测试用例编写与管理.pdfVIP

第三章 测试用例编写与管理 本章重点 本章结合TestDirector 的使用，使用这个全面的测试管理解决方案软件全过程的管理测 试过程中所产生的工件。从测试需求提取、用例设计直至用例管理整个测试工作中的关键点 进行系统地阐述，读者在本章可以了解如何获取测试需求及设计、管理测试用例，并运用 TestDirector 进行实际的测试活动。 3.1 测试需求提取 所谓测试需求，就是我们在开展测试工作的初期，需要确定本项目测试的内容与重点。 在接收到测试申请，分配到相应的任务后，测试工程师需要弄清楚被测对象是干什么的，哪 些地方需要测试，这些需要测试的地方有没有优先级等。一般情况下，测试组长分配测试任 务时，会给出与项目相关的文档，比如我们这里的《OA 系统需求规格说明书》、 《OA 系 统概要设计文档》、《OA 系统详细设计文档》、《OA 系统数据字典定义》、《OA 系统 数据库设计》等等，然后测试工程师会根据自己的任务内容去查阅相关章节。如果前面有需 求测试的话，这个步骤可以省略，直接进行需求的提取了。如果没有需求测试，则需要深入 了解被测系统，以期知己知彼。 以OA 系统测试为例，测试组长从配置管理员处提取该系统的相关文档。比如 《OA 系 统需求规格说明书》、 《OA 系统概要设计文档》、《OA 系统详细设计文档》等。当然， 也可能什么文档都没有，仅有开发同事提供的 《Function List》（功能列表）、CheckList （检 查列表），那么测试工程师就需根据这些文档去熟悉系统，画出系统的功能结构图、业务流 程图等，从而清晰地了解系统的功能架构，为更好的熟悉、测试被测系统提供帮助。需要说 明的是，不要总幻想公司在实际项目生产过程中流程多么规范，文档多么齐备，我们知道， 高质量的软件是受Scope （范围）、Time （时间）、Cost （成本）三个因素影响的。在某些 情况下，因为各种客观、主观的原因，可能没有这么多完善齐备需求、开发文档，测试工程 师也应该能够出色的完成测试任务，不要受测试理论的影响。我们要学会在多种环境下作战。 碰到正规军，我们就讲策略，碰到野战部队，咱们就各个击破，而不要过分的追求规范，不 管是白猫黑猫，抓住耗子的就是好猫。当然，要在一定的质量管理原则下。 我们这里将OA 系统的帮助文档假设为该系统的 《Function List》 （该帮助文档位于oa 文件help 目录下，名称为“frame.html ”），那么根据此帮助文档可以绘制出该系统的基本 功能结构图，如图3- 1 所示。 图3- 1 OA 系统功能结构图 实际上根据该帮助文档还可以划分更深的目录，这里为了便于大家理解就不分了。功能 结构图有了，这样从上图我们可以明确得知系统的整体功能结构状况，极大地方便了测试需 求的提取。如果项目开发比较正规，那么在项目的用户需求规格说明书都会给出系统的整个 功能结构图。测试工程师可以根据这个功能结构图来组织测试。如果没有，就需要自己画图 了。根据我的经验，测试工程师最好在提取需求、设计用例之前画出系统的功能结构图及自 己所分任务模块的功能结构图、业务流程图。图形一目了然，比起无章法的随意划分要好多 了。 为了便于讲解，这里仅以“公共信息”下的“图书管理”功能模块为例，详细描述该模 块测试需求的提取过程，并如何使用TestDirector 测试管理工具进行测试需求的管理。 在开展需求提取之前，作为测试负责人需要在 TestDirector 中创建相应的项目。 TestDirector 的安装与配置这里就不再讲解了，不太清楚的读者可以查看《软件测试工程师 培训教程》一书中的第三章第三节《3.4TestDirector 安装配置及使用》对应的部分。TestDirector 创建项目的一般流程如图3- 2 所示。 图3- 2 TestDirector 项目创建流程 3.1.1 创建被测项目 测试组长接到测试任务后，可先行与TestDirector 管理员取得联系，申请在TestDirector 中创建相应的项目，比如此处的OA 系统项目。TestDirector 管理员审批通过后，可进行OA 系统项目的创建。 1、打开TestDirector 后台管理界面，如2/tdbin/SiteAdmin.htm