第一章

1、软件测试的定义:

IEEE给出的定义——

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

《软件测试技术基础》——

软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。

2、软件测试的目的

软件质量:

1.发现系统的错误

2. 验证系统是否满足需求

3. 为产品放行提供依据

4. 改进开发流程

对于企业来说：

回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

测试的重要目的之一：发现软件中的缺陷

3、软件测试对象

阶段性文档(1 2 3):

1需求规格说明书 2概要设计规格说明书 3详细设计规格说明书

4源程序 5系统

最终产品文档(6 7):6用户手册 7帮助文档

4、软件质量保证人员与软件测试人员

同：两个岗位旨在提高软件的质量

异：软件测试人员SQC

1关心过程的产物2剖析开发出的软件

质量保证人员SQA

1全面质量管理 2过程改进

5、软件测试的原则

1.所有的软件测试都应追溯到用户需求

2.尽早地、不断地进行测试

3.严格执行测试计划

4.注重测试用例的设计

5.程序员应该避免测试自己的程序

6.增量测试，由小到大

7.注意集群现象(二八定理)

8.完全测试是不可能的

9.测试维护

集群现象（二八定理）Pareto原则：测试发现的错误中80%很可能起源于20%的模块中。

6、测试用例

IEEE标准610（1990）的定义：

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

一组测试用例包含：1、用例的编号 2、测试标题 3、用例级别 4、预置条件

5、操作步骤 6、预期结果

7、软件测试环境

软件测试环境= 软件+ 硬件+ 网络+ 历史数据

8、软件缺陷

软件从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都可能产生和发现缺陷。

需求阶段最多，运行维护时花费代价最高。

9、软件测试分类

1）、按测试技术上分类（是否查看代码）

黑盒测试：在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规 定正常用。也被称为功能测试或数据驱动测试。

白盒测试（测试代码）：要完全了解程序结构和处理过程，它按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。也被称为结构测试或逻辑驱动测试。

灰盒测试：介于黑盒测试与白盒测试之间的测试，即要像黑盒测试那样关注输出对于输入的正确性；同时也关注内容表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志判断内部的运行状态。避免过度测试，精简冗余用例。

2）、按测试方式上分类（是否运行程序）

静态测试：是指不运行程序，对程序和文档进行分析与检查；静态测试技术又称为静态分析技术。

动态测试：通过运行程序进行检查、分析程序的执行状态和程序逻辑的外部表现

3）、按测试阶段分类

单元测试：单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作。包括对每一行代码进行基本测试。（白盒）

目的：主要是测试模块在语法、格式和逻辑上的错误。

集成测试：集成测试也称为组装测试，集成测试按设计要求把通过单元测试的各个模块组装在一起之后所进行的测试。(黑灰盒)

目的：检查模块间的接口关系，以便发现与接口有关的各种错误

系统测试：系统测试是将已经集成好的软件系统置于实际运行环境中所进行的测试。（黑盒为主）

目的：根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。

验收测试：为了检验接受测试的系统是否满足需求。用户也参与进来，（黑盒）

目的：验证软件功能的正确性和需求的符合性。

4）、按测试实施组织分类

开发方测试：开发方测试也称内部测试，主要指在软件开发完成后，开发方要对提交的软件进行全面的自我检查与验证，验证软件的实现是否满足软件需求说明的要求。

用户方测试：用户方测试是在用户的应用环境下，由用户通过运行和使用软件，验证软件实现是否符合自己期望的要求。由用户找出软件的应用中发现的问题与缺陷，并对使用质量进行评价。

第三方测试：第三方测试又称为独立测试，由在技术、管理和财务上和开发方和用户方相对独立的组织进行的测试。软件质量工程强调开展独立的验证和确认工作。一般找一个别的公司。

5）、按软件的质量特性分类

功能测试、性能测试、压力测试、用户界面测试、安全测试、可靠性测试、安装测试、兼容性测试、

10、软件测试什么时候开始

尽早开始，贯穿整个生命周期。

软件生命周期被划分成了若干个阶段：

可行性分析与项目计划、需求分析、系统设计、编码、调试、测试（执行）、维护升级到废弃等阶段。

11、测试数据文档

需求文档、缺陷报告、测试用例、测试计划方案

简单选择判断：

完全的测试是不可能的

原因：软件太复杂，资源不容许，“杀虫剂现象”等等。

措施：

需要根据实际情况来决定资源的分配，对测试程度和

范围进行有效的控制，只有这样才能投入最少的成本

获得最大的回报。

不能修复所有的软件故障

原因：没有足够的资源进行修复 修复的风险较大 不值得修复

结论：关键是要进行正确的判断、合理的取舍根据成本和风险分析决定哪些必须修复，哪些可以不修复

经验1：没有经过自己验证的问题，不要轻信

经验2：测试人员要始终站在用户的角度去看问题

经验3：必须基于“质量第一”的思想去开展工作

经验4：修复缺陷后，一定要进行回归测试

软件质量

软件的一些质量特性的组合，反映了软件满足用户需求的程度。[规定或隐含的需求]

瀑布模型

开发阶段包括计划、需求分析、设计、编码、测试和运行维护。

2章 黑盒测试（3个简答，黑盒测试设计）

1.黑白盒测试的定义及区别 （简答）

黑盒测试（Black-box Testing）又称为功能测试。

黑盒测试就是把测试对象看做一个不能打开的黑盒子，在完全不考虑程序的内部结构和处理过程的情况下，只依据程序的需求规格说明书， 检查程序的功能是否符合他的功能说明。

Ps:  关注程序外部结构，不考虑内部逻辑结构，不知道程序如何工作。 

注重软件的功能性需求，主要针对软件界面和软件功能进行测试。

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的，又称为数据驱动测试。

黑盒测试是在程序外部接口进行的测试。

白盒测试也称结构测试或逻辑驱动测试，通过了解软件系统的内部工作过程，设计测试用例来检测程序内部动作是否按照规格说明书规定的正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作。

 白盒测试旨在使测试充分地覆盖软件系统的内部结构，并以软件结构中的某些元素是否都已得到测试为准则来判断测试的充分性。

2.黑盒测试发现的主要错误类型（简答）

1）功能错误或遗漏； 2）界面错误； 3）外部数据库访问错误；

4）性能错误； 5）初始化和终止错误。

黑白盒的测试方法 （简答）

黑盒测试方法：①等价类划分法 ②边界值分析法 ③判定表法 ④因果图法 ⑤场景法

白盒测试方法：①逻辑覆盖法（语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖）、②基本路径测试

等价类定义

等价类是指某个输入域的子集合。

在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。

测试某等价类的代表值就等价于对这一类其 它值的测试。

等价类划分法步骤

（1）划分等价类（有时需要细化） （2）建立等价类表，等价类进行编号

（3）通过等价类导出测试用例

从划分出的等价类中按以下原则设计测试用例:（选择）

（1）编号唯一 （2）尽可能多地覆盖尚未覆盖的有效等价类

（3）仅覆盖一个尚未覆盖的无效等价类 （4）覆盖所有的有效和无效等价类

等价类例题 （设计题）

对于函数F（X,Y）,其输入变Y的取值边界定义如下： X ∈ [a，b）∪ [b，c） ∪ [c，d] ； Y ∈[e，f）∪ [f，g] 可得到X,Y的等价类如下表

试用前述几种等价类测试用例设计法设计测试用例

边界值分析法定义 （设计题）

对输入或输出的边界值进行测试的一种黑盒测试方法。

是作为对等价类划分法的补充，这种情况下， 其测试用例来自等价类的边界。

边界点分为上点（边界上的点）、内点（域范围内的任意一个点）和离点（离上点最近的一个）

边界条件设计测试用例步骤

（1）确定边界情况（2）选取测试数据（3）导出测试用例

边界值分析法例题

程序的规格说明中规定：“重量在10公斤至50公斤范 围内的邮件，其邮费计算公式为……”。

（1）测试数据应取10及50，还应取9.99，10.01, 49.99及 50.01等。

(2)

判定表定义（设计题）

判定表（也称决策表）是一个用来表示条件和行动的二维表，是分析和表达多逻辑条件 下执行不同操作的情况的工具。

Ps: 等价类划分法和边界值分析方法比较适合输入变量或输入条件相互独立的情况，但是当输入变量或输入条件相互依赖、相互制约的时候，采用等价类划分法和边界值分析方法是难以描述的，测试效果也很难保障。

在所有的黑盒测试方法中，基于判定表的测试是最为严格、最具有逻辑性的测试方法

判定表的建立步骤

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

（3）填入条件项 （4）填入动作项 （5）简化判定表

规则公式

①有限条件桩：2的n次方（n条件桩个数 ②扩展条目：每组取值个数相乘

判定表例题（设计题）

我们可以通过分析三角问题的处理过程（即“业务逻辑”）得到： 

当判断出a=b=c时，程序输出“等边三角形”。 

当判断出a=b或b=c或a=c时，程序输出“等腰三角形”。 

当a!=b且b != c且c !=a时，程序输出“一般三角形”

（1）列出所有的条件桩和动作桩：C1:a,b,c构成 三角形? C2:a=b? C3:a=c? C4:b=c?

A1:非三角形 A2:一般三角形 A3:等腰三角形 A4:等边三角形 A5:不可能

（2）确定规则的个数 2ˆ4=16

（3）填入条件项，填入动作项

（5）简化判定表 （6）设计测试用例

①对每一条规则设计一个测试用例

②去掉不存在的情况

因果图法定义（设计题）

因果图法（Cause-Effect Graphics） 是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法。

Ps: 因果图提供了一个把需求转化为判定表的系统化方法 

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

原因：输入条件 结果：输出

因果图法例题+步骤

某软件的一个模块的需求规格说明书中描述：

（1）年薪制员工：严重过失，扣年终风险金的4%； 过失，扣年终风险金的2%。

（2）非年薪制员工：严重过失，扣当月薪资的8%； 过失，扣当月薪资的4%。

请绘制出因果图和判定表，并给出相应的测试用例

（1）分析原因和结果 （2）画出因果图

（3）施加相应的约束 （4）将因果图转化成决策表（判定表）

（5）设计测试用例

因果图的约束符号

1）输入条件的4种约束

①E约束（异/互斥Exclusive）：几个原因不会同时成立，可能他们都不成立，但最多有一个成立

② I约束（或/包含In）：表示几个原因中至少有一个必须成立，当然也 可能都成立。

③O约束（唯一Only）：表示几个原因中必须有且仅有一个成立

④R约束（要求Request）：表示当a出现时，b必须也出现。

2）输出条件的约束类型

①M 约束（屏蔽Mandate）：表示当a是1时，b必须是0； 而当a为0时，b的值不一定

场景法定义

场景法就是通过用例场景描述用例执行的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。

18.场景法例题+步骤

需求规格说明： 用户在一个在线购物网站购物，需要成功登录 到系统，选购后在线购买，在线上支付。支付成 功后生成订单，完成整个购物过程。

（1）画出路径流程图

（2）描述出基本流和备选流

（3）确定用例场景

（4）生成测试用例

V（Valid有效的）表明这个条件必须有效才可执行基本流； 

I（Invalid 无效的）表明这种条件下将激活所需备选流； 

“N/A”（不适用）表明这个条件不适用于测试用例。

（5）设计测试数据

（6）测试用例的补充

第三章（选择、判断）

1、测试过程模型

V模型：

开发过程

测试过程

优点：1. 表明了测试过程中存在的不同级别的测试

2. 描述了测试阶段和开发过程各阶段的对应关系

局限性：仅仅把测试过程作为编码之后的一个阶段。忽视了测试活动对需求分析、设计等活动的验证功能。容易使人理解为测试是软件开发的最后一个阶段，主要针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的测试才被发现。不能体现“尽早地、不断地进行测试”的原则

W模型

优点：表明测试与开发的并行关系，有利于尽早地发现问题。

强调测试伴随着整个软件开发周期

测试的对象不仅仅是程序，还包括需求和设计等

局限性：W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动

上一阶段完全结束，才可正式开始下一个阶段工作。

这样就无法支持迭代的开发模型。

注：实践告诉我们，严格的阶段划分知识一种理想状况。

2、单元测试（测试代码）

1）依据：详细设计说明书、需求规格说明书

2）使用的方法：白盒测试为主

3）目的：验证代码是与设计相符合

发现在编码过程中引入的错误

4）主要任务：模块接口、局部数据结构、边界条件、路径和错误处理

5）单元测试的环境：

辅助模块有两种：

驱动模块(Drive) 用来模拟被测试模块的上一级模块，相当于被测模块的主程序。用来模拟被测试模块的上一级模块，相当于被测模块的主程序。

桩模块(Stub) 用来模拟被测模块工作过程中所调用的模块。

驱动模块调用被测模块，被侧模块调用桩模块

6）单元测试工具：

C++：Gtest、Cppunit(开源件)C++Test（parasoft公司）Visualunit（国产）

Java：JunitGtestCppunit()

.Net：Nunit

7）测试人员：开发人员（白盒测试范畴）、测试人员（或同组的程序员）的测试，灰盒测试。（最后一个可忽略）

3、集成测试（测试接口）

1）集成测试策略

在对测试对象分析的基础上，描述软件单元集成（组装）的方式和方法，它是集成测试过程中各种活动的基础。过程中各种活动的基础。

基于分解的集成策略、基于功能的集成、基于调用图的集成、基于路径的集成、基于进度的集成、基于风险的集成

2）依据：概要设计说明书、需求规格说明书

3）使用方法：黑盒灰盒

4）集成测试流程（5个阶段）：计划阶段、设计阶段、实施阶段、实施阶段、执行阶段、评估阶段

4、系统测试

1）概念：

系统测试（System Testing，简称ST ）对已经集成好的软件系统进行的测试，以验证软件系统的功能和性能等满足其需求规格所指定的要求。

系统测试的对象：

软件产品、操作系统、硬件、外设、相关配置、支持软件及其接口硬件、数据库

总之，要将软件与各种依赖的资源结合起来，在系统实际运行环境下进行测试。

2）几类常用的系统测试类型：

功能测试、性能测试、恢复性测试、GUI测试、压力测试、安全性测试、兼容性测试、安装测试、文档测试

5、单元测试、集成测试、系统测试区别

6、验收测试要有用户参与

测试过程包括三大部分：

测试人员、测试过程分解、测试工作产品

第四章 软件测试流程（简答 论述题：测试流程）

项目中测试的基本流程

测试流程的阶段

（1）测试计划阶段 —需求分析、制定测试计划  （2）测试设计阶段 —制定测试方案、设计测试用例 —制定测试方案、设计测试用例 （3）测试实现阶段 —编写测试用例  4）测试执行阶段 —执行测试用例、提交缺陷报告、编写测试报告

测试计划应该包含哪些内容

1、确定测试的目标、进度、人力、环境、工具等 2、为达到测试目标采用测试类型 • 3、功能性需求4、非功能性需求 5、针对测试需求采用的测试方法

Ps 测试计划≠测试计划文档

需求分析的方法（简答）

①范围分析：明确需求的测试范围

②流程分析：明确每一个功能的业务处理过程

③功能交互分析：不同的功能点之间业务的组合

④数据分析：明确各测试模块的数据流

⑤用户场景分析：模拟用户实际业务中的场景

⑥隐式需求分析：挖掘显式需求背后的隐式需求

·测试用例的基本要素包括：

①用例编号 ②用例标题 ③用例级别 ④预置条件 ⑤操作步骤 ⑥预期结果

设计测试用例易犯问题

(1) 把测试用例设计等同于测试输入数据的设计 (2) 强调测试用例设计得越详细越好

(3) 追求测试用例设计“一步到位” (4) 将多个测试用例混在一个用例中

(5) 让没有测试经验的人员设计测试用例

测试用例的编写依据

·测试用例的设计必须建立在需求的基础之上， 根据用户的需求设计，用于检测系统的行为是否与 需求所指定的一致。

测试用例设计的基本原则

(1) 用成熟测试用例设计方法来指导设计 (2) 测试用例的正确性(3) 测试用例的代表性 (4) 测试结果的可判定性 (5) 测试结果的可再现性 (6) 足够详细、准确和清晰的步骤

9、缺陷的类型

1.） 软件未达到产品说明中已标明的功能。

2.）软件出现了产品说明书中指明不会出现的错误。

3.） 软件功能超出了产品说明书指明的范围。

4.） 软件超出了产品说明书虽未指出但应达到的目标。

5.）软件测试员认为软件难以理解，不易使用，运行速度慢，或者最终用户认为该软件使用效果不好。

10、缺陷的生命周期

11、缺陷报告包括那些内容，由什么组成

基本信息：软件名称、测试版本号、缺陷编号ID、日期、提交人、处理人、所在模块、软件平台、操作系统

主要属性：严重程度、优先级、缺陷状态

主要描述：概要描述：标题 详细描述：操作步骤、缺陷实际结果、预期正确结果、截图、注释

12、缺陷的分布、属性、成本高低

软件缺陷的主要属性

（1）缺陷的严重程度 （2）缺陷的优先级 （3）缺陷的状态

分布：需求>设计>编码>测试>发布

成本：发布>测试>编写代码>设计阶段>编制说明书

13、优先级和缺陷严重程度关系

严重性(Severity)是软件缺陷对软件质量的破坏程度

优先级(Priority)是处理软件缺陷的先后顺序的指标。

一般来说，严重程度高的缺陷具有较高的优先级。

1）如果某个严重的缺陷只在非常极端的条件下产生，则可以将缺陷的优先级设置得比较低。2）如果修正一个软件缺陷需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且市场要求尽快发布软件版本，那么即使这个缺陷严重程度很高，也需要仔细考虑是否需要修改。

3）对于有些缺陷，可能它的严重程度很低，例如：界面单词拼写错误，但假如这是公司的名称或者商标，则这个缺陷的优先级就很高，必须尽快进行修复，因为这个关系到软件系统和公司在市场上的形象。

第五章（选择、判断、一个简答）

1、自动化测试

1）概念：软件测试自动化是一项让计算机代替测试人员进行软件测试的技术，希望能够通过自动化测试工具或者其他手段，按照测试工程师的预定计划进行自动的测试。

软件测试自动化通常借助测试工具进行。

软件测试自动化的目的是减轻手工测试的工作量。

2）常见工具

根据测试方法不同，可以分为：

白盒测试工具、黑盒测试工具

根据测试的对象和目的，可以分为：

单元测试工具、回归测试工具、单元测试工具、功能测试工具、负载测试工具、性能测试工具、Web测试工具、数据库测试工具、回归测试工具、嵌入式测试工具、页面链接测试工具、测试设计与开发工具、测试执行和评估工具、测试管理工具等

常用工具类型总结表

————————————————

版权声明：本文为CSDN博主「syh1047679200」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/weixin_44846959/article/details/90756179