软件测试学习（二）

软件质量

指软件产品满足基本需求及隐式需求的程度。（基本需求指其能满足软件开发时所规定需求的特性）

分为三个层次：满足用户需求；满足需求规定；满足隐式需求；

软件质量模型

有6大特性和27个子特性：

功能性

适合性：提供了相应的功能

准确性：正确（用户需要的）

互操作性：产品与产品之间交互数据的能力

保密安全性：允许经过授权的用户和系统能够正常访问相应的数据和信息，禁止未授权用户的访问

依从性：国际/国家/行业/企业标准规范一致性

可靠性

产品在规定条件下，在规定的时间内完成规定功能的能力；

成熟性：防止内部错误导致软件失效的能力

容错性：软件出现故障。自我处理能力

易恢复性：失效情况下的恢复能力

依从性

易用性

在指定条件下，产品被理解、学习、使用和吸引用户的能力；

易理解性、易学性、易操作性、吸引性、依从性

效率性

在规定条件下相对于所用资源的数量，软件产品可以提供适当性能的能力；

时间特性：平均事务响应时间，吞吐率，TPS（每秒事务数）

资源利用性：CPU、内存、磁盘、IO、网络带宽、队列、共享内存

效率依从性

软件维护性

规定条件下、规定时间内、使用规定的工具或方法修复规定功能的能力；

易分析性：分析定位问题的难易程度

易改变性：软件产品使指定的修改可以被实现的能力

稳定性：防止意外修改导致程序失效

易测试性：使已修改软件能被确认的能力

依从性

可移植性

从一种环境迁移到另一种环境的能力；

适应性：适应不同平台

易安装性、共存性、易替换性、依从性

软件测试类型

功能测试

通过直接运行软件的方式对前端（用户界面）的输入和输出功能进行测试，来检验软件能否正常使用各项功能、业务逻辑是否清楚、是否满足用户需求。所涉及的软件产品可能是Web程序、手机app，也可能是微信小程序。

接口测试

可以使得测试提前切入。测试人员可以在界面没有开发完成之前就进行测试，以便提早发现问题。接口测试可以将测试工作前置，前后端分离。

功能：可以发现很多在前端页面上操作时发现不了的Bug；可以检查系统的异常处理能力；减少人工回归测试的人力成本与时间成本，缩短时间周期。

性能测试

通过模拟生产运行的业务压力或用户使用场景来测试系统是否满足生产性能的要求，为软件产品的使用者提高高质量、高效率的软件产品。

测试方法

黑盒测试

通过软件外部表现来发现缺陷和错误。不关注程序内部结构和处理过程，仅针对程序是否能适当地接收输入数据、是否产生正确输出信息等进行测试。

 主要检测的错误类型

1.是否有不正确或者遗漏了的功能

2.在接口上能否正确地接受输入数据，能否产生正确地输出信息

3.访问外部信息是否有错

4.性能上是否满足要求

5.界面是否错误，是否不美观

6.初始化或终止错误

优点

不需要了解程序内部的代码及实现，操作简单；

与软件内部实现无关，不考虑内部逻辑结构及内部特性；

从用户角度出发，易于知道用户会用到的功能、遇到的问题；

适用于功能测试、可用性测试及可接受测试；

缺点

不可以覆盖所有代码，覆盖率较低，大概只可以达到总代码量的30%，有些Bug检测不出来；

自动化测试的复用性较低；

如果需求规格说明书不全面，得到的测试结果也不会很完善；

用例设计方法

等价类划分法

将输入数据按需求进行分类，划分为若干子集，子集即为等价类；子集互不相交；

有效等价类：有效值的集合，符合程序要求、合理且有意义的输入数据；

无效等价类：无效值的集合，不符合程序要求、不合理或无意义的输入数据；

同一个等价类中的数据发现程序缺陷的能力是相同的。

划分原则

1）输入值为一个有限区间的值——划分为一个有效等价类和两个无效等价类；

eg:分数在[1-10]之间，则有效等价类：{x|1<=x<=10};无效等价类：{x|x>10}、{x|x<1}

2)输入值为一个“必须成立”的情况or规定输入值的集合——划分为一个有效等价类一个无效等价类；

eg:输入值s第一个字符必须为数字，则有效等价类：{s|s第一个字符为数字}；无效等价类：{s|s第一个字符不是数字}

3）输入值为布尔值——划分为一个有效等价类一个无效等价（true、false）

4）输入值条件有n种情况且各情况处理不同——划分为n个有效等价类一个无效等价

eg:输入值x取值为1、2、3三个数之一，则有效等价类：{x|x=1}、{x|x=2}、{x|x=3}；无效等价类：{x|x!=1,2,3}

5)规定输入数据必须遵守的规则——划分一个有效等价类（符合规则），若干个无效等价类（从不同角度违反规则）

eg:邮箱格式输入密码规则不能包含空格、长度为8-10字符、必须包含字母和数字，则有效等价类{x|x不包含空格、长度为8-10字符、必须包含字母和数字};无效等价类：{x|x包含空格}、{x|x<8}、{x|x>10}、{x|x不含数字}等

设计测试用例

确定测试对象，保证非测试对象的正确性；

为每个等价类规定一个唯一编号；

设计有效等价类的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，直到测试用例覆盖了所有的等价有效类；

设计无效等价类的测试用例，使其覆盖所有的无效等价类。

边界值分析法

对软件的输入或输出边界进行测试的一种方法，通常作为等价类划分法的一种补充测试。

在边界附近寻找某些点作为测试数据，而不是在等价类内部选择测试数据；

若输入或输出的是一组有序集合，可以选取第一个和最后一个元素作为测试数据；若被测试的程序中有循环，则可以选取第0次、第1次与最后两次循环；选取的边界值个数为5个或者7个；

5个测试值：略小于最小值、最小值、正常值、最大值、略大于最大值。

7个测试值：略小于最小值、最小值、略大于最小值、正常值、略小于最大值、最大值、略大于最大值。

eg:边界值为0和1000，测试数据为-1,0,1,500，999,1000,1001

判定表方法

决策表也叫判定表，实质是一种逻辑表。可以把复杂的逻辑关系和 多种条件组合的情况表达的既具体又明确，利用决策表可以设计出完整的测试用例集合。

决策表的组成部分

条件桩：列出问题的所有条件，除了某些问题对条件的先后次序有要求之外，通常决策表中所有所列条件的先后次序都无关紧要。

条件项：条件桩的所有可能取值。

动作桩：问题可能采取的操作，操作一般没有先后次序之分。

动作项：指出在条件项的各组取值情况下应采取的动作。

规则指 任何一个条件组合的特定取值及其系那个硬要执行的操作；即决策表中的每一列就是一条规则，每一列都可以设计一个测试用例。

因果图法

根据输出对输入的依赖关系设计测试用例的方法；因果图需要处理输入之间的作用关系同时考虑输出的情况，将两者之间复杂的逻辑关系用图示来展现。

因果图的基本符号

1）输入条件与输出结果之间的关系

恒等：若原因出现，则结果出现；若原因不出现，则结果不出现；

若a=1,则b=1；若a=0,则b=0

非：若原因出现，则结果不出现；若原因不出现，则结果出现；

若a=1,则b=0；若a=0,则b=1

或：若几个原因中有一个出现，则结果出现；若几个原因都不出，现则结果不出现；

若a=1或b=1或c=1，则d=1；若a=b=c=0，则d=0

与：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现；

若a=b=c=1，则d=1；若a=0或b=0或c=1，则d=0

2）输入或输出的约束关系

互斥 ：众多原因不会同时成立，最多只有一个可能成立

包含：众多原因中至少有一个必须成立

唯一：众多原因中必须有一个成立，且只有一个成立

要求：当a出现时b也必须出现

屏蔽：若a=1，则b必须为0；a=0时b值不定。

场景法

用来描述用例流经的路径，从开始到结束遍历整条路径上所有的基本流和备选流。

基本流：按照正确的业务流程实现的一条操作路径（模拟正确的操作流程）。

备选流：导致程序出现错误的操作流程（模拟错误的操作流程）。

场景法主要针对系统的业务流程来进行测试；

适用范围

多个功能间的组合测试；在冒烟测试时主要采用场景法进行测试；

正交试验法

功能图法

错误推测法

黑盒测试方法选择策略

首先进行等级类划分，是提高效率的最有效方法；

在任何情况下都必须使用边界值分析的方法；

依赖测试工程师的智慧和经验用错误推测加一些测试用例；

针对逻辑比较简单的测试对象，可以直接使用判定表法；

如果程序的功能说明书含有输入条件的组合情况，可以选择因果图法；

对于业务清晰的系统，可以利用场景法贯穿这个测试过程

白盒测试

通过对程序内部结构的分析与检测来寻找软件的方法。又称为结构测试。需要清楚了解程序内部结构及逻辑路径是否正确、检查软件内部动作是否符合软件设计说明书的规定来发现程序中的缺陷。

分类

静态方法

不用运行程序，包括代码检查、静态结构分析、代码质量度量、文档测试等等。

动态方法

需要执行代码，分析软件系统在模拟或真实的环境中执行前、执行中、执行后的行为，包括功能的确认与接口测试、覆盖率分析、性能分析、内存分析等。

优点

帮助软件测试人员增大代码的利用率，提高代码的质量，发现代码中的隐藏问题。

缺点

程序运行会有很多的不同路径，不可能测试所有的运行路径；

测试基于代码，只可测试开发人员操作是否正确，不能知道设计的正确性，可能会漏掉一些功能需求；

系统非常庞大时，测试开销会很大。

方法

逻辑覆盖法——通过对程序逻辑结构的遍历实现对程序的覆盖

语句覆盖

目的：测试程序中的代码是否被执行，只测试代码中的执行语句，不包括头文件、注释、空行等。

只可以覆盖某一条路径，使得该路径中的每一个语句至少被执行一次，但不会考虑各种分支组合情况。

语句覆盖不可以发现语句之间的内部逻辑关系，不能满足白盒测试的所有逻辑语句基本要求，语句覆盖是弱覆盖方法。

判定覆盖

又称为分支覆盖，原则是设计足够多的测试用例，在测试过程中保证每个判定至少有一次为真值，有一次为徦值。

作用：使真假分支均被执行；但是内部条件的覆盖也会被遗漏，也属于弱覆盖。

条件覆盖

设计足够多的测试用例，使判定语句中的每个逻辑条件取真值与徦值至少出现一次。

条件分支覆盖的状态下仍旧不能满足判定覆盖。

判定-条件覆盖

设计足够多的测试用例，使得判定语句中所有条件的可能取值至少出现一次，所有判定语句可能结果也至少出现一次。

仍然存在遗漏测试的情况。

条件组合覆盖

设计足够多的测试用例，使得判定语句中所有条件的可能取值至少出现一次，并且每个判定语句本身的判定结果也至少出现一次。

与判定-条件覆盖区别为：条件组合覆盖要求每个条件结果的所有可能组合都至少出现一次，例如有4个条件，结果有两个，即真或假，则会有2的4次方16个测试用例；在从中去掉两个条件互相矛盾的用例。

条件组合覆盖包括所有判定-条件覆盖，但是在程序中条件较多时，条件组合数量呈指数型增长，测试用例数量也会增加，使得测试效率降低。

注意！：

满足判定覆盖一定满足语句覆盖；

满足条件覆盖一定满足语句覆盖；

判定覆盖和条件覆盖都是单一覆盖，不存在判定覆盖满足条件覆盖、条件覆盖满足判定覆盖这一说法；

满足判定-条件覆盖一定满足条件覆盖；

满足条件组合覆盖一定满足判定-条件覆盖；

灰盒测试

基于程序运行时的外部表现同时结合程序内部逻辑结构来实际用例、执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。

介于黑盒测试和白盒测试之间的测试。关注对于输入的正确性，同时也关注程序内部的表现，但只通过表面上的现象、事件和标志来判断内部状态，不像白盒测试那样详细。

测试手段

手工测试

手工测试不可替代的方面：测试用例的设计、界面和用户体验测试、正确性检查。

自动化测试

通过编写代码来代替手工的重复性测试工作，对经常需要多次回归的测试用例进行代码化，可以提高测试效率、解放人力。

应用领域：UI自动化测试（模拟人在界面上的操作）、接口自动化测试（模拟调用接口传不同的参数）、单元自动化测试；

收益：单元自动化测试>接口自动化测试>UI自动化测试