本文由小编根据慕课网视频亲自整理，转载请注明出处和作者。
1.定义：
Agile Testing：遵循敏捷宣言的一种测试实践
敏捷宣言：
我们通过身体力行和帮助他人来揭示更好的软件开发方式，基于这种方式形成了如下的价值观：
在每对比较中，后者并非全无价值，但我们更看重前者。
特点：
更多地站在客户的视角来看待我们的系统。
不强调传统测试当中严格的阶段划分，单元测试、集成测试、系统测试、验收测试。
某个模块的功能编写完了，就可以开始做单元测试。与H模型一样。
测试过程中，测试的结果、过程，发现的问题都要尽可能快速地通知到相关人员。比如敏捷中的看板方法，及时地把当前的状态反馈给项目组成员。
敏捷不是以发现缺陷为目标，重点是为了预防缺陷，给整个研发提供建设性的意见、质量改进的建议。
测试是全方位地参加到软件研发的各个层面，来提升整个团队的工作效率，和保证产品的质量。
敏捷测试VS传统测试：
敏捷强调规则就是用来打破的，我们注重的是最终的结果。
对于敏捷测试来说，我们整个测试就是一个持续不断的质量反馈的过程，从研发生命周期的开始就把测试过程中相关的问题持续不断地反馈给开发人员、产品经理，所以敏捷测试更加注重的是让团队的相关角色及时知晓当前研发过程中的质量现状，并且及时地进行改正。这是敏捷测试，它更多地体现为一种价值观，一种研发流程的思想。
2.敏捷测试分类
基于脚本的测试-SBT：
SBT: Script-based Testing
or ST: Scripted Testing
它强调先做我们的测试设计，然后再执行测试。
首先设计出我们的Script，这里的script在手工测试里更多指的是我们编写的测试用例，而在自动化测试当中，这个script就是我们自动化测试的脚本。
SBT：它是遵照测试计划，属于比较传统的测试。
ET：Exploratory Testing，探索式测试。
现在我们说ST都是和ET一起说的，ET也是目前逐渐开始流行的一种测试方式。
探索式测试ET:
完全抛开测试脚本的测试。探索被测系统，带着问题来使用我们的被测系统，并在探索的问题当中发现测试的要点，找出被测系统的问题。
在测试过程当中，测试设计和测试执行两者是并行的。
ET的执行，对于测试人员来说，会更加的自由。所以ET也更加依赖测试人员的责任。
ET更多的是一种测试风格、思维而不是一种测试技术。
ST和ET一般来说，是互补的，在实际的项目使用上，一般ST、ET都会涉及到。我们从实际项目的实施上，可以分成这么几种模式：
Pure Scripted：完全的ST，完全地按照测试用例来执行，而且测试用例的编写会非常的详细
Freestyle ET：完全自由的ET，没有任何文档做支持，也不对测试过程的要点进行记录，
Vague Scripted：中间的一种模式，还是会写测试用例，但是用例的编写相对会比较模糊，比如对预期结果、执行步骤的描述相对会简单一些。
Fragmentary test cases：指的是测试用例不会再正式地写成规程文档，可能只是会用一两句话来描述测试的思路，可以看做是一个测试点的清单。
Charters：偏向ET，ET会列出一个详细的任务列表，在列表中会指出测试对象，测试的策略，指出可能的风险，参考的文档等等。
Roles：只是给定测试人员一个独立的角色，测试人员从这个角色来出发，去测试产品，测试进度和测试的质量，都是由测试人员自己来掌握的。
所以说从不同的实施方式上来说，ET、ST的应用程度是不同的。我们需要根据项目本身的特点来确定使用何种的实施方式。
ST vs ET：
ST:
是按照需求文档进行详细的设计的。
测试的过程是比较容易控制的。
ET:
更多强调的是测试人员的主观性和创造性。
执行和设计两者是并行的。
探索式测试的优点：
更能激发测试人员的创造性和工作乐趣
增加了发现新的或较深入bug的可能性
在较短时间内找到更多bug以及对SUT(Software Under Test)作一个快速的评估
有利于更加有效地实施自动化（进行探索性测试之后，就会更加地有针对性的，对有风险、更有价值的地方来做自动化）
更加适用于敏捷项目
减少了在简单、繁复上用例的无谓编写时间
探索式测试的缺点：
测试管理上有局限性，较难协调和控制
对于bug的重复利用和重现上作用有限
对测试人员的测试技能和业务知识深度依赖较大
只有在SUT已完全可用的前提下才更有作用
ET的生产率很难定义（测试的过程、测试的完成度很难量化）
ET本身较难进行自动化
从测试方法来说，还可以分成局部探索性测试和全局探索性测试。
局部探索式测试：
对于局部探索性测试，一般是从被测系统的5大要素开始着手的。
输入、状态、代码路径、用户数据、执行环境
对于输入来说，测试基本的任务包括接受输入，产生输出，存储数据，进行运算。测试一般是从输入顺序，输出内容，输出异常几个角度来考虑我们的测试要点。
从状态来看，可以分成临时状态和永久状态，状态有运行时有效、阶段有效这种相对临时的状态，还有数据库保存、文件保存这种永久状态。状态的信息可以协助我们来更加有效地判断我们的测试输入和输出。
代码路径更多指的是代码的覆盖，即白盒测试时那些覆盖的方法。
用户数据，测试时更多地采用真实的用户数据，尽量地模拟实际运用时的数据。如果实在条件不具备，也需要构造合理的数据。
从执行环境上来说，包括软件运行的操作系统，系统组网的一个网络拓扑，跟系统交互的第三方系统，还有系统的配置数据，运行系统的硬件设备。
全局探索式测试：
一般都会提到漫游测试法，让测试人员像游客游览一样，来测试被测系统，并把被测系统按照不同的属性分成不同的区域，来进行针对性的测试。
商业区：软件从启动到关闭，用户主要可能使用到的功能。
旅游区：软件在休息，或者没有在实际运行的时候的一些功能，一般是指运行在后台的进程，或者定时任务。
历史区：更多是说版本历史遗留代码中的一些功能，或者在以前的测试过程中，曾经发现较多问题的功能。
旅游区：则一般指的是新用户会使用或者比较关注的功能。比如说新手的指引，新用户的注册这些功能。
娱乐区：系统主要功能之外的一些辅助的特性或者功能。
破旧区：系统已经废弃，或者系统隐藏的、用户一般看不到的功能。一般没有在用户手册当中提及。
对于每一个区域，都有一些具体的探索式测试方法。比如指南测试法、麻烦测试法、懒汉测试法、恶邻测试法、伸向测试法、破坏测试法。
执行探索式测试：
基于Session的测试流程。
Know Your Mession：了解测试任务的重点，测试主要方向，系统的环境是怎样的，有一个总体的测试思路。
Learning Session：详细地学习和探索被测系统，了解系统的业务逻辑、具体的功能，深入地学习被测系统。
Coverage Session：探索式测试的实施阶段，完成主要功能点的测试验收，完成测试点的覆盖。尽可能地把需要测试的东西都覆盖到。
Deep Session：在上一个阶段的基础上，进一步做深入地、发散式的探索式测试，挖掘一些深层次的问题。
Close Session：对前面的测试工作有一个总结，总结前面探索式测试的过程，会整理测试过程中记录的测试信息，并且根据这些记录和对过程的总结分析测试过程还有没有什么遗漏，覆盖率怎么样。
除了这些阶段，一般还有一个缺陷大扫除的阶段，这个阶段一般放在Close Session之后，根据Close Session中整理的信息，再针对性地进行大扫除的阶段。也有把大扫除阶段包含在Deep Session当中，这个阶段会发动项目中的相关人员，或者是不相关的人员，更多地参与到缺陷的大扫除。
基于风险的测试-RBT：
Risk-based Testing：一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型。
哪些是风险？
质量风险：更多指的是被测系统本身的一些质量问题，比如软件的功能、易用性、性能、软件功能的缺失、数据的转换等等。
管理风险：人员的技能不足，项目的人力不足，测试环境不具备，被测系统的需求不够清晰，被测系统关联的第三方的系统有问题，导致无法进行联调。
具体的风险程度，可以用：
风险级别=风险可能性 x 风险严重度。
识别风险：
从可能性上来说：
被测系统的功能越复杂，产生风险的可能性就越大。
项目周期越紧张，时间越短，那风险的几率也越高。
如果需求变更的频率非常快，对项目也是有着极大影响的风险。
研发人员的技能水平，对系统实现方法的熟练程度。
从研发上来说，研发团队如果分散在不同的地理位置，会影响研发效率；从研发的环境上来说，如果太过分散，则存在网络、还有集成上一些潜在的问题；从最终发布的产品来说，如果地理上是分散的，是统一的集中部署，还是分布式的部署，也是有着不一样的风险。
从严重程度来说：
如果功能的使用频率越高，对应的风险严重的程度就越高。
如果发现这个问题，它的可视性越好，更加地可见，则风险越严重。可视性不好，可能用户感觉不到。
功能失效，会直接产生商业损失，而且损失越大，问题越严重。比如软件系统当中，关键的计费功能，支付功能，这样一些能直接带来损失的功能。
功能的失效，可能会给组织带来负面影响，比如给可口可乐开发了一个系统，这个系统面向用户，这个系统中出现了百事可乐的logo，这样的问题就是组织负面影响，损害程度越大，问题就越严重。
比如快播被禁，被封，这个就是典型的软件的功能导致了法律的负责，或者说做了一个电商的网站，上面有大量的强制买卖的信息，承担的法律责任越大，风险就会越高。
从具体的评估上来说，识别风险的时候，不一定每个单项都需要选择，根据项目的情况，自己来定义一个评分。每一个风险的要素，我们会把单项设定一个权重值，然后针对功能的清单，列出单项对应的得分，从而得到要素得分。要素得分再得出风险级别。这样的一个评分表，一般是由项目的相关责任人对风险来进行打分，最后根据风险的级别来定义我们版本测试的优先级，这也是RBT主要实施的一个方式。
风险要素分=Sum（单项权重*得分）
RBT的优点：
随着测试工作量的增加，风险也会线性地下降。
如果优先测试高风险的地方，所以风险会有一个快速下降的过程，因此版本质量更加地能得到保证。版本发布时风险也会更低。
从测试完成率与对质量的信心上：
在随机策略下，用例的执行随着测试任务的完成率的提升，对系统的质量信心是一个线性提升的过程。
按照人性来做，其实人都是由惰性的，前期完成的都是简单的功能，比较困难的、深度的功能往往会放到后期，所以如果按照正常的人性来做测试的话，质量信心是一个缓慢上升的曲线。
基于风险的测试，对于质量信心的建立是快速上升的，因为优先测试的都是高风险的问题，所以随着完成率的增加，质量信心是一个快速提升的过程。
做RBT，对项目识别风险的能力要求是比较高的，对于功能等各种因素的梳理是比较详细的，如果准确率达不到要求，也很容易出现风险评估上的偏差。
基于模型的测试 - MBT
MBT: Model-based Testing
维基百科的定义如下：
它是一种软件测试的类型，它的测试用例是从一个模型当中完整或者部分导出得到的，这个模型描述了被测系统的某个方面，通常是功能部分。更多指的是对需求功能点建模，而不是对测试过程建模。
微软基于模型的测试的描述：https://blogs.msdn.microsoft.com/sechina/2009/11/18/123/
首先是从一组需求开始，通过这个需求创建一个机器可读的模型，这一步也是基于模型测试工作量最大的部分。在建模的过程中，会有一些反馈，发现需求当中的一些问题，来改进我们的需求。
模型建立完成以后，会生成测试用例，通过执行来控制被测系统，对待测系统会有一个期望输出的校验，最后来判定测试是否成功。如果测试失败了，可能是待测系统本身有问题，也有可能是模型建立的问题，甚至有可能是需求本身就有问题。所以通过模型的建立，反馈出系统中存在的问题。
基于模型的测试，更多的是一种借助测试工具建模，然后执行，所以说它更多地偏向自动化测试。
主要的MBT建模工具：
