CSTQB培训心得

1、刘菊华刘菊华ISQTB初级认证培训心得目录目录 一一、软件测试基础软件测试基础 二、软件生命周期中的测试二、软件生命周期中的测试 三、静态测试技术三、静态测试技术 四、测试设计技术四、测试设计技术 五、软件测试管理五、软件测试管理 六、软件测试工具六、软件测试工具目录目录n 什么是测试什么是测试n 测试的总体目标测试的总体目标n 测试的基本原则测试的基本原则n 基本的测试过程基本的测试过程什么是测试？什么是测试？n定义： 在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是 否能满足设计要求进行评估的过程。n测试包含：n测试执行之前和之后的一些活动，包括计划与控制、选择测试条件

2、、设计与执行测试用例，检查测试结果、评估出口准则、报告测试过程及被测系统、在一个测试阶段完成后要进行测试结束和总结工作。n测试同时也包括文档的评审（包括源代码）和执行静态分析。n测试分为动态分析和静态分析两种手段软件测试程序测试什么是测试什么是测试什么是测试测试测试静态分析静态分析（不运行软件）（不运行软件）动态分析动态分析（运行软件）（运行软件）静态测试技术静态测试技术评审评审软件测试的总体目标软件测试的总体目标n总体目标n发现缺陷n获取对产品质量的信心n提供用于决策的信息n预防缺陷早期测试开发阶段的测试运行阶段的测试静态测试组件测试集成测试系统测试验收测试非功能测试维护测试预防缺陷发现缺陷

3、建立信心提供信息软件测试的原则软件测试的原则 测试显示存在缺陷测试可以显示存在缺陷，但不能证明系统不存在缺陷。测试可以减少软件中存在未被发现缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。 穷尽测试是不可行的除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不可行的。通过运用风险分析和不同系统功能的测试优先级，来确认测试的关注点，从而替代穷尽测试 测试尽早介入为了尽早发现缺陷，在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已定义的测试目标上 缺陷集群性测试工作的分配比例应该与预期的和后期观察到的缺陷分布模块相适应，少数模块通常都

4、包含大部分在测试版本中发现的缺陷或失效。 杀虫剂悖论采用同样的测试用例多次重复进行测试，最后将不再能够发现缺陷。为了克服这种“杀虫剂悖论”，测试用例需要进行定期评审和修改，同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷。 测试活动依赖于测试背景针对不同的测试背景，进行不同的测试活动，比如：对安全关键的软件进行测试，与对一般的电子商务软件的测试是不一样的。 不存在缺陷（就是有用系统）的谬论假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的软件测试的基本过程软件测试的基本过程n软件测试计划和控制n测试分析和设计n测试实现和执行

5、n评估出口准则和报告n测试结束活动 开始结束测试计划跟踪控制分析与设计实现与执行评估与报告完成测试测试计划测试进度表测试设计规格说明测试用例规格说明测试规程规格说明测试日志/事件报告.测试总结报告二、软件测试与软件生命周期二、软件测试与软件生命周期北京昱达环球科技有限公司北京昱达环球科技有限公司 版权所有版权所有目录目录n 软件开发模型软件开发模型n 软件测试级别软件测试级别n 软件测试类型软件测试类型n 维护性测试维护性测试瀑布模型瀑布模型n模型特点n将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这几个阶段，规定了它们自上而下、相互衔接的固定次序，

6、如同瀑布流水逐级下落。需求分析设计实施测试维护V模型模型W W模型模型迭代迭代-增量增量模型分析模型分析n在每次迭代过程中,对迭代产生的系统可能需要在不同的测试级别上进行测试。n通过将增量模块加入到以前开发的模块中，形成一个逐渐增大的系统，这个系统同样需要进行测试。n在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。n验证和确认可以在每个增量模块中进行。 不同测试类型之间的关系不同测试类型之间的关系软件测试测试级别运行软件查看代码测试类型组件测试集成测试系统测试验收测试动态测试静态测试黑盒测试白盒测试功能性测试非功能性测试结构性测试维护测试变更相关的测试确认测试（再测试）回归测试各

7、种测试级别与测试方法对比分析各种测试级别与测试方法对比分析测试级别测试级别测试目的测试目的执行者执行者测试环境测试环境测试方法测试方法单元测试单元测试从单个模块中发现逻辑、数据和运算缺陷 软件开发者单独的；桩和支撑程序白盒测试集成测试集成测试发现模块间接口缺陷软件开发者单独的和/或模拟；桩和支撑程序白盒测试，黑盒测试系统测试系统测试 测定软件是否满足需求软件测试者实 际 的 环 境（可能没有最终的硬件）黑盒测试，白盒测试回归测试回归测试确认软件经过一些小的变更或修改后是否仍满足所有的需求软件测试者实 际 的 环 境（可能没有最终的硬件）黑盒测试验收测试验收测试确定软件是否满足客户的需求客户，软

8、件质 保 组 和 /或项目组实 际 的 环 境（通常在客户方）黑盒测试（客户可能有自己的测试方法）维护性测试概述维护性测试概述n维护性测试n修改：功能增强、纠正错误、环境变化、安全漏洞n移植：从一个平台移植到另外一个平台n退役：数据移植测试或者存档测试n维护性测试和可维护性测试的区别n维护性测试，由于维护开发,例如修改、拓展、移植及部分软件的退役等都只是基于原系统的改动,并未从根本上改变系统。n针对维护开发而进行的测试，完全可以遵从对原系统开发过程中测试的流程，如组件测试、集成测试、系统测试和验收测试。n可维护性测试是仅针对系统是否易于维护而开展的测试。测试技术（静态测试和动态测试）测试技术（

9、静态测试和动态测试）n静态测试和动态测试的区别：是否执行被测试软件n动态测试和静态测试这两种手段都可以提供信息来改进被测试软件系统的质量，以及改善开发和测试的过程。 功过手工检查（评审）或自动化分析（静态分析）的方式对文档进行检查 直接发现缺陷（引起失效的原因） 发现的缺陷类型：与标准之间的偏差、需求内的错误、设计的错误、接口规格说明错误等 通过执行被测软件对软件进行检查 发现失效（缺陷的外部表现） 发现的缺陷类型：软件运行过程中与规格说明、用户需求之间的偏差静态测试静态测试动态测试动态测试三、软件静态测试技术三、软件静态测试技术北京昱达环球科技有限公司北京昱达环球科技有限公司 版权所有版权所

10、有目录目录n 静态测试技术概述静态测试技术概述n 静态测试分类静态测试分类n 评审过程评审过程n 评审原则及类型评审原则及类型静态测试技术概述静态测试技术概述n概述n静态测试技术通过手工检查（评审）或自动化分析（静态分析）的方式对代码或者其他的项目文档进行检查而不需要执行代码。n静态测试分为评审和静态分析两种形式 n评审n评审是对软件工作产品（包括代码）进行测试的一种方式，可以在动态测试执行之前进行。n在生命周期早期的评审过程中发现并修改缺陷（例如发现需求中的缺陷）的成本会比在动态测试中才发现并修改这些缺陷的成本低的多。 n静态分析n工具支持的静态测试技术称为静态分析。n依据程序内部逻辑结构相

11、关信息，使用工具软件对程序的所有逻辑路径进行测试，检查程序源代码确定实际的状态与预期的状态一致。n静态分析的目的是发现软件源代码和软件模型中的缺陷。 静态测试分类静态测试分类静态测试技术评审工具支持的静态测试（静态分析）非正式评审正式评审走查技术评审审查评审过程评审过程n计划阶段n预备会阶段 n个人准备阶段（自评审） 定义评审标准选择人员分配角色为更加证实的评审类型（比如审查）制定入口和出口准则；选择需要进行评审的文档的内容核对入口准则（针对更正式的评审类型） 先行评审文档，为评审会议做准备 标注可能的缺陷、问题和建议 分发文档向评审参与者解释评审的目标、过程和文档评审过程（续）评审过程（续）

12、n检查/评价/记录结果（评审会议阶段）n返工阶段n跟踪结果阶段 讨论和记录，并留下文档化的结果或会议纪要（针对更正式的评审类型）；标注缺陷、提出处理缺陷的建议、对缺陷作出决策；在任何形式的会议期间或跟踪任何类型的电子通信期间检查/评价和记录问题； 作者根据评审记录对评审对象进行修改 主持人检查所有评审后的工作都已经到位 进行度量分析（例如，缺陷的密度、覆盖度、成本） 检查是否符合规定的结束评审条件 管理机构确定此次评审工作是否达到预期的目的评审的基本原则评审的基本原则n尽早开展评审活动n控制评审会议时间（2小时以内）n评审的是软件工作产品而不是作者n每个评审员都必须有机会充分表达各自的观点n发

13、现缺陷而不是修复缺陷n为发现的缺陷划分不同的严重级别评审的四种类型评审的四种类型审查审查：u专门培训的主持人来领导；u同行检查u引入了度量u根据入口、出口准则的检查列表和规则定义正式的评审过程；u出具审查报告和发现问题列表；u正式的跟踪过程；u主要目的：发现缺陷技术评审技术评审：u文档化和定义的缺陷检测过程，需要包含同行和技术专家u可能是没有管理者参与的同行评审u会议之前需要进行准备u准备评审报告，包括发现问题的列表、软件产品是否符合需求的判断，与发现的问题合适的建议u主要目的：讨论、作决评估候选方案、发现缺陷、解决技术问题、检查与规格及标准的符合程度；走查走查：u由作者主持开会u以场景、演示

14、的形式和同行参加的方式进行。u开放式模式u记录员是可选的u主要目的：学习、增加理解、发现缺陷非正式评审非正式评审：u没有正式的过程u可以是由程序猿的同行们或技术负责人对设计和代码进行评审u评审结果可以文档化u主要目的：以较低的成本获得收益由正式到非正式评审成功的因素评审成功的因素n每次评审都有预先明确定义的目标。n针对评审目标，有合适的评审人员的参与。n测试人员参加评审不但有利于提高评审质量，还可以通过评审了解产品，为测试尽早开始做准备。n对发现的缺陷持欢迎态度，并客观地描述缺陷。n能够正确处理人员之间的问题以及心理方面的问题（比如对作者而言，能让他觉得有积极正面的体验）。n评审应该在一种信任

15、的气氛中进行；并且结果不应用于对参与者的评价。n采用的评审技术适合于要达到的目标、软件工作产品的类型和级别以及参与评审人员。n选用合适的检查表或定义合适角色，可以提高缺陷识别的有效性。n提供评审技术方面的培训，特别是针对正式的评审技术，比如审查。n管理层对良好评审过程的支持（如在项目计划中安排足够的时间来进行评审活动）。n强调学习和过程的改进。四、软件测试设计技术四、软件测试设计技术目录目录n 软件测试的开发过程软件测试的开发过程n 测试设计技术测试设计技术n 基于规格说明或黑盒测试技术基于规格说明或黑盒测试技术n 基于结构的或白盒技术基于结构的或白盒技术n 基于经验的技术基于经验的技术软件测

16、试开发过程软件测试开发过程n测试分析阶段n在测试分析(test analysis)阶段，要对测试基础文档进行分析，从而决定测试什么，也就是明确测试的条件。n测试条件是能通过一个或多个测试用例进行验证的一个条目或事件（比如功能、事务处理、质量特征或结构元素等）。n建立从测试条件到需求的可追溯性，有助于需求变更时的影响分析(impact analysis)和测试用例集的需求覆盖率分析。 n测试设计阶段n在测试设计阶段，要定义和记录测试用例和测试数据。n完成测试设计规格说明（包含测试条件）和测试用例规格说明n预期的测试结果应该作为测试用例规格说明的一部分，同时包含输出、数据和状态的变化，以及其他的测

17、试结果。 软件测试开发过程（续）软件测试开发过程（续）n测试执行阶段n在测试实现阶段，测试用例的开发、实现、确定优先级和组织都应该包含在测试规程规格说明中。n测试规程（或者手工测试脚本）描述了测试用例执行的顺序。n如果使用测试执行工具(test execution tool)进行测试，这种测试的动作顺序将在测试脚本中描述（自动化的测试规程）。 n测试执行进度计划(test execution schedule) 。n不同的测试规程和自动化测试脚本要体现在测试执行进度计划(test execution schedule)中，该计划定义了不同测试规程和可能的自动化测试脚本的执行顺序、执行的时间和执

18、行者。n测试执行进度计划同时考虑了其他的因素，比如回归测试、测试优先级以及技术和逻辑的依赖等。 软件测试设计技术软件测试设计技术n测试技术分类n黑盒测试技术（基于规格说明的测试技术 ）n白盒测试技术（基于结构的测试技术）n基于经验的测试技术基于规格说明或黑盒测试技术基于规格说明或黑盒测试技术n等价类划分n有效等价类n无效等价类n边界值n临界值n刚好超出临界值n刚好小于临界值n决策表n包含触发条件，各种输入条件真假的组合以及相应的输出动作n覆盖标准通常是每列至少对应一个测试用例，用于覆盖触发条件的所有组合n用例（Use Case）测试n用例描述了参与者（包括用户与系统）之间的相互作用，并从这些交

19、互产生一个从系统用户或客户的角度所期望和能观察到的结果。 n根据业务流程，确定测试场景n状态转换测试n根据软件的状态、状态间的转换、触发状态变化（转换）的输入或事件以及从状态转换导致的可能的行动来进行测试。 结构性（白盒）测试结构性（白盒）测试n白盒测试主要是检查程序的内部结构、逻辑、循环和路径。白盒测试主要是检查程序的内部结构、逻辑、循环和路径。n白盒测试的常用测试用例设计方法：白盒测试的常用测试用例设计方法：n逻辑覆盖逻辑覆盖n基本路径测试基本路径测试n根据覆盖测试的目标不同，逻辑覆盖可分为根据覆盖测试的目标不同，逻辑覆盖可分为n语句覆盖语句覆盖n判定覆盖判定覆盖n条件覆盖条件覆盖n判定判

20、定- -条件覆盖条件覆盖n条件组合覆盖条件组合覆盖n路径覆盖路径覆盖 基于经验的测试方法基于经验的测试方法n错误推测法和探索性测试。五、软件测试管理五、软件测试管理北京昱达环球科技有限公司北京昱达环球科技有限公司 版权所有版权所有目录目录n 测试组织机构测试组织机构n 测试计划和估算测试计划和估算n 测试过程监控测试过程监控n 配置管理配置管理n 风险和测试风险和测试n 缺陷管理缺陷管理测试组织机构和测试独立性测试组织机构和测试独立性通过独立的测试员进行测试和评审，发现缺陷的效率会提供，可能的独立性测试如下：l不独立的测试员，开发人员测试自己的代码；l开发团队内独立的测试员；l组织内独立的测试

21、小组或团队，向项目经理或执行经理汇报；l来自业务组织、用户团体内的独立测试e员；l针对特定测试类型的独立测试专家，例如：可用性测试员、安全性测试员或认证测试（他们根据标准和法律法规对软件产品进行认证）；l外包或组织外的独立测试人员；独立测试优缺点优点：l独立的测试员是公正的，可以发现一些其他不同的缺陷；l一个独立的测试员可以验证在系统规格说明和实现阶段所做的一些假设；缺点：l与开发小组脱离（如果完全独立）；l开发人员可能丧失对软件质量的责任感；l独立的测试员可能被视为瓶颈或者成为延时发布而被责骂的对象；测试的角色和职责测试的角色和职责n角色n测试经理（测试组长）n测试员n说明n测试组长的角色有

22、时候也可以由项目经理、开发经理(Development manager)、质量保证经理(QA manager)或测试组的经理来担任。n在较大的项目中，常常会有两个职位：测试组长(test leader)和测试经理(test manager)。n这两个角色执行的活动和任务是由项目和产品的背景、人员的角色和组织结构来决定的。测试组长的职责测试组长的职责n与项目经理以及其他人共同协调测试策略和测试计划。n制定或评审项目的测试策略和组织的测试方针。n将测试的安排合并到其他项目活动中，比如集成计划。n制定测试计划（考虑背景，了解测试目标和风险等）。n创建测试规格说明、测试准备、测试实施和测试执行，监督测

23、试结果并检查出口准则。n根据测试结果和测试进度（有时记录在状态报告中）调整测试计划，必要时采取必要的措施对存在的问题进行补救。n对测试件进行配置管理，保证测试件(testware)的可追溯性。n引入合适的度量项以测量测试进度，评估测试和产品的质量。n决定哪些测试用例可以自动化执行，自动化的程度，如何实现。n选择测试工具支持测试，并为测试员组织测试工具的培训。n决定测试环境的实施。n根据在测试过程中收集的信息编写测试总结报告。 测试员的职责测试员的职责n职责n评审和参与测试计划的制定；n分析、评审和评估用户需求、规格说明书及模型的可测试性；n创建测试规格说明；n建立测试环境（通常需要系统管理员，

24、网络管理员协同完成）；n准备和获取测试数据；n进行所有级别的测试，执行并记录测试日志，评估测试结果，记录和预期结果之间的偏差；n对他人的测试进行评审；n根据需要使用测试管理工具和测试监控工具；n实施自动化测试（可能需要开发人员或测试自动化专家的支持）；n在可行的情况下，测量组件和系统的性能；单元测试阶段软件测试的不同阶段系统测试阶段集成测试阶段测试计划验收测试阶段测试计划可以在项目计划或总体测试计划中文档化，也可以在不同的测试级别的测试计划中文档化，如：u 单元测试计划u 集成测试计划u 系统测试计划u 验收测试计划测试计划文档的内容测试计划文档的内容n测试范围和风险，明确测试的目标n定义测试

25、的整体方法（测试策略），包括测试级别的定义、入口和出口准则(exit criteria)的定义。 n把测试活动集成和协调到整个软件生命周期活动中去：收集，准备，开发，运行和维护。 n决定测试什么？测试由什么角色来执行？如何进行测试？如何评估测试结果？n为测试分析和设计活动安排时间进度。 n为测试实现、执行和评估安排时间进度。n为已定义的不同测试任务分配资源。n定义测试文档的数量、详细程度、结构和模板。n为测试准备和执行的监控、缺陷解决(defect resolution)和风险问题(risk issues)选择度量项。n确定测试规程的详细程度，以提供足够的信息支持可重复的测试准备和执行。 n测

26、试过程的质量保证和配置管理。n应交付的测试工作产品。 测试工作量估算概述测试工作量估算概述n概述n软件测试工作进行WBS分解，通过分解定义的任务，并根据以前项目测试的经验和历史数据确定具体任务的工作量，根据工作量并结合企业生产率估算出成本。n一旦估算了测试工作量，就可以识别资源和建立时间进度表。 n测试工作量的内容n测试用例设计n测试环境设置n测试用例执行n测试缺陷报告n测试工作量的估算计量单位n人时n计算机硬件数量n计算机软件与测试工具数量测试工作量的决定因素和估算方法测试工作量的决定因素和估算方法n决定因素n产品的特点n测试模型(即如测试基础(test basis)使用的规格说明和其它信息

27、的质量、产品的大小(size)、问题领域(problem domain)的复杂度、可靠性(reliability)和安全性(security)方面的需求、对文档的需求等。n开发过程的特点n组织的稳定性(stability)、使用的工具、测试过程、参与者的技能水平和时间紧迫程度(pressure)等。n测试的输出n发现的缺陷数量和需要返工的工作量。 n估算方法n基于度量的方法n根据以前或相似项目的度量值来进行测试工作量的估算，或者根据典型的数据来进行估算。n基于专家的方法n由任务的责任人(owner of the task)或专家来进行测试任务工作量的估算。 测试过程进度监控的目的测试过程进度监

28、控的目的n目的n为测试活动提供反馈信息和可视性。n监控的信息可以通过手工或自动的方式进行收集，同时可以用来衡量出口准则(exit criteria)，比如测试覆盖率。n可以用度量数据对照原计划的时间进度和预算来评估测试的进度。n测试进度的跟踪控制的方法n里程碑管理法n关键路径法进行进度管理n对测试用例的执行进行跟踪 n测试用例执行直接关系到测试的效率、结果，不仅要做到测试效率高，而且要保证结果正确、完整。n对测试用例的执行进行跟踪可以保证测试执行的质量。n测试缺陷的跟踪和管理n每个bug包含的信息条目、状态分类等，通过日报、周报、阶段报告来跟踪目前bug状态，在里程碑阶段对bug进行评审n通过

29、一些历史曲线、统计曲线进行趋势分析。 测试过程的测试度量项测试过程的测试度量项n测试用例准备阶段工作所占时间的百分比（或按计划已编写的测试用例的比例）。n测试环境准备阶段工作所占时间的百分比。n测试用例执行量（例如：执行的测试用例数/没有执行的测试用例数，通过/失败的测试用例数）。n缺陷信息（例如：缺陷密度、发现并修改的缺陷、失效率、重新测试的结果）。n需求、风险或代码的测试覆盖率。n测试员对产品的主观信心。n测试中确定的里程碑的具体日期。n测试成本，包括寻找下一个缺陷或执行下一轮测试所需成本与收益的比较。 测试控制测试控制n概述n测试控制描述了根据收集和报告的测试信息和度量而采取的指导或纠正

30、措施。n措施可能包括任何测试活动，也可能包括任何软件生命周期中其他的活动或任务。n控制内容n基于测试监控信息来做决策。n如果一个已识别的风险发生（如软件发布延期），重新确定测试优先级。n根据测试环境可用性，改变测试的时间进度表。n设定入口准则n规定修改后的缺陷必须经过开发人员重新测试后才能将它们集成到版本中去。 测试报告测试报告n概述n测试报告是对测试工作和活动等相关信息的总结。n内容n在测试阶段发生了什么？比如达到测试出口准则的日期。n通过分析相关信息和度量可以对下一步的活动提供建议和做出决策n比如对仍然存在的缺陷的评估、继续进行测试的经济效益、存在的突出风险以及被测试软件的置信度(leve

31、l of confidence)等。n进行和完成某个测试级别时的度量内容n该测试级别的测试目标的充分性。n采用的测试方法的适当性。n针对测试目标的测试的有效性。 软件配置管理概述软件配置管理概述n目的n在项目和产品的生命周期内建立和维护软件或系统产品（组件、数据和文档）的完整性。n软件测试配置管理的目的n标识出所有测试件(testware)，版本控制，跟踪相互之间有关联以及和开发项（测试对象）之间有关联的变更，从而在测试过程中可以维持可追溯性。n在测试文档中，所有被标识的文档和软件项能被清晰明确的引用。n帮助测试员唯一地标识（并且复制）测试项(test item)、测试文档、测试用例和测试用具

32、(test harness)。 n说明n在测试计划阶段，应该选择配置管理的规程和基础设施（工具），将其文档化并予以实施。软件配置管理的内容和工具软件配置管理的内容和工具n配置管理的内容 n识别配置项n建立配置管理系统n建立基线(版本管理)n配置状态报告和配置审计n变更控制管理。 n测试人员在软件配置管理中的主要工作n根据配置管理计划和相关规定，提交测试配置项和测试基线；n负责软件变更的测试验证n软件配置管理工具nRational ClearCase、Borland StarTeam、PVCS、Visual SourceSafe、CVS,SubVersion等。 nSourceSafe是Micr

33、osoft公司推出的配置管理工具，是Visual Studio的套件之一。 nSourceSafe是通过“共享目录”方式存储文件的，因此适合于局域网内的用户群，不适合于通过Internet连接的用户群 风险管理概述风险管理概述n风险概述n风险可以定义为事件、危险、威胁或情况等发生的可能性以及由此产生不可预料的后果，即一个潜在的问题。n风险级别由出现不确定事件的可能性(likelihood)和出现后所产生的影响（事件引发的不好的结果）两个方面来决定。 n软件风险的定义n软件项目风险是指在软件开发过程中可能会发生的质量、成本和进度等方面的问题以及这些问题对软件项目的影响。n产生软件测试风险的因素n

34、测试计划的不充分n测试方法有误或测试过程的偏离，造成测试的不足以及结果不准确。n测试的不成功导致软件交付潜藏着问题，一旦在运行时爆发，会带来很大的产品风险。n软件项目风险的影响n如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。风险分类风险分类n项目风险n项目风险是指关于项目按目标交付的能力方面的风险。n如用户需求不明确，项目组未正确理解客户需求，缺乏项目管理经验，资源冲突，进度延误等。n产品风险n在软件或系统中的潜在失效的区域（即将来可能发生的不利事件或危险）称之为产品风险，因为它们对产品质量而言是一个风险。n交付后的产品存在问题而导致的风险。n缺陷导致人

35、员的伤害、企业的财政损失、功能失效、性能不良等。n产品风险对于项目的成功来讲是一种特殊类型的风险。n作为一种风险控制活动，测试通过评估修正严重缺陷的能力和应急计划的有效性来提供关于残留风险的反馈信息。 影响项目风险的因素影响项目风险的因素n组织方面：n员工缺少应有的资质或者员工数量不足n人员缺少必要的培训n人员交流的问题n与测试员进行需求和测试结果沟通方面存在的问题。n测试和评审中发现的信息未能得到进一步跟踪（如未改进开发和测试实践）。n缺乏项目管理经验n对测试的态度或预期不合理（如：认为在测试中发现缺陷是没有价值的）。n技术方面：n如用户需求不明确，项目组未正确理解客户需求n在经验不足的情况

36、下，适用新技术、新工具、新方法n设计、开发和测试的质量n变更技术方案、软件产品出现性能问题n供应商方面：n分包商无法按期、按质的交付产品n合同问题产品风险的产生因素和表现产品风险的产生因素和表现n易错(failure-prone)的软件交付使用。n软件/硬件对个人或公司造成伤害的可能性。n劣质的软件特征（比如功能性、可靠性、可用性和性能等）。n低劣的数据完整性和质量（例如：数据迁移问题、数据转换问题、数据传输问题、违反数据标准问题）。n软件没有实现既定的功能。 测试风险管理的主要过程测试风险管理的主要过程n风险管理的过程n风险识别，定性、定量风险分析，风险应对计划制定和风险监控。n风险识别：n

37、风险识别是一个连续的过程，贯穿软件项目的整个生命周期。n识别风险的方法：n根据专家们的经验n独立的评定n使用风险模板n风险专题讨论会n自由讨论/头脑风暴n核查表(Checklist)n根据以往项目的经验软件测试风险应对的措施软件测试风险应对的措施n风险规避n有些风险可能带来的后果非常严重，可采取措施将其转换为不会引起严重后果的低风险。n例如，对于测试环境需要复杂配置时，可以在测试环境配置好后，使用事先列出的核查表(Checklist)进行逐项检查，检查其是否满足要求，规避由于测试环境配置不正确引起的测试风险。n风险转移n例如，产品发布前忽然发现某个不是很重要的新功能，给原系统带来一个严重的bu

38、g，这时处理这个bug所带来的风险就很大，应对策略是去掉那个新功能，转移这种风险。n降低风险n有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，就要通过提高测试用例的覆盖率（如达到99）来降低这种风险。n说明n为了避免、转移、降低风险，事先应做好风险管理计划n对风险的处理还应制定应对缓解计划和方案，并实施跟踪管理。 基于风险的软件测试基于风险的软件测试n概述n基于风险的测试方法能够在项目初期阶段的开始就主动提供降低产品风险级别的方法 。n它包括对产品风险的识别以及在考虑了这些风险的情况下指导测试计划和测试控制、以及规格说明、测试准备和执行。n基于风险的测试依赖于项目利

39、益相关者的集体智慧和对业务的理解，从而来决定风险和针对这些风险需要采用的测试级别。 n在基于风险的测试方法中，识别出的风险的用途n决定采用何种测试技术。n决定要进行测试的范围。n为了尽早的发现严重的缺陷，确定测试的优先级。n决定是否可以通过一些非测试的活动来减少风险（比如对缺乏经验的设计者进行培训）。 n减少软件产品风险的管理方法n评估（和定期重新评估）可能出现错误处（风险）。n确定哪些风险需要处理。n实施处理这些风险的措施。n测试可以识别新的风险，有助于确定应该降低哪些风险，以及降低风险的不确定性。 软件测试缺陷管理概述软件测试缺陷管理概述n概述n对缺陷进行管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。n在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程。 n事件与缺陷n事件（Incident）是意外发生并需要进一步调查的