敏捷测试：

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

2. 重点关注迭代测试的功能，不在强调测试阶段

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

4. 强调持续反馈

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

传统的瀑布模型：它的每一个阶段都是以他上一个阶段的输出作为下一个阶段的输入。

优点：强调需求和设计。前一阶段完成后只需关注后一阶段。按阶段划分检查点，里程碑清晰。文档规范。

缺点：难以适应频发地需求变动。项目周期后段才能看到成果。文档工作量大

V模型：明确地界定了不同的测试阶段。局限性：仅仅把测试过程作为在各个阶段的后期的工作，忽视了测试对于需求的分析和验证，对于测试要尽早进行的这个原则没有很好的体现。

W模型：有利于及时的了解项目的测试风险来及早地设计测试的应对方案，加快项目的进度。局限性：需求、设计、编码仍然是串行的。呈线性关系。不能很好地支持像迭代这样的开发模型。

测试分类如果按测试手段分：（一黑一白，两动两静）

黑盒测试、白盒测试

静态测试、动态测试

手工测试、自动化测试

黑盒测试：着眼于程序的外部结构，不考虑内部的逻辑（一般来说针对界面和可见的功能测试），在适当的输入下能否有正确的输出。

黑盒测试主要测试什么？

a.功能是否正确或者有遗漏

b.接口上，输入是否能正确接收，输出结果是否正确

c.是否有数据结构错误或外部信息访问错误

d.性能上是否满足

黑盒测试的主要设计方法：

等价类划分法，边界值分析法，因果图法，判定表法，错误推断法等

白盒测试：又称结构化测试，对测试人员来说是透明的，针对程序的逻辑结构来设计测试用例，用逻辑的覆盖率来衡量测试的完整性。

静态测试：是指无需执行被测程序，而是通过评审软件文档或代码，度量程序静态静态复杂度，检查软件是否符合标准，借以发现编写的程序不足之处，减少错误出现的概率。 方式有：互审、走查、会议

动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等。

测试类型如果按测试阶段分：

单元测试，集成测试，系统测试，验收测试

单元测试流程：（尽量保持测试的相互独立，比如登陆中密码的提取不要用数据库的）

打开eclipse，创建工程，右键Properties，build path然后add library,然后导入JUnit包，导入一个。java文件夹，右键创建一个JUnit Test，可选择一些方法，一般选择setUp（）【开始时的动作】和tearDown（）【结束时动作】，随后选择待测方法

单元测试与集成测试的区别：

a.测试对象不同（单元：针对软件的最小单元；集成：针对模块与子系统，主要测试模块与模块间的接口）

b.测试依据不同（单元：针对软件的详细设计；集成：针对软件的概要设计）

c。测试方法不同（单元：关心单元的内部；集成：关系模块间的接口）

系统测试：在集成测试的基础上，对系统在实际运行环境下进行测试（一般有性能测试，功能测试，稳定性测试等多种测试类型。）

集成测试和系统测试的区别：

测试对象不同（集成测试是通过了单元测试的各个模块所集成起来的构件；系统测试；系统测试是除了软件以外，还包括计算机硬件及相关的外围设备、数据采集和传输机构等整个软件）

测试时间不同

测试内容不同（集成：各个单元模块之间的接口；系统：整个系统的功能和性能）

测试角度不同（集成偏向技术验证；系统偏向业务验证）

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

软件测试的分类

安测试手段来分

黑盒测试、白盒测试

静态测试、动态测试（按状态）

手工测试、自动化测试（按测试执行的方式）

黑盒测试

输入 输出 用户需求 事件驱动

黑盒测试的优缺点

优点：

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

2.更贴近用户的使用角度

缺点：

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

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

黑盒测试主要测试什么

1.是否有不正确或者遗漏的功能?

2.在接口上,输入是否能正确的接受?能否输出正确的结果?

3.是否有数据结构错误或者外部信息(例如数据文件)访问错误?

4.性能上是否能够满足要求?(重要方面)

系统测试阶段更多的运用黑盒测试

黑盒测试的主要设计方法

1.等价类划分法

2.边界值分析法

3.错误推测法

4.因果图法

5.正交试验分析法

6.状态迁移图法

7.流程分析法

白盒测试 透明盒测试 结构化测试

针对逻辑结构设计测试用例

主要的逻辑单位:

语句 语句覆盖 每条语句至少执行一次

条件 条件覆盖 每个判定至少执行一次

条件组合 

分支

路径

白盒测试的优缺点

优点:

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

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

3.解释隐藏在代码中的错误

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

缺点:

1.昂贵

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

3.不能直接验证需求的正确性

白盒测试的主要测试方法

1.代码检测法

2.静态结构分析法

3.静态质量度量法

4.逻辑覆盖法

5.基本路径测试法(主要测试法)

灰盒测试

介于黑/白盒测试之间的,关注输出对于输入的正确性,同时也关注系统内部表现

静态测试定义

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

静态测试方法

互审

走查

会议

动态测试定义

动态测试是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率/正确性和健壮性等

黑盒测试主要是动态测试的方法

手工测试

由专门的测试人员从用户视角来验证软件是否满足设计要求的行为,更适用针对深度的测试和强调主观判断的测试

众包测试/探索性测试

自动化测试

使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查

单元测试/接口测试/性能测试等

手工测试vs自动化测试

手工测试

优点

1.容易发现缺陷

2.容易实施

3.创造性/灵活性

缺点

1.覆盖量化难

2.重复测试效率低

3.不一致性/可靠性低

4.人力资源依赖

自动化测试

优点

1.高效率/速度快

2.高复用性

3.覆盖率容易度量

4.准确/可靠

5.不知疲劳

缺点

1.机械/发现缺陷率低

2.一次性投入较大 自动化测试工具的选型 框架的设计 自动化脚本的编写与维护

软件测试的分类：

按测试阶段来分类：单元测试、集成测试、系统测试、验收测试。

单元测试

什么是单元测试？

对软件中的最小可测试单元进行检查和验证。

单元测试的原则：

1. 尽可能保证各个测试用例是互相独立的。

2. 一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。

单元测试的益处：

1. 能尽早发现缺陷

2. 有利于重构

3. 简化集成

4. 文档

5. 用于设计

单元测试的限制

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

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

单元测试框架

Xunit

JUnit、nunit、CPPUnit、PHPUnit

集成测试定义：

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

集成测试的主要实施方案

1. Big Bang

2. 自顶向下

3. 自底向上

4. 核心系统集成

5. 高频集成
   

2/3瀑布式研发常用。4/5敏捷型研发常用。

集成测试&单元测试

1. 测试的对象不同

2. 测试的依据不同 单元 详细设计  集成  概要设计

3. 测试的方法不同 单元 注重单元内部  集成 注重接口之间

系统测试定义：

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

单元、集成测试更多用模拟的方法测试，系统测试是在真实运行环境中测试。

系统测试中包含功能测试、性能测试、稳定性测试。

关注点

关注系统本身的使用

关注系统与其他相关系统间的连通

关注系统在不同使用压力下的表现

关注系统在真实使用环境下的表现

系统测试&集成测试

测试对象

集成测试：由通过了单元测的各个模块所集成起来的构件

系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统

测试时间

集成测试介于单元测试和系统测试之间测试

系统测试在集成测试之后

测试内容

集成测试：各个单元模块之间的接口

系统测试：整个系统的功能和性能

测试角度

集成测试：偏于技术角度的验证

系统测试：偏于业务角度的验证

验收测试（交付测试）定义：

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

 细分

用户验收测试

运行验收测试

合同和规范验收测试

alpha测试  开发者的环境

beta测试  真实的用户环境

什么是软件测试？

早期定义：软件测试时对程序能够按预期运行建立起的一种信心。

经典定义：测试时为发现错误而执行程序的过程。

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

软件的测试对象：软件的概要设计、软件详细设计、软件运行环境、可运行程序、软件源代码、软件需求。

五大要素和两个目标：质量（核心）、人员、资源、流程、技术要素；测试覆盖率、测试效率目标。

ISTQB

软件测试所遵循的原则：

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

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

3. 测试应该尽早进行。

4. 缺陷具备群集特性。

5. 测试的杀虫剂悖论。

6. 测试的二八原则。

7. 测试活动依赖于测试背景。

了解软件测试的含义

软件测试遵循的准则

软件测试有哪些分类？分别是什么概念

何时开始测试？测试方案如何设计？

测试流程是怎么样的？怎么提BUG？怎么写报告？

为什么要做自动化？怎么做？

按测试阶段分类

  单元测试：最小可测试单元 

    原则：尽量保证各个测试用例相互独立；一般由代码开发人员实施；

    益处：尽早发现缺陷（TDD）；有利于重构；简化集成；文档；用于设计

    限制：难以覆盖所有执行路径；代码量上需要投入和产出之间寻找一个平衡；

单元测试框架

  集成测试 ：单元测试的基础上，完成测试的单元组装成子模块，测试这个集成是否达到要求，测试对象为单元接口

         实施方案：1.Big bang  2.自顶向下  （主程序-控制层逐层向下） 3.自底向上（常用基础）  4.核心系统集成     5.高频集成（同步开发过程）

单元测试&集成测试：测试对象不同、测试依据不同（详细设计/概要设计）、测试方法不同

系统测试：完成集成测试的软件，作为部分，与系统中的其他部分，实际运行环境下，进行的测试。（功能测试，性能测试，稳定性测试等）

       关注点：本身的使用，系统间的联通，不同压力下的表现，真实使用环境下的表现

集成测试&系统测试：测试对象不同、测试时间先后、测试内容、测试角度（技术和业务）

 验收测试（又称交付测试，确定系统是否满足验收标准，能否被客户接受）

细分：用户验收；运行验收（运行备份维护）；合同和规范验收；alpha；beta? ；----?验收测试驱动开发

敏捷测试

敏捷宣言：

个体与交互  重于 过程和工具

可用的软件  重于 完备的文档

客户协作  重于  合同谈判

响应变化  重于  遵循计划

敏捷测试的特点： 强调从客户角度进行测试；重点关注迭代测试新测试，不在强调测试阶段 ；早测试，不间断测试，具备条件即测试 ；调持续反馈 ；防缺陷重于发现缺陷 

敏捷测试VS传统测试 

传统测试： 测试是质量的最后保护者； 严格的变更管理； 预先的计划和细节的准备； 重量级文档 各阶段测试严格的入口和出口标准； 更多在回归测试时进行重量级的自动化测试； 严格依赖流程执行； 测试团队和开发团队是相对独立的 

敏捷测试： 开发和测试人员是紧密合作，大家都有责任对软件负责； 变更是可接受的，拥抱变更； 计划随着进展时常调整； 只需要绝对必要的文档； 各迭代之间已经没有明显的入口和出口标准； 所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分； 流程不再需要严格执行； 团队合作是无缝隙合作

基于脚本的测试-ST

scripted testing

script-based testing<br> 

Exploratory testing（ET）：探索式测试，完全抛开测试脚本测试的测试，跟ST/SBT相对应的。带着问题去使用产品，探索式去挖掘。

ET是一种测试风格、思维，而不是一种测试技术。

Pure Scripted-VagueScripted-Fragmentary test cases-Charters-Roles-Freestyle ET

ST：系统性强；容易管理，控制；设计在先，执行在后；主要是验证自己的思路；可预见性 

ET：自由灵活；与ST是互补的，执行和设计并行；不断和系统交互，带着问题测试；学习的过程（重在测试人员） 

探索式测试的优点：更能激发测试人员的创造性和工作乐趣；增加了发现新的或较深入的bug的可能性；在较短时间内找到更多的bug以及对SUT（被测程序）作一个快速的评估；有利于更加有效的实施自动化；更加适用于敏捷项目；减少了在简单，繁复上用例的无谓编写时间 

缺点：测试管理上有局限性，较难协调和控制；对于bug的重复利用和重现上作用有限；对测试人员的测试技能和业务知识深度要求高；只有在SUT（system under test）一完全可用的前提下才更有作用；ET的生产率很难定义；ET本身较难进行自动化 

局部探索式测试：输入；状态；代码路径；用户数据；执行环境 

全局探索式测试：漫游测试法（商业，旅馆，历史，旅游，娱乐，破旧）

执行探索式测试：了解整体，深入学习，测试实施，发散式测试，总结整理分析（---大扫除阶段）

基于风险测试-RBT 

风险：质量风险（软件功能，性能，软件代码缺失）；管理风险（人员能力不足，环境风险） 

识别风险：

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

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

风险要素分=sum（单项权重*得分）

RBT的优点：参考图像（测试工作量-风险、测试完成率-质量信心）

基于模型的测试-MBT：它的测试用例是从一个模型中导出所得，这个模型描述了被测系统的某些方面，通常是功能部分。 

模型：对需求功能点建模 https://blogs.msdn.microsoft.com/sechina/2009/11/18/123/

更偏向于借助MBT?工具的自动化测试

按测试模式分类：瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。 

（传统的）瀑布模型：项目计划（项目计划书）->需求分析（需求说明书）->软件设计（概要设计、详细设计等）->程序开发（产品）->软件测试（测试文档）->集成维护 

     优点：强调需求；前一阶段完成后只需关注后续阶段；提供按阶段划分的检查点；文档规范 

     缺点：难以适应需求的频繁变化；项目周期后段才可看到成果；较关注时间节点；文档工作量较大；测试在项目的后期，补救，工作量大

V模型（最广泛） 需求分析->概要设计->详细设计->软件编码->单元测试->集成测试->系统测试->验收测试 

     缺点：也没能体现出测试需要尽早进行的原则 

W模型（双V模型） 开发与测试并行，可以尽早发现问题 

     局限性：需求、设计、编码仍然是串行进行的，上一个阶段完成之后才能进行下一个阶段 

X模型:解决交接和频繁集成周期的问题 

H模型：把软件测试看成一个独立的流程，与其他流程并发进行，比如设计流程，编码?流程，甚至是测试流程

软件测试的分类

按测试手段分类：

     测试对象可见度-黑盒测试、白盒测试；

     状态-静态测试、动态测试；

     执行方式-手工测试。自动化测试；

黑盒测试：输入，输出，用户需求、事件驱动

    优点：容易实施， 无需关注内部实现；更贴近用户使用角度

    缺点：测试覆盖率低；针对黑盒的自动化测试，复用率较低，维护成本高。

    主要测试：是否有错误或遗漏的功能；接口上是否能正确接受输入，正确输出；是否有数据结构错误或外部文件访问错误；性能是否满足要求

    主要设计方法：等价类划分法；边界值分析法；错误推测法；因果图法；正交试验分析法；状态迁移图法；流程分析法

白盒测试：内部逻辑结构（主要逻辑单位：语句，条件，条件组合，分支，路径）

    优点：迫使测试人员思考软件实现，理解原理；检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码测试更彻底。

    缺点：昂贵；无法检测代码中遗漏的路径和数据敏感性错误；无法直接验证需求正确性

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

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

静态测试：无需执行程序，评审软件文档和代码

动态测试：运行程序，根据结果分析效率，正确性，健壮性

手工测试（- 容易发现缺陷和实施，创造性灵活性，覆盖量化难，重复效率低，不一致性，可靠性低，人力资源依赖）

自动化测试：使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查（单元测试，接口测试，性能测试等）-（高效，高复用，覆盖率易度量，准确可靠，不知疲劳，发现缺陷率低，一次投入大?）

软件测试分类

按测试阶段分类

  单元测试：最小可测试单元 

    原则：尽量保证各个测试用例相互独立；一般由代码开发人员实施；

    益处：尽早发现缺陷（TDD）；有利于重构；简化集成；文档；用于设计

    限制：难以覆盖所有执行路径；代码量上需要投入和产出之间寻找一个平衡；

单元测试框架

  集成测试 ：单元测试的基础上，完成测试的单元组装成子模块，测试这个集成是否达到要求，测试对象为单元接口

         实施方案：1.Big bang  2.自顶向下  （主程序-控制层逐层向下） 3.自底向上（常用基础）  4.核心系统集成     5.高频集成（同步开发过程）

单元测试&集成测试：测试对象不同、测试依据不同（详细设计/概要设计）、测试方法不同

系统测试：完成集成测试的软件，作为部分，与系统中的其他部分，实际运行环境下，进行的测试。（功能测试，性能测试，稳定性测试等）

       关注点：本身的使用，系统间的联通，不同压力下的表现，真实使用环境下的表现

集成测试&系统测试：测试对象不同、测试时间先后、测试内容、测试角度（技术和业务）

 验收测试（又称交付测试，确定系统是否满足验收标准，能否被客户接受）

细分：用户验收；运行验收（运行备份维护）；合同和规范验收；alpha；beta? ；

验收测试驱动开发

软件测试的分类

按测试阶段分类

  单元测试：最小可测试单元 

    原则：尽量保证各个测试用例相互独立；一般由代码开发人员实施；

    益处：尽早发现缺陷（TDD）；有利于重构；简化集成；文档；用于设计

    限制：难以覆盖所有执行路径；代码量上需要投入和产出之间寻找一个平衡；

单元测试框架

  集成测试 ：单元测试的基础上，完成测试的单元组装成子模块，测试这个集成是否达到要求，测试对象为单元接口

         实施方案：1.Big bang  2.自顶向下  （主程序-控制层逐层向下） 3.自底向上（常用基础）  4.核心系统集成     5.高频集成（同步开发过程）

单元测试&集成测试：测试对象不同、测试依据不同（详细设计/概要设计）、测试方法不同

系统测试：完成集成测试的软件，作为部分，与系统中的其他部分，实际运行环境下，进行的测试。（功能测试，性能测试，稳定性测试等）

       关注点：本身的使用，系统间的联通，不同压力下的表现，真实使用环境下的表现

集成测试&系统测试：测试对象不同、测试时间先后、测试内容、测试角度（技术和业务）

 验收测试（又称交付测试，确定系统是否满足验收标准，能否被客户接受）

细分：用户验收；运行验收（运行备份维护）；合同和规范验收；alpha；beta? ；----?验收测试驱动开发

软件测试概念

软件测试的分类

按测试阶段来分类  单元测试  集成测试  系统测试  验收测试

单元测试：对软件中的最小可测试单元进行检查和验证。

单元测试的原则：1.尽可能保证各个测试用例是相互独立的

2.一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。

单元测试的好处：1、能尽早的发现缺陷

2.有利于重构。

3.简化集成

4.文档

5.用于设计

单元测试的限制：1.不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误。2.每一行代码，一般需要3-5行测试代码才能完成单元测试。所以存在投入和产出的一个平衡。

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

集成测试的主要实施方案：1.Big Bang     2.自顶向下     3.自底向上   4.核心系统集成     5.高频集成

集成测试和单元测试的区别

1. 测试的对象不同

   单元测试对象：软件的基本单元，最小的单元
   

   集成测试对象：模块与模块之间接口的关系
   

2. 测试的依据不同

   单元测试依据：针对软件的详细设计
   

   集成测试依据：针对软件的概要设计
   

3. 测试的方法不同

   单元测试方法：单元的类

   集成测试方法：模块与模块接口的集成

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

系统测试关注点

1. 关注系统本身的使用

2. 关注系统与其他相关系统间的连通

3. 关注系统在不同使用压力下的表现

4. 关注系统在真实使用环境下的表现

系统测试与集成测试的区别

1. 测试对象不同
   

   集成测试对象：由通过了单元测试的各个模块所集成起来的构件

   系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统。

2. 测试时间不同

   集成测试介于单元测试和系统测试之间测试

   系统测试在集成测试之后

3. 测试内容

   集成测试：各个单元模块之间的接口

   系统测试：整个系统功能和性能

4. 测试角度

   集成测试：偏于技术角度的验证

   系统测试：偏于业务角度的验证

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

验收测试细分  1、用户验收测试   2、运行验收测试   3、合同和规范验收测试

alpha测试：是由开发者提供操作环境，用户进行执行的

Beta测试：脱离开发者，用户操作环境，用户执行。

软件测试的定义：测试是为发现错误而执行程序的过程。使用人工或自动的手段来运行或测量软件系统的过程，已检测软件系统是否满足规定的需求，并找出与预期结果之间的差异。

软件的测试对象：软件需求，软件概要设计，软件详细设计，软件运行环境，可运行程序，软件源代码。

五大要素：质量，人员，技术，流程，资源。   两个目标：测试覆盖率，测试效率。

软件测试所遵循的原则

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

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

3. 测试应该尽早进行

4. 缺陷具备群集特性

5. 测试的杀虫剂的悖论

6. 测试的二八原则

7. 测试活动依赖于测试背景