你好，我是阿ken

考虑到 CSDN这个圈儿里除了一些正拼搏在一线工作岗位的大牛外，还有跟我一样还在上大学(白天在教室哔哔赖赖，晚上回宿舍熬夜淦文哈哈哈)的小白，在此也是即将迎来一年一度的期末考试的时间，先给诸位跟我一样的博主们一个素质三连

Ok，现在我们要言归正传

目录传送门：

4.1 测试执行概述

4.1.1 软件缺陷的定义

4.1.2 分离和再现软件缺陷

4.1.3 软件缺陷的生命周期

4.2 测试执行与报告软件缺陷

4.3 软件缺陷的跟踪管理

4.3.1 软件缺陷跟踪管理系统

4.3.2 手工软件缺陷报告

4.3.3 自动软件缺陷跟踪

4.1 测试执行概述

4.1.1 软件缺陷的定义

1. 软件缺陷的定义
”缺陷“是指存在不够完备的地方，即测试人员在测试过程中指出的不满足需求或质量要求的情况，也称之为”Bug“。

对于软件缺陷的定义，通常有以下5项规则描述，如符合任意一项，便称为“软件缺陷”：

(1) 软件未达到产品说明书中已标明的功能。
(2) 软件出现了产品说明书中指明不会出现的错误。
(3) 软件未达到产品说明书中虽未指出但应达到的目标。
(4) 软件功能超出了产品说明书中指明的范围。
(5) 软件测试人员认为软件难以理解，不易使用、运行速度缓慢，或者最终用户认为该软件使用效果不佳。

2. 软件缺陷的来源及分布

3. 软件缺陷的属性

4. 软件缺陷的图片信息

4.1.2 分离和再现软件缺陷

在此期间，测试人员要做的就是尽量缩小缺陷的范围。

1. 分离和再现软件缺陷的有效方法

① 测试人员在思想上不要想当然地接受任何的提前假设。

② 确保记录了测试过程中的所有步骤。

③ 考虑缺陷的出现是否需要特定的时间和条件。

④ 注意软件的边界条件、内存容量和数据溢出的问题。

⑤ 考虑资源依赖性和内存、网络、硬件共享的相互作用。

⑥ 了解硬件的影响。

⑦ 一个软件缺陷问题可能需要小组的共同努力。

2. 测试人员和开发人员的权责问题

当开发人员打开一个软件缺陷时，通常需要明确修复该缺陷所需的一些问题具体如下：

① 最少需要哪些步骤才能再现该缺陷。

② 该缺陷是否是真实存在的。

③ 哪些外部因素导致软件缺陷出现。

④ 哪些内部因素，包括代码、网络等导致软件缺陷出现。

⑤ 如何修复是否经过调试和单元测试。

⑥ 如何修复该软件缺陷并确保不产生新的软件缺陷。

⑦ 该修复是否通过了确认和回归测试，并且不影响系统其他正常功能。

4.1.3 软件缺陷的生命周期

一个最简单的软件缺陷生命周期：

① 发现--分配打开阶段：测试人员发现软件缺陷并将该缺陷提交给开发人员。

② 分配打开--修复阶段：开发人员根据缺陷报告再现缺陷并尽力修复，然后再提交给测试人员进行确认。

③ 修复--确认关闭阶段：测试人员经过回归测试确认该缺陷已被修复，关闭已不存在的缺陷。

④ 确认关闭

4.2 测试执行与报告软件缺陷

测试执行过程：

1. 测试启动评估

2. 制定测试执行计划

3. 建立测试环境

4. 执行测试用例

5. 记录测试执行

6. 报告测试结果

7. 管理软件缺陷

4.3 软件缺陷的跟踪管理

4.3.1 软件缺陷跟踪管理系统

1. 术语辨析
在软件测试过程中经常会出现术语来描述软件出现的问题，如软件错误、软件缺陷、软件故障、软件失效。

2. 软件缺陷跟踪管理的目的
① 及时跟踪每个发现的软件缺陷，确保每个缺陷都能及时被解决。解决并不一定就是修复，也有可能是延迟到下一版本再处理，或者由于技术原因或成本问题无法修复而注销等。总之，每个缺陷务必有理有据地被处理。
② 收集缺陷数据并生成缺陷趋势图以识别测试阶段。利用数据生成的缺陷趋势曲线是判断测试是否可以结束的一种行之有效的方法。
③ 收集缺陷数据，并在其上进行数据分析，作为组织过程的财富。

3. 软件缺陷跟踪管理的人员职责
① 高级经理(EM)：负责裁决测试组长和项目经理之间关于缺陷的争议。
② 项目经理(PM)：一般由项目经理来判断是否真为缺陷，并负责将缺陷分配给各开发
人员进行修复。
③ 测试组长(TM)：主要职责是确定缺陷管理的工具和方式,审核测试人员提交的缺陷、
管理缺陷的状态，并评估测试人员的工作质量。
④ 测试人员(TE)：是测试工作的完成人，主要工作包括:测试用例的编写、测试和回归
测试的执行、缺陷的提交和跟踪分析以及测试周报月报的提交等。
⑤ 开发人员(DE)：开发人员在测试环节负责修复软件缺陷。
⑥ 其他人员:如质量保证人员，负责监控缺陷跟踪管理的执行情况。
 

4. 软件缺陷的描述原则
① 单一性原则
如果在一个缺陷报告中表达了多个缺陷，往往会导致只有部分缺陷会被注意和解决。因此，每个报告只针对一个缺陷显得很重要，而如果在多个模块中出现同样的缺陷，可以在同一报告中体现。
② 可再现原则
软件缺陷是否可以再现关系到开发人员能否正确有效地修复该缺陷，因此，缺陷描述应该精确提供缺陷出现的操作步骤，开发人员容易读懂并操作。
③ 统一性原则
缺陷的描述需要前后统一，信息完整，必要时可加入屏幕截图辅助说明。
④ 简练原则
缺陷描述务求简单、准确、易懂，不相干、含糊的操作描述将严重影响开发人员的工作。
通过使用统一的关键词，既可以使缺陷描述短小精炼，又可使缺陷现象描述准确。
⑤ 指明特定条件
许多软件缺陷只有在特定条件下才会出现，这种特定条件可能是操作系统、浏览器、网络环境等特定的测试环境，在这种情况下，务必指明这种特定条件，以补充完善软件缺陷报告，有助于开发人员找出缺陷原因。
⑥ 不评价原则
缺陷描述需要的是对软件本身的客观描述，而不需要带有个人主义色彩的评价，尤其是不要有针对开发人员的评价。

5. 软件缺陷跟踪管理系统
> 如果采用人工传递缺陷报告的方式，显然效率过于低下，因此，在实际的测试工作中，常常运用软件缺陷跟踪系统以更好地处理每个缺陷，加快软件缺陷状态转换，缩短软件缺陷生命周期。
> 缺陷管理系统提供缺陷跟踪的数据库，使得缺陷描述的清晰、简洁、统一等原则更容易实现，各组地人员更能理解一致。
> 软件缺陷跟踪管理系统可以提供大量供分析和统计的选项，可以快速生成满足查询条件的缺陷。
将软件缺陷信息记录到电子化的管理系统中，使工作人员可以很方便地查看历史记录，有助于理解和处理新面临的缺陷。

4.3.2 手工软件缺陷报告

4.3.3 自动软件缺陷跟踪

以外这两节因触及学习较小，故不再赘述，日后接触到再来补充，还请读者谅解~

这是最近在看的一本书，基于此我只有一句话要说，慢慢加油

原文链接:https://blog.csdn.net/kenken_/article/details/118334726