1.0 软件的生命周期
1.0.1 计划
项目经理完成
1.0.2 需求分析
加法功能：十进制加法，有两个输入参数（参数1、参数2），有1个结果输出（结果）； 点击加法按钮能获取参数1和参数2的和，和在结果输出中显示。
需要包含错误处理
界面
1.0.3 设计
考虑加法按钮如何实现：结果中显示两个参数的和
即：主要对加法按钮的处理，点击按钮后，结果文本框的取值=参数1文本框的取值+参数2文本框的取值
1.0.4 编码
python实现
1.0.5 测试
1.0.5.1 动态测试：
检查实际结果和期望值结果是否一致
加法功能不正确：通过正向测试用例发现
输入参数不正确，无错误提示：通过反向测试用例发现
1.0.5.2 静态测试
检查需求或者设计是否有遗漏
1.0.5.3 新的需求
新增减法，乘法，除法等额外功能
1.1 软件开发过程模型(了解)
1.1.1 瀑布模型
1.1.1.1 定义
线性模型的一种，在所有的模型中占有重要地位，是其他模型的一个基础
每个阶段执行一次，按照线性模型的顺序进行软件开发
测试的切入点：
测试阶段处于软件实现后，必须在代码完成后留出足够多的时间给测试活动，否则导致测试不充分，很多问题在项目后期才暴露
1.1.1.2 优点缺点
瀑布模型
地位：这是一种经典模型,提供了软件开发的基本框架。
优点:
1）各阶段划分清晰
2）强调计划与需求分析
3）适合需求稳定的产品开发
缺点:
1）单一流程，不可逆
2）风险显露得晚，纠正机会少
3）测试只是其中一个阶段，缺乏全过程测试思想
4）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
5）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。
6）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果.
1.1.1.3 改良
沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代思想
1.1.1.4 应用场景
- 银行
- 保险
- 建筑
- 传统行业
1.1.2 快速原型模型
1.1.2.1 原型阶段
| 快速分析 | |
| 需求说明 | |
| 构造原型 | |
| 原型 | |
| 运行原型 | |
| 评价原型 | |
| 修改意见 |
1.1.2.2 步骤
step1
建造一个快速原型，实现用户和系统的交互，用户对原型进行评价，进一步细化待开发软件的需求，通过逐步调整原型使其满足用户的要求，开发人员可以确定用户真正的需求
step 2
在第一步的基础上开发出用户满意的软件产品
1.1.2.3 优缺点
优点
克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。适合预先不能确切定义需求的软件系统的开发。
缺点
不适合大型系统的开发(适合开发小型的、灵活性高的系统)前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
1.1.2.4 应用场景
- 微信
- 抖音
- 互联网行业
1.1.3 螺旋模型
1.1.3.1 模型
本质上，将线性模型实现多遍
比较浪费时间，在实际的开发中，使用比较少
1.1.3.2 优缺点
优点
螺旋模型很大程度上是一-种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
缺点
采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必
造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间。
1.1.3.3 应用场景
大型复杂项目
1.1.4 三种开发模型的区别
| 需求 | 项目规模 | 模型 |
|---|---|---|
| 清晰 | 大 | 瀑布模型 |
| 不清晰 | 中小型 | 快速原型 |
| 不清晰 | 大 | 螺旋模型 |
1.2 测试模型
1.2.1 V模型
1.2.1.1 模型
1.2.1.2 单元测试
模块测试，针对软件设计中的最小单位--程序模块
又称模块测诚，针对软件设计中的最小单位—程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。 单元定义：C中指一个函数，Java中指一个类，在图形化的软件中，单元一般指1个窗口，1个菜单。
1.2.1.3 集成测试
组装测试，在单元测试的基础上，将所有程序模块进行有序的，递增的测试，重点测试不同模块的接口部分
1.2.1.4 系统测试(system testing)：
指的是将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。 系统测试在系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。
1.2.1.5 验收测试
α测试：Alpha是内测版本，即现在所说的C8，比版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件的bug较多，普通用户最好不要安装。
β测试：Beta是公测版本，是对所有用户开放的测试版本。该版本相对于a颜已有了很大的改进，消除了严重的错误，但还是存在着一些陷需要经过大规模的发布试来进一步消除。这一版本通常由软件公司免费发布，用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户安装。
λ测试：Camma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了，与即将发行的正式版相差无几，成为正式反布的候选版本。
软件正式版本推出之前的几个版本，需要有人测试一下，看看是不是有问题。在开发该软件的公司内部的由该公司内部人员式的称为：Alpha测试，Alpha 测式主要看有没有功能缺失或系统错误，Alpha 测试完后一般不会有大问题了。然后巴软件拿给用户测试称为：beta 测试，主要是看用户对软件外观、使用方便等的反应。这么多的式版一方面为了最终产品尽可能地满足用户的需要，另一方面也尽量成少了软件中的bug。然后做过一些修改，成为正式发布的候选版本时，叫做gamma（现在叫做RC-ReleaseCandidate)。 简单来说，阿尔法测试主要是测试人员在开发环境下的测试，贝塔测试是在实际环境中的测试，或者公司内部人员在模拟真实环境中的测试。
1.2.1.6 优缺点
优点：相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。
缺点：虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析，系统设计的验证，时间效率上也大打折扣。
明确标注了测试过程中存在不同的测试类型，明确表示出了开发阶段与测试各阶段的对应关系。
单元测试：是否满足详细设计的要求
集成测试：验证已测试过的部分是否可以很好地结合在一起
系统测试：检验系统功能、性能是否达到系统的要求。
验收测试：确定软件的时限是否满足用户需求或合同需求
1、优点：包含了底层测试（单元测试）和高层测试（系统测试）；
清楚的标识了开发和测试的各个阶段；
自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
2、缺点：自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；
实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。
改良：每个步骤都可以进行小的迭代工作。
1.2.2 w模型
1.2.2.1 模型
1.2.2.2 优缺点
优点：
开发伴随着整个开发周期，需求和设计同样要测试；
更早的介入测试，可以发现初期的缺陷，修复成本低；
分阶段工作，方便项目整体管理。
缺点：
开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！
管理成本很高
沟通成本很高
1.2.3 H模型
1.2.3.1 模型
1.2.3.2 优缺点
H模型的优点：
>开发的H模型揭示了软件测试除测试执行外，还有很多工作；
>软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
>软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
>软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。
H模型的缺点：
>管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
>技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
>测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
>对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。
1.2.4 对比总结
v模型适用于中小企业，
w模型适用于中大型企业（因为人员要求高），
h模型人员要求非常高，很少有公司使用。
2.0 测试的分类
2.1 功能测试
- 写测试用例
2.2 自动化测试
1.python
1.java
2.3 接口测试
1.postman
2.4 性能测试
- 使用JMerer
3.0 计算机基础
3.1 dos命令
| Linux | ||
|---|---|---|
| dir | 将当前目录的内容展示 | ls |
| ipconfig | 查看网卡 | ifconfig |
| cd | 打开当前的路径 | cd |
| md | 创建新目录 | |
| echo | echo data>文件 | |
| del | 删除文件 | |
| copy | copy 文件的原路径 文件的新路径 | |
| move |
4.0 前端知识
4.1 web3大核心
-
html 标签--堆盒子
-
css 将页面美化
-
js 行为动作
5.0 后端知识
5.1 cs/bs
5.1.1 cs
5.1.1.1 定义
client-server 客户端-服务端
5.1.1.2 优缺点
优点：
客户端pc 能够处理一部分功能，可以让客户端处理完成之后，再提交给后端，相应速度快
操作界面很美观
安全性
缺点：
1.不方便安装
2.兼容性比较差，不同的系统需要不同的版本
3.开发和维护成本比较高
5.2 BS架构
5.2.1 定义
browser-server 浏览器--服务器
5.2.2 优缺点
优点:
- 客户端0维护，只要有浏览器和网络，就可以进行访问
- 增加功能简单，只需要增加网页就可以完成
- 不需要用户进行同步更新
- 开发简单
缺点：
1. 跨浏览器兼容
2. 响应速度会慢一些
3. 速度和安全性花费巨大的设计成本
4. 功能弱化
5.3 cs与bs的区别
| cs | bs | |
|---|---|---|
| 效率 | cs效率比较高，一部分数据已经加载到系统 | bs每次都需要加载最新的数据 |
| 版本升级 | 删除旧版本，更新新版本 | 无缝升级 |
| 安全 | cs更安全，下载，安装，注册，登录 | 浏览器 |
| 开发成本 | 不同的系统需要不同的开发人员，成本高 | 相对成本低 |
5.4 文件格式
5.4.1 xml
5.4.1.1 案例
<note>
<to>George</to>
<from>John</from>
<heading>Reminder</heading>
<body>Don't forget the meeting!</body>
</note>
5.4.2 json
5.4.2.1 案例
6.0 软件测试分类
6.1 按照测试阶段来细分
单元测试：模块测试，是最小的程序模块
集成测试：在单元测试的基础上，将各个模块合在一起测试
系统测试：将整个的软件系统，看作一个整体，进行测试
验收测试：
α测试：内测版本，在软件开发者内部交流，或者忠实的粉丝之间发布，一般情况下，都是bug比较多的，普通用户不建议安装
β测试：对所有的用户开发的测试版本，bug会相对少一些，免费发布
γ测试：正式版本的候选版本
6.2 按照是否覆盖源码
6.2.1 黑盒测试
只关注业务逻辑，输入内容和输出内容
6.2.2 白盒测试
- 研究的是源码，观察程序结构
6.2.3 灰盒测试
介于二者之间，灰盒测试用在集成测试阶段，不仅关注输入和输出，也关注源码
测试关注点：
测试输入
测试输出
代码逻辑
6.3 按照是否运行来划分
6.3.1 静态测试
6.3.1.1 定义
不运行被测程序，仅仅通过分析和检查源码中的语法，结构，过程和接口，来检查程序的正确性
6.3.1.2 测试对象
源码 =====>白盒测试
sql脚本
文档：
需求文档
各种设计文档，比如数据库设计文档
6.3.2 动态测试
6.3.2.1 定义
运行被测程序，检查运行的结果是否和预期结果保持一致，分析运行效率，正确性和健壮性
6.3.2.2 测试对象
源码======>运行
系统
6.4 按照是否自动化来进行划分
6.4.1 手工测试
6.4.1.1 定义
手动执行测试用例的过程
6.4.1.2 缺点
效率低
重复工作高
6.4.2 自动化测试
利用工具或者代码去帮助执行相关测试用例
web自动化
app自动化
6.5 其他
6.5.1 冒烟测试(重点)
针对当前的西贡进行的最基本功能的测试，保证基本的功能和流程能够走通
6.5.2 回归测试(重点)
6.5.2.1 定义
开发修改了旧代码之后，测试重新进行测试确认本次代码修改有没有引入新的错误或者导致其他代码出现错误
Bug回归
旧功能回归
6.5.2.2 回归原则
需要轮次：
取决于项目的复杂度和规模
N版本，需要进行N-1次回归测试
6.5.2.3 缺点
重复性工作大
效率低
6.5.2.4 解决方法
自动化测试：自动回归测试
6.5.3 随机测试
6.5.3.1 定义
根据测试者的经验对软件进行性能和功能的抽查
6.5.3.2 注重点
对重要功能进行复测
对没有覆盖到的模块进行测试
6.5.4 探索性测试
同时设计测试和执行测试，是一种测试思维技术
7.0 软件的质量模型(了解)
| 功能性 | 检查业务功能是否满足需求 |
| 可靠性 | 容错能力(恢复时间，恢复能力) |
| 易用性 | 看得懂，会使用 |
| 效率性 | 性能(响应时间，消耗的资源(CPU,内存)) |
| 维护性 | 为后续功能的开发和维护提供便利 |
| 移植性 | 软件需要在不同的软件环境下和硬件环境下都能正常工作 |
| 信息安全性 | 信息在传输过程中或者存储过程中的安全程度 |
8.0 软件的测试用例
8.1 软件的测试用例概念
一个为了特地的目的而设计的文档，文档的形式可是是excel，xmind等，
Test Case
8.2 模板
ID:
唯一值
模块：
测试用例所属的模块
优先级：
作用：体现了测试用例的执行先后顺序
分类：高 中 低
P0:一般是保证软件中最重要、最主要的功能，保证最基本的流程能够正常运行而设计的
P1：次要功能，小功能
P2：UI,边界，错误设置
P3：错误信息，较为复杂的场景，不常用的场景
用例标题：
唯一性
见名知意
预置条件：
前提条件
测试步骤：
要求：尽可能详细
测试数据：
根据要求填写
预期结果：
根据数据和步骤，预期的结果
测试结果：
pass
fail
block 由于存在bug不能继续执行填写
Na 由于环境或者资源缺失导致不能执行
测试版本号：
当前测试任务所用的软件版本号
测试人员：
略
备注：
fail 的用例问题和对应的BugID填写
block NA需要在备注中填写原因
8.3 测试用例的作用
便于理清测试思路，确保需要覆盖测试的功能点无缺失
便于估计测试工作量
便于提前准备测试数据
便于把控测试的工作进度
便于回归测试
便于测试工作的组织，提高测试效率，降低测试的交接成本
9.0 等价类划分法(重要)
10.0 边界值分析法(重要)
10.1 边界范围的确定
选取正好等于，或者刚好大于，挥着正好小于边界值的数据作为测试数据
10.2 上点，离点 ，内点
| 上点 | 边界上的点 |
|---|---|
| 内点 | 区间范围内的点 |
| 离点 | 距离上点距离最近的点，刚好大于，正好小于 |
10.3 边界值设计用例的步骤
1.明确需求
2.确定有效类和无效类
3.确定边界值范围
4.提取数据编写测试用例
10.4 7位-------->5位
| 内点 | 必选，尽量选择中间范围的 |
|---|---|
| 上点 | 必选的 |
| 离点 | 根据开闭情况进行选择 |
9.5 等价划分法使用场景
- 具有典型的输入框的业务场景
- 比如：邮箱注册，用户注册等
11.0 判定表(重要)
11.1 判定表的定义
一种以表格形式表达的多条件逻辑判断工具
11.2 组成部分
| 条件桩 | 列出当前问题中，所有的条件，次序没有影响 |
| 动作桩 | 列出当前问题中所有的可能性操作，没有次序的影响 |
| 条件项 | 列出条件对应的取值，所有可能性的真假值 |
| 动作项 | 列出条件项的各种取值情况下，对应采取的动作结果 |
11.3 设计测试用例的步骤
1.明确条件桩(找到所有的输入条件)
2.明确动作桩(找到所有的输出结果)
3.对所有的条件桩进行全组合
4.明确每一个组合对应的动作桩
5.设计测试用例，每一条数据，对应了一个测试用例
12.0 因果图
12.1 展示图
12.2基本符号
| V | 或 | 只要一个条件成立就可以 |
| 与 | 多个条件同时成立 | |
| ~ | 非 | 条件成立，则结果不成立；条件不成立，则结果成立 |
| - | 恒成立 | 条件成立，结果成立 |
12.3 步骤
实例分析
产品说明书：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”、或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。
（1）确定需求中的原因与结果
（2）确定原因与结果的逻辑关系
C1 与 C2 需要一个中间结果Cm1, C3、C4、C5 需要一个中间结果Cm2.
（3）确定因果图中的约束
C1 与 C2 是或的关系, C3、C4、C5 是或的关系。
（4）画出因果图并转化为决策表
决策表
将原因C1、C2、C3、C4、C5按二进制由小到大分别取值，并分析中间结果的成立与否，进而得出下面的简化版（即中间结果Cm1、Cm2成立的情况）
简化版
5）根据决策表设计测试用例
- 需求分析
- 画出因果图
- 将因果图转换成判定表
- 生成对应的测试用例
13.正交法
13.1 定义
- 用最小的测试用例获得最大的测试覆盖率
13.2 基本定义
- 因素：条件桩，输入的参数条件，电量，绿码
- 水平：输入参数的取值充足，无就是电量的水平
13.3 使用步骤
- 需求分析
- 确定因素和水平
- 确定正交表
- 根据正交表，进行测试用例的书写，一条数据就是一条测试用例
14.场景法
- 画流程图
14.1 定义
- 场景法，就是流程图发，使用流程图来描述用户的使用场景，然后通过流程图路径来设计测试用例
14.2 案例 点外卖
14.3 使用的测试阶段
- 集成测试
- 系统测试
- 验收测试
14.4 使用步骤
- 需求分析
- 绘制流程图
- 根据流程图的每一条路径进行设计测试用例
15.错误推测法
15.1 定义
- 根据经验和智慧进行分析，推测出程序中可能出现的错误
15.2 使用场景
- 同类型产品
- 任务紧
16. 测试用例方法总结
- 具有输入功能，但是功能之间没有组合关系 等价类
- 输入具有边界，比如长度 边界值
- 多输入。多输出，输入和输出之间具有组合关系，判定表，因果图
- 用最小的测试用例覆盖率高最高是，正交表
- 多个功能之间的组合测试 场景法
- 错误推测法 做进一步的补充
17.软件缺陷
17.1 定义
- 软件在使用的过程中存在的任何问题（错误，异常等），都叫做软件缺陷，简称bug
17.2 软件缺陷的判定标准
17.2.1 软件未实现需求说明书中明确要求的功能
17.2.2 软件出现了需求说明书中知名的不应该出现的错误
17.2.3 软件实现了超出需求说明书中的功能
17.2.4 软件未实现需求文档中未指明但是又应该实现的功能
17.2.5 用户体验不好，界面不漂亮 易用等
17.3 软件缺陷的原因
17.3.1 编码
- 代码出错
17.3.2 运行系统
- 软硬件系统本身故障导致的软件缺陷
17.3.3 设计问题
- 设计文档出现错误或者缺陷
17.3.4 需求阶段
- 需求描述有歧义
17.3.5 软件本身很复杂
17.4 软件缺陷的核心内容（重点）
| 标题 | 描述软件缺陷的基本信息，例如（用户名5位，只展示3位） |
|---|---|
| 前置条件 | 描述缺陷出现依赖的相关基础条件 |
| 复现步骤 | 测试用例里的执行步骤， |
| 实际结果 | 执行测试用例的执行步骤，系统给出的结果 |
| 预期结果 | 参照需求说明书，在测试用例中设计的预期结果 |
| 附件 | bug截图或者出错的日志信息，方便定位Bug的 |
17.5 缺陷的基本要素
17.5.1 ID
- 唯一
17.5.2模块
- 根据产品进行具体的划分，支付模块，订单模块等
17.5.3 缺陷状态
| new | 新建 |
|---|---|
| open | 打开 |
| fix | 已经修复 |
| postpone | 延期 |
| reject | 拒绝 |
| close | 关闭 |
| reopen | 重新打开 |
17.5.4 缺陷的严重程度
- 从技术上衡量bug的破坏力
| 致命 | 5 | critical |
|---|---|---|
| 非常高 | 4 | major |
| 高 | 3 | medium |
| 中 | 2 | minor |
| 低 | 1 | tiny |
17.5.5 缺陷的优先级
- 处理缺陷的优先程度
| 紧急 | 5 | |
|---|---|---|
| 非常高 | 4 | |
| 高 | 3 | |
| 中 | 2 | |
| 低 | 1 | |
17.5.6 缺陷类别
- 功能错误
- UI界面错误
- 兼容性错误
- 易用性
- 改进意见
17.6 提交缺陷的注意事项
-
唯一性，一个缺陷只需要提交一次
-
保证可复现性
-
规范性
- 描述需要准确，有细节真实
17.7 缺陷跟踪流程
17.7.1 场景
- 测试 new -——>开发 open——>开发 fix——>测试 close
- 测试 new ——>开发 open——>开发 fix——>测试 reopen
- 测试 new——>开发 open ——>开发 postpone
- 测试 new——>开发 open——>开发 reject
