【软件测试】软件测试管理

软件测试环境

软件测试环境包括设计环境，实施环境和管理环境三部分，是指为了完成软件测试工作所必需的硬件、软件、设备、数据的总称。

软件测试环境是软件测试实施的一个重要阶段，软件测试环境适合与否会严重影响测试结果的真实性和正确性。

测试环境的要素

⭐一般来说，配置测试环境应该满足五个基本要素是：硬件、软件、网络环境、数据准备、测试工具。其中硬件、软件是测试环境中的最基本的两个要素，并派生出后三者。

• 硬件环境：软件赖以运行的硬件平台，例如服务器、个人服务器、PC机及配套设备等。测试中所需要的硬件设备的数量，以及对每台设备的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等。
• 软件环境：指支持待测软件运行的软件系统平台，包括用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本。测试工具软件也是软件环境中派生出来的一部分。
• 数据准备：在软件测试中测试的数据源非常重要，应尽可能的取得大量并且真实数据。无法取得真实数据时尽可能的模拟出大量的数据。数据准备包括数据量和真实性两个方面。数据的真实性通常表现在为正确数据和错误数据，在容错性测试中对错误数据的处理和系统恢复是测试的关键。
• 网络环境：网络环境是硬件因素和软件因素的综合。各种路由器，交换机，网线，网卡等是硬件基础，各种代理，网关，协议，防火墙等是软件基础。
• 测试工具：为了提高软件测试的效率，有时测试必须依托测试工具，以便测试过程的自动和半自动执行和测试结果的自动或半自动评审和报告。现在一般测试工具分为：代码分析工具，自动或半自动测试过程管理工具，测试资源管理工具 ，文档编写工具、性能测试工具、缺陷跟踪管理系统等。 包括软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议。

测试环境管理员

每个测试项目或测试小组都应当配备一名专门的测试环境管理员，职责包括：

①测试环境的搭建

②测试环境的备份及恢复

软件测试计划

是软件测试员与产品开发小组交流意图的主要方式。

⭐测试计划目标

①规定测试活动的范围、方法、资源和进度；

②明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险。

③测试计划的最终目标是：交流（而不是记录）软件测试小组的意图、期望，以及对将要执行的测试任务的理解。

测试计划主题

①测试过程中第一个论题是定义测试小组的高级期望。

②测试计划需要明确在项目中工作的人，他干什么，怎样和他联系

③定义，如对软件缺陷的定义等，这些定义要达成一致

④明确团队之间的责任

⑤明确哪些要测试，哪些不用测试

⑥测试的阶段

⑦测试策略

⑧资源需求

⑨测试员的任务分配

⑩测试进度

测试计划制订过程

分析和测试软件需求定义测试策略定义测试环境定义测试管理编写和审核测试计划

定义工作进度的过程

确认工作任务估算工作量编写进度计划

测试策略

• 测试范围

测试过度，则在测试覆盖中存在大量冗余；测试范围过小，则存在遗漏错误的风险。

定义测试范围是一个在测试时间、费用和质量风险之间寻找平衡的过程。

• 测试方法

①需求分析阶段：静态测试

②概要设计与详细设计阶段：静态测试

③编码和单元测试阶段：静态测试和动态测试、白盒测试

④集成测试阶段：动态测试、白盒测试、黑盒测试

⑤系统测试阶段：动态测试、黑盒测试

⑥验收测试阶段：动态测试、黑盒测试

• 测试标准

定义测试标准的目的是设置测试中遵循的规则。

①基于测试用例的规则

②基于”测试期缺陷密度“的规则

③基于”运行期缺陷密度“的规则

需要制订这几种标准：测试入口标准、测试出口标准、测试暂停与继续标准

• 测试工具

选择自动化测试工具

软件缺陷(bug)管理

所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

缺陷管理流程

1. 测试人员发现并记录缺陷（new / open）
2. 测试人员将缺陷提交给项目经理，项目经理会对该缺陷进行确认
   2.1 如果确认为是一个缺陷，那么项目经理会将该缺陷进行分配（assigned）
   2.2 如果项目经理认为这不是一个缺陷，那么会将该缺陷打回给测试人员（rejeccted），或者直接关闭（closed）
3. 开发人员在接到这个缺陷后，也需要先对缺陷进行判断
   3.1 如果是缺陷，就对缺陷进行处理（In Progress），处理完成（resolved / fixed）后将缺陷重新返回给测试人员
   3.2 如果不是缺陷，可直接返回给测试人员（rejected）
4. 测试人员接收到开发人员返回的缺陷后，需要做如下处理
   4.1 对于开发人员修复的缺陷（resolved / fixed）进行回归测试，如果测试通过则置为（Tested / Closed），测试不通过可以重开（Reopen），重新将缺陷打回给开发人员
   4.1 对于开发人员拒绝的缺陷（Rejected），一般是存在争议的缺陷，经过项目组讨论或评定后，确认不是缺陷可以直接对其进行关闭（Closed），如果确认是缺陷，需要对其进行重开（Reopen,如果该缺陷可暂缓修复或修复成本较高，需另行找时间修复，可将缺陷挂起（Suspened）

缺陷的主要属性

缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源

如何报告缺陷

①结构:测试过程的结构。
②再现:三次再现缺陷。
③隔离:确定影响再现的变量。
④推广:确定系统其他部分是否可能出现这种错误。
⑤比较:评审运行相似测试的结果。
⑥总结:简短描述客户或用户的质量体验和观察到的特征。
⑦压缩:精简不必要的信息，特别是冗余的测试步骤。
⑧去除歧义:使用清晰的语言。
⑨中立:公正地表达自己的意思，避免夸张、幽默、讽刺。
⑩评审:同行评审。

⭐如何跟踪缺陷

• 使用状态来管理缺陷生命周期

• 强调所有权和责任

• 关键转移

缺陷度量

帮助确定产品缺陷分布的情况、 帮助确定产品缺陷分布的情况“概率”和“风险发生后所带来的损失”来评估风险。

• 测试有效性度量

• 缺陷度量

  • 缺陷数量
  • 产品缺陷

  在产品中或客户发现的缺陷数量。

  • 缺陷消除率（DRE）

  DRE = （测试期间发现的bug数量）/（测试期间发现的bug数量+未发现的bug数量）

  未发现的bug数量=客户发现的bug数量

  • 缺陷潜伏期（Defect Age）

  我们发现bug的时间越晚，这个bug所带来的损害就越大，修复这个bug所耗费的成本就越多。

  • 缺陷损耗

  缺陷损耗 = （缺陷数量*发现的阶段潜伏期）/（缺陷总量）

  损耗的数值越低，说明发现过程越有效。

  • 缺陷密度

  缺陷密度 = （缺陷数量）/（代码行或功能点的数量）

软件配置管理（SCM）

⭐①是软件工程中用来管理软件资产变更的一项规程，包括它所使用的相关工具和应用技术（流程和方法）。

②协调软件开发使得混乱减到最小的技术

⭐③软件配置管理是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。

④表示和确定系统中配置项的过程，在系统整个生存期内控制这些配置项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。

软件配置管理的基本概念

• 配置项

凡是纳入配置管理范畴的工作成果统称为配置项。配置项主要分两大类：

①属于产品组成部分的工作成果，例如源代码、需求文档、设计文档、测试用例等等。

②在管理过程中产生的文档,例如各种计划、监控报告等等，这些文档虽然不是产品的组成部分，但是值得保存。

• 基线

基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。

基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。

通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”

• 配置管理员

为了提高配置管理的效率和安全性，项目应当设有配置管理员这个角色。配置管理员的主要工作是为项目制定配置管理计划，创建和维护配置库等。

⭐SCM的三个应用层次（从低到高）

• 版本控制

版本控制主要应用于个人独立开发或小组开发，它可以控制任何文件的版本、实现分支和归并功能、进行文本比较、标记注释和版本报告信息。

版本控制就是通过对软件开发进程中的文档及源码的版本（每一次改动）进行控制(记录、追踪、比较、合并等)。

• 以开发者为中心

以开发者为中心主要应用于部门级开发，它可用于软件维护、不断增加的开发任务、并行开发、QA及测试，它面向大型团队、利于交流、能最大限度地利用人力资源。

• 过程驱动

过程驱动主要使用于企业级开发，着重解决新的工具引入、IT审核、管理报告、复杂的生命周期、应用工具包、集成解决方案、资料库等问题，实现真正规范的团队开发。

软件维护

⭐软件维护的定义

软件维护是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。

要求进行维护的原因

• 改正程序中的错误和缺陷
• 改进设计以适应新的软、硬件环境
• 增加新的应用范围

⭐软件维护的类型

• 改正性维护

为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。

• 适应性维护

为使软件适应外部环境或数据环境的变化，而去修改软件的过程就叫做适应性维护。

• 完善性维护

为了满足用户提出的新要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。

• 预防性维护

采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试，称为预防性维护。

⭐ 各种维护类型和维护工作量的比例

• 完善性维护：50%-66%
• 适应性维护：18%-25%
• 改正性维护：17%-21%
• 其他维护：4%

软件维护特点

• 结构化维护与非结构化维护差别巨大

⭐①非结构化维护

在非结构化维护过程中，开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等，这样做是十分困难的，也容易产生误解。

在没有文档的情况下，也不可能进行回归测试，很难保证程序的正确性。

风险极大！

⭐②结构化维护

在结构化维护的过程中，所开发的软件具有各个阶段的文档，它对于理解和掌握软件的功能、性能、体系结构、数据结构、系统接口和设计约束等有很大的作用。

这种维护有利于减少工作量和降低成本，大大提高软件的维护效率。

• 软件维护代价高昂

$$M=P+K\ast e^{(c-d)}$$

M是维护的总工作量，P是生产性工作量，K是经验常数，c是复杂程度，d是维护人员对软件的熟悉程度.

• 维护问题多

影响软件维护工作量的因素

• 系统的大小
• 程序设计语言
• 系统年龄
• 数据库技术的应用
• 先进的软件开发技术
• 其它一些因素

软件维护的过程

软件维护过程由一系列变更请求触发。变更请求可能来自系统用户、管理层或者客户。对变更请求经过成本和影响分析评估，一旦变更请求获得批准，就要对系统规划一个新版本，然后实现这个变更。

软件维护工作在维护申请提出之前就开始了，它包括：
①建立维护组织，强制报告和评估的过程；
②为每个维护申请确定标准化的事件序列；
③制定保存维护活动记录的制度和有关复审及评估的标准。

软件维护的副作用

软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误。

分为三类：

• 代码副作用
• 数据副作用
• 文档副作用

软件可维护性

⭐软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。

可维护性、可使用性、可靠性是衡量软件质量的主要质量特性，也是用户十分关心的几个方面。

目前广泛使用的是如下七个特性来衡量程序的可维护性

• 可理解性
• 可测试性
• 可修改性
• 可靠性
• 可使用性
• 可移植性
• 效率

可维护性的度量

常用的度量一个可维护性的程序的七种特性的方法，就是：

• 质量检查表
• 质量测试
• 质量标准

⭐提高可维护性的方法

• 建立明确的软件质量目标和优先级
• 使用提高软件质量的技术和工具
• 进行明确的质量保证审查
• 选择可维护的程序设计语言
• 改进程序的文档