测试基础（仅供学习）

调试：

是程序员以程序员视角对软件代码进行的一系列检查，改正的开发活动，是为了满足程序员的设计需求。

测试：

是以最终用户的应用角度出发，对软件系统做出的一系列测试活动，主要检测程序代码、观察软件系统的运行表现，最终验证系统是否满足了用户的需求。

软件的定义：

是源代码、文档、配置数据的集合体。

软件生命周期：

市场需求调研——>可行性研究——>产品项目立项——>需求调研开发——>设计编码测试——>发布运行维护

研发模型：

1、瀑布模型

按照瀑布模型的软件生命周期的6个阶段（计划、需求分析、设计、编码、测试、运行维护、）严格按照线性方式进行，上一个活动的输出作为下一个活动的输入，而且每一个阶段的活动都需要进行评审和验证。

缺点在于模型间耦合度高，不利于需求频繁变更或者需求灵活的项目，因此只适用于小型的传统项目。

2、原型模型

在瀑布模型基础上演进的一种先进的研发模型，即在需求分析阶段加入了原型确认，避免了客户需求表述不正确或者需求分析不完整的情况。

3、螺旋模型

将研发项目分割成多个计划阶段，每个阶段按照瀑布模型或者原型模型来进行研发，同时对每个计划阶段加入风险分析。只适用于大型研发项目。

4、RUP模型

5、敏捷模型

测试模型：

1、V模型

详细见P40（图4-5），线性关系，要求必须开发提供测试版本后才能进行测试活动，造成需求早期存在缺陷时往往到后期才能发现，增加了研发成本，且测试活动严重滞后于开发活动，造成人力成本浪费。

2、W模型

详细见P41（图4-6），要求测试V模型和研发V模型分离且实现并行。

3、X模型

4、H模型

5、敏捷模型

软件测试的定义：

利用一定的手段（手动或者自动的方式）对软件系统的源代码、配置数据、文档进行检测，查看被测对象的功能或性能表现是否与用户的预期需求一致。

软件测试的目的：

1、发现缺陷，解决缺陷。

2、提高软件产品的质量，增强用户对软件产品的质量信心。

3、通过缺陷分析，可以给决策提供数据依据

4、通过测试活动积累经验，降低产品失败的风险。

缺陷：

一切与用户的显性和隐性需求不一致的错误

缺陷分类：

1、遗漏

a、需求规格说明书没有记录客户的原始需求

b、需求规格说明书有记录，但是开发阶段遗漏了需求

2、错误

需求是正确，但是开发阶段实现的功能与用户的预期不一致。

3、冗余

实现了用户未提及的需求。

该类问题一般情况下会先与客户进行协商，如果客户满意可以留下，如果不满意则记录为缺陷，进行删除

4、不满意

用户只要不满意的功能都可以称为缺陷

（**）缺陷报告的内容：

1、缺陷ID（**）

缺陷的唯一标识，来定位和管理缺陷。

2、概要描述（**）

描述缺陷的存在形式和表象。开发可以通过描述快速理解缺陷的现象和定位缺陷产生原因。

3、发现人

4、发现时间

5、修复时间

6、所属版本（**）

发现缺陷时的版本，便于缺陷的定位和回归测试

7、所属模块（**）

发现缺陷的业务模块，便于开发定位解决问题，便于后期统计分析缺陷。

8、缺陷状态（**）

标识缺陷当前的状态，便于缺陷的跟踪和管理。

ALM（管理工具）新建（new）——打开（open）——修复（fix）——关闭（close）——重新打开（reopen）

拒绝（reject）  ——延期（postpone）

9、严重程度（***）

反映缺陷引发不良影响的严重程度。决定缺陷修复的优先级。

严重程度分级：

1、低级：用户使用不方便，不够人性化等易用性方面的缺陷。

2、中级：一般指错别字、字体错误、显示错误等或者一些细小的子功能错误。

3、高级：当前功能无法实现，由当前功能引发了其他子功能无法使用。

4、致命级：由当前缺陷引发了大面积功能失效，业务中断或者流程错误，甚至系统崩溃。涉及金钱结算类的缺陷也可以定义为致命级。

10、修复优先级

缺陷严重程度越高，越优先修复（一般由开发填写）

11、下一步处理人（**）

缺陷下一步流转的负责人

12、详细描述（**）

对缺陷情况的详细描述，是对概要描述的补充。

一般包含：测试环境、测试步骤、实际结果、预期结果

13、附件（**）

缺陷的额外证据信息。一般包括：缺陷截图、录屏、系统的日志信息、或页面的抓包信息等等。

缺陷管理流程：

1、测试工程师发现缺陷提交缺陷报告，直接指派给对应的开发，开发确认后，如果是缺陷则进行修复，修复完成后由测试工程师进行确认测试，修复成功则关闭缺陷，如果不成功则重新打开，直到缺陷修复成功关闭缺陷。

2、如果开发确认后不是缺陷，则标记为拒绝，然后转派回测试人员。测试会重新确认，如果缺陷仍然存在则重新打开，指派给对应开发。如果缺陷不存在或者是误提，则只关闭。

3、如果重新提交给开发的缺陷，开发仍然拒绝，则需要跟开发进行沟通，问清楚拒绝原因。如果是因为无法复现，则需要当面复现一次。如果是因为需求理解不一致，则需要产品经理来做出需求仲裁：是缺陷就进行修复，不是缺陷则关闭。

注意：高级以上缺陷需要抄送测试负责人，开发负责人

软件测试原则：

1、测试证明软件存在缺陷

2、不可能执行穷尽测试

3、测试应该尽早启动，尽早介入

4、缺陷存在群集现象，测试资源应该合理分配

5、杀虫剂悖论（测试应该实时调整测试用例）

6、不同的测试活动应该依赖于不同的测试背景

7、不存在缺陷的谬论（测试应该考虑实际用户的使用背景）

软件测试的对象和目的（阶段性）

1、需求分析阶段

对需求规格说明书等需求文档进行检测，验证需求的正确性、完整性、歧义性、可验证等。

2、产品设计阶段

对概要设计说明书、详细设计说明书等设计文档进行检测，验证设计是否正确，是否符合逻辑等。

3、编码开发阶段

单元测试：对软件的单元/组件进行测试，验证单元的关键函数、类文件的数据结构，逻辑控制和异常处理是否正确。

集成测试：对模块与模块间的接口以及模块与第三方平台的接口，集成的整体功能进行检测。验证接口的数据传递是否正确，集成后的整体功能是否符合需求。

系统测试：对整个软件系统进行检测，验证系统所表现的功能、性能等特征是否满足了用户的需求。

4、验收测试阶段

对即将交付的软件系统进行检测，验证是否达到了交付的标准。

软件测试的级别：（不同的测试阶段，不同的测试目的划分的测试活动）

1、需求测试

对需求规格说明书进行检测，检测是否存在描述不正确、定义模糊、需求用例不正确、语言存在二义性等问题。

2、单元/组件测试

测试组件/单元与详细设计说明书的符合程度。

3、集成测试

检测软件模块对概要设计说明书的符合程度。

4、系统测试

检测整个软件系统是否与需求规格说明书中定义的需求相符。

5、验收测试

Alpha测试：

用户在开发者环境下进行的测试。（受控环境下，开发者可以随时记录和解决用户发现的问题）

Beta测试：

一个或多个用户在实际生产环境中去进行测试。（不受控环境，用户发现的问题统一收集后统一反馈给开发者进行处理）

UAT测试：

用户可接受度测试，用户验证软件系统的重点业务、核心功能点进行验收。

软件测试类型：

1、功能测试

软件在指定条件下使用时，满足用户显性和隐性需求的能力

a、是否有错误、冗余、遗漏的功能

b、是否满足了用户的隐性需求（用户满意度）

c、对输入是否有正确的响应，输出有正确的展示。

2、性能测试

通过模拟系统运行的业务压力和使用场景，验证系统是否满足了预先定义的性能能力

性能测试监控指标：并发数、响应时间、吞吐量、TPS 、HPS、硬件资源耗用等

性能测试特点：

a、验证系统是否具有宣称的性能能力

b、要有明确的性能目标

c、要尽量在真实环境下测试（不同的测试环境得到测试结果不同，不能使用类推的结论）

3、负载测试

在超过系统的标准性能负荷指标下，不断给系统施加负载，直到系统负载极限或者性能的临界点。

4、压力测试

在超过性能指标的饱和状态下，系统持续运行一段时间，观测系统正常处理业务的能力（稳定性）。

5、容量测试

测试被测对象的最大数据容量

6、安全测试

检测系统的安全保护机制在实际使用过程中不受非法入侵，保证本身数据的完整性和保密性的能力。

7、兼容性测试

测试软件系统在不同的运行环境下的实现业务的能力。

web的兼容性关注点：浏览器的类型、浏览器的版本、电脑的分辨率

app的兼容性关注点：操作系统、操作系统版本、手机厂商、机型（分辨率）

8、可靠性测试

测试被测对象在规定的时间，规定环境下，实现规定功能和性能的能力。

指标：平均故障间隔时间MTBF、平均故障修复时间MTTR

9、可用性测试

测试被测对象能够被用户理解、学习、使用，能够吸引用户的能力。

10、移植测试

软件产品能否顺利的从原平台移植到新的软硬件平台上，且移植后仍然能够满足用户的需求。

11、维护测试

软件系统交付部署运行后，在实际使用过程中，因为改正错误或者需求变更而引发的测试活动。

12、确认测试

对修复的缺陷进行的测试活动

13、回归测试

对已测试过的系统在程序修复缺陷以后进行的重复测试

回归测试策略：

完全回归：需要执行所有的测试用例

选择性回归：除了执行发现缺陷的测试用例外，还要选择性的执行其他的测试用例

a、基于风险回归：除了确认缺陷是否修复成功以外，还要执行风险较高的用例。

b、基于重点业务回归：除了确认缺陷是否修复以外，还要执行重点业务和核心功能的测试用例。

c、基于缺陷回归：仅回归发现缺陷的用例。

软件测试方法：

根据测试是否关注程序内部结构：

1、黑盒测试

将被测对象看做一个不透明的黑盒子，测试只关注系统所表现出来的功能和性能特性，而不关注程序内部的结构。

2、白盒测试

将被测对象看做一个透明的盒子，测试只关注程序代码的内部逻辑结构等，而不关注软件所表现的功能、性能特性。

3、灰盒测试

白加黑，既关注软件系统的外部表现特征，也关注内部的逻辑结构。

根据测试是否运行软件系统：

4、静态测试

不执行程序代码，不运行软件系统，仅对软件系统中的代码文件、文档资料进行检测。

主要的测试活动：需求测试、代码审查（白盒测试）等

5、动态测试

运行被测对象的程序代码，通过执行测试用例，检测系统的运行结果。

主要的测试活动：单元测试、集成测试、系统测试、验收测试等

根据测试是否手动执行还是自动检测：

6、手工测试

测试工程师手工运行被测对象，执行测试用例

7、自动化测试

使用测试工具和自动化测试脚本，自动运行测试用例来发现缺陷。

测试流程基本可以划分为：

测试计划、测试设计、测试实现、测试执行   4个阶段

详细的测试流程：

产品经理召开需求评审会，评审通过以后，测试组长编写测试计划，分配测试任务。测试工程师拿到自己负责的模块以后，详细阅读需求规格说明书，熟悉软件系统的业务规则，提取测试功能点，编写测试方案，设计编写测试用例。用例完成后，组织用例评审。评审通过后，开发提供测试版本，由测试团队搭建测试环境，准备测试数据，然后执行测试用例。对发现的缺陷进行记录提交、跟踪管理。开发修复缺陷后要及时进行回归测试，直到系统测试达到测试通过的标准，测试组长编写测试报告，测试活动结束，整理归档测试文档。

___________________________________________________________________________________

1、需求评审（会议前1~2日内，产品经理提前将需求规格说明书发给参会人员进行预览）

组织人：产品经理（讲解需求）

参会人：项目经理、QA、开发人员、测试人员、维护人员、客户代表等

主要内容：主要对需求进行讲解和评审，评审通过则作为后期开发和测试的基准，原则上不允许变更，如果评审后需求要变更，则执行需求变更流程。评审不通过，则需要产品经理重新分析需求，然后评审，直到通过为止。

2、测试计划

编写人：测试组长

主要内容：1、概述（项目背景、测试范围等） 2、组织形式和职责分配  3、工作量评估  4、任务分配及进度划分  5、测试通过和失败的标准   6、测试挂起和恢复标准   7、测试资源的准备   8、测试交付物清单

3、提取测试功能点

执行人：测试工程师

主要的内容：根据需求文档，提取测试功能点（熟悉软件的业务流程）

方法：先确定测试项和测试子项（1、先提取软件的业务场景，2、再提取其他的单独功能点）

测试需求的来源：1、需求规格说明书  2、客户的原始需求和开发需求  3、规范/标准文档   4、继承性需求  5、同行竞争性文档   6、测试经验

4、测试方案

编写人：测试工程师

5、测试用例

编写人：测试工程师

方法：等价类、边界值、判定表、因果图、正交实验、状态迁移、场景分析、错误分析等

标准的用例模板：用例编号、用例标题、测试项、用例属性、优先级、预置条件、测试输入、测试步骤、预期结果、实际结果

每个公司都有自己的用例模板，不同管理软件也有自己的模板格式。

6、评审用例

方式：1、交叉评审（项目时间紧凑，没有多余时间来进行正规的同行评审）2、同行评审（项目时间充足，由组长组织，开发测试参与，测试工程师讲解，其他人给出评审意见，对于有问题的地方进行标注，评审会后统一进行修改）

7、搭建测试环境，准备测试数据

方式：1、没有基础环境，需要从头开始搭建（按照部署文档搭建或者询问开发各种安装软件和版本以及配置，然后进行搭建）

          2、版本发布，只需要将开发提供的程序包编译，然后替换掉上一个版本，修改相关的配置数据即可。

测试数据来源：1、客户提供相关的生产数据  2、直接使用数据库语句创建  3、在测试环境中创建测试数据

8、执行用例

执行人：测试工程师

整体项目的话，需要先进行预测试（冒烟测试），执行用例中优先级为高的部分用例（重点业务流程，核心功能点，以及部分功能点的正向用例，风险高的用例）：当预测试不通过时，可以将测试版本封回给开发，减少因为流程阻塞而造成人力成本闲置。

预测试通过后进入系统测试阶段，全面执行测试用例。通常情况下进行3~5轮。

对于迭代模式：没有预测试，也没有轮数的概念，一般都是开发自测后提供测试版本，测试工程师开始执行用例，直到需求通过为止。

9、记录、跟踪缺陷

缺陷管理流程

10、回归测试

先进行缺陷修复的确认测试，所有缺陷修复完成后，对整个系统进行基于重点业务或者基于风险回归，甚至做完全回归。

11、编写测试报告

编写人：测试组长，测试工程师提供相应的测试数据

内容：1、概述（测试环境描述，人力分工和统计）2、测试结论  3、测试用例的执行情况  4、缺陷分析

5、遗留问题清单  6、风险评估   7、测试总结  

12、测试活动结束

整理归档测试文档。

___________________________________________________________________________________

测试计划内容：

1、概述（项目背景、测试范围等） 2、组织形式和职责分配  3、工作量评估  4、任务分配及进度划分  5、测试通过和失败的标准   6、测试挂起和恢复标准   7、测试资源的准备   8、测试交付物清单

测试报告的内容：

1、概述（测试环境描述，人力分工和统计）2、测试结论  3、测试用例的执行情况  4、缺陷分析

5、遗留问题清单  6、风险评估   7、测试总结  

衡量软件质量的特性 ：

功能性、可靠性、易用性、效率、可移植性、可维护性

测试需求的来源：

1、需求规格说明

2、原始需求和开发需求

3、规范/标准/协议文档

4、继承性需求

5、同行竞争分析文档

6、测试经验

用例的格式：

1、用例编号

用例的唯一标识，便于用例的管理。通常用例编号由4段组成：项目名称-测试阶段-测试项-数字编号

测试阶段（ST系统测试、IT集成测试、UT单元测试）

测试项（测试的模块，如果测试项太大，可以拆分细化到页面的测试子项）

2、测试项

测试的功能模块

3、用例标题

概括描述该条用例的测试关注点。

注意点：1.同一测试项下，用例标题不允许重复

2.在用例标题中不允许出现是否，可能等判断性词语，标题为一个陈述句

3.最好不要把用例标题写成操作步骤，最好使用概括性的标题，简单直接陈述关注点。

4、用例属性

描述用例的功能用途（测试类型）

5、优先级

描述该条用例的重要性，执行优先级

划分方式（高、中、低）

1、根据用户的使用频率

高：主业务流程或者核心功能点的正向流程或者正向输入，以及部分用户使用较多的异常流程或异常输入。

中：部分不常用功能的正向输入，或者核心功能的部分正向输入以及部分异常输入

低：功能点的异常流程或者异常输入

2、该用例测试关注点的风险

根据测试经验判断可能出问题的频率较大时可以给高级

6、预置条件

描述该用例要执行的先决条件。

7、测试输入

执行用例时需要输入的外部数据。

8、操作步骤

执行用例时的操作顺序。

9、预期结果

根据需求规格说明书，描述该条用例用户期望达到的隐性或者显性的需求。

预期结果要从两方面来描述：

1、界面预期：根据操作步骤操作后，系统做出的页面反馈信息。

2、功能预期：从数据记录、流程响应、界面调用等方面来描述预期

10、实际结果

执行用例填写的实际执行情况（通过/不通过）

用例设计方法：

等价类

在被测对象的某个测试输入域中，其中一个个体能够发现被测对象的某种缺陷，那么该集合中的其他个体也能揭露该缺陷，可以称该输入域集合为一个等价类。

有效等价类：对需求规格而言，有意义，有效的输入集合

无效等价类：对需求规格而言，无意义，无效的输入集合（异常输入）

等价类划分原则：

1、若需求规格说明书中明确规定了取值范围或者值个数时 ，可以划分一个有效等价类和两个无效等价类

2、若需求规格说明书规定了输入值的集合或者必须遵循某个规则，则可以划分一个有效等价类和一个无效等价类

3、若输入的条件是一个布尔值（真假值），则可以确定一个有效类和一个无效等价类。

4、若需求规格说明书中规定了输入的数据是一组值，且程序对每一个值分别处理，则可以划分若干个有效等价类和一个无效等价类。

5、若需求规格说明书中规定了输入数据必须遵循某一些规则，则可以划分一个符合规则的有效等价类和若干个从不同角度违反规则的无效等价类。

设计步骤：

1、划分等价类

2、给所有的有效等价类和无效等价类分别编号

3、抽取用例的编号

一条有效用例需要覆盖所有的有效等价类。但是其中互斥的有效等价类需要重新设计一条用例，直到所有的有效等价类被完全覆盖。

一条无效用例只覆盖一个无效等价类，也就是说一个无效等价类就是一条无效用例

边界值：

需求规格说明书中，规定了输入域有边界时，采用边界值法。

[6,18]    6 ，18  ，12         5,  19

(6,18)    7 ,  17   ,  10         6,  18

判定表：

当需求规格中有多个输入域，且输入域之间存在逻辑业务关联时即（不同的输入域的组合可以产生不同的响应结果）可以使用判断表来分析和设计用例。

设计步骤：

1、找到需求中的所有条件桩和动作桩

条件桩：需求中的所有输入域

动作桩：需求中的响应结果

2、确定条件项和动作项

条件项：条件桩的可能取值

动作项：动作桩的可能取值

3、按照需求设计并优化判定表

4、抽取用例

状态迁移：

需求规格说明书中有明确的状态变化时，需要根据状态的迁移路径来设计测试用例。

设计步骤：

1、找出需求规格说明书中定义的所有状态

2、标记出这些状态之间的迁移路径和条件绘制出状态迁移图

3、找出迁移图中的开始节点和结束节点，绘制出开始到结束节点的状态迁移路径

4、抽取用例，一条状态迁移路径就是一条测试用例。

场景设计：

需求涉及到业务流程的就需要使用场景设计法来设计测试用例。

3中业务场景：

基本流：输入经过每一个正确的流程运转最终达到预期结果

备选流：输入经过每一个流程运转时可能产生异常情况，但是经过纠正后仍然达到预期结果

异常流：输入经过每一个流程运转时，产生了异常终止情况

设计步骤：

1、熟读需求规格说明书，理清业务流程（流程中的每一个事件点）

2、画出场景流程图

3、根据场景流程图，提取业务流程，然后设计用例（一个流程一条用例）