首页  思维导图  详情

软件测试

2017-09-25 09:41:34   0  举报





仅支持查看

AI智能生成

为你推荐

查看更多



CMMI5 测试应该怎么做？系统测试、验收测试汇总

软件测试的课程概况..............

作者其他创作

大纲/内容

Software Testing概述

第一章软件测试核心概念

什么是软件测试

软件

程序+数据库+文档+服务

软件测试

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

软件需求说明书

为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础

硬件、功能。性能

输入输出、接口需求、警示信息、保密安全

数据与数据库

文档和法规

测试的核心与实质

根本目的是确保软件满足用户需求

目的是要衡量软件产品是否符合预期量

软件测试工作的认识误区

为什么进行软件测试

提高软件质量

确保软件满足需求

什么是软件缺陷

软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好

软件未达到需求规格说明书中指明的功能

软件出现了需求规格说明书中指明不该出现的错误

软件功能超出需求规格说明书中指明的范围

软件未达到需求规格说明书中虽未指出但应达到的目标

什么是测试用例

是一组测试输入、执行条件和预期结果，目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求

第二章软件测试的背景

软件测试发展历程

初始阶段

定义阶段

集成阶段

管理、测量和最佳化阶段

软件测试现状

国外现状

相当成熟，并已成为一个独立的产业

国内现状

萌芽中的市场正在起步

外包测试现状

现场测试模式

内部测试模式

设立联合研发中心模式

学习软件测试的意义

对于测试工程师

扎实的理论基础

对于软件开发工程师

帮助分析复杂需求

提高代码质量

等价类划分

为什么引入等价类划分法

可以通过等价划分满足测试的完备性和无冗余性，避免测试工作量过大，并且测试不合理

什么是等价类测试

定义：依据需求对输入的范围进行细分，然后再分出的每一个区域内选取一个有代表性的测试数据开展测试

等价类满足的条件

被测系统对该等价类中的每个数据的处理方式相同

各等价类之间互不相交

所有等价类的并集是整个输入域

如何使用等价类划分

等价类划分的简便原则

将某个输入条件所有可以取的值划分为一个有效等价类，其余取值划分为一个无效等价类

针对有效等价类，通过不断施加规则，将满足规则和不满足规则的数据划分为不同的有效等价类

重复该步骤，将有效等价类中不断划分为更多子有效等价类，直至无法继续划分为止，最终得到的每个有效等价类代表了被测对象的一种特殊的处理方式

强组合

得到的测试用例完全覆盖所有输入条件的有效等价类的所有组合情况

弱组合

测试用例仅需覆盖所有输入条件的有效等价类即可

无效等价类的测试用例

测试用例引入单缺陷假设，即一个测试用例，仅覆盖一个输入条件的某一个无效等价类

针对输出域的等价类测试

选择合适的输出域来划分等价类

针对选定的输出域划分等价类

根据划分的等价类设计测试用例

等价类测试用例设计步骤总结

1.分析被测对象的输入域和输出域，若二者不相似，则针对输入域的等价类测试之后，还需要针对输出域进行等价类测试

2.分析被测对象的输入域和输出域，若二者不相似，则针对输入域的等价类测试之后，还需要针对输出域进行等价类测试

3.若针对整体输入域划分有效和无效等价类，则对每个等价类设计一个测试用例，转第（7）步

4.若针对个体输入域划分有效和无效等价类，则执行第（5）步

5.对于有效等价类，在强组合方式下设计测试用例

6.对于无效等价类，基于单缺陷假设来设计测试用例

7.设计测试用例时，对于每个等价类，通常测试数据的选择是从该等价类中抽取一个正常值，即该取值范围内的一个较接近中值的数据即可，若输入条件是布尔型或逻辑型条件，则不存在典型数据的抽取问题

8.若需要针对输出域进行等价类测试，则选择合理的输出域进行等价划分，并补充测试用例

正交表法设计测试用例

测试用例的设计

选择个体输入域，确定所有输入条件及其最大取值范围

确定每个输入条件的取值个数

选择合适的正交表

建立正交表

生成测试用例

混合水平正交表

Ln(q1^s1*q2^s2)

q1^s1：表示在所有输入条件中，有s1个输入条件的取值个数均为q1

q2^s2：表示在所有输入条件中，有s2个输入条件的取值个数均为q2

正交表：Ln(q^s)

s为每个因子的状态数（水平数），q为因子数

难点：如何根据系统的输入条件选择合适的正交表，以及根据测试用例的指标测量结果分析出最优的输入组合

适用场景：当输入条件较多，并且条件中参数值较多，若组合设计用例数量较大，则考虑使用正交实验法设计测试用例

场景法设计测试用例

基本思想

场景法：通过分析同一事件的不同触发顺序和处理结果，构建各个事件流，并基于这些事件的触发控制业务流程，形成多个不同场景，最终基于场景设计测试用例

基本流：是从系统的某个初始状态开始，经一系列状态变化后到达最终状态的过程中最主要的一个业务流程

备选流：以基本流为基础，在经过基本流上每个判定节点（包括条件判定和循环判定）处满足不同的触发条件。而导致的其他事件流。

基本流和备选流的区别

数目不同：基本流1条、备选流1条或多条

初始节点位置不同：基本流为系统初始状态，备选流为基本流或其他备选流

结束节点位置不同：基本流为系统默认终止状态，备选流为基本流或系统其他终止状态

节奔流为完整的业务流程，备选流为业务流程的执行片段

基本流可以构成场景，备选流需要和基本流共同构成场景

场景法使用步骤

分析需求，得出业务流程

得出基本流和备选流

基于这些事件流构建场景

根据场景设计测试用例

场景设计的基本原则

最少的场景数等于事件流的总数，基本流与备选流的总数

有且唯一有一个场景仅包含基本流

对应某个备选流，至少应有一个场景覆盖，且在场景中应该避免覆盖其他备选流

状态迁移图法

定义：是一种基于产品规格分析，对系统的每个状态及与状态相关的函数进行测试，通过不同的状态验证程序的逻辑流程，任何一个系统，如果对同一个输入，根据不同的状态，可以得到不同的输出，就是一个有限状态系统。

有限状态机：有限个状态以及在这些状态之间的转换和动作等行为的数学模型。可以用状态图、状态表、状态树表示

使用场合

多状态变化的情况

状态迁移图法的使用步骤

根据需求，理解关键字段，获得主要的状态

绘制状态迁移图

画出状态迁移树

抽取测试用例规则（每个状态至少到达一次）

测试过程管理

软件开发模型概述

什么是开发模型

软件开发模型是软件开发的全部过程、活动、任务和管理的结构框架。它给出了软件开发活动各阶段之间的关系。

软件开发模型常见类型

大爆炸开发法边写边改法瀑布模型快速原型法螺旋式开发

软件测试流程

熟悉需求—>拟定测试计划—>测试计划评审(未通过执行上一步)—>设计测试用例—>测试用例评审(未通过执行上一步)—>搭建测试环境—>实施测试—>测试评估—>测试总结

几个常用概念

黑盒测试

不考虑程序内部结构和内部特性的情况下检测每个功能是否正常使用

白盒测试

考虑程序内部结构和内部特性的情况下检测

静态测试

不运行程序，只是对程序进行检查和审核

动态测试

使用和运行程序进行检查

通过性测试

审查软件，描绘状态，尝试彀中合法可能性，确认状态及其转换正常

失效性测试

为了破坏软件而设计和执行的测试用例

边界值法

边界值分析定义

在被测对象的边界及边界附近设计测试用例

边界值测试难点

输入域（被测数据）的确定

整体输入域

多个输入条件共同构成的具有一定实际意义的输入域

个体输入域

输入条件分别构成的单个输入域的集合

边界的确定

边界点：可能导致被测系统内部处理机制发生变化的点

边界的确定的原则

若输入条件规定了取值范围，则以该范围作为边界

若输入条件规定了值的个数，则以值的个数为边界

若输入域是有序集合(如有序表、顺序文件等)，则选取集合中特定次序的数据作为边界，如第一个或最后一个数据等

边界点附近领域的设置

对于每个输入条件的每个边界点(设为P点)，需在该点附近确定大小为1的邻域（注意：这里的“1”是指1个单位长度）

数据选择

穷举法

在每个边界点的邻域范围内取所有数据

典型值法

边界组合方式

强边界法

测试用例覆盖所有输入条件的所有边界组合

弱边界法

基于单缺陷假设，仅覆盖输入条件的单个边界点即可

全边界法

强边界+弱边界

针对输出域的边界值测试

输出域边界点确定

边界点邻域

设计测试用例

决策表法设计测试用例

定义：是一个用表格形式来整理逻辑关系的工具，由横向的条件和动作和纵向的规则（测试用例）组合而成

决策表中的基本概念

条件桩：列出了问题的所有条件（输入区）

动作桩：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束（输出区）

条件项：列出针对它左列条件的取值。在所有可能情况下的真假值。（输入取值区）

动作项：列出在条件项的各种取值情况下应该采取的动作（输出取值区）

规则：决策表中右部的每一列（条件项和对应的动作项）都是一条规则

化简决策表的规则

输出相同：欲化简的多个测试用例的输出结果应相同

输入相似：仅有一个输入条件的值可以不相同

决策表法设计用例的步骤

分析条件和动作

生成决策表

简化决策表

转成测试用例

决策表的适用场合

在程序中，若输入输出较多，且相互制约的条件较多

基于决策表的测试尽可能在一定程度上消除测试冗余，但仍会受到各输入条件的等价划分的限制，并不保证达到完全无冗余

因果图测试

产生背景：等价类划分法和边界值分析法都着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系，多个输入条件组合起来可能出错的情况被忽略了。

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

优点：将自然语言转化为形式语言规格说明的一种严格方法，可以指出规格说明存在的不完整性和二义性。

因果图中的4种基本关系

恒等：若 c1 是1，则 e1 也为1，否则 e1 为0

非：若 c1 是1，则 e1 为0，否则e1为1

或：若 c1 或 c2 或 c3 是1，则 e1 为1，否则 e1 为0

与：若 c1 和 c2 都是1，则 e1 为1，否则 e1 为0

因果图中的约束

约束：在实际问题中输入状态相互之间、输出状态相互之间可能存在某些依赖关系

输入条件的约束

E约束(异)：a和b中最多有一个可能为1，即a和b不能同时为1。

I 约束(或)：a、b、c中至少有一个必须为1，即 a、b、c不能同时为0。

O约束(唯一)：a和b必须有一个且仅有一个为1。

R约束(要求)：a是1时，b必须是1，即a为1时，b不能为0。

输出条件的约束

M约束(强制)：若结果a为1，则结果b强制为0。

因果图生成测试用例的步骤

分析软件规格说明中哪些是原因，哪些是结果，并给每个原因和结果赋予一个标识符。（提取因果，赋予标识符）

分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系画出因果图。（提取因果关系，画出因果图）

由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。（标明约束条件）

把因果图转换为决策表。

根据决策表中的每一列设计测试用例。

应用场合

当软件的输入条件过多时，可以考虑输入的所有排列组合情况，考虑条件之间和条件结果之间关系，防止遗漏

局限性

测试用例数目可能会很大，不便于维护

5.1 概述

基本原理：基于软件的源代码。主要对程序内部结构展开测试，关注程序实现的细节

白盒测试关注的对象

源代码

直接查看源代码，查看代码的规范性，并对照函数功能查找代码的逻辑缺陷、内存管理缺陷、数据定义和使用缺陷等

程序结构

通过函数调用图、算法流程图等反映程序设计的相关图表，找到程序设计的缺陷，或评价程序的执行效率，以利于程序的结构优化

白盒测试的优势

针对性强，便于快速定位缺陷

在函数级别开始测试工作，缺陷修复的成本低

有助于代码优化和缺陷预防

测试效率高，通过不同的白盒覆盖指标有助于衡量对被测对象的测试覆盖程度

白盒测试的巨响性

对测试人员的技术要求高

成本高

准备时间长

适用阶段

当被测对象为函数时

当被测对象为功能时

测试方法的评价

通过重点关注源代码中不同类型的结构，引入不同的白盒覆盖指标，从而得到不同的白盒测试方法，这些方法的侧重点不同，对应源代码结构的覆盖程度也不同

通过引入白盒测试覆盖指标来评估黑盒测试方法的测试覆盖率

5.2 静态测试

概述

不需要实际运行被测软件，而是直接对软件源代码的形式和结构进行分析

静态白盒测试主要包括

代码检查

主要是通过同行评审发现缺陷

三类评审结果

正常

延期

取消

注意事项

计划和准备阶段

评审会议进行阶段

评审会议过后

静态结构分析

基本原理：通过引入多种形式的图表(如函数调用关系图、模块控制流图等)，帮助人们快速了解程序设计和结构，更好地理解源代码，以及找到程序设计缺陷和代码优化的方向

函数调用关系图

测试重点

函数之间的调用关系是否符合要求

是否存在递归调用

函数调用层次是否太深

是否存在孤立的函数

一般原则

有限测试根节点

优先测试叶子节点

接口数量多的节点需要优先测试

函数控制流图

由节点和边组成的有向图

节点表示一条或多条语句

边表示节点之间的控制走向，即语句的执行

作用

直观反应函数的内部逻辑结构

展示程序中明显的缺陷

揭示程序是否隐含缺陷

是否存在多出口情况

是否存在孤立的语句

环复杂度是否太大

是否存在非结构化的设计

在远离代码的条件下对程序进行分析

代码质量度量

软件质量模型

代码质量度量模型

代码质量自动度量

5.3 对判定的测试

测试用例设计

语句覆盖

基本思想：设计测试用例时应保证程序的每一条可执行语句至少执行一次（语句覆盖等同于对途中所有结点的覆盖）

关注语句而非判定表达式。语句覆盖的测试重点是所有的可执行语句，并非判定节点，因此，尽管语句覆盖可以识别未执行的代码块，却无法识别源代码中因控制流结构而导致的缺陷。

对隐式分支无效

判定覆盖

基本思想：设计测试用例时应保证程序中每个判定节点的取真和取假分支至少执行一次

并未彻底分析每个简单判定条件的取值情况，仍然会导致遗漏部分缺陷

条件覆盖

基本思想：设计测试用例时应保证程序中每个复合判定表达式中，每个简单判定条件的取真和取假情况至少执行一次

有时条件覆盖和判定覆盖率不能同时达到100%

判定/条件覆盖

基本思想：测试用例的设计应满足判定节点的取真和取假分支至少执行一次，且每个简单判定条件的取真和取假情况也应至少执行一次。

增大程序结构的复杂性，导致语句数目，路径数目等大大增加

and错写为or，判定/条件覆盖是无法发现缺陷的

条件组合覆盖

基本思想：测试用例的设计应满足每个判定节点中，所有简单判定条件的所有可能的取值组合情况应至少执行一次

含义

对于每个判定节点而言，其简单判定条件的所有取值组合情况应覆盖到

对于多个串联判定节点而言，判定节点的整体取值存在多种组合情况，也应完全覆盖到

当判定表达式本身较为复杂、且存在多个判定节点串联时，条件组合覆盖的测试用例规模大的惊人

修正的判定/条件覆盖

基本思想：在满足判定/条件覆盖的基础上，每个简单判定条件都应独立地影响到整个判定表达式的取值

设计测试用例的步骤

对每个简单判定条件，找到能够对整个判定结果产生独立影响的多组测试用例

抽取能体现所有简单判定条件独立影响性的最少独立影响对

无法处理存在耦合的判定表达式。（例如：year<1800||year>2050）

测试用例优化

尽量选择边界测试数据

应避免“与”、“或”关系的屏蔽现象

5.4 对路径的测试

什么是路径测试

是设计足够多的测试用例，使得被测试程序中的每一条路径至少被覆盖一次。注意：路径测试不一定满足条件覆盖，一定满足判定覆盖