软件测试的组织和管理 山东省软件评测中心 韩庆良

目标 与软件企业项目管理人员、测试管理人员对测试管理进行交流。 提高对测试工作、测试管理的重要性的认识，以改进我们的测试过程。 从理论角度来认识软件测试和测试管理。

主要内容 团队建设（组织结构、人员组成、规模、人员培训） 过程规划（软件过程、测试过程、测试的阶段、规划自己的过程） 测试过程实施（计划、设计、实施、执行、评估、缺陷跟踪） 过程改进（成熟度模型、改进） 测试工具

（一）团队建设 测试部门的组织形式 测试组的人员组成 测试组的规模 测试人员的培训

组织形式－测试人员的位置 一个好的组织结构，可以更好的发挥人员的能动性，使工作更有效率，也使工作的质量更高。 在一个单位内测试人员处于什么位置？属于那个部门？ 质量管理？ 开发组？ 测试组？ 适用的就是最好的。

组织形式－常见测试组组织结构 烟囱测试组（小型） 烟囱测试组（大型） 集中测试组 IV&V（独立验证与确认）测试组 SMT（系统方法与测试）组

组织形式－烟囱测试组 测试人员由临时人员组成，通常有2-5人组成，直接向项目经理负责。大型的组可以划分为几个小组，设测试经理。项目经理负责制定测试计划文档。企业没有正规的方法将测试程序、方法、相关的知识经验传递下去，测试质量难以保证。优点是成本低，不需要对测试人员提供培训、生活保障等服务。

组织形式－集中测试组 企业成立专职、独立的测试部门，通常由10－30人组成。集中测试组为每个项目配备几个全职的测试人员。部分企业中可能还负责执行项目中软件质量管理和性能规范制定的工作。可以将相关的知识、经验传递下去。

IV&V组－组织形式 通常由软件开发组织之外的人员或其中的独立人员组成，如转包商。其参与检查、验证是否遵循标准、进行软件文档的质量保证检测，主要完成系统测试。可以将其看作一个最苛求的用户。

组织形式－SMT组 通常作为企业的内部顾问组的方式存在。主要负责方法及标准的知识交流、编制开发和测试指南、开发测试方法、测试工具评估与培训，其同不同的项目组进行协作，对其进行指导。通常不负责具体测试工作的执行。由软件专家组成。

组织形式－企业或项目组织结构样例 微软的项目组织 产品组经理 项目经理 质量保证经理 开发经理 流程经理 设计经理 开发工程师 测试人员

组织形式－企业或项目组织结构样例 一种常见的组织

组织形式－企业或项目组织结构样例 又一

人员组成－成功测试组的10大因素 业务知识：测试工程师应具备业务知识，并和用户紧密接触。 技术知识：熟悉所测试的产品用到的技术，并掌握测试工具、方法等相关技术。 任务划分：将业务任务和技术任务相互独立。 资源管理：业务资源和技术资源相互结合。 与开发组的关系：同开发人员协同工作。 生存周期早期介入：测试应在开发周期的早期介入。 测试过程：有成熟的测试过程管理规范。 灵活性/适应性：能够适应不同的测试项目。 度量：掌握度量的方法，以改进工作。 过程改进：应致力于工作的不断改进。

人员组成－测试组组成 测试经理：负责测试流程、沟通、测试工具的引入、人员管理、测试计划/设计/开发及执行。 测试组长：沟通、测试工具引入、人员管理、费用/过程状态报告、测试计划/设计/开发及执行。 测试工程师：执行测试计划，进行设计/开发及执行。

测试组规模－影响因素 企业文化或测试成熟度 测试需求范围 工程师技能水平 测试工具及应用水平 业务知识 组织形式 测试工作介入时间

测试组规模－确定方法（一） 开发比例法：根据开发人员数量按照一定比例来确定测试工程师的数量。开发人员指进行设计、开发、编译以及进行单元测试的人员。 开发类型 开发人员 比例 测试组规模 商业产品（大型市场） 30人 3:2 20 商业产品（小型市场） 3:1 10 单个客户端的应用开发 6:1 5 单个客户端开发并与系统集成 4:1 7 政府部门应用开发（内部） 5:1 6 公司应用开发（内部）

测试组规模－确定方法（二） 百分比法：根据测试人员应该占到项目组中人员的百分比数量。 开发类型 项目人员数量 测试组规模比例 测试组规模 商业产品（大型市场） 50人 27％ 13 商业产品（小型市场） 16％ 8 单个客户端的应用开发 10％ 5 单个客户端开发并与系统集成 14％ 7 政府部门应用开发（内部） 11％ 公司应用开发（内部）

测试组规模－确定方法（三） 测试程序法：根据测试程序数量，以及每个程序可能的执行时间，计算出人小时，再根据完成周期计算测试组规模。 测试过程数目 计算因子 人小时 完成周期 测试组规模 历史记录 860 6.16 5300 9个月 3.4 新项目评估 1120 6900 12个月 3.3

测试组规模－确定方法（四） 任务计划法：根据历史记录中类似项目工作量，比较新项目同历史项目的工作量，历史项目乘以相应的因子。 步骤：先将任务分解，根据历史记录乘以一个因子，计算出新项目的所以任务工作量。再根据该工作量和完成周期计算测试组规模。

人员培养－人员要求 一个好的测试人员更难得 适应各种环境的知识背景 学习速度快 组织能力 解决问题的能力 创造性 分析/编程能力 业务领域的知识 交流与协调能力 测试经验 关注细节 书写与语法技能 一个好的测试人员更难得

人员培养－成长的路径 初级测试工程师－测试工程师－高级测试工程师－测试组负责人－测试负责人－测试经理－产品/业务经理。 技术技能：测试工具\测试自动化编程\编程语言\操作系统\网络、数据库\测试生存周期 （1-2年） 测试过程：评审、制订和改进过程，指导初级工程师工作，了解业务领域。 （3-4年） 测试组工作：任务安排、跟踪和报告，监管测试工程师，掌握测试周期支持工具。（4-6年） 项目管理：管理项目，与客户交流，管理测试人员。（6-12年） 产品管理：项目或产品研发指导、促进产品销售、确定业务机会、承担盈亏责任。（12年以上）

（二）测试过程规划 软件过程 测试过程 测试的阶段 规划测试过程

软件过程－定义 目的：测试过程是软件过程的组成部分，明确自己的软件过程，才能明确自己的测试过程。 软件生存周期指软件从出现一个构思之日起，直到最后决定停止使 用之时止。包括可行性与计划研究、需求分析、设计 、实现 、测试、运行与维护等阶段。 软件过程是指开发和维护软件及相关产品（如项目计划、文档、代码、手册等）的一套行为、方法、实践及变换过程。软件过程是软件生存周期的框架。

软件过程－常见软件过程与模型（一） 瀑布模型、原型模型、演化模型、增量模型、螺旋模型、喷泉模型等等。 敏捷方法（如XP、功能驱动等） 统一过程（RUP） 《GB/T 8566-2001 信息技术 软件生存周期过程》 过程裁减

软件过程－常见软件过程与模型（二） 敏捷方法中的测试：在极限编程中提出测试驱动开发。提倡在开发前，先考虑测试，先完成测试用来和代码。 统一过程中的测试：测试是其核心工作流程之一 GB/T 8566-2001标准中的测试（如下图）： 没有单独的测试过程。 测试开始于编码。 不足以指导测试工作。

测试过程－测试生命周期 开发生命周期 测试生命周期 ... 维护 需求定义 应用定义 应用开发 修订 建立 执行. 执行 测试计划 缺陷跟踪 测试开发 测试设计 评估

测试过程－几个亮点 测试工作开始于需求分析之后。 测试经过评估后，达到了结束的标准后才能结束。 测试也是迭代过程。 测试需求来自于软件需求。

测试过程－活动 计划 设计 准备 执行 评估 缺陷跟踪

测试过程－与开发过程的关系 都是软件过程的有机组成部分。 与开发过程同步进行。 与开发过程相互依赖，又相互独立。‘ 开发过程、测试过程、项目管理过程以及其他支撑过程相互交织共同组成了软件过程。

测试阶段－V模型

测试阶段－四个阶段 清晰直观 阶段划分 单元测试 集成测试 系统测试 验收测试 同开发的对应关系

测试阶段－甄别 开发和测试并不是线性关系。 测试工作不是开始于代码完成之后。 测试具有阶段性，但各阶段之间没有鸿沟。尤其是单元测试和集成测试。

规划测试过程 分析项目总体需求（概览） 分析项目特点（如类型、规模、人员、客户、风险、进度、成本等等） 确定自己的软件过程 确定自己的开发方法和模型 规划测试阶段 构建测试过程

（三）测试过程实施 制订测试计划 设计测试 测试准备 执行测试 评估测试结果 缺陷跟踪

制订测试计划－定义 什么是测试计划：测试计划包含项目范围内的测试目的和测试目标的有关信息。此外，测试计划还将确定实施和执行测试时所使用的策略以及所需资源。测试计划包括测试主计划和阶段计划。 项目开始时制订测试主计划。根据开发的迭代过程和测试主计划对测试计划进行细化，制订各个阶段的测试计划。

制订测试计划－内容 1. 简介(目的、背景、范围、使用的文档） 2. 测试需求（确定被测试的对象、内容和范围，来源于用户需求，包括功能性需求和非功能性需求。） 3. 测试策略 测试的项目、测试的主要方法、完成标准、使用的工具、特殊事项等） 4. 资源（人员组成、任务和职责、环境、人员培训等） 5. 项目进度表（阶段） 6. 可交付工件（测试模型、测试记录、缺陷报告等等） 7. 附录 A：项目任务

制订测试计划－步骤（一） 确定测试需求：确定测试对象以及测试工作的范围和内容。测试需求应是可核实的。测试需求可来源于软件需求列表、用例、用例模型、用例实现、补充规约、设计需求、商业理由、法规、标准、最终用户访谈以及对现有系统的复审。 被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。

制订测试计划－步骤（二） 评估风险：测试工作需要平衡资源约束和风险，以确定测试的优先级。从三个方面分析： 影响:失效后将造成的影响或后果 原因:失效所导致的非预期结果 可能性:用例失效的可能性 根据风险分析情况，确定测试执行的优先级。通常分为高、中、低三种。进而安排测试的先后顺序。

制订测试计划－步骤（三） 制定测试策略：描述测试活动的一般方法和目标。包括测试的阶段、类型、技术、测试完成的标准、特殊要求、可能存在的影响等。 确定资源 人力资源（人员数量和技能） 测试环境（包括硬件和软件） 工具 数据 创建时间表：估计测试工作，制订时间进度。参考软件开发进度、项目工作计划等。 生成测试计划 ：复审相关材料，确定交付的内容，将计划提交相关的人员。

制订测试计划－主计划和阶段计划 阶段计划的测试需求应是对主计划中的测试需求的分解。 阶段计划的工作进度安排应尽可能同主计划相一致。 阶段计划的制订应能保证主计划能够完满执行。

测试设计（一） 分析程序工作流程。目的在于确定并说明系统与外部交互时的操作和步骤。以进一步用于确定与描述测试用例。 确定并说明测试用例 详细分析应用程序工作流程与操作步骤。 确定测试用例数据

测试设计（二） 确立并结构化测试执行过程 确定本测试执行过程与其他测试执行过程（或生成的测试脚本之间）的关系或顺序。 确定本测试执行过程的起始条件/状态与结束条件/状态。 指明本测试执行过程（或生成的测试脚本）要执行的测试用例。 结构化的方式固化测试执行过程。

测试设计（三） 复审并评估测试覆盖 确定测试覆盖评测方法：基于代码覆盖和基于需求的覆盖。基于代码覆盖的方法只有在代码完成后才能进行。 生成测试覆盖报告

测试准备 记录、生成或通过编程创建测试脚本 确定软件设计与实施模型中的专用于测试的功能。 建立外部数据集 桩模块与驱动模块设计 执行前的准备工作

执行测试 单元测试和集成测试时有开发人员的参与可能更有效，但应避免开发人员测试自己的程序。 验收测试应由测试组、用户和相关的专家完成。 测试的执行应该遵循如下的过程：设置测试环境，执行测试过程，核实测试结果，评估测试的执行情况。

评估测试结果 分析测试结果并提交变更请求 评估基于需求的测试覆盖 评估基于代码的测试覆盖 分析缺陷 确定是否达到了测试的完成标准和成功标准 生成测试评估摘要

缺陷跟踪 缺陷等级（严重、主要、次要、轻微等）与优先级（高、中、低等）分类 缺陷修改应遵循一定的流程（提交－任务分配－修改－回归测试） 缺陷趋势分析 不易修改的缺陷的处理

配置管理 主要实现软件版本控制和软件变更管理 测试过程中形成的文档、用例、数据、测试用程序等也存在配置管理的问题 应和开发中的配置管理共同进行，并互相关联。

过程改进－测试能力成熟度模型 优化、缺陷预防 和质量控制 管理与度量 集成 阶段定义 初始

过程改进－测试能力成熟度等级一 无序 测试和调试没有区分 测试只在编码后进行 无专业的测试人员/没有测试工具 测试的目的是为了证明软件和系统能够正常工作。

过程改进－测试能力成熟度等级二 将测试同调试区分开来 测试是编码后的一个已定义的阶段 具有基本的测试方法和技术以及标准的测试过程 测试的目的是为了确认程序能够满足要求

过程改进－测试能力成熟度等级三 测试分布于软件的整个生命周期 有固定的测试组织（能够提供人员培训、监督和控制测试过程、引入自动化测试工具） 基于系统需求进行测试 管理层已认识到测试是一项专业性的活动

过程改进－测试能力成熟度等级四 测试是一个可测量和量化的过程 产品的质量特性如可靠性、可用性、可维护性等都被测试 测试用例被良好的管理并可重用 发现的缺陷被记录，并按照严重程度、修改的优先级进行分类

过程改进－测试能力成熟度等级五 测试在组织内已被制度化 测试过程得到良好的管理 测试的成本和有效性得到监测 测试中主要用自动化的工具来完成 已建立选择和评估测试工具的流程

过程改进－度量 工作效率 测试覆盖 缺陷（发现的数量、修改的数量） 错误成本 测试成本 …… ……

测试管理工具 主要功能 常见工具 测试需求和计划组织、测试资源（如文档、脚本、程序）管理、和其他工具集成。 MI TestDirector Compuware QADirector Rational TestManager

谢谢参与！