闪光桐人の实习日记（2023年2月27日-3月3日）

2023年3月3日（docker）

项目部署

1. 项目、环境
2. docker镜像
3. 镜像仓库
4. 新服务器
5. 项目、环境

docker基本概念（三大核心）

镜像、仓库、容器

镜像：一个可执行包，包含运行所需的代码、运行时、库、环境变量和配置文件
容器：镜像运行时的实体
仓库：集中存放镜像文件的地方

docker优势

普通部署互相影响、杂乱

1. 一致的运行环境：docker镜像
2. 弹性伸缩，快速扩展：善于处理集中爆发的服务器使用压力
3. 更快速的启动时间：可以做到秒级甚至毫秒级的启动时间
4. 持续交付和部署：定制镜像来实现
5. 隔离性、迁移方便：避免公用的服务器资源会容易收到其他用户影响

jkenis自动化打包成docker部署

传统部署

• 资源、应用监控麻烦
• 部署杂乱
• 应急响应慢
• 资源利用率低

docker部署

• 资源、应用集中监控
• 容器化部署、隔离性
• 自动应急响应、告警
• 按需分配、资源利用率高

什么是PaaS平台

以福建pcmp平台为例：

• 实现分布式云化架构的部署自动化、配置自动化、实施流程化
• 支持省份IT系统高效上云
• 实现了PaaS组件一点开通，集中管理
• 提供多维度的部署视图展示
• 实现运营管理全球超的集约化和可视化

PaaS平台应用部署

1. 上传镜像：打包好的镜像上传到平台镜像仓库
2. 创建容器：创建容器，包括容器所需资源信息
3. 配置告警：配置容器告警机制，包括CPU、内存使用告警

PaaS平台应用优势

1. 可视化
2. 合理分配资源
3. 隔离性
4. 易迁移、环境一致
5. 保障服务稳定
6. 启动时间短
7. 扩展性强
8. 监控方便

docker命令

详见此处

docker创建

-d 代表后台启动
--name xx 代表创建的容器名称
-p 10003:80 将nginx的80端口映射到本机的10003端口
-v 挂载目录，目录映射
-privileged 使镜像里的root真正具有root权限

查看容器内部

执行

docker exec -it xx bin/bash

进入容器

构建docker镜像

1.项目文件准备
将项目jar包和dockerfile文件（编写详见此处）放在同一服务器目录下

宿主机上创建需要挂载的目录

cd /root/docker_study —进入/root/docker_study目录下
mkdir springboot —创建目录
cd springboot —进入springboot
rz —上传后端项目demo-0.0.1-SNAPSHOT.jar和Dockerfile。注：虚拟机内操作，可以直接从电脑拖拽项目到对应创建目录下

2.创建后端镜像

docker build -t springbootdemo4docker .

命令末尾有个点不能遗漏

镜像确认

docker images

查看镜像信息

3.创建后端容器命令

docker run --name springbootdemo -d -p 8082:8080 springbootdemo4docker

2023年3月2日（测试流程）

为什么

不测试的风险
体验差、质量差、问题多、财产损失、生命安全等

测试重点
性能、易用性、兼容性、功能性、可靠性

是什么

1983年IEEE定义，人工操作或软件自动运行的方式来检验是否满足需求或弄清预期结果与实际结果之间的差别

目的

• 检验产品是否符合用户需求
• 发现程序代码错误
• 发现程序业务逻辑错误
• 提高用户的体验

软件调试与测试

软件调试：开发时发现错误后消除错误的过程
软件测试：主要目的是寻找缺陷（不包括修复），调试必须由开发人员自己完成，测试不一定

常见问题

• 业务逻辑错误：比如新增保存失败
• 展示数据未同步：比如数据展示不正确
• 兼容性问题：比如WEB兼容、网络兼容
• 性能问题：比如页面加载慢、内存泄漏
• 安全问题：比如安全漏洞、服务器安全

测试阶段
例图

冒烟测试
开发提测后，测试部门进行冒烟测试，验证系统重要核心业务功能通过后，进入详细系统测试阶段

回归测试

修改bug，新增功能
提交bug验证
……

各阶段定义

• 单元测试，软件最小单元测试，开发小组白盒测试，测试单元是否符合设计
• 集成测试，单元测试系统测试开发小组黑白测试验证设计和需求
• 系统测试，粒度最大，测试小组黑盒测试测试是否符合需求规格说明书
• 验收测试，与系统测试相似，测试对象不同

如何进行

软件测试流程
例图

测试用例

软件测试的核心是编写测试用例

好处

• 记录问题，发现问题
• 理清思路，避免遗漏
• 跟踪测试进展
• 历史参考
• 重复性
• 告诉领导做过测试（避免甩锅）

测试用例设计原则

• 尽可能多覆盖有价等价类
• 用例个数尽量少

等价类划分法用例设计步骤

分析需求

• 确定有效等价类和无效等价类

建立等价类表：

• 列出所有划分出的等价类

选择测试用例：

• 尽可能多覆盖有价等价类
• 仅覆盖一个无效等价类

应用场景：测试需要数据量大数据操作可分类时进行等价类划分

边界值分析法

定义：
等价类划分法补充边界值从等价类的边缘值去寻找
原则：
确定便捷，选取正好等于、刚刚大于、刚刚小于边界
方法：
两点法、四点法、三点法
作用：边界值法设计测试用例可以查出更多的错误提出更多bug

应用场景：
需求规定了取值范围或规定了取值的个数时

常见运用场景：

1. 输入取值范围，输入值个数
2. 下拉列表
3. 报表数据第一行、最后一行、中间一行
4. 屏幕上的光标在最左上、右上等位置

场景法

定义
通过场景描述的业务流程（逻辑），也包括代码实现逻辑，设计用例……

画出流程图
遍历场景，提取测试用例：

• 覆盖正常路径，冒烟测试
• 走每一分支-找菱形-正常场景下没有覆盖路径分支

错误推测法（反推法）

定义
基于经验和直觉推测程序所有可能存在各种错误设计测试用例的方法，探索性测试

使用

• 不单独使用，使用其他方法补充
• 场景法，业务流程梳理、核心业务逻辑场景
• ……

举例-登录错误
网络断开
账户错误
服务器性能瓶颈
账号多点登录
服务器无法访问
账号被封禁
同意协议不勾选
浏览器兼容问题
登录次数最大
验证码不通过等

自动化测试

定义
软件测试重要分支，用工具或脚本测试，没有或极少人工参与

意义
版本发布频繁方便回归测试
自动处理繁琐重复任务
提高测试准确性
不同版本重复运行

实施流程
例图

自动化测试框架及组成部分

定义
由一些标准、协议、规则组成，提高脚本运行的环境

框架设计
例图

API接口测试框架搭建步骤
例图

2023年3月1日（消息队列MQ）

什么是消息队列

消息+队列

消息的流向

消息生产者系统 =消息=> 消息队列 =消息=> 消息消费者系统

主流消息队列功能对比

为什么要使用消息队列

平时不用消息队列的时候，消息是无序的

痛点

• 消息交互频繁
• 单线程处理消息
• 多目标维护累
• 等待返回结果

消息队列（kafka）的优势

1. 有序无序
   

2. 数据处理快慢
   

3. 依赖关系区别
   

4. 无需等待
   

5. 耦合度低
   

优势

1. 利用队列处理的模式，能解决需要数据有序处理的场景
2. 利用流式处理实现单线程处理相同数据时计算复杂导致处理过慢
3. 利用异步处理的形式解决对后续程序的依赖以及等待响应的痛苦

特点

• 易扩展
• 可靠性，持久性强
• 容错性高，支持高并发

适用场景

• 多目标
  当一条消息要被多个地方使用或多个地方生成时

• 队列形式
  当消息处理的过程需要队列的先进先出时

• 不需要结果
  当消息只需要通知对方，不需要对方的返回结果时

不适用场景

• 实时性要求高，需要即使响应结果时
• 需要确定后续程序数据处理正常时
• 一致性要求高，需要确保多套程序运行结果一致
• 系统结构简单，无需增加消息队列增加系统复杂度

如何保证消息不丢失

1. 生产端通过带有回调的send方法来处理调用失败的
2. KAFKA配置acks = all确保写入分区副本完成确认提交
3. 消费端通过配置手动提交偏移量，确保偏移量正确提交

关键信息

主题
主题是⼀个逻辑的概念，进行数据分类

消息
消费,是通信的基本单位，每个生产者可以向一个主题发布一些消息

分区

• 主题->分区->消息
• 避免大文件
• 数据不会重复

偏移量

• offset是指某一个分区的偏移量
• topic、partition、offset这三个唯一确定一条消息

生产者
生产者Producer将消息发布到指定的主题Topic中，同时Producer也能决定将此条消息归属于哪个分区Partition

消费者
消费者Consumer通过订阅topic消费其发布的消息，也可以指定分区Partition消费

消费组
每个消费者Consumer属于一个消费主Consumer Group

• 一个消费组可以有多个消费主题
• 一个消费主题可以被多个消费组消费
• 每个消费组中的每个消费主题只会被一个消费者来消费

SpringBoot整合Kafka

教程1
教程2

2023年2月28日（Git入门）

什么是版本控制

版本管理的特点：

• 记录每次修改描述
• 历史文档备份
• 可恢复到之前的版本

流程：

• 按天创建文件夹
• 在文件夹里编写文档
• 记录每次修改的日志文件
• changelog文件

本地版本控制系统
RCS

集中化版本控制系统
SVN等

本地的无法满足集中协作的需求，因而有了集中化版本控制系统

优点

• 集中管理的服务器
• 协同工作
  缺点
• 必须与服务端交互
• 单点故障风险

分布式版本控制系统
Git，Bazzer

特点

• 完整的镜像
• 独立工作

Git简介

• 2005年由大名鼎鼎的Linus创作，用于管理Linux内核开发
• 免费开源，应用于大部分的开源社区，比如GitHub、GitLab

分布式版本控制系统
几乎所有的操作都可本地执行

强大的分支模型
记录快照而非差异（快照效率高）
所有数据通过计算的校验和保证数据完整性

Git安装配置

略

Git设置

git config的配置等级
系统（–system）/etc/gitconfig
用户（–global）~/.gitconfig、/.config/git/config
仓库（–local）.git/config

下一个级别覆盖上一级别的配置

查看所有配置和所在文件位置
git config --list --show-origin

初始设置
用户和邮箱

git config --global user.name "Your Name"
git config --global user.email "name@example.com"

文本编辑器

git config --global core.editor "code --wait"

基础操作

初始化本地仓库

git init

添加文件到暂存区

git add <path>

提交修改

git commit [-a] -m "msg"

加了-a，在 commit 的时候，能帮你省一步 git add ，但也只是对修改和删除文件有效， 新文件还是要 git add，不然就是 UNtracked ！什么是UNtracked ？就是没有跟踪，不在git的代码仓里面，你更改了什么是不会提示你更改的，你提交也是不会提交到远程仓库的。

分支提交日志

git log

查看仓库状态

git status

移动文件

git mv <src> <dest>

删除文件

git rm <path>

显示文件每行最后修改的版本和作者

git blame <file>

文件状态

分支概述

分配完任务的时候，一个分支做这个另外一个分支做别的，最终就是任务都完成了

分支创建/删除

仅创建分支

git branch <new branch>

创建并切换分支

git checkout -b <new branch>

删除分支

git branch -d <branch name>

创建并切换分支

git switch -c <new branch>

分支比较

git diff <branch name>

合并

详细
分支合并-冲突
删去冲突的部分留下需要的版本内容

merge 合并

rebase 变基

只对尚未推送或分享给别人的本地修改执行变基操作清理历史

不对已推送至别处的提交执行变基操作

版本重置

三棵树
工作目录（Working Directory）
暂存区（Index）
仓库目录（HEAD）

例图

提交后发现还有其他未添加提交时的后悔药

git commit --amend

标签管理

创建当前分支标签

git tag <tagname>

对提交点打上标签

git tag <tagname> <commitID>

查看标签记录

git tag -l

查看标签详情

git show <tagname>

结合中央仓库的操作

克隆仓库

git clone <remote-url>

获取更新但未合并

git fetch [origin]

拉取更新并合并

git pull [origin]

推送到远程仓库

git push [origin]

IDEA集成Git

开发版本流程

2023年2月27日

何为异常

什么是异常：程序执行过程中的不正常情况。
异常的作用：增强程序的 健壮性。

异常抛出的方式

• 方法体上写throws Exception
• 方法内写throw new 自定义的异常类
• try/catch 语句

如何正确捕获异常

使用try 和 catch关键字即可在Java中捕捉异常代码

例:

try{
   /*正常运行的代码*/
}catch(ExceptionName e)
{
   //Catch代码块
}

自定义异常类

public class MyException extends RuntimeException {
	
	private Integer code;

	public Integer getCode() {
		return code;
	}

	public void setCode(Integer code) {
		this.code = code;
	}
	
	public MyException(Integer code, String message) {
		super(message);
		this.code = code;
	}
	
	public MyException(StateEnums enums) {
		super(enums.getMessage());
		this.code = enums.getCode();
	}
	
	public MyException(StateEnums enums, String message) {
		super(message);
		this.code = enums.getCode();
	}

}

什么是log4j

组成

Log4J 主要由 Loggers (日志记录器)、Appenders（输出端）和 Layout（日志格式化器）组成。其中 Loggers 控制日志的输出级别与日志是否输出；Appenders 指定日志的输出方式（输出到控制台、文件等）；Layout 控制日志信息的输出格式。

日志级别

Log4J 在 org.apache.log4j.Level 类中定义了OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL七种日志级别：

• OFF 最高日志级别，关闭左右日志
• FATAL 将会导致应用程序退出的错误
• ERROR 发生错误事件，但仍不影响系统的继续运行
• WARN 警告，即潜在的错误情形
• INFO 一般和在粗粒度级别上，强调应用程序的运行全程
• DEBUG 一般用于细粒度级别上，对调试应用程序非常有帮助
• ALL 最低等级，打开所有日志记录

  注：一般只使用4个级别，优先级从高到低为 ERROR > WARN > INFO > DEBUG