按测试阶段分类：

单元测试：

对软件中最小可测试单元的检查和验证

   原则：独立性，测试人员为编程人员或者了解源代码的人员

   好处：能在前期发现bug，在重构（？）是避免相同错误，简化集成（？），体现设计理念

   局限性：要4行左右的代码来对原1行代码进行测试，投入与产出；不能发现所有bug

集成测试：

对已经进过单元测试的模块所组成的模块火子系统进行集成

   方案：bigboom（打包好一起测试），顺序测试（从顶层开始），反向测试（从底层开始），由核心向外围，高频集成

单元测试&集成测试：1，测试对象

  2.测试依据

  3.测试方法：单元位于内部，集成倾向接口

系统测试；重点

对经过集成测试的模块在实际计算机系统中进行各方面的测试

关注点：被测系统和其他系统的兼容性，在真实环境的表现，在各种压力下的表现

系统测试&集成测试;对象不同:集成（集成厚德模块），系统（各个环境和）

 时间不同

 内容不同：集成（接口）系统（功能，性能）

 角度不同;集成（技术）系统（业务）

验收测试：

对比客户的需求和业务的流程来进行最后测试，决定系统是否被客户用户所接受

用户验收测试：

运行验收测试：

合同和规范验收测试：

alpha测试：开发者提供场所，用户测试

beta测试;用户场所，用户测试

 黑盒测试：无法看到软件如何运行，之考虑结果是否符合要求，测试其功能

 白盒测试：测试人员了解内部的结构，通过代码来判断有可能出现的bug

  优点，可以在代码阶段发现问题，可以完全覆盖

  缺点,不能验证需求

 静态测试，测试软件不运行的部分

 动态测试，运行软件，检查运行结果，分析运行效率、正确性等

 手工测试，从用户视角来验证软件是否满足需求，主观（灵活，能发现缺陷的概率大，蛋效率低，不同人的水平参差）

 自动化测试，使用第三方软件自动化执行测试过程，并对结果进行自动检查（效率高，过程不变，适合大量，重复工作，但发现缺陷单一）

测试模式：

 瀑布模型：一个阶段完成菜开始下一阶段

  分工明确，文档规范，不能适应需求变化，完成时间确定，结果只有最后才能体现

 V模型：

 W模型：V的改进

 H模型：

 敏捷测试： 从客户角度，尽早、不间断测试，持续反馈，预防大于发现，团队

 基于脚本的测试-SBT：系统的

 探索式测试：抛开测试脚本，它是一种思想，自由的

  优点：增加兴趣，发现bug更快，有利于自动化，减少编写

  缺点：难于管控，依赖测试人员，本身难于自动化

 基于风险的测试-RBT：对风险进行评估后设计车来的测试方案

  质量风险，管理风险，风险=可能性*严重程度

  优点：质量保证，降低风险，前期处理高风险缺陷

 基于模型测试-MBT：需求的模型，偏向自动化

基本都是看的过程记得笔记，还在看一本书，但感觉和视频的模式完全不一样

最后我不是很懂任务是什么意思，还不是很明白如何修真0.0