软件测试基础

Ⅰ 软件测试基础

一、软件测试基础理论

1、软件测试的必要性

所有的产品或者服务上线都需要测试

2、测试的发展过程

3、什么是软件测试

找bug，发现缺陷

4、测试的定义

• 使用人工或自动的手段来运行或者测试某个系统的过程。
• 目的在于检测它是否满足规定的需求。
• 弄清预期结果和实际结果的差别。

5、测试的目的

以最小的人力、物力和时间找出软件中潜在的错误和缺陷

6、测试的原则

28原则：

• 20%的主要功能要重点测（eg：支付宝的支付功能，其他功能都是次要的）
• 80%的错误存在于20%的代码中

7、测试标准

8、测试的基本要求

• 功能测试
• 性能测试
• 安全性测试
• 兼容性测试
• 易用性测试
• 外观界面测试
• 可靠性测试

二、质量模型

衡量一个优秀软件的维度

①功能性

• 功能数量
• 功能的正确实现
• 错误处理情况

②性能

• 服务器每秒能处理的请求数
• 服务器的硬件配置是否满足

③兼容性

④易用性

简洁、友好、流畅、美观

⑤可靠性

无响应、卡顿、死机

⑥安全

• 传输加密
• 存储加密

⑦可移植性

网站数据迁移

⑧可维护性

三、测试流程

Ⅱ 测试与开发模型

一、测试的工作流程

1､需求分析

• 阅读需求文档（产品文档或产品详细没计说明书）
• 分析需求的点
• 参与需求评审
• 快速熟悉项目

2、制定测试计划和测试方案

• 测试计划：测试整个项目的总体规划 - 测试的范围- 进度的安排- 人力物力的安排- 整体的测试策略- 风险的规避
• 测试方案- 被测试的目标- 选取什么样的测试工具- 测试的方法- 测试的重点

3、设计测试用例

• 边界值、等价类

4、执行测试用例

5､评估阶段 测试报告

二、开发模式

1､瀑布模型（重点）

①瀑布模型示例图

②瀑布模型的特点

③瀑布模型的优缺点

优点：

• 为项目提供了按阶段划分的检查点
• 当前阶段完成后，您只需要去关注后续阶段
• 可在迭代模型中应用瀑布模型

缺点：

• 不适合需求经常变动的系统
• 用户可能需要较长等待时间来获得一个可供使用的系统，也许会给用户的信任程度带来影响
• 由于开销的逐步升级问题，它不希望存在早期阶段的反馈
• 在一个系统完成之前，它无法预测一个新系统引入一个机构的影响（不易变动）

2､增量模型

把瀑布模型的顺序特征与快速原型法的迭代特征相结合，将软件看作一系列相互联系的增量，在开发过程中的各次迭代中，每次完成其中一个增量

3､快速原型

快速原型是快速建立起来的可以在计算机上运行的程序

• 优点：克服瀑布横型的缺点，减少由于软件需求不明确带来的开发风险，适合预先不能确切定义需求的软件系统的开发
• 缺点：所选用的开发技术和工具不一定符合主流的发展，快速建立起来的系统结构加上连续的修改可能导致产品质量低下，使用前提是要有一个展示性的产品原型，一定程度上可能会限制开发人员的创新

4、其他开发模式

迭代模型是不可以并行的，但增量模型可以并行

• 螺旋开发模型
• 迭代开发模型
• 敏捷开发模型

三、测试模型

1､ V模型

V模型和瀑布模型有一些共同的特性，v模型中的过程从左到右，描述了基本的开发过程和测试行为。

• 优点：每一个阶段都清晰明了，便于控制开发的每一个过程，既包含单元测试又包含系统测试。
• 缺点：测试进入的较晚，对于前期的一些缺陷，无从发现和修改，测试和开发串行，总用时较长。

2､ W模型

V模型的局限性在于没有明确的说明早期的测试，无法体现尽早地和不断地进行软件测试的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W模型模型。在模型中不难看出，开发是V,测试是与此并行的V，W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序、需求、功能和设计，同样要测试，测试与开发是同步进行的，从有利于尽早地发现问题。

• 优点：测试伴随软件的整个生命周期，例如在需求分析结束之后就可以进行需求分析测试，测试与开发是并行独立进行。
• 缺点：对需求和测试技术要求高，适用于大中型企业。

四、测试与开发的关系：

• 目标相同：都是为了制造出高质量的软件
• 相辅相成：开发经验对测试有用，测试经验对开发有用
• 侧重点不同：开发偏重于从无到有，测试偏重于从有到优

Ⅲ 测试分类

测试（开发）阶段

• 单元测试- 阶段：编码完成后- 测试内容：主要测试模块、类、函数和方法- 测试人员：开发人员、白盒测试人员

• 集成测试- 阶段：单元测试完成后，模块已完成编码- 测试内容：模块与模块之间的内容，接口- 测试人员：开发人员、白盒测试人员

• 系统测试- 阶段：集成测试完成后- 测试内容：程序、软件、app、系统、网站、项目- 测试人员：开发人员、白盒黑盒测试人员

• 验收（交付）测试- 阶段：系统测试完成后- 测试内容：整个系统- 测试人员：媒体、用户- 可以分为Alpha测试和Beta测试

是否覆盖源码

• 黑盒测试（没有覆盖源码）- ##### 功能测试- UI（界面）测试- 业务（功能）测试- 文档测试- 易用性测试- 安装和卸载测试- 兼容性测试- ##### 性能测试- 一般性能测试 - 响应速度- 对资源的利用 - CPU的使用率- GPU的使用率- 内存的使用率- 稳定性测试- 负载测试- 压力测试

• 白盒测试（有覆盖源码）- ##### 语句覆盖- ##### 判断覆盖- ##### 条件覆盖- ##### 路径覆盖

• 灰盒测试- ##### 关心输入输出- ##### 考虑程序的运行状态

是否运行

• 静态测试- 考虑程序的结构- 程序过程- 接口是否正常- 代码的风格是否符合标准

• 动态测试

是否自动化

• 手工测试
• 自动化测试

地域测试

• 本地化测试
• 国家化测试

其他测试分类

• 回归测试
• 冒烟测试 - 硬件测试词语- 基本功能、基本模块是否能正常运行
• 随机测试 - monkey测试
• 探索测试

Ⅳ 测试用例设计

一、测试用例介绍

1､概念

①测试用例定义

测试用例又叫做test case,是为某个特殊目标而编制一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

②测试用例的特性

• 有效性：测试用例能够被使用，且被不同人员使用测试结果一致。
• 可复用性：良好的测试用例具有重复使用的功能，如回归测试。
• 易组织性：好的测试用例会分门别类地提供给测试人员参考和使用。
• 可评估性：从测试管理的角度，测试用例的通过率和软件缺陷的数量是软件产品质量好坏的测试标准。
• 可管理性：从测试管理的角度，测试用例的通过率和软件缺陷的数量是软件产品质量好坏的测试标准。

2､测试用例的要素

• 测试用例编号编号由字符和数字组合成字符串，用例编号具有唯一性、容易识别。
• 测试项目／模块测试的项目属于哪个项目或者被测试的需求、被测的模块、被测单元等等。
• ️预置条件执行当前测试用例需要的前提条件，如果前提条件不满足，则后面的测试步骤不能进行，或者得不到预期结果。
• ️测试输入测试用例执行过程中需要加工的外部信息，据测试用例的具体条件有手工输入、数据库等
• ️预期输出测试用例的预期输出结果，包括返回值内容、界面响应结果等。
• ️操作步骤执行当前测试用例需要经过的操作步骤，需要明确地给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行。
• ️测试用例标题对测试用例的简单描述，用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点是不一样的。
• ️级别- 高级别- 保证系统基本功能、核心业务、重要特性，实际使用频率比较高的用例- 中级别- 重要程度介于高和低之间的测试用例- 低级别- 实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例
• 其他要素- 用例的设计者：能准确找到测试用例的设计人员，对用例修改时能方便找到人员- 用例设计日期：方便检查用例的设计进度- 对应的开发人员：出现bug后能及时找到相应的人员进行修复- 测试结果：执行用例最后执行的结果包括pass､fail､block- 测试类型：功能、性能、压力等等

3､测试用例的设计原则

①明确性

测试人员要尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的。

②代表性

尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并。

③简洁性

测试用例简洁，可读性良好，测试过程目的明确，测试结果唯一。测试用例要用陈述性语句，一句话直指问题的核心，不要使用浮夸的修饰手法。

4､小结

测试用例要素是为了便于我们快速的设计测试用例，因此要掌握最常用的八大要素，但是每家公司的具体要求不一样，要根据公司要求灵活添加测试的元素。

二、等价类划分法

等价类测试方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法收集测试用例要经历划分等价类（列出等价类表）和选取测试用例两步，它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。

在测试中，最完美的测试是使用穷举测试，把所有的数据都测一遍，但是实际工作中不能采用，因为效率太低了。理想的测试是使用最少的测试数据达到最好的测试质量。

1、概念介绍

• 等价类等价类是指某个输入域的子集合，在该子集合中各个输入数据对于揭露程序中的错误都是等效的，具有等价特性。
• 有效等价类有效等价类是指对于程序的规格说明来说，是合理的有意义的输入数据构成的集合，利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
• 无效等价类无效等价类指对程序的规格说明是不合理的、无意义的输入数据所构成的集合，对于具体的问题，无效等价类至少拥有一个也可能有多个。利用无效等价类可校检程序对于无效数据的处理能力，检验程序的健壮性、容错能力。
• 注意设计测试用例时，要同时考虑这两种等价类，因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试，才能够确保软件具有更高的可靠性。

2、设计测试用例的步骤

• ①确定需求
• ②确定有效等价类和无效等价类
• ③对每条等价类设计测试用例

3、案例 – QQ登录

①明确需求

6~10位的整数，包括6位和10位

• 位数：6~10位，闭区间
• 类型：整数，不能以0开头

②划分等价类

• 有效等价类：不以0开头的6位数字
• 无效等价类：以0开头的6位数字、不以0开头的11位数字、不以0开头的5位数字、不以0开头的6位字母、小数、特殊字符、汉字

③设计测试用例

三、边界值法

边界值分析法就是对输入和输出的边界值进行测试，也是一种黑盒测试。边界值分析法通常作为等价类划分法的补充，其测试用例来自等价类的边界；长期的经验得知大量的错误是发现在输入或输出范围的边界上，而不是发生在输入输出范围的内部，因此针对各种边界情况设计测试用例可以查出更多错误。

1、等价类划分法的区别

• 等价类划分法可以挑选等价范围内任意一个数据作为代表
• 边界值分析法要求每个边界值都要作为测试条件
• 边界值分析法不仅考虑输入条件，同样考虑输出产生的测试情况

2、常见的边界值

• 边界点（上点）：输入范围的边界点
• 离点：离边界点最近的点
• 内点：输入范围内的任意一个点

3、设计测试用例的步骤

• 明确需求
• 确定有效等价类和无效等价类
• 明确输入条件中的边界值
• 编写测试用例

四、因果图法

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

1、背景

等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的各种组合，输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但是多个输入条件组合起来可能出错的情况却忽视了。如果在测试时必须考虑输入条件的各种组合，则有可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合，相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

2、特点

• 考虑输入条件的相互制约及组合关系
• 考虑输出条件对输入条件的依赖关系

3、核心

• 因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合
• 所谓的原因就是输入，所谓的结果就是输出。
• “因”等于输入条件，“ 果”等于输出结果

4、主要考虑内容

• 所有输入／输出条件的相互制约关系以及组合关系
• 输入条件的依赖关系，也就是什么样的输入组合会产生什么样的输出结果，即因果关系

5、因果图中的符号

①基本符号

通常在因果图中用ci表示原图，用ei表示结果，各结点表示状态，可取值0或1，0表示某状态不出现，1表示某状态出现。

②约束条件

6、因果图法基本步骤

①找出所有的原因，原因即输入条件或输入条件的等价类
②找出所有的结果，结果即输出条件
③明确所有输入条件之间的制约关系以及组合关系。哪些条件不能组合到一起，哪些条件可以组合到一起
④明确所有输出条件之间的制约关系以及组合关系。哪些输出结果不能同时输出，哪些输出结果可以同时输出
⑤找出什么样的输入条件组合会产生哪种输出结果
⑥把因果图转换成判定表/决策表
⑦为判定表/决策表中的每一列表示的情况设计测试用例

7、案例：交通一卡通自动充值软件

系统需求：

系统只接收50或100元纸币，一次只能使用一张纸币，一次充值金额只能为50元或100元；
若输入50元纸币，并选择充值50元，完成充值后退卡，提示充值成功；
若输入50元纸币，并选择充值100元，提示输入金额不足，并退回50元;
若输入100元纸币，并选择充值50元，完成充值后退卡，提示充值成功，找零50元;
若输入100元纸币，并选择充值100元，完成充值后退卡，提示充值成功;
若输入纸币后在规定时间内不选择充值按钮，退回输入的纸币，并提示错误;
若选择充值按钮后不输入纸币，提示错误

输入条件：

输入50元纸币
输入100元纸币
选择充值50元
选择充值100元

输出条件：

完成充值后退卡
提示充值成功
提示错误
退回50元、退回100元（找零）
123456781、输入50元111输入2、输入100元1113、选择充值50元1114、选择充值100元1111、完成充值、退卡111输出2、提示充值成功1113、找零11114、提示错误11111

五、判定表法

判定表也称决策表，是分析和表达多逻辑条件下执行不同操作的工具，它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。利用判定表能够设计出完整的测试用例集合，在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即针对不同逻辑条件的组合值，分别执行不同的操作。判定表适合于处理这类问题。

1、使用场景

适合于有多个输入和多个输出，输入和输出之间有相互的组合关系，输入输出之间有相互的制约和依赖关系

2、组成

判定表示有条件桩、动作桩、条件项、动作项四个部分组成。

条件桩：列出了问题的所有条件，通常认为列出条件的次序无关紧要。
动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
条件项：列出针对它左列条件的取值，在所有可能的情况下的真假值。
动作项：列出在条件项的各种取值情况下应该采取的动作。

3、规则

任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的列就是一条规则。显然判定表中列出多少组条件取值，也就有多少条规则，即条件项和动作项有多少列。

4、化简

规则合并有两条或多条规则具有相同动作，并且其条件项之间存在着极为相似的关系。

5、步骤

①明确规则个数
②列出所有条件桩和动作桩
③填入条件项
④填入动作项到初始判定表
⑤简化，合并相似规则

6、优缺点

优点：能把复杂问题，按照各种可能情况一一列举出来，简明而易于理解，避免遗漏。
缺点：不能表达重复执行的动作，例如循环结构。

六、正交表法

正交法也叫正交实验法或者正交排列法，就是使用最小的测试过程集合获得最大的测试覆盖率，正交实验是研究多因素、多水平的一种实验方法。它利用正交表来对实验进行设计，通过少数实验代替全面的实验。在一项实验中，把影响试验结果的量称为试验因素，简称因素，因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况称为因素的水平，简称水平。

1、步骤：

①根据需求把控件及其取值列举出来
②根据控件和控件的取值个数，选择一个合适的正交表
③根据控件的个数，选择正交表的次幂，也就是正交表中包含的最大值，例如，4个控件，选择4次幂
④根据控件的取值个数，选择正交表的底，也就是正交表包含的最大值，例如，每个控件有3个取值，底是3
⑤把控件及其取值映射到正交表中
⑥把控件名字分别映射到正交表的列名位置
⑦把正交表中每一列的数字分别用对应的控件取值替代
⑧根据正交表，编写测试用例

2、案例

正交表如下：

allpairs工具的使用

1、利用Excel准备一个表格
2、将表格内容粘贴到txt文本中，并保存
3、通过allpairs命令生成
4、拷贝结果到测试用例中

挑选出少量用例

需要使用命令行打开

3、使用场景

需求中条件的组合量比较大的时候 需要两个两个相互组合的时候

七、场景法

从起点起，通过一系列操作步骤（事件），达成某一结果，到终点的过程测试。场景法主要用于冒烟测试。在通过了场景测试后，再通过其他方法进行更为细腻的测试。

现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。

1、要素

​ 下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流1和3），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和4）。

2、说明

​ 遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
场景1 基本流
场景2 基本流 备选流1
场景3 基本流 备选流1 备选流2
场景4 基本流 备选流3
场景5 基本流 备选流3 备选流1
场景6 基本流 备选流3 备选流1 备选流2
场景7 基本流 备选流4
场景8 基本流 备选流3 备选流4
注：为了方便起见，场景5、6和8只描述了备选流3指示的循环执行一次的情况。

八、流程分析法

1、由来

​ 流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法。在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够多的测试用例覆盖函数的所有代码路径。
​ 路径覆盖法：把所有测试条件写成测试用例，白盒是根据代码分支分析写测试用例。
​ 在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。黑盒测试是看文档来写测试用例，不需要看代码。

2、步骤

①详细了解需求；
②根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系；
③画出业务流程图；
④写用例，覆盖所有的路径分支。

3、案例-ATM

①ATM机功能
②绘制出可达矩阵
③使用深度或者广度法进行遍历
④写测试用例

4、使用场景

一般用于测试非常重要的系统（ATM、医疗设备）

九、错误推断法

错误推断法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

1、基本思想：

根据经验，列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

2、使用场景：

适用于项目时间比较短，任务比较繁重的情况下，而且测试经验较多。

十、测试用例的力度

• 简单仅仅是测试的纲要，可能只包含测试的内容。简单的测试用例其实并没有进行设计，而仅仅是记录。只是提醒测试人员主要功能有哪些。

• 复杂包含具体的输入项、每一个步骤、期待的结果。

• 中庸过于简单，会导致测试有遗漏，而且根据测试执行人员的水平不同导致偏差较大。过于复杂，会导致效率太低，维护成本太高，限制测试人员的思维。一般在工作中都介于两者之间。

十一、测试用例设计方法总结

1、测试用例的本质（基于需求）

• 理解需求、反映需求、忠于需求
• 需求会变化，则测试用例也应该是可变的
• 及时响应变更比遵循计划更有价值

2、原则

①根据程序的重要性和一旦发生故障带来的损失，来确定测试等级和测试重点
②认真选择测试策略。用尽可能少的测试用例发现尽可能多的错误。测试用例不足则会导致风险的增大；测试过度导致资源的浪费。需要找到平衡点

3、方法选取

①先关注主要功能也就是业务流程、业务逻辑是否正确实现，考虑场景法
②需要输入数据的地方，考虑等价类划分法
③在任何情况下都使用边界值法
④如果程序中的功能中包含输入条件的组合情况，则选取因果图和判定表法
⑤对于配置类软件，需要考虑参数的组合情况，考虑使用正交排列法
⑥对照程序逻辑，如果发现没有达到要求的覆盖标准，适当补充更多的测试用例
⑦采用错误推断法，追加其他测试用例

Ⅴ 缺陷

一、软件缺陷

1、定义：

• 从内部看，软件缺陷产品开发或者维护过程中存在的错误、毛病等各种问题
• 从外部看，软件缺陷是系统所需要实现的某种功能的失效或者违背
• 总的来说，缺陷就是问题，最终表现为所需要的功能没有完全实现，没有满足用户的需求

2、具体包含（程序、数据、文档）

• 未达到需求规格说明书中的功能
• 出现了需求规格说明书中指明不能出现的错误
• 功能超出了需求规格说明书的范围
• 未达到需求规格说明书中虽然没有指明，但应该达到的目标
• 测试人员或者用户认为软件难以理解、不易使用、运行速度慢或者最终用户认为不好

3、表现形式

• 功能、特性没有实现或者部分实现
• 设计不合理，功能特性不明确，逻辑不清楚或者存在矛盾
• 产品实际结果和所期望的结果不一致
• 没有达到需求规格说明书中所规定的性能指标
• 运行出错、中断、崩溃、界面混乱
• 数据不正确、精度不够，不完整，格式不统一
• 用户不能接受的其他问题，超时、界面丑陋
• 硬件或者系统软件上存在的其他问题

4、缺陷产生的原因

缺陷不可避免，主要原因如下

• 需求解释或者记录错误
• 用户需求定义错误
• 需求说明存在错误
• 编码说明、程序代码有误
• 硬件或者系统存在错误
• 文档错误、内容不正确、拼写错误

5、缺陷产生的根源

• 交流不充分
• 软件的复杂性
• 开发任务的错误
• 需求的变化
• 进度压力

二、缺陷报告

1、缺陷报告相关概念

在测试后，如果发现缺陷，则应该进行缺陷报告

• ​ 缺陷报告的一些字段说明

2、缺陷报告的作用

• 记录测试结果
• 方便开发人员进行缺陷的定位
• 为后期统计缺陷提供依据

3、缺陷报告书写规范

• 标题- 简短- 尽量能够体现原因和结果- 准确：避免使用模糊不清的词语- 便于他人理解，不要使用俚语、方言词汇

• 原则- 完整 他人按照步骤，即可复现问题- 简明 不包含夸，啰嗦的内容

• 内容- 测试环境描述- 步骤：- 加上编号- 一个步骤不要包含太多步骤- 可能将多个步骤合为一个- 可以包含该步骤后的一个中间结果- 可使用短语或者短句，不需要复杂句式- 实际结果：清楚，不笼统- 期望结果：根据需求文档，应该出现的结果- 附件：截图、录屏、测试中需要的数据- 解决方案/可能的原因（非必须）：如果测试人员能够给出解决方案则更好了

• 常见错误- 人称代词不明确- 情绪化语言、强调符号- 不确定词汇- “幽默”，“梗”- 不确定：对于缺陷，测试人员至少需要再次操作，来重现缺陷

三、缺陷的状态

1、状态变化

① new-测试人员发现缺陷

② assigned - 由开发经理或者其他人员，将修复职责指定为某位开发人员

③ 开发人员阅读缺陷报告，可能得到的结果如下：

• open：测试人员是正确的，准备修复
• duplicate： 与其他bug为同一原因，修正好一个后，这个也就修复了
• reject ：测试人员理解错误，其实这不是bug
• fixed ：经过一段时间开发人员修复了bug，就会标记为此状态
• postponed：小问题，目前没有时间修复

④ 测试人员检验缺陷状态

• closed：再次测试，发现错误已经修复，或是reject的错误，经过沟通核实后，确认无需修复
• reopen：原来修复后的缺陷，经过回归测试后有出现了，标记原先的缺陷为此状态

2、缺陷的跟踪

• 要点 缺陷从测试人员开始，也应该由测试人员结束

3、严重程度

• 严重程度分为五个等级：- Fatal****致命的缺陷：造成系统或应用程序崩溃、死机、系统挂起、或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。- Critical 严重错误的软件缺陷​ 系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如系统资源占用过大、功能没有做完。- Major 一般的软件缺陷​ 次要功能没有完全实现但不影响使用。如:提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等。- Minor较小的软件缺陷较小错误的软件缺陷，使操作者不方便或遇到麻烦，但它不影响功能性的操作和执行。例如:对话框弹出位置，步骤较多，输入项太麻烦。- Enhancemental 建议问题由问题提出人对测试对象的改进意见或测试人员提出的建议，质疑。 例如:错别字、颜色、按钮大小。

• 说明：​ 严重程度的分级，并不统一，有的公司分为三个等级或者四个等级都是可以的

4、优先级

​ 有的公司，也会把优先级分为3个或者5个，都是可以的。

5、表现形式

四、缺陷的统计

1、通过缺陷统计，我们可能得出以下信息

• 缺陷分布:找出系统的薄弱环境
• 缺陷状态:根据变化，检查测试和开发的工作情况
• 人员水平:开发人员出错的数量，测试人员测出的数量 o比较历史:对人员水平有所把握
• 模块难度:较难的模块出问题的可能较大
• 修复时间:平均修复缺陷需要的时间，越短越好。
• 未修复的缺陷数目

2、作用

• 风险评估：能否在计划内的时间发布
• 缺陷原因：避免反复出现同类型的缺陷
• 员工技能提升：根据开发和测试人员表现出来的问题，可有针对性提升
• 团队配置：根据缺陷修复时间，可知道团队配合强弱

3、指标

• 单位时间(天/周)内报告的缺陷数目
• 单位时间(天/周)内修复的缺陷数目
• 累计缺陷报告数量。
• 累计缺陷修复数量。
• 不同严重性的缺陷数。
• 模块与缺陷的对应关系。

4、缺陷密度

• 单位缺陷数量/kloc(kilolinesofcode)计算总缺陷数量/总代码行数/1000

五、缺陷报告的原则和重要性

1、重要性

• 节省开发和测试人员的沟通时间
• 提高缺陷修复速度
• 提高测试人员的声誉
• 加强协同工作

2、原则

• 5C准则- 准确:每个组成部分的描述准确不会引起误解。- 简洁:只包含必不可少的信息，不包括任何多余的内容。- 清晰:每个组成部分的描述清晰，易于理解。- 完整:包含复现该缺陷的完整步骤和其他本质信息。- 一致:按照一致的格式书写全部缺陷报告。

• 3、一个缺陷一个报告- 便于分配- 便于验证

六、常见缺陷的查找方法

1、UI(非重点)

• 色彩
• 大小
• 布局
• 图片
• 字体

2、时间

• 网络传输
• 数据未压缩
• 解析困难

3、文字内容

• 描述不清
• 描述不正确
• 有语病、错别字
• 太复杂
• 乱码

4、容错处理

5、性能缺陷

• 花费时间长
• 资源占用多
• 卡顿
• 并发差
• 延迟高

七、缺陷的修复

1、不是所有的“缺陷”都是缺陷

• 无法重现 或者 难以捕捉
• 缺陷报告中没有复现步骤
• 缺陷报告无法理解
• 极少使用的功能，或者不符合用户习惯，或者惯例
• 由不受信任的测试人员提出

2、不是所有的缺陷都会修改

• 上线时间有限制
• 不正确的操作
• 涉及模块太多，可能导致按下葫芦浮起瓢的情况
• 性价比太低
• 极难重现

八、缺陷的管理过程

CMM = Capability Maturity Model for Software = 软件能力成熟度模型

CMM/CMMI将软件过程的成熟度分为5个等级，以下是5个等级的基本特征：

1、初始级（initial）：

• 工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。

2、可重复级（Repeatable）

• 管理制度化，建立了基本的管理制度和规程，管理工作有章可循。初步实现标准化，开发工作比较好地按标准实施。变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。

3、已定义级（Defined）

• 开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解。

4、已管理级（Managed）

• 产品和过程已建立了定量的质量目标，开发活动中的生产率和质量是可量度的。已建立过程数据库，已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，实现及时纠正。

5、优化级（Optimizing）

• 可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。