软件测试基础

一、测试基本入门

1.知道测试是什么，不是什么。

2.知道怎么去做测试.

3.从标准和规范的角度，保证全流程软件系统，防范质量风险.

二、软件测试的定义

“软件测试是使用人工或自动的手段来运行或测试某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别.”

人工或自动的手段 系统的过程 满足规定的需求 弄清预期结果与实际结果之间的差别

三、软件的生命周期

计划 需求分析 设计 编码 测试 运行和维护

1.计划:确定开发目标 完成项目的可行性研究(确定项目能不能做，做出来之后有没有意义) 对项目进度进行预估和安排(找人 找时间 确定预算) 指定实施计划

2.需求分析:分析和整理项目的需求项(确定项目具体有哪些项目需要开发，产品具有哪些详细的特性) 根据整理出来的需求项，编写需求规格说明书 指定产品原型(Axure)

3.设计:完成项目概要设计 完成项目详细设计

4.编码:根据概要设计说明书以及详细设计说明书编写程序代码

5.测试:单元测试(对程序的最小单位进行测试的过程，最小单元指函数或者一个类的代码) 集成测试(对模块与模块之间调用的接口进行的测试) 系统测试(对完成编码的系统整体进行测试的过程) 验收测试(交付给客户或最终用户时，和客户一起完成的测试)

6.运维:产品部署 运行维护 功能升级 性能提升

四、常见测试模型

模型:将比较抽象的事务用比较形象的方式表现出来

1.传统的瀑布模型 

最大的问题是测试工作后置 导致整个项目开发完成之后如果发现比较重要的问题，修改的成本是巨大的

2.V模型 V模型主要的特点是将测试过程细化，分为了单元测试、集成测试、系统测试和验收测试四个不同的阶段，但是仍然是测试后置，没有解决风险问题.

(1)测试阶段分得很清楚 (2)每个测试阶段都有相应的开发文档支持 (3)测试与开发是串行进行的而不是并行，也就是测试需求等开发完成后再开始 (4)测试对象只有程序，而不包括需求等其他的文档 (5)V模型是瀑布模型的变种，瀑布模型存在的问题V模型也存在 

 3.W模型 W模型将测试和开发过程分离出来 对整个项目过程中的需求文档、设计文档同样要进行测试 将测试工作前置，大大降低了整个项目的质量风险

4.敏捷测试模型:敏捷模型主要的特点是为了适应现代互联网公司的”短平快”的开发节奏而设计的一种测试和开发模型

迭代:每次迭代叫做一个sprint,每个sprint里面选出来要实现的需求会安排到sprint backlog里面,每个sprint一般以一个月作为一个周期 

 产品经理整理出整个项目的所有需求并且按照需求的优先级来将需求排列到product backlog.

五、软件质量模型

质量模型是基于ISO25000和国标GB/T25000制定的可用于测量产品质量的模型，该模型提供了从不同维度考量产品质量属性的依据.

质量模型规定的各种不同质量属性和不同的测试类型之间具有映射关系，所以可以用不同的测试类型来测试不同的质量属性.

利用8大软件质量模型对水杯进行测试点的提取

常见的测试类型

功能性测试 验证产品能否满足用户特定功能要求并做出正确响应        

安全性测试 验证产品是否有保护数据的能力，并能在合适的范围内承受恶意攻击

兼容性测试 验证产品是否能够和其他相关产品顺利对接

配置测试 验证产品是否能够在推荐配置上流畅运行，验证产品为了完成特定功能的输入是否会出现故障

可靠性测试 验证产品在长时间运行下能否满足保证系统的性能水平，在存在异常的情况下系统是否依然可靠

易用性测试 验证产品是否易于理解，易于学习和易于操作

性能测试 测试产品提供某项功能时的时间和资源使用情况

安装测试 测试产品能否被正常安装并运行          

按代码是否可见将测试类型划分为黑盒测试、白盒测试和灰盒测试

黑盒测试:指在不知道被测软件代码结构的基础上，根据产品需求规格、站在最终用户的角度来对软件的输入和输出进行测试的过程叫黑盒测试

白盒测试:指基于被测软件的代码和结构，对被测软件的代码和结构本身进行测试的过程叫白盒测试

灰盒测试:介于白盒和黑盒之间，一般来说灰盒是针对接口来进行测试，比如只知道函数的函数名、参数以及返回值，并不知道函数内部的实现结构

测试流程

分析:需求评审、测试需求分析 得到测试点

计划:测试计划和方案文档编写 

设计:测试用例设计

实现:编写测试用例、测试脚本等

执行:搭建测试环境、执行测试脚本、缺陷报告

需求评审  合同型项目(有甲方乙方) 用户业务需求->产品需求   产品型项目(没有明确的用户) 协议/标准/规范 继承性需求 竞品分析

需求评审检查表

测试需求分析 明确测试的系统是干什么的  系统有哪些特点  系统有哪些功能  系统的业务流程是什么  系统在这个版本上，哪些需要测试，哪些不需要测试  系统对性能、安全性上有没有要求

测试需求分析流程   

1.根据产品需求提取系统的测试点 

2.编写需求跟踪矩阵 

3.根据测试点利用适当的测试用例设计方法设计测试用例

测试设计的概念 将测试点转化为测试用例的过程，就叫测试设计

测试用例的概念 测试用例就是一种用来说明具体如何进行测试操作并验证结果的文档

测试用例编写

测试编号:TC_系统名称_模块名称_编号 

测试标题:用一句话来表述该条用例是测试哪个测试点的

优先级:高中低，作用是在项目时间不够或者人员不足的时候，可以优先测试重点的测试用例

预置条件:在执行该条用例时，系统必须预先达到的一个状态或者条件

测试步骤:详细描述在测试这条用例时，需要进行哪些操作

预期结果:来自于需求，要求我们达到的一个结果

实际结果:实际操作系统之后得到的结果

测试结果:pass/fail/NA  pass预期结果和实际结果相同.fail预期结果和实际结果不相同.N/A指当前用例不合适或无法操作

常用测试用例设计方法

等价类  某个输入域的集合，在这个集合中每个输入条件都是等效的，如果其中某一个输入不会导致问题，则集合中其他输入条件进行测试也不可能发现问题

有效等价类:有效等价类即对程序有意义、正确的输入数据

无效等价类:无效等价类即对程序无意义、不正确的输入数据

等价类划分原则:

1.如果输入条件规定了取值范围或值的个数，则可以确定一个有效等价类和两个无效等价类 例如:要求函数有三个参数 三个参数为一个有效等价类 小于三个和大于三个都是无效等价类

2.输入条件规定了输入值的集合，或是规定了必须如何的条件，则可以确定一个有效等价类和一个无效等价类

3.在输入条件是一个布尔值的情况下，可确定一个有效等价类和一个无效等价类

4.如果我们确知，已经划分的等价类中各个元素在程序中的处理方式不同，则应该将此等价类进一步划分

5.在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类和若干个无效等价类 例如:要求输入的数据必须是一个正整数，那么正整数是一个有效等价类 无效等价类可以是0，小数，负数

等价类设计步骤:

1.编写等价类表，为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号

2.设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤，使得有效等价类均被测试用例所覆盖

3.设计一个测试用例，使其只覆盖一个无效等价类。重复这一步骤，使得所有无效等价类均被覆盖

边界值

对程序的输入和输出边界进行测试的一种黑盒用例设计方法，常与等价类设计法结合使用，此时它的用例来自于等价类的边界

边界值分析法的理论基础是假定大多数的错误是发生在各种输入条件的边界上，如果在便捷附件的取值不会导致程序出错，那么其他的取值导致程序错误的可能性也很小

边界值使用条件(重点:可度量)

输入条件明确了一个值的取值范围，或是规定了值的取值个数

输入条件明确了一个有序集合

上点:边界上的点(优先级高)   范围中能看到的点一定是上点  20<age<80 上点为20和80 

离点:离边界最近的点(优先级高)

内点:取值域内的任意一点

使用括号法快速判断离点 离括号最近的点为离点

20<=age<=60    19,(20,21...59,60),61 上点为20和60 离点为19和61

20<age<60       19,20,(21...59),60,61 上点为20和60 离点为21和59 一个数只能为上点或离点

边界值法分析原则

如果输入输出条件规定了取值范围，则应该以该范围的边界内的及边界附件的值作为测试用例

如果输入输出条件规定了值的个数，则用最大个数、最小个数，比最小个数少1，比最大个数多1的数作为测试用例

如果程序规格说明中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试用例

如果程序中使用一个内部数据结构，则应该选择这个内部数据结构的边界上的值作为测试用例

边界值设计用例步骤:

1.分析输入参数的类型:从测试规格中分析得到输入参数类型

2.等价类划分(可选):对于输入等价类划分方法进行等价类的划分确定边界

3.边界值划分:运用边界值测试分析方法确定域范围的边界(上点、离点与内点)

4.形成测试项:选择这些上点、离点与内点或者这些点的组合形成测试项

把输入条件分成多个不同的子条件，条件与条件之间相对独立，没有制约关系

判定表

具有因果关系或条件制约的测试场景，需要使用判定表法进行测试点的提取

判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确

 判定表设计步骤:

1.确定规则的个数。如有三个条件，每个条件有两个取值，则有2*2*2=8种规则

2.列出所有的条件桩和动作桩

3.填入条件桩

4.填入动作桩和动作项

5.化简，合并相似规则

6.将每条规则转化为用例

流程分析法(场景设计法)

流程分析法(又名场景设计法)是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。根据流程的顺序依次进行组合，使得流程的各个分支都能走到。这是从白盒测试中路径覆盖分析法中推广到黑盒测试中来的测试分析方法

基本流:指所有操作都正确的主流程

备选流:指部分操作不正确的流程分支

流程分析法用例设计步骤:

1.画出业务流程图

2.设置功能路径优先级

3.确定测试路径

4.选取测试数据

5.构造测试用例

错误猜测法

错误猜测法就是根据经验猜想可能有什么问题并依次设计测试用例

错误猜测法只能作为测试设计的补充而不能单独用来设计测试用例，否则可能会造成测试的不充分

测试猜测不是瞎猜，不是没有根据和目的的猜测。它需要依据对系统薄弱地方的了解和对开发人员盲点的了解

测试用例设计总结

测试用例设计方法很多，我们不仅要知道每种方法怎么用，更需要清楚每种方法使用的场景

等价类和边界值是任何其他测试设计方法的基石，必须首先考虑使用等价类和边界值进行用例设计

当输入域与输入域之间有约束关系，必须使用判定表来进行组合

在考虑了所有测试用例设计方法后，最后还要使用错误猜测法进行补充，以免遗漏

在测试某一个字段时，应保证其他字段的取值是一个正常值

测试点提取思路

1.首先检查界面元素的显示是否正确

2.测试页面的基本功能。如果页面既有表单(既有输入域又有提交按钮的页面，都叫表单页面)也有列表，则优先测试表单功能是否正常

3.针对表单在测试时，需要依据表单里面的每个字段依次进行测试。凡是用户可输入的输入域，都要使用等价类和边界值根据字段的约束来进行考虑

4.如果多个字段之间有关联关系和制约关系，那么在测试完单个字段的等价类和边界值之后，应该继续使用判定表等测试方法进行组合的测试

5.表单测试完后，再测试列表中的功能

6.当单个页面的内容都测试完毕后，再来结合流程分析法(场景法)测试流程相关的内容

7.流程分析测试完后，最后再使用错误猜测法来确保没有遗漏的测试点

如果测试时间较短，无法完整地设计和书写测试用例时，一般会直接写测试点来代替测试用例 

建立需求跟踪矩阵

需求跟踪矩阵指的是根据产品需求和测试点以及测试用例，建立一个三者映射的列表，这个表叫做需求跟踪矩阵 

需求跟踪矩阵的作用

1.建立产品需求、测试需求与测试用例之间的映射关系，方便进行用例需求覆盖率统计

2.如果需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新

关于缺陷

缺陷的定义

1.软件没有实现产品说明书所描述的功能

2.软件实现了产品说明书描述不应有的功能

3.软件执行了产品说明书没讲的操作

4.软件没有实现产品说明书没讲但应该实现的功能

5.从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对

缺陷的生命周期

描述缺陷管理流程或者生命周期，必须要写清楚两点:

1.缺陷管理里面每一步是如何进行流转的，并且负责人是谁

2.缺陷管理每一步对应的缺陷的状态

填写缺陷报告

一个完整的测试报告一般包含一下内容:

1.缺陷编号  系统名_模块名_bug_编号  

2.用例编号  哪条用例发现了这个缺陷 缺陷由探索性测试发现可以不填

3.预置条件  

4.缺陷标题 用一句话来描述缺陷如何产生

5.测试步骤

6.严重程度

7.优先级

8.重现率

9.缺陷状态

缺陷严重程度分类

严重性:顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响

1.致命:软件的意外退出甚至操作系统崩溃，造成数据丢失

2.严重:由于单功能失效导致多个相关功能均失效

3.一般:软件的单个功能失效

4.提示:软件界面的细微缺陷，某个控件没有对齐，某个标点符号丢失等

如何处理不可重现的缺陷？

一定要提交到缺陷管理库

1.一定要详细描述遇到缺陷的过程和相关环境配置，如果有日志的话，一定要附上相关的操作日志或者系统运行日志

2.对于不可重现的缺陷，一定要尽量描述清楚复现率是多少

3.对于不可重现的缺陷，当开发人员将缺陷设置为fixed之后，在验证时，不能只在一个版本上去验证缺陷是否修复，必须至少在3个以上的版本上验证后都没有重现过，才能将缺陷关闭

回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试。

目的:检查缺陷是否真的被修复了 程序员在修复缺陷的过程中有没有引入新的缺陷

回归测试流程:

1.在测试策略制定阶段，制定回归测试策略

2.确定需要回归测试的版本Version，哪个版本上bug被修改了就在哪个版本上回归

3.回归测试版本发布，按照回归测试策略执行回归测试

4.回归测试通过，关闭缺陷报告单

5.回归测试不通过，缺陷报告单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

回归测试策略:

1.完全回归: 重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性

2.选择性回归:即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序

选择性回归三种选择方法

1.覆盖修改法: 即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法

2.周边影响法: 该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点

3.指标达成方法: 这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖，与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。

验收测试

在通过了内部系统测试之后，就可以开始验收测试

验收测试是以用户为主的测试，验收组应该由项目组成员、用户代表等组成

验收测试原则上在用户所在地进行，但如经用户同意也可以在公司内模拟用户环境进行

验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试

对于产品型的项目，验收测试一般又分为alpha测试和Beta测试两种

alpha测试（内测）

α测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试

α测试时，软件在一个自然设置状态下使用。开发者坐在用户旁，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试

α测试的目的主要是评价软件产品的功能、局域化、可用性、可靠性、性能和技术支持

Beta测试（公测）

β测试是由软件的多个用户在一个或多个用户的实际使用环境（生产环境）下进行的测试

与α测试不同的是，β测试时开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用

目前在很多互联网公司也称为灰度测试

生命周期各测试方法对比 

项目管理工具禅道的使用

 测试执行全过程

测试执行工作流程

1.确定测试用例优先级

2.创建测试数据，同时也可以准备测试工具和设计自动化测试脚本

3.创建本次测试的测试套件，以提高测试执行的效率

4.确认已经正确搭建了测试环境

5.根据计划的执行顺序，通过手工或使用测试工具来执行测试套件内的用例

6.记录测试执行的结果，以及被测软件、测试工具和被测软件的标识和版本

7.对比实际结果和预期结果之间差异，如果确认是缺陷需要填写缺陷报告

8.缺陷被开发人员修改后，重新进行下一轮的测试