课堂笔记《软件基础测试》

IT（information Technology), 即信息科技产业的意思.

软件是什么:程序+数据+文件.
产品是什么:被人们/用户所需要.消费.使用的.

1.什么是软件测试?

了解用户需求(甲方),为用户所需进行系统性、标准化、规范化的一个过程.
定义：用人工和自动手段来运行或测试某个系统的过程.
目的：在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别.
(找BUG，找错误）

测试类型：

• 功能测试（必须会）
• APP
• 接口
• 自动化

2.软件的生命周期

立项–>需求分析–>设计–>写代码 编码(coding)–测试(testing)–>部署实施–>产品支持–>END

项目组成员

客户经理(写需求文档,与客户沟通,反馈)
项目经理(关联需求,建立项目)
开发团队(创建build)
测试经理
测试团队

3.研发模型

瀑布模型

计划–>需求分析–>设计–>编码–>测试阶段–>运行维护

优点:

• 为项目提供了按阶段划分的检查点:
• 当前一阶段完成后，您只需要去关注后续阶段。
• 可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
• 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导

缺点：

• 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
• 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
• 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
• 瀑布模型的突出缺点是不适应用户需求的变化。

原型

需求分析–>原型设计–>设计–>编码–>测试–>运行维护

优点:
缺点:

敏捷模型（要记）

优点:

1. 频繁交货
2. 与客户面对面的交流。
3. 高效的设计并满足业务需求。
4. 随时可以接受更改。
5. 它减少了总的开发时间。

缺点:

7. 由于缺少正式文件, 因此会造成混乱, 并且各个团队成员随时可能会误解贯穿各个阶段做出的重要决定。
8. 由于缺乏适当的文档, 一旦项目完成并且开发人员被分配到另一个项目, 完成的项目的维护就会变得很困难。

“V”模型（要记）

需求分析–>还要设计–>详细设计–>编码–>单元测试–>集成测试—>系统测试–>验收测试

优点:

既包括底层测试又包括了高层测试,低层测试是为了源代码的正确性,
高层测试是为了是使整个系统满足用户的需求.

局限性:

把测试的过程作为再需求分析,概要设计,详细设计及编码之后的一个阶段,不能体现"尽早地和不断地进行软件测试"的原则.

“W”模型（要记）

优点:

1. 测试的活动与软件开发同步进行
2. 测试的对象不仅仅是程序，还包括需求和设计
3. 尽早发现软件缺陷可降低软件开发的成本

局限性：

但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

"H"模型

优点：

1. 软件测试不仅仅指测试的执行，还包括很多其他的活动。
2. 软件测试是一个独立的过程，贯穿产品整个生命周期，与其他流程并发的进行。
3. 软件测试要尽早准备，尽早执行。
4. 软件测试是根据被测物的不同而分层次进行的。
5. 不同层次的软件活动可以是按照某个次序先后进行的，但也可能是反复的。
6. 软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发的进行。

"X"模型

前置模型

优点：

1. 体现开发和测试相结合。
2. 对每一个交付内容进行测试。
3. 在设计阶段进行测试计划和测试设计。
4. 测试和开发结合在一起。
5. 让验收测试和技术测试保持相对独立。

4.软件测试阶段

需求测试

返工：70%～85%由于需求
重点：检查需求规格说明书 SRS

• 完整性
• 正确性
• 一致性
• 可行性
• 无二义性
• 健壮性
• 必要性
• 可测试性
• 可修改性

单元测试

单元：函数、类

单元测试是针对软件基本组成单元（软件设计的最小单元）来进行正确性检测的测试工作。
单元检测的目的是检测软件模块对《详细设计说明书》LLD的符合程度。

类与对象：
例子：学生（类）与老师
学生有属性，姓名、学号、性别，学生的属性都存在数据库（增、删、改、查）
业务逻辑：代码是怎么处理的

集成测试

集成测试是对单元之间及单元与第三方接口之间的测试，目的是验证接口是否与设计相符，是否与需求相符。（即检测软件模块对《概要设计说明书》的符合程度）
集成策略：自底向上或自顶向下 渐增式

系统测试

系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行(使用)环境下，对计算机系统进行系列的测试工作
系统测试的目的在于通过与《需求规格说明书》作比较，发现软件与系统需求定义不符合或与之矛盾的地方

确认测试

又称有效性测试，它的任务是验证软件的有效性，即验证软件的功 能和性能及其它特性是否与用户的要求一 致。
若能达到这一要求， 则表明开发的软件是合格的。

验收测试

交付用户部署前，进行验收测试
以用户为主，验收组:项目组成员、用户代表或者系统的其它利益相关者。
根据合同、《需求规格说明书》 或《验收测试计划》对成品进行验收测试。

Alpha测试和Beta测试

Alpha:内部，模拟/真实
Beta:外部，真实

UAT测试

User Acceptance Test 用户接受度测试
验证系统的可用性

回归测试

回归测试(Regression Testing) :软件在测试或其他活动中发现的缺陷经过修改后进行的测试。目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。
回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试。

回归测试策略

完全重复测试:
重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性
选择性重复测试:
即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序

回归测试流程

ⅰ. 在测试策略制定阶段，制定回归测试策略。
ⅱ. 确定需要回归测试的版本。
ⅲ. 回归测试版本发布，按照回归测试策略执行回归测试。
ⅳ. 回归测试通过，关闭缺陷跟踪单（问题单）
ⅴ. 回归测试不通过，缺陷跟踪单反回开发人员，开发人员重新修改问题，再次提交测试人员回归测试。

5.软件测试类型（了解）

功能测试：
概念：功能测试是根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格
目标：功能测试主要是为了发现以下几类错误:
a. 是否有不正确或遗漏了的功能?
b. 功能实现是否满足用户需求和系统设计的隐藏需求?
c. 输入能否正确接受?能否正确输出结果?

性能测试(Performance Testing)：

就是用来测试软件在集成系统中 的运行性能的。
目标：度量系统相对于预定义目标的差距。
性能测试收集的信息：

1. CPU使用情况
2. IO使用情况
3. 内存使用情况
4. 信道使用情况
5. 每个模块执行时间百分比
6. 一个模块等待IO完工的百分比
7. 指令随时间的跟踪路径
8. 每一组指令页换入和换出的次数
9. 系统反应时间
10. 系统吞吐量，即每个时间单元的处理数量 • 所有主要指令的单元执行时间

负载测试：

超过被测对象标准性能负荷指标下，验证系统的负载承受能力。并要求超负荷情况下，依然正常实现业务功能。

压力测试(Stress Testing）：

目的：调查系统在其资源超负荷的情况下的表现。尤其感兴趣的是这些对系统的处理时间有什么影响。这类测试在一种需要反常数量、频率或资源的方式下执行系统。
目标：通过极限测试方法，发现系统在极限或恶劣环境中自我保护能力。主要验证系统的可靠性，找到系统薄弱环节。

容量测试(Volume Testing)：

目的：使系统承受超额的数据容 量来发现它是否能够正确处理。
安全性测试(Security Testing)：
目的：用来验证集成在系统内的保护机制是否能够在 实际中保护系统不受到非法的侵入。用来保证系统本身数据的完整性和保密性。
一些功能性的安全性问题:
• 没有口令是否可以登录到系统中?
• 各级用户权限划分是否合理?
• 错误和文件访问是否适当地被记录?
• 系统配置数据是否能正确保存，系统故障时是否能恢复?

GUI测试：是针对软件系统GUI界面进行的测试
可用性测试(Usability Testing)：
为了检测用户在理解和使用系统方面到底有多好。

安装卸载测试：

定义：系统的可安装性测试，主要是根据软件的测试特性列表、软件安装、配置文档，设计安装过程的测试用例，发现软件在安装过程中的错误。

异常测试：

概念：系统异常测试又叫系统容错和可恢复性测试，它是通过人工干预手段使系统 产生软、硬件异常，通过验证系统异常前后的功能和运行状态，达到检验系 统的容错、排错和恢复的能力。它是系统可靠性评价的重要手段。
文档测试：(Documentation Testing)
目标：验证用户文档是正确的并且保证操作手册的过程能够正确工作。

网络测试（接口测试）：

概念：网络测试是在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常
如通信产品，主要进行协议测试：

1. 一致性测试
2. 性能测试
3. 互操作性测试
4. 坚固性测试

稳定性测试：

目的：评价系统在一定负荷情况下、长时间的运行情况。包括系统在一定负荷下，再增加新的业务，原有的业务是否受影响，新的业务是否能正常工作，系统资源有无泄漏，数据有无不一致的情况，系统性能是否会降下来，关键点是长时间的运行后，系统的状况如何，系统平均无故障时间MTBF是否满足系统设计要求。

兼容性测试：

兼容性测试验证被测对象与硬件、其他软件之间的兼容情况。

软件测试方法

白盒测试：（又被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试）
依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况。
为什么进行白盒测试：

• 白盒测试一般在测试前期进行，通过达到一定的逻辑覆盖率指标，使得软件内部逻辑 控制结构上的问题能基本得到消除
• 白盒测试能保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证
• 白盒测试发现问题后解决问题的成本较低
白盒测试的常用技术：
• 静态分析:控制流分析、数据流分析、信息流分析等
• 动态分析:逻辑覆盖测试(分支测试、路径测试等)、程序插装等

黑盒测试

1. 黑盒测试把被测对象看成一个黑盒，只考虑其整体特性，不考虑其内部具体实现。
2. 黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块、一个函数等。
3. 黑盒测试又可以被称为基于规格的测试。
   
   黑盒测试类型：

• 功能性测试，一种是顺序测试每个程序特性或功能，另一种途径是一个模块一个模块的测试，即每个功能在其最先调用的地方被测试
• 容量测试，检测软件在处理海量数据时的局限性，能发现系统效率方面的问题
• 负载测试，检测系统在一个很短时间内处理一个巨大的数据量或执行许多功能调用上的能力
• 恢复性测试，主要保证系统在崩溃后能够恢复外部数据的能力

黑盒测试的特点：

• 对于更大的代码单元来说(子系统甚至系统级)比白盒测试效率要高
• 测试人员不需要了解实现的细节，包括特定的编程语言
• 从用户的视角进行测试，很容易被大家理解和接受
• 有助于暴露任何规格不一致或有歧义的问题

灰盒测试

• 根据利用的被测对象信息的不同，会采用不同的方法进行测试。
• 利用被测对象的整体特性信息，采用黑盒测试方法
• 利用被测对象的内部具体实现信息，采用白盒测试方法
• 如果既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，采用的就是灰盒测试方法。两种信息占的比例不同，相应的灰度就不同。完全是整体特性信息，就是黑盒测试，完全是内部具体实现信息，就是白盒测试
• 典型的灰盒测试比如集成测试和系统测试时借助log信息

动态测试和静态测试

• 静态测试:不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。例如:代码走读、文档评审、程序分析等都是静态测试的范畴。常用技术有静态分析技术。
• 动态测试: 按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。常用技术有动态分析技术。

静态分析技术

• 定义:静态分析是一种不通过执行程序而分析程序执行的技术
• 功能:检查软件的表示和描述是否一致，没有冲突或者没有歧义，它瞄准的是纠正软件系统在描述、表示和规格上的错误，因此是任何进一步测试执行的前提。
主要有三种不同的程序测试可能性:

1. 考虑程序是否满足编码规则，语法上是否具有一致性和完整性;
2. 考虑文档描述是否规范、准确、便于查阅;
3. 考虑程序和文档之间的一致性。

人工和自动化测试

• 人工测试:测试活动(如评审、测试设计、测试执行等)由人来完成，狭义上是指测试执行由人工完成，这是最基本的测试形式
• 自动化测试:一般是指通过计算机模拟人的测试行为，替代人的测试活动，狭义上是指测试执行由计算机来完成

自动化测试的意义：

• 对程序新版本运行前一版本执行的测试，提高回归测试效率
• 可以运行更多更频繁的测试，比如冒烟测试
• 查看路由能做的测试，比如大量的重复
• 可以执行手工测试困难或不可操作或者集成测试
• 更好地利用资源，比如测试仪器或者被测对象

自动化测试的限制：

• 不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即不可能发现更多缺陷
• 手工测试比自动测试发现的缺陷更多
• 对测试设计依赖性极大，测试设计的不好会遗漏问题
• 自动化测试对软件开发具有很大的依赖性，开发上出现变更可能导致前面的自动化测试完全失效
• 工具本身并不具备想象力，工具不具有智能

6.软件测试流程

• 测试需求阶段–测试需求报告
• 测试计划阶段 – 测试计划
• 测试设计阶段 – 测试方案
• 测试实现阶段 – 测试用例、测试规程
• 测试执行阶段 – 测试报告
• 评估与总结阶段–测试总结报告

主要的测试文档：

1. 测试计划:指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。
2. 测试方案:指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
3. 测试用例:指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。
4. 测试规程:指明执行测试时测试活动序列的文档。
5. 测试报告:指明执行测试结果的文档。
6. 测试日报:每天测试执行情况的记录和总结。

系统测试过程与开发阶

系统测试各阶段的输入与输出

7.软件测试质量

软件质量模型：

软件测试与QA的区别：

1. 从性质上看: 测试属于技术的工作；QA属于管理的工作
2. 从对象上看: 测试的对象是软件研发产品，大多数工作是对研发领域的检验；QA的对象是整个软件过程，覆盖各个领域
3. 从手段上看: 测试以事后检查为主；QA强调的是缺陷预防

质量保证活动与软件测试的关系

1、点赞。防止以后找不到，想看的时候，在自己主页就能找到了，很方便;
2、关注我。让我们成为长期关系，下一个视频会分享更多的硬核干货;
3、本文章学习资源，均可以免费分享。

微信公众号：程序员一凡。这样的好内容，里面还有近百篇。 谢谢你的支持！

目前测试平台项目研发已经完成并且在Github开源，有兴趣的朋友可以去Github下载
https://github.com/ooqitech/ATP

不要只做收藏从未停止，行动从未开始的人，很多事情，做着做着就无师自通了。如果在做的过程中还能稍微加点思考，稍微看一些别人的经验和做法，成长会更快，效果也会更好！加油吧，测试人！路就在脚下，成功就在明天！

一个用心码了这么多文字的人，往往渴望得到大家的认可。如果你觉得这篇文章对你有帮助，双击屏幕，给我点个赞呀！

更多软件测试资源分享微信公众号：【程序员一凡】
软件测试技术交流群：1079636098