软件测试的基础
第一章
软件（理解）：一系列按照特定顺序组织的计算机数据和指令的集合程序+数据+文件。
产品（理解）：能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组织。
项目：指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。
什么是软件测试：
软件测试的分类：1.功能测试
2.性能测试
软件测试的定义：
软件测试的发展史：
为什么做软件测试：
软件bug实例：
软件测试任职要求：
第二章 软件生命周期
软件生命周期：
1.需求调研阶段
2.需求分析阶段
3.设计阶段（输出概要设计和详细设计的文档）
4.开发阶段
5.测试阶段
6.发布上线
7.运维（产品支持）：用于解决产品使用过程中出现的问题，提供技术支持。
8.下线
第三章 项目组成员
项目组成员：
第四章 测试的基本原则
测试的基本原则：
1.测试是上下文相关的
（对于不同的软件，测试的强度是不一样的）
2.穷尽测试时不可能的
（不可能把软件所有的操作都测试一遍）
3.测试尽早介入
（从需求阶段开始测试，从需求文档本身开始测试，使测试人员尽早介入需求，降低成本）
4.杀虫剂悖论
（软件的每一个版本都使用了相同的用例，不会再发现新的BUG，测试用例需要根据实际版本需要进行维护、增加）
5.缺陷群集性
（80%的缺陷存在20%的模块中，当一个模块存在BUG，可能会存在其他的BUG）
6.测试证明存在缺陷
（即使被发现的BUG都被修复了，还是有可能存在其他的BUG）
7.无错谬误
（软件都有可能存在缺陷）
软件测试的对象：
1.程序
2.数据
3.文档
第五章 软件开发模型
研发模型---瀑布型（早期模型）：
（每一个阶段的工作都是上一个阶段完成之后进行的，瀑布模型对每一个阶段输出的文档要求非常高）
（缺点：测试是在后期进行，如果发现需求有问题，维护成本很高）
研发模型---原型：
demo：原型图
（通过原型图，提前跟客户确认；在需求分析阶段可以在原型图中体现工作完成的样子；对原型图要求很高；一旦完成工作后，原型图就没有存在的价值，原型图需要人力、资源去完成；对每一个阶段文档输出没有瀑布模型那么高；特点：后期维护成本很高）
研发模型---敏捷模型：
敏捷开发是一种以人为核心、迭代、循序渐进的开发模型。
(先确定需要迭代的功能列表，进过2-4周的迭代开发，完成功能列表)
研发模型---其它模型：
第六章 软件测试模型
测试模型---V模型（早期模型）：
（单元测试是由开发人员本身完成；集成测试关注的是功能；系统测试不仅关注功能，还会关注非功能的测试；验收测试是由用户需求进行的）
优点：既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。
局限性：把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，不能体现“尽早地和不断地进行软件测试”的原则。
测试模型---W模型（使用较多）：
（如果有新需求的增加或变更，通常会停止测试）
优点：
1.如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。
2.测试者可以在项目中尽可能早地面对规格说明书中的挑战。
3.测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。
局限性：无法支持迭代、自发性以及变更调整。
测试模型---H模型（了解）：
测试模型---X模型（了解）：
第七章 软件测试阶段
需求测试
返工：70%~85%由于需求
重点：检查需求规格说明书SRS：
1.完整性
2.正确性
3.一致性
4.可行性
5.无二义性
6.健壮性
7.必要性
8.可测试性
9.可修改性
这三个测试可能交叉与前后互换：
（根据实际的业务确认软件是否正常）
单元测试
单元：函数、类
单元测试是针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作。
单元测试的目的是检测软件模块对《详细设计说明书》LLD的符合程度。
集成测试
集成测试是对单元之间及单元与第三方接口之间的测试，目的是验证接口是否与设计相符，是否与需求相符。（即检测软件模块对《概要设计说明书》的负荷程度）
集成策略：自底向上或自顶向下、渐增式
（自底向上：驱动模块
自顶向下：桩模块模拟的是被调用的模块，只保证代码格式满足要求即可）
系统测试
系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作。
系统测试的目的在于通过与《需求规格说明书》作比较，发现软件与系统需求定义不符合或与之矛盾的地方。
确认测试
又称为有效性测试，它的任务是验证软件的有效性，即验证软件的功能和性能及其他特性是否与用户的要求一致。
验收测试
交付用户部署前，进行验收测试
以用户为主，验收组：项目组成员、用户代表或者系统的其他利益相关者。
根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试。
Alpha测试和Beta测试
Alpha：内部，模拟/真实
Beta：外部，真实
UAT测试
User Acceptance Test：用户接受度测试
它是用于验证系统的可用性。
回归测试
回归测试（Regression Testing)：软件在测试或其他活动中发现的缺陷经过修改后进行的测试。目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。
回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试。
回归测试策略：
1.完全重复测试：
重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性。
2.选择性重复测试：
即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序。
选择性重复测试：
1.覆盖修改法
即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。
2.周边影响法（使用较多）
该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点。
3.指标达成法
这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择宇哥最小的测试用例集合。
回归测试流程
以下流程适合于单元测试、集成测试和系统测试：
回归测试自动化：
冒烟测试
它可以理解为该种测试耗时短，仅用一袋烟功夫足够了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
冒烟测试的执行者是版本编译人员。
第十章 软件测试质量
质量：
软件质量：
他是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。
软件质量的属性：
质量属性的分类：
1.功能性
2.非功能性
质量模型：一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础。
软件测试与QA的区别
1.从性质上看：
测试属于技术的工作
QA属于管理的工作
2.从对象上看：
测试的对象是软件研发产品，大多数工作是对研发领域的检验
QA的对象是整个软件过程，覆盖各个领域
3.从手段上看：
测试以事后检查为主
QA强调的是缺陷预防
QA：quality assurance（质量保证）
QC：quality control（质量控制）
QM：quality manage（质量管理）
质量保证活动与软件测试的关系
第八章 软件测试类型
功能测试
概念：
功能测试是根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格。
目标：
性能测试
性能测试就是用来测试软件在集成系统中的运行性能的。
目标是度量系统相对于预定义目标的差距。
性能测试收集的信息：
负载测试
负载测试是超过被测对象标准性能负荷指标下，验证系统的负载承受能力。并要求超负荷情况下，依然正常实现业务功能。
负载测试是通过不断对被测对象施加负荷，观察被测对象在不同负载下的性能表现。
压力测试
压力测试的目的是调查系统在其资源超负荷的情况下的表现。尤其感兴趣的是这些对系统的处理时间有什么影响。这类测试在一种需要反常数量、频率或资源的方式下执行系统。
目标：
通过极限测试方法，发现系统在极限或恶劣环境中自我保护能力。主要验证系统的可靠性，找到系统薄弱环节。
容量测试
容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。
容量测试是面对数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
安全性测试
安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。用来保证系统本身数据的完整性和保密性。如当收到恶意攻击时，设备的自我保护能力，病毒防护能力，自定义通信协议安全性等。广义的还包括物理安全性测试、业务安全性测试。
安全性测试内容：
一般可以从以下方面考虑安全性测试：
1.系统的登录
2.用户管理
3.防火墙
4.系统数据
5.WEB安全性，如WEB的加密，解密，数字签名等
6.数据库的安全性
7.内部通信协议
8.系统防病毒测试
GUI测试
GUI测试是针对软件系统GUI界面进行的测试。
GUI测试主要包括两方面的内容：
1.界面实现与界面设计的吻合情况。
2.确认界面处理的正确性。
GUI测试对象：
1.简单界面元素：指功能能和属性相对比较单一的界面区域，即通常所指的各种控件
2.组合类界面元素：主要指一些复杂的界面元素，比如工具栏、组合框、表格、菜单栏等
3.完整界面（窗口）：由一系列界面元素通过适当的形式组合而成的界面形式，最为常见的为各种窗口。包括各种对话框、单文档窗口、多文档窗口、多文档子窗口等
可用性测试
可用性测试是为了检测用户在理解和使用系统方面到底有多好。考虑产品是否符合实际应用情况，是否符合用户习惯或特殊要求，操作方式是否方便合理、设备和用户间的交互信息是否准确易于理解、是否遵从行业习惯、外观/界面是否美观等。应设计到所有和用户有交互的功能或子系统。这包括系统功能、系统发布、帮助文本和过程，以保证用户能够舒适地和系统交互。
安装卸载测试
定义：
系统的可安装性测试，主要是根据软件的测试特性列表、软件安装、配置文档，设计安装过程的测试用例，发现软件在安装过程中的错误。
目的：
系统可安装性测试的目的不仅是找安装软件本身的错误，而且还要找安装文档的错误。在安装软件系统时，会有多种选择，要分配和装入文件与程序，布置适当的配置，进行程序的联结。而安装测试就是找出这些安装过程中出现的错误。
异常测试
概念：
系统异常测试又叫系统容错和可恢复性测试，它是通过人工干预手段使系统产生软、硬件异常，通过验证系统异常前后的功能和运行状态，达成检验系统的容错、排错和恢复的能力。它是系统可靠性评价的重要手段。
容错处理：
1.系统自动处理
2.人工干预处理
文档测试
文档测试的目标是验证用户文档是正确的并且保证操作手册的过程能够正确工作。
网络测试（接口测试）
概念：
网络测试是在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常。
稳定性测试
兼容性测试
兼容性测试验证被测对象与硬件、其他软件之间的兼容情况。
测试的分类：
1.黑盒测试和白盒测试、灰盒测试
2.静态测试和动态测试
3.人工测试和自动化测试
软件测试的两种极端情况：
什么是白盒测试
白盒测试是依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况。
白盒测试是基于程序结构的逻辑驱动测试。
白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试。
白盒测试示意图
（白盒测试需要读懂代码，并准备代码所需要的输入）
为什么要进行白盒测试
白盒测试一般在测试前期进行，通过达到一定的逻辑覆盖率指标，使得软件内部逻辑控制结构上的问题能基本得到消除。
白盒测试能保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证
白盒测试发现问题后解决问题的成本较低。
白盒测试的常用技术：
1.静态分析：控制流分析、数据流分析、信息流分析等
2.动态分析：逻辑覆盖测试（分支测试、路径测试等）、程序插装等
语句覆盖：设计出来的测试用例要保证程序中的每一个语句至少被执行一次。
判定覆盖：设计的测试用例要保证被测程序每一个分支至少被执行一次。
条件覆盖：要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值，即每个条件至少有一次真值，有一次假值。
判定条件覆盖：使得判定中每个条件所有的可能取值至少执行一次，同事每个判断本身所有的结果也要至少执行一次。
组合覆盖：设计的测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。
路径覆盖：设计的测试用例可以覆盖程序中所有可能的执行路径。
什么是黑盒测试
黑盒测试把被测对象看成一个黑盒，只考虑其整体特性，不考虑其内部具体实现。
黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块、一个函数等。
黑盒测试又可以被称为基于规格的测试。
黑盒测试示意图
常见的黑盒测试类型
1.功能性测试：一种是顺序测试每个程序特征或功能，另一种途径是一个模块一个模块的测试，即每个功能在其最先调用的地方呗测试
2.容量测试：检测软件在处理海量数据时的局限性，能发现系统效率方面的问题
3.负载测试：检测系统在一个很短时间内处理一个巨大的数据量或执行许多功能调用上的能力
4.恢复性测试：主要保证系统在崩溃后能够恢复外部数据的能力
黑盒测试的特点
1.对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率要高。
2.测试人员不需要了解实际的细节，包括特定的编程语言
3.从用户的视角进行测试，很容易被大家理解和接受
4.有助于暴露任何规格不一致或有歧义的问题
灰盒测试
1.根据利用的被测对象信息的不同，会采用不同的方式进行测试。
2.利用被测对象的整体特性信息，采用黑盒测试方法。
3.利用被测对象的内部具体实现信息，采用白盒测试方法。
4.如果既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，采用的就是灰盒测试方法。两种信息占的比例不同，相应的灰度就不同。完全是整体特性信息，就是黑盒测试，完全是内部具体实现信息，就是白盒测试。
5.典型的灰盒测试比如集成测试和系统测试时借助log信息。
静态测试和动态测试
静态测试：不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。例如：代码走读、文档评审、程序分析等都是金泰测试的范畴。常用技术有静态分析技术。
动态测试：按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件西戎进行检测的一种测试技术。常用技术有动态分析技术。
静态分析技术
定义：静态分析是一种不通过执行程序而分析程序执行的技术
功能：检查软件的表示和描述是否一致，没有冲突或者没有歧义，它瞄准的是纠结软件系统在描述、表示和规格上的错误，因此是任何进一步测试执行的前提。
主要有三种不同的程序测试可能性：
1.考虑程序是否满足编码规则，语法上是否具有一致性和完整性
2.考虑文档描述是否规范、准确、便于查阅
3.考虑程序和文档之间的一致性
人工和自动化测试
人工测试：测试活动（如评审、测试设计、测试执行等）由人来完成，狭义上是指测试执行由人工完成，这是最基本的测试形式。
自动化测试：一般是指通过计算机模拟人的测试行为，替代人的测试活动，狭义上是指测试执行由计算机来完成。
自动化测试的意义
1.对程序新版本运行前一版本执行的测试，提高回归测试效率
2.可以运行更多更频繁的测试，比如冒烟测试
3.可以执行手工测试困难或不可能做的测试，比如大量的重复操作或者集成测试。
4.更好地利用资源，比如测试仪器或者被测对象
自动化测试的限制
1.不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即不可能发现更多缺陷。
2.手工测试比自动测试发现的缺陷更多
3.对测试设计依赖性极大，测试设计的不好会遗漏问题
4.自动化测试对软件开发具有很大的依赖性，开发商出现变更更可能导致前面的自动化测试完全失效
5.工具本身并不具备想象力，工具不具有智能。
第九章 软件测试流程
软件测试流程
1.测试计划阶段-测试计划
2.测试设计阶段-测试方案
3.测试实现阶段-测试用例、测试规程（规定了每一个测试人员具体的工作流程）
4.测试执行-测试报告
主要的测试文档
1.测试计划
2.测试方案
3.测试用例
4.测试规章
5.测试报告
6.测试日报
系统测试过程与开发阶段
系统测试各阶段的输入、输出
测试工程师系统测试各阶段任务（需要记忆）
软件需求阶段：评审软件需求规格说明书
软件设计阶段：评审软件概要设计说明书、软甲你详细设计说明书、协助编写系统测试计划
软件编码阶段：设计系统测试用例、准备测试资源（测试工具、测试环境等）、开发测试脚本、开发测试工具、准备测试数据
软件测试阶段：执行测试用例、提交缺陷单、跟踪缺陷、回归测试、提交测试报告