今天完成的事情：今天继续从各方面深入了解的测试的分类，算是昨天学习部分的续

按测试手段分类

一、黑盒测试，也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看

作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它

只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确

的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行

测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外

部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。

功能不正确或遗漏；

界面错误；

输入和输出错误；

数据库访问错误；

性能错误；

初始化和终止错误等

优点

1、容易实施，不需要关注内部的实现，操作简单

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

缺点

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

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

黑盒测试主要测试什么

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

2、在接口上，输入是否能正确的接受，能否输出正确的结果，从输入到输出经过系统处理后是否能够满

足预期要求

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

4、性能是否满足要求

系统测试阶段更多使用黑盒测试手段

黑盒测试的主要设计方法

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

二、白盒测试，又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用

例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是

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

试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯

穿程序的独立路径数是天文数字。

白盒测试时针对程序的逻辑结构来设计测试用例，逻辑单位主要是语句、条件、条件组合、分支、路径

不同单位有不同覆盖方法

白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖

、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变

化：

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

2.判定覆盖每个判定的每个分支至少执行一次。

3.条件覆盖每个判定的每个条件应取到各种可能的值。

4.判定/条件覆盖同时满足判定覆盖条件覆盖。

5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。

6.路径覆盖使程序中每一条可能的路径至少执行一次。

优点

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

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

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

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

缺点

1、成本高，工作量大

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

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

白盒测试主要测试方法

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

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

合黑、白盒测试的相关要素

四、静态测试，是指无须执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软

件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率

方式

互审-走查-会议

五、动态测试，是指测试是通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正

确性和健壮性

六、手工测试，由专门的测试人员从用户视角来验证软件是否满足设计要求的行为，更适用针对深度的

测试和强调主观判断的测试

众包测试、探索式测试等更多使用手工测试

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

单元测试、接口测试、性能测试等更多使用自动化测试

手工测试与自动化测试对比

  手工测试                     自动化测试

容易发现缺陷                 高效率、速度快  

容易实施                     高复用性

具有创造性、灵活性           覆盖率容易度量

覆盖量化难                   准确、可靠

重复测试效率低               不知道疲劳

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

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

按测试模式来分类

一、传统测试模式

长用测试模型（瀑布模型、V模型、W模型、X模型、H模型）

二、敏捷测试模式

特点

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

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

3、强调尽早测试、不间断测试、具备条件即测试

4、强调持续反馈

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

传统测试与敏捷测试对比

      传统测试                                           敏捷测试

测试是质量的最后保护者              开发和测试人员是紧密合作，大家都有责任对软件负责

严格的变更管理                      变更是可以接受的，拥抱变更

预先的计划和细节的准备              计划随着进展时常调整

重量级文档                          只需要绝对必要的文档

各阶段测试严格的入口和出口标准      各迭代之间已经没有明显的入口和出口标准

更多在回归测试时进行重量级的自      所有阶段都需要自动测试，每个人都需要做，

动化测试                            是项目集成的一部分

严格依赖流程执行                    流程不在需要严格执行

测试团队和开发团队是相对独立的      团队合作是无缝隙合作

三、基于脚本的测试-SBT

强调先做测试设计，然后再执行测试

先做测试用例（脚本）

四、探索式测试-ET

完全抛开测试脚本的测试，探索被测系统，带着问题来使用被测系统，并在探索的过程中发现测试的要

点，找出被测系统的问题，测试过程中测试设计和测试执行是并行的。它是一种测试风格、思维而不是

一种测试技术

ST和ET的比较

      ST                         ET

系统性强                   自由灵活

容易管理、控制             和ST是互补的

设计在先、执行在后         执行和设计（思考）并行

主要是验证自己的思路       不断和系统交互，带着问题测试  

可预见性                   学习的过程

优点

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

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

3、在较短时间内找到更多Bug以及对被测系统做一个快速的评估

4、有利于更加有效的实施自动化

5、更好适用于敏捷项目

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

缺点

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

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

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

4、只有在被测系统已经完全可用的前提下才更有作用

5、ET的生产率很难定义

6、ET测试过程本身较难进行自动化

ET测试方法

1、局部探索式测试

一般是从系统输入、状态、代码路径、用户数据、执行环节入手

2、全局探索式测试

漫游测试法，让测试人员像游客游览式来测试被测系统，并把被测系统按照不同属性分成不同区域来测

试，对应区有对应的测试法

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

旅馆区，指软件在休息或没有时间运行的时候的功能，一般指后台进程

历史去，指版本历史遗留代码的功能或在以前测试中发现较多问题的功能

旅游区，指新用户会使用和关注的功能

娱乐区，指系统主要功能之外的辅助功能

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

五、基于风险的测试-RBT

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

测试过程当中有那些风险

质量风险、管理风险

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

如何识别风险

风险可能性一般包括复杂性、时间压力、高变更率、技能水平、地理分散度

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

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

根据风险级别来定义版本测试的优先级别

六、基于模型的测试-MBT

指的是对功能需求点建模，而不是对测试过程建模，更多的是借助工具来建模，更偏向于自动化测试

明天计划的事情：感觉基础内容学习的差不多，完成任务一
遇到的问题：感觉写的内容与任务要求有点偏，是不是没找对方向，求师姐指点，还有写下来的内容算是临时笔记，有点杂乱

收获：对测试的认知更加近了一步，初步有了一个还算是清晰的框架