测试计划与测试管理.ppt

第七章 测试计划与测试管理,7.1 测试文档和测试计划,7.1.1 测试计划概述 7.1.2 测试计划的主要内容 7.1.3 编写合适有效的测试计划必须考虑的问题,7.1.1测试计划概述,什么是测试计划：测试计划包含项目范围内的测试目的和测试目标的有关信息。此外，测试计划还将确定实施和执行测试时所使用的策略以及所需资源；以及对测试风险等做出预先的计划和安排 测试计划包括测试主计划和阶段计划。 项目开始时制订测试主计划。根据开发的迭代过程和测试主计划对测试计划进行细化，制订各个阶段的测试计划。,测试计划概述（续）,制定测试计划的目的 一个计划一定是为了某种目的而产生的，对于软件质量管理而言，制定测试计划的目的主要有3个。 1使软件测试工作进行更顺利 2促进项目参加人员彼此的沟通 3使软件测试工作更易于管理,测试计划概述（续）,制定测试计划的原则 制定测试计划是软件测试中最有挑战性的一个工作。以下原则将有助于制定测试计划工作。 1制定测试计划应尽早开始 2保持测试计划的灵活性 3保持测试计划简洁和易读 4尽量争取多渠道评审测试计划 5计算测试计划的投入,7.1.2 测试计划的主要内容,1 范围 1.1 标识 1.2 系统概述 1.3 文档概述 1.4 与其它计划的关系 2 引用文档 3 软件测试环境 3.1 软件项 3.2 硬件和固件项 3.3 权限 3.4 安装、测试与控制,4 正式合格性测试 4.X （CSCI 名称和项目唯一标识号） 4.X.1 总体测试要求 4.X.2 测试类 4.X.3 测试级 4.X.4 测试定义 4.X.4.Y （测试名称和项目唯一标识号） 4.X.5 测试进度 5 数据记录、整理和分析,测试计划主要内容(续),1 范围 1.1 标识 列现本文档的： a 已批准的标识号； b 标题； c 缩略语； d 本文档适用的系统和计算机软件配置项（CSCI）。如果本文档适用于系统中所有的CSCI，则也要说明。并用标题、缩略语和标识号写出适用的CSCI。,CSCI是计算机软件配置项(Computer Software Configuration Item), CSC是计算机软件部件(Computer Software Component), CSU是计算机软件单元(Computer Software Unit). HWCI (HardWare Configuration Item) 硬件配置项. 项目测试过程中会产生许许多多的工作成果，例如测试计划文档、测试用例以及自动化测试执行脚本和测试缺陷数据等，他们都应当被保存起来，以便查阅和修改。这些纳入配置管理范畴的工作成果统称为配置项(Configuration Item，CI)，每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。,测试计划主要内容(续),1.2 系统概述 概述本文档所适用的系统和CSCI 的用途。 1.3 文档概述 概述本文档的用途和内容。 1.4 与其它计划的关系 概述本计划与其它项目测试计划的关系。,测试计划主要内容(续),2 引用文档 按文档号和标题列出本文档引用的所有文档。 3 软件测试环境 分节标识和描述为执行正式合格性测试所使用资源（软件、固件和硬件）的实现和控制计划。为减少重复，对在软件测试环境和软件工程环境中均用到的资源，可以引用在“软件开计划”文档中有关的软件工程环境的描述。,测试计划主要内容(续),3.1 软件项 标识用于执行正式合格性测试的软件项（如，操作系统、编译器、编码审核器、动态路径分析器、测试驱动器、预处理器、测试数据产生器、后处理器），描述并说明每个软件项的用途、保密处理和安全性问题。 3.2 硬件和固件项 标识用于软件测试环境的计算机硬件、接口设备和固件项。描述并说明每个项目的用途、保密处理和安全性问题。,测试计划主要内容(续),3.3 权限 标明软件测试环境相关的每个项目的专利和权限。 3.4 安装、测试与控制 本节应标识承制方为安装和测试每个项目所制订的计划，还应要描述承制方为控制和维护软件测试环境而制订的计划。,人员人数、经验和专长。他们是全职、兼职、业余还是学生？ 设备计算机、测试硬件、打印机、测试工具等。 办公室和实验室空间在哪里？空间有多大？怎样排列？ 软件字处理程序、数据库程序和自定义工具等。 其他资源软盘、电话、参考书、培训资料等。,测试计划主要内容(续),测试计划主要内容(续),4 正式合格性测试 分节对每个正式合格性测试进行说明，并描述软件测试计划对每个CSCI 作正式合格性测试的要求。 4.X （CSCI 名称和项目唯一标识号） 从4.1 节开始编号。用名称和项目的唯一标识号标识CSCI。 4.X.1 总体测试要求 从4.1.1 开始编号。描述用于所有正式合格性测试或用于一组正式合格性测试的要求。例如：每个正式合格性测试都需要满足下列一般要求：,测试计划主要内容(续),a 测量CSCI 的大小和执行时间； b 用假设值、最大值和错误值作为输入对CSCI 进行测试。 c 对CSCI 进行错误判断和出错恢复的测试，包括相关的错误信息。 对不同的实际问题应外加相应的专门测试。例如，验证雷达跟踪要求的正式合格性测试需满足下列要求： （1）对特定环境条件的组合，用模拟数据对CSCI 进行测试； （2）用从该环境中提取的“真实数据”作为输入，对CSCI 进行测试。,测试计划主要内容(续),4.X.2 测试类 从4.1.2 节开始编号。描述要进行的正式合格性测试的种类或类型（如：强度测试、时间性测试、错误输入测试、最大能力测试等）。 4.X.3 测试级 从4.1.3 节开始编号。描述要进行的正式合格性测试的级别，例如： aCSCI 级（如果需要，也可划分为CSC 或CSU 级）：评测与CSCI 要求的符合程度； bCSCI 到CSCI 集成级：评测与CSCI 外部接口要求的符合程度；,测试计划主要内容(续),cCSCI 到HWCI 集成级：评测与CSC 外部接口要求的符合程度； d系统级：评测与整个系统CSCI 要求的符合程度。 4.X.4 测试定义从4.1.4 节开始编号。分节标识和描述用于CSCI 的各项正式合格性测试。 4.X.4.Y （测试名称和项目唯一标识号） 从4.1.4.1 节开始编号。用测试名和项目唯一标识号标识正式合格性测试。 本切要给出下列用于测试的信息，这些信息的一部分或全部可以用图表给出，如： a 测试对象； b 特殊要求（如：48 小时设备连续运行）； c 测试级；,测试计划主要内容(续),d 测试种类或类型； e 在软件需求规格说明中规定的合格性方法； f 该测试所涉及的软件需求规格说明对CSCI 工程需求的交叉引用； g 该测试所涉及的接口需求规格说明对CSCI 接口需求的交叉引用； h 记录的数据类型； i 假定和约束条件。 4.X.5 测试进度 说明或引用本文档4.X.4 的测试进度。 5 数据记录、整理和分析 分节描述按本测试计划所作测试的数据整理和分析过程。并说明根据数据整理和分析得到的信息和结果。数据记录、整理和分析的结果应清楚地显示出是否达到测试目标。,7.1.3 编制合适有效的测试计划考虑的问题,1 了解手头的任务和相关的测试目标 2 考虑风险 3 根据功能优先级安排测试工作 4 规划测试环境,1了解手头的任务和相关的测试目标,Step1:了解手头的任务、它的范围和与之关联的测试目标,必须对实现测试目标过程中起作用的每个细节都清楚。 How to understand? 理解系统：功能需求+非功能需求 涉及整个系统的讨论会和文档（对系统要解决的问题的有关讨论、高层次的商业需求陈述、产品管理的案例研究和商业案例） 及早介入（测试经理等）：增加对客户需求、客户问题、潜在的风险和功能的理解 理解企业文化和过程 测试组和开发组独立还是一体化？ 测试方法是否适应“极限编程”的方法？,了解手头的任务和相关的测试目标（续）,实现的范围（测试范围） 测试的期望 管理层对测试的期望？ 客户期望的测试类型？（验收测试？遵从的方法？预定的里程碑？可交付使用的含义？） 吸取教训：以前的测试工作中学到了什么？（确定测试策略、设定实际的测试预期） 工作量大小：初步估计项目的复杂度的工作量 解决方案的类型：最终是实现了最复杂的解决方案？较短时间开发、更划算的解决方案？（决定采用的测试类型）,了解手头的任务和相关的测试目标（续）,技术选择： 实现技术？引起的问题？架构？系统类型？（确定测试策略、选择测试工具） 预算（确定测试类型、测试工作量） 时间表：系统测试的时间？截止日期？调整测试时间表 获得测试环境所需的硬件和软件？ 评估、购买和实现测试工具 分阶段的解决方案（迭代开发？发行许多版本？）,2考虑风险,软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些风险是真正存在的，而有些最终证实是无所谓的，重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。 风险分析是一项十分艰巨的工作，尤其是第一次尝试进行时更是如此，但是以后会好起来，而且也值得这样做。,考虑风险(续),一般而言，大多数测试小组都会发现自己的资源有限，不可能穷尽测试软件所有方面。如果能勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。下面是一些潜在的问题和风险的例子： 不现实的交付日期 与其他系统的接口 处理巨额现金的特征 极其复杂的软件 有过缺陷历史的模块 发生过许多或者复杂变更的模块 安全性、性能和可靠性问题 难于变更或测试的特征,考虑风险(续),确定测试策略时了解项目风险，每个项目都有一系列的风险，其中某些风险的级别可能比另一些风险高。（风险级别的排列考虑了损失发生的可能性和损失带来的影响的严重程度） 风险分类和来源 风险评估 降低风险的测试策略,考虑风险(续) 风险分析（续）,风险分析所提供的信息，有助于测试经理作出决定： 根据技能的高低、需要的工作量、风险和质量目标分配测试人员,降低风险的测试策略,把测试工作的重点放在系统中可能会引起绝大多数问题的那些部分。 测试经理必须确定风险最大的部分、最可能出现问题的部分、最易失灵的功能 对风险低和影响小的功能，只执行必须的测试工作，并可为新手提供积累经验的机会。 产生可预测的、更高质量的测试结果,3 制定测试策略(续) 根据功能优先级安排测试工作,最需要的功能的最先开发和测试 根据不同的标准划分优先级 风险最高到最低 复杂度最高到最低 客户的需要（市场和销售） 预算的限制 时间的限制 人员限制（特殊需求？谁来做？） 综合使用以上方法，得到一个功能的总体价值，并进行排序，得到功能优先级表。,4 规划测试环境,测试环境：支持测试工作的所有物质元素 测试数据、硬件、软件、网络和设备 测试环境必须反映软件最终运行环境的基线配置 设计测试环境 获得客户环境的样本（os,支撑软件，硬件） 确定是否需要一个归档机制来存储测试后生成的大文件（日志） 确定网络特性（带宽、网络协议等） 确定服务器os 确定需要的自动测试工具的许可证数量 确定执行某些测试过程需要的其他软件 确定硬件环境时考虑测试数据的需求（规模） 考虑配置测试需要的特殊资源（活动硬盘和图像库）,7.2软件测试管理,7.2.1 测试执行周期的入口标准（开始时间）和 出口标准（完成时间） 7.2.2 测试用例管理 7.2.3 缺陷追踪管理,7.2.1系统测试周期的入口和出口标准,1入口标准 在系统测试期间,为了接受一个软件版本,必须满足以下标准: 所有的单元测试和集成测试成功完成、 软件的生成过程没有任何错误、 配套文档完成、 缺陷已经修正并且准备重新测试 源代码已经存储在版本控制系统 只有以上标准满足后,测试组才接受软件版本并开始测试周期,测试周期的入口和出口标准(续),2出口标准:描述了软件完成了充分测试的时间. 测试资源有限,测试预算和测试工程师的人数有限,截止期限很快就到了,测试工作的范围也有一定的限制.即使满足了出口标准，只是说明它对客户是有用的。 所有基于需求的、预先定义的测试过程在执行过程中没有出现任何重大错误 高优先级的问题已经被开发人员修正，并且由测试组成员用回归测试进行了验证 已经执行了用来确定系统满足指定的功能性和非功能性需求的测试过程,测试周期的入口和出口标准(续),在测试结果中记录的所有1级、2级和3级的软件问题都已经解决 在测试结果中记录的所有1级、2级的软件问题都已经解决 在测试结果中记录的所有1级、2级的软件问题都已经解决，同时90%的3级问题已经解决。 软件发布时可能存在已知的低优先级的缺陷（当然有若干未知缺陷）,测试周期的入口和出口标准(续),一些度量也可以作为出口标准的一部分 在回归测试中，从以前运转正常的功能中发现缺陷的比例？（修正工作破坏以前运转正常功能的频率？） 缺陷修正失败的频率？ 新缺陷的发现率走势？下降,7.2.2 测试用例的管理,测试用例的管理属性有那些？ 测试用例体本身的属性有那些？ 测试用例管理系统可以协助对测试用例进行良好的管理,测试用例的管理属性,行业，属性值用列表表示，包括：银行、电信、交通、电子、智能楼宇、其它. 操作系统，属性值用列表表示，包括：windows 98、windows 2000、windows XP、Unix、Linux，嵌入式软件的操作系统有：Linux(armlinux/uClinux/RTlinux)、Vxworks、uCos/II、pSos、eCos、WinCE、Delta OS、VRTX、Nucleus、其它； 数据库管理系统，属性值用列表表示，包括：sql server, my sol, oracle, Sybase, access，其它； 浏览器，属性值用列表表示，包括：ie3.0,ie4.0，ie5.0,ie6.0,netscape3.0，netscape4.0，netscape6.0，其它；这三个属性支持具有相同系统平台的被测软件项目间的测试用例复用；,测试用例的管理属性,系统类型，属性值用列表表示，包括：嵌入式、b/s、c/s、其它； 编码语言，属性值用列表表示，包括：java、c+、c、smalltalk、dephi、其它； 测试类型，属性值用列表表示，包括：功能（包括可使用性测试）、兼容性、负载测试、强度测试、数据库容量测试、安全性测试、其它; 测试阶段 项目名称 创建人/创建时间 重要级别: 状态,测试用例体本身的属性,包括以下属性：测试用例名称、测试用例目的描述、测试用例版本号、相关附件、测试用例描述方式、测试用例前置条件、输入、操作步骤、预期输出、程序文件；与复用操作有关的属性有：父测试用例id、修改原因、修改时间、修改人员。 在这些属性中，“测试用例目的描述”属性记录了测试用例的测试目的，因为每个测试用例都必须有明确的测试目标； “测试用例描述方式”属性的值用列表表示，属性值包括文本方式、源代码（c，c+，java，rational脚本，qbasic，其它）、可执行程序 ；,测试用例体本身的属性,“测试用例前置条件”属性用文字描述测试用例执行前必须满足的条件，可能是和其他测试用例的关系，比如：在运行测试用例A的前提下才能完成该测试用例就描述了测试用例A和该测试用例之间的关系； “输入”属性可以是某个数据源，要给出数据源的路径和名称；或是具体的数据，要给出具体数据； “操作步骤”属性用文字描述操作步骤，各个操作步骤之间用“”进行分隔； “预期输出”属性指测试用例执行后的预期结果； “程序文件”属性是指有关的一些程序。(当测试用例是自动测试时所录制的脚本程序或者是可执行程序时.) “相关附件”属性是指与测试用例有关的一些文件；,测试用例管理系统可以协助对测试用例进行良好的管理,市场上比较有名的测试管理工具中，国外著名的有Rational公司的Test Manager、Compueware公司的QADirector、MI的TestDirector等软件；国内比较有名的有中科院的I-test、北航的QESuite等软件，在这些工具中，测试用例的管理只是其中的一个子系统，提供的功能有限。,7.2.3 缺陷追踪管理,缺陷文档包含的属性举例 缺陷优先级和严重性划分 缺陷的分离和重现 缺陷的度量及其意义,1缺陷文档包含的属性举例,度量项目名称 值 说明 缺陷id Y+M+D+id 例如：08090101 表示2008年9月1日记录的第1个 缺陷 状态 1，2 1新发现状态，2正在修改状态 3，4 3待确认状态，4修改完毕状态 测试人员 id 001 编号为001的测试人员 提交时间 Y+M+D+AM/PM 例如080902a 表示缺陷在2008年9月2日上午 提交 缺陷所属项目 id wf01 项目编号为01的工作流系统 缺陷所属模块 id wf0101 该缺陷位于工作流系统的01模块 开发人员 id 001 编号为001的测试人员 缺陷类型 A-E 详见表2 优先级 1，2 ,3，4 1-Urgent,2-High ,3-Midium,4-Low 修改人 id 001 编号为001的修改人 解决方案 文字描述 提出解决当前缺陷的方案并给出修改部分代码 修改时间 Y+M+D 例如080902表示2008年9月2日进行修改 修改次数 N 用自然数记录该缺陷被反复修改的次数 确认结果 1/0 1-表示缺陷已修复，0表示该缺陷还需再次修改,2缺陷类别划分,缺陷类别 标识/权值 说明 A 类 A1/5.6 由程序执行引起的死机、非法退出 A2/5.5 死循环 A3/5.4 数据库发生死锁 A4/5.3 数据库设计未达到第三范式的要求或需求规格说明的水平 A5/5.2 数据功能实现错误 A6/5.1 与数据库连接错误 A7/5.0 数据通讯错误 B 类 B1/4.3 程序语法错误 B2/4.2 因错误操作迫使程序中断 B3/4.1 程序接口错误 B4/4.0 数据库的表、业务规则、缺省值未加完整性等约束条件 C 类 C1/3.4 操作界面错误(包括数据窗口内列名定义、含义是否一致) C2/3.3 打印内容、格式错误 C3/3.2 简单的输入限制未放在前台进行控制 C4/3.1 删除操作未给出提示 C5/3.0 数据库表中有过多的空字 D 类 D1/2.5 界面不规范 D2/2.4 辅助说明描述不清楚 D3/2.3 输入输出不规范 D4/2.2 长操作未给用户提示 D5/2.1 提示窗口文字未采用行业术语 D6/2.0 可输入区域和只读区域没有明显的区分标志 E 类 E1/6.1 遗漏部分功能 E2/6.1 实现功能与需求不相吻合,缺陷优先级划分,优先级 1 :紧急,需要马上关注 2:高级,是重要的,1处理完后赶快处理 3:中级,可以用较长时间解决 4:低级,时间和资源允许就解决,普通的缺陷处理流程,缺陷报告最初生成的状态为“新”； 赋予各个小组打开不同问题的能力（错误、变更请求、增强请求） 选择缺陷优先级 评估缺陷，为缺陷分配状态 若状态为“打开”，则把缺陷分配给负责的人，变为“开发”状态 开始改正缺陷了，变为“正在开发”状态 缺陷改正完了，改为“修改完毕”状态；或者“工作正常”、“缺陷不能重现” 若创建了新版本，所有改正的缺陷改为“返测”状态 测试工程师返测这些改动，设置状态为“关闭-改正”、“返测失败”,普通的缺陷处理流程,3缺陷的分离和重现,有效地报告缺陷?(明显,通用,再现步骤) 执行一些测试用例后出现 分离缺陷 记录每一个步骤每一个停顿每一件工作 查找时间依赖和竞争条件的问题(slow软盘,quick硬盘)(时间发生次序) 与负荷相关的边界条件内存泄露数据溢出 考虑资源依赖性和内存网络硬件共享的相互作用,4缺陷的度量及其意义,为了保证软件的质量，软件开发组织必须对软件测试中发现的缺陷进行有效的管理，确保测试人员发现的所有缺陷都能够得到适当的处理。 对缺陷数据进行分析和度量，使我们在改正缺陷的同时，挖掘出更多对项目管理有用的信息，以便建立高效的缺陷管理流程,并使缺陷管理更好地融入项目管理过程中，转被动为主动，将缺陷管理从流程处理的模式下完全解脱出来，并将这一过程推向更高的阶段量化管理阶段.,缺陷的度量及其意义(续),对收集的缺陷数据度量，并使用统计方法或者分析模型得出分析结果，以便: 了解缺陷集中的区域，明晰缺陷发展趋向，度量软件开发过程中各阶段工作产品的质量，评估开发人员的效率、测试人员的效率和项目进展的情况. 这对于软件过程的改进，软件产品的发布，软件质量的预测具有十分重要的意义。,缺陷的度量及其意义(续),软件开发只有引入了度量机制和定量化的管理，才能称为真正意义上的“工程”，这一准则清楚地体现在CMM中：CMM 4级（已管理级）引入了“定量软件过程”，CMM 5级（优化级）则完全建立在定量管理的基础之上，并明确提出了“缺陷预防”。,缺陷的度量及其意义(续),缺陷的发展趋势 缺陷的发展趋势包括新发现缺陷数量增长趋势和关闭缺陷数量的增长趋势。对于软件产品发布而言，发展趋势图是辅助决策的重要依据。一般来说，软件发布的必要条件是新缺陷的数量增加呈下降趋势.,缺陷的度量及其意义(续),缺陷的度量及其意义(续),缺陷的分布状况 在软件开发过程中，缺陷分布状况图有助于我们了解各版本中缺陷数量的分布。特别在回归测试阶段中，缺陷的分布可以直接反映出版本的质量状况（见下图中各版本缺陷的分布状况）。缺陷分布状况图有两种，第一种是缺陷按模块的分布状况，另外一种是缺陷按产生的根本原因的分布状况。 缺陷的模块分布图反映的是各个模块中缺陷数量的分布状况。它可以被用来评估各模块质量水平，开发难度。同时也能从侧面反映出测试资源在各模块分布的情况。,缺陷的度量及其意义(续),5缺陷管理系统,国内外已出现了一批质量较好的缺陷管理工具，其中比较有代表性的有： 开源软件Bugzilla、jira Compuware公司的TrackRecord 、 Rational公司的ClearQuest、 北京航空航天大学的QAMonitor、 上海微创软件有限公司的BMS等。 这些工具各有特色，在功能的全面性上也各不相同，但都是基于“找出缺陷、修改缺陷、进行回归测试”这种面向流程处理的传统模式，实现了缺陷管理的基本流程，并在此基础上提供了一些查询和统计功能； 其共同的缺点是没有充分利用软件开发过程中产生的缺陷数据，不能以一种主动的、精确量化的方式对软件缺陷进行预防并提供软件项目管理者所需的有关产品和过程的度量信息。,7.3测试管理,1.企业的测试策略 2.企业的测试人员的组织 3. 测试组织与管理 4.测试部门的测试评估 5. 测试部门的管理,1. 企业的测试策略,1 理念： 企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。 用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。,1. 企业的测试策略,2 如何合理地减少测试工作量 减少冗余的测试 白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。 在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。 减少无价值的测试 无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。 。,1. 企业的测试策略,如何“偷工减料” 有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分,其它次要部分可以忽略或将来再测试. “偷工减料”方法的测试优先级： 哪些功能是软件的特色？ 哪些功能是用户最常用的？ 如果系统可以分块卖的话，哪些功能块在销售时最昂贵？ 哪些功能出错将导致用户不满或索赔？ 哪些程序是最复杂、最容易出错的？ 哪些程序是相对独立，应当提前测试的？ 哪些程序最容易扩散错误？ 哪些程序是全系统的性能瓶颈所在？ 哪些程序是开发者最没有信心的？,1. 企业的测试策略,3 测试的经济学(下页) “Too little testing is a crimetoo much testing is a sin.” 4 测试奖励机制 根据缺陷的危害程度，把奖金分等级。每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。奖金额要适当，太低了人们不感兴趣，太高了会让项目破产的。,测试的经济学,2. 测试人员的组织,1 了解开发人员的测试心理 测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。 开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误. 开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。 结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。,2. 测试人员的组织,2 如何组织测试人员：应当视企业的人力资源而定 条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完成单元测试、集成测试和系统测试工作，能够实现开发与测试同步进行。 条件比较好的公司，可以设置一个独立的测试小组，该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。 条件一般的公司，养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。 条件比较差的公司，也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方的程序。如果人员实在太少了，只好让开发者测试自己的程序，有测试总比没有测试好吧！,2. 测试人员的组织,3 避免开发人员与测试人员产生矛盾 开发人员的注意事项： 不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。 不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。 测试人员的注意事项： 发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。 在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。 请留意另一种极端：如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。,3. 测试组织与管理,测试管理的目的 测试管理中的PDCA 测试管理控制对象的管理 测试流程控制和管理 统计分析和决策支持 软件测试过程组织,测试管理的目的,通过对产品的整个测试流程进行控制和管理，提高企业软件测试的管理水平； 灌输和强化企业的管理理念； 确保开发产品的质量； 进一步提高企业的市场竞争能力,测试管理中的PDCA,P：测试计划 D：测试案例及测试步骤的设计 C：测试实施和错误跟踪 A：测试总结与报告,测试管理控制对象的管理,测试管理控制对象（测试文档）包含的内容： 测试计划 测试案例 各案例的具体测试步骤 问题报告 测试总结报告,测试管理控制对象的管理,软件测试文件描述要执行的软件测试及测试的结果 测试文件的编写是测试工作规范化的一个组成部分 开始于需求分析阶段、使用于整个生命周期中,软件测试的过程及组织,测试阶段 测试方法的应用 测试人员的组织 软件测试文件,测试阶段,准备工作 全面熟悉系统 编写测试计划 设计测试用例 划分阶段,需求审查阶段,组长 系统分析员 软件开发管理者 软件设计、开发人员 测试人员 用户,设计评审阶段,组长 系统分析员 软件设计人员 测试负责人,程序测试,组长：负责整个测试的计划、组织工作 测试人员：运行测试并记录测试结果,软件测试文档,测试文档的类型 测试文档的使用,4.测试部门的测试评估,测试经理必须跟踪、监督和评估测试工作的实现，并在必要时进行改进。测试工作的核心力量是测试工程师。 评估测试人员的有效性 对测试人员的期望 评估测试人员测试工作的要点 评估测试组的有效性 行业知识、测试技巧和经验 角色和职责 评估测试组测试活动质量的几个方面,4.1评估测试人员的有效性,测试人员的期望（达到共识） 遵守测试标准和测试过程 保持进度（提交各种产品的时间） 达到目标和完成指派的任务（为每人分配的任务必须形成文档，确定截止期限和完成目标） 控制预算（购买测试工具时）,评估测试人员测试工作的要点,行业专家和技术专家 行业专家:是否具备应用程序的行业领域的知识 技术专家: 测试人员履行自动测试时,根据预定标准评估自动测试过程 开发的脚本? 重新运行脚本时能够恢复基线数据库? 开发自动测试工具-代码的可读性和可靠性? 是否了解系统的功能? 熟悉测试工具? 有经验的测试人员与初学者 是否遗漏 了缺陷? 功能和非功能性测试（测试人员对各种可利用的测试技术的了解程度，以及对哪种技术能够提高手头测试任务的测试效率?对应用程序行为的理解程度，测试过程的深度如何？）,功能性测试评估时要考虑的问题 测试过程中的步骤是否完全映射为需求的步骤?是完全可追溯的吗? 测试的输入步骤和预期输出正确吗? 在测试过程的功能流中遗漏了重要的测试步骤吗? 设计有效的测试过程时是否经过了分析思考的过程? 是否遵从了测试过程的创建标准? 在认定测试过程有效和完整之前,由于误解和缺乏交流导致的修改次数是多少? 制作测试用例的过程中是否运用了有效的测试技术?,验证测试过程的深度? 测试过程的内容?只测试了较高层次上的功能,还是触及到了程序的实质性功能? 与需求的深度有关(系统应该添加A类型的记录-添加,查询,类型为A,添加多条?) 若测试过程遗漏细节,则测试工程师需要培训 测试阶段（测试、测试、系统测试、用户验收测试）不同阶段有不同任务。 测试 测试(测试人员需要把测试人员的测试过程文档化) 开发生命周期的各个阶段(及早介入,需求阶段,发现细微的缺陷),服从命令和关注细节 遵照指示和注意细节 (周例会每天) 缺陷类型、缺陷率和缺陷文档 缺陷类型(技能水平测试类型测试阶段应用程序的复杂度和成熟度)(复杂的、与行业领域相关的缺陷/简单的外观缺陷) 缺陷报告：是否包含了足够的信息可以使开发人员重现缺陷？缺陷报告标准化 参考：测试人员的绩效评定办法,测试工程师的自我评价,关注发现的缺陷类型 (总是发现不重要的缺陷？) 测试过程足够详细吗？是否覆盖了高优先级的缺陷所需的深度以及数据和基本功能的组合与变化？是否同时包含了对非法数据和合法数据的测试？ 是否听取了来自需求人员、开发人员和其他测试人员的反馈意见？ 对可用的测试技术了解吗？ 了解应用程序功能的实质和足够的行业知识吗？ 主要缺陷是否发现太晚了？（开始阶段是否集中在低优先级的需求上？）,所测试的部分是否缺陷太少了? 测试覆盖的内容是否足够全面？ 正在执行的测试类型是否最高效？是否遗漏了重要的步骤？ 应用程序是否