当前位置:文档之家› 用例(UC)文档模板

用例(UC)文档模板

用例(UC)文档模板
用例(UC)文档模板

软件测试用例文档模板(带实例)

软件测试用例模板(带实例) 工程管理系统案例研究项目功能测试用例 编号:Project_MA_Login_1 编号:Project_MA_Interface_3 项目/软件工程管理系统案例研究项目程序版本 1.0.0 功能模块Login 编制人李虎、彭贝贝、唐姣凤用例编号Project_MA_Login_1编制时间 2005-2-22 相关用例Project_MA_Main_1 、Project_MA_Interface_1 、Project_MA_Priority_1 功能特性系统的初始窗体,并进行用户的合法性验证。 测试目的验证是否输入合法的信息,阻止非法登陆,以保证系统的安全特性预置条件数据库中存储了一些用户信息特殊规程说明 (区分大小写) 参考信息需求说明中关于“登录”的说明测试数据用户名= administrators 密码= 1001(数据库表中有相应的信息)操作步骤 操作描述 数据期望结果 实际结果 测试状态(P/F ) 1 选择用户名称,按“提交”按钮。用 户 名 = administrators ,密码为空显示警告信息“帐号 或密码不能为空!” (符合) P 2 选择用户名称,输入错误密码,按 “提交”按钮。用 户 名 为 administrators ,密码=123 显示警告信息 “帐号 或密码不错误!” (符合) P 3 选择用户名称 ,输入密码,按“提交”按钮。 用 户 名 = administrators ,密码 为=1001 进入系统” (符合) P 测试人员 彭贝贝、李绍霞、 唐姣凤 开发人员杨丽娟负责人李虎(手写)

项目/软件工程管理系统案例研究项目程序版本 1.0.0 功能模块Interface编制人李虎、彭贝贝、唐姣凤用例编号Project_MA_Interface_3编制时间2005 – 2– 21 相关用例Project_MA_Interface_1、Project_MA_Interface_2、Project_MA_Priority_1、Project_MA_DBACCESS_1 功能特性维护界面添加操作 测试目的检查维护窗体界面与设计的符合性。 预置条件能够登录进入到系统特殊规程说明(无) 参考信息系统概要设计说明和详细设计说明 测试数据 操作步骤操作描述数据期望结果实际结果测试状态(P/F)1 …………… 2 3 4 5 6 7 8 9 10 11 12 测试人员彭贝贝、李绍霞、 唐姣凤开发人员杨丽娟负责人李虎(手写)

手机APP产品测试用例实例与模版

中国电信XXX项目 功能测试用例 撰稿人:XX XXX信息网络有限责任公司 2013年X月XX日

目录 1.概述----------------------------------------------------------------------------------------------------------------- 3 1.1编写目的---------------------------------------------------------------------------------------------------------- 3 1.2读者对象---------------------------------------------------------------------------------------------------------- 3 1.3参考资料---------------------------------------------------------------------------------------------------------- 3 2.ANDROID测试用例-------------------------------------------------------------------------------------------- 4 2.1登陆/注册--------------------------------------------------------------------------------------------------------- 4 2.2文件上传---------------------------------------------------------------------------------------------------------- 4 2.3文件收藏---------------------------------------------------------------------------------------------------------- 5 2.4文件删除/还原 -------------------------------------------------------------------------------------------------- 5 2.5文件重命名 ------------------------------------------------------------------------------------------------------ 6 2.6文件移动---------------------------------------------------------------------------------------------------------- 7 2.7文件分享---------------------------------------------------------------------------------------------------------- 7 2.8图片浏览---------------------------------------------------------------------------------------------------------- 8 2.9相册备份---------------------------------------------------------------------------------------------------------- 8 2.10私密空间 -------------------------------------------------------------------------------------------------------- 9 2.11设置 ------------------------------------------------------------------------------------------------------------ 10 2.12客户端安装/升级-------------------------------------------------------------------------------------------- 10

软件测试用例实例[非常详细]

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不 同的软件组合,从而占用不同的资源。 Win dowXp Win dow2000(P) Win dow2003 用例编号TestCase_Li nkWorks_WorkEvaluate 项目名称Li nkWorks 模块名称WorkEvaluate 模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本:版本/状态作者参与者起止日期备注 V1.1 1.1. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内 存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享 资源(如数据库锁或网络带宽)而造成的。强 度测试还可用于确定测试对象能够处理的最大工作量。 测试目的 测试说明

前提条件连续运行8小时,设置添加10用户并发 测试需求输入/动作输出/响应是否正常运行 功能1 2小时 4小时6小时 8小时 2小时 功能1 4小时 6小时8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务 规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI (图形用户界面)与应用程序交互,对 交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

用例模板

4.2 体检业务子系统 4.2.1 用例模型 在3.2小节的分析基础上,我们可以抽象出如图16所示的用例模型: (from 1-体检人申请体检) 综合科医生 ) (from 1-体检人申请体检) 体检医生 开单 (from 1-体检人申请体检 ) ) 处理改单 (from 2-体检人中途改单) (from 3-财务部门提交公司客户缴费情况 ) 财务人员 (from 4-客服中心查询体检情况) 客服中心 (from 6-系统通知体检者领取报告) Timer :体检已完成 管理体检项 体检业务增长分析报表 (from 1-体检业务周期统计报表) 体检业务周期统计报表 (from 1-体检业务周期统计报表) 体检部门管理人员

4.2.1.1 服务人员 1、开单(UC_B_TJ_KaiDan) 1、概述 ?用例名称:开单 ?编号:UC_B_TJ_KaiDan ?参与者:服务人员 ?用例概述:服务人员根据体检者的选择或预约单开具体检单,并打印出来交给体检 者。 ?相关 2、事件流 ?前置条件:无 ?后置条件:确保没有重复的体检项目 ?基本事件流: 1.参与者输入用户姓名或预约号,系统确认用户已经预约,并从预约单中获取体检套 餐与体检项目显出在屏幕上; 2.系统确认用户选择的体检套餐与体检项目符合要求(参见规则UC_KD_01); 3.系统保存并打印体检单。 ?备选(扩展)事件流: 1a. 参与者或系统确认用户没有预约 1a1. 参与者输入用户基本信息,并根据用户选择输入体检餐套与体检项 目信息; 1b. 系统发现有多个可能重名的预约用户 1b1.系统显示出所有可能重名的预约用户,并显示区分身份的主要信息; 1b2.参与者从中选择符合的预约用户,并从相应的预约单中调出数据。 2a.用户选择的体检套餐不符合要求 2a1. 系统给出具体的提示信息,并且阻止参与者完成体检单 ?异常事件流: 3a.系统保存或打印失败 3a1. 系统仍然显示信息录入界面,并提示失败原因 3b. 用户发现打印失败 3b1. 系统已退出信息录入界面,参与者可切换到历史体检单界面,重新 打印已保存的体检单 3、相关需求 ?用户原始需求: ●通过输入预约号或姓名可查询是否预约,如果有重名则应该都显示; ●体检者选择的体检项目若属于已选择的体检套餐,则应提示并说明对应套餐; ●如果发现打印出来的体检单不清晰,系统能够支持重新打印的功能。 ●……

用例分析文档模板

文档名称版本<1.0 >

文档属性及版本

目录 1用例:<用户登录> (4) 1.1用例图 (4) 1.2简要说明 (4) 2事件流 (4) 2.1基本流 (4) 2.2备选流 (4) 3用例场景 (5) 3.1成功场景 (5) 3.2失败场景 (5) 4特殊需求 (5) 4.1总体要求 (5) 4.2用例要求 (5) 5前置条件 (5) 6后置条件 (5) 7扩展点 (5) 7.1新用户注册 (5)

1用例:<用户登录> 1.1用例图 1.2简要说明 此用例主要描述XXXXXX系统的用户登录。由于XXXXXX系统是基于用户许可授权访问的系统,在用户访问该系统时,首先要通过合法的用户身份验证,其次要控制用户对系统资源的访问权限。根据XXXXXX系统的实际应用需求,该系统的用户分为两种类型:一种是一般用户,另一种是特殊用户。不同类型的用户具有不同的访问权限。 2事件流 用户在浏览器地址栏输入系统的URL(网址),该用例启动。 2.1基本流 1.进入登录页面 如果用户没有通过身份验证,则在浏览器地址栏内访问任何一个页面的URL都自动进入登录页面。 2.输入用户名和密码 系统提示用户名和密码必须输入。用户名符合数据结构要求,密码符合密码长度以及复杂度等要求。 3.选择“登录”操作 系统验证用户输入数据的合法性,进而验证是不是合法的系统用户以及用户的权限(一般用户、特殊用户)。 4.进入系统主页面。 2.2备选流 A1.用户和密码输入 在基本流的步骤3,提示用户输入合法的用户名和密码。 A2.用户或密码错误 在基本流的步骤3中,用户输入的用户名或者密码错误,提示用户重新输入。然后继续执行基本流的步骤3。三次输入用户名和密码无效后,该用户被锁定,用例结束。 A3.退出系统

测试用例模板实例

sample ┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓┃用例编号│BOSS_ FS_ MARKETING_NEW_01P ┃┠──────┼───────────────────────────┨┃测试优先级│高(还有“较高、中、较低、低”几个等级)┃┠──────┼───────────────────────────┨┃用例摘要│新增营销记录┃┠──────┼───────────────────────────┨┃测试类型│功能性测试(对应还有“安全性测试”等)┃┠──────┼───────────────────────────┨┃用例类型│基本事件(对应还有“备选事件”、“异常事件”)┃ ┠──────┼───────────────────────────┨┃用例设计者│songfun ┃┠──────┼───────────────────────────┨┃设计日期│2005-04-25 ┃┠──────┼───────────────────────────┨┃对应需求编号│REQ_ MARKETING_NEW_01 ┃┠──────┼───────────────────────────┨┃对应UI │Marketing.htm ┃┠──────┼───────────────────────────┨┃对应UC │UC_ MARKETING_NEW_01 ┃┠──────┼───────────────────────────┨┃版本号│Build v0.1 ┃┠──────┼───────────────────────────┨┃对应开发人员│Frank ┃┠──────┼───────────────────────────┨┃前置条件│操作员登录营销管理系统┃┠──────┼───────────────────────────┨┃测试方法│等价类划分(对应还有“错误猜测法”、“边界值分析”等)┃ ┠──────┼───────────────────────────┨┃输入数据│用户名:51testing 性别:男金额:10元描述:aaaaaaa ┃┠──────┼───────────────────────────┨┃执行步骤│①.进入【营销下发】页面;┃┃│②.点击『增加』按钮;┃┃│③.输入相应数据;┃┃│④.点击『确定』按钮;┃┃│⑤.在后台数据库(test/test@testDB)输入查询语句验证:┃┃│select * from MarketingTab where ID='1001' ┃┃│┃┠──────┼───────────────────────────┨┃预期输出│㈠.执行步骤④后,页面弹出添加成功提示信息框;┃┃│㈡.执行步骤⑤后查询数据库,记录确实添加成功且数据无误┃┃│┃

测试用例模板

XXXX项目/平台 测试用例 版本历史 目录 一、引言 ............................................................... 1.1文档目的........................................................ 1.2读者对象........................................................ 1.3术语与缩写解释.................................................. 二、测试说明 ........................................................... 2.1功能相关参考文档................................................ 2.2测试范围与目的.................................................. 2.3测试环境........................................................

2.4测试工具........................................................ 2.5测试用例........................................................ 2.5.1 功能一...................................................... 2.5.2 功能二...................................................... 一、引言 1.1文档目的 文档的编写目的 1.2读者对象 文档的读取对象 1.3术语与缩写解释 二、测试说明 2.1功能相关参考文档 ?用户需求说明书 ?概要设计说明书

用例描述模板

实验一编写用例(以下给出用例描述模板),并画出用例图(编写时可参照下面的实例) 用例描述模板 是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。写出用例是一种最好的理解和描述需求的技巧。 注意:这个模板列出可以定义用例的典型标题,但应当强调的是,实用上更重要的是专注于写出完整的可理解的事件路径,而不是按指定的模板填写每个部分。 名称 用例的名称应当用简短的动词短语表达,说明用户使用用例完成的任务。 概述或简要描述 单列一节概述该用例完成什么通常是有益的。 参与者 列出此用例涉及的参与者和负责发起此用例执行的主要参与者。 触发器 触发器是开始此用例的事件。触发者并不必须向该系统输入事件,例如,在预约系统示例中,“预约”用例的触发者可能是“一个潜在的客户打给餐馆的一个预约电话”。而在另一种情况下,触发者可能是此用例中第一个系统事件。 前置条件 前置条件概述在用例可以开始前,什么必须为真。通常前置条件说明在指定的一个用例运行前,另一个什么用例必须运行。典型的前

置条件可以是“用户已成功登陆”。 后置条件 后置条件概述当用例完成时什么是真。在许多情况下,这将依赖于在一个特定用例实例中发生的确切的一系列交互。区分“最低保证”和“成功保证”可能是实用的,前者描述在所有情况下发生什么和不发生什么,后者描述如果正常的事件路径成功地完成将会发生什么。 事件路径或脚本 基本的或正常的事件路径,通常应当作为不中止的交互序列出现。对事件路径中的交互通常加以编号,以便于以后的参考。 可选和例外事件路径 可选和例外事件路径可以完整地写出。然而通常只须在基本事件路径中的分叉点简单地指明可选事件流,对行为可能改变的位置予以编号,并指明导致分叉的事件。 扩展点 这一节应当列出在事件路径中可能发生扩展的位置,并给出确定扩展是否发生的条件或事件。扩展本身应当作为单独的用例写出;否则,可以指明可选的事件路径。 例如,订餐系统中“记录未预约顾客”的用例可以作为“记录达到”用例的扩展。(因为在“记录未预约顾客”中指定的交互不是在每次执行“记录达到”时都执行) 包含 这一节简单地概述包含在已定义的用例中的用例。在哪些地方包

测试用例模板示例

OA办公自动化系统 销售管理子系统 测试用例 目录 测试用例名称:OA系统销售管理子系统我的客户管理添加模块 (2) 测试用例名称:OA系统销售管理子系统我的客户管理管理模块 (4) 测试用例名称:OA系统销售管理子系统我的客户管理高级管理模块 (5) 测试用例名称:OA系统销售管理子系统我的客户管理共享客户模块 (6) 测试用例名称:OA系统销售管理子系统我的联系人管理添加模块 (7) 测试用例名称:OA系统销售管理子系统我的联系人管理管理模块 (9) 测试用例名称:OA系统销售管理子系统我的客户管理高级管理模块 (10) 测试用例名称:OA系统销售管理子系统我的联系人管理共享客户模块 (11) 测试用例名称:OA系统销售管理子系统销售管理产品信息添加模块 (12) 测试用例名称:OA系统销售管理子系统销售管理产品信息产品管理模块 (14) 测试用例名称:OA系统销售管理子系统销售管理产品信息高级查询模块 (16) 测试用例名称:OA系统销售管理子系统销售管理服务型产品添加模块 (17) 测试用例名称:OA系统销管理子系统销售管理服务型产品服务销售管理模块 (19) 测试用例名称:OA系统销售管理子系统销售管理服务型产品高级查询模块 (21) 测试用例名称:OA系统销售管理子系统销售管理销售合同管理添加模块 (22) 测试用例名称:OA系统销售管理子系统销售管理销售合同管理合同管理模块 (25) 测试用例名称:OA系统销售管理子系统销售管理销售合同管理高级查询模块 (26) 测试用例名称:OA系统销售管理子系统销售管理产品销售记录添加模块 (27) 测试用例名称:OA系统销售管理子系统销售管理产品销售记录产品销售管理模块 (29) 测试用例名称:OA系统销售管理子系统销售管理产品销售记录高级查询模块 (30) 测试用例名称:OA系统销售管理子系统销售管理服务销售记录添加模块 (31) 测试用例名称:OA系统销售管理子系统销售管理服务销售记录服务销售管理模块 (33) 测试用例名称:OA系统销售管理子系统销售管理产品销售记录高级查询模块 (34)

CMMI5文档之集成测试用例模板

×××××× 项目集成测试用例模板文档编号:FHI_CMMI_VER_TEM_TUC 文档信息:集成测试用例模板 文档名称:集成测试用例模板 文档类别:CMMI模板 密级:内部秘密 版本信息:1.1 建立日期:2016-1-5 创建人:EPG 批准人:李庆林 批准日期:2016.2.25 存放位置:集成公司组织资产库/组织标准过程 编辑软件:Microsoft Office 2003 中文版

文档修订记录(引用时请修改为实际项目的信息) 版本编号或者更改记录编号*变化 状态 简要说明(变更内容和变更范 围) 日期变更人批准日期批准人 V1.0 C 创建2016-1-5 张娜娜2016-2-25 李庆林V1.1 M 文档编号去掉版本号2016-4-17 邓沛沛2016-4-17 李庆林 *变化状态:C――创建,A——增加,M——修改,D——删除

目录 4 1.产品/项目信息.................................................................................................................. 4 2.集成测试用例设计........................................................................................................... 4 1.1集成内容描述..................................................................................................... 4 1.2类协作关系描述................................................................................................. 4 1.3对外接口描述..................................................................................................... 5 1.4测试用例.............................................................................................................

测试用例模板(完整版)

用例编号XXX-XXX-XXXX 项目名称XXXX 模块名称XXXX模块 项目承担部门XXXX部 用例作者 完成日期2014-12-24 本文档使用部门XXXX部 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本: 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则

的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。

二、性能测试 性能测试是一种对响应时间、事务处理速率和其他与时间相关的需求进行测试和评估。性能测试的目标是核实性能需求是否都已满足。可以分为以下几种进方式来组织进行测试。 1.1.预期性能测试用例 通常系统在设计前会提出一些性能指标,这些指标是性能测试要完成的首要工作,针对每个指标都要统写多个测试用例来验证是否达到要求,根据测试结果来改进系统的性能。预期性 1.2.用户并发测试用例 用户并发测试是性能测试最主要的部分,主要是通过增加用户数量来加重系统负担,以检

1.3.大数据量测试用例 大数据量测试是测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。大

1.4.疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强 1.5.负载测试测试用例 负载测试也是性能测试中的一种。在这种测试中,将使测试对象承担不同的工作量,以评测

软件需求文档模板

版本说明编制批准批准日期 1.1 初次编写SEPG 目录 1. 引言1 1.1. 背景1 1.2. 参考资料1 1.3. 假定和约束1 1.4. 用户的特点1 2. 功能需求1 2.1. 系统范围1 2.2. 系统体系结构(二层架构的系统可剪裁本小节)1 2. 3. 系统总体流程2 2.4. 需求分析2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述2 2.4.1.2. 业务建模2 2.4.1. 3. 用例描述3 2.4.1.4. 用户界面5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求5 3.1. 性能要求5 3.1.1. 精度5 3.1.2. 时间特性要求6 3.1.3. 输人输出要求6 3.2. 数据管理能力要求6 3.3. 安全保密性要求6 3.4. 灵活性要求6 3.5. 其他专门要求6 4. 运行环境规定6

4.2. 支持软件7 4.3. 接口7 4.4. 控制7 5. 需求跟踪7 6. 签批单7 1. 引言 1.1. 背景 说明: a.待开发的软件系统的名称; b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络; C.该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2. 参考资料 列出本说明书中引用和参考的资料,如: a.本项目的经核准的计划任务书或合同、上级机关的批文; b.属于本项目的其他已发表的文件; c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。 1.3. 假定和约束[可选] 列出进行本软件开发工作的假定和约束,例如经费限制、开发期限、设备条件、用户的资料准备和交流上的问题等。 1.4. 用户的特点[可选] 列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使用频度。这些是软件设计工作的重要约束。 2. 功能需求 2.1. 系统范围 明确概要地说明用户对系统、产品高层次的目标要求,如系统开发的意图、应用目标、作用范围以及其他相关的背景材料。 如果所定义的产品是一个更大系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系

最全面的测试用例模板

当前位置:首页 -> 资讯详细内容 最全面的测试用例模板 { 项目名称 } 测试用例标题 文件状态:[√] 草稿 [ ] 正式发布[ ] 正在修改文件标识:Company-Project-IT-PLAN 当前版本:X.Y 作者: 完成日期:Year-Month-Day 版本历史 版本/状态作者参与者起止日期备注 目录 0. 文档介绍 0.1 文档目的 0.2 文档范围 0.3 读者对象 0.4 参考文献 0.5 术语与缩写解释 1. 接口-路径测试用例 1.1 被测试对象(单元)的介绍 1.2 测试范围与目的

1.3 测试环境与测试辅助工具的描述1.4 测试驱动程序的设计 1.5 接口测试用例 1.6 路径测试的检查表 2. 功能测试用例 2.1 被测试对象的介绍 2.2 测试范围与目的 2.3 测试环境与测试辅助工具的描述2.4 测试驱动程序的设计 2.5 功能测试用例 3. 健壮性测试用例 3.1 被测试对象的介绍 3.2 测试范围与目的 3.3 测试环境与测试辅助工具的描述3.4 测试驱动程序的设计 3.5 容错能力/恢复能力测试用例 4. 性能测试用例 4.1 被测试对象的介绍 4.2 测试范围与目的 4.3 测试环境与测试辅助工具的描述4.4 测试驱动程序的设计 4.5 性能测试用例 5. 图形用户界面测试用例 5.1 被测试对象的介绍 5.2 测试范围与目的 5.3 测试环境与测试辅助工具的描述5.4 测试驱动程序的设计

5.5 测试人员分类 5.6 用户界面测试的检查表 6. 信息安全性测试用例 6.1 被测试对象的介绍 6.2 测试范围与目的 6.3 测试环境与测试辅助工具的描述6.4 测试驱动程序的设计 6.5 信息安全性测试用例 7. 压力测试用例 7.1 被测试对象的介绍 7.2 测试范围与目的 7.3 测试环境与测试辅助工具的描述7.4 测试驱动程序的设计 7.5 压力测试用例 8. 可靠性测试用例 8.1 被测试对象的介绍 8.2 测试范围与目的 8.3 测试环境与测试辅助工具的描述8.4 测试驱动程序的设计 8.5 可靠性测试用例 9. 安装/反安装测试用例 9.1 被测试对象的介绍 9.2 测试范围与目的 9.3 测试环境与测试辅助工具的描述9.4 测试驱动程序的设计 9.5 安装/反安装测试用例 附录:评审意见

相关主题
文本预览
相关文档 最新文档