本着共享主义，本人将PPT考点梳理出来，并且已经翻译成中文，供大家参考，欢迎各位指导！
本次考试题型分为选择、判断、简答和大题写测试用例（Final Exam： 70%（闭卷考试））
所以考点既要把握细节，又要掌握大题和理解概念（文章结合PPT用电脑看合适）
软件缺陷的概念
从产品内部看，软件缺陷是产品开发或维护过程中所存在的错误、毛病等各种问题。
从产品外部看，软件缺陷是系统所需要实现的某种功能的失效或者违背。
软件测试的一个重要功能
verification(验证）and validation(确认)
verification：验证我们是不是正确的做了这个产品，也就是产品要符合他的目标
validation：确认我们是不是做了正确的产品，也就是产品是用户真正想要的
软件测试的目的
* 软件测试是为了发现错误而执行程序的过程。
* 一个好的测试能过在第一时间发现程序中存在的错误。
* 一个好的测试是发现了至今尚未发现的错误。
* 减小软件不能正常工作的风险
软件测试的分类
C1:按照测试生成的来源
C2：按照生命周期的阶段
C3：按照测试活动的目的
C4：按被测对象的特征
C5：按测试过程的模型
软件测试V模型
软件测试V模型
软件测试用例
输入以测试系统和预测这些系统的输出，如果系统根据其规范运作。
黑盒测试
等价类划分
分为有效类和无效类，两者不能有重叠的部分
例如：前亚利桑那州境内的一位步枪销售商销售密苏里州制造的步枪机、枪托和枪管。枪机（Lock）卖45美元，枪托（Stock）卖30美元，枪管（Barrel）卖25美元。销售商每月至少要销售一支完整的步枪，且生产限额是大多数销售商在一个月内可销售70个枪机、80个枪托和90个枪管。每访问一个镇子之后，销售商都给密苏里州步枪制造商发出电报，说明在那个镇子中售出的枪机、枪托和枪管数量。到了月末，销售商要发出一封很短的电报，通知－1个枪机被售出。这样步枪制造商就知道当月的销售情况，并计算销售商的佣金如下：销售额不到（含）1000美元的部分为10％，1000（不含）～1800（含）美元的部分为15％，超过1800美元的部分为20％。佣金程序生成月份销售报告，汇总售出的枪机、枪托和枪管总数，销售商的总销售额以及佣金。
有效等价类：
L1＝{Lock：1≤Lock≤70}
L2＝{Lock＝－1}
S1＝{Stock：1 ≤Stock≤80}
B1＝{Barrel ：1 ≤ Barrel ≤90}
无效等价类：
L3＝{Lock ： Lock ＝0 or Lock ﹤－1}
L4＝{Lock ： Lock ﹥70}
S2＝{Stock ： Stock ﹤1}
S3＝{Stock ： Stock ﹥80}
B2＝{Barrel ： Barrel ﹤1}
B3＝{Barrel：Barrel﹥90}
再例如：有一个报表处理系统，要求用户输入处理报表的日期。假如日期限制在2000年1月至2020年12月，即系统只能对该段时期内的报表进行处理。如果用户输入的日期不在这个范围内，则显示“错误信息”。并且此系统规定日期由年月的6位数字组成，前四位代表年，后两位代表月。
要求：
写出日期的等价类划分。
生成测试用例。
等价类划分
生成测试用例
生成测试用例
边缘值分析法
基本原理
如下图取值
边界值法取值
两个变量的情况下
注意：边界值分析法是单一错误原则
举例说明：
三角形问题，输入a、b、c
1 ≤ a ≤ 200
1 ≤ b ≤ 200
1 ≤ c ≤ 200
所以a,b,c的取值是
a = {1，2，100，199，200}
b = {1，2，100，199，200}
c = {1，2，100，199，200}
测试用例如下
边界值分析的测试用例
小节总结
等价类测试的弱形式不如强形式测试全面。
无效值会引起运行错误的时候（实现语言是强类型），则没有必要做健壮形式的测试。
错误条件很重要的时候，健壮测试很重要。
边界值测试是等价类测试的一种补充，两者结合可以加强测试效果。
决策表技术可以解决变量之间依赖的问题。
要进行多次尝试，确认最合适的等价类划分。
正交测试
正交测试http://www.jianshu.com/writer#/notebooks/11085322/notes/10481239
Decision Tables（决策表）
先来感受一波决策表吧（特别注意，结果能合并的一定要合并！！！）
决策表有四个部分
Stub portion、Entry portion、Condition portion、Action portion
决策表四个部分
从问题决策到结果，Y代表条件满足，N代表条件不满足，--代表忽略这个条件
决策表
练习：
某货运站收费标准如下：如果收件地点在本省，则快件每公斤5元，慢件每公斤3元；如果收件地点在省外，则在20公斤以内（含20公斤）快件每公斤7元，慢件每公斤5元，而超过20公斤时，快件每公斤9元，慢件每公斤7元。请用决策表方法解决此问题。
第一步：确定规则的数目。
条件：
（1）收件地在本省？
（2）是快件？
（3）重量不超过20公斤？
根据公式计算2的3次方＝8
所以应有8条规则。
第二步：列出所有的条件桩和行动桩。
第三步：填入条件条目
第四步：填入行动条目
未简化的决策表
第五步：化简决策表（一定要合并简化）
简化的决策表
Cause-Effect Graphing （因果图）
因果图法产生的背景
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
因果图概念介绍
因果图（Cause-EffectGraphing）提供了一个把规格转化为判定表的系统化方法，从该图中可以产生测试数据。其中原因是表示输入条件，结果是对输入执行的一系列计算后得到的输出。因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
因果图中基本符号介绍（这里可以看PPT，不全部列出）
因果图分析步骤
第一步，找出Cause（原因）
Cause（原因）
c1— the first character is #
c2 —the first character is *
c3 —the second character is number
第二步，找出Effect（结果）
e1— give the information N
e2— modify the document
e3— give the information M
第三步，分析出中间节点
然后画出因果图，如图
再举个例子
某公司对客户有一定的折扣政策，公司软件的一个模块的需求说明书中描述“……当交易额小于等于5万元时折扣为0，当交易额大于5万元时才有折扣，如果交易的客户在三个月内无欠款，则折扣为15%；如果交易用户在三个月内有欠款，若该用户是三年以上的老客户，则折扣为10%；若该客户不是三年以上的老客户，则折扣为5%。”
原因（对立的就不要再写了，比如写了是小于五万就不用写大于等于五万了）：
C1：交易额大于5万元
C2：三个月无欠款
C3：三年以上老客户
结果（注意对立的就不要再写了）：
E1：无折扣
E2：折扣=5%
E3：折扣=10%
E4：折扣=15%
因果图，从这个图中你就能找出导出上边说的四种结果的逻辑
白盒测试（White-box testing）
白盒测试也叫structural testing, clear box testing, and glass box testing.
透明的看得见结构
白盒测试分为静态测试和动态测试
白盒静态测试：Code inspection, Static structure analysis, Static quality metric method
白盒动态测试：主要基于覆盖，包括logic coverage, loop coverage, basis path coverage, etc.
白盒测试主要应用于单元测试
we can’t use exhaustive（详尽的） testing
动态测试之逻辑覆盖
白盒测试用例设计的一个很重要的评估标准就是对代码的覆盖度。一说到覆盖，大家都感觉非常熟悉，但是常见的覆盖都有哪些？各自有什么优缺点？在白盒测试的用例设计中我们应该如何自如地运用呢？为大家总结了一下几种常见的覆盖以及各自的优缺点。
白盒测试中常见的覆盖有六种：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。下面我们就分别看看这几种不同的覆盖究竟是什么鬼。
一、语句覆盖（Statement Coverage）
语句覆盖，顾名思义就是针对代码语句的嘛。它的含义是我们设计出来的测试用例要保证程序中的每一个语句至少被执行一次。通常语句覆盖被认为是“最弱的覆盖”，原因是它仅仅考虑对代码中的执行语句进行覆盖而没有考虑各种条件和分支，因此在实际运用中语句覆盖很难发现代码中的问题。举个非常简单的例子：
public int foo(int a,int b)
{
return a/b;
}
这是一个求两数之商的函数。如果我们设计如下的测试用例：
TestCase: a = 2, b = 1
这时候我们会发现，该函数的代码覆盖率达到了100%，并且设计的case可以顺利通过测试。但是显然该函数有一个很明显的bug：当 b=0 时，会抛出异常。
再来看这个例子：
流程图1
主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
用例设计：（如果此时将A路径上的语句1—〉T去掉，那么用例如下）
语句覆盖测试用例
优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。在本例中去掉了语句1—〉T去掉，那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支，那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行，而往往这种错误会经常出现。再如，在Do-While结构中，语句覆盖执行其中某一个条件分支。那么显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。
二、判定覆盖（Decision Coverage）
判定覆盖也被成为分支覆盖(Branch Coverage)，也就是说设计的测试用例要保证让被测试程序中的每一个分支都至少执行一次。举个例子,有如下流程图：
流程图2
针对该图我们想要做到判定覆盖，可以设计如下case：
TestCase1: a=1, b=1 (路径：ab)
TestCase2: a=-1, b=-1 (路径：acd)
TestCase3: a=2, b=-1 (路径：ace)
判定覆盖比语句覆盖强一些，能发现一些语句覆盖无法发现的问题。但是往往一些判定条件都是由多个逻辑条件组合而成的，进行分支判断时相当于对整个组合的最终结果进行判断，这样就会忽略每个条件的取值情况，导致遗漏部分测试路径。
同样上边流程图1例子也一样
用例设计
用例设计
优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
缺点：往往大部分的判定语句是由多个逻辑条件组合（也就是可能if(a==b&&c==d)这种的逻辑组合）而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
三、条件覆盖（Condition Coverage）
条件覆盖于分支覆盖不同，条件覆盖要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值，即每个条件至少有一次真值、有一次假值。
仍然以上面流程图2作为例子来说明。上图中涉及到的条件一共有4个：
a>0, a<0, b>0, b<0
为了达到条件覆盖的目的，我们设计的用例需要在 a 点有：
a>0, a≤0, b>0, b≤0，
这些情况出现，并且在 c 点有：
a<0, a≥0, b<0, b≥0
这些情况出现。现在可以设计如下用例：
TestCase1: a=1, b=1 (路径：ab)
TestCase1: a=-1, b=-1 (路径：acd)
TestCase1: a=-1, b=0 (路径：ace)
TestCase1: a=1, b=-1 (路径：ace)
通常而言条件覆盖比判定覆盖强，因为条件覆盖使得判定中的每一个条件都取到了不同的结果，这一点判定覆盖则无法保证。但条件覆盖也有缺陷，因为它只能保证每个条件都取到了不同结果，但没有考虑到判定结果，因此有时候条件覆盖并不能保证判定覆盖。
优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。
缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
四、判定条件覆盖（Decision/Condition Coverage）
以流程图1为例
主要特点：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
测试用例
优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。
缺点：判定/条件覆盖准则的缺点是未考虑条件的组合情况。
五、组合覆盖（Branch Condition Combination Coverage）
组合覆盖也叫做条件组合覆盖。意思是说我们设计的测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。显然，满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。
主要特点：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
针对前文提到的流程图2，做条件组合覆盖时我们可以设计如下用例：
TestCase1: a=1, b=1 (路径：ab)
TestCase1: a=-1, b=-1 (路径：acd)
TestCase1: a=-1, b=0 (路径：ace)
TestCase1: a=1, b=-1 (路径：ace)
针对流程图1
测试用例
优点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。
缺点：线性地增加了测试用例的数量。
六、路径覆盖
路径覆盖，意思是说我们设计的测试用例可以覆盖程序中所有可能的执行路径。这种覆盖方法可以对程序进行彻底的测试用例覆盖，比前面讲的五种方法覆盖度都要高。那么这种方法是不是就一定最好呢？当然不能讲得这么绝对，它的缺点也是显而易见的：由于需要对所有可能的路径全部进行覆盖，那么我们需要设计数量非常巨大的而且较为复杂的测试用例，用例数量将呈现指数级的增长。所以理论上来讲路径覆盖是最彻底的测试用例覆盖，但实际上很多时候路径覆盖的可操作性不强。
针对流程图1
测试用例
优点：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。
缺点：由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的
总结
以上简单描述了几种不用的逻辑覆盖方法的原则和优劣。在实际的操作中，要正确使用白盒测试的代码覆盖方法，就要从代码分析和代码调研入手，根据调研的结果，可以选择上述方法中的某一种，或者好几种方法的结合，设计出高效的测试用例，尽可能全面地覆盖到代码中的每一个逻辑路径。
控制流程图和圈复杂度
常见控制流图
控制流图
程序
将上诉程序转化成控制流图
控制流程图
圈复杂度=判定节点数+1
练习1：
计算下图的圈复杂度
标识它的独立路径
独立路径是指程序中至少引进一个新的处理语句集合，采用流图的术语，即独立路径必须至少包含一条在定义路径之前不曾用到的边。
独立路径数=判定节点数（4）+1= 5
独立路径数= e – n + 1 = 11 – 7 + 1 = 5
独立路径：
ABCFG
ABDFG
ABEFG
ABCDFG
ABEDFGABDFG
再比如
控制流程图
独立路径
路径1：1-11
路径2：1-2-3-4-5-10-1-11
路径3：1-2-3-6-8-9-10-11
路径4：1-2-3-6-7-9-10-1-11
V=3个判定节点+1=4（圈复杂度）
由此为了覆盖所有程序语句，必须设计至少4个测试用例使程序运行于这4条路径。
循环测试
路径覆盖法是一种将程序中循环结构简化成选择结构的测试方法。
循环简化的目的是限制循环次数，无论循环的形式和循环体实际执行的次数，简化后的循环测试只考虑循环一次或者零次两种情况。
在这种情况下，循环与判定分支的效果是一样的，即循环要么执行，要么跳过。
采用较复杂的循环测试策略测试循环，可采用下面测试集：
跳过整个循环；
只循环一次；
只循环两次；
循环m次，m
数据流测试...
突变测试（Mutation Testing）
突变测试(mutation testing) , 或称作突变分析、程序突变，它是用于衡量软件测试的质量。突变测试通常对程序的源代码或者目标代码做小的改动，并把截然不同的错误行为（或者怪异行为）作为预期。如果测试代码没有觉察到这种小改动带来的错误，就说明这个测试是有问题的。
突变测试目的：Help testers design high quality tests
Evaluate the quality of existing tests
突变测试范围
unit level、integration level、specification level
下面用一个例子来解释什么是变异测试，考虑以下代码片段：
if(a && b) c = 1;
else c = 0;
条件运算符如果用||来替换&&，就会产生以下变异：
if(a || b) c = 1;
else c = 0;
为了杀死这个突变，需要满足以下条件：
（1）测试数据必须对突变和原始程序引起的不同状态覆盖。如：a=1,b=0可以达到目的。
（2）c的值应该传播到程序输出，并被测试检查。
弱突变覆盖需满足（1），强突变覆盖需满足（1）（2）。
1 变异测试理论
1.1 两个基本假设
变异测试旨在找出有效的测试用例，发现程序中真正的错误。在一个工程中，潜在BUG的数量是巨大的，通过生成突变体来全面覆盖所有的错误是不可能的。所以，传统的变异测试旨在寻找这些错误的子集，能尽量充分地近似描述这些BUG。这个理论基于两条假设：Competent
Programmer Hypothesis(CPH) 和 Coupling Effect(CE)。
CPH是指：假设编程人员是有能力的，他们尽力去更好地开发程序，达到正确可行的结果，而不是搞破坏。它关注的是程序员的行为和意图。而CE(耦合效应)更加关注在变异测试中错误的类别。一个简单的错误产生往往是由于一个单一的变异（例如句法错误），而一个庞大复杂的错误往往是由于多出变异所导致。复杂变异体往往是由诸多简单变异体组合而成。
变异测试流程
在变异测试中，对于被测程序p，设定一个测试用例集合T。首先根据被测程序特征设定一系列变异算子；随后通过在原有程序p上，执行变异算子生成大量变异体；接着从大量变异体中识别出等价变异体；然后在剩余的非等价变异体上执行测试用例集T中的测试用例，若可以检测出所有非等价变异体，则变异测试分析结束，否则对未检测出的变异体，需要额外设计新的测试用例，并添加到测试用例集T中。
定义 1（变异算子）
在符合语法规则前提下， 变异算子定义了从原有程序生成差别极小程序（即变异体）
的转换规则。下表给出了一个典型的变异算子， 该变异算子将“＋” 操作符变异为 “-” 操作符。选择被测程序 p 中的条件表达式 a + b
> c 执行该变异算子， 将得到条件表达式 a - b > c ， 并生成变异体 p′ 。
定义 2（一阶变异体）
在原有程序p上执行单一变异算子并形成变异体p′ ，则称p′为p的一阶变异体。
定义3（高阶变异体）
在原有程序 p 上依次执行多次变异算子并形成变异体 p′ ，则称 p′ 为 p 的高阶变异体。若在 p 上依次执行 k 次变异算子并形成变异体 p′ ， 则称 p′ 为 p 的 k 阶变异体。
定义 4（可杀除变异体）
若存在测试用例t，在变异体p′ 和原有程序p上的执行结果不一致， 则称该变异体p′ 相对于测试用例集T是可杀除变异体。
定义 5（可存活变异体）
若不存在任何测试用例t， 在变异体p′ 和原有程序p上的执行结果不一致， 则称该变异体p′ 相对于测试用例集T是可存活变异体。一部分可存活变异体通过设计新的测试用例可以转化成可杀除变异体，
剩余的可存活变异体则可能是等价变异体。本文对等价变异体定义如下。
定义 6（等价变异体）
若变异体p′ 与原有程序p在语法上存在差异， 但在语义上与p保持一致， 则称p′ 是p的等价变异体。
等价变异体
单元测试（Unit Testing）
单元测试是最小的测试部分，测试模块是独立于其他模块的，一般情况下，被测单元能够实现一个特定的功能，并与其他单元有明确的接口定义，这样才可以与其他单元隔离开来。
In Java, a unit is a class or a class method.
In C, a unit is a function or sub processes.
目标：确保模块被正确的编码
依据：系统详细的规格说明
过程：经过设计、脚本开发、执行、调试和分析结果一个过程
执行者：由程序开发人员和测试人员共同完成
方法：以白盒测试方法为主，辅以黑盒测试方法
如何进行评估：通过所有单元测试用例，代码没有严重缺陷
单元测试过程
1、在详细设计阶段完成单元测试计划
2、建立单元测试环境，完成测试设计和开发
3、执行单元测试用例，并且详细记录测试结果
4、判定单元测试是否通过
5、提交单元测试报告
单元测试过程
单元测试优点
1、单独进行，一起进行，降低软件质量成本，缩短开发周期；
2、便于跟踪错误；
3、集成后错误会放大，集成后复杂性高，很难发现问题；
4、无需而外的设备和人员。
单元测试分为静态测试和动态测试
静态测试
代码评审：代码走查和正式会议审查。
代码走查：代码互查应用最多，代码走查是相对比较正式的评审过程，项目组部分成员通过阅读代码，向其他成员提出问题并对有关技术、风格、可能错误是否违背开发标准和规范等进行评论。
正式会议审查：是一种正式的检查和评估方法，最早由IBM提出，经实践证明，有一种有效的检查办法，从而得到软件工程界的普遍认同。它使用逐步检查源代码中有无逻辑或语法错误的办法来检验故障。
集成测试（Integration Testing）（集成测试、组装测试、联合测试、子系统测试、部件测试）
优点：早点发现错误，早点修正错误，早点获得测试反馈，调度修正错误灵活
分为增量式测试和非增量式测试
测试模式
Big bang（大爆炸） integration
优点：完成速度快、能够并行
缺点：错误发生时很难找出他的位置和改变以及很多问题得在系统测试才能发现
适用范围：Existing system with only minor modifications
Small systems with adequate unit testing
System made from certified high quality reusable components
Top-down （自顶向下）integration
分为广度和深度集成测试
Advantage
Early show main points of control and judgments.
Use depth-first assembly, and a complete software function can be firstly implemented and validated.
Only one driver module is needed at most.
Support fault isolation.
Disadvantage
The costs of the development and the maintenance of stubs are both higher.
Bottom level components demand can not be predicted may lead to many amendments to the top level components.
Bottom-up （自底向上）integration
Advantage
Allow conducting early certification for bottom modules, any leaf node is ready for integration testing can be tested.
Reduce workload of stub development
Support fault isolation
Disadvantage
Driver module development huge workload comparison.
Senior validation was deferred until the end, design error can not be found in time.
Bottom abnormal hard cover.
Sandwich（三明治） integration
Advantage
Combine the advantage of top-down strategy and bottom-up strategy.
Disadvantage
The testing of middle level is insufficient before integration testing.
Scope
It is used by the majority of software development projects.
Layers（分层） integration
High-frequency （高频）integration
Event-based（基于事件） integration
System testing（系统测试）
目的:测试可安装性、可用性、兼容性、可维护性等等
Performance Testing(性能测试)
性能是量度系统或组件在一定约束条件下，是否达到功能设计的指标：如响应速度，计算的精度，内存利用率。
性能是系统外部的质量属性基于用户的需求和用户的系统操作性的看法。
同时性能特别应用于对实时系统的评价当中,就是它的行为在指定的期限内完成正确的操作。
评估指标为时间效率，空间效率，I∕O性能，数据库性能，内存性能，初始化∕退出时间和资源利用率延时，事务处理时间，最大事务处理时间，事务操作时间，数据库性能，最大消耗的内存量，高峰内存时间，资源消耗。
下图描述了web应用的页面响应时间的分解。
页面响应时间分解为网络传输时间（N1+N2+N3+N4）和应用延迟时间（A1+A2+A3），
而应用延迟时间又可分为数据库延迟时间（A2）和应用服务器延迟时间（A1+A3）。
延迟：一个指令控制器发出数据请求的一瞬间和数据传送的一瞬间之间的时间间隔;是请求和完成操作之间拖延的时间差。
事务处理时间：是指完成一项事务所需要的运行时间，用于评价事务处理效率。通常，事务处理的时间越短，则效率越高。
并发用户数，一般分两种情况：
严格意义的并发，即所有用户在同一时间做同一件事情或者操作。
广义范围的并发，多个用户对系统发出了请求或进行了操作，但这些操作可以是相同的，也可以是不同的。
吞吐量：是指在一次性能测试过程中网络上传输数据量的总和。
一般来说，吞吐量用请求数/秒或页面数/秒来衡量。
吞吐量指标有如下两个作用：
1、协助设计性能测试场景，衡量性能测试场景是否达到了预期的设计目标。
在设计性能测试场景时，根据估算吞吐量数据测试场景事物发生频率。
2、协助分析性能测试瓶颈。
性能测试比较关注业务并发用户数，从业务的角度设置多少并发数合理。
下面给出估算并发用户数的公式：C=nL／T
C —平均的并发用户数
n —登录会话的数量
L —登录会话的平均长度
T —考察的时间段长度
例题：
一个软件系统每天约有400个用户访问。用户在一天之内有8小时内使用该系统，从登录到退出的平均时间为4小时，请计算该系统的并发用户数和并发用户的峰值各是多少？
分析：根据公式C=400×4／8=200
并发用户数的峰值
负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（不断增加模拟用户数量）或其他加载方式来观察不同负载下系统响应时间和数据吞吐量，系统资源占有率（cpu和内存）等性能指标，以检验系统的行为和特性，发现系统可能存在的性能瓶颈、内存泄露和不能实现同步等问题。
高低突变加载：某个时间用户数量很大，突然降到很低，过一段时间，又突然加到很高，反复几次。借助这种负载方式的测试，容易发现资源的释放和内存泄漏的问题。
随机加载方式：由随机算法自动生成某个数量范围内变化的、动态的负载，这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬间高峰期，但可以模拟系统长时间的运行过程的状态。
压力测试用于判定应用处理大量数据的能力。
压力测试可以成功的测试服务器满负载的情况。
除了在服务器上增加运行的应用结合客户端测试是一种额外的形式的压力测试。
性能测试过程：计划，记录，修改，执行，分析
网友评论