Testopia 中文用户手册


Project Testopia 中文用户手册 By: Eddie Zhang 简介 Testopia 是 Bugzilla 的扩展组件。设计的目的是为了跟踪产品测试的效率。 Testopia 提供了 case 和 bug 之间的互连。 Testopia 采用了标准的黑盒测试流程。将主要目标分为如下三个:Test Plans,Test Cases 和 Test Runs。 Test Plans Test Plans 是位于最高层的文档,规划了整个测试流程。在 Testopia 中,用于组织 test cases 和 test runs。 Test Cases Test Cases 是任何测试流程中都包含的元素。详细的描述了如何通过一系列的步骤来验证 一个测试对象是否符合设计目的。 Test Runs Test Runs 是一组 test cases 在产品的某个版本上运行后可获得的结果集。 Testopia 中不仅仅包括这三个对象,只是最主要的三个对象。 框架结构图 从图中可知,Testopia 中的对象都包含在 Product 的下一层中。位于顶层的是 test plan, 然后才可以创建 test case 和 test run。 Test case 使用关联到 product 的 category 分割,但是同时也可以和一个或者多个 component 关联起来。 Test run 通过 build 分割,build 由产品中设置的 milestone 获得。Test run 可以与测试 环境 environment 关联。Environment 中可包含一个 platform 和一个 operating system。 Test Plan 创建一个 Test plan,只需要点击位于页面下部的 New Plan 链接即可。系统将引导你进入 一个新的页面,来填写创建一个新的测试计划需要的信息。 这个页面中包含了一系列的 field,让我们来看一下: Field 名称 描述 Name 测试计划的名称。允许有同名的测试计划。 Product 每个测试计划都必须包含一个且唯一的产品。产品列表与 Bugzilla 中创 建的产品列表相同。 Product Version 一旦选择了一个产品,将自动获得该产品的版本列表 Type 表明该测试计划的类型。 Plan Document 用于填写与测试计划的执行相关的文档内容。 在填写完毕后,提交该测试计划,将来到一个新的页面。在这个新页面,你可以浏览你刚 刚创建的测试计划。 在页面顶部的 overview 部分,你将注意到几个 buttons。他们的功能如下: 按键名称 功能 Archive 点击后,测试计划将被置为无效状态。在查找中无法获得。 Unarchive 点击后,测试计划将被置为有效状态。在查找中可以获得。 Print 点击后,生成一个可被打印的测试计划页面。 History 点击后,可查看测试计划的历史记录,和修改情况。 Clone 点击后,可复制当前测试计划到一个新的测试计划。 点击“Clone”按键后,将进入一个复制测试计划的页面。 在该页面中,有如下几个选项: 选项 描述 New plan name 填写一个任意的新测试计划名称。 Product version 选择一个新的产品版本。 Copy plan document 是否复制测试计划的文档。 Copy tags 是否复制测试计划的标签。 Copy/Link test cases 是否复制/链接相关的测试用例。 Copy/Link test cease from selected categories only 选择复制/链接指定分类的测试用例。 什么是 Copy? 如果你选择了“Copy”,那么源测试计划所包含的测试用例将被物理复制到新的测试计划 中。 好处是同样的 case 包含在不同的测试计划中,如果 case 的更新是针对某个特定的计划, 将不需要考虑其他的测试计划的更改。缺点是,一旦更新 case 的通用基本信息,需要在一 个个测试计划中查找出来然后更新,效率较低。 什么是 Link? 如果你选择了“Link”,那么源测试计划所包含的测试用例将被逻辑的复制到新的测试计 划中。好处是,一旦更新 case 的通用基本信息,只需要更改一次。缺点是,一旦针对某个 特定的测试计划去修改测试用例,可能会导致其他测试计划出现问题。 Category,Tag 和 Build 公共图 Category 在建立测试用例前,必须至少有一个 Category 被定义。 Category 是测试用例的分类集合。每个测试用例必须属于而且唯一属于一个 Category。这 样就能将 cases 组织成不同的有意义的测试集合。 Category 是基于 Product 来定义的,凡是属于这个 product 的测试计划都能够选取它。 为了创建一个 Category,如公共图所示。点击 Add 链接,就进入了创建页面: 只需要输入 Category 的名称即可。描述是可选项。 Build Build 和 Category 很类似,不同之处在于他们为 Test run 使用。 Build 是同一 Product 的在不同开发阶段的产品实例。对于同一product 的所有测试计划都 是可见。 为了创建一个 Build,如图 1 所示,点击 Add 链接,就进入了创建页面: 只需要输入 Build 的名称即可。描述是可选项。Milestone 从 product 中获得。 Test Case 测试用例是 Testopia 的核心。一个测试用例由一系列步骤和期望值组成。所有的测试用例 都必须连接到至少一个测试计划。 创建新的测试用例: 1.首先要选择与那个测试计划关联。可以关联多个测试计划。 2.然后填写 Attribute 部分: 名称 描述 Summary 测试用例的概要描述 Default Tester 默认的测试人员 Add Tags 标签 Select Components From 关联的组件 Alias 唯一的标示符 Requirement 额外需求 Status 状态 Automatic 测试方法 Priority 优先级 Script 自动测试使用的脚本文件所在路径 Category 所属类别 Arguments 自动测试需要的参数 【Status】用于区分测试用例的使用范围。 ―Proposed 状态: 表明该用例正在修改中,应避免使用。 -Confirmed 状态:表明该用例可正常用于测试。 -Disabled 状态: 表明该用例应该从测试中删除。 【Alias】帮助你快速定位。在一个系统中,测试用例的 Alias 必须唯一。主要是用于帮助 自动测试使用测试用例的名称而不是 ID,提高效率。 3.然后填写 Dependency 部分: 【Depends On】设置另一个测试用例,作为本测试用例先驱用例。 【Blocks】设置另一个测试用例,作为本测试用例的后继用例。 4.然后填写 Set Up 部分。该部分用于描述测试用例需要的相关的配置信息。 5.然后填写 Break Down 部分。该部分用于描述测试用例中止的条件信息。 6.然后填写 Action 部分。该部分用于描述执行测试用例的步骤。 7.然后填写 Expect Result 部分。该部分用于描述执行步骤后应该得到的正确结果。 最后获得一个新创建的测试用例 对于一个存在的测试用例,还需要注意的部分包括: 【History】按键,浏览该测试用例的历史 【Clone】按键,复制该测试用例,选项如下图: 测试用例执行历史: 附件: Test Run Test Run 是 Testopia 的运动形式。一个 test run 去动态的运行了一系列 test cases(默 认包含了其要检验的对象),从而达到检验对象是否符合设计要求的目的。每个 test run 都要与唯一的 test plan 关联,但是可以多个 test cases。 要创建一个 test run,点击页面下部的链接,即可进入创建页面。 Filter 部分: 该部分用于筛选你所需要的测试用例。 选择测试用例部分: 该部分用于选择你要运行的测试用例。 Test run 的属性部分: 该部分用于设置该 test run 的相关属性。 其中: 名称 描述 Product Version Product 的版本 Plan Version Plan 的版本 Manager 管理员 Build Build 的版本 Status 状态 Environment 环境 Summary 简介 Notes 详细描述 【status】有两个状态: -Running:表示 test run 在运行状态。 -Stopped:表示 test run 在禁止运行状态。 创建完成后: 【CC List】加入 cc 列表中的用户,将会收到 test run 更新的消息。 【History】该 test run 更改的历史。 【Clone】复制该 test run。 运行 Test Run 测试人员的大部分测试时间都工作在一个 Test run 上。在这里,你将判断一个测试用例是 否通过,并记录相对应的 bugs。 等你建立了一个 test run,所有你选择的测试用例都将包含进来。这些测试用例在测试用 例运行表中按行分布。 运行一个测试用例的第一步是设置 build。测试结束后,可以给该用例选择一个状态。这些 状态包括:Idle,Pass,Failed, Running, Pause and Blocked。 Tags Tags 是一个非常有用的对象。通过设定自定义的 tag,用户可以在不打乱原有结构的情况 下重新组织自己风格的结构。通过 tag 我们可以自由的关联 Case,Run 和 Plan。 只需要简单的添加 tag,然后通过 search 功能,就可以非常简单应用它。 Environment Environment 用来定义一个 test run 如何运行。 创建一个 environment 需要两步:第一,创建你可能用到的所有元素;第二步,从这些元 素中,选择你需要的来创建一个 environment。 对于第一次建立起来的 Testopia,你必须在第一步就建立这些 environment。 首先要先建立 Environment 需要的 variables: 主要有四个级别:Category,Element,Property 和 Property Values。 然后创建 Environment: 从右边的列表中,可以直接将你需要的元素拖拽到左边的列表中。 The Testing Life Cycle Testopia 可以适用于任意的开发和测试模式。下面仅仅是一个简单的示例模型。 I.Create a Test Plan 如上所述,在 testopia 中,所有的工作都是围绕 test plan 来完成的。一个典型的测试计 划用来环绕一个单独的产品或者一个产品版本。通过设置 category,build 和 environment 可以搭配出更多的测试场景。 II.Create or Select Test Case 如果你是刚刚开始使用 testopia,你需要为每个测试域创建所需要的测试用例。如果这些 测试用例已经存在,而且你只是创建一个同产品不同版本的测试计划时,就可以通过 clone 这些已有的 cases 来快速的达到目的。在 clone 的时候,你可以增加或者删除,甚至修改 这些用例来满足新的测试计划的特殊需要。 III.Start a Test Run 当你完成了上述工作后,你就可以开始测试工作了。只需创建一个新的 test run,选择加 入那些你想要覆盖的测试用例即可开始。如果需要验证多个不同的 environments 时,你可 以为每个 environment 创建一个 test run。每个test run都关联一个 build。但是如果build 更新过于频繁的时候,也可以将 build 关联到 case 上,减少工作负载。 测试用例在设计时都会默认分配一个测试人员,在运行过程中你可以将其中某些测试用例 重新分配其他测试人员。并且,即便没有分配给一个有修改测试用例权限的测试人员,该 人员也可以更新该测试用例的状态。通过 tested by 列表,我们可以查找该测试用例的真 正更新人员,避免了分歧。 VI.Cleaning UP 一旦一个 test run 中的所有的测试用例都置为 closing 状态(包括 Passed,Failed 和 Blocked),这个test run 就应该从 Running 状态移至 Stopped 状态。当所有 test run 都 完成后,产品也被发布或者达到预定目标后,这个测试计划就可以被置为 archived 状态。 当任何测试用例不再被涉及到,那么也就可以被置为 disabled 状态。 Glossary Action 该测试用例必须完成的步骤集合。 Alias 全局唯一字符串,用来标示一个测试用例,并且和测试用例 ID 关联。 Archive 测试计划可以置为存档状态,将在常规搜索中隐藏。 Arguments 一系列用于发送给自动测试脚本的参数集合。 Assignee 一个负责给运行的测试用例分配状态的人员。 BLOCKED 测试用例的一个状态,表示该测试用例的前驱用例是失败的状态。 Build 在测试中,用于表示处于开发某一阶段的代码版本的字符。 Category 产品的一项属性,用于测试用例的分类。 Clone 一个对象的完全复制,可以复制 plan,run 和 case。 Component Bugzilla 的一个组件,是产品的一项属性。 CONFIRMED 测试用例的一个状态,表示该测试用例可以被使用。 Default Tester 默认执行测试用例的人员。 Dependency 一个测试用例可能依赖于其他测试用例。分为前驱和后继关系。 Depends on 设置该测试用例的前驱测试用例。 DISABLED 测试用例的一个状态,表示该测试用例不能够在测试中使用。 Expected Results 执行完测试步骤后的期望值。 Environment 测试执行时所需要的周边环境。 FAILED 测试用例的一个状态,表示该测试用例在当前环境下运行失败。 IDLE 测试用例的一个状态,表示该测试用例在运行前未经过检查。 Manager 控制 test run 的人员。 Milestone Bugzilla 的对象。产品的一个属性。Build 与之关联。 PASSED 测试用例的一个状态,表示该测试用例在当前环境下运行成功。 PAUSED 测试用例的一个装填,表示该测试用例处于长期运行中的某个阶段。 Plan Document 测试计划的详细描述文档。 Plan version Plan document 的版本,用于特定的 run。 Priority Bugzilla 优先级别。测试用例可以设置和包含的 bug 所处的优先级。 PROPOSED 测试用例的一个状态,表示该测试用例还未被允许参与运行。 Requirement 测试用例的一个域,用于标示该测试用例的特殊需求。 RUNNING 测试用例的一个状态,表示该测试用例可以参与运行。 Running Run 的状态,表示该 run 处于运行状态。 Script 测试用例所用到的脚本文件的路径。 Stopped Run 的状态,表示该 run 处于完成状态。 Tag 用户定制的字符串,用于区分 plan,case 和 run。 Test Case 检测一个特定功能或者对象是否成功达到预定目标所需要的各种状况 和其对应的期望值的集合。可以和一个或者多个测试计划关联,也可 以和任意个(包含零个)test run 关联。 Test Case-Run 测试用例和 test run 的联合体。每次一个测试用例被引入一个新的 test run,将被放置进入一个 test case-run 表。用于表现一个测试 用例在给定的 run 中成功还是失败。每个 case-run 只能以给定状态中 一个和唯一的一个 build 关联。 Test Plan 在 Testopia 中预定义的对象。用于组织其他对象。 Test Run 在 Testopia 中执行的实例。每个run 都和一个单独的测试计划和测试 环境关联。包括一系列需要执行的测试用了以及一个存储测试结果的 case-run 表。 Tested By 真正执行测试用例,并记录其状态的测试人员。 Type 测试计划的类型。每个测试计划只能唯一属于某个类型。
还剩13页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

lkliukai

贡献于2012-07-18

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf