测试
测试分类
1 动态测试：
-
运行被测程序，检查运行结果是否和预期的保持一致，分析运行效率的正确性和健壮性（融错性）
-
加法功能不正确：通过正向测试用例发现
-
输入参数不正确，无错误提示：通过反向测试用例发现
1.2 静态测试
-不运行被测程序，仅仅通过分析和检查源码来检查程序的正确性
2 软件开发过程模型
线性模型的一种，在所有的模型中占有重要地位，是其他模型的一个基础
每个阶段执行一次，按照线性模型的顺序进行软件开发
切入点：测试切入
有缺点
瀑布模型 地位：这是一种经典模型,提供了软件开发的基本框架。
优点: 1）各阶段划分清晰 2）强调计划与需求分析 3）适合需求稳定的产品开发 缺点: 1）单一流程，不可逆 2）风险显露得晚，纠正机会少 3）测试只是其中一个阶段，缺乏全过程测试思想 4）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。 5）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。 6）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
改良
- 沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代思想
应用场景
银行
保险
建筑
传统行业
2、螺旋模型
优缺点
优点 螺旋模型很大程度上是一-种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评 估。 缺点 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必 造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间。
应用场景
大型复杂项目
3、测试模型
单元测试
模块测试，针对软件设计中的最小单位--程序模块
集成测试
组装测试，在单元测试的基础上，将所有程序模块进行有序的，递增的测试，重点测试不同模块的接口部分
系统测试(system testing)：
指的是将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。 系统测试在系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。
验收测试
α测试：内测版本，在软件开发者内部交流，或者忠实粉丝之间发布，一般情况下bug比较多。
β测试：公测版，对所有用户开放的测试版本，bug相对少一些，免费的版本。
λ测试：正式版的后选版本。
优缺点
优点：相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。 缺点：虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析，系统设计的验证，时间效率上也大打折扣。 明确标注了测试过程中存在不同的测试类型，明确表示出了开发阶段与测试各阶段的对应关系。 单元测试：是否满足详细设计的要求 集成测试：验证已测试过的部分是否可以很好地结合在一起 系统测试：检验系统功能、性能是否达到系统的要求。 验收测试：确定软件的时限是否满足用户需求或合同需求
1、优点：包含了底层测试（单元测试）和高层测试（系统测试）；
清楚的标识了开发和测试的各个阶段；
自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。 2、缺点：自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；
实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。 改良：每个步骤都可以进行小的迭代工作。
4、w模型
优缺点
优点：
开发伴随着整个开发周期，需求和设计同样要测试； 更早的介入测试，可以发现初期的缺陷，修复成本低； 分阶段工作，方便项目整体管理。 缺点：
开发和测试依然是线性的关系，需求的变更和调整，依然不方便； 如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！ 管理成本很高 沟通成本很高
对比总结
v模型适用于中小企业，
w模型适用于中大型企业（因为人员要求高），
h模型人员要求非常高，很少有公司使用。
5、测试分类
功能测试
- 写测试用例
自动化测试
-
python
-
java
接口测试
postman
性能测试
例如一亿人同时访问
6、计算机基础
| 标题 | linux | |
|---|---|---|
| dir | 将当前目录展示 | ls |
| ipconfig | 查看网卡 | ifconfig |
| cd | 打开当前目录 | |
| md | 创建新的目录 | |
| echo | 输出某个文件 | |
| cd.. | 返回上一个目录 | |
| mkdir | 创建新的目录 | |
| del | 删除文件夹 | |
| rm-rf* | 这个会删除电脑里的所有文件 | 、 |
| copy | 复制 |
7、前端知识
- 1、web 三大核心 html （标签）一堆盒子 css 页面美化 js 行为动作 （事件:比如登录）
8、后端知识
cs/bs架构
1、cs架构定义
- client - server
- 客户端 - 服务器
优缺点
- 优点
- 客户端pc {安全性}
- 能够一部分功能在客户端处理完后，在提交给后端，速度快
- 操作界面很美观
- 缺点
- 不方便安装
- 兼容性比较差，不同系统需要不同的版本
- 开发和维护成本高
2、bs架构定义
- browser - server
- 浏览器 - 服务器
优缺点
- 优点
- 客户端0维护，只要有浏览器和网络就可以访问。
- 增加功能简单，只需要增加网页就可以了
- 不需要用户同步更新
- 开发简单
- 缺点
- 跨浏览器兼容
- 响应速度会慢些
- 速度和安全性花费巨大的设计成本
- 功能弱化
cs与bs的区别
- 效率
- cs效率高，一部分数据已经加载到系统
- bs每次都要加载到最新数据
- 版本升级
- cs需要删除旧的版本，更新新的版本
- bs（无缝升级）不需要升级，每次打开都是最新的版本。
- 安全
- cs更安全，下载、安转、注册、登录。、
- bs浏览器安全性低些。
- 成本
- cs成本更高，不同系统需要不同的开发人员。
- bs相对cs成本更低
9、文件格式
- xml 设计用来结构化，储存以及传输数据
标签成对出现
<note>
<to>georg</to>
<form>joho</form>
</note>
- json
- 是存储和交换文本信息的语法，类似 xml。
- josn比 xml 更小、更快，更易解析。
9、软件测试分类
1、按照测试阶段分析
- 单元测试：模块测试，是最小的程序模块
- 集成测试：在单元测试基础上将个个模块合在一起测试
- 系统测试：将整个软件看做一个整体，进行测试
- 验收测试：
- α测试：内测版本，在软件开发者内部交流或者在忠实粉丝之间发布，一般情况下。bug比较多
- β测试：对所有用户都开放的测试版本，bug相对少点
- γ测试：正式版本的后选版本
2、按照是否覆盖码源
- 黑盒测试：只关心业务逻辑（输出内容和输入内容）
- 白盒测试：研究的是码源，观察程序结构
- 灰盒测试：介于白盒和黑盒之间，灰盒测试用在集成测试阶段，不仅关注输出和输入也关注源码
- 灰盒关注点
- 测试输出
- 测试输入
- 代码逻辑
3、按照是否运行来划分
- 静态测试
- 动态测试
- 3.1静态测试定义
- 不运行被测试，仅仅通过分析和检查源码中的语法结构、过程和接口来检查程序的正确性
- 3.2静态测试（测试对象）
- 源码---白盒测试
- 3.3动态测试定义
- 运行被测程序，检查和运行结果对否和预期结果保持一致，分析运行效率的正确性和健壮性（融错性）
- 3.4动态测试（测试对象）
- 源码---运行
4、是否按照自动化划分
- 4.1手工测试
- 4.2 手工测试定义
- 手动执行测试用例的过程
- 4.3缺点
- 效率低
- 重复工作高
- 4.5自动化测试
- 利用工具或者代码去帮助执行相关测试用例
- web 自动化
- app 自动化
10 其他测试
- 1、冒烟测试
- 对于我们当前系统进行最基础功能测试，保证基础的功能和流程能够走通
- 2、回归测试
- 开发修改了旧代码之后，测试重新进行测试，确认本次代码修改有没有引入新的错误或者导致其他代码出现错误
- bug 回归
- 旧功能
- 3、回归原则：
- 需要轮次：取决于项目的复杂度和规模
- N 版本：
- 需要进行N+1次回归测试
- 缺点
- 重复性工作大
- 效率低
- 解决方法
- 定义：根据测试者的经验对软件进行功能和性能的抽查
- 注重点:对重要的功能进行重复测试 - 对没有覆盖到的模块进行测试
- 探索性测试
-（是测试的思维技术）
- 同时设计测试和执行测试是一个思维技术
