软件测试基础（一）--基本概念

笔记内容来源：慕课网--软件测试基础--概念篇（视频）

视频链接：https://www.imooc.com/learn/700

课程目标 

一、了解软件测试的含义，行业对软件测试的定义，软件测试的对象有哪些

早期定义：软件测试是对程序能够按预期运行建立起一种信心。------Bill Hetzel，1973

经典定义：测试是为了发现错误而执行程序的过程。------Myers，1979

IEEE定义（ISO/IEC/IEEE 29119）：使用人工或自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。

软件测试的对象：（整个软件开发周期）软件需求，软件概要设计，软件详细设计，软件源代码，可运行程序，软件运行环境。

五大要素：质量（重要），人员（决定因素），资源（硬件设备、网络环境、测试周期、测试数据等），流程（测试计划、用例、执行、报告，做规范要求），技术（测试技术、方法、工具）。

两个目标：提高测试覆盖率和提高测试效率。

二、软件测试遵循的原则

1.测试显示缺陷的存在，但不能证明系统不存在缺陷；

2.穷尽测试是不可能的，应设定及时终止的条件；

3.测试应该尽早进行；

4.缺陷具备群集特性（问题越多的模块，越要重点关注）；

5.测试的杀虫剂悖论（即测试方法和用例要不定期的评审和修改，增加不同的测试方法，用例，测试不同的部分，发现更多的错误）；

6.测试的二八原则（测试时间和资源有限，80%的时间用在20%的重要模块中）；

7.测试活动依赖于测试背景（不同测试背景有不同的测试活动）；

三、软件测试有哪些分类，分别是什么概念，有什么样的适用场景

1.按测试阶段分类：

单元测试：对软件中的最小的可测试单元进行检查和验证（对代码的测试，是其他测试的基础）

• 尽可能保证各个测试用例是相互独立的。
• 一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。
• 益处：

1.能尽早发现缺陷。

2.有利于重构【java重构：指程序员对已有程序在尽量不改变接口的前提下，进行重新编写代码的工作，一般有以下几方面：去除已知bug。提高程序运行效率。增加新的功能。重构举例：（简化代码、提升效率）】。

3.简化集成；

4.减少文档的编写（尽可能地减少文档）

5.用于设计

• 限制：

1.不可能覆盖所有的执行路径，所以不可能保证捕捉到多有路径的错误。

2.每一行代码，一般需要3-5行测试代码才能完成单元测试。所以存在投入和产出的一个平衡。

• 单元测试框架：JUnit(Java)，nunit(.net)，PHPUnit(PHP)，CPPUnit(C++)。

集成测试：是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。

• 实施方案：

1.Big Bang：所有的东西组装好之后进行测试

2.自顶向下：从主程序开始，沿控制层逐层向下测试

3.自底向上：从程序最底层开始测试，逐层向上组装逐层进行测试。

好处：针对已经组装过的测试，不需要针对上一层的中央模块，比较好的锁定软件故障的所在位置。

4.核心系统集成：先把核心的软件部分挑选出来进行集成测试，在测试通过的基础上向外围的部件扩展，直到形成稳定的软件产品。

5.高频集成：与开发过程同步，每隔一段时间进行一次测试。

传统开发模式（瀑布开发模式）：自顶向下或自底向上。

敏捷研发方式常用的测试方案：核心系统集成+高频集成。

• 单元测试&集成测试的区别：

1.测试的对象不同：单元测试针对的是软件基本单元进行的测试；集成测试是以模块和子系统为单元进行的测试，主要测试的是模块和模块之间接口的关系。

2.测试的依据不同：单元测试主要针对的是软件的详细设计的测试，测试用例主要的依据是详细设计文档；集成测试主要针对软件的概要设计进行测试，测试用例的主要依据是概要设计。

3.测试的方法不同：单元测试只关心单元的类；集成测试关注集成之间的接口。

系统测试：是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。

• 系统测试一般需要做功能测试、性能测试、稳定性测试等。
• 关注点：关注系统本身的使用，系统与其他相关系统间的连通，系统在不同使用压力下的表现，系统在真是使用环境下的表现。
• 集成测试&系统测试的区别：

1.测试对象不同：集成测试是由通过了单元测试的各个模块所集成起来的构件；系统测试除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统，都是系统测试的对象。

2.测试时间不同：集成测试介于单元测试和系统测试之间测试；系统测试在集成测试之后。

3.测试内容不同：继承测试测试各单元模块之间的接口；系统测试测试的是整个系统的功能和性能。

4.测试角度：集成测试偏于技术角度的验证；系统测试偏于业务角度的验证。

验收测试：也称交付测试。针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，有用户、客户或其他授权机构决定是否接受系统。

• 细分：

用户验收测试：开发方移交产品之前的测试。

运行验收测试：运维层面测试系统能否正常运行和正常维护。

合同和规范验收测试：参照约定的规范进行验收，对政府和法律法规的合规进行验证。

alpha测试：用户在开发者提供的场所和环境中进行测试。

Bate测试：完全脱离开发者的环境，在用户提供的场景下进行测试。

2.按测试手段来分类

按对象可见度分：

黑盒测试：也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

• 优点：

容易实施，不需要关注内部的实现。

更贴近用户的使用角度。

• 缺点：

测试覆盖率较低，一般只能覆盖到代码量的不到40%。

针对黑盒的自动化测试，复用率较低，维护成本较高。

• 主要关注：

是否有不正确或遗漏的功能

在接口上，输入是否能正确的接受，能否输出正确的结果

是够有数据结构错误或外部信息（例如数据文件）访问错误

性能上是否能够满足要求

• 一般用于系统测试
• 主要设计方法：

等价类划分法、边界值分析法、错误推测法、因果图法、正交实验分析法、状态迁移图法、流程分析法

白盒测试：又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。用逻辑覆盖率来衡量测试的完整性。

白盒测试法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。是穷举路径测试。

• 主要的逻辑单位：语句、条件、条件组合、分支、路径。
• 不同的逻辑单位不同的覆盖方法，主要有：

语句覆盖：测试用例设计执行之后，保证程序每条语句至少执行一次。

条件覆盖：覆盖到条件的表达式，所有表达式都至少计算一次。

条件组合覆盖：所有不同条件的组合情况。

分支覆盖/判定覆盖：保证每条分支执行一次，是路径的一部分

路径覆盖：每一条可能的路径至少执行一次。

判定和条件的组合覆盖：

• 优点：

1.迫使测试人员去仔细思考软件的实现，理解原理。

2.可以检测代码中的每条分支和路径。

3.揭示隐藏在代码中的错误。

4.对代码测试比较彻底。

• 缺点：

1.成本高

2.无法检测代码中遗漏的路径和数据敏感性错误。

3.无法直接验证需求正确性。

• 主要测试方法：代码检测法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法。

灰盒测试：介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部之间的表现。

按状态：

静态测试：无须执行被测程序，而是通过评审软件文档或代码，度量程序复杂度，检查软件是否符合编程标准，来发现程序不足之处，减少错误出现的概率。

• 方法：

互审：程序员互相检查。

走查：小组集体检查。

会议：召开会议检查。

• 有些白盒是静态测试。

动态测试：运行被测程序，比较运行结果与预期结果的差异，分析运行效率、正确性、健壮性等。

• 黑盒大部分是动态测试。

按测试执行的方式：

手工测试：由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。

• 更适用于针对深度的测试和强调主观判断的测试。
• 众包测试、探索式测试。
• 优点：容易发现缺陷，容易实施、创造性、灵活性。
• 缺点：不一致性、可靠性低、依赖人力资源、重复测试效率低、覆盖量不容易度量。

自动化测试：用单独的测试工具软件控制测试的自动化执行，并对预期和结果进行自动检查。

• 单元、接口、性能多用该测试。
• 优点：高效率、速度快、高复用性、覆盖量容易度量、准确可靠、工具不易出现疲劳问题。
• 缺点：机械、发现缺陷率低、一次性投入较大。

按测试模式来分类：

瀑布模型：项目计划，需求分析，软件设计，程序开发，软件测试，集成维护。

• 优点和缺点：

优点	缺点
强调需求、设计的作用	难以适应需求的频繁变化
前一阶段完成后，只需关注后续阶段	项目周期后段才能看到成果
为项目提供了按阶段划分的检查点，里程碑清晰	强制的里程碑、完成时间点
文档规范	文档工作量大

V模型：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试

• 优点：强调了软件开发的协作和速度，反映测试活动和分析设计的关系，并且将软件的实现和验证有机结合。明确的界定测试过程是存在不同阶段的，明确了不同测试阶段和研发过程当中每一阶段的对应关系。
• 局限性：仅把测试过程作用在需求分析系统设计和编码之后的阶段、忽视了测试对于需求的分析和验证，对需求和系统设计的验证要到验收测试才能被发现。测试需要尽早的原则没有很好的体现。

W模型：又称双V模型。用户需求（验收测试设计）、需求分析（系统测试设计）、概要设计（集成测试设计）、详细设计（单元测试设计）、编码（单元测试）、集成（集成测试）、实施（系统测试）、交付（验收测试）。

• 优点：增加了软件开发各个阶段中同步进行验证和确认活动，测试伴随着整个开发周期，有利于尽早地发现问题。
• 缺点：需求、设计、编码仍然是串行的，测试和开发保持线性的先后关系，不能很好的支持迭代开发模型。

X模型：针对V模型的改进。主要解决交接和频繁集成的周期问题。定位了探索式测试。

H模型：把软件测试看作完全独立的流程，贯穿整个产品的生命周期，与其他流程（软件开发流程或测试流程）并发进行。分为测试准备和测试执行两个阶段。

敏捷测试：Agile Testing。遵循敏捷宣言的一种测试实践。

• 敏捷宣言：个体与交互重于过程和工具、可用的软件重于完备的文档、客户的协作重于合同谈判、响应变化重于遵循计划。

在每对比较中，后者并非全无价值，但更看重前者。

• 特点：

1.强调从客户角度进行测试。

2.重点关注迭代测试新功能，不再强调测试阶段。

3.尽早测试，不间断测试，具备条件即测试。

4.强调持续反馈。

5.预防缺陷重于发现缺陷。

敏捷测试VS传统测试：

敏捷测试	传统测试
开发和测试人员紧密合作	测试是质量的最后保护者
变更是可接受的，拥抱变更	严格的变更管理
计划随着进展时常调整	预先的计划和细节的准备
只需要绝对必要的文档	重量级文档
各迭代之间已经没有明显的入口和出口标准	各阶段测试严格的入口和出口标准
所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分	更多在回归测试时进行重量级的自动化测试
流程不再需要严格执行	严格依赖流程执行
团队合作是无缝隙合作	测试团队和开发团队是相对独立的

基于脚本的测试：Script-based Testing，Scripted Testing（ST）。先做测试设计，然后执行测试。

• Script在手工测试中指测试用例，在自动化测试中指测试脚本。SBT遵照测试计划，是比较传统的测试。

探索式测试：Exploratory Testing（ET）。完全抛开测试脚本的测试。它是一种测试风格、思维而不是一种测试技术。更加依赖测试人员的责任。

• 测试流程：Know Your Mession（了解测试任务的重点、主要测试方向、系统的环境，有总体的测试思路）、Learning Session（详细的学习和探索被测系统，了解系统的业务逻辑、具体的功能，深入学习被测系统）、Coverage Session（主要实施阶段，要完成主要功能点的测试验收、测试点的覆盖）、Deep Session（进一步的发散式探索测试，挖掘深层次的问题）、Close Session（对前面测试过程的总结，整理测试过程中的信息并根据这些信息分析是否有遗漏）。
• ST和ET是结合使用的。但从不同的实施方式上来说，ST和ET的应用程度是不同的，根据项目本身特点确定使用何种实施方式。

Pure Scripted是完全的ST按照测试用例进行测试；

Vague Scripted会编写测试用例，但比较模糊；

Fragmentary test cases测试用例不会正式的归为文档；

Charters会列出详细的任务列表，在列表中指出测试对象，测试策略，并指出可能的风险、参考的文档；

Roles给测试人员一个独立的角色，从角色出发测试产品，测试进度、测试的质量都是由测试人员自己掌握；

Freestyle ET是完全自由的测试，没有任何文档做支撑，不对测试要点进行记录。

• 优点和缺点

优点	缺点
更能激发测试人员的创造性和工作乐趣	测试管理上有局限性，较难协调和控制
增加了发现新的或较深入Bug的可能性	对于Bug的重复利用和重复上作用有限
在较短时间内找到更多Bug以及对SUT（被测系统）做一个快速的评估	对测试人员的测试技能和业务知识深度依赖较大
有利于更加有效的实施自动化	只有在SUT（被测系统）已完全可用的前提下才更有作用
更加适用于敏捷项目	ET的生产率很难定义
减少了在简单、繁复上用例的无谓编写时间	ET本身较难进行自动化

• ET测试方法：

局部探索式测试：

输入：基本任务包括接受输入、产生输出、存储数据、进行运算；测试时一般从测试顺序、输出内容、输出异常几个角度考虑测试要点；

状态：临时状态（运行时有效，阶段有效）、永久状态（数据库保存、文件保存），有效判断测试的输入和输出；

代码路径：对代码的覆盖（白盒测试的覆盖方法）；

用户数据：模拟真实数据；

执行环境：软件运行的操作系统、系统组网的网络拓扑、与系统交互的第三方系统、系统的配置数据、运行系统的硬件设备等；

全局探索式测试：（漫游测试法）把被测系统根据不同的属性分成不同的区域进行针对性测试。

商业区：指软件从启动到关闭之间，用户可能主要使用到的功能；

旅馆区：软件在休息或没有在实际运行时的功能，一般指运行在后台的进程或任务；

历史区：软件版本的历史遗留代码中的功能或者是在以前的测试中发现较多问题的功能；

旅游区：新用户会使用或关注的功能；

娱乐区：系统主要功能之外的一些辅助的特性及功能；

破旧区：系统已经废弃或隐藏的，用户看不到的功能。

对应区域由不同的测试方法，例如指南测试法、麻烦测试法、懒汉测试法、恶灵测试法、伸向测试法、破坏测试法等

• ST和ET对比：

ST	ET
系统性强，是按照需求文档详细的设计的	自由灵活，更多的是强调测试人员的主观性和创造性
容易管理、控制	和ST是互补的
设计在先，执行在后	执行和设计（思考）并行
主要是验证自己的思路	不断和系统交互，带着问题测试
可预见性	学习的过程

基于风险的测试：Risk-based Testing（RBT）。一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型。

• 风险：

质量风险：被测系统本身的质量问题，例如软件的功能、应用性能、软件功能的缺失、数据的转换等；

管理风险：人员技能不足、人力不足、测试环境不具备、被测系统需求不清晰、被测系统关联的第三方系统有问题等；

• 风险级别 = 风险可能性 * 风险严重度
• 风险要素分 = Sum（单项权重 * 得分）
• 识别风险：

可能性：复杂性、时间压力、高变更率、技能水平、地理分散度

严重程度：使用频率、失效可视性、商业损失、组织负面影响和损害、社会损失和法律责任

基于模型的测试：model-based testing（MBT）。根据需求建模，借助工具建模然后执行，偏向于自动化测试。

• 主要的MBT工具：Spec Explorer（Microsoft）、GrabphWalker、Tcases、modeljunit等

按测试类型分类：

功能测试：根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作性为已确定它们满足设计需求。

• 软件测试中最主要的测试类型。
• 针对的问题：功能错误或遗漏、界面问题（缺陷清单中占比很大的错误类型）、性能错误、数据及访问错误初始化及终止错误。
• 功能测试工具：

商用：QTP（web应用系统，基于关键字驱动）、 winrunner（桌面软件）、silkTest、Rational robot

开源：selenium（web应用系统，敏捷）、Watir（web应用自动化测试）、Sikuli（基于屏幕截图）

性能测试：验证软件系统的性能可以满足系统规格给定的指标要求。

负载测试：测试过程中逐步增加负载，并且记录下系统相应的性能表现，并最终确定系统在正常指标下的最大负载。

压力测试：测试系统在极限情况下的压力情况。即在负载压力下系统不能运行，所能承受的极限是多少。

稳定性测试：一般是稍大于正常业务量的负载对系统进行持续的长时间的测试，确定系统稳定性情况。

• 性能指标：web应用：并发用户数VU，每秒事务数TPS、系统响应时间、设备性能

• 自动化测试工具：LoadRunner、Silkperformer、Jmeter、WebLoad、Apache Bench、LoadUI（接口性能的测试）

• 静态性能评估：开发Web应用时，基于一系列Web应用页面性能优化的最佳实践，对Web应用的页面进行静态分析，并给出评估结果的性能分析方法（基于web代码）。工具有YSlow、PageSpeed。都是浏览器插件，评级静态网页的标准有14个，减少HTTP请求之类的。

• 应用性能管理（APM:Application performance Management）：提供对系统的实时监控以实现性能管理、故障管理的解决方案。比如听云。

部署测试：又称安装测试，主要验证系统部署过程，并确保软件经过安装测试后可以正常使用。一般是软件进行测试的第一个步骤，是建立测试环境的基础。

• 主要测试内容：在不同环境下的部署验证；参照部署文档执行，部署过程的合理、正确性；准备软件环境的基础数据（重要）。

文档测试：针对软件产品的交付品，配套的文档类部件的测试。如用户手册、使用说明、用户帮助文档等。

• 要点：完整性（文档内容是否齐全）、正确性（文档编写是否有错误）、一致性（文档相同部分内容是否不一致）、易理解性（是否容易理解，读懂）、易浏览性（文档结构便于浏览）。

安全测试：对软件产品进行测试以确保其符合产品安全需求和质量标准。

渗透测试：通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试，与黑客不同于，黑客未授权，而且最后还会抹掉记录。

• 安全测试 VS 渗透测试

安全测试（要掌握的知识多，较困难一些）	渗透测试
着重点在防御，对整个系统防御的功能进行测试	着重点在攻击，目的是攻破软件系统，证明系统存在问题
从整个防御面上考虑	选择一个薄弱点攻击系统，达到攻破系统的目的

• OWASP（Open Web Application Security Project）：针对web应用安全的项目。它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。重要栏目有Top 10，Testing Guide。
• 安全测试工具：Appscan（IBM，web漏洞扫描）、Webinspect（惠普，与Appscan功能相似）、Nessus（服务器主机类漏洞扫描）、Nmap（端口嗅探工具，扫描主机开放端口）、MetaSploit（攻击框架，包含大量插件，对目标系统进行检测和渗透测试）、WebScarab（OWASP提供，基于代理劫持的分析进行攻击路径的检测）、Fortify（惠普，白盒测试工具，分析源代码中可能存在的问题）、W3AF（开源漏洞扫描工具，针对web应用）。

兼容性测试：

• 软件本身的兼容性：软件的向后兼容。兼容以往的历史版本配置数据等。
• 不同平台下的兼容性：软件可以运行在不同的平台下。
• 软件对运行设备的兼容性：软件可以运行在不同的设备上。
• 软件互操作性：软件内部不同功能操作是否兼容、与其他软件是否兼容。

针对Web应用：浏览器兼容性，浏览器内核不同。

浏览器兼容性测试工具：BrowserShots（该网站输入url值，可以看不同平台下的显示）、Browser Sandbox（使用不同插件实现测试）、Google浏览器兼容性测试插件（http://www.w3help.org/）（从页面代码层面进行分析，通过不同浏览器的内核来判断代码对浏览器不同内核的兼容情况，给出分析的建议）。

易用性测试：测试用户使用软件时是否感觉方便、是否能保证用户使用体验。针对用户交互界面的测试。

本地化测试：针对软件的本地化版本实施的针对性测试。即针对不同地区用户提出的差异化的版本。

• 测试的主要内容：语言、书写习惯；时区、日期格式、货币；当地风俗、法律法规；政治敏感内容。

无障碍测试：Accessibility Test。也称可访问性测试。是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试。

可靠性测试：分软件可靠性和硬件可靠性，更多的是测试硬件可靠性。

• 软件可靠性：软件系统在规定的时间内，已经规定的环境条件下，能够完成规定功能的能力。一般是对软件系统进行可靠性测试来度量软件的可靠性。
• 硬件可靠性：硬件产品在设计应用过程中受气候环境及机械环境的影响能否正常工作。

其他测试类型：

回归测试：软件功能修改后，对软件进行重新测试，以确认修改没有引入新的错误或导致其他部分产生错误。

• 回归测试的重心在关键模块和重点功能组件。
• 软件研发周期中会进行多次回归测试，且尽量实现自动化。

冒烟测试：来自于硬件板卡验证术语。

• 软件上则用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。类似于回归测试，但是测试的注重点不同，冒烟测试针对业务流程的测试，回归测试根据具体的功能模块分别进行测试。
• 敏捷开发的“每日构建”中用冒烟测试来确认合入的代码没有影响主要功能的正常。

Monkey测试：搞怪测试。就是用一些随机、稀奇古怪的方式来操作软件，以测试系统的健壮性和稳定性。

AB测试：（非常常用）：多用于互联网行业，通过为页面提供2个版本给用户使用并记录相关的用户行为数据，来确定更优化设计。

• 实施要点：

多个方案并行：用户达到一定数量，保证统计结果的有效性，结合回台发布、动态配置等技术实现。

每次测试仅改动一个变量：变量唯一，根据改动的变量确定用户行为的差异。

按照某种规则进行优胜劣汰：确定评判的标准。

• 测试工具：Google Analytics Content Experiments、Visual Website Optimizer