风险测试：

质量风险：被测系统质量问题，软件的功能，性能，易用性，功能缺失，数据转换

管理风险：人手不足，人员技能不匹配，测试环境不具备，被测系统需求不清晰，被测系统关联的第三方需求有问题

Script-based Testing

Script Testing（ST）

敏捷测试

Agile Testing

宣言：强调了个体的沟通重于过程，对于软件看重结果轻文档，客户视角与客户合作创造更多的价值，拥抱变化

特点：

强调从客户的角度测试

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

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

强调持续反馈

预防缺陷重于发现缺陷（给整个研发提出建设性的意见，质量改进的建议，全方位的参与到软件研发的各个层面，提升整个团队的工作效率和保证产品质量）

与传统测试的区别：

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

传统测试有严格的变更管理；变更是可接受的，拥抱变更

预先的计划和细节的准备（测试计划、测试方案、测试用例、规程文档）；敏捷计划随着进展时常调整；

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

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

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

严格依赖流程执行；流程不再需要严格执行（注重测试结果，规则就是被打破的）

测试团队和开发团队是相互独立的；团队合作是无缝隙的合作（整个测试持续不断的质量反馈的过程，从研发生命周期的开始，就把测试过程中的问题持续不断的反馈给我们的开发人员、项目经理，及时知晓研发过程中的质量现状并且及时的进行改正）

基于脚本的测试-SBT

Scripted Testing(ST)

Exploratory Testing（探索式测试）：

完全抛开测试脚本的测试 探索被测系统，带着问题使用系统，在探索的过程中发现测试要点，找出被测系统的问题，在测试过程中测试设计和测试执行是并行的，更自由；

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

局部探索式测试：

输入：接收输入 产生输出 存储数据 进行运算 输入顺序 输出内容 输出异常

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

代码路径：对代码的覆盖率

用户数据：模拟真实用户数据

执行环境：软件运行的操作系统 网络拓扑 三方系统 系统的配置数据 硬件设备

全局探索式测试：

像游客游览一样测试系统

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

旅馆区：软件在没有运行时的功能如定时任务、一些后台进程

历史区：历史遗留的功能

旅游区：新用户使用或关注的功能（新手指引等）

娱乐区：辅助功能

破旧区：隐藏或遗弃的功能，用户看不到

执行探索式测试：

Konw You Mession：了解测试任务的重点 主要测试方向 系统的环境

Learnging Session：详细学习和探索被测系统 业务逻辑 系统功能

Coverage  Session：测试执行阶段 完成测试点的覆盖

Deep Session：更深入的发散式的测试

Close Session：总结 整理 复盘阶段

基于风险的测试-RBT

Risk-based Testing

风险：

质量风险（功能 易用性 性能 软件功能缺失 数据的转换）

管理风险（人员的技能不足 人力不足 测试环境不具备 被测系统的需求不够清晰 三方系统有问题等）

风险级别：风险的可能性*风险的严重度

识别风险：

可能性：复杂性（越复杂风险越大）时间压力 高变更率 技能水平 地理分散度（研发团队太分散 集成上有潜在的问题）

严重程度：使用频率 失效可视性 商业损失（支付功能 计费功能） 组织负面影响和损害 社会损失和法律责任

优点：优先测试的都是高风险的部分 对质量信心的提升非常明显

基于模型的测试-MBT

敏捷测试（Agile Testing）

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

探索式测试的优点：

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

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

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

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

    更加适用于敏捷项目

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

探索式测试的缺点：

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

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

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

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

    ET的生产率很难定义

    ET本身较难进行自动化

主流的MBT建模工具

基于模型的测试更多的偏向于自动化测试

基于模型的测试 MBT Model based testing

RBT 基于风险的测试的优点，优先测试可能存在高风险的环节，所以风险率越来越低，质量信息逐渐提高

风险要素分值的运算逻辑

可能出现风险的原因以及风险带来的后果

基于风险的测试 风险类别

基于风险的测试 RBT

探索式测试的执行流程，最后通常还会有一个缺陷大扫除的环节

探索式测试的缺点2

探索式测试的缺点1

探索式测试的优点2

探索式测试的优点1

ST和ET的区分

探索式测试的基本概念 ET

基于脚本的测试分类

在手动测试里 script更多是指测试用例，而在自动化测试里，script是指测试脚本

敏捷测试和传统测试的区分2

敏捷测试和传统测试的区别

敏捷测试的主要逻辑

敏捷宣言更看重前者

软件工程中的测试用例是一组条件或变量，测试者根据它来确定应用软件或软件系统是否正确工作。

敏捷测试：遵循敏捷宣言的测试实践

敏捷宣言：个体与交互重于过程与工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划

强调从客户角度进行测试

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

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

强调持续反馈

预防缺陷重于发现缺陷

基于脚本的测试（ST/SBT）

探索式测试（ET）：完全抛开测试脚本的测试。是一种测试风格、测试思维，而不是测试技术

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

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

探索式测试优点：更能激发测试人员的创造性和工作乐趣；增加发现新的或较深入缺陷的可能性；在较短时间内找到最多BUG以及对被测系统做出快速评估；有利于更加有效地实施自动化；更加适用于敏捷项目；减少了在简单、繁复用例上的编写时间

缺点：在测试管理上有局限性，较难协调和控制；对BUG的重复利用和重现（设计与执行并行）、对测试人员的测试技能和业务知识深度依赖较大；只能在被测系统完全可用前提下更有作用；生产率难定义；本身较难进行自动化

基于风险的测试（RBT）：基于对软件失效的风险评估，并以此指导测试技术、设计、执行、结果评价的软件测试类型

风险：质量风险（软件质量问题）、管理分析（人员、第三方问题）

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

基于模型的测试：对需求功能点建模

保存