功能测试工具

基于风险的测试--RBT

Risk based Testing

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

那些是风险？

质量风险：软件的功能、易用性、软件的性能；比如：软件功能的缺失、数据的转换。

管理风险：人员的技能不足、项目的人力不足、测试环境不具备、被测系统的需求不够清晰、被测系统关联的第三方的系统异常导致无法进行联调。

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

识别风险

按测试模式:

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

敏捷测试

Aglie Testing --遵循敏捷宣言的一种测试实现

敏捷宣言

我们通过身体力行和帮助他人来揭示更好的开发方式。

敏捷测试

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

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

尽早测试，不间断测试，具备条件即测试（比如某个模块代码编写完成即可进行测试）

强调持续反馈

预防缺陷重于发现缺陷

基于脚本的测试--SBT

Script-based Testing

Scripted Testing(ST)

Exploratory Testing(ET)

探索式测试（ET）

完全抛开测试脚本的测试

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

探索式测试的优点

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

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

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

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

5、更加适用于敏捷项目

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

探索式测试的缺点

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

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

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

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

5、ET的生产率很难定义

6、ET本身较难进行自动化

局部探索式测试

输入   状态   代码路径  用户数据   执行环境

输入：接受输入、产生输出、存储数据、进行运算  （测试时一般从输入顺序，输出内容、输出异常考虑测试要点）

状态：临时状态、永久状态 （运行时有效、阶段有效、数据库保存、文件保存）

代码路径：代码的覆盖

用户数据：真实的用户数据

执行环境：操作系统、系统组网的拓扑、与系统有交互的第三方系统、系统的配置数据，系统的设备

全局探索式测试

漫游测试法： 旅馆区 旅游区  历史区 娱乐区 破旧区  商业区  

定义：让测试人员像游客游览一样来测试被测系统，并把系统按照不同的属性分成不同的区域来进行针对性的测试

商业区：软件启动到关闭之间用户可能使用到的一些主要功能

旅馆区：软件在休息或没有在运行的时候的一些功能，一般指运行在后台的一些进程/定时任务。

历史区：版本历史遗留代码的一些功能，或以前测试过程之中发生比较多问题的模块的一些功能

旅游区：新用户会使用到或比较关注的一些功能，比如：新手的一些指引、注册的功能

娱乐区：系统之外的一些辅助功能

破旧区：系统已经废弃的或者是隐藏的，用户看不到的一些功能，一般不在用户手册中提及。

Know You Mession：了解测试任务的重点，测试的主要测试方向，系统的环境信息，理清测试的总体思路。

Leaning Session：详细的学习与探索被测系统，了解系统的逻辑具体的功能，深入的学习被测系统。

Coverage session：主要的探索测试的实施阶段，需要完成主要功能点的测试验收，完成测试点的覆盖，尽可能的把测试点都测试到。

Deep Session：在上一阶段覆盖性测试的基础上进一步的、深入的、发散式的探索性测试，挖掘一些深层次的问题。

Close Session：对前面的测试工作总结，总结前面探索性测试的过程，整理测试过程记录的一些测试信息，并根据这些记录和过程总结，分析测试过程有没有遗漏问题，覆盖率是多少。

软件测试的分类

按测试模式来分类

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

传统的瀑布模型（传统软件工程学的开发模式）

项目计划-->需求分析-->软件设计-->程序开发-->软件测试-->集成维护

项目计划：制定项目总体的研发计划，确定项目主要的里程碑节点；需要输出项目计划书。

需要分析：明确用户的需求定义，并对定义进行清晰的描述，是充分理解客户需求，详细描述产品功能的一个重要阶段；需要输出产品的需求规格书。

软件设计：根据产品的定义，确定产品的实现方案；包括定义软件与硬件的结构，组件模块的实现方法，接口、界面、数据如何组织，需要输出概要设计、详细设计在内的多份说明书。

程序开发：由开发团队根据需求和设计具体实现产品的功能，根据编程规范编写各类组件和模块，最后输出产品版本。

软件测试：通过独立的测试小组（QA团队）来评估产品是否满足需求的定义，需要输出测试结果、测试报告。

集成维护：产品经过测试后交付给用户，根据用户的使用情况，对产品进行维护，及必要的修改、升级的操作。

瀑布模式的有缺点

优点

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

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

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

4、文档规范

缺点

1、难以适应需求的频繁变化

2、项目周期后段才能看到成果

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

4、文档工作量大

优点

描述了测试与软件开发过程的对应关系。

强调了软件开发的协作与速度，反应测试活动和分析设计的关系，并且将软件实现和验证有机的结合起来，明确界定测试过程存在不同阶段的，明确了不同测试阶段和研发过程每个阶段的对应关系。

缺点

把测试当做软件编码后的阶段，忽视了测试对需求的分析和验证，对需求与概要的验证要到后期才能进行，不符合软件测试需要尽早进行的感念。

软件开发过程中，各个阶段测试都参与，测试伴随软件开发的整个开发周期

优点：能尽早的发现软件的缺陷；有利于尽早的发现软件的风险，及早的制定相应的应对方案，加快项目的进度

缺点：需求设计编码还是串行的关系，测试开发保持着一种线性的关系，在上一个阶段完成后才能进行以一个阶段，不能很好的支持迭代场景。

解决交接与频繁集成周期的问题。

分片段进行测试。

把软件测试当做一个独立的流程，贯穿在整个软件测试周期当中，与其他流程并发进行。

静态测试

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

动态测试

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

手工测试

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

如：众包测试、探索式测试

自动化测试

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

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

手工测试VS自动化测试

手工测试                             自动化测试

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

容易实现                            高复用性

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

覆盖量化难                         准确、可靠

重复测试效率低                  不知疲劳

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

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

白盒测试

测试人员对内部的结构是非常了解，白盒测试又称为结构化测试/透明测试。

用逻辑的覆盖率来衡量测试的完整性

主要的逻辑单位

语句、条件、条件组合、分支、路径

白盒测试的优缺点

优点

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

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

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

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

缺点

1、昂贵

2、无法检测代码中遗漏的路径和数据敏感性错误（比如少写了代码）

3、不能直接的验证需求的正确性（测试的特点针对代码，不是需求）

白盒测试的主要测试方法

1、代码检测法

2、静态结构分析法（使用工具分析代码的结构）

3、静态质量度量法（标准的质量模型，如：ISO）

4、逻辑覆盖法（语句、条件、条件组合、分支、路径、条件与判断组合）

5、基本路径测试法（程序的控制流图流程路径进行测试）

软件测试的分类

按测试手段来分类

按测试的可见的度： 黑盒测试  白盒测试

按测试的状态：        静态测试  动态测试

按测试执行的方式： 手工测试   自动化测试

黑盒测试

定义：把被测试的系统/软件当成一个不能打开的盒子，在完全不考虑程序的内部结构与内部特性的情况下，通过相关资料暴露出来的接口对程序进行测试

检查标准：只检查程序的功能是否能按照我们需求规格的规定，能够正常的使用，程序是否能正当的接受输入数据并能正确的产生输出信息。

黑盒测试只考虑程序的外部结构，不考虑内部逻辑；一般为界面或可见的功能进行测试。

从用户的视角，通过不同的数据/事件来驱动系统，并通过输出结果进行判断。

黑盒测试的优点缺点

优点：

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

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

缺点：

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

2、针对黑盒测试的自动化测试，复用率较低，维护成本较高（黑盒一般为功能测试，软件变化最快的是功能，经常修改，导致自动化测试用例经常要修改）

黑盒测试主要测试什么

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

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

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

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

黑盒测试的主要设计方法

1、等价类划分法（程序有很多输入条件，等价类划分就是把程序中所有的输入等价的归类在一类，最后会形成若干典型的代表性的输入，通过这些典型的数据进行测试用例的设计）

2、边界值分析法（各种各样的边界条件进行测试用例设计）

3、错误推测法（基于经验或直觉来判断程序中可能出现错误的地方，从而针对性的对功能进行测试用例的设计，例如：界面输入的时候考虑特殊字符，处理文件时时候考虑文件不存在或超大）

4、因果图法（拿到程序的需求规格书，针对需要的每一种输入与输出，形成一个判定表，根据判定表来设计用例）

5、正交试验分析法（刷选我们的输入数据，然后设计测试用例的输入输出用例）

6、状态迁移图法（比如申请权限->提交审批->审批通过/驳回 等的状态变化的场景进行测试用例的设计）

7、流程分析法（梳理程序的流程路径进行测试用例的设计）

真实运行环境

失败后不能判断是被测方法的问题还是依赖方法的问题

单元测试尽量避免使用依赖的方法

应该编写一个模拟的方法取代使用外部的依赖

提升测试覆盖率和测试效率为目标

回归测试：重心在关键模块和重点功能组件

修复成本 时间越久成本越高