Ready Test? Go, Go, Go !!!
 

关注测试,也关注成长

公告
  • 关注软件测试自动化,性能测试。
    目前负责医疗软件功能测试以及
    测试过程改进

日历
<2007年11月>
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678
统计
  • 随笔 - 22
  • 文章 - 0
  • 评论 - 87
  • 引用 - 0

导航

常用链接

留言簿(17)

随笔分类

随笔档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜

 
 

ü         Architecture(体系结构)一个系统在其环境中的最高级别的概念(IEEE)。软件系统(在某一给定时刻)的体系结构是通过接口互相联系的主要组件的组织方式或结构,这些组件相应的是由更小的组件和接口构成的。

ü         Artifact(产物)某过程所创建的任何产品、交付物或文档。

ü         Build(构建版本)一个构建版本由一个或多个组件(通常是可执行的)组成,每一个组件通常又由其他组件通过编译和连接源代码而构成。

ü         Component(组件)系统中的一个实际的可替换的部分,它包括功能的实现、提供并配合接口的实现。

ü         DataDriven Testing(数据驱动测试)这是一种测试脚本的功能及执行由外部数据所引导的自动测试方法。这种方法将测试及控制数据与测试脚本本身分离开了。

ü         Functional Decomposition Approach(功能分解方法)这是一种将测试用例缩减为基本任务、导航、功能测试、数据验证和返回导航的自动化测试方法,也称作框架驱动方法(FrameworkDriven Approach)。

ü         Key WordDriven Testing(关键字驱动测试)这种方法是由SAS研究所的Carl Nagle开发的,并作为自由软件发布在互联网上。关键字驱动测试是数据驱动方法学的提高。

ü         Performance Testing(性能测试)通过这类测试的实现和执行可以对索要测试的应用程序与性能相关的特征作出描绘和评估。这些测试包括时间调度情况、执行流畅、响应时间以及操作可靠性和限制。

ü         Procedure(程序)当执行一个任务时所要遵循的行动过程的文档化描述,通过遵循这种一步接一步的方法可以保证达到各项标准。

ü         Process(过程)可活动产品或服务的一系列步骤;可生成出产品或服务的劳动。

ü         Process Control(过程控制)保持产品或服务符合规格说明的自我调节操作。

ü         Product(产品)某个过程所创建的任何产物、交付物以及文档。

ü         Rational ClearCase  Rational公司提供的配置管理软件

ü         Rational ClearQuest 这是Rational公司提供的跟踪缺陷及需要更改管理系统。

ü         Rational Robot RobotRational Suite TestStudio 2001软件的捕获/回放组件。

ü         Rational TestManager  TestManagere Rational公司提供的管理所有测试活动-计划、设计、实现、执行和分析-的中心控制台。

ü         Rational Unified Process 这是Rational公司提供的软件工程过程,此过程为在一个开发组织中分配任务和责任提供了严谨的方法。

ü         Specifications(规格说明)为客户提供的产品和服务时期望能达到的标准。

ü         Test Artifact Set(测试产物集)搜集和形成与所进行测试相关的信息。

ü         Test Case(测试用例)时一套为特定目标开发的测试输入、执行条件和预期结果,例如执行一跳特殊程序路径或者在特定要去下验证一致性。

ü         Test Condition(测试条件)测试所涉及的各种环境因素。

ü         Test Data(测试数据)在测试中所用到的实际数值或执行测试所必须的数值。测试数据是测试条件(作为输入或预存在的数据)的具体例化,用于验证已成功实现的特定要求(通过将实际结构与期望结果比较)。

ü         Test Inputs(测试输入)是工作过程的产物,用于标志和定义发生在测试期间的动作。这些产物可能是从测试组之外的软件开发过程中产生的,例如功能需求规格说明和设计规格说明。它们也可能是从前期测试阶段产生的并被留给了后续的测试活动。

ü         Test Plan(测试计划)包括项目中的测试目标和目的的信息。此外,测试计划还明确了测试实现的策略和所需要的资源。

ü         Test Procedure(测试程序)是一套详细的指示,用于某特定测试用例(或一套测试用例)的建立、执行和结构评估。

ü         Test Requirement(测试需求)是关于某具体测试目标的声明以及确认测试是否通过所要达到的标准。

ü         Test Results(测试结果)执行测试所捕获的数据,并被用于计算测试的不同关键测度。

ü         Test Script(测试脚本)这是计算机可读懂的能令测试程序(或一部分测试程序)自动执行的指令。测试脚本可以由人创建(复制)或者由自动测试工具产生,它使用编程语言限制,或者由记录、生成和编程混合创建。

ü         Test Strategy(测试策略)描述了测试获得的通用目标合方法。

ü         Test Suite(测试套件)是指在执行时将某一测试场景具体化的一套测试。

ü         Test Workspace(测试工作区)这是测试者的“私有”区域,在这里测试者能够根据项目采用的标准对代码进行安装和测试,从而与开发人员保持了相对的隔离。

Resource:《Just Enough Software Test AutomationDaniel JMosley

《软件测试自动化》邓波等译 机械工业出版社

posted on 2007-11-23 14:35 Cinderella 阅读(1439) 评论(1)  编辑  收藏 所属分类: 基本技能功能测试他山之玉
评论:
  • # 不错  楷子狐 Posted @ 2008-01-10 19:35
    目前公司不需要英语,英语也早丢回家了 :)  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 
 
Copyright © Cinderella Powered by: 博客园 模板提供:沪江博客