1.0软件开发过程模型
1.0.1 瀑布模型
1.0.1.1 定义
线性模型的一种，在所有的模型中占有重要地位，是其他模型的一个基础
每个阶段执行一次，按照线性模型的顺序进行软件开发
测试的切入点：
测试阶段处于软件实现后，必须在代码完成后留出足够多的时间给测试活动，否则导致测试不充分，很多问题在项目后期才暴露、
1.0.1.2 优缺点
瀑布模型
地位：这是一种经典模型,提供了软件开发的基本框架。
优点:
1）各阶段划分清晰
2）强调计划与需求分析
3）适合需求稳定的产品开发
缺点:
1）单一流程，不可逆
2）风险显露得晚，纠正机会少
3）测试只是其中一个阶段，缺乏全过程测试思想
4）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
5）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。
6）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
1.0.1.3 改良
沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代思想
1.0.1.4 应用场景
银行
保险
建筑
传统行业
1.0.2 快速原型模型
1.0.2.1 原型阶段
| 快速分析 | |
| 需求说明 | |
| 构造原型 | |
| 原型 | |
| 运行原型 | |
| 评价原型 | |
| 修改意见 |
1.0.2.2 步骤
step1
建造一个快速原型，实现用户和系统的交互，用户对原型进行评价，进一步细化待开发软件的需求，通过逐步调整原型使其满足用户的要求，开发人员可以确定用户真正的需求
step 2
在第一步的基础上开发出用户满意的软件产品
1.0.2.3 优缺点
优点
克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。适合预先不能确切定义需求的软件系统的开发。
缺点：
不适合大型系统的开发(适合开发小型的、灵活性高的系统)前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
1.0.2.4 应用场景
微信
抖音
互联网行业
1.0.3 螺旋模型
1.0.3.1 模型
本质上，将线性模型实现多遍
比较浪费时间，在实际的开发中，使用比较少
1.0.3.2 优缺点
优点：
螺旋模型很大程度上是一-种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评
估。
缺点：
采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必
造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间。
1.0.3.3 应用场景
大型复杂项目
1.0.4 三种开发模型的区别
| 需求 | 项目规模 | 模型 |
|---|---|---|
| 清晰 | 大 | 瀑布模型 |
| 不清晰 | 中小型 | 快速原型 |
| 不清晰 | 大 | 螺旋模型 |
2.0测试模型
2.0.1 V模型
2.0.1.1 模型(背会)
2.0.1.2 单元测试
模块测试，针对软件设计中的最小单位--程序模块
又称模块测诚，针对软件设计中的最小单位—程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。 单元定义：C中指一个函数，Java中指一个类，在图形化的软件中，单元一般指1个窗口，1个菜单。
2.0.1.3 集成测试
组装测试，在单元测试的基础上，将所有程序模块进行有序的，递增的测试，重点测试不同模块的接口部分
2.0.1.4 系统测试(system testing)：
指的是将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。 系统测试在系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。
2.0.1.5 验收测试
α测试：Alpha是内测版本，即现在所说的C8，比版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件的bug较多，普通用户最好不要安装。
β测试：Beta是公测版本，是对所有用户开放的测试版本。该版本相对于a颜已有了很大的改进，消除了严重的错误，但还是存在着一些陷需要经过大规模的发布试来进一步消除。这一版本通常由软件公司免费发布，用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户安装。
λ测试：Camma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了，与即将发行的正式版相差无几，成为正式反布的候选版本。
软件正式版本推出之前的几个版本，需要有人测试一下，看看是不是有问题。在开发该软件的公司内部的由该公司内部人员式的称为：Alpha测试，Alpha 测式主要看有没有功能缺失或系统错误，Alpha 测试完后一般不会有大问题了。然后巴软件拿给用户测试称为：beta 测试，主要是看用户对软件外观、使用方便等的反应。这么多的式版一方面为了最终产品尽可能地满足用户的需要，另一方面也尽量成少了软件中的bug。然后做过一些修改，成为正式发布的候选版本时，叫做gamma（现在叫做RC-ReleaseCandidate)。 简单来说，阿尔法测试主要是测试人员在开发环境下的测试，贝塔测试是在实际环境中的测试，或者公司内部人员在模拟真实环境中的测试。
2.0.1.6 优缺点
优点：相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。
缺点：虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析，系统设计的验证，时间效率上也大打折扣。
明确标注了测试过程中存在不同的测试类型，明确表示出了开发阶段与测试各阶段的对应关系。
单元测试：是否满足详细设计的要求
集成测试：验证已测试过的部分是否可以很好地结合在一起
系统测试：检验系统功能、性能是否达到系统的要求。
验收测试：确定软件的时限是否满足用户需求或合同需求
1、优点：包含了底层测试（单元测试）和高层测试（系统测试）；
清楚的标识了开发和测试的各个阶段；
自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
2、缺点：自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；
实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。
改良：每个步骤都可以进行小的迭代工作。
2.0.2 w模型
2.0.2.1 模型
2.0.2.2 优缺点
优点：
测试伴随着整个开发周期，需求和设计同样要测试；
更早的介入测试，可以发现初期的缺陷，修复成本低；
分阶段工作，方便项目整体管理。
缺点：
开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！
管理成本很高
沟通成本很高
2.0.3 H模型
2.0.3.1 模型
2.0.3.2 优缺点
H模型的优点：
>开发的H模型揭示了软件测试除测试执行外，还有很多工作；
>软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
>软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
>软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。
H模型的缺点：
>管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
>技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
>测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
>对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。
2.0.4 对比总结
v模型适用于中小企业，
w模型适用于中大型企业（因为人员要求高），
h模型人员要求非常高，很少有公司使用。
软件测试的分类
3.0按照测试阶段来细分
单元测试：模块测试，是最小的程序模块
集成测试：在单元测试的基础上，将各个模块合在一起测试
系统测试：将整个的软件系统，看做一个整体，进行测试
验收测试：
α测试：内测版本，在软件开发者内部交流，或者忠实的粉丝之间发布，一般情况下，都是bug比较多的，普通用户不建议安装
β测试：对所有的用户开发的测试版本，bug会相对少一些，免费发布
γ测试：正式版本的候选版本
3.1按是否覆盖原码分类
3.1.1黑盒测试
只关注业务逻辑，输入内容和输出内容
3.1.2白盒测试
a = 1
b = 1
sum = a+b
print(sum)
研究的是源码，观察程序结构
3.1.3灰盒测试
介于黑盒测试和白盒测试之间，用在集成测试阶段，不仅关注输入输出，也关注源码 测试关注点：测试输入，测试输出，代码逻辑
3.2按照是否运行划分
3.2.1静态测试
3.2.1.1定义
不运行被测程序，仅通过分析和检查源码中的语法、结构、过程和接口来检查程序的正确性
3.2.1.2测试对象
源码====》白盒测试 sql脚本
文档：
需求文档
各种设计文档，比如数据库设计文档
3.2.2动态测试
3.2.2.1定义
运行被测程序，检查运行的结果是否和预期结果保持一致，分析运行效率，正确性和健壮性
3.2.2.2测试对象
源码====》运行
系统
3.3 按照是否自动化进行划分
3.3.1手工测试
3.3.1.1定义
手动执行测试用例的过程
3.3.1.2缺点
效率低
重复工作高
3.3.2自动化测试
利用工具或者代码帮助执行相关测试用例，如web自动化，app自动化
3.4其他
3.4.1冒烟测试（重点）
针对当前的系统进行的最基本功能的测试，保证基本的功能和流程能够走通
3.4.2回归测试（重点）
3.4.2.1定义
开发修改了旧代码后，测试人员重新进行测试，确认本次代码修改是否引入新的错误，或者导致其他代码出现错误。
Bug回归
旧功能回归
3.4.2.2回归原则
需要轮次 取决于项目复杂度和规模 n版本需要进行n-1此回归测试
3.4.2.3缺点
重复性工作大，效率较低
3.4.2.4解决方法
自动化测试：自动回归测试
3.4.3随机测试
3.4.3.1定义
根据测试者的经验，对软件进行功能和性能的抽查
3.4.3.2注重点
对重要功能进行复测
对没有覆盖到的模块进行测试
3.4.4探索性测试
同时设计测试和执行测试，是一种测试思维技术
