软件测试知识点总结

软件测试知识点总结

第一次课10.7软件测试概述

一 软件测试定义:使用人工或者自动的手段来运行或测定它是

否满足规定的需求,或弄预期结果与实际结果之间的差别。

二 软件测试的分类

1.按照开发阶段划分

a) 单元测试:模块测试,检查每个程序单元嫩否正确实现详细

设计说明中的模块功能等。

b) 集成测试:组装测试,将所有的程序模块进行有序、递增的

测试,检验程序单元或部件的接口关系

c) 系统测试:检查完整的程序系统能否和系统(包括硬件、外

设和网络、系统软件、支持平台等)正确配臵、连接,并满

足用户需求。

d) 确认测试:证实软件是否满足特定于其用途的需求,是否满

足软件需求说明书的规定。

e) 验收测试:按项目任务或合同,供需双方签订的验收依据文

档进行的对整个系统的测试与评审,决定是否接受或拒收系

统。

2.按照测试技术划分

白盒测试:通过对程序内部结构的分析、检测来寻找问题。检

查是否所有的结构及逻辑都是正确的,检查软件内部动作是否

按照设计说明的规定正常进行。--结构测试

黑盒测试:通过软件的外部表现来发现错误,是在程序界面处

进行测试,只是检查是否按照需求规格说明书的规定正常实

现。

灰盒测试:介于白盒测试与黑盒测试之间的测试。

3 按照测试实施组织划分:开发方测 用户测试 第三方测试

4 是否使备测软件运行:静态测试 动态测试。

课后作业:1.软件测试与调试的区别?

(1)测试是为了发现软件中存在的错误;调试是为证明软件开

发的正确性。

(2)测试以已知条件开始,使用预先定义的程序,且有预知的

结果,不可预见的仅是程序是否通过测试;调试一般是以不可知

的内部条件开始,除统计性调试外,结果是不可预见的。

(3)测试是有计划的,需要进行测试设计;调试是不受时间约

束的。

(4)测试经历发现错误、改正错误、重新测试的过程;调试是

一个推理过程。

(5) 测试的执行是有规程的;调试的执行往往要求开发人员进

行必要推理以至知觉的"飞跃"。

(6) 测试经常是由独立的测试组在不了解软件设计的条件下完

成的;调试必须由了解详细设计的开发人员完成。

(7) 大多数测试的执行和设计可以由工具支持;调式时,开发

人员能利用的工具主要是调试器。

2.对软件测试的理解?

软件测试就是说要去根据客户的要求完善它.即要把这个

软件还没有符合的或者是和客户要求不一样的,或者是客户要

求还没有完全达到要求的部分找出来。

1.首先要锻炼自己软件测试能力,包括需求的分析能力,提取

能力,逻辑化思想能力,即就是给你一个系统的时候,能够把

整个业务流程很清晰的理出。

2.学习测试理论知识并与你锻炼的能力相结合。

3.想和做。想就是说你看到任何的系统都要有习惯性的思考;

做就是把实际去做练习,然后提取经验。

总结测试用例,测试计划固然重要,但能力和思想一旦到位

了,才能成为一名合格的软件测试工程师。

第二次课10.10软件测试模型

一、软件缺陷:(1)软件未达到产品说明书中已经标明的功能;

(2)软件出现了产品说明书中指明不会出现的错误;

(3)软件未达到产品说明书中虽未指出但应当达到的目标;

(4)软件功能超出了产品说明书中指明的范围;

(5)软件测试人员认为软件难以理解、不易使用,或者最终用户

认为该软件使用效果不良。

二、软件测试模型 H

V模型:, 模型(了解)

V模型的缺陷

1、仅把测试过程作为在需求分析、系统设计及编码之后的一个阶

2、忽视了测试对需求分析,系统设计的验证,一直到后期的验收测

试才被发现。

W模型的概念:增加了软件各开发阶段中应同步进行的验证和确认

(v$v)活动,明确了测试与开发的并行性.

1、测试伴随着整个软件开发周期

2、测试的对象不仅仅是程序,需求、设计和功能同样要测试

3、根据W模型要求,一旦有文档提供,就及时确定测试的条件、

编写测试用例

四. 软件测试的原则

4.1 完全测试的不可能性 4.2 软件测试是有风

险的活动

4.3.测试无法显示潜伏的软件缺陷和故障 4.4. 充分注意测试中

的群集现象

4.5杀虫剂现象 4.6.并非所有的软件缺

陷都要修复

4.7. 80-20 原则 4.8.软件测试必须有预

期结果

4.9. 应当把“尽早地和不断地进行软件测试”作为软件测试者的

座右铭

4.10. 程序员应该避免检查自己的程序

4.11 追溯至用户需求 4.12 及时更新测试

第三次课10.14 等价类

1、等价列划分设计方法:是把所有可能的输入数据,即程序的输

入域划分成若干部分(子集),然后从每一个子集中选取少量具有

代表性的数据作为测试用例。

等价类是指某个输入域的子集合。在该子集合中各个输入数据对于

揭露程序中错误都是等效的。并合理地假定:测试某等价类的代表

值就等于对这一类其他值的测试。

有效等价类:对于程序的规格说明来说是合理的、有意义的输入数

据构成的集合

无效等价类:对软件规格说明而言,是无意义的、不合理的输入数

据所构成的集合

等价类对于测试有两个重要的意义:完备性 无冗余性

2、等价类的划分原则

(1)按照区间划分: 一个有效等价类和两个无效等价类。

(2)按照数值划分: n 个有效等价类和一个无效等价类

(3)按照数值集合划分 一个有效等价类和一个无效等价类

(4)按照限制条件或规则划分:可确定一个有效等价类和若干个

无效等价类

(5)细分等价类

3.等价类划分法的步骤

(1)确定等价类

(2)建立等价类表,列出所有划分出的等价类

(3)从划分出的等价类中按以下的3个原则设计测试用例:

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

B 设计一个新的测试用例,使其尽可能多的覆盖尚未被覆盖的有

效等价类,重复这一步,直到所有的有效等价类都被覆盖为止。

C 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等

价类,重复这一步,直到所有的无效等价类都被覆盖为止。

习题:三角形问题。

4.等价类划分法

(1)弱一般等价类测试

特点: 不考虑无效数据,测试用例使用每个等价类中的一个值

(2)强一般等价类测试

特点:每一个有效等价类要选择至少一个测试用例

(3)弱健壮等价类测试

对于有效输入: 使用每个有效类的一个值

对于无效输入: 测试用例只使用一个无效值,其余值都是有效

(4)强健壮等价类测试

每个有效等价类和无效等价类都至少要选择一个测试用例

第四次课10.17 等价类划分(续)

1.测试用例的定义

(1)测试用例是为特定的目的而设计的一组测试输入、执行条件

和预期的结果。

(2)测试用例是执行的最小实体。

2、特征:(1)最有可能抓住错误的;(2)不是重复的、多余的;

(3)一组相似测试用例中最有效的;(4)既不是太简单,也不是

太复杂。

3、设计测试用例的基本准则

测试用例的代表性 测试结果的可判定性 测试结果的可再现性

4、确定等价类的方法

(1)先考虑输入数据的类型(合法型和非法型)

(2)再考虑数据范围(合法型中的合法区间和非法区间)

(3)最后考虑输出结果,逆向设定输入

5、常见等价类划分测试形式 针对是否对无效数据进行测试,可以将等价类测试分为两种:

1 、标准等价类测试(也称,一般等价类测试)

2、健壮等价类测试

弱健壮(5):A (Anom, Bnom) B (Anom,Bmin-)

C (Anom,Bmax+) D (Amin-,Bnom) E

(Amax+,Bnom)

强健壮(9):(Amin- ,Bmin-) ( Amin- ,Bmin+) (Amin+, Bmax+) (Amax+, Bmin-)

.

第五次课10.21 边界值分析法

1、边界值分析法就是对输入或输出的边界值进行测试

2、特点:具有很强的发现程序错误的能力;测试用例来自等价类

的边界;

3、基本原理:故障往往发生在输入定义域和输出值域的边界上,

而不是在其内部。

2、选取正好等于,

d

试数据

5、标准边界值: min、min+、nom、max-、max 4、方法:1、首先应确定边界情况. 有两个变量x、y的程序的输入域

健壮边界值: min、min+、nom、max-、max min- max+

6、例

7、对于一个含有n个变量的程序,只让其中一个变量取极值,让其余的变量取正常值,被保留的变量依次取min、min+、nom、max-、max值,对每个变量都重复进行。n个变量的程序,边界值分析测试程序会产生4n+1个测试用例。

第六次课10.24 -----决策表方法

1.概述:决策表法是黑盒测试方法中最为严格、最具有逻辑性的测试方法。

2.什么时候使用?

程序输入输出比较多,输入之间、输出之间相互制约的条件比较多时,可以清楚地表达它们之间的各种复杂关系。

3.决策表通常由四部分组

规则

条件桩: 列出问题的所有

条件项:针对条件桩给出

能的取值

动作桩:给出问题规定的可能采取的操作 :

动作项:与条件项紧密相关,指出在条件项的各组取值情况下应采取的动作

规则:项中的每一列是一条规则,每一条规则是一组测试用例。

4.决策表的化简

(1)合并 :如果一个条件项(表中某列中的条件值)和另外一个条件项所产生的动作是相同的,且两个条件项对应的每一行的值只有一个是不同的,则可以将其合并.合并的项除了不同值变成”不关心”条目外,其余不变

(2)包含:如果两个条件项的动作是相同的,对任意条件1的值和条件2中对应的值,如果满足:

A.如果条件1的值是T(F),则条件2中的值也是T(F).

– B.如果条件1的值是-(不关心),则条件2中的值是

T,F,-,称条件1包含条件2,条件2可以撤去.

– 重复A,B就可以得到精简的决策表.

合并 包含

5.构造决策表的步骤:

(1)确定规则的个数 (2)列出所有的条件桩和动作桩

(3)填入输入项 (4)填入动作项,得到初始的决策表 (5)对初始的决策表化简

6决策表测试法的适用范围

(1)if-then-else逻辑突出 (2)输入变量之间存在逻辑关系 (3)涉及输入变量子集的计算 (4)输入和输出之间存在因果关系

第七次课10.28--------因果图方法

1、概述:如果输入之间有关系,测试时必须考虑输入条件的各种组合,考虑适合于描述对于多种条件的组合,相应产生多个动作的形式来设计测试用例,这就需要利用因果图。

因果图方法最终生成的就是判定表。适合于检查程序输入条件的各种组合情况。

2、因果图法的基本思想: 首先从程序规格说明书的描述中,找出因(输入条件)和果(输出结果或者程序状态的改变),然后通过因果图转换为判定表,最后为判定表中的每一列设计一个测试用例. 3.基本符号 原因 结果

通常在因果图中用Ci表示原因,用Ei表示结果,各结点表示状态,可取值“0”或“1”。“0”表示某状态不出现,“1”表示某状态出现。

c1

C2

恒等: c1为1,则e1也为1,否则e1为0. 非: 若c1是1,则e1为0,否则e1是1.

或: 若c1或c2或c3是1,则e1是1,若三者都不为1,则e1为0. 与: 若c1和c2都是1,则e1为1,否则若有其中一个不为1,则e1为0.

4..约束:实际问题中,输入状态之间可能存在某些依赖关系. E约束(异): a,b最多有一个可能为1,不能同时为1. I约束(或): a,b,c中至少有一个必须为1,不能同时为0. O约束(惟一): a和b必须有一个且仅有一个为1

R约束(要求):a是1时,b必须是1,即a为1时,b不能为0 M约束:对输出条件的约束,若结果a为1,则结果b必须为0.

5、因果图生成测试用例的基本步骤

1、找出原因和结果。2、画出因果图。 3、增加约束。 4、把因果图转化为判定表,并化简。

5、把判定表的每一列拿出来作为依据,设计测试用例。 6.例题

(1)原因: C1:第一个字符是A; C2:第一个字符是B;

C3:第二个字符是一个数字字找.结果:

结果: E1:给出信息L; E2:修改文件; E3:给出信息M; (2)因果图. (3)决策表。 (4)设计测试用例

测试用例1: 输入数据:A3 预期输出:修改文件 测试用例2: 输入数据:AM 预期输出:给出信息M 测试用例3: 输入数据:B3 预期输出:修改文件 测试用例4: 输入数据:B* 预期输出:给出信息M 测试用例5: 输入数据:C2 预期输出:给出信息L 测试用例6: 输入数据:CM 预期输出:给出信息LM

7.因果图法的优点:

1.考虑了多个输入之间的相互组合、相互制约关系;

2.能够帮助我们按一定步同时还能为我们指出,程序规格说明描述中存在着什么问题.

第八次课10.31 黑盒复习

第九、十次课11.4 11.7白盒测试

1、 白盒测试概述:白盒测试也称结构测试或逻辑驱动测试。 2、 方法:程序结构分析;逻辑覆盖测试;基本路径测试; 3、 原则:1、保证一个模块中所有独立路径至少被测试一次;

2.所有逻辑值均需测试真(True)和假(False)两

种情况;

3.检查程序的内部数据结构,保证其结构的有效性; 4.在取值上、下边界,即可操作范围内运行所有循环.

5、逻辑覆盖测试:主要是测试覆盖率,以程序内在逻辑结构为基础的测试。

6种:语句覆盖 判断覆盖 条件覆盖 判定-条件覆盖 条件组合覆盖 路径测试.

(1) 语句覆盖:在测试时,首先设计若干个测试用例,然后运

行被测程序,使程序中的每个可执行语句至少执行一次 。 判定:整体 控制。 包括:1、单一条件判定 2、符合条件覆盖

语句覆盖率:已执行的可执行语句占程序中可执行语句总数的百分比

(2) 判定覆盖:设计足够多的测试用例,使程序中的每个判定

至少都获得一次“真值”或“假值”。

(3) 条件覆盖:构造一组测试用例,使得每一判定语句中每个

逻辑条件的可能值至少满足一次。

满足条件覆盖的不一定满足判定覆盖,反之亦然。两者无直接关系。

(4) 判定/条件覆盖:设计足够的测试用例,使得判定中每个

条件的所有可能(真/假)至少出现一次,并且每个判定本身的判定结果(真/假)也至少出现一次

(5) 组合条件覆盖(MCC):设计足够的测试用例,使得每个

判定中条件的各种可能组合都至少出现一次。

满足组合条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和

判定/条件覆盖。

(6) 修正条件判定覆盖(MCDC):需要足够的测试用例来确定各

个条件能够影响到包含的判定的结果,即要求满足两个条件。

第十一次课11.11 测试用例设计-8-基本路径

1、

流图:在程序设计时,为了更加突出控制流的结构,可对程序

流程图进行简化,简化后的图称为控制流图.简化后所涉及的图形符号只有两种, 即节点和控制流线. 节点——标有编号的圆圈

 程序流程图中矩形框所表示的处理  菱形表示的两个甚至多个出口判断  多条流线相交的汇合点 边——由带箭头的弧或线表示

 与程序流程图中的流线一致,表明了控制的顺序  它代表程序中的控制流。  控制流线通常标有名字

常见语句的控制流图

包含条件的节点被称为判断节点(也叫谓词节点),由判断节点发出的边必须终止于某一个节点,由边和节点所限定的范围被称为区域. 2、

(1)环形复杂度(圈复杂度):亦可将该度量用于基本路径

方法,它可以提供程序基本集的独立路径数量和确保所有语句至少执行一次的测试数量上界

(2)独立路径:指程序中至少引入一个新的处理语句集合或一个新条件的程序通路,它必须至少包含一条在本次定义路径之前不曾用过的边.

(3)环形复杂度计算:

1. 流图中区域的数量对应于环形复杂度;(闭合区域数+1) 2. 给定流图G的环形复杂度为V(G),定义为V(G )=E-N+2,E是流图中边的数量,N是流图中节点的数量.

一个简单的流图

3. 给定流图G的环形复杂度V(G),定义为V(G)=P+1,P是流图G中判定节点的数量.

46

3

7

8

41

 流图中有四个区域; 10

2

11

13

 V(G)=10条边-8结点+2=4; 14

 V(G)=3个判定结点+1=4。

(4)图矩阵

图矩阵-即流图的矩阵表示。其维数等于流图的节点数。每列和每行都对应于标识的节点,矩阵元素对应于节点的边。其中横坐标为起点, 纵坐标为终点。

例:若矩阵记为M,则M(4,1)=“d”,边d的方向是节点4到节点1

第十二次课11.14 测试用例设计-9-白盒最后

1、 静态测试不实际运行软件,主要对软件的编程格式、结构等方

面进行评估。可以有人工进行,也可借助软件工具自动进行。 2、 静态测试的方法

(1)代码检查:代码审查 代码走查 桌面检查 同行评分(略)  代码审查:通常由4人组成,其中一人是协调人,一人是程序的编写者,其他人员通常是程序的设计人员以及测试专家。 优点和作用:错误列表、高效、会后修正、增加修改错误清单、较早发现错误。

 代码走查:为测试员的人会带着一些书面的测试用例参加会议

 桌面检查:(1)完全没有约束(2)开发人员测试自己的程序(3)没有展示自己能力,缺乏良好的效应。(效果远远逊于代码审查和代码走查)

3、静态结构分析:主要是以图形的方式表现程序的内部结构。 4、代码质量度量:功能性 可靠性 可用性 |有效性 可维护性 轻便性

第十三次课11.18 单元测试

1、单元测试的重要性

时间方面——节省 测试效果——明显 测试成本——较低 产

品质量——直接 2.1 单元测试的定义

单元测试又称模块测试,是最小单位的测试,其依据是详细设描述,对模块内所有重要的控制路径设计测试用例,以便发现模块内部的错误。

单元测试多采用白盒测试技术 2.2 单元测试的对象

结构化程序,单元测试所说的单元是指函数, 面向对象程序,单元测试的单元一般是指类。 2.4 单元测试的人员:开发人员 3、单元测试的内容

模块接口: 检查进出程序单元的数据流是否正确。 局部数据结构: 必须测试模块内部的数据能否保持完整性。 边界条件测试:主要检查临界数据是否正确处理。 独立路径测试:单元测试中最主要的测试。

出错处理:要求能预见出错的条件,并设臵适当的处理对象,保证

其路径的正确性。

1、 输出的错误信息难以理解。

2、 记录错误与实际遇到的错误不符。

3、 在程序自定义出错处理运行之前系统介入。

4、 异常处理不当。

5、 错误陈述中未能提供做够的定位出错信息。

6、

4.、单元测试的方法

5、单元测试的流程 计划单元测试 设计单元测试 执行单元测试 评估单元测试

(1)驱动模块(Drive) 用来模拟被测试模块的上一级模块,相当于被测模块的主程序。它接收数据,将相关数据传送给被测模块,启动被测模块,并打印出相应的结果。

(2)桩模块(Stub) 用来模拟被测模块工作过程中所调用的模块。它们一般只进行很少的数据处理。

5.3 执行单元测试(1)设臵测试环境(2)将测试环境初始化(3)

执行测试过程。

5.4 评估单元测试(1)测试完备性评估 (2) 代码覆盖率评估

第十四次课11.21 单元测试-JUNIT

常用的断言方法

第十五次课11.25 集成测试

1、集成测试又称组装测试,集成测试是在单元测试的基础上,将所有模块按照设计要求组装成子系统或系统进行的测试活动。

2、集成测试的目的

确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确,所测试的内容包括单元间的接口以及集成后的功能。

3、集成测试的层次

(1)模块内集成测试(2)子系统内集成测试(3)子系统间集

成测试

4、集成测试流程

5、集成测试方法:

1)静态测试 只要指对概要设计的测试。

2)动态测试:以黑盒测试为主,需要了解内部细节时结合白盒测试

6、集成测试策略

 非增量式集成:对所有模块进行个别的单元测试后,按照程序结构图将各模块连接起来,把连接后的程序当作一个整体进行测试。

关键模块的特征:

① 满足某些软件需求;

② 在程序的模块结构中位于较高的层次(高层控制模块); ③ 较复杂、较易发生错误;

④ 有明确定义的性能要求。

 增量式集成:逐次将未曾集成测试的模块和已经集成测试的模块(或子系统)结合成程序包,再将这些模块集成为较大系统,在集成的过程中边连接边测试,以发现连接过程中产生的问题。

方法: 1、自顶向下增量式测试 深度优先 广度优先。

2、 自底向上增量式测试

3、混合增量式测试

7、不同集成测试方法的比较

第十六次课11.28 功能测试

1、 确定功能测试的需求

功能测试的基本目标:从用户需求出发,尽早的发现不满足用户需求,与产品说明书不一致的所有问题。

(1) 程序安装启动正常,有相应的提示框,错误提示。

(2) 每一项功能能正常运行,输出结果正确。

(3) 能处理各种不正常的操作,对异常数据的输入可以进行提

示容错处理等。

(4) 系统的界面清晰美观。

(5) 菜单按钮正常、灵活。

(6) 软件升级后能继续支持旧版的数据,支持各种应用环境。

2、 功能测试的内容:

(1) 界面测试:指系统界面整体布臵的合理性,以及是否能清

晰美观。

(2) 数据测试:能够正确的数据输入,对异常的数据输入有提

示和容错处理。

(3) 操作测试:所有菜单按钮设计符合操作习惯,能对操作有

正确的响应。

(4) 逻辑测试:合理清楚、流畅,不复杂。

(5) 接口测试:与硬件设备的接口 第三软件接口 公共接口。

3、所有测试方法都可以使用:例如等价类、边界值、因果图、决策表、场景。

第十七次课12.2

1、 可用性测试

2、 安全性测试

3、 兼容性测试

4、 指标/协议测试

5、安装 /卸载程序测试

6、软件本地化测试

软件测试知识点总结

第一次课10.7软件测试概述

一 软件测试定义:使用人工或者自动的手段来运行或测定它是

否满足规定的需求,或弄预期结果与实际结果之间的差别。

二 软件测试的分类

1.按照开发阶段划分

a) 单元测试:模块测试,检查每个程序单元嫩否正确实现详细

设计说明中的模块功能等。

b) 集成测试:组装测试,将所有的程序模块进行有序、递增的

测试,检验程序单元或部件的接口关系

c) 系统测试:检查完整的程序系统能否和系统(包括硬件、外

设和网络、系统软件、支持平台等)正确配臵、连接,并满

足用户需求。

d) 确认测试:证实软件是否满足特定于其用途的需求,是否满

足软件需求说明书的规定。

e) 验收测试:按项目任务或合同,供需双方签订的验收依据文

档进行的对整个系统的测试与评审,决定是否接受或拒收系

统。

2.按照测试技术划分

白盒测试:通过对程序内部结构的分析、检测来寻找问题。检

查是否所有的结构及逻辑都是正确的,检查软件内部动作是否

按照设计说明的规定正常进行。--结构测试

黑盒测试:通过软件的外部表现来发现错误,是在程序界面处

进行测试,只是检查是否按照需求规格说明书的规定正常实

现。

灰盒测试:介于白盒测试与黑盒测试之间的测试。

3 按照测试实施组织划分:开发方测 用户测试 第三方测试

4 是否使备测软件运行:静态测试 动态测试。

课后作业:1.软件测试与调试的区别?

(1)测试是为了发现软件中存在的错误;调试是为证明软件开

发的正确性。

(2)测试以已知条件开始,使用预先定义的程序,且有预知的

结果,不可预见的仅是程序是否通过测试;调试一般是以不可知

的内部条件开始,除统计性调试外,结果是不可预见的。

(3)测试是有计划的,需要进行测试设计;调试是不受时间约

束的。

(4)测试经历发现错误、改正错误、重新测试的过程;调试是

一个推理过程。

(5) 测试的执行是有规程的;调试的执行往往要求开发人员进

行必要推理以至知觉的"飞跃"。

(6) 测试经常是由独立的测试组在不了解软件设计的条件下完

成的;调试必须由了解详细设计的开发人员完成。

(7) 大多数测试的执行和设计可以由工具支持;调式时,开发

人员能利用的工具主要是调试器。

2.对软件测试的理解?

软件测试就是说要去根据客户的要求完善它.即要把这个

软件还没有符合的或者是和客户要求不一样的,或者是客户要

求还没有完全达到要求的部分找出来。

1.首先要锻炼自己软件测试能力,包括需求的分析能力,提取

能力,逻辑化思想能力,即就是给你一个系统的时候,能够把

整个业务流程很清晰的理出。

2.学习测试理论知识并与你锻炼的能力相结合。

3.想和做。想就是说你看到任何的系统都要有习惯性的思考;

做就是把实际去做练习,然后提取经验。

总结测试用例,测试计划固然重要,但能力和思想一旦到位

了,才能成为一名合格的软件测试工程师。

第二次课10.10软件测试模型

一、软件缺陷:(1)软件未达到产品说明书中已经标明的功能;

(2)软件出现了产品说明书中指明不会出现的错误;

(3)软件未达到产品说明书中虽未指出但应当达到的目标;

(4)软件功能超出了产品说明书中指明的范围;

(5)软件测试人员认为软件难以理解、不易使用,或者最终用户

认为该软件使用效果不良。

二、软件测试模型 H

V模型:, 模型(了解)

V模型的缺陷

1、仅把测试过程作为在需求分析、系统设计及编码之后的一个阶

2、忽视了测试对需求分析,系统设计的验证,一直到后期的验收测

试才被发现。

W模型的概念:增加了软件各开发阶段中应同步进行的验证和确认

(v$v)活动,明确了测试与开发的并行性.

1、测试伴随着整个软件开发周期

2、测试的对象不仅仅是程序,需求、设计和功能同样要测试

3、根据W模型要求,一旦有文档提供,就及时确定测试的条件、

编写测试用例

四. 软件测试的原则

4.1 完全测试的不可能性 4.2 软件测试是有风

险的活动

4.3.测试无法显示潜伏的软件缺陷和故障 4.4. 充分注意测试中

的群集现象

4.5杀虫剂现象 4.6.并非所有的软件缺

陷都要修复

4.7. 80-20 原则 4.8.软件测试必须有预

期结果

4.9. 应当把“尽早地和不断地进行软件测试”作为软件测试者的

座右铭

4.10. 程序员应该避免检查自己的程序

4.11 追溯至用户需求 4.12 及时更新测试

第三次课10.14 等价类

1、等价列划分设计方法:是把所有可能的输入数据,即程序的输

入域划分成若干部分(子集),然后从每一个子集中选取少量具有

代表性的数据作为测试用例。

等价类是指某个输入域的子集合。在该子集合中各个输入数据对于

揭露程序中错误都是等效的。并合理地假定:测试某等价类的代表

值就等于对这一类其他值的测试。

有效等价类:对于程序的规格说明来说是合理的、有意义的输入数

据构成的集合

无效等价类:对软件规格说明而言,是无意义的、不合理的输入数

据所构成的集合

等价类对于测试有两个重要的意义:完备性 无冗余性

2、等价类的划分原则

(1)按照区间划分: 一个有效等价类和两个无效等价类。

(2)按照数值划分: n 个有效等价类和一个无效等价类

(3)按照数值集合划分 一个有效等价类和一个无效等价类

(4)按照限制条件或规则划分:可确定一个有效等价类和若干个

无效等价类

(5)细分等价类

3.等价类划分法的步骤

(1)确定等价类

(2)建立等价类表,列出所有划分出的等价类

(3)从划分出的等价类中按以下的3个原则设计测试用例:

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

B 设计一个新的测试用例,使其尽可能多的覆盖尚未被覆盖的有

效等价类,重复这一步,直到所有的有效等价类都被覆盖为止。

C 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等

价类,重复这一步,直到所有的无效等价类都被覆盖为止。

习题:三角形问题。

4.等价类划分法

(1)弱一般等价类测试

特点: 不考虑无效数据,测试用例使用每个等价类中的一个值

(2)强一般等价类测试

特点:每一个有效等价类要选择至少一个测试用例

(3)弱健壮等价类测试

对于有效输入: 使用每个有效类的一个值

对于无效输入: 测试用例只使用一个无效值,其余值都是有效

(4)强健壮等价类测试

每个有效等价类和无效等价类都至少要选择一个测试用例

第四次课10.17 等价类划分(续)

1.测试用例的定义

(1)测试用例是为特定的目的而设计的一组测试输入、执行条件

和预期的结果。

(2)测试用例是执行的最小实体。

2、特征:(1)最有可能抓住错误的;(2)不是重复的、多余的;

(3)一组相似测试用例中最有效的;(4)既不是太简单,也不是

太复杂。

3、设计测试用例的基本准则

测试用例的代表性 测试结果的可判定性 测试结果的可再现性

4、确定等价类的方法

(1)先考虑输入数据的类型(合法型和非法型)

(2)再考虑数据范围(合法型中的合法区间和非法区间)

(3)最后考虑输出结果,逆向设定输入

5、常见等价类划分测试形式 针对是否对无效数据进行测试,可以将等价类测试分为两种:

1 、标准等价类测试(也称,一般等价类测试)

2、健壮等价类测试

弱健壮(5):A (Anom, Bnom) B (Anom,Bmin-)

C (Anom,Bmax+) D (Amin-,Bnom) E

(Amax+,Bnom)

强健壮(9):(Amin- ,Bmin-) ( Amin- ,Bmin+) (Amin+, Bmax+) (Amax+, Bmin-)

.

第五次课10.21 边界值分析法

1、边界值分析法就是对输入或输出的边界值进行测试

2、特点:具有很强的发现程序错误的能力;测试用例来自等价类

的边界;

3、基本原理:故障往往发生在输入定义域和输出值域的边界上,

而不是在其内部。

2、选取正好等于,

d

试数据

5、标准边界值: min、min+、nom、max-、max 4、方法:1、首先应确定边界情况. 有两个变量x、y的程序的输入域

健壮边界值: min、min+、nom、max-、max min- max+

6、例

7、对于一个含有n个变量的程序,只让其中一个变量取极值,让其余的变量取正常值,被保留的变量依次取min、min+、nom、max-、max值,对每个变量都重复进行。n个变量的程序,边界值分析测试程序会产生4n+1个测试用例。

第六次课10.24 -----决策表方法

1.概述:决策表法是黑盒测试方法中最为严格、最具有逻辑性的测试方法。

2.什么时候使用?

程序输入输出比较多,输入之间、输出之间相互制约的条件比较多时,可以清楚地表达它们之间的各种复杂关系。

3.决策表通常由四部分组

规则

条件桩: 列出问题的所有

条件项:针对条件桩给出

能的取值

动作桩:给出问题规定的可能采取的操作 :

动作项:与条件项紧密相关,指出在条件项的各组取值情况下应采取的动作

规则:项中的每一列是一条规则,每一条规则是一组测试用例。

4.决策表的化简

(1)合并 :如果一个条件项(表中某列中的条件值)和另外一个条件项所产生的动作是相同的,且两个条件项对应的每一行的值只有一个是不同的,则可以将其合并.合并的项除了不同值变成”不关心”条目外,其余不变

(2)包含:如果两个条件项的动作是相同的,对任意条件1的值和条件2中对应的值,如果满足:

A.如果条件1的值是T(F),则条件2中的值也是T(F).

– B.如果条件1的值是-(不关心),则条件2中的值是

T,F,-,称条件1包含条件2,条件2可以撤去.

– 重复A,B就可以得到精简的决策表.

合并 包含

5.构造决策表的步骤:

(1)确定规则的个数 (2)列出所有的条件桩和动作桩

(3)填入输入项 (4)填入动作项,得到初始的决策表 (5)对初始的决策表化简

6决策表测试法的适用范围

(1)if-then-else逻辑突出 (2)输入变量之间存在逻辑关系 (3)涉及输入变量子集的计算 (4)输入和输出之间存在因果关系

第七次课10.28--------因果图方法

1、概述:如果输入之间有关系,测试时必须考虑输入条件的各种组合,考虑适合于描述对于多种条件的组合,相应产生多个动作的形式来设计测试用例,这就需要利用因果图。

因果图方法最终生成的就是判定表。适合于检查程序输入条件的各种组合情况。

2、因果图法的基本思想: 首先从程序规格说明书的描述中,找出因(输入条件)和果(输出结果或者程序状态的改变),然后通过因果图转换为判定表,最后为判定表中的每一列设计一个测试用例. 3.基本符号 原因 结果

通常在因果图中用Ci表示原因,用Ei表示结果,各结点表示状态,可取值“0”或“1”。“0”表示某状态不出现,“1”表示某状态出现。

c1

C2

恒等: c1为1,则e1也为1,否则e1为0. 非: 若c1是1,则e1为0,否则e1是1.

或: 若c1或c2或c3是1,则e1是1,若三者都不为1,则e1为0. 与: 若c1和c2都是1,则e1为1,否则若有其中一个不为1,则e1为0.

4..约束:实际问题中,输入状态之间可能存在某些依赖关系. E约束(异): a,b最多有一个可能为1,不能同时为1. I约束(或): a,b,c中至少有一个必须为1,不能同时为0. O约束(惟一): a和b必须有一个且仅有一个为1

R约束(要求):a是1时,b必须是1,即a为1时,b不能为0 M约束:对输出条件的约束,若结果a为1,则结果b必须为0.

5、因果图生成测试用例的基本步骤

1、找出原因和结果。2、画出因果图。 3、增加约束。 4、把因果图转化为判定表,并化简。

5、把判定表的每一列拿出来作为依据,设计测试用例。 6.例题

(1)原因: C1:第一个字符是A; C2:第一个字符是B;

C3:第二个字符是一个数字字找.结果:

结果: E1:给出信息L; E2:修改文件; E3:给出信息M; (2)因果图. (3)决策表。 (4)设计测试用例

测试用例1: 输入数据:A3 预期输出:修改文件 测试用例2: 输入数据:AM 预期输出:给出信息M 测试用例3: 输入数据:B3 预期输出:修改文件 测试用例4: 输入数据:B* 预期输出:给出信息M 测试用例5: 输入数据:C2 预期输出:给出信息L 测试用例6: 输入数据:CM 预期输出:给出信息LM

7.因果图法的优点:

1.考虑了多个输入之间的相互组合、相互制约关系;

2.能够帮助我们按一定步同时还能为我们指出,程序规格说明描述中存在着什么问题.

第八次课10.31 黑盒复习

第九、十次课11.4 11.7白盒测试

1、 白盒测试概述:白盒测试也称结构测试或逻辑驱动测试。 2、 方法:程序结构分析;逻辑覆盖测试;基本路径测试; 3、 原则:1、保证一个模块中所有独立路径至少被测试一次;

2.所有逻辑值均需测试真(True)和假(False)两

种情况;

3.检查程序的内部数据结构,保证其结构的有效性; 4.在取值上、下边界,即可操作范围内运行所有循环.

5、逻辑覆盖测试:主要是测试覆盖率,以程序内在逻辑结构为基础的测试。

6种:语句覆盖 判断覆盖 条件覆盖 判定-条件覆盖 条件组合覆盖 路径测试.

(1) 语句覆盖:在测试时,首先设计若干个测试用例,然后运

行被测程序,使程序中的每个可执行语句至少执行一次 。 判定:整体 控制。 包括:1、单一条件判定 2、符合条件覆盖

语句覆盖率:已执行的可执行语句占程序中可执行语句总数的百分比

(2) 判定覆盖:设计足够多的测试用例,使程序中的每个判定

至少都获得一次“真值”或“假值”。

(3) 条件覆盖:构造一组测试用例,使得每一判定语句中每个

逻辑条件的可能值至少满足一次。

满足条件覆盖的不一定满足判定覆盖,反之亦然。两者无直接关系。

(4) 判定/条件覆盖:设计足够的测试用例,使得判定中每个

条件的所有可能(真/假)至少出现一次,并且每个判定本身的判定结果(真/假)也至少出现一次

(5) 组合条件覆盖(MCC):设计足够的测试用例,使得每个

判定中条件的各种可能组合都至少出现一次。

满足组合条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和

判定/条件覆盖。

(6) 修正条件判定覆盖(MCDC):需要足够的测试用例来确定各

个条件能够影响到包含的判定的结果,即要求满足两个条件。

第十一次课11.11 测试用例设计-8-基本路径

1、

流图:在程序设计时,为了更加突出控制流的结构,可对程序

流程图进行简化,简化后的图称为控制流图.简化后所涉及的图形符号只有两种, 即节点和控制流线. 节点——标有编号的圆圈

 程序流程图中矩形框所表示的处理  菱形表示的两个甚至多个出口判断  多条流线相交的汇合点 边——由带箭头的弧或线表示

 与程序流程图中的流线一致,表明了控制的顺序  它代表程序中的控制流。  控制流线通常标有名字

常见语句的控制流图

包含条件的节点被称为判断节点(也叫谓词节点),由判断节点发出的边必须终止于某一个节点,由边和节点所限定的范围被称为区域. 2、

(1)环形复杂度(圈复杂度):亦可将该度量用于基本路径

方法,它可以提供程序基本集的独立路径数量和确保所有语句至少执行一次的测试数量上界

(2)独立路径:指程序中至少引入一个新的处理语句集合或一个新条件的程序通路,它必须至少包含一条在本次定义路径之前不曾用过的边.

(3)环形复杂度计算:

1. 流图中区域的数量对应于环形复杂度;(闭合区域数+1) 2. 给定流图G的环形复杂度为V(G),定义为V(G )=E-N+2,E是流图中边的数量,N是流图中节点的数量.

一个简单的流图

3. 给定流图G的环形复杂度V(G),定义为V(G)=P+1,P是流图G中判定节点的数量.

46

3

7

8

41

 流图中有四个区域; 10

2

11

13

 V(G)=10条边-8结点+2=4; 14

 V(G)=3个判定结点+1=4。

(4)图矩阵

图矩阵-即流图的矩阵表示。其维数等于流图的节点数。每列和每行都对应于标识的节点,矩阵元素对应于节点的边。其中横坐标为起点, 纵坐标为终点。

例:若矩阵记为M,则M(4,1)=“d”,边d的方向是节点4到节点1

第十二次课11.14 测试用例设计-9-白盒最后

1、 静态测试不实际运行软件,主要对软件的编程格式、结构等方

面进行评估。可以有人工进行,也可借助软件工具自动进行。 2、 静态测试的方法

(1)代码检查:代码审查 代码走查 桌面检查 同行评分(略)  代码审查:通常由4人组成,其中一人是协调人,一人是程序的编写者,其他人员通常是程序的设计人员以及测试专家。 优点和作用:错误列表、高效、会后修正、增加修改错误清单、较早发现错误。

 代码走查:为测试员的人会带着一些书面的测试用例参加会议

 桌面检查:(1)完全没有约束(2)开发人员测试自己的程序(3)没有展示自己能力,缺乏良好的效应。(效果远远逊于代码审查和代码走查)

3、静态结构分析:主要是以图形的方式表现程序的内部结构。 4、代码质量度量:功能性 可靠性 可用性 |有效性 可维护性 轻便性

第十三次课11.18 单元测试

1、单元测试的重要性

时间方面——节省 测试效果——明显 测试成本——较低 产

品质量——直接 2.1 单元测试的定义

单元测试又称模块测试,是最小单位的测试,其依据是详细设描述,对模块内所有重要的控制路径设计测试用例,以便发现模块内部的错误。

单元测试多采用白盒测试技术 2.2 单元测试的对象

结构化程序,单元测试所说的单元是指函数, 面向对象程序,单元测试的单元一般是指类。 2.4 单元测试的人员:开发人员 3、单元测试的内容

模块接口: 检查进出程序单元的数据流是否正确。 局部数据结构: 必须测试模块内部的数据能否保持完整性。 边界条件测试:主要检查临界数据是否正确处理。 独立路径测试:单元测试中最主要的测试。

出错处理:要求能预见出错的条件,并设臵适当的处理对象,保证

其路径的正确性。

1、 输出的错误信息难以理解。

2、 记录错误与实际遇到的错误不符。

3、 在程序自定义出错处理运行之前系统介入。

4、 异常处理不当。

5、 错误陈述中未能提供做够的定位出错信息。

6、

4.、单元测试的方法

5、单元测试的流程 计划单元测试 设计单元测试 执行单元测试 评估单元测试

(1)驱动模块(Drive) 用来模拟被测试模块的上一级模块,相当于被测模块的主程序。它接收数据,将相关数据传送给被测模块,启动被测模块,并打印出相应的结果。

(2)桩模块(Stub) 用来模拟被测模块工作过程中所调用的模块。它们一般只进行很少的数据处理。

5.3 执行单元测试(1)设臵测试环境(2)将测试环境初始化(3)

执行测试过程。

5.4 评估单元测试(1)测试完备性评估 (2) 代码覆盖率评估

第十四次课11.21 单元测试-JUNIT

常用的断言方法

第十五次课11.25 集成测试

1、集成测试又称组装测试,集成测试是在单元测试的基础上,将所有模块按照设计要求组装成子系统或系统进行的测试活动。

2、集成测试的目的

确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确,所测试的内容包括单元间的接口以及集成后的功能。

3、集成测试的层次

(1)模块内集成测试(2)子系统内集成测试(3)子系统间集

成测试

4、集成测试流程

5、集成测试方法:

1)静态测试 只要指对概要设计的测试。

2)动态测试:以黑盒测试为主,需要了解内部细节时结合白盒测试

6、集成测试策略

 非增量式集成:对所有模块进行个别的单元测试后,按照程序结构图将各模块连接起来,把连接后的程序当作一个整体进行测试。

关键模块的特征:

① 满足某些软件需求;

② 在程序的模块结构中位于较高的层次(高层控制模块); ③ 较复杂、较易发生错误;

④ 有明确定义的性能要求。

 增量式集成:逐次将未曾集成测试的模块和已经集成测试的模块(或子系统)结合成程序包,再将这些模块集成为较大系统,在集成的过程中边连接边测试,以发现连接过程中产生的问题。

方法: 1、自顶向下增量式测试 深度优先 广度优先。

2、 自底向上增量式测试

3、混合增量式测试

7、不同集成测试方法的比较

第十六次课11.28 功能测试

1、 确定功能测试的需求

功能测试的基本目标:从用户需求出发,尽早的发现不满足用户需求,与产品说明书不一致的所有问题。

(1) 程序安装启动正常,有相应的提示框,错误提示。

(2) 每一项功能能正常运行,输出结果正确。

(3) 能处理各种不正常的操作,对异常数据的输入可以进行提

示容错处理等。

(4) 系统的界面清晰美观。

(5) 菜单按钮正常、灵活。

(6) 软件升级后能继续支持旧版的数据,支持各种应用环境。

2、 功能测试的内容:

(1) 界面测试:指系统界面整体布臵的合理性,以及是否能清

晰美观。

(2) 数据测试:能够正确的数据输入,对异常的数据输入有提

示和容错处理。

(3) 操作测试:所有菜单按钮设计符合操作习惯,能对操作有

正确的响应。

(4) 逻辑测试:合理清楚、流畅,不复杂。

(5) 接口测试:与硬件设备的接口 第三软件接口 公共接口。

3、所有测试方法都可以使用:例如等价类、边界值、因果图、决策表、场景。

第十七次课12.2

1、 可用性测试

2、 安全性测试

3、 兼容性测试

4、 指标/协议测试

5、安装 /卸载程序测试

6、软件本地化测试


相关内容

  • 测试工程师工作总结
  • 总体来说,xx年我主要完成了以下几方面的工作: l 项目测试工作 l 知识与经验分享 l 完成所需知识的积累 l 工具学习及研究 具体来说,如下: 1.项目测试工作 这段时间,我主要是协助c.y.x进行cmbp项目测试,主要工作内容有: l 对测试用例的编写提供反馈意见; l 对测试过程及测试情况进 ...

  • 软件测试工程师的工作总结
  • 【摘要】 软件质量越来越受到人们的关注,软件测试作为新兴行业有很多不完善的地方。很多从事软件测试工作的同行处于迷茫之中,如何提高,如何解决测试工作中的实际问题,困惑着每一个人。本文总结了一下个人经验,希望对大家有帮助。 【关键词】 软件测试 软件 测试学习 软件测试工程师 我最初参加测试工作的时候, ...

  • 反腐倡廉法规知识测试活动总结
  • 开展反腐倡廉法规知识测试活动总结 为进一步贯彻落实<廉洁从政若干准则>等反腐倡廉法规制度,增强广大党员干部遵纪守法意识,营造学习.知晓和遵守反腐倡廉政策法规的良好氛围,构筑清正廉洁的思想道德防线,按照眉教纪发 [2014]13号文件要求,学校党支部认真组织反腐倡廉法规知识学习和测试活动, ...

  • 软件工程知识点总结
  • 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.是一门指导软件系统开发的工程学科,它以计算机理论及其他学科为指导,采用工程化的概念.原理.技术和方法进行软件的开发和维护,把经实践证明的学科的管理措施与最先进的技术方法结合起来,目标是以较少的投资获取高质量的软件. 内容: ...

  • 软件项目工作总结2篇
  • 自2月份开始,我一直在跟进xx银行w-xxnd1s2.0项目的测试工作,至此为止已近6个月时间, 从公司内部系统测试、验收测试,再到uat测试,以及投产前的系统压力测试等等。从开始到项目即将结束,一步步走过来。本次项目中,我作为测试环节的主力 人员之一,仅对此项目中测试工作进行总结。 一、项目测试进 ...

  • 手机游戏设计与开发-T0201-0
  • 编号:JX/GC7.3.1-02-JL01 <手机游戏设计与开发>课程标准 学分:4学分 参考学时:72学时 一.课程概述 <手机游戏设计与开发>是嵌入式技术与应用专业的专业限选课程.本课程的先修课程包括<C 程序设计>.<C++程序设计>.<嵌 ...

  • 软件年终总结范文
  • 软件年终总结范文哲学就是用简单的说话来体现出隐含深层意义的道理,让人们去思考和体会.哲学本身就是用来完善自己的精神修养和帮助他人完善思想的. 哲学的特征在于追问本质,不断反思.内容上,哲学的反思对象无所不包;深度上,哲学的反思是无穷无尽的.现实中,我们可以借用哲学的思维方式,但是不能照搬哲学的思维方 ...

  • 软件开发工作总结
  •  1、 分享第一条经验:“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要:“重要的道理明白太晚将抱憾终生!”所以放在每一条,让刚刚毕业的朋友们早点看到哈!   2、 一定要确定自己的发 ...

  • 一位软件工程师的经验总结
  • 一位软件工程师的经验总结 又是一年毕业时,看到一批批学子离开人生的象牙塔,走上各自的工作岗位想想自己也曾经意气风发.踌躇满志,不觉感叹万千--本文是自己工作6年的经历沉淀或者经验提炼,希望对所有的软件工程师们有所帮助,早日实现自己的人生目标. [查看详情] 1."学历代表过去.能力代表现在 ...

  • 软件测试工程师最新个人年度总结
  • 软件测试工程师工作岗位 =个人原创,有效防止雷同,欢迎下载= 转眼之间,一年的光阴又将匆匆逝去.回眸过去的一年,在×××(改成软件测试工程师岗位所在的单位)软件测试工程师工作岗位上,我始终秉承着"在岗一分钟,尽职六十秒"的态度努力做好软件测试工程师岗位的工作,并时刻严格要求自己, ...