敏捷测试

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

敏捷宣言（价值观）： 个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作   重于 合同谈判 响应变化   重于 遵循计划 ——在每对比较中，后者并非全无价值，但我们更看重前者

敏捷测试的特点：

敏捷测试强调从客户角度进行测试

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

尽早测试，不间断测试，具备条件既测试

强调持续反馈

预防缺陷重于发现缺陷

基于脚本的测试-SBT

Script-based Testing

Scripted Testing(ST)

Exploratory Testing(ET) 逐渐开始非常流行的方式

探索式测试（ET）

完全抛开测试脚本的测试

它是一种测试风格、思维而不是一种测试技术

ST和ET是互补的

探索式测试的优点：

更能激发测试人员的创造性和工作乐趣

增加了发现新的或较深入Bug的可能性

在较短的时间内找到更多Bug以及对SUT做一个快速的评估

有利于更加有效地实施自动化

更加适用于敏捷项目

减少了在简单、繁复上用例的无谓编写时间

探索式测试的缺点：

测试管理上有局限性，较难协调和控制

对于Bug的重复利用和重现上作用有限

对测试人员的测试技能和业务知识深度依赖较大

只有在SUT已完全可用的前提下才更有作用

ET的生产率很难定义

ET本身较难进行自动化

局部探索式测试

输入、状态、代码路径、用户数据、执行环境（被测系统的五大要素）

    让测试人员像游客游览一样来测试，而且软件按照不同属性划分为各个区域。商业区是指软件启动到关闭之间用户会使用的功能。旅馆区是指软件休息没有实际运行时候的功能，例如后台进程和定时任务。历史区是指版本遗留代码或者说以前版本经常出现bug的功能模块。旅游区是指新手引导之类的功能。娱乐区是指主要功能之外的一些辅助特性。破旧区是指废弃或者已经隐藏的功能。

    konw you mession 了解测试重点，系统环境，有一个测试的总体思路     learning session 详细的学习探索被测系统了解系统的业务逻辑，具体功能，深入学习被测系统     coverage session 探索式测试的实施阶段，完成主要功能点的测试验收，完成测试点的覆盖     deep session 在上一个功能点的基础上，更深入的发散式的测试，挖掘深层次的问题，深入测试     close session 总结测试，整理测试信息，根据整理数据，分析有没有测试的遗漏 缺陷大扫除。

基于风险的测试-RBT

Risk-based Testing

一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型

那些是风险？

质量风险（软件功能，易用性，性能，软件代码缺失）；

管理风险（人员能力不足，环境风险，被测系统的需求不清晰，被测系统关联的第三方系统不能联调）

风险级别=风险可能性*风险严重度

分析要素分=Sum（单项权重*得分）

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

基于模型的测试-MBT

https://blogs.msdn.microsoft.com/sechina/2009/11/18/123/            更偏向于借助MBT?工具的自动化测试

第四讲 软件测试模式

传统测试模型：瀑布、V、W、X、H模型

敏捷测试

基于脚本的测试

基于风险的测试

探索式测试等

【瀑布模型】

定义：

项目计划：指定项目总体的研发计划，确定里程碑节点。

需求分析：充分理解用户需求，产出产品需求规格说明。

软件设计：详细设计说明书。

程序开发

软件测试

集成维护

优点：

1、强调需求、设计的作用

2、前一阶段完成后，只需关注后续阶段

3、为项目提供了按阶段划分的检查点，里程碑清晰

4、文档规范

缺点：

1、难以使用需求的频繁变化

2、项目周期后半段才能看到成果，用户要末期才能看到，增大开发风险

3、强制的里程碑，完成时间点

4、文档工作量大

【V模型】

目前使用最广泛的模型，为瀑布模型的变种

需求分析                        验收测试

概要设计                 系统测试

详细设计         集成测试

软件编码 单元测试

【W模型】

也称双V模型

用户需求 验收测试设计

需求分析 系统测试设计             交付 验收测试

概要设计 集成测试设计       实施 系统测试

详细设计 单元测试设计 集成 集成测试

    编码 单元测试

【X模型】

针对V模型做出的改进，定位了探索式测试，不进行事先计划的探索性测试

程序片段1 封板

测试设计 执行测试

工具配置 测试设计

执行测试

编码完成 迭代1...n

执行测试 探索式测试

工具配置

测试设计 执行测试

程序片段n

【H模型】

测试准备 测试就绪点 测试执行

——> | ——> 测试流程

——> | <—— 其他流程

                                 软件测试的分类

按测试模式来分类：

        瀑布模式     敏捷测试    基于脚本的测试    基于风险的测试   探索式测试等

传统的瀑布模式：项目计划  ---》需求分析  ---》软件设计  ---》程序开发  ----》软件测试  ----》集成维护

瀑布模型的优缺点：

        优点：    1.强调需求，设计的作用

                      2.前一阶段完成后，只需关注后续阶段

                      3.为项目提供了按阶段划分的检查点，里程碑清晰

                      4.文档规范

        缺点：    1.难以适应需求的频繁变化

                      2.项目周期后段才能看到结果

                      3.强制的里程碑，完成时间点

                      4.文档工作量大

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

第三讲 软件测试手段笔记

黑白分明，一静一动，类似太极

根据对象可见度分为：黑盒测试、白盒测试

根据状态分为：静态测试、动态测试

根据侧测试执行的方式分为：手工测试、自动化测试

【黑盒测试】

更偏向用户的角度出发涉及测试用例

优点：

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、创造性、灵活性 覆盖丰富易度量

4、覆盖量化难 准确、可靠

5、重复测试率低 不知疲劳

6、不一致性，可靠性低 机械，发现缺陷率低

7、人力资源依赖 一次性投入较大

按测试手段分类：

黑盒测试、白盒测试

静态测试、动态测试

手工测试、自动化测试

黑盒测试的优点：   1.容易实施，不需要关注内部的实现       

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

黑盒测试的缺点： 1.黑盒测试覆盖率低，一般只能覆盖到代码量的不到40%                     2.复用率低，维护成本高

黑盒测试主要测试什么：

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

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

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

     4.性能上是否能够满足要求？

白盒测试（结构法测试/透明测试）-------------》逻辑

主要的逻辑单位：语句、条件、条件组合、分支、路径

白盒测试优点：

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

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

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

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

白盒测试缺点：

        1.昂贵.

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

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

白盒测试的主要测试方法：

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

灰盒测试

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

静态测试

        静态测试是指无须执行被测程序

动态测试：

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

手工测试：

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

众包测试、探索式测试

自动化测试：

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

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

第二讲 软件测试阶段笔记

按阶段分类：单元-集成-系统-验收

【单元测试】

一、单元测试定义

对软件中最小可测试但愿进行检查和验证。例如，类。

二、单元测试原则

1、尽可能保证各个测试用例是相互独立的。最小单元模块可减少依赖可缩小问题出现范围。

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

三、单元测试优点

1、能今早发现缺陷

2、有利于重构

3、简化集成

4、代码即文档

5、用于设计

四、单元测试缺点

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

2、每一行代码，一般需要3-5行的测试代码才能完成单元测试。所以存在

集成投入和产出的一个平衡。

五、单元测试框架

JUnit、Nunit、PHPUnit和CppUnit。

单元测试如何执行和实施：

1、创建一个Java工程

2、导入Junit依赖库

3、导入计算代码

4、新建一个Junit Test,规定开始和结束时的动作和测试的方法，自动生成单元测试基本框架

【集成测试】

一、集成测试定义

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

二、集成测试方案

1、Big Bang大爆炸，所有东西都组装好然后进行测试。

2、自顶向下

3、自底向上

4、核心系统集成

5、高级/持续集成

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

1、测试对象不同

2、测试依据不同：详细设计和概要设计文档

3、测试方法不同：关注模块内部和关注接口集成

【系统测试】

一、系统测试定义

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

二、专注点

1、关注系统本身的使用

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

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

4、关注系统在真是使用环境下的表现

三、集成测试和系统测试的区别

1、测试对象不同：通过单元测试集成起来的构件和计算机硬件和外围设备等整个系统。

2、测试时间不同

3、测试内容不同：接口和功能性能。

4、测试角度不同：集成测试偏向于技术角度的验证，系统测试偏向于业务角度的验证。

【验收测试】

一、验收测试定义

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

二、细分

1、用户验收测试

2、运行验收测试(运维侧)

3、合同和规范验收测试(政府法律法规验收）

4、alpha测试

开发提供的场所和环境下运行

5、Beta测试

用户提供的场所和环境下运行，relase就是正式可交付的版本

第一讲 软件测试概要笔记

一、定义

1、Bill Hetzel,1973

软件测试是对程序能够按照预期运行建立起一种信心。

2、Myers，1979

测试是为了发现错误执行程序的过程。

3、IEEE定义（ ISO/IEC/IEEE 29119）

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

二、测试对象、五大要素和两个目标

1、测试对象：软件开发生命周期的方方面面

2、五大要素：质量、人员、资源、流程、技术

3、两个目标：测试覆盖率、测试效率

三、原则

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

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

3、测试应该尽早进行

4、缺陷具备群集特性

5、测试的杀虫剂悖论

6、测试的二八原则

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