当前位置：首页 > news >正文

【软件测试】

news 来源：原创 2025/4/20 7:51:23

第一章测试概述

PIE模型(这个是什么意思)

这三个含义

fault(缺陷)：静态存在于软件中的缺陷

**error（错误）😗*软件运行过程中，Fault表现出的不正确的中间状态

failure(失效) ：错误状态在软件执行过程中传播从而影响到软件的输出，导致用户或测试人员能观测到软件的失效行为。

PIE模型三要素：

执行（execution）:执行错误代码

感染(infection):执行错误代码触发错误的状态

传播(propagation):错误在软件系统中传播并影响到最终的输出结果

练习题(重要)：
Please construct a simple program P (with a fault) and 3 tests (t1, t2, t3), s.t.

t1 executes the fault, but no error

t2 (executes the fault and) produces an error, but no failure

t3 produces a failure

写出一个有fault 无error的程序和测试用例

#include<iostream>
using namespace std;
int main(){int a[3];cin >> a[0] >> a[1] >> a[2];int length = 3;int sum =0;for(int i=1;i<length;i++){ //faultsum +=a[i];}int avg = sum / length;cout << avg << endl;  return 0;
}  
//测试用例 ： 0 4 5 预期输出 3 实际输出 3

写出一个有fault 有error 无failure的程序和测试用例

#include<iostream>
using namespace std;
int main(){int a[3];cin >> a[0] >> a[1] >> a[2];int length = 2;int sum =0;for(int i=0;i<length;i++){ //faultsum +=a[i];}int avg = sum / length;cout << avg << endl;  return 0;
}  
//测试用例 ： 2 4 3 预期输出 3  实际输出 3

写出一个有fault 有error 有failure的程序和测试用例

#include<iostream>
using namespace std;
int main(){int a[3];cin >> a[0] >> a[1] >> a[2];int length = 3;int sum =0;for(int i=1;i<length;i++){ //faultsum +=a[i];}int avg = sum / length;cout << avg << endl;  return 0;
}  
//测试用例 ： 3 4 5 预期输出 4 实际输出 3

讨论题：

存不存在一个fault 永远不会被执行？（重要）

答：存在的

if(true){c = a-b //求两个数的差
}
else{c = a + b;
}

执行了fault 可能不可能没有error？

答：可能上面有例子

执行了fault 有error 可能不可能没有failure？

答：可能上面有例子（有两处错误的就可以了）

有没有一个bug 永远不会被检测出来？

答：有，不满足PIE模型的bug就不会被检测

那这个fault还是fault吗（重要）？不是 fault是被测试定义的测试不出来就没有fault

测试术语

**测试用例（不光是输入还要有预期结果！！！）**包括：测试输出预期输出环境

Test fixture(测试夹具)：测试的时候把环境固定下来
Test suite（测试套件） : （测试用例集test cases）
Test script（测试脚本）：自动运行测试用例
Test driver : 把测试夹具测试脚本集成固定环境自动运行测试用例
Test adequacy : (测试准则充分性准则) 代码覆盖率达到…

关键概念对比

测试和调试：

测试：执行软件，观察是否有失效，来发现Bug

调试：找到fault 理解fault 并且纠正fault 是修复Bug

确认和验证：

确认：我们的产品是否能满足用户的需求

验证：我们的产品满足需求规格说明书

静态测试和动态测试：

区分点：是否需要执行程序

静态测试不需要执行程序严格来讲不算测试动态测试需要执行程序我们这门课讲的测试就是动态测试

黑盒测试和白盒测试：

区分点：是否需要源代码。

黑盒测试不需要源代码白盒测试需要源代码

灰盒测试不是白盒测试+黑盒测试，而是我们通过某种手段获得了软件的部分结构信息进行测试。

测试层次

单元测试模块测试集成测试系统测试

V模型（再过一轮）

每一个开发阶段都有对应的测试阶段

测试过程

fault反思

fault 是由修复定义的是由测试定义的

fault的个数确定一个还是两个什么时候是BUG 什么时候不是 (从failed 到 passed 就是Bug 一直是failed就不是Bug)

第二章单元测试

单元测试：对单个模块的测试

集成测试：测试模块之间的接口交互功能

系统测试：把系统作为一个整体来进行测试

接受测试：由客户根据用户需求验证系统，无需正式的测试用例

单元测试的概念

单元测试：软件的基础模块的测试（比如：函数类组件等）

为什么做单元测试？

怎么做单元测试避免写MOCK class

从不依赖于其他类的类开始
基于已经测试过的类的基础上继续测试

JUnit参数化测试（再过一轮）

参数化运行器是一种测试框架或工具提供的功能，用于在单元测试中以不同的参数运行相同的测试代码。

它允许我们定义一组输入参数，并自动化地执行相同的测试代码多次，每次使用不同的参数进行测试。可以减少重复的测试代码编写，提高测试覆盖率，并且可以轻松地执行大量的测试用例。

什么时候用不了参数化测试什么时候能用参数化的测试？

当测试调用的是相同的方法的时候可以抽象成参数化测试，当测试中包含不同的方法调用的时候不能用参数化测试。

第三章白盒测试

掌握覆盖准则（分支主路径基本路径等）出大题注意设计测试用例集要写输入和预期输出

3.1 图论和结构化覆盖

图

V ：有穷非空的顶点的集合

E ：边的集合（E可以为空）

一个单独的顶点是一个图吗？

是的边可以为空

E可以是无限的集合吗？

不可以 V是有限的集合那么V的数量一定的情况下 E的数量是一定的不可能是无限的

有很多初始节点或者有很多终止节点应该怎么办？

路径

路径：顶点的序列其中每一对顶点都是一个边

路径的长度：边的数量

子路径： P中顶点的子序列

测试路径

测试路径：在初始节点开始，终止节点结束的路径

测试路径跟测试用例的关系：一对多一对一一对0都存在

多个测试用例执行一个测试路径
没有测试用例能执行测试路径（例子）

测试和测试路径

规定一条测试只能执行一个测试路径

path(t) : 表示被测试t执行的测试路径

path(T) : 表示被测试集T执行的测试路径集

图覆盖准则

可达分为语法可达和语义可达，

语法可达：图中存在这么一条路径

语义可达：有测试用例能执行路径

覆盖：点在测试路径里边在测试路径里子路径在测试路径里分别是覆盖点覆盖边覆盖子路径

在测试中使用图的准备工作：利用软件的资料构建图的模型；要求测试覆盖某些特定的点边子路径

结构化覆盖（只关心点和边） VS 数据流覆盖 — 后面会有介绍

测试需求TR ：描述测试路径的性质

测试准则C ：定义测试需求的规则

满足：针对C派生出来的测试需求，TR中的每一个tr都有测试集T中的t满足

结构化覆盖

npc(npc：覆盖所有长度为n的可达子路径)中n的不同取值：

n = 0 顶点覆盖（VC）：覆盖所有的可达点

n = 1 边覆盖（EC）：覆盖所有的可达边

n = 2 边对覆盖(EPC)：覆盖所有的可达边对

n = 无穷全路径覆盖覆盖所有的路径

讨论：

针对EC 如果图是只有一个顶点没有边怎么办？为了定义的完整性，认为EC是覆盖所有长度小于等于1的边
针对EPC 如果图中只有一个边怎么办？为了定义的完整性，认为EPC是覆盖所有长度小于等于2的子路径
针对n1pc,如果图中只有n2个边，并且n2 <=n1，怎么办？为了定义的完整性，n1pc表示覆盖所有长度小于等于n1的路径。

蕴含关系

C1蕴含C2 记作C1>=C2 对于任意的测试用例集只要满足C1 就一定能满足C2. n1<=n2 则n1pc <=n2pc 注意：满足C2的测试用例集T2发现的Bug 满足C1的测试用例集T1不一定能发现

写VC EC EPC的测试路径，可以先写出TR 再写Test paths（看看哪些tr没被满足）

控制流图及其覆盖

控制流图

控制流图表示程序执行的流转过程

控制流图中的点：可以是代码行可以是语句块函数模块

边：表示流转跳转

if while do-while for break和continue switch

Soot

基于控制流图的覆盖–语句覆盖（被覆盖的语句➗总语句）

基于控制流图的覆盖–分支覆盖（被覆盖的分支➗总分支每个分支的t f 都要覆盖）

基于控制流图的覆盖–路径覆盖（被覆盖的路径➗所有可能的路径）

语句覆盖和分支覆盖

分支覆盖达到100% 语句覆盖能达到100%吗能分支覆盖严格蕴含语句覆盖

语句覆盖达到100% 分支覆盖能达到100%吗不能 PPT有例子 3.1 P56

分支覆盖和路径覆盖

路径覆盖达到100% 分支覆盖能达到100%吗能路径覆盖严格蕴含分支覆盖

分支覆盖达到100% 路径覆盖能达到100%吗不能 PPT有例子 3.1 P57

总结

路径覆盖蕴含分支覆盖分支覆盖蕴含语句覆盖

基于控制流图覆盖的优点和缺点

优点：

65%的Bug在单元测试中发现
单元测试中基于控制流图的测试占主导
语句覆盖和分支覆盖占据控制流图覆盖的主导

缺点：

100%的覆盖不能保证程序没有Bug，为什么？？

比如如下：

测试路径与测试之间的关系可能是一对多，可能测试用例刚好就不是能发现错误的数据。

测试用例x = 0 y = 1 覆盖率是100% 
int sum(int x, int y){ return x-y; //should be x+y
}

3.2 主路径和基本路径覆盖

图中的循环

如果图中有循环那么有无穷多个路径，对于CPC而言是不适用的

解决循环

主路径或者基本路径

简单路径定义：

从i 到 j 的路径是简单的，如果它满足：除了第一个节点和最后一个节点可能会相同外，每个节点都只出现一次。

主路径定义：

首先是简单路径，然后不是其他简单路径的子路径

主路径覆盖（PPC）

TR（测试需求）包含图中的每个主路径

PPC换成SPC（prime换成simple）可以吗？不可以如果只有一个节点的话（可以什么？？？）

PPC蕴含点覆盖和边覆盖，不蕴含边对覆盖–EPC 列子（112）

往返路径：开始节点和结束节点相同的主路径

简单往返路径覆盖：测试需求对G中所有round-trips中的每一个节点包含至少一条round-trip路径。
完全往返路径覆盖：测试需求包含G中所有可达节点包含所有round-trips路径。
这两个准则省略了不在round trips中的点和边，因而不包括边对、边或者点覆盖。

主路径和对应的测试路径的寻找算法思想是首先找到所有简单路径，之后从中筛选出主路径。

从长度为0的路径开始，对下面两种无法继续扩展的路径给出标记
- 到达终止节点，无出边
- 构成环
按路径长度，从上一路径集合的每一个路径出发进行扩展，直到无法继续
消除所有作为子路径存在的路径

从最长的主路径着手开始选择测试路径，直到满足所有主路径的情况。

Are some prime paths infeasible? 一些主路径的语义不可达：while(false)
怎么样产生测试用例来覆盖所有主路径？
1. 符号执行：路径求解，将路径变为推理器，逆向推出数据。
往返路径：在主路径的基础上，只关注循环体。这个里面的主路径改为简单路径可不可以？不可以对于简单路径来说还包含了只有一个节点的情况而主路径不包含只有一个节点的情况

基本路径覆盖（重要）

介于分支覆盖和全路径覆盖之间的一种方法

把独立路径弄出来独立路径是其他所有的路径都覆盖不了的

坑：（公式要求的是）单进单出！！！！！！

矩阵的秩等于图的圈复杂度（边的数目减去节点数+2）

写控制流图
求圈复杂度
选择一组基本路径（独立路径）
为基本路径产生测试用例

数据流覆盖和事件流覆盖

数据流覆盖

对数据的操作有：**def(定义包括变量的初始化或者声明) 和 use（使用对数据的访问），**对于被定义的变量，至少要访问一次

一些概念：

def(n)或者def(e)：在节点n上被定义的节点，在边e上被定义的节点
use(n)或者use(e)：在节点e上被访问的节点，在边e上被访问的节点

DU配对：定义访问对，在i节点定义在j节点访问

定义清晰：目的是为了保证数据不会在别的地方重新写入，保证前面定义的值一定是后面访问的值。

可达： i到j存在定义清晰的路径就是i可达j

一定要掌握下图

事件流图

变异测试

考概念理解 比如什么时候可以用变异测试怎么用变异测试？？？

满足以下两个假设就可以用变异测试：

**有能力程序员假设：****该被测模块是由一位有能力的程序员或设计人员编写的。**因此，如果该模块存在错误，它与正确的模块相比，最多也只存在几个小的缺陷。
**耦合效应：**能发现简单错误的测试集，也能发现复杂错误

怎么用变异测试？

被测程序（进行常规测试，确保它基本没有错误有的话就要尽可能修复Bug） ➜ 生成变异体 ➜ 运行测试 ➜ 杀死变异体(变异体被测试用例识别) ➜ 检查是否有存活变异体 ➜ 有则补充测试 ➜ 无则测试完成

什么是变异测试？

通过创建程序的多个版本（称为变异体）来引入fault。每个变异体包含一个单一的fault。测试用例被应用于原始程序和变异程序，目标是使变异程序失败，从而证明测试用例的有效性。

变异测试是一种通过向程序中插入fault来检查测试是否能发现这些fault，从而验证或否定测试有效性的方法。

变异测试是一种专注于衡量测试用例充分性的测试技术。

变异测试应与传统测试技术结合使用，而不是替代它们。

变异程序

变异测试涉及创建一组被测试程序的变异体。

每个变异体相较于原始程序仅包含一个变异。

变异是对程序语句进行的单个语法修改。

变异算子的种类

逻辑覆盖

概念理解+简单应用 CC DC关系是否包含互不柏寒给出理由（分析题）

语句覆盖:执行语句是否被覆盖

判定覆盖： If的true和false

条件覆盖 : 每一个条件的true 和 false

判定条件覆盖：判定覆盖和条件覆盖的结合

条件组合覆盖：每一个条件true和flase的组合，比如一共有5个条件，那么共有2^5种条件组合

包含关系：

判定覆盖包含语句覆盖；

判定覆盖和条件覆盖互不包含（可以举个例子）

判定条件覆盖包含判定覆盖包含条件覆盖

条件组合覆盖包含语句覆盖包含判定覆盖包含条件覆盖

MC/DC（修正判定条件覆盖）：每一个条件a 出现a为T 结果为T a为F 结果为F

**什么时候MCDC做不到？**两个条件互斥的时候用“与”连接
MC/DC理论上是覆盖的但实际上没有覆盖是什么情况？（逻辑连接符“与”前面为假的时候后面的条件不判断直接整个判定为假怎么解决–拆分成两个if）

Please construct a decision, in which a condition has no independent outcome. 不能满足MCC 互斥的就不能满足MCC

这些覆盖的复杂度：

DC 2

CC 2*n

MC/DC 2*n

MCC 2^n

第五章黑盒测试

5.1 随机测试

随机测试：测试用例是随机产生的

随机测试的问题：

输入域的定义
随即机制–随机数的产生（一般都是伪随机）

希望随机测试用多样性，因此产生了自适应随机测试，使用ART算法

ART算法流程

随机产生一个测试输入运行输入把测试输入加入到测试集合T中
while(不满足停止准则){
产生k个输入作为候选点
计算这几个候选点到T的距离（以最小的距离为准）
选择具体T最远的候选点作为测试用例，运行并加入到T中

ART什么时候失效怎么改进？？？？？？

块状区域带状区域都会失效

ART算法的问题：

距离（距离的计算方式）
开销（每个点都要计算距离开销很大）
**维度灾难当维度很高的时候距离计算变得无意义；随机性降低，**在高维空间中，均匀分布的测试点仍然可能无法有效覆盖故障区域。

分别的解决办法：

改进计算距离的方法
降低开销（网格搜索）
降低维度（PCA降维）

5.2 等价类划分边界值分析组合测试

等价类划分(重要)

考分析题或者应用题

等价类划分法分 @为有效等价类和无效等价类，

怎么划分等价类？

同一等价类中的数据发现缺陷的能力一样，

基于接口的和基于功能的区别？？？？

基于接口的：直接从单个输入参数中提取特征；非常简单；某些情况下可以实现部分自动化

**基于功能的：从被测程序的行为的角度来提取特征；有些困难，工作量更大；**可能产生更有效的测试，或数量更少但同样有效的测试。

默认是基于功能的等价类划分，考试的时候不要忘记无效等价类的情况（比如上面的构不成三角形不要忘记预期输出）针对输入进行划分找出一个数据代表这个等价类

比如一个三角形可以划分为 等边但不等腰等腰普通构不成三角形

边界值分析（重要）

边界值分析的要求：边界值分析的要求Min-（非法）、Min（边界）、Min+（合法）、Nom（合法）、Max-（合法）、Max（边界）、Max+（非法）最后加个笛卡尔乘积

对日期进行分析

组合测试

之前的黑盒测试技术（随机测试等价类划分边界值分析没有考虑输入变量之间的关系）决策表（考虑了输入和输出的关系但提取关系比较复杂表达关系也比较复杂）

但如果用完全组合测试开销很大

因此我们采用两两组合测试或者t个组合测试

组合测试分为固定力度组合测试和可变力度组合测试，固定力度就是两两组合测试或者t个组合测试

组合测试的问题：1. 没有考虑输入变量之间的特殊情况 2. 是完全组合测试的一种抽样抽样的准则需要选择

t = 3要会 + 缺省 + 约束

二元组合测试 — 先把TR列出来每次写出一个测试用例就划掉覆盖到的TR 直到所有的TR被覆盖

5.3 缺省约束决策表

缺省值：测试用例里面没有出现的一定要加上去

约束：测试用例里面出现了约束一定要删掉

决策表（分析题）

会画会写分析题描述功能写决策表条件动作不合并没问题

决策表的生成（考点）—构造决策表的5个步骤：

（1） 确定规则的个数

有n个条件的决策表有2^n个规则（每个条件取真、假值）

（2） 列出所有的****条件桩和动作桩

（3） 填入****条件项

（4） 填入动作项，得到初始决策表

（5） **简化决策表，合并相似规则（**考试可以不合并）

若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并

合并后的条件项用符号“-”表示，说明执行的动作与该条件的取值无关，称为无关条件

第六章测试前言专题

6.2 蜕变测试测试用例简约集

蜕变测试：设计蜕变关系（分析题）设计测试用例

测试用例集简约：

冗余的数据有用吗？有用做数据强化

6.3 测试排序缺陷定位

计算APFD

缺陷定位的概念：

第七章集成与系统验收测试移动测试(全是概念+理解死记硬背还要再加点)

集成测试的模式，二者的优缺点？

渐增式测试：针对待测模块，将已经测试完成的模块和这个待测模块结合进行测试，测试完成后，针对下一个待测模块，同样和已经测试好的模块结合进行测试。
- 优点：
  - 问题早发现：每次集成后都进行测试，可以及早发现问题
  - 容易定位bug : 由于每次都只增加一个模块进行测试，更容易找到缺陷的位置
  - 测试风险低：每次集成较少的模块，系统复杂性低，出现的风险较小，容易控制。
- 缺点：
  - 测试周期长，每增加一个模块就要进行一次测试
  - 需要处理各个模块之间的依赖关系，工作量大
  - 测试资源需求高：需要频繁的测试和调试，可能会占用大量的测试资源
非渐增式测试：把所有的模块单独测试完成后，按照设计要求将这些模块结合成所要的程序。（适合简单的系统或者每个模块都没有问题）
- 优点：
  - 测试周期短，只需要进行一次集成测试
- 缺点：
  - 问题发现晚，再最后的集成测试阶段才会发现模块之间的兼容性问题等
  - 难以找到bug的位置

什么时候用宽度优先什么时候用深度优先（使用场景）

功能单一但实现功能的时候使用了很多的模块，使用深度优先；
功能很多，实现的时候使用的模块较少，使用宽度优先。

什么时候用自顶向下什么时候用自底向上？？？？？？？
什么是桩模块什么是驱动模块

驱动模块：用来模拟待测模块的上级模块，它用于接收测试数据，将数据传送给待测模块，调用待测模块并打印出相应的结果。
桩模块：模拟待测模块在集成测试中所调用的模块，一般桩模块只进行少量数据的处理，比如可以打印输入与返回，用于测试待测模块和下级模块的接口。

并发用户数和同时在线数的区别？？？？？？？？
什么是压力测试什么是容量测试二者的目的是什么区别是什么

压力测试（极限什么时候崩溃）：模拟程序的软硬件环境以及用户使用过程中的系统负荷，长时间或超负荷地使用软件，以测试软件的性能稳定性和可靠性，本质上来说，测试者是想要破坏程序。
容量测试（容量的上限）：目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。还将确定测试对象在给定时间内能够持续处理的最大负载或工作量

验收测试与前面的测试最大的不同？有客户的参与
兼容性测试中的向前兼容和先后兼容的区别是什么，用例子说明？

向前兼容是现在的软件可以打开以前创建的word文档
向后兼容：以前的软件可以打开现在的软件创建的word文档

集成测试前的准备：人员安排测试内容测试计划集成模式测试方法
大棒集成法：先对每一个子模块进行测试，然后将这些模块集成起来进行测试，适合规模较小的系统
三明治集成法：三明治集成就是把系统划分为三层，中间一层为目标层，测试的时候，对目标层上面的一层使用自顶向下的集成策略，对目标层下面的一层使用自底向上的集成策略，最后测试在目标层会合。优点—它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。采用这种方法的主要缺点是：在真正集成之前每一个独立的模块没有完全测试过。
改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底。
持续集成：软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的进行集成，有助于尽早发现Bug，避免集成中大量Bug涌现。而且容易定位Bug、修正Bug，最终提高软件开发的质量与效率
功能测试的定义：根据产品特性和设计需求，验证一个产品的特性和行为是否满足设计需求
功能测试常用步骤：
- 根据需求来细分功能点
- 根据功能点派生测试需求
- 根据测试需求设计功能测试用例
- 逐项执行功能测试用例验证产品
测试类型：
- 正确性：产品功能是否与需求和设计文档一致
- 可靠性：用户交互是否引发软件崩溃和其它异常
- 易用性：软件产品完成特定任务的难易程度
回归测试：它涉及在软件发生变更后重新运行之前的测试用例，以确保这些变更没有引入新的错误或影响到软件的其他部分。这种测试的目的是验证修改后的软件仍然保持了预期的功能和性能。
回归测试的目的：
- 所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；
- 不影响软件原有功能的正确性。
回归测试的方法
- 再测试全部用例
- 基于风险选择测试
- 基于操作剖面选择测试
- 再测试修改的部分
非功能测试：
- 性能测试：验证产品的性能在特定负载和环境条件下使用是否满足性能指标，进一步发现系统中存在的性能瓶颈，优化系统。
  - 目的：为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的
  - 性能测试需求：用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）
  - 主要的性能指标：服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间
  - 度量方法：服务端性能采用CPU、内存等使用率来度量；客户端性能通常根据系统处理特定用户请求的响应时间来度量
  - 一些概念：
    - 响应时间：系统对请求作出响应所需要的时间
    - 响应时间划分为：
      - 服务端响应时间是指从请求发出开始到客户端接收到最后一个字节数据所消耗的时间。
      - 客户端响应时间是指客户端收到响应数据后呈现/响应用户所消耗的时间。
    - 并发用户数VS用户在线数
    - 吞吐量：吞吐量是指单位时间内处理的用户请求数量（访问人数/天，页面数/秒，请求数/秒，处理业务数/小时）
    - 性能计数器是描述系统性能的一些数据指标，
  - 性能测试的步骤：
    1. 确定性能测试需求
    2. 根据测试需求，选择测试工具和开发相应的测试脚本
    3. 建立性能测试负载模型，就是确定并发虚拟用户的数量、每次请求的数据量、思考时间、加载方式和持续加载的时间等
    4. 执行性能测试
    5. 结果分析，并提交性能测试报告
- 压力测试：模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。从本质上来说，测试者是想要破坏程序。
- 并发性能测试：并发性能测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发虚拟用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。
- 疲劳强度测试：通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程；疲劳强度测试案例制定的原则是保证系统长期不间断运行的业务量，并且应该尽量去满足该条件。
- 大数据量测试：
  - 独立的数据量测试：针对某些系统存储、传输、统计、查询等业务进行大数据量测试
  - 综合数据量测试：和压力性能测试、负载性能测试、并发性能测试、疲劳性能测试相结合的综合测试方案
- **容量测试：**通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
- 安全性测试：检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。
- 可靠性测试：可靠性（Reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的可靠程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。
  - 成熟性度量可以通过错误发现率DDP（Defect Detection Percentage）来表现。在测试中查找出来的错误越多，实际应用中出错的机会就越小，软件也就越成熟。
  - DDP=测试发现的错误数量/已知的全部错误数量
- 容错性测试：检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面
  - 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
  - 灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。
验收测试：最大的不同—客户的参与
验收测试定义：在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段,也称为交付测试。
1. 前提：系统或软件产品已通过了系统测试的软件系统
2. 测试内容：验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、操作手册等）测试等几个方面的内容
3. 测试步骤：
  1. 制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。
  2. 建立测试环境，设计测试用例，并经过评审。
  3. 准备测试数据，执行测试用例，记录测试结果。
  4. 分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。
    1. 测试项目通过；
    2. 测试项目没有通过，并且不存在变通方法，需要很大的修改；
    3. 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进；
    4. 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。
  5. 提交测试报告
移动应用测试和传统软件测试的区别？