软件测试按测试模式分类：
1.瀑布模型：
项目计划 （制定总体的研发计划，确定主要的里程碑节点－输出项目计划书）
需求分析（明确用户需求定义，并对定义进行清晰描述，充分理解需求，描述产品功能－ 输出产品需求规格说明）
软件设计－根据需求定义，设计产品的实现方案，包括定义软件硬件的结构、组件、实现方法、接口、界面、数据－输出概要设计、详细设计
程序开发－根据概要和详细设计具体实现，根据编程规范构建各类组件模块，输出产品版本。
软件测试－通过独立的测试小组评估产品是否满足需求定义－输出测试报告
集成维护－交付用户，根据用户使用情况进行维护及升级
优：
强调需求、设计的作用，保证用户需求有一个充分的了解
阶段分工明确
按阶段划分检查点，里程碑清晰
文档规范
缺：
难以适应需求变化
项目周期后段才能看到成果
强制里程碑、完成时间点，对变化不容易适应
产生大量文档，工作量大
从测试角度不能体现测试的价值和地位
V模型
是瀑布模型的变种
明确表明测试过程的不同级别，阶段 单元测试－集成测试－系统测试－验收测试
并且描述了各个阶段与开发过程各个阶段的对应关系
优点：
v模型 强调软件开发的协作和速度，反应测试活动和分析设计的关系，软件的实现和验证有机结合
缺点：
仅把关系明确对应，忽略了对需求分析的验证，对需求和功能的测试到验收测试才能发现；没有很好的体现测试的及时性
w模型
v模型的改进
增加了开发各个阶段的验证，测试的对象不再是对象，对需求和分析都有测试过程
有利于及于发现项目的风险，线性的相互关系，串行
不能很好的支持像迭代这样的模式
x模型
针对v模型的改进，主要解决交接和频繁周期的问题，左边是针对单独的程序片段所进行的相互分离的编码和测试，然后进行频繁的交接，再通过集成，最终合成可执行的程序，x模型还可以探索性测试，不进行事先计划，可以发现过多的错误
H模型
把测试当成一个完全独立的流程 便于尽早的完成测试，与其他流程并发进行，可以是任何流程，可交叉
2.敏捷测试
敏捷测试:Agile Testing—-遵循敏捷宣言的一种测试实践
敏捷宣言：个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
敏捷测试：强调从客户角度测试
重点关注迭代测试新功能，不在强调测试阶段
尽早测试，不间断测试，具备条件即测试
强调持续反馈
预防缺陷重于发现缺陷
敏捷测试VS传统测试：
传统测试 敏捷测试
测试是质量的最后保护者 开发和测试人员紧密合作，大家都有责任对软件负责
严格的变更管理 变更可以接受
预先的计划和细节准备 计划随着进展时常调整
重量级文档 只需要必要的文档
各阶段测试严格的入口和出口标准 各迭代之间没有明显入口和出口标准，更多在回归测试 时进行重量级自动化测试 所有阶段都要自动测试，每个 人都需要做，是项目集成一部分
测试 开发 相对独立 合作
3.基于脚本的测试
基于脚本的测试 SBT script-based testing 和ET【探索性测试】 互补
ST ET
系统性强 自由灵活
容易管理控制 和ST互补
设计在先，执行在后 执行和设计并行
主要是验证自己的思路 不断和系统交互，带着问题测试
可预见 学习的过程
4.基于风险的测试
基于风险的测试：RBT risk based testing一种基于对软件失效的风险评估并以此指导测试计划，设计，执行，结果评价的软件测试类型
风险包括 质量风险 管理风险
风险级别=风险可能性*风险严重度
5.探索式测试
探索式测试更适用于敏捷项目。测试管理上有局限性。只有在SUT完全可用下更有作用。生产率难定义。
输入 状态 代码路径 用户数据 执行环境
局部探索式测试
输入：接受输入，产生输出，存储数据，进行运算；
测试时：输入顺序，输入内容，输出异常
状态：临时状态（运行时有效，截断时有效）和永久状态（数据库保存，文件保存）
代码路径：对代码的覆盖，白盒测试
用户数据：最好真实；
执行坏境：软件运行的系统，网络拓扑，系统的配置数据，跟系统交互的第三方系统，运行系统的硬件设备
全局探索测试： 漫游测试法
基于模型的测试：MBT model based testing 对需求功能点建模 自动化
主要MBT工具：Spec Explorer GraphWalker Tcases modeljunit
结语：
最后跟大家推荐一个学习资料分享群：175317069，里面大牛已经为我们整理好了许多的学习资料，有自动化，接口，性能等等的学习资料！
人生是一个逆水行舟的过程，不进则退，咱们一起加油吧！
