ISTQB初级认证-知识点及脑图总结

前言

此文章为本人利用课余时间进行的ISTQB初级认证知识和考点的总结。总结过程主要参考了“ISTQB测试人员认证初级大纲（2011版）”，由于作者能力与精力有限，此篇文章可能会存在纰漏，望见谅并及时指出。谢谢！

ISTQB思维脑图

上图中红色字体部分为重要考点和易错点。

ISTQB（初级）知识和考点总结

软件测试基础(1)

为什么需要测试(1.1)

• 缺陷带来的危害(1.1.1)

  • 资金受损

  • 时间受损

  • 信誉受损

  • 人员伤亡

• 测试基本术语(1.1.2)

  • 【人为】错误（Error, Mistake）

  • 【内在】缺陷（Defect，Bug，Fault）

  • 【外部】失效（Failure）

    • 当存在缺陷的代码被执行时引发缺陷（即发现缺陷必须要运行软件）
    • 失效也可能是由于环境条件引起的

• 测试和调试的区别
  调试和测试是两个不同的概念。动态测试可以发现由于软件缺陷引起的失效。而调试是一种发现，分析，清除引起失效原因的开发活动，随后由测试员进行的再测试是为了确认修改的代码已经解决了失效问题。每个活动的职责是截然不同的，即测试员进行测试，开发人员进行调试。

  • 调试（Debug）

    • 调试是一种开发活动；
    • 调试为了发现、分析并消除缺陷；
    • 调试一边修改代码一边进行验证；
    • 调试由开发人员执行；

    注意：调试的对象只能是代码，不能是文档；

  • 测试（Test）

    • 动态测试可以发现缺陷引起的失效；
    • 再测试（Verify）是为了验证代码修改已经解决了失效；
    • 测试由测试人员执行；

    注意：测试的对象不仅限于代码，还可以包括文档；

• 外部和内部质量特性(1.1.4)
  软件满足规定或潜在客户需求特性的程度（ISO9126）

  • 功能性

    • 适合性

    • 准确性

    • 互操作性

    • 保密安全性

    • 功能依从性

  • 可靠性

    • 成熟性

    • 容错性

    • 可靠依从性

  • 易用性

    • 易理解性

    • 易学性

    • 易操作性

    • 吸引性

    • 易用依从性

  • 效率

    • 时间特性

    • 资源利用性

    • 效率依从性

  • 维护性

    • 易分析性

    • 易改变性

    • 稳定性

    • 易测试性

    • 维护依从性

  • 可移植性

    • 适应性

    • 易安装性

    • 共存性

    • 易替换性

    • 可移植依从性

• 测试和质量的关系(1.1.4)
  软件测试是对软件质量的度量和评估，提供软件质量的信息，不能仅靠软件测试保证质量。

  • 度量及评估软件质量特性
    可以根据测试中所发现的缺陷，对软件功能和非功能性需求以及特性(例如:可靠性、可用性、 效率、可维护性和可移植性)进行度量，从而评估软件质量。

  • 树立对于软件质量的信心
    当测试发现很少或者没有发现缺陷的时候，测试就会帮助树立对于软件质量的信心。

  • 改进软件开发过程
    通过分析在其他项目中发现的缺陷和引起缺陷的根本原因，可以改进软件开发过程。

  • 质量保证工作的一部分
    测试应该作为开发过程中质量保证工作的不可或缺的一部分(与开发标准、培训和缺陷分析一样)。

• 测试的充分性(1.1.5)

  • 风险

    • 技术风险

    • 商业产品风险

    • 项目风险

  • 时间限制

  • 预算限制

测试总体目标(1.2)

• 【早期阶段】预防缺陷

  • 静态测试

• 【开发阶段】发现缺陷

  • 组件测试

  • 集成测试

  • 系统测试

• 【验收阶段】增加对质量的信心

  • 验收测试

• 【运行阶段】为决策提供信息

  • 维护测试

测试的基本原则(1.3)

• 原则 1 - 测试显示存在缺陷
  测试可以显示存在缺陷，但不能证明系统不存在缺陷。测试可以减少软件中存在未被发现缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。

• 原则 2 - 穷尽测试是不可行的
  除了小型项目，进行完全(各种输入和前提条件的组合)的测试是不可行的。通过运用风险分 析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。

  助记：
  不要追求完美，考虑测试的充分性。

• 原则 3 - 测试尽早介入
  为了尽早发现缺陷，在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经定义的测试目标上。

  助记：
  越早发现缺陷影响越小

• 原则 4 - 缺陷集群性
  测试工作的分配比例应该与预期的和后期观察到的缺陷分布模块相适应。少数模块通常包含大部分在测试版本中发现的缺陷或失效。

  助记：
  缺陷多的模块要着重测试

• 原则 5 - 杀虫剂悖论
  采用同样的测试用例多次重复进行测试，最后将不再能够发现新的缺陷。为了克服这种“杀虫 剂悖论”，测试用例需要进行定期评审和修改，同时需要不断增加新的不同的测试用例来测试软件或 系统的不同部分，从而发现潜在的更多的缺陷。

  助记：
  要尽量测新版本；随时更新测试用例、环境、工具和计划。

• 原则 6 - 测试活动依赖于测试背景
  针对不同的测试背景，进行不同的的测试活动。比如，对安全关键的软件进行测试，与对一般的电子商务软件的测试是不一样的。

  助记：
  测试人员要有行业背景和行业知识！

• 原则 7 - 不存在缺陷(就是有用系统)的谬论
  假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的。

基本的测试过程(1.4)

• 1. 测试计划和控制
     测试计划的主要活动是:识别测试任务、定义测试目标以及为了实现测试目标和任务确定必要的测试活动。

  测试控制是持续进行的活动:通过对测试实际进度和测试计划之间的比较，报告测试的状态，包括与计划之间存在的偏差。测试控制包括在必要的时候采取必要的措施来满足测试的任务和目标。 需要在项目的整个生命周期中对测试活动进行监督，以达到控制测试过程的目的。同时，测试计划 的制定也需要考虑测试监控活动的反馈信息。

  测试计划和控制阶段的任务将在第五章讲述。

• 2. 测试分析和设计
     测试分析和设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。

  主要任务:
   评审测试依据(比如需求、软件完整性级别1(风险等级)、风险分析报告、系统架构、设 计和接口说明);
   评估测试依据和测试对象的可测性;
   通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定其优先级;
   设计测试用例并确定优先级;
   确定测试条件和测试用例所需要的测试数据;
   规划测试环境的搭建和确定测试需要的基础设施和工具;
   创建测试依据和测试用例间的双向可追溯性。

• 3. 测试实现和执行
     通过特定的顺序组织测试用例来完成测试规程和脚本的设计，并且包括测试执行所需的其他任何信息，以及测试环境的搭建和运行测试。

  主要任务:
   测试用例的开发、实现并确定它们的优先级。(包括识别测试数据);
   开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用具和设计自动化测试脚本;
   根据测试规程创建测试套件，以提高测试执行的效率;
   确认已经正确搭建了测试环境;
   确认并更新测试依据和测试用例间的双向可追溯性;
   根据计划的执行顺序，通过手工或使用测试执行工具来执行测试规程;
   记录测试执行的结果，以及被测软件、测试工具和测试件的标识和版本;
   将实际结果和预期结果进行比较;
   对实际结果和预期结果之间的差异，作为事件上报，并且进行分析以确定引起差异的原因(例如:代码缺陷、具体测试数据缺陷、测试文档缺陷、或测试执行的方法有误等);
   缺陷修正后，重新进行测试活动。比如通过再次执行上次执行失败的用例来确认缺陷是否 已经被修正(确认测试)。执行修正后的测试用例或执行一些测试用例来确保缺陷的修正没有对软件未修改的部分造成不良影响或对于缺陷的修正没有引发其他的缺陷(回归测试)。

• 4. 评估出口准则和报告
     评估出口准则是将测试的执行结果和已经定义的测试目标进行比较的活动。这个活动在各个测试级别上都需要进行。(参见章节 2.2)

  主要任务:
   按照测试计划中定义的测试出口准则检查测试日志;
   评估是否需要进行更多的测试，或是否需要更改测试的出口准则;
   为利益相关者提供一个测试总结报告。

• 5. 测试结束活动
     测试结束活动就是从已完成的测试活动中收集和整合有用的数据，这些数据可以是测试经验、测试件、影响测试的因素和其他数据。
     在以下几种情况下需要执行测试结束活动，例如:当软件系统正式发布、当一个测试项目完成(或取消)、当达到一个里程碑或当一个维护版本完成时。

  主要任务:
   检查提交了哪些计划的可交付产品;
   事件报告是否关闭、或对未关闭的事件报告提交变更需求;
   记录系统的验收;
   记录和归档测试件、测试环境和测试基础设备，以便以后的重复使用; 移交测试件到维护部门;
   分析和记录所获得的经验教训，用于以后的项目和测试成熟度改进;
   使用为测试成熟度的提高所收集的信息。

测试的独立性级别(1.5)

• 由开发者本人执行
  测试由软件本身编写的人员来执行(最低级别的独立)

• 由其他开发人员执行
  测试由一个其他开发人员(如来自同一开发小组)来执行

• 由独立的测试小组或专家执行
  测试由组织内的一个或多个其他小组成员(如独立的测试小组)或测试专家(如可用性或性能测试专家)来执行

• 由外包或其他外部组织执行
  测试由来自其他组织或其他公司的成员来执行(如测试外包或其他外部组织的鉴定，最高级别的独立)

软件测试与开发如何相处(1.5)

沟通方面的问题经常会发生，特别是当测试员只是被视为不受欢迎的缺陷消息的传递者的时候。 然而可以使用下面的一些方法来改善测试员和其他小组成员之间的沟通和相互关系:
 以合作而不是争斗的方式开始项目，时时提醒项目的每位成员:共同目标是追求高质量的 产品;
 对产品中发现的问题以中性的和以事实为依据的方式来沟通，而不要指责引入这个问题的 小组成员或个人。比如，客观而实际地编写缺陷报告和评审发现的问题;
 尽量理解其他成员的感受，以及他们为什么会有这种反应;
 确信其他成员已经理解你的描述，反之亦然。

职业道德(1.6)

公共 - 认证测试工程师应当以公众利益为目标。
客户和雇主 - 在保持与公众利益一致的原则下，认证测试工程师应注意满足客户和雇主的最高利益。
产品 - 认证测试工程师应当确保他们提供的(在产品和系统中由他们测试的)发布版本符合最高的专业标准。
判断 - 认证测试工程师应当维护他们职业判断的完整性和独立性。
认证软件测试管理人员和测试领导人员应赞成和促进对软件测试合乎道德规范的管理。
专业 - 在与公众利益一致的原则下，认证测试工程师应当推进其专业的完整性和声誉。
同事 - 认证测试工程师对其同事应持平等和互助和支持的态度，并促进与软件开发人员的合作。
自我 - 认证测试工程师应当参与终生职业实践的学习，并促进合乎道德的职业实践方法。

软件生命周期中的测试(2)

软件开发模型(2.1)

软件开发模型是指软件开发所依据的方式和过程。

如何选择开发模型？

• 根据项目的内容

• 根据产品的特征

• V模型（顺序开发模型）(2.1.1)
  “V模型”也称“顺序开发模型”，它适合需求明确且不常改变的场景。

  用户需求 <———— 验收测试
  系统设计 <——— 系统测试
  概要设计 <—— 集成测试
  详细设计 <— 组件测试
  编码/实现

  备注：
  箭头表示验证关系

  • 组件测试

  • 集成测试

  • 系统测试

  • 验收测试

• 迭代-增量开发模型(2.1.2)
  迭代-增量开发模型由需求建立、设计、构建和测试等一系列相对较短的开发周期构成。

  在每次迭代过程中, 对迭代产生的系统可能需要在不同的测试级别上进行测试。通过将增量模块加入到以前开发的模块中，形成一个逐渐增大的系统，这个系统同样需要进行测试。在完成第一次迭代后，对所有的迭代 进行回归测试会变得越来越重要。验证和确认可以在每个增量模块中进行。

  • 原型开发

  • 快速应用开发(RAD)

  • 统一软件开发过程(RUP)

  • 敏捷开发(Agile)
    “敏捷开发模型”适合需求快速变化的场景。

测试级别(2.2)

“V模型”也称“顺序开发模型”，它适合需求明确且不常改变的场景。

用户需求 <———— 验收测试
系统设计 <——— 系统测试
概要设计 <—— 集成测试
详细设计 <— 组件测试
编码/实现

备注：
箭头表示验证关系

• 组件测试(2.2.1)

  • 也称“单元测试”或“模块测试”；

  • 在软件编码完成后，对每个程序模块进行测试；

  • 通常由开发人员进行，测试人员辅助；

    • 概述
      在独立可测试的软件中(模块、程序、对象和类等),可以通过组件测试发现缺陷，以及验证软 件功能。根据开发生命周期和系统的背景，组件测试可以和系统的其他部分分开，单独进行测试。 在组件测试过程中，会使用到桩、驱动器和模拟器。

      组件测试可能包括功能测试和特定的非功能特征测试，比如资源行为测试(如内存泄漏)或健 壮性测试和结构测试(比如分支覆盖)。根据工作产品，例如组件规格说明、软件设计或数据模型等设计测试用例。

      通常，通过开发环境的支持，比如组件测试框架或调试工具，组件测试会深入到代码中，而且实际上设计代码的开发人员通常也会参与其中。在这种情况下，一旦发现缺陷，就可以立即进行修改，而不需要正式的缺陷管理过程。

    • 测试依据

      • 组件需求说明

      • 详细设计文档

      • 代码

    • 测试对象

      • 组件

      • 程序

      • 数据转换/移植程序

      • 数据库模型

• 集成测试(2.2.2)

  • 也称“组装测试”或“联合测试”；

  • 关注模块之间的配合，用以发现接口上的缺陷；

  • 集成应当是渐进的，可以“自顶向下”也可以“自底向上”集成；

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

      集成的规模越大，就越难在某一特定的组件或系统中定位缺陷，从而增加了风险并会花费额外的更多时间去发现和修理这些故障。
      系统化集成的策略可以根据系统结构(例如自顶向下或自底向上)、功能任务集、事务处理顺序 或系统和组件的其他方面等来制定。为了能方便快速地隔离故障和定位缺陷，集成程度应该逐步增加，而不是采用“大爆炸”式的集成。

      测试特定的非功能特征(比如性能)也可以包含在系统集成测试中。
      在集成的每个阶段，测试员只是把精力集中在集成本身。举例来说，假如集成模块 A 和模块 B， 测试人员是应该关注两个模块之间的交互，而不是每个模块的功能。功能测试和结构测试方法都可以应用在集成测试。

    • 测试依据

      • 软件和系统设计文档

      • 系统架构

      • 工具流

      • 用例

    • 测试对象

      • 子系统

      • 数据库实现

      • 基础结构

      • 接口

      • 系统配置和配置数据

• 系统测试(2.2.3)

  • 将整个程序安装到运行环境中，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试。

  • 通常由独立的测试团队进行。

    • 概述
      系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行为。

      在系统测试中，测试环境应该尽量和最终的目标或生产环境相一致，从而减少不能发现和环境相关的失效的风险。

      系统测试可能包含基于不同方面的测试:基于风险评估的、基于需求规格说明的、基于业务过程的、基于用例的、或基于其他对系统行为的更高级别描述或模型的、基于与操作系统的相互作用的、基于系统资源等的测试。

      针对功能需求的系统测试开始时可以选择 最适合的基于规格说明的测试即黑盒技术来对系统进行测试。比如:可以根据业务准则描述的因果 组合来生成决策表。基于结构的技术即白盒测试技术，可以评估测试的覆盖率，可以基于评估覆盖 一个结构元素，如菜单结构或者页面的导航等的完整性。

      系统测试通常由独立的测试团队进行。

    • 测试依据

      • 系统和软件需求规格说明

      • 用例

      • 功能规格说明

      • 风险分析报告

    • 测试对象

      • 系统、用户手册和操作手册

      • 系统配置和配置数据

• 验收测试(2.2.4)

  • 也称“交付测试”或“确认测试”；

  • 在交付软件前，需要检测与证实软件是否满足了需求说明书中规定的要求。

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

      验收测试的目的是建立对系统、系统的某部分或特定的系统非功能特征建立信心。发现缺陷不是验收测试的主要目标。验收测试可以用来评估系统对于部署和使用的准备情况，但是验收测试不 一定是最后级别的测试。

      验收测试可以在多个测试级别上进行。

    • 测试依据

      • 用户需求

      • 系统需求

      • 用例

      • 业务流程

      • 风险分析报告

    • 测试对象

      • 基于完全集成系统的业务流程

      • 用户处理过程

      • 结构

      • 报告

      • 配置数据

    • 典型类型

      • 用户验收测试
        最终操作人员参与

      • 操作（验收）测试
        由系统管理员来进行，测试内容主要包括:
         系统备份/恢复测试;
         灾难恢复测试;
         用户管理测试;
         维护任务测试;
         数据加载和移植活动;
         安全漏洞阶段性检查。

      • 合同和法规性验收测试
        合同性：根据合同中规定的验收准则进行测试；
        法规性：根据法律法规进行测试，如政府、法律和安全方面的法律法规。

      • Alpha和Beta（或现场）测试
        Alpha 测试通常在开发组织现场进行，但测试并非由开发团队执行。Beta 测试或实地测试，是在客户或潜在客户现场进行并由他们执行。

测试类型(2.3)

• 功能性测试(2.3.1)
  可以采用基于规格说明的技术，根据软件或系统的功能来设计测试条件和测试用例(参见第 4 章)。功能测试主要是考虑软件的外部表现行为(黑盒测试)。

  安全性测试是功能测试的一种，它会对安全性相关的功能(比如防火墙)进行测试，从而检测系统和数据是否能抵御外部恶意的威胁，如病毒等。互操作性测试是另一种功能性测试，评估软件产品与其他一个或多个组件或系统交互的能力。

  注意：
  安全性和互操作性测试是功能性测试。

• 非功能性测试(2.3.2)
  非功能测试包括但不限于:性能测试、负载测试、压力测试、可用性测试、可维护性测试、可靠性测试和可移植性测试。非功能性测试就是测试系统运行的表现如何。

• 结构测试(2.3.3)
  可以在任何测试级别上进行结构测试(白盒测试)。

  结构测试技术最好在进行基于规格说明的测试之后使用，以便通过评估结构类型的覆盖来测量测试的完整性。

  覆盖是指结构通过测试套件检验的程度，以项被覆盖的百分比来表示。假如覆盖率不是 100%， 可能需要设计更多的测试用例，来测试被遗漏的项，从而提高测试的覆盖。有关覆盖技术参见第 4 章。

  在所有的测试级别，特别是在组件测试和组件集成测试中，可以利用工具来测量代码内某些元 素的覆盖率，比如语句覆盖和判定覆盖。结构测试也可以基于系统的结构，比如调用层次结构。

  结构测试方法也同样可以运用到系统、系统集成或验收测试级别(比如业务模型或菜单结构)。

• 再测试和回归测试(2.3.4)
  当发现和修改了一个缺陷后，应进行再测试以确定已经成功的修改了原来的缺陷，这称之为确认。调试(定位并修复缺陷)是一种开发活动，不是一种测试活动。

  回归测试是对已被测过的程序在修改缺陷后进行的重复测试，以发现在这些变更后是否有新的 缺陷引入或被屏蔽。

  当软件发生变更或者应用软件的环境发生变化时，需要进行回归测试。回归测试的规模可以根据在以前正常运行的软件中发现新的缺陷的风险大小来决定。

  回归测试可以在所有的测试级别上进行，同时适用于功能测试、非功能测试和结构测试。回归测试套件一般都会执行多次，而且通常很少有变动，因此将回归测试自动化是很好的选择。

维护测试(2.4)

维护测试是在一个现有的运行系统上进行，且一旦对软件或系统进行修改、移植或退役处理时，就需要进行维护测试。

当数据从另一个应用程序移植到正在维护的系统时，需要移植测试(转换测试)。

为系统退役而进行的维护测试应该包括数据移植测试，或当数据要长时间的保存时还须存档测试。

维护测试根据变更情况的不同，可以在某一测试级别或所有测试级别和测试类型上进行。确定变更如何影响现有系统的过程，称之为影响分析，它有助于决定实施回归测试的广度和深度。

如果规格说明遗失、过时或测试人员没有具备领域知识，进行维护测试将是一件困难的事情。

软件静态测试技术(3)

静态测试分类

• 评审

  • 非正式评审

  • 正式评审

    • 走查(Walk through)

    • 技术评审(Technical Review)

    • 正规审查(Inspection)

• 基于工具的静态分析

  • 词法和语法分析

  • 静态错误分析

静态技术和测试过程(3.1)

• 概述
  静态测试技术通过手工检查(评审)或自动化分析(静态分析)的方式对代码或者其他的项目文档进行检查。

  评审是对软件工作产品(包括代码)进行测试的一种方式，可以在动态测试执行之前进行。
  在生命周期早期的评审过程中发现并修改缺陷(例如发现需求中的缺陷)的成本会比在动态测试中才发现并修改这些缺陷的成本低的多。

• 目标
  评审、静态分析和动态测试具有共同的目标是识别缺陷。
  它们之间是互补的，不同的技术可以有效和高效地发现不同类型的缺陷。

• 特点

  • 不需要运行代码；
  • 直接发现缺陷本身；
  • 检查对象不仅是代码还可以是文档；
  • 可以在早期发现缺陷，大幅降低成本；
  • 相对动态测试而言，静态测试成本低效率高；

评审过程(3.2)

• 正式评审的阶段(3.2.1)

  • 1. 计划阶段
        定义评审标准;
        选择人员;
        分配角色;
        为更加正式的评审类型(比如审查)制定入口和出口准则;
        选择需要进行评审的文档的内容;
        核对入口准则(针对更正式的评审类型)。
  • 2. 预备会阶段
        分发文档;
        向评审参与者解释评审的目标、过程和文档。
  • 3. 个人准备阶段
        先行评审文档，为评审会议做准备;
        标注可能的缺陷、问题和建议;
  • 4. 评审会议阶段
        讨论和记录，并留下文档化的结果或会议纪要(针对更正式的评审类型);
        标注缺陷、 提出处理缺陷的建议、对缺陷作出决策;
        在任何形式的会议期间或跟踪任何类型的电子通信期间检查/评价和记录问题。
  • 5. 返工阶段
        修改发现的缺陷(通常由作者来进行);
        记录缺陷更新的状态(在正式评审中)。
  • 6. 跟踪结果阶段
        检查缺陷是否已得到解决;
        收集度量数据;
        核对出口准则(针对更正式的评审类型)。

• 角色和职责(3.2.2)

  • 经理
    经理:决定是否需要进行评审，在项目计划中分派时间，判断是否已达到评审的目标。

    注意：
    经理未必出席评审会议。

  • 主持人
    主持人:主持文档或文档集的评审活动，包括策划评审、召开会议和会议后的跟踪。假如需要，主持人可能还需要进行不同观点之间的协调。主持人通常是评审成功与否的关键。

    注意：
    主持人是评审成败的关键。

  • 作者
    作者:待评审文档的作者或主要责任人。

  • 评审员
    评审员:具有专门技术或业务背景的人员(也称为检查员(checker)或审查员(inspector))，他们在必要的准备后，标识和描述被评审产品存在的问题(如缺陷)。所选择的评审员应该
    在评审过程中代表不同的观点和角色，并且应该参与各种评审会议。

  • 记录员
    记录员:记录所有的事件、问题，以及在会议过程中识别的未解决的问题。

    注意：
    记录员可以是其他角色兼职负责，例如主持人，但不能是作者本人。

• 评审类型(3.2.3)
  非正式评审：

  • 评审对象是正在进行中的工作产品；
  • 不需要明确定义的过程，可以没有书面指导性材料。

  正式评审：

  • 评审对象是已经确认完成的工作产品；

  • 需要遵循明确定义的过程，参与人员有明确的职责划分，有明确定义的入口和出口准则，以及规范化的书面材料。

    • 非正式评审
      主要目的:以较低的成本获得收益。

    • 走查(Walk through)
      主要目的:学习、增加理解、发现缺陷。

      在实际情况中可以是非常正式的，也可能是非常不正式的;

    • 技术评审(Technical Review)
      主要目的:讨论、作决策、评估候选方案、发现缺陷、解决技术问题、检查与规格及标准的符合程度。

      在实际情况中可以是在不正式的和非常正式的之间;

    • 正规审查(Inspection)
      主要目的:发现缺陷。

• 技术评审的注意事项

  1. 评审应针对材料而非作者；
  2. 评审会议不宜超过两个小时：当被审核材料多时，应该拆分成若干部分进行评审；
  3. 限制争辩的时间：当无法取得一致认同时，先记录问题，可另行安排时间进行讨论；
  4. 阐明问题而不试图解决问题：评审会上不要解决问题，应记录问题，会后再解决问题；

静态分析的工具支持(3.3)

• 概述
  静态分析的目的是发现软件源代码和软件模型中的缺陷。静态分析的执行并不需要使用工具去 实际运行被测软件。而动态测试是真正运行软件的代码。静态分析可以定位那些在测试过程很难发 现的缺陷。与评审一样，静态分析通常发现的是缺陷而不是失效。静态分析工具能够分析程序代码 (比如控制流和数据流)，以及产生如 HTML 和 XML 的输出。

• 静态分析的好处
  静态分析的好处:
   在测试执行之前尽早发现缺陷;
   通过度量的计算(比如高复杂性测量)，早期警示代码和设计可能存在问题的方面;
   可以发现在动态测试过程不容易发现的一些缺陷;
   可以发现软件模块之间的相互依赖性和不一致性，例如链接;
   改进代码和设计的可维护性;
   在开发过程中学习经验教训，从而预防缺陷。

• 静态分析策略
  开发人员通常在组件测试和集成测试之前或期间，或当代码签入到配置管理工具时使用静态分析工具(按照预先定义的规则或编程规范进行检查)。

  设计人员在软件建模期间也使用静态分析工具。

  静态分析工具会产生大量的警告信息，需要很好的管理这些信息，从而可以有效地使用静态分析工具。

  编译器也可以为静态分析提供一些帮助，包括度量的计算。

• 工具能够发现的典型缺陷
  通过静态分析工具能够发现的典型缺陷如下:
   引用一个没有定义值的变量;
   模块和组件之间接口不一致;
   从未使用的变量;
   不可达代码或死代码;
   逻辑上的遗漏与错误(潜在的无限循环);
   过于复杂的结构;
   违背编程规则;
   安全漏洞;
   代码和软件模型的语法错误。

测试设计技术(4)

测试开发过程(4.1)

• 测试分析阶段
  在测试分析阶段，要对测试基础文档进行分析，从而决定测试什么，也就是明确测试的条件。 将测试条件定义为能通过一个或多个测试用例进行验证的一个条目或事件(比如功能、事务处理、 质量特征或结构元素等)。
  建立从测试条件到需求的可追溯性，有助于需求变更时的影响分析和测试用例集的需求覆盖率 分析。在测试分析阶段，除了考虑一些其它的因素，基于已经识别的风险，实施具体的测试方法从 而选择要采用的测试技术(有关风险分析的更多的内容请参见第 5 章)。

• 测试设计阶段
  在测试设计阶段，要定义和记录测试用例和测试数据。测试用例由:一组输入值、执行的前提 条件、预期结果和执行的后置条件等元素组成，以覆盖一定的产生目标或测试条件。测试设计规格 说明(包含测试条件)和测试用例规格说明的内容在“软件测试文档标准(IEEE Std 829-1998)” 中有具体的描述。
  预期的测试结果应该作为测试用例规格说明的一部分，同时包含输出、数据和状态的变化，以 及其他的测试结果。假如没有明确预期结果，则一个看似合理却错误的结果可能被视为正确的结果。 理想情况下预期结果应该在测试执行之前明确定义。

• 测试实现阶段
  在测试实现阶段，测试用例的开发、实现、确定优先级和组织都应该包含在测试规程规格说明 中(IEEE STD 829-1998)。测试规程(或者手工测试脚本)描述了测试用例执行的顺序。如果使用 测试执行工具进行测试，这种测试的动作顺序将在测试脚本中描述(自动化的测试规程)。
  不同的测试规程和自动化测试脚本要体现在测试执行进度表中，该计划定义了不同测试规程和可能的自动化测试脚本的执行顺序、执行的时间和执行者。测试执行进度表同时考虑了其他的因素，比如回归测试、测试优先级以及技术和逻辑的依赖等。

测试设计技术的种类(4.2)

• 基于规格说明/黑盒(4.3)
  基于规格说明的测试技术具有以下共同特点:
   使用正式或非正式的模型来描述需要解决的问题、软件或其组件等;  根据这些模型，可以系统地导出测试用例。

  • 等价类
    有效等价类
    无效等价类

  • 边界值
    临界值
    刚好超出临界值
    刚好小于临界值

  • 决策表
    因果图与判定表：
    复杂条件构成因果图
    根据因果图生成判定表

  • 状态转换
    根据软件的状态、状态间的转换、触发状态变化(转换)的输入或事件以及从状态转换导致的可能的行动来进行测试。

  • 用例
    描述了参与者(用户或系统)之间的相互作用，并从这些交互产生一个从系统用户或客户的角度所期望和能观察到的结果。

    用例非常有助于设计用户/客户参与的验收测试; 也可以帮助发现由于不同组件之间的相互作用和相互影响而产生的集成缺陷，这是在单个的组件测 试中是无法发现的。

    备注：用例指的是用户如何使用软件，即“Use Case”。

• 基于结构/白盒(4.4)
  基于结构的技术的共同特点:
   根据软件的结构信息设计测试用例，比如软件代码和详细设计信息;
   可以通过已有的测试用例测量软件的测试覆盖率，并通过系统化的导出设计用例来提高覆盖率。

  • 语句覆盖
    在组件测试中，语句覆盖是指评价一个测试用例套件中已经执行的可执行语句的百分比。

  • 判定覆盖
    判定覆盖，和分支测试相关，是指评价在一个测试用例套中已经执行的判定(例如 if 语句的 true 和 false 选项)输出的百分比。

    备注：“判定覆盖”比“语句覆盖”更全面，100%的“判定覆盖”可以保证 100%的“语句覆盖”，反之则不行。

• 基于经验(4.5)
  基于经验的方法具有以下共同特点:
   测试用例根据参与人员的经验和知识来编写;
   测试人员、开发人员、用户和其他的利益相关者对软件、软件使用和环境等方面所掌握的知识作为信息来源之一;
   对可能存在的缺陷及其分布情况的了解作为另一个信息来源。

  注意：这种技术依据测试员的经验，所以产生的效果会有极大的不同。

  • 探索性测试
    探索性测试是指依据包含测试目标的测试章程来同时进行测试设计、测试执行、测试记录和学习，并且是在规定时间内进行的。
    这种方法在规格说明较少或不完备且时间压力大的情况下使用更有帮助，或者作为对其他更为正式的测试的增加或补充。
    它可以作为测试过程中的检查，以有助于确保能发现最为严重的缺陷。

  • 错误推测法
    错误推测法的一个结构化方法是列举可能的错误，并设计测试来攻击这些错误，这种系统的方法称之为缺陷攻击。

测试管理(5)

测试组织(5.1)

• 测试组织的独立性
  独立测试的优点:
   独立的测试员是公正的，可以发现一些其他不同的缺陷。;
   一个独立的测试员可以验证在系统规格说明和实现阶段所做的一些假设。
  独立测试的缺点:
   与开发小组脱离(如果完全独立);
   开发人员可能丧失对软件质量的责任感;
   独立的测试员可能被视为瓶颈或者成为延时发布而被责备的对象。

• 测试组织模式

  • 基于技能的组织模式

  • 基于项目的组织模式

• 测试角色及职责

  • 测试组长
    测试组长可能的主要任务包括:
     与项目经理以及其他人共同协调测试策略和测试计划;
     制定或评审项目的测试策略和组织的测试方针;
     将测试的安排合并到其他项目活动中，比如集成计划;
     制定测试计划(要考虑背景，了解测试目标和风险)，包括选择测试方法，估算测试的时间、工作量和成本，获取资源，定义测试级别、测试周期并规划事件管理;
     启动测试规格说明、测试准备、测试实施和测试执行，监督测试结果并检查出口准则;
     根据测试结果和测试过程(有时记录在状态报告中)调整测试计划，并采取任何必要措施对存在的问题进行补救;
     对测试件进行配置管理，保证测试件的可追溯性;
     引入合适的度量项以测量测试进度，评估测试和产品的质量;
     决定什么应该自动化，自动化的程度，以及如何实现;
     选择测试工具支持测试，并为测试员组织测试工具使用的培训;
     决定关于测试环境实施的问题;
     根据在测试过程中收集的信息编写测试总结报告。

  • 测试员
    测试员可能的主要任务包括:
     评审和参与测试计划的制定;
     分析、评审和评估用户需求、规格说明书及模型的可测试性;
     创建测试规格说明;
     建立测试环境(通常需要系统管理员，网络管理员协同完成);
     准备和获取测试数据;
     进行所有级别的测试，执行并记录测试日志，评估测试结果，记录和预期结果之间的偏差。
     根据需要使用测试管理工具和测试监控工具;
     实施自动化测试(可能需要开发人员或测试自动化专家的支持);
     在可行的情况下，测量组件和系统的性能;
     对他人的测试进行评审。

测试计划和估算(5.2)

• 测试计划(5.2.1)

  1. 测试计划受到很多因素的影响:组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等。
  2. 随着项目和测试计划的不断推进，将有更多的信息和具体细节包含在计划中。
  3. 测试计划是个持续的活动，需要在整个生命周期过程和活动中进行。
  4. 从测试中得到的反馈信息可以识别变化的风险，从而对计划作相应的调整。

• 测试计划活动(5.2.2)
  对整个系统或部分系统可能的测试计划活动包括:
   确定测试的范围和风险，明确测试的目标;
   决定总体测试方法，包括测试级别、入口和出口准则的界定;
   把测试活动整合和协调到整个软件生命周期活动中去(采购、供应、开发和运维);
   决定测试什么?测试由什么角色来执行?如何进行测试?如何评估测试结果?
   为测试分析和设计活动安排时间进度;
   为测试实现、执行和评估安排时间进度;
   为已定义的不同测试活动分配资源;
   定义测试文档的数量、详细程度、结构和模板;
   为监控测试准备和执行、缺陷解决和风险问题选择度量项;
   确定测试规程的详细程度，以提供足够的信息支持可复用的测试准备和执行。

• 入口准则(5.2.3)
  入口准则定义了什么时候可以开始测试，如某个测试级别的开始，或什么时候一组测试准备就绪可以执行。

  入口准则主要包含:
   测试环境已经准备就绪并可用;
   测试工具在测试环境中已经准备就绪;
   可测的代码可用;
   测试数据可用。

• 出口准则(5.2.4)
  测试出口准则(exit criteria)的目的是:定义什么时候可以停止测试，比如某个测试级别的 结束，或者当测试达到了规定的目标。

  出口准则主要包含:
   完整性测量，比如代码、功能或风险的覆盖率;
   对缺陷密度或可靠性度量的估算;
   成本;
   遗留风险，例如没有被修改的缺陷或在某些部分测试覆盖不足;  进度表，例如基于交付到市场的时间。

• 测试估算(5.2.5)

  • 测试工作量
    测试工作量的内容：

    1. 测试用例设计；
    2. 测试环境设置；
    3. 测试用例执行；
    4. 测试缺陷报告；

    一旦估算了测试工作量，就可以识别资源和制定时间进度表。

  • 决策因素
    测试的工作量可能取决于多种因素，包括:
     产品的特点:规格说明和用于测试模型的其它信息(即测试依据)的质量，产品的规模，问题域的复杂度，可靠性、安全性的需求和文档的需求;
     开发过程的特点:组织的稳定性、使用的工具、测试过程、参与者的技能水平和时间紧迫程度等;
     测试的输出:缺陷的数量和需要返工的工作量。

  • 估算方法
    两种估算测试工作量的方法:
     基于度量的方法:根据以前或相似项目的度量值来进行测试工作量的估算，或者根据典型的数据来进行估算;
     基于专家的方法:由任务的责任人或专家来进行测试任务工作量的估算。

• 测试方法(5.2.6)

  • 测试策略与方法
    测试方法是测试策略的具体实现。

    仅做了解：
    测试策略（Testing Strategy）通常是描述如何测试软件的总体方法和目标。它是关于如何测试系统的正式描述，需要确定针对所有测试级别的测试策略。包括确定测试环境、阶段、类型、方法和技术。描述测试包含多少个测试级别（如组件测试、集成测试、系统测试等）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等）。
    【从2010版大纲开始：为保持测试方法(test approach)与术语表中的定义一致。术语“测试策略(test strategy)” 将不再作为术语要求了。】

  • 典型的测试方法
    典型的测试方法包括:
     分析的方法，比如基于风险的测试，直接针对风险最高的部分进行测试;
     基于模型的方法，比如随机测试利用失效率(如:可靠性增长模型)或使用率(如:运行概 况)的统计信息;
     系统的方法，比如基于失效的方法(包括错误推测和故障攻击)，基于检查表的方法和基于质量特征的方法; 基于与过程或符合标准的方法，比如在行业标准中规定的方法或各类敏捷的方法;
     动态和启发式的方法，类似于探索性测试，测试很大程度上依赖于事件而非提前计划，而且执行和评估几乎是同时进行的;
     咨询式的方法，比如测试覆盖率主要是根据测试小组以外的业务领域和/或技术领域专家的建议和指导来推动的;
     可重用的方法，比如重用已有的测试材料，广泛的功能回归测试的自动化，标准测试套件等。

    可以结合使用不同的测试方法，比如基于风险的动态方法。

测试过程的监控(5.3)

• 测试监控的目的
  测试监控的目的是：

  1. 提供关于测试活动的反馈信息，使测试活动保持可视性。监控的信息可以通过手工或自动的方式进行收集，同时可以用来衡量出口准则，比如测试覆盖率。
  2. 也可以用度量数据对照原计划的时间进度和预算来评估测试的进度。

• 常用的测试度量项目
  常用的测试度量项有:
   测试用例准备工作完成的百分比(或按计划已编写的测试用例的百分比);
   测试环境准备工作完成的百分比;
   测试用例执行情况(例如:执行/没有执行的测试用例数，通过/失败的测试用例数);
   缺陷信息(例如:缺陷密度、发现并修改的缺陷、失效率、重新测试的结果);
   需求、风险或代码的测试覆盖率;
   测试员对产品的主观信心;
   测试里程碑的日期;
   测试成本，包括寻找下一个缺陷或执行下一轮测试所需成本与收益的比较。

• 测试报告
  测试报告是对测试工作和活动等相关信息的总结，主要包括:
   在测试周期内发生了什么?比如达到测试出口准则的日期;
   通过分析相关信息和度量可以对下一步的活动提供建议和做出决策，比如对遗留缺陷的评估、继续进行测试的经济效益、未解决的风险以及被测试软件的置信度等。

  测试总结报告的大纲可以参考“软件测试文档标准”(IEEE Std 829-1998)。

  需要在测试级别的过程中和完成时收集度量信息，来评估:
   该测试级别的测试目标实现的充分性;
   采用的测试方法的适当性;
   针对测试目标的测试的有效性。

  注意：
  “软件测试文档标准”(IEEE Std 829-1998)的内容在考题中会有体现，建议了解。

• 测试控制
  测试控制描述了根据收集和报告的测试信息和度量而采取的指导或纠正措施。措施可能包括任何测试活动，也可能影响其它软件生命周期中的活动或任务。

  测试控制措施的例子:
   基于测试监控信息来做决策;
   如果一个已识别的风险发生(如软件交付延期)，重新确定测试优先级;
   根据测试环境可用性，改变测试的时间进度表;
   设定入口准则:规定修改后的缺陷必须经过开发人员再测试(确认测试)后才能将它们集成到版本中去。

配置管理(5.4)

配置管理的目的是在整个项目和产品的生命周期内，建立和维护软件或系统产品(组件、数据和文档)的完整性。

对测试而言，采用配置管理可以确保:
 测试件的所有相关项都已经被识别，版本受控，相互之间有关联以及和开发项(测试对象)之间有关联的变更可跟踪，从而保证可追溯性;
 在测试文档中，所有被标识的文档和软件项能被清晰明确的引用。

对于测试员来说，配置管理可以帮助他们唯一地标识(并且复制)测试项、测试文档、测试用例和测试用具。

在测试计划阶段，应该选择配置管理的规程和基础设施(工具)，将其文档化并予以实施。

风险和测试(5.5)

• 项目风险(5.5.1)
  项目风险是围绕项目按目标交付的能力的一系列风险，比如:
   组织因素:
   技能、培训和人员的不足;
   个人问题;
   政策因素，比如:
   与测试员进行需求和测试结果沟通方面存在的问题;
   测试和评审中发现的信息未能得到进一步跟踪(如未改进开发和测试实践);
   对测试的态度或预期不合理(如:没有意识到在测试中发现缺陷的价值)。
   技术因素:
   不能定义正确的需求;
   给定现有限制的情况下，没能满足需求的程度;
   测试环境没有及时准备好;
   数据转换、迁移计划，开发和测试数据转换/迁移工具造成的延迟;
   低质量的设计、编码、配置数据、测试数据和测试。
   供应商因素:
   第三方存在的问题;
   合同方面的问题。

  在分析、管理和缓解这些风险的时候，测试经理需要遵循完善的项目管理原则。“软件测试文档 标准”(IEEE Std 829-1998)中指出，测试计划需要陈述风险和应急措施。

• 产品风险(5.5.2)
  在软件或系统中的潜在失效部分(即将来可能发生不利事件或危险)称之为产品风险，因为它们对产品质量而言是一个风险，包括:
   故障频发的软件交付使用;
   软件/硬件对个人或公司造成潜在损害的可能性;
   劣质的软件特性(比如功能性、可靠性、易用性和性能等);
   低劣的数据完整性和质量(例如:数据迁移问题、数据转换问题、数据传输问题、违反数 据标准问题);
   软件没有实现既定的功能。

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

  在项目初期阶段，使用基于风险的方法进行测试，有利于降低产品风险的级别。

  在基于风险的测试方法中，识别出的风险可以用于:
   决定采用的测试技术;
   决定要进行测试的范围;
   确定测试的优先级，尝试尽早的发现严重缺陷;
   决定是否可以通过一些非测试的活动来降低风险(比如对缺乏经验的设计者进行相应的培训)。

  风险管理活动提供了一些系统化的方法:
   评估(并定期重新评估)可能出现的错误(风险);
   决定哪些风险是重要的需要处理的;
   处理风险的具体措施。

事件管理(5.6)

• 事件报告的主要目标
  事件报告的主要目标如下:
   为开发人员和其他人员提供问题反馈，在需要的时候可以进行识别、隔离和纠正;
   为测试组长提供一种有效跟踪被测系统质量和测试进度的方法;
   为测试过程改进提供资料。

• 事件报告的具体内容
  事件报告的具体内容主要包括:
   提交事件的时间，提交的组织和作者;
   预期和实际的结果;
   识别测试项(配置项)和环境;
   发现事件时软件或系统所处的生命周期阶段;
   为了能确保重现和解决事件需要描述事件(包括日志、数据库备份或截屏);
   对利益相关者的影响范围和程度;
   对系统影响的严重程度;
   修复的紧迫性/优先级;
   事件状态(例如:打开的、延期的、重复的、待修复的、修复后待重测的或关闭的等);
   结论、建议和批准;
   全局的影响，比如事件引起的变更可能会对系统的其他部分产生影响;
   变更历史记录，比如针对事件的隔离、修改和已修改的确认，项目组成员所采取的行动顺序;
   参考，包括发现问题所用的测试用例规格说明的标识号。

  事件报告的大纲也可以参考“软件测试文档标准”(IEEE Std 829-1998)。

软件测试工具(6)

测试工具的类型(6.1)

测试工具大体上可分为三类：

1. 功能测试工具
2. 性能测试工具
3. 测试管理工具

• 测试管理(6.1.3)

  • 测试管理工具

  • 需求管理工具

  • 事件管理工具

  • 配置管理工具

• 静态测试(6.1.4)

  • 评审工具

  • 静态分析工具

  • 建模工具

• 测试规格说明(6.1.5)

  • 测试设计工具

  • 测试数据准备工具

• 测试执行和记录(6.1.6)

  • 测试执行工具

  • 测试用具/单元测试框架工具

  • 测试比较器

  • 覆盖率测量工具

  • 安全性测试工具

• 性能和监控(6.1.7)

  • 动态分析工具

  • 性能/负载/压力测试工具

  • 监控工具

• 特定应用领域(6.1.8)

  • 数据质量评估

有效使用工具(6.2)

• 潜在的收益与风险(6.2.1)

  • 潜在收益
    使用工具的潜在收益包括:
     减少重复性的工作(比如，执行回归测试，重新输入相同测试数据，代码规则检查);
     更好的一致性和可重复性(比如，用工具按照相同的顺序和频率执行测试，从需求生成测试);
     客观的评估(比如，静态测量、覆盖率);
     容易得到测试和测试的相关信息(比如，关于测试进展的统计和图表，事件发生率和性能)。

  • 潜在风险
    使用工具存在的风险:
     对工具抱有不切实际的期望(包括功能性和易用性);
     低估首次引入工具所需的时间、成本和工作量(包括培训和额外的专业知识);
     低估从工具中获得较大和持续性收益需要付出的时间和工作量(包括使用工具的方式需要更改测试过程，并不断改进);
     低估了对工具生成的结果进行维护所需的工作量;
     对工具过分依赖(替代测试设计或者对一些更适合手工测试的方面却使用自动测试工具);
     忽视了在工具中对测试对象的版本控制;
     忽视了多个重要工具之间的关联和互操作性，例如:需求管理工具、版本控制工具、事件管理工具、缺陷跟踪工具和其他从不同供应商获得的工具;
     工具供应商破产、停止维护工具或将工具卖给其他供应商的风险;
     供应商对工具的支持、升级和缺陷修复反应不力;
     开源/免费工具项目中止的风险;
     其他不可预知的风险，例如不能支持新平台。

• 工具类型的特殊考虑(6.2.2)

  • 测试执行工具
    注意：

    1. 所有的测试方法都需要脚本语言方面的技术专家(或测试员或测试自动化专家)。
    2. 无论使用什么脚本技术，都需要储存每次测试的预期结果，便于后续比较。

    • 自动化测试
      正确认识自动化测试：

      1. 为了获得可观收益，经常需要为这类工具投入很多工作量。
      2. 通过记录测试员手动操作的捕捉过程往往开始看起来似乎很吸引人，但是这种方法不适合大量的自动化测试。捕获的脚本只是用特定数据和动作来线性表示每个脚本的一部分。当发生意外事件时，这类脚本是不稳定的。

    • 数据驱动技术

      1. 数据驱动的方法是将测试输入(数据)与测试用例分离，并将测试输入存放在一个电子表格中，这样可以使用不同的数据进行相同的测试。
      2. 不熟悉脚本语言的测试员可以从一个表格内输入测试数据并执行事先定义好的测试脚本。

      注意：此方法需要脚本语言方面的技术专家。

    • 关键字驱动技术

      1. 在关键字驱动的测试方法中，电子表格含有描述系统要采取的行为的关键字(也称为行为字)和测试数据。
      2. 测试员(即使不熟悉脚本语言)也能针对被测应用，使用这些关键字来定义测试。

      注意：此方法需要脚本语言方面的技术专家。

  • 静态分析工具
    警告信息不阻碍代码转换成可执行程序，但理想情况是应予以处理，以便将来更容易进行代码的维护。
    在开始就有计划的逐步使用分析工具来过滤一些警告信息是一种有效的方法。

  • 测试管理工具
    测试管理工具需要有与其他工具和表格有接口，以便产生符合组织所需格式的有用信息。

组织内引入工具(6.3)

• 需要考虑的关键点
  为组织选择工具所需要考虑的关键点有:
   评估组织的成熟度、分析引入工具的优点和缺点和认识引入工具能改善测试过程的可能性;
   根据清晰的需求和客观的准则进行评估;
   概念验证，在评估阶段要确认在现有的情况下使用工具对被测软件是否有足够效果，或为了有效使用工具，目前的基础设施需要如何改变;
   评估供应商(包括培训、提供的支持及其他商业方面考量)，如果是非商业性工具要评估提供服务的供应商;
   为了在工具使用方面得到更好的指导和培训，需要先收集内部需求;
   评估培训需求时需要考虑现有测试团队的自动化测试技能;
   根据实际的情况估算成本-收益比。

• 试点项目的目的
  将选择的工具引入组织要从一个试点项目开始，试点项目有以下目的:
   对工具有更多的认识;
   评估工具与现有的过程以及实践的配合程度，确定哪些方面需要作修改;
   定义一套标准的方法来使用、管理、储存 和维护工具及测试资产(比如，定义文件和测试的命名规则、创建库和定义模块化测试套件);
   评估在付出合理的成本后能否得到预期的收益。

• 成功部署的因素
  在组织内成功部署工具的因素包括:
   逐步在组织的其余部分将工具推广到测试中;
   调整并改进过程来配合工具的使用;
   为新使用者提供培训和指导;
   定义使用指南;
   实施一种在实际运用中收集工具使用情况的方法;
   监控工具的使用和收益情况;
   为测试团队使用工具提供支持;
   在所有团队内收集经验和教训。