测试组织和管理.pptx

测试的组织包括对人员的组织，在项目开测试的组织包括对人员的组织，在项目开发过程中，各阶段都应该有测试人员投入。发过程中，各阶段都应该有测试人员投入。（1）需求分析阶段：可以安排测试代表参加项）需求分析阶段：可以安排测试代表参加项目组的需求讨论会，尽早了解项目需求，同时目组的需求讨论会，尽早了解项目需求，同时也根据自己的测试经验，尽早发现是否需求中也根据自己的测试经验，尽早发现是否需求中存在缺陷或遗漏。需求完成后，测试人员根据存在缺陷或遗漏。需求完成后，测试人员根据需求编写部分系统测试用例，包括检查需求完需求编写部分系统测试用例，包括检查需求完整性以及需求的可测试性。整性以及需求的可测试性。（2）在设计阶段：系统设计人员编写集成测试）在设计阶段：系统设计人员编写集成测试计划和用例，为集成测试做指导，此时，要特计划和用例，为集成测试做指导，此时，要特别注意接口的用例设计。别注意接口的用例设计。（3）在详细设计和编码阶段：由开发人员进行）在详细设计和编码阶段：由开发人员进行全面完整的单元测试用例编写。全面完整的单元测试用例编写。（4）提交系统测试：测试人员要仔细研究项目）提交系统测试：测试人员要仔细研究项目的有关资料，包括需求规格说明书、设计规格的有关资料，包括需求规格说明书、设计规格说明书，完善和补充系统测试用例，做到需求说明书，完善和补充系统测试用例，做到需求被被100%覆盖，然后执行系统测试。覆盖，然后执行系统测试。（3）在详细设计和编码阶段：由开发人员进）在详细设计和编码阶段：由开发人员进行全面完整的单元测试用例编写。行全面完整的单元测试用例编写。（4）提交系统测试：测试人员要仔细研究项）提交系统测试：测试人员要仔细研究项目的有关资料，包括需求规格说明书、设计目的有关资料，包括需求规格说明书、设计规格说明书，完善和补充系统测试用例，做规格说明书，完善和补充系统测试用例，做到需求被到需求被100%覆盖，然后执行系统测试。覆盖，然后执行系统测试。7.1测测试试准准备备7.1.1测试需求分析和计划测试需求分析和计划1什么是测试需求什么是测试需求软件测试需求是根据程序文件和质量目软件测试需求是根据程序文件和质量目标对软件测试活动所提的要求，也就是在项标对软件测试活动所提的要求，也就是在项目中要测试哪些内容和测试到什么程度。目中要测试哪些内容和测试到什么程度。在测试活动中，首先需要明确测试需求，才在测试活动中，首先需要明确测试需求，才能决定需要多少人、怎么测、测试多长时间、测能决定需要多少人、怎么测、测试多长时间、测试的环境、需要的技能、工具、相应的背景知识试的环境、需要的技能、工具、相应的背景知识以及可能遇到的风险等，以上所有的内容结合起以及可能遇到的风险等，以上所有的内容结合起来就构成了测试计划的基本要素。来就构成了测试计划的基本要素。测试需求是测试计划的基础与重点。测试需求是测试计划的基础与重点。2为什么要做测试需求分析为什么要做测试需求分析要成功地完成一个测试项目，必须了解测要成功地完成一个测试项目，必须了解测试的规模、复杂程度以及可能存在的风险，这试的规模、复杂程度以及可能存在的风险，这些都需要通过详细的测试需求来了解。些都需要通过详细的测试需求来了解。测试需求详细、精准，表明对所测软件了测试需求详细、精准，表明对所测软件了解得深入，对所要进行的任务内容有清晰的认解得深入，对所要进行的任务内容有清晰的认识，因而保证测试的质量与进度就更有把握。识，因而保证测试的质量与进度就更有把握。3测试需求的依据与收集测试需求的依据与收集测试需求通常是以待测对象的软件需求为测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不原型进行分析而转变过来的。但测试需求并不等同于软件需求，它是以测试的观点根据软件等同于软件需求，它是以测试的观点根据软件需求整理出一个检查表（需求整理出一个检查表（Checklist），作为），作为测试该软件的主要工作内容。测试该软件的主要工作内容。测试需求主要通过以下途径来收集：测试需求主要通过以下途径来收集：（1）与待测软件相关的各种文档资料。）与待测软件相关的各种文档资料。（2）与客户或系统分析员的沟通；）与客户或系统分析员的沟通；（3）业务背景资料，如待测软件业务领域的）业务背景资料，如待测软件业务领域的知识等；知识等；（4）正式与非正式的培训；）正式与非正式的培训；（5）其他相关内容。）其他相关内容。4测试需求分析测试需求分析测试需求分析是通过划分需求来源、分解测试需求分析是通过划分需求来源、分解测试需求类型，并分析测试需求的确定性、可测试需求类型，并分析测试需求的确定性、可测性、测试次序、重要性、稳定度、工作量等测性、测试次序、重要性、稳定度、工作量等活动，定义出测试需求的测试范围、优先级、活动，定义出测试需求的测试范围、优先级、测试风险、关系及约束，并建立与需求规格、测试风险、关系及约束，并建立与需求规格、测试用例之间的双向跟踪关系的过程。测试用例之间的双向跟踪关系的过程。我们把测试需求分析概括为以下我们把测试需求分析概括为以下4个部个部分。分。（1）明确需求的范围）明确需求的范围（2）明确每一个功能的业务处理过程）明确每一个功能的业务处理过程（3）不同的功能点业务侧重）不同的功能点业务侧重（4）挖掘显式需求背后的隐式需求）挖掘显式需求背后的隐式需求（5）测试需求的优先级）测试需求的优先级5测试计划测试计划测试计划是一个叙述了预定的测试活动的测试计划是一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。人员安排以及任何偶发事件的风险。（1）测试计划的目的）测试计划的目的（2）编写策略）编写策略“5W”规则指的是规则指的是“What”（做什么）、（做什么）、“Why”（为什么做）、（为什么做）、“When”（何时做）、（何时做）、“Where”（在哪里）、（在哪里）、“How”（如何做）。（如何做）。利用利用“5W”规则创建软件测试计划，可以帮助规则创建软件测试计划，可以帮助测试团队理解测试的目的（测试团队理解测试的目的（Why），明确测），明确测试的范围和内容（试的范围和内容（What），确定测试的开始），确定测试的开始和结束日期（和结束日期（When），指出测试的方法和工），指出测试的方法和工具（具（How），给出测试文档和软件的存放位），给出测试文档和软件的存放位置（置（Where）。）。（3）主要内容）主要内容测试计划（如表测试计划（如表7.1所示）的内容因项目所示）的内容因项目以及项目的大小而有所不同，一般包含测试以及项目的大小而有所不同，一般包含测试概要、测试目标、测试范围、测试策略、重概要、测试目标、测试范围、测试策略、重点事项、测试配置、人员组织、沟通方式、点事项、测试配置、人员组织、沟通方式、测试进度、测试标准、发布测试进度、测试标准、发布/提交产物、风险提交产物、风险分析等内容。分析等内容。序序 号号条条 目目内内 容容1测试概要测试概要摘要说明所需测试的软件、名词解释以及所参考的相关文档摘要说明所需测试的软件、名词解释以及所参考的相关文档2测试目标测试目标对测试目标进行简要的描述对测试目标进行简要的描述3测试范围测试范围测测试试计计划划所所包包含含的的测测试试软软件件需需测测试试的的范范围围和和优优先先级级，哪哪些些需需要要重重点点测测试试、哪哪些些无无需测试或无法测试或推迟测试需测试或无法测试或推迟测试4测试策略测试策略针对每个范围内的要素和内容，制定测试策略，选择所使用的测试技术和方法针对每个范围内的要素和内容，制定测试策略，选择所使用的测试技术和方法5重点事项重点事项列列出出需需要要测测试试的的软软件件的的所所有有的的主主要要功功能能和和测测试试重重点点，这这部部分分应应该该和和测测试试用用例例设设计计相对应，并互相检查相对应，并互相检查6测试配置测试配置测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等7人员组织人员组织需需要要什什么么样样的的人人进进行行测测试试，多多少少人人测测试试，各各自自的的角角色色和和责责任任，需需要要进进行行哪哪些些学学习习和培训和培训8沟通方式沟通方式测试组内部、测试与开发组之间使用什么样的工具、标识和频度进行沟通和确认测试组内部、测试与开发组之间使用什么样的工具、标识和频度进行沟通和确认9测试进度测试进度将将测测试试计计划划合合理理分分配配到到不不同同的的测测试试人人员员，并并注注意意先先后后顺顺序序。对对于于长长期期大大型型的的测测试试计划，可以使用里程碑来表示进度的变化计划，可以使用里程碑来表示进度的变化10测试标准测试标准测测试试开开始始、完完成成、延延迟迟以以及及继继续续的的标标准准，包包括括制制定定测测试试开开始始和和完完成成的的标标准准；某某些些时时候候，测测试试计计划划会会因因某某种种原原因因（过过多多阻阻塞塞性性的的Bug）而而导导致致延延迟迟，问问题题解解决决后后测测试试继继续续11发布提交发布提交在在按按照照测测试试计计划划进进行行测测试试发发布布后后需需要要交交付付的的软软件件产产品品、测测试试用用例例、测测试试数数据据及及相相关文档关文档12风险分析风险分析需要考虑测试计划中可能的风险和解决方法需要考虑测试计划中可能的风险和解决方法表表7.1测试计划内容测试计划内容7.1.2测试环境搭建测试环境搭建测试环境是指为了完成软件测试工作所测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史必需的计算机硬件、软件、网络设备、历史数据的总称。数据的总称。其中，硬件环境指测试必需的服务器、其中，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机客户端、网络连接设备，以及打印机/扫描扫描仪等辅助硬件设备所构成的环境；软件环境仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。他应用软件构成的环境。1测试环境搭建原则测试环境搭建原则一般来说，配置主测试环境可遵循下列一般来说，配置主测试环境可遵循下列原则：原则：（1）尽可能地模拟真实环境。）尽可能地模拟真实环境。（2）符合软件运行的最低要求，保证能支撑）符合软件运行的最低要求，保证能支撑软件正常运行。软件正常运行。（3）选用比较普及的操作系统和软件平台。）选用比较普及的操作系统和软件平台。（4）营造相对简单、独立的测试环境。）营造相对简单、独立的测试环境。（5）无毒的环境。）无毒的环境。辅测试环境常常用来满足不同的测试需辅测试环境常常用来满足不同的测试需求或特殊测试项目。求或特殊测试项目。（1）兼容性测试）兼容性测试（2）真实环境测试）真实环境测试（3）横向对比测试）横向对比测试2搭建软件测试环境搭建软件测试环境搭建测试环境是软件测试实施的一个重搭建测试环境是软件测试实施的一个重要阶段，测试环境适合与否，会严重影响测要阶段，测试环境适合与否，会严重影响测试结果的真实性和正确性。试结果的真实性和正确性。（1）确定测试环境的组成。）确定测试环境的组成。（2）管理测试环境。）管理测试环境。设置专门的配置管理员。设置专门的配置管理员。记录测试环境管理所需的信息。记录测试环境管理所需的信息。测试环境访问权限的管理。测试环境访问权限的管理。测试环境的备份和恢复。测试环境的备份和恢复。测试数据的获取。测试数据的获取。3某系统测试环境（如表某系统测试环境（如表7.2所示）举例所示）举例设设 备备 名名 称称性性 能能 描描 述述数数 量量Web中间件中间件WebLogic 8.1或或WebLogic 9.11数据库软件数据库软件Sybase标准版（默认标准版（默认25用户）用户）1测试系统（测试服务器为品牌测试系统（测试服务器为品牌PC服务器服务器TP320）数据库服务器数据库服务器2个个Intel 2.8GHz处处理理器器，512KB L2高高速速缓缓存存，400MHz前前端端总总线线，4GB PC2100 ECC DDR内内存存，80GB IDE硬硬盘盘，2个个集集成成NC7781 10/100/1000吉吉比比特特以以太太网网卡卡，Windows操操作作系系统统1Web应用服务器应用服务器2个个Intel 2.8GHz处处理理器器，512 KB L2高高速速缓缓存存，400MHz前前端端总总线线，4GB PC2100 ECC DDR内内存存，8GB IDE硬硬盘盘，2个个集集成成NC7781 10/100/1000吉吉比比特特以以太太网网卡卡，Windows操操作作系统系统1测试工作站测试工作站P4 2.8 GHz 512 MB DDR内内存存，40 GB高高速速硬硬盘盘，10/100M网卡网卡1核心交换机核心交换机10/100M交换机，交换机，100 Mbit/s网络速度网络速度2表表7.2测试环境配置测试环境配置7.1.3测试用例测试用例1测试用例的概念测试用例的概念测试用例（测试用例（TestCase）通常是指对一项特）通常是指对一项特定的软件产品进行测试任务的描述，体现测试定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例是为某个特殊目标而编制的成文档。测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需测试某个程序路径或核实是否满足某个特定需求。求。2测试用例的重要性测试用例的重要性3测试用例的分类测试用例的分类根据测试过程中具体涉及问题类型及测试根据测试过程中具体涉及问题类型及测试需求，一般可将测试用例划分为功能性测试用需求，一般可将测试用例划分为功能性测试用例、界面测试用例、数据处理测试用例、性能例、界面测试用例、数据处理测试用例、性能测试用例、操作流程测试用例以及安装测试用测试用例、操作流程测试用例以及安装测试用例等六种类型例等六种类型。4测试用例的设计测试用例的设计5测试用例的编写测试用例的编写6其他相关问题其他相关问题（1）测试用例的评审。）测试用例的评审。（2）优化测试用例的方法。）优化测试用例的方法。（3）测试用例的更新。）测试用例的更新。（4）测试用例的管理。）测试用例的管理。7.2测测试试实实施施测试实施过程指根据测试计划里定义的输测试实施过程指根据测试计划里定义的输入条件、测试策略、功能点，执行设计好的测入条件、测试策略、功能点，执行设计好的测试用例的过程。测试实施前应确定需要进行哪试用例的过程。测试实施前应确定需要进行哪些测试内容、测试时间计划、测试的软些测试内容、测试时间计划、测试的软/硬件硬件环境以及测试方法和测试工具。环境以及测试方法和测试工具。测试实施过程中应完整记录测试数据，验测试实施过程中应完整记录测试数据，验证测试用例的有效性，追踪测试缺陷的修复情证测试用例的有效性，追踪测试缺陷的修复情况。况。7.2.1测试用例执行测试用例执行（1）测试开始标准。）测试开始标准。测试计划评审通过；测试计划评审通过；测试用例已编写完成，并已通过评审；测试用例已编写完成，并已通过评审；测试环境已搭建完毕。测试环境已搭建完毕。（2）测试停止标准。）测试停止标准。满足以下条件，测试可以正常停止。满足以下条件，测试可以正常停止。缺陷状态为缺陷状态为“关闭关闭”（Closed）或）或“推推迟迟”（Later）状态；）状态；在系统测试中发现的错误已经得到修改，在系统测试中发现的错误已经得到修改，各级缺陷修复率达到规定的标准；各级缺陷修复率达到规定的标准；缺陷密度（缺陷密度（n个个/KLOC）需要符合软件要求的）需要符合软件要求的范围；范围；测试用例全部通过；测试用例全部通过；需求覆盖率达到需求覆盖率达到100%；确认系统满足产品需求规格说明书的要求。确认系统满足产品需求规格说明书的要求。当出现如下问题时，测试可以中止。当出现如下问题时，测试可以中止。半数以上测试用例无法执行；半数以上测试用例无法执行；测试环境与要求不符；测试环境与要求不符；测试中需求经常变动。测试中需求经常变动。7.2.2测试数据记录测试数据记录对测试的数据进行记录，也就是把测试中对测试的数据进行记录，也就是把测试中实际得到的动态输出（包括内部生成数据输出）实际得到的动态输出（包括内部生成数据输出）结果与对动态输出的要求进行比较，描述其中结果与对动态输出的要求进行比较，描述其中的各项发现。的各项发现。对于测试过程的记录，应该包括对于测试过程的记录，应该包括Who、When、Where、What和和How等几方面的数等几方面的数据信息。据信息。什么人（什么人（Who）：测试执行人员以及测试用例）：测试执行人员以及测试用例的的“负责人负责人”。什么时候（什么时候（When）：测试在何时开始、何时）：测试在何时开始、何时通过以及测试日程的具体安排。通过以及测试日程的具体安排。什么环境（什么环境（Where）：在何种软、硬件配置的）：在何种软、硬件配置的环境下运行，包括硬件型号、网络拓扑结构、环境下运行，包括硬件型号、网络拓扑结构、网络协议、防火墙或代理服务器的设置、服务网络协议、防火墙或代理服务器的设置、服务器的设置、应用系统的版本（包括被测系统以器的设置、应用系统的版本（包括被测系统以前发布的各种版本）以及相关的或依赖性的产前发布的各种版本）以及相关的或依赖性的产品。品。做了什么（做了什么（What）：使用了什么测试方法、）：使用了什么测试方法、测试工具以及测试用例。测试工具以及测试用例。结果如何（结果如何（How）：通过或失败。）：通过或失败。7.2.3测试沟通测试沟通最直接的通报方法是使用测试管理工具，最直接的通报方法是使用测试管理工具，由系统自动给测试管理者及测试用例负责人发由系统自动给测试管理者及测试用例负责人发送电子邮件，这对于分布式的开发和测试会更送电子邮件，这对于分布式的开发和测试会更加有效。邮件内容的详细程度可根据需要灵活加有效。邮件内容的详细程度可根据需要灵活决定。决定。测试执行过程中，如果确认发现了软件的测试执行过程中，如果确认发现了软件的缺陷缺陷，应马上提交问题报告单。，应马上提交问题报告单。7.2.4测试用例验证测试用例验证测试实施过程的重点之一是验证测试用测试实施过程的重点之一是验证测试用例的有效性，并且对测试用例库的内容进行例的有效性，并且对测试用例库的内容进行增加、删除和修改。增加、删除和修改。将所有执行过的测试用例进行分类，基将所有执行过的测试用例进行分类，基于测试策略和历史数据的统计分析（包括测于测试策略和历史数据的统计分析（包括测试策略和缺陷的关联关系），构造有效的测试策略和缺陷的关联关系），构造有效的测试套件，然后在此基础上建立要执行的测试试套件，然后在此基础上建立要执行的测试任务，这样的任务分解有助于进度和质量的任务，这样的任务分解有助于进度和质量的有效控制，可以减少风险。有效控制，可以减少风险。对所有测试用例、测试套件、测试任务对所有测试用例、测试套件、测试任务和测试执行的结果，通过测试管理系统进行和测试执行的结果，通过测试管理系统进行管理，使测试执行的操作过程记录在案，具管理，使测试执行的操作过程记录在案，具有良好的控制性和追溯性，有利于控制测试有良好的控制性和追溯性，有利于控制测试进度和质量。进度和质量。7.3测测试试总总结结7.3.1测试数据整理测试数据整理测试数据整理是缺陷数据统计的前期准测试数据整理是缺陷数据统计的前期准备，要删除重复的和不重要的测试数据，修备，要删除重复的和不重要的测试数据，修改不确切的描述。然后生成缺陷数据统计图改不确切的描述。然后生成缺陷数据统计图表，包括缺陷趋势图、缺陷分布图、缺陷及表，包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。时处理情况统计表等。7.3.2测试用例修订测试用例修订测试用例修订要删除重复的和不重要的测试用例修订要删除重复的和不重要的测试用例，修改不确切的描述，补充需要的测试用例，修改不确切的描述，补充需要的测试用例，以保证测试用例库的可用性，为测试用例，以保证测试用例库的可用性，为产品改进或项目复用打下良好的基础。测试产品改进或项目复用打下良好的基础。测试用例修订情况统计如表用例修订情况统计如表7.3所示。所示。名名 称称说说 明明测试用例总数（个数）测试用例总数（个数）执行的测试用例（个数）执行的测试用例（个数）测试用例执行率测试用例执行率达到达到100%测试用例覆盖需求率测试用例覆盖需求率达到达到100%已通过的测试用例数（功能、性能和其他）已通过的测试用例数（功能、性能和其他）表表7.3测试用例修订情况统计表测试用例修订情况统计表7.3.3用例库的维护用例库的维护测试用例库的维护是一个不间断的过程，测试用例库的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的通常可以将软件开发的基线作为基准，维护的主要内容包括删除过时的测试用例、改进不受主要内容包括删除过时的测试用例、改进不受控制的测试用例、删除冗余的测试用例以及增控制的测试用例、删除冗余的测试用例以及增添新的测试用例等几个方面工作。添新的测试用例等几个方面工作。根据产品特性和测试用例一致性的原则，根据产品特性和测试用例一致性的原则，分下面几种情况分别处理：分下面几种情况分别处理：（1）产品特性没变，只是根据最近的修订特性）产品特性没变，只是根据最近的修订特性来完善测试用例，这时，修改的测试用例对目来完善测试用例，这时，修改的测试用例对目前和以前的版本都有效。前和以前的版本都有效。（2）原有产品特性发生了变化，不是新功能，）原有产品特性发生了变化，不是新功能，而是功能增强，而是功能增强，这时，原有的测试用例只对这时，原有的测试用例只对先前版本有效，而对新的版本无效，此时只能先前版本有效，而对新的版本无效，此时只能增加新的测试用例，而不是修改原来的测试用增加新的测试用例，而不是修改原来的测试用例。原有的测试用例依然对原有版本有效。例。原有的测试用例依然对原有版本有效。（3）原有功能取消时，只要在新版本上将与）原有功能取消时，只要在新版本上将与之对应的测试用例状态置为无效即可。之对应的测试用例状态置为无效即可。（4）完全新增加的特性，需要增加对应的、）完全新增加的特性，需要增加对应的、新的测试用例。新的测试用例。7.3.4配置管理配置管理测试资产是被质量保证或测试团队开发测试资产是被质量保证或测试团队开发的任何一种工作产品。配置管理和变更管理的任何一种工作产品。配置管理和变更管理的任务就是管理谁变更了资产，以及何时变的任务就是管理谁变更了资产，以及何时变更了资产和为什么变更资产。更了资产和为什么变更资产。此外，配置管理支持追踪工作产品的版此外，配置管理支持追踪工作产品的版本，创建和重新产生产品基线，并且支持并本，创建和重新产生产品基线，并且支持并行的和多地域的开发。行的和多地域的开发。一个一个“优秀的优秀的”配置管理流程应该满足配置管理流程应该满足以下要求：以下要求：（1）为软件开发创建一个稳定的环境，为团）为软件开发创建一个稳定的环境，为团队成员提供独立的编写和测试代码的开发平队成员提供独立的编写和测试代码的开发平台，并且使他们可以将自己的变更在准备就台，并且使他们可以将自己的变更在准备就绪时引入团队环境中。绪时引入团队环境中。（2）定义并加强项目策略，例如，谁被授权）定义并加强项目策略，例如，谁被授权对工件进行更改。对工件进行更改。（3）记录何人、何时、何原因变更工件的的）记录何人、何时、何原因变更工件的的审计痕迹。审计痕迹。（4）随着团队扩大而相应地扩展。）随着团队扩大而相应地扩展。（5）支持异构的、地理分布的并行开发。）支持异构的、地理分布的并行开发。（6）增加团队生产力，缩短开发周期。）增加团队生产力，缩短开发周期。（7）确保高质量产品的开发。）确保高质量产品的开发。7.4缺缺陷陷管管理理软件中的缺陷（软件中的缺陷（Defect或或Bug）是软件开）是软件开发过程中的发过程中的“副产品副产品”。通常，缺陷会导致软。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。件产品在某种程度上不能满足用户的需要。一般而言，缺陷的跟踪和管理需要达到以一般而言，缺陷的跟踪和管理需要达到以下两个目标：一是确保每个被发现的缺陷都能下两个目标：一是确保每个被发现的缺陷都能够被解决，二是收集缺陷数据并根据缺陷趋势够被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防缺陷的频繁发生。曲线识别和预防缺陷的频繁发生。7.4.1缺陷描述缺陷描述可追踪信息可追踪信息缺陷标识缺陷标识缺陷标识唯一，可以根据该标识追踪缺陷缺陷标识唯一，可以根据该标识追踪缺陷缺陷基本信息缺陷基本信息缺陷状态缺陷状态缺缺陷陷的的状状态态分分为为“待待分分配配”、“待待修修正正”、“待验证待验证”、“待评审待评审”、“关闭关闭”缺陷标题缺陷标题描述缺陷的标题描述缺陷的标题缺陷的严重程度缺陷的严重程度描描述述缺缺陷陷的的严严重重程程度度，一一般般分分为为“致致命命”、“严重严重”、“一般一般”、“建议建议”缺陷的紧急程度缺陷的紧急程度描描述述缺缺陷陷的的紧紧急急程程度度，从从1到到4，1是是优优先先级级最最高的等级，高的等级，4是优先级最低的等级是优先级最低的等级缺陷类型缺陷类型界界面面缺缺陷陷、功功能能缺缺陷陷、安安全全性性缺缺陷陷、接接口口缺缺陷、数据缺陷、性能缺陷等陷、数据缺陷、性能缺陷等缺陷提交人缺陷提交人缺陷提交人的姓名和邮件地址缺陷提交人的姓名和邮件地址缺陷提交时间缺陷提交时间缺陷提交的时间缺陷提交的时间缺陷所属项目缺陷所属项目/模块模块缺陷所属的项目和模块，最好能精确到模块缺陷所属的项目和模块，最好能精确到模块缺陷指定解决人缺陷指定解决人缺缺陷陷指指定定的的解解决决人人，在在缺缺陷陷“提提交交”状状态态为为空空或或在在缺缺陷陷“分分发发”状状态态下下，由由项项目目经经理理指指定定相相关开发人员修改关开发人员修改缺陷指定解决时间缺陷指定解决时间项目经理指定的开发人员修改此缺陷的期限项目经理指定的开发人员修改此缺陷的期限表表7.4缺陷描述缺陷描述可追踪信息可追踪信息缺陷标识缺陷标识缺陷标识唯一，可以根据该标识追踪缺陷缺陷标识唯一，可以根据该标识追踪缺陷缺陷基本信息缺陷基本信息缺陷处理人缺陷处理人最终处理缺陷的处理人最终处理缺陷的处理人缺陷处理结果描述缺陷处理结果描述对对处处理理结结果果的的描描述述，如如果果对对代代码码做做了了修修改改，要要求在此处体现出修改求在此处体现出修改缺陷处理时间缺陷处理时间缺陷处理的时间缺陷处理的时间缺陷验证人缺陷验证人对被处理缺陷验证的验证人对被处理缺陷验证的验证人缺陷验证结果描述缺陷验证结果描述对验证结果的描述（通过、不通过）对验证结果的描述（通过、不通过）缺陷验证时间缺陷验证时间对缺陷验证的时间对缺陷验证的时间缺陷详细描述缺陷详细描述对对缺缺陷陷的的详详细细描描述述；对对缺缺陷陷描描述述的的详详细细程程度度直直接接影影响响开开发发人人员员对对缺缺陷陷的的修修改改，描描述述应应尽尽可可能能详细详细测试环境说明测试环境说明对测试环境的描述对测试环境的描述必要的附件必要的附件对对于于某某些些文文字字很很难难表表达达清清楚楚的的缺缺陷陷，使使用用图图示等附件是必要的示等附件是必要的续表续表7.4.2测试缺陷追踪测试缺陷追踪测试缺陷追踪是软件工作的一个重要部测试缺陷追踪是软件工作的一个重要部分，测试的目的是为了尽早发现软件系统中分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行追踪，确保每个的缺陷，因此，对缺陷进行追踪，确保每个被发现的缺陷都能够及时得到处理是测试工被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。作的一项重要内容。1缺陷跟踪管理的目标缺陷跟踪管理的目标分析缺陷活动中必须收集的一些数据项分析缺陷活动中必须收集的一些数据项目应该包括缺陷的严重等级、缺陷所在的模目应该包括缺陷的严重等级、缺陷所在的模块、缺陷发现块、缺陷发现/关闭的时间、缺陷所在的版关闭的时间、缺陷所在的版本号、缺陷的发现者、负责修改缺陷的开发本号、缺陷的发现者、负责修改缺陷的开发人员、修复缺陷而改动的代码行数、产生缺人员、修复缺陷而改动的代码行数、产生缺陷的根本原因等。陷的根本原因等。2缺陷管理的一般流程缺陷管理的一般流程图图7.1缺陷管理流程缺陷管理流程在缺陷管理的流程中会涉及多种角色：在缺陷管理的流程中会涉及多种角色：（1）评审委员会：主要由项目经理、测试经）评审委员会：主要由项目经理、测试经理、理、QA经理以及资深的开发、测试工程师等经理以及资深的开发、测试工程师等组成。组成。（2）项目经理：对整个项目负责，对产品质）项目经理：对整个项目负责，对产品质量负责的人员。量负责的人员。（3）测试人员：主要是指发现和报告缺陷的）测试人员：主要是指发现和报告缺陷的测试人员。测试人员。（4）开发人员：执行开发任务的人员，完成）开发人员：执行开发任务的人员，完成实际的设计和编码工作，负责对缺陷进行研实际的设计和编码工作，负责对缺陷进行研究和修改的开发人员。究和修改的开发人员。在整个缺陷的生命周期中，随着测试工作在整个缺陷的生命周期中，随着测试工作的进展，缺陷的状态在不断变化：的进展，缺陷的状态在不断变化：（1）New（新缺陷）：软件中新发现的缺陷，（新缺陷）：软件中新发现的缺陷，一般由测试人员提交。当然也可能是开发人员一般由测试人员提交。当然也可能是开发人员自己在单元或代码测试过程中提交，或来自软自己在单元或代码测试过程中提交，或来自软件使用的最终用户，又或测试现场反馈得到的件使用的最终用户，又或测试现场反馈得到的缺陷报告。缺陷报告。（2）Accepted（接受）：经过缺陷评审委员会（接受）：经过缺陷评审委员会的确认，认为缺陷确实存在。的确认，认为缺陷确实存在。（3）Assign（分配）：将该缺陷分配给相（分配）：将该缺陷分配给相关的开发人员来进行修改。关的开发人员来进行修改。（4）Open（打开）：处于该状态时，缺陷（打开）：处于该状态时，缺陷已经被确认并已经分配给相关的开发人员进已经被确认并已经分配给相关的开发人员进行相关的修改。行相关的修改。（5）Fixed（已修改）：开发人员已经解决（已修改）：开发人员已经解决的缺陷并经过内部的验证。的缺陷并经过内部的验证。（6）Reopen：开发人员确认修改后提交测：开发人员确认修改后提交测试组，但是测试人员验证发现，该问题仍然试组，但是测试人员验证发现，该问题仍然存在，此时将状态设置为存在，此时将状态设置为Reopen。（7）Closed（关闭）：缺陷状态处于已修（关闭）：缺陷状态处于已修改，并通过测试人员的验证后，由测试人员改，并通过测试人员的验证后，由测试人员将其状态置为将其状态置为Closed。7.4.3缺陷统计分析缺陷统计分析（1）比较常用的缺陷分析报告，是按照时间段来）比较常用的缺陷分析报告，是按照时间段来分析。分析。（2）按照软件开发的各个阶段，分为需求阶段、）按照软件开发的各个阶段，分为需求阶段、设计阶段、代码走查、手动测试、自动化测试。设计阶段、代码走查、手动测试、自动化测试。（3）按照）按照Bug产生的原因，分为需求设计缺陷、产生的原因，分为需求设计缺陷、功能性缺陷、性能缺陷、安全性缺陷、易用性缺功能性缺陷、性能缺陷、安全性缺陷、易用性缺陷及文字界面缺陷。陷及文字界面缺陷。缺陷分析本质上是对缺陷中包含的信息缺陷分析本质上是对缺陷中包含的信息项进行收集、汇总、分类后，使用统计方法项进行收集、汇总、分类后，使用统计方法（或者分析模型）得出分析结果。（或者分析模型）得出分析结果。缺陷分析得出的结果可以用来度量软件缺陷分析得出的结果可以用来度量软件开发过程中各阶段工作产品的质量，了解缺开发过程中各阶段工作产品的质量，了解缺陷集中的区域，明晰缺陷发展趋势。陷集中的区域，明晰缺陷发展趋势。它对于软件过程的改进及软件产品的发它对于软件过程的改进及软件产品的发布来说，具有十分重要的参考价值。布来说，具有十分重要的参考价值。缺陷分布状况图有两种，第一种是缺陷缺陷分布状况图有两种，第一种是缺陷按模块的分布状况，另外一种是缺陷按产生按模块的分布状况，另外一种是缺陷按产生原因的分布状况。原因的分布状况。按模块分布图反映的是各个模块中缺陷按模块分布图反映的是各个模块中缺陷数量的分布状况，可用来评估各模块质量水数量的分布状况，可用来评估各模块质量水平和开发难度，同时也能从侧面反映出测试平和开发难度，同时也能从侧面反映出测试资源在各模块的分布情况。资源在各模块的分布情况。按缺陷产生原因分布图可以直接反映出按缺陷产生原因分布图可以直接反映出各软件工程活动的质量，为软件过程的改进各软件工程活动的质量，为软件过程的改进提供直接的参考数据，是缺陷分析中最为重提供直接的参考数据，是缺陷分析中最为重要的一张图表，一般来说，缺陷产生的原因要的一张图表，一般来说，缺陷产生的原因划分得越细致，分析的结果就越精确。划分得越细致，分析的结果就越精确。缺陷度量数据采集表如表缺陷度量数据采集表如表7.5所示。所示。名名 称称说说 明明一级严重级别最高缺陷个数一级严重级别最高缺陷个数二级严重级别较高缺陷个数二级严重级别较高缺陷个数三级严重级别一般缺陷个数三级严重级别一般缺陷个数四级严重级别较低缺陷个数四级严重级别较低缺陷个数五级严重级别最低缺陷个数五级严重级别最低缺陷个数缺陷总数缺陷总数残残留留的的缺缺陷陷数数（未未关关闭闭的的Bug，例例如如：Later、Reject）按模块分布的缺陷数（有独立模块的项目）按模块分布的缺陷数（有独立模块的项目）关闭缺陷个数关闭缺陷个数缺陷修复率（三级以上，四级、五级）缺陷修复率（三级以上，四级、五级）修修复复的的缺缺陷陷数数/缺缺陷陷总总数数，三三级级合合格格标标准准分分别为别为100%、80%、60%表表7.5缺陷度量数据采集表缺陷度量数据采集表7.4.4寻找薄弱环节寻找薄弱环节经过对测试缺陷的统计分析，首先需要经过对测试缺陷的统计分析，首先需要确定占缺陷总数确定占缺陷总数80%的那些缺陷都发生在什的那些缺陷都发生在什么地方。么地方。这些地方不是按照单个模块中发现的缺这些地方不是按照单个模块中发现的缺陷数来确定的，而是按照模块缺陷密度统计陷数来确定的，而是按照模块缺陷密度统计排行，将缺陷密度大的模块排行在前，密度排行，将缺陷密度大的模块排行在前，密度小的在后，哪些模块的缺陷密度更大，下次小的在后，哪些模块的缺陷密度更大，下次的测试和修改的重点就放在哪里。的测试和修改的重点就放在哪里。模块模块名称名称缺陷缺陷数数模块规模块规模模（KLOC）缺陷密度缺陷密度（个（个/KLOC）规模累规模累计计（KLOC）规模累计百规模累计百分比（分比（%）累计缺累计缺陷数（个）陷数（个）缺陷累缺陷累计百分比计百分比模块模块82802810.00285.6%28028.0%模块模块3280426.677014.0%56056.0%模块模块2160305.3310020.0%72072.0%模块模块6165662.5016633.2%88588.5%模块模块132281.1419438.8%91791.7%模块模块426360.7223046.0%94394.3%模块模块720420.4827254.4%96396.3%模块模块515500.3032264.4%97897.8%模块模块912780.1540080.0%99099.0%模块模块10101000.10500100.0%1000100.0%表表7.6缺陷密度按模块分布累计表缺陷密度按模块分布累计表7.5测试成熟度模型测试成熟度模型CMM最初是美国卡