1.
2.
2001年提出
3.敏捷测试的特点
第二点：传统测试中严格阶段的划分，敏捷测试中并不强调（单元测试、集成测试、系统测试、验收测试，没有这种阶段的划分）
第三点：比如某个模块的功能编写完了，就要开始测试，这和我们前面讲到的H模型基本上是一样的。
第四点：比如利用敏捷方法中的看板方法，及时将当前状况反馈给项目组成员。
4.
最后一个重量级文档，每个阶段会出现详细的文档，测试计划、功能等
可用软件重于完备文档
5.基于脚本的测试-SBT
也叫ST
强调的是先做测试设计，然后再执行设计。
scripted在手工测试中更多的指的是测试用例；而在自动化测试中指的就是自动化测试的脚本。
ET是探索式测试。
ET一般是通过探索我们的被测系统，带着问题使用我们的被测系统，在探索过程中发现测试要点，找出测试问题。
测试过程中，测试设计和测试执行是并行的。ET的执行对测试人员来说会更加自由，所以ET会更加依赖测试人员的责任
项目中ST和ET一般都会使用到
从实际项目的实施上，pure scripted是完全的ST，完全参照测试用例来执行，而且用例编写会非常详细。
Freestyle ET是指完全自由的ET，没有任何文档做支持，也不会对测试过程的要点进行记录。这是两个极端。
Vague Scripted：用例编写比较模糊，比如对预期结果执行步骤的描述就会相对简单。
Fragmentary test cases：测试用例不会归成文档，可能只会用一两句话描述测试思路，也可以看做是测试点的清单。
charters：更偏向ET，ET会列出一个详细的任务列表，在列表中指出测试对象、测试的策略并指出可能的风险，参考的文档等。
roles：只是给定测试人员一个给定的角色，测试人员从这个角色出发，测试进度、质量都是测试人员自己掌握。
比较ST和ET
探索式测试的优点
SUT：soft and test 测试系统
缺点：
SUT被测系统，因为探索式测试强调和被测系统之间不断地交互，有一个深度学习的过程，所以在系统还不能完全可用的情况下，它的作用是有限的。
因为测试过程如何、完成度如何，很难有一个量化的指标
更多依赖于测试人员个人技能和创造性
局部探索
对于输入，测试时基本任务包括：接受输入、产生输出、存储数据、进行运算。测试时从输入顺序、输入内容、输出异常角度来考虑测试要点。
状态：临时状态（运行时有效、阶段有效），永久状态（数据库保存、文件保存）。状态信息可以帮助我们更加有效的判断测试输入和测试输出。
代码路径：更多的是测试覆盖（详见白盒测试的方法）
用户数据：测试尽量模拟真实数据，或者构造合理的测试数据
执行环境：操作系统，网络拓扑，第三方系统、配置数据、运行设备
全局探索
让测试人员像游客游览一样测试被测系统，并把测试系统按照不同的属性分成不同区域针对测试。
商业区：用户从启动到关闭主要可能使用的一些功能
旅馆区：软件休息或没有实际运行时候的功能，一般是后台进程或者是定时任务
历史区：版本历史遗留代码中的一些功能，或者是以前测试中问题比较多的功能
旅游区：新用户会使用的或比较关注的功能，比如新用户注册或者新手指引
娱乐区：系统主要功能之外的辅助特性或功能
破旧区：系统已经废弃或者隐藏的一些功能，一般没有在用户手册提及
探索式测试的流程：
know you：需要了解测试任务重点、主要测试方向、系统环境
learning:相惜学习和探索被测系统，了解系统业务逻辑和功能
coverage:主要实施阶段，完成主要功能点的测试验收和测试点的覆盖
deep:上一阶段覆盖基础上进一步挖掘深层次东西
close:对前面的测试工作的总结，整理测试信息，根据记录总结分析有没有遗漏
大扫除行动：对close中遗漏进行再次测试
6.RBT基于风险的测试
有什么风险？
被测系统的质量风险：软件功能、应用性、软件缺失等
管理风险：人员技能不足、人力不足、测试环境不具备、被测系统需求不清晰、关联第三方有问题
风险的识别
可能性：
项目周期时间紧张，风险更高。
需求变化快，风险高。
地理分散度，研发团队太过分散影响效率
严重程度：
使用频率越高，风险越严重。
失效更加可见，失效可视性
商业损失，损失越大问题越严重（计费功能）
组织负面影响和损害（可口可乐系统中出现百事可乐logo；快播被禁）
RBT优点
优先测试高风险，测试工作增加，风险降低
基于人性，刚开始会比较懒惰，会先做简单的
但是RBT对于项目识别风险能能力要求比较高，对功能和各种要素梳理要求比较详细，如果准确率达不到要求，很容易产生评估偏差。
7.MBT-基于模型的测试
一种软件测试类型，测试用例使用一个模型中完整或部分导出得到的。这个模型描述了被测系统的某些方面，通常是功能部分。
这里的模型，更多指对需求功能点的模型而不是过程模型（w v ）
更多偏向于自动化测试