软件测试知识汇总（一）

软件测试

一、软件测试基础概念

1. 测试的定义：使用人工或者自动的手段来运行或者测试某个系统的过程；目的在于检验它是否满足规定的需求；弄清预期结果和实际结果的差别。
2. 测试的目的：以最小的人力、物力和时间找出软件中潜在的错误和缺陷。
3. 测试的原则：证明软件中存在缺陷；不能穷尽测试；测试应该尽早介入；28原则；不存在缺陷谬论；妥善保存一切文档等
4. 测试的标准：国际标准：ISO25010；国内标准：GBT20438或GBT18905
5. 测试的基本要求：外观界面测试；功能测试；易用测试；性能测试；兼容性测试；安全性测试。
6. bug的由来：bug现在指程序中的错误。

二、测试与开发模型

2.1 测试的工作流程

1. 需求分析：阅读需求文档、产品文档、产品详细设计说明书、分析需求的点、参与需求评审、快速熟悉项目。
2. 测试计划和测试方案：测试整个项目的总体规划，如测试的范围，进度的安排，人力物力的安排，整体的测试策略，风险的评估和规避；测试方案如被测试的目标，选取的测试工具，测试的方法，测试的重点。
3. 测试用例设计
4. 测试用例执行
5. 评估阶段测试报告

2.2 开发模型

2.2.1 瀑布模型

• 特点：1.阶段间具有顺序性和依赖性；2.推迟实现；3.质量保证的观点
• 特点总结:瀑布模型是文档驱动的模型，遵守这个约束可使软件维护变得比较容易一些，从而显著降低软件预算
• 优点：为项目提供了按阶段划分的检查点；当前一阶段完成后,您只需要去关注后续阶段；可在迭代模型中应用瀑布模型

2.2.2 增量模型

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

2.2.3 快速模型

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

2.2.4 螺旋开发模型

2.2.5 迭代开发模型

2.2.6 敏捷开发模型

2.3 测试模型

2.3.1 V模型

2.3.2 W模型

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

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

2.4 开发和测试的关系

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

三、软件测试分类

按测试阶段；是否运行；是否自动化；是否覆盖源码等分类
另：阿尔法：α，贝塔：β。

四、测试用例

4.1 概念

4.1.1 定义

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

4.1.2 特性

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

4.1.3 测试用例的要素

1. 测试用例编号：
   编号由字符和数字组合成的字符串，用例编号具有唯一性、容易识别,如下表。
2. 测试项目/模块：
   测试的项目属于哪个项目或者被测试的需求、被测的模块、被测的单元等等。
3. 预置条件：执行当前测试用例需要的前提条件，如果前提条件不满足，则后面的测试步骤不能进行或者得不到预期结果。
4. 测试输入：测试用例执行过程中需要加工的外部信息，根据测试用例的具体条件有手工输入、数据库等。
5. 预期输出：测试用例的预期输出结果，包括返回值内容、界面响应结果等。
6. 操作步骤：执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行。
7. 测试用例标题：对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能复，因为每个测试用例的测试点事不一样的。
8. 级别：对于测试用例的重要程度的区分，包含如下几种:

• 高级别:保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例
• 中级别:重要程度介于高和低之间的测试用例
• 低级别:实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例

9. 其他要素

• 用例的设计者:能准确找到测试用例的设计人员，对用例修改时能方便找到人员。
• 用例设计日期:方便检查用例的设计进度
• 对应的开发人员:出现bug后能及时战到相应的人员进行修复。
• 测试结果:执行用例最后执行的结果,包括:pass、fail、block。测试类型:功能、性能、压力等等

4.1.4 测试用例的设计原则

• 明确性：测试人员要尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的。
• 代表性“尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并。
• 简洁性：测试用例简洁，可读性良好。测试过程目的明确，测试结果唯一。测试用例要用陈述性语句，—句话直
  指问题的核心,不要使用浮夸的修饰手法。

4.2 测试用例的设计方法

4.2.1 等价类划分法

1. 官方定义：等价类测试方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
2. 等价类划分
   在测试中最完美的测试是使用穷举测逋肥所有的数据都测一遍，但是实际工作中不能采用，因为效率太低了。理想的测试时:使用最少的测试数据，达到最好的测试质量。
3. 合理假设
   测试某等价类的代表值就等于对这一类其它值进行了测试。
4. 类型划分

• 有效等价类
  有效等价类是指对对于程序的规格说明来说是合理的、有意义的输入数据构成的集合，利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
• 无效等价类
  无效等价类指对程序的规格说明是不合理的、无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。利用无效等价类可校验程序对于无效数据的处理能力，检测程序的健壮性、容错能力。

5. 等价类
   等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，具有等价特性。
6. 注意
   设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。
7. 设计测用例步骤

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

8. 案例：qq登录6-10位的qq，包括6位和10位
   qq号码必须整数数字不能以0开头
   有效等价类 6位的数字7位数字8位数字9位10位数字（不以0开头)
   无效等价类6位的数字7位数字8位数字9位10位数字〈以o开头)
   小数字母特殊字符*应个%汉字组合
   
   注意：无效等价类最后的测试结果是由该测试案例是否实现预期输出决定的。

4.2.2 边界值法

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

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

3. 常见的边界值

边界点(上点)：输入范围的边界点
离点：离边界点最近的点
内点：输入范围内的任意一个点

4. 步骤

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

5. 案例：计算器

4.2.3 因果图法

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

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

3. 背景
   等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的各种组合，输入条件之间的相互制约关系，这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑来用一种适合于描述多种条件的组合，相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。
4. 核心
   因果图法比较合适输入条件比较多的情况，测试所有的输入条件的排列组合，所谓的原因就是输入，所谓的结果就是输出。“因"=输入条件，“果”=输出结果。
5. 主要考虑内容

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

6. 因果图中的符号

• 基本符号
  通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值‘0’或‘1’。‘0’表示某状态不出现，‘1’表示某状态出现。
  
• 因果图中的约束条件
  
• E(exclude)约束：a和b中至多有一个为1。
• I(include)包含：a、b和c中至少有一个必须1。
• M(mandatory)强制：若结果a是1，结果b强制为0。
• O(only)唯—: a和b必须有一个，且仅有1个为1。
• R(required)要求: a是1时，b必须是1。
• 因果图法基本步骤
  1.找出所有的原因，原因即输入条件或输入条件的等价类。
  2.找出所设的结果，结果即输出条件。
  3.明确所有输入条件之间的制约关系以及组合关系。哪些条件不能组合到一起，哪些条件可以组合到一起
  4.明确所有输出条件之间的制约关系以及组合关系。哪些输出结果不能同时输出，哪些输出结果可以同时输出
  5.找出什么样的输入条件组合会产生哪种输出结果。
  6.把因果图转换成判定表/决策表。
  7.为判定表/决策表中的每一列表示的情况设计测试用例。
• 案例：交通一卡通自动充值软件
  
  

4.2.4 判定表法

• 定义
  判定表也称决策表，是分析和表达多逻辑条件下执行不同操作的工具。它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即:针对不同逻辑条件的组合值，分别执行不同的操作。判定表适合于处理这类问题。
• 使用场景
  适合于有多个输入和多个输出，输入和输出之间有相互的组合关系，输入输出之间有相互的制约和依赖关系。
• 组成
  判定表是由条件桩、动作桩、条件项、动作项四部分组成，如下：

1. 条件桩（Condition Stub)：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2. 动作桩(Action stub)：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3. 条件项(Condition Entry)：列出针对它左列条件的取值。在所有可能情况下的真假值。
4. 动作项(Action Entry)：列出在条件项的各种取值情况下应该采取的动作。

• 规则
  任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。
• 化简
  规则合并有两条或多条规则具有相同动作.并且其条件项之间存在着极为相似的关系。
• 步骤
  1.明确规则个数
  2.列出所有条件桩和动作桩
  3.填入条件项
  4.填入动作项到初始判定表
  5.简化，合并相似规则
• 案例1：公交卡充值。
• 案例2：维修设备
  问题要求：对于功率大于50马力的机器且维修记录不全或运行10年以上的机器，应优先维修。
  优缺点
  优点：能把复杂问题按照各种可能情况—列举出来，简明而易于理解，避免遗漏。
  缺点：不能表达重复执行的动作、例如循环结构。

4.2.5 正交表法

• 定义
  正交法，也叫正交实验法或者正交排列法，就是使用最小的测试过程集合获得最大的测试覆盖率。“正交实验”是研究多因素、多水平的一种实验方法。它利用正交表来对实验进行设计，通过少数实验代替全面的实验。在一项实验中，把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平,简称水平。
  
• 正交表的构成
  
• 要点
  所有组合中，只要任意两个因素间，进行了全排列即可。
• 步骤
  1根据需求把空间即其取值列举出来
  2.根据空间和空间的取值个数，选择一个合适的正交表
  3.根据控件的个数，选择正交表的次幂，也就是正交表中包含的最大值。例如，4个控件，选择4次幂4，根据控件取值个数，选择正交表的底，也就是正交表包含的最大值。例如，每个控件有3个取值，底是3
  5.把控件及其取值映射到正交表中
  6.把控件名字分别映射到正交表的列名位置
  7.把正交表中每一列的数字分别用对应的控件取值替代
  8.根据正交表,编写测试用例
• 案例
  
• allpairs工具的使用步骤
  1.准备excel表格（3的4次方）
  
  2.将表格贴到txt文本中并保存
  
  3.通过allpairs命令生成
  
  4.将结果拷贝到测试用例中
  

4.2.6 场景法

• 学习链接：https://www.cnblogs.com/vmorgen/p/6862115.html
• 定义
  从起点，通过一系列操作步骤（事件)，达成某一结果，到终点的过程测试。场景法主要用于冒烟测试。在通过了场景测试后，再通过其他方法进行更为细腻的测试。
• 概念及定义
  现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。
• 要素
  下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流1和3)，还可能起源于另一个备选流（备选流2)，或者终止用例而不再重新加入某个流（备选流2和4）
• 基本流和备选流的识别原则
  ① 基本流只有一个起点，一个终点；
  ② 基本流是主流，备选流是支流；
  ③ 备选流可以始于基本流，也可以始于其它备选流；
  ④ 备选流的终点，可以是一个流程的出口，也可以是回到基本流，还可以是汇入其它的备选流；
  ⑤ 备选流汇合时，谁汇合到谁，取决于流量大小也即该流程出现的可能性大小，小的汇入大的；
  ⑥ 如果在流程图中出现了两个不相上下的基本流，一般需要把它们分别当做一个业务看待。
• 案例1：
  
• 案例2：
  

4.2.7 流程分析法/功能图法

• 由来
  流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法。在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。路径覆盖法：把所有测试条件写成测试用例.白盒是根据代码分支分析写测试用例在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。黑盒测试是看文档来写测试用例，不需要看代码
• 步骤：
  1.详细了解需求;
  2.根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系;
  3.画出业务流程;
  4.写用例，覆盖所有的路径分支。
• 使用场景
  一般用于测试非常重要的系统(ATM机、医疗设备)
• 案例-购物系统
  1.购物系统功能
  2.绘制出可达矩阵
  3.使用深度或者广度法进行遍历
  4.写测试用例
  

购物广度图

购物深度图

4.2.8 错误推断法

• 定义
  错误推测法是：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
• 基本思想
  根据经验，列举出程序中可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。
• 使用场景
  适用于项目时间比较短促，任务比较繁重的情况下，而且测试经验较多。

4.2.9 测试用例的力度

• 简单
  仅仅试测试的纲要，可能只包含测试的内容。简单的测试用例其实并没有进行"设计"，而仅仅是记录。只星提醒测试人员主要功能有哪些。
• 复杂
  包含具体的输入项、每一个步骤、期待的结果。
• 中庸
  过于简单。会导致测试有遗漏，而且根据测试执行人员的水平不同导致偏差较大。过于复杂，会导致效率太低，维护成本太高，限制测试人员的思维一般在工作中都介于两者之间。

4.2.10 测试用例设计方法总结

• 测试用例的本质(基于需求)
  1.理解需求、反映需求,忠于需求
  2.需求会变化，则测试用例也应该是活的，变化的“及时响应变更比遵循计划更有价值”
• 原则
  1.根据程序的重要性和一旦发生故障带来的损失，来确定测试等级和测试重点
  2.认真选择测试策略。用尽可能少的测试用例发现尽可能多的错误。测试用例不足则会导致风险的增大；测试过度导致资源的浪费，需要找到平衡点。
• 方法选取
  1.先关注主要功能也业务流程、业务逻辑是否正确实现，考虑场景法
  2.需要输入数据的地方，考虑等价类划分法
  3.在任何情况行都使用边界值法
  4.如果程序的功能中包含输入条件的组合情况，则选取因果图和判定表法
  5.对于配置类软件，需要考虑参数的组合情况，考虑使用正交排列法
  6.对照程序逻辑，如果发现没有达到要求的覆盖标准。适当补充更多的测试用例
  7.采用错误推断法，追加其他测试用例

4.2.11 测试用例的评审

• 同行评审
  “个体和交互比过程和工具更有价值”
  由测试小组内部进行相互评审，达到思想的碰撞，通过探讨、协作完成测试用例的设计
• 用户评审
  “顾客的协作比合同谈判更有价值”
  1.如果测试是对产品的批判，则顾客指最终用户或者顾客代表
  在公司内部可以是市场调查人员或者相关领域专家
  2.如果测试是为软件开发提供帮助和支持，那么顾客就是程序员

五、缺陷

5.1 软件缺陷基础概念

5.1.1 定义

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

5.1.2 具体包含(程序、数据、文档)

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

5.1.3 表现形式

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

5.1.4 缺陷产生的原因

缺陷不可避免，主要原因如下
1.需求解释或者记录错误
2.用户需求定义错误
3.需求说明存在错误
4.编码说明、程序代码有无
5.硬件或者系统存在错误
6.文档错误、内容不正确、拼写错误

5.1.5 缺陷产生的根源

1.交流不充分
2.软件的复杂性
3.开发任务的错误
4.需求的变化
5.进度压力

5.1.6 缺陷修复的费用

5.2 缺陷报告

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

5.2.1 缺陷报告的一些字段及说明

5.2.2 缺陷报告作用

1.记录测试结果
2.方便测试人员进行缺陷的定位
3.为后期统计缺陷提供依据

5.2.3 缺陷报告书写规范

• 标题
  1.简短
  2.尽量能够体现原因和结果
  3.准确:避免使用模糊不清的词语
  4.便于他人理解，不要使用俚语、方言词汇
• 原则
  1.完整。他人按照步骤，即可复现问题
  2.简明。不包含夸张、啰嗦的内容
• 内容
  1.测试环境描述
  2.步骤
  ①加上编号
  ②一个步骤不要包含太多步骤
  ③可能将多个步骤合为一个
  ④可以包含该步骤后的一个中间结果
  ⑤可使用短语或者短句，不需要复杂句式
  3.实际结果：清楚，不笼统
  4.期望结果：根据需求文档，应该出现的结果
  5.附件：截图、录屏、测试中需要的数据
  6.解决方案/可能的原因（非必须)如果测试人员能够给出解决方案则更好了。
• 常见错误
  1.人称代词不明确
  2.情绪化语言、强调符号
  3.不确定词汇
  4.幽默、梗
  5.不确定：对于缺陷，测试人员至少需要再次操作，来重现缺陷

5.2.4 缺陷状态

• 状态变化
  1.new 测试人员发现缺陷
  2.assigned 由开发经理或者其他人员，将修复职责指定为某位开发人员
  3.开发人员阅读缺陷报告，可能得到如下结果
  ①open 测试人员是正确的，准备修复
  ②duplicate 与其他bug为同一原因，修正好一个后，这个也就修复了
  ③reject 测试人员理解错误，其实这不是bug
  ④fixed 经过一段时间开发人员修复了bug，就会标记为此状态- postpone 小问题，目前没有时间修复
  4.测试人员检验缺陷状态
  ①closed 再次测试，发现错误已经修复。
  ②closed reject的错误，经过沟通核实后，确认无需修复
  ③reopen 原来修复后的缺陷，经过回归测试后又出现了，标记原先的缺陷为此状态
• 缺陷的跟踪
  
• 要点
  缺陷从测试人员开始，也应该有测试人员结束。

5.2.5 严重程度

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

5.2.6 优先级

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

5.2.7 表现形式

5.3 缺陷统计

• 通过缺陷统计，我们可能得出以下信息。
  1.缺陷分布:找出系统的薄弱环境
  2.缺陷状态:根据变化，检查测试和开发的工作情况
  3.人员水平:开发人员出错的数量，测试人员测出的数量
  4.比较历史:对人员水平有所把握
  5.模块难度:较难的模块出问题的可能较大
  6.修复时间:平均修复缺陷需要的时间，越短越好
  7.未修复的缺陷数目:
• 作用
  1.风险评估:能否在计划内的时间发布
  2.缺陷原因:避免反复出现同类型的缺陷
  3.员工技能提升:根据开发和测试人员表现出来的问题，可有针对性提升
  4.团队配置:根据缺陷修复时间，可知道团队配合强弱
• 指标
  1.单位时间(天/周)内报告的缺陷数目
  2.单位时间(天/周)内修复的缺陷数目
  3.累计缺陷报告数量
  4.累计缺陷修复数量
  5.不同严重性的缺陷数
  6.模块与缺陷的对应关系
• 缺陷密度
  单位缺陷数量/kloc ( kilo lines of code)计算总缺陷数量/总代码行数/1000

5.4 缺陷的原则和重要性

• 原则:
  5C准则
  1.准确：每个组成部分的描述准确不会引起误解。
  2.简洁：只包含必不可少的信息，不包括任何多余的内容。
  3.清晰：每个组成部分的描述清晰，易于理解。
  4.完整：包含复现该缺陷的完整步骤和其他本质信息。
  5.一致：按照一致的格式书写全部缺陷报告。
  一个缺陷一个报告
  1.便于分配
  2.便于验证
• 重要性
  1.节省开发和测试人员的沟通时间
  2.提高缺陷修复速度
  3.提高测试人员的声誉
  4.加强协同工作

5.5 常见缺陷的查找方法

• UI：色彩、大小、布局、图片、字体
• 时间：网络传输、数据未压缩、解析苦难
• 文字内容：描述不清、描述不正确、有语病或错别字、太复杂、乱码
• 容错处理
• 性能缺陷：花费时间长、资源占用多、卡顿、并发差、延迟高

5.6 缺陷的修复

• 不是所有的缺陷都是缺陷
  1.无法重现或者难以捕捉
  2.缺陷报告中没有复现步骤
  3.缺陷报告无法理解
  4.极少使用的功能，或者不符合用户习惯，或者惯例。
• 由不受信任的测试人员提出
  1.不是所有的缺陷都会修改
  2.上线时间由限制
  3.不正确的操作
  4.涉及模块太多，可能导致按下葫芦浮起瓢的情况
  5.性价比太低
  6.极难重现

六、测试自动化及框架

6.1 自动化测试概念

• 狭义：自动化测试通过工具记录或编写脚本的方式模拟手工测试的过程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。
• 广义：自动化测试包括一切通过工具（程序)的方式来代替或辅助手工测试的行为,包括接口测试(REST Assured、Postman)、性能测试工具(LoadRunner、JMeter)和自己所写的一段程序。
• 作用：节省人力、物力、时间、硬件资源等，提升测试效率，特别是对于烦琐重复的测试用例，可以使测试人员更专注于
  新的测试模块的建立和开发，从而提高测试覆盖率。

6.2 自动化测试和手工测试的关系和联系

• 手工测试的特点：
  1.有较强的异常处理然力，能通过人为的逻辑判晰校验当前的步骤是否正确，同时用例的执行具有一定的步骤跳跃性，能够步步跟踪，细致定位问题.
  2.如果修正缺陷所需时间稍长，那么想将秀工测试应用于回归测试将变得异常困难。这是因为需要测试的测试用例太多，并且难以对不可视对象或对象的不可视属性进行测试.
• 自动化测试的特点：
  自动化测试执行的对象是脚本，能通过人为的逻辑判断校验当前的步骤是否正确，用例步骤之间关联性强，不像手工测试用例那么有跳跃性。另外可以用来保证产品主体功能正确和完整,让测试人员从繁重的工作中解脱出来。它可以更好地利用资源，可在夜间自动执行测试用例，测试具有移植性和可重复性。
• 手工和自动化测试互补：
  自动化测试不能完全替代手工测试，自动化测试的目的仅仅在于让测试人员从烦琐重复的测试流程中解脱出来，把更多的时间和精力放在更有价值的测试中，例如探索性测试。因此自动化测试和手工测试应该相互结合、相互补充才对。
• 手工和自动化测试关系：
  二者并不是对立的，什么手段效率高，就用什么手段。自动化测试发展了这么多年，也没有把手工测试取代，很好地说明了手工测试仍然是非常有必要的。

6.3 自动化测试的常见误区

• 自动化测试分类：
  1.按产品类型分：pc端产品自动化测试、web端产品自动化测试、app移动端产品自动化测试
  2.按产品研发阶段分：单元测试、接口测试、契约测试、集成测试、验收测试
• 常见误区
  

6.4 自动化测试的优劣

• 优点：
  
• 弊端
  

6.5 自动化测试的分层

单元测试（代码内部）>集成接口测试（类或函数）>UI测试（用户操作行为）

6.6 什么项目适合自动化测试

• 适合：项目变动少、项目周期足够、项目资源足够、产品型项目、能够自动编译和自动发布的系统、回归测试、多次重复且机械性动作、需要频繁运行测试
• 不适合：物理交互、项目周期很短、测试很少运行、定制性一次性、美观声音易用性测试

6.7 自动化测试需要的能力，常见框架和总结

• 能力：编码研发能力、熟悉被测系统、掌握一套自动化测试框架/工具、善于学习知其然知其所以然、逻辑思维能力、逆向思维能力
• 总结：
  
• 框架
  接口/UI自动化测试框架：Robot Framework、Selenium、Jmeter、SoapUI
  移动自动化测试框架：Robotium、Appium、Monkey
• 测试介入越早越好
  回归测试、冒烟测试、每日线上巡检、构造测试数据、建立测试与代码的覆盖关系…