软件测试第7章 测试组织和管理.pptVIP

● 什么人（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 缺陷描述 可追踪信息 缺陷标识 缺陷标识唯一，可以根据该标识追踪缺陷 缺陷基本信息 缺陷状态 缺陷的状态分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭” 缺陷标题 描述缺陷的标题 缺陷的严重程度 描述缺陷的严重程度，一般分为“致命”、“严重