[活动]迎五一，庆周年，盖高楼(活动结束)

walker1020

功能测试流程
•        测试计划：确定测试的具体目标，确定测试的入口条件和出口条件，进行风险评估，选定测试流程，选定测试工具软件，制定测试计划，搭建测试管理系统
•        测试需求：撰写测试需求，评审测试需求
•        测试用例：设计测试用例，评审测试用例，制定自动化方案 ，设计自动化测试脚本
•        部　　署: 部署被测系统，进行冒烟测试
•        执　　行：执行测试，提交缺陷，回归测试
•        总　　结：测试用例有效性分析，缺陷密度分析，缺陷衰减趋势分析

walker1020

在独立可测试的软件中（模块、程序、对象和类等）,可以通过组件测试发现缺陷，以及验证软件功能。根据开发生命周期和系统的背景，组件测试可以和系统的其他部分分开，单独进行测试。在组件测试过程中，会使用到桩、驱动器和模拟器(simulators)。
组件测试可能包括功能测试和特定的非功能特征测试，比如资源行为测试（如内存泄漏）或健壮性测试和结构测试（比如分支覆盖）。根据工作产品如，组件规格说明、软件设计或数据模型等，来设计测试用例。
通常，通过开发环境的支持，比如组件测试框架或调试工具(debugging tool)，组件测试会深入到代码中，而且实际上设计代码的开发人员通常也会参与其中。在这种情况下，一旦发现缺陷，就可以立即进行修改，而不需要正式的事件记录。
组件测试的一个方法是在编写代码之前就完成编写和自动化了测试用例。称之为测试优先的方法或测试驱动开发。这是个高度迭代的方法，并且取决于如下的循环周期：测试用例的开发、构建和集成小块的代码，执行组件测试直到它们全部通过。

walker1020

在任何生命周期模型中，一个好的测试都应该具有下面几个特点：
  每个开发活动都有相对应的测试活动；
  每个测试级别都有其特有的测试目标；
  对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计；
  在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审。

walker1020

可以将软件或系统的输入分成不同的组，对于同一个组的输入，软件或系统应该有相似的表现行为，就好像系统是以相同的方式对这些输入值进行处理。等价类划分（或等价类）可以分为两种类型的数据：有效数据和无效数据(即应该被系统拒绝的数据)。等价类划分也可以基于输出、内部值、时间相关的值（例如在事件之前或之后）以及接口参数（在集成测试阶段）等进行。可以设计测试用例来覆盖不同的等价类。等价类划分可以应用在所有测试级别上。
通过应用等价类划分技术，能够实现输入覆盖和输出覆盖。它同样适用于人为的输入、通过系统接口的输入以及集成测试中的接口参数。

walker1020

在各等价类划分的边界通常更可能出现不正确的行为，因此边界就是测试较可能发现缺陷的区域。每个划分的最大和最小值就是它的边界值。有效部分的边界就是有效边界值，无效部分的边界就是无效边界值。测试的设计应当既覆盖有效边界值又覆盖无效边界值。在设计测试用例时，应该将每个边界值包含在测试用例中。
边界值分析可以应用于所有的测试级别。这种方法的应用相对简单，发现缺陷的能力也比较高，同时，详细的规格说明对边界值分析很有帮助。
边界值分析技术通常被认为是等价类划分技术的一种拓展。它可以应用在用户从屏幕输入的等价类中，也可以应用在如时间段的范围（如超时、对于事务处理速度的需求）或表的范围（如表的大小是256*256）等方面。边界值同样可以用于选择测试数据。

walker1020

风险通常可以用来决定从什么地方开始测试，什么地方需要更多的测试。测试可以用来降低风险或可以减少负面事件的影响。

walker1020

产品风险对于项目的成功来讲是一种特殊类型的风险。作为一种风险控制活动，测试通过评估修复严重缺陷的能力和应急计划的有效性来提供关于残留风险的反馈信息。

walker1020

迭代-增量开发模型(iterative-incremental development model)由需求建立、设计、构建和测试等一系列相对较短的开发周期构成。比如：原型开发、快速应用开发（RAD）、统一软件开发过程（RUP）和敏捷开发模型等。作为其开发的一部分，迭代产生的系统需在不同的测试级别上进行测试。通过将增量模块加入到以前开发的模块中，形成一个渐渐增大的系统，这个系统同样需要进行测试。在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。验证和确认可以在每个增量模块中进行。

walker1020

Alpha测试(alpha testing)、Beta测试(beta testing)、组件测试(component testing)（也称为单元测试、模块测试或程序测试）、驱动器(driver)、现场测试(field testing)、功能需求(functional requirement)、集成(integration)、集成测试(integration testing)、非功能需求(non-functional requirement)、健壮性测试(robustness testing)、桩(stub)、系统测试(system testing)、测试级别（test level）、测试驱动开发(test-driven development)、测试环境(test environment)、用户验收测试(user acceptance testing)。

walker1020

集成测试是对组件之间的接口进行测试，以及测试一个系统内不同部分的相互作用，比如操作系统、文件系统、硬件或系统之间的接口。

walker1020

对于集成测试，可以应用多种集成级别，也可以根据不同的测试对象规模采用不同的级别，比如：
􀁺 组件集成测试对不同的软件组件之间的相互作用进行测试，一般在组件测试之后进行。
􀁺 系统集成测试对不同系统之间的相互作用进行测试，一般在系统测试之后进行。在这种情况下，开发组织/团体通常可能只控制自己这边的接口，所以变更可能是不稳定的。按照工作流执行的业务操作可能包含了一系列系统，因此跨平台的问题可能至关重要。

集成的规模越大，就越难在某一特定的组件或系统中定位失效，从而增加了风险。
系统化集成的策略可以根据系统结构（例如自顶向下或自底向上）、功能任务集、事务处理顺序或系统和组件的其他方面等来制定。为了减少在生命周期后期才发现缺陷而产生的风险，集成程度应该逐步增加，而不是一下子将系统集成为“巨无霸”来进行测试。
测试特定的非功能特征（比如性能）也可以包含在系统集成测试中。
在集成的每个阶段，测试员只是把精力集中在集成本身。举例来说，假如集成模块A和模块B，测试人员是应该关注两个模块之间的交互，而不是每个模块的功能。功能测试和结构测试方法都可以应用在集成测试。
在理想情况下，测试员应该理解系统的架构，从而可以影响相应的集成计划。假如集成测试计划是在组件或系统生成之前制定，则可以根据对集成最有效率的顺序来进行设计。

walker1020

系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行为。
在系统测试中，测试环境应该尽量和最终的目标或生产环境相一致，从而减少不能发现和环境相关的失效的风险。
系统测试可能包含基于不同方面的测试：根据风险评估的、根据需求规格说明的、根据业务过程的、基于用例(use case)的、或根据其他对系统行为的更高级别描述的、根据与操作系统的相互作用的、根据系统资源的等。
系统测试应该对系统功能和非功能需求进行研究。需求可以以文本形式或模型方式描述。同时测试员也需要面对需求不完全或需求没有文档化的情况。功能需求的系统测试开始时可以选择最适合的基于规格说明的测试即黑盒(black-box)技术来对系统进行测试。比如：可以根据业务准则描述的因果组合来生成决策表(decision table)。基于结构的技术(structure-based technique)即白盒（white-box）测试技术，可以评估测试的覆盖率，可以基于评估覆盖一个结构元素，如菜单结构或者页面的导航等的完整性

walker1020

验收测试通常是由使用系统的用户或客户来进行，同时系统的其他利益相关者也可能参与其中。

walker1020

用户验收测试
验证由商业用户使用一个系统的可用性。

walker1020

Alpha和Beta（或现场（field））测试
在软件产品正式商业销售之前，市场或商业现货软件开发人员希望从市场中潜在的或已经存在的客户中得到关于软件的反馈信息。Alpha测试通常在开发组织现场进行。Beta测试或实地测试，通常在用户现场进行。两者都由潜在的客户进行测试，而不是由产品的开发者进行测试。
有些组织也可能使用不同的术语，比如在系统正式移交给客户之前或之后进行的测试分别称为工厂验收测试和现场验收测试(site acceptance testing)等。

walker1020

系统、子系统或组件要实现的功能可以在工作产品中，如需求规格说明书、用户用例或功能规格说明书予以描述，不过也可能没有相应的文档。功能指的是系统能做什么。
功能测试基于功能和特征（在文档中描述的内容或测试员自己的理解）以及专门的系统之间的交互，可以在各个级别的测试中进行（例如组件测试可以基于组件的规格说明书）。
可以采用基于规格说明的技术，根据软件或系统的功能来设计测试条件和测试用例（参见第4章）。功能测试主要是考虑软件的外部表现行为（黑盒测试）。
安全性测试就是功能测试的一种，它会对安全性相关的功能（比如防火墙）进行测试，从而检测系统和数据是否能抵御外部恶意的威胁，如病毒等。互操作性测试是另一种功能性测试，评估软件产品与其他一个或多个组件或系统交互的能力。

walker1020

可以在任何测试级别上进行结构测试（白盒测试）。结构测试技术最好在进行基于规格说明的测试之后使用，以便通过评估结构类型的覆盖，来测量测试的完整性。
覆盖(coverage)是指通过测试套件检验的结构的程度，以覆盖项(item)的百分比来表示。假如覆盖率不是100％，可能需要设计更多的测试用例，来测试被遗漏的项，从而提高测试的覆盖。有关覆盖技术参见第4章。
在所有的测试级别，特别是在组件测试和组件集成测试中，可以利用工具来测量单元代码的覆盖，比如语句覆盖(statement coverage)和判定覆盖(decision coverage)。结构测试可以基于系统的结构，比如调用层次结构。
结构测试方法也可以运用到系统、系统集成或验收测试级别（比如业务模型或菜单结构）。

walker1020

Acceptance Testing－－可接受性测试
一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。

actual outcome－－实际结果        
被测对象在特定的条件下实际产生的结果。

Ad Hoc Testing－－随机测试        
测试人员通过随机的尝试系统的功能，试图使系统中断。

algorithm－－算法        
（1）一个定义好的有限规则集，用于在有限步骤内解决一个问题；（2）执行一个特定任务的任何操作序列。

algorithm analysis－－算法分析        
一个软件的验证确认任务，用于保证选择的算法是正确的、合适的和稳定的，并且满足所有精确性、规模和时间方面的要求。

Alpha Testing－－Alpha测试        
由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。

walker1020

analysis－－分析        
（1）分解到一些原子部分或基本原则，以便确定整体的特性；（2）一个推理的过程，显示一个特定的结果是假设前提的结果；（3）一个问题的方法研究，并且问题被分解为一些小的相关单元作进一步详细研究。

anomaly－－异常        
在文档或软件操作中观察到的任何与期望违背的结果。

application software－－应用软件        
满足特定需要的软件。

architecture－－构架        
一个系统或组件的组织结构。

ASQ－－自动化软件质量（Automated Software Quality）
使用软件工具来提高软件的质量。

assertion－－断言        
指定一个程序必须已经存在的状态的一个逻辑表达式，或者一组程序变量在程序执行期间的某个点上必须满足的条件。

assertion checking－－断言检查        
用户在程序中嵌入的断言的检查。

walker1020

Backus-Naur Form－－BNF范式        
一种分析语言，用于形式化描述语言的语法

baseline－－基线        
一个已经被正式评审和批准的规格或产品，它作为进一步开发的一个基础，并且必须通过正式的变更流程来变更。

Basic Block－－基本块        
一个或多个顺序的可执行语句块，不包含任何分支语句。

basis test set－－基本测试集        
根据代码逻辑引出来的一个测试用例集合，它保证能获得100%的分支覆盖。

behaviour－－行为        
对于一个系统的一个函数的输入和预置条件组合以及需要的反应。一个函数的所有规格包含一个或多个行为。

benchmark－－标杆/指标/基准        
一个标准，根据该标准可以进行度量或比较。