Interview :软件工程
软件工程
性能测试
-
执行计划
-
性能测试如何开展
- 能测试需要合理的计划和有条理的步骤，不能随意得出结论，性能测试的大概步骤如下。
- 1）明确测试目的。
- 2）设计测试模型。
- 3）准备测试集群环境。
- 4）准备压力测试工具或编写压力测试脚本。
- 5）明确性能指标并加以监控。
- 6）根据2）设计的测试模型准备测试数据。
- 7）测试执行。
- 8）测试分析。
-
性能测试怎么进行
- 主要测试什么东西（部署环境（制作包/安装）/压测/出测试报告）
-
性能测试流程
-
性能测试流程
-
性能测试过程-主要做了什么
-
性能测试怎么做
-
-
基础指标
-
内存指标
- 内存指标性能表现
-
线程状态
-
系统负载指标
-
负载查看
-
性能 buffer / cache
-
数据库 binlog
-
数据库慢查询日志
-
QPS
- 每秒查询事务数（每秒处理事务数）
-
TPS
- 每秒处理事务数
- 补充：不同的用例设计方式，事务数计算方式会有较大区别
-
-
测试工具
-
Jmeter测试框架
-
有没有自己开发插件
- Jmeter特定的加密方式插件代码开发
-
使用Jmeter过程中有没有遇到什么问题（不支持同一个接口不同加密方式）
-
-
-
应用场景
- 线上数据TCP导流如何完成
- 真实流量导流
-
基础概念
- 性能基准测试
-
性能问题
-
性能问题发现
- 数据一致性，先通知，然后commit，然后服务b反查之前的数据是否提交成功
-
CPU无法跑满，可能会有哪些问题
- CPU性能太强了，没有什么问题
- 带宽不够，请求发送不进来
- 句柄数配置问题，无法进行更多的资源分配
- CPU配置问题，没有给当前用户配置太多的资源使用权限
- IO问题，较大的磁盘IO限制了CPU的切换
- 内存成为瓶颈
- CPU监控存在问题
-
-
性能优化——没有整理相关的东西（金斧子）
-
性能测试工具链详情
-
性能测试，能否更深入（无资源，给你资源，怎么深入）
自动化
-
测试报告
-
自动化测试报告
- 使用的就是pytest + allure/ unitest +htmlrunner
-
-
测试数据
-
怎么保证测试数据的一致性
- 每一个自动化用例都不应该对测试环境造成影响
- 如何保证数据唯一
-
测试前
- 如何准备测试数据
-
测试断言
- 如何进行数据准确性验证
-
-
测试策略
-
自动化设计流程，如何避免反复修改
- 从源头制定规范
-
接口自动化怎么做的
- 使用RF、goconvey、ginkgo等等手段
- 透露出我现在用的什么做的
-
-
测试框架
-
jmeter + ant + Jenkins 框架实现细节
-
接口自动化做了什么，产生了什么效果
- 自动化编写工具的编写、标准规范的制定、覆盖率的推广应用
-
接口测试怎么测试（自动化怎么获取登录状态、怎么校验正确性）
-
selenium
-
源码原理
-
selenium定位元素用的最多的是什么
- id、path
-
定位方式，遇到的问题（显示等待、隐式等待），XPath优缺点
-
-
-
落地过程中遇到的问题
- 数据污染问题：banner未清理，半小时推荐触发推送，导致数据流越来越大，甚至出现了有人在做性能测试的假象（查询ingress流量来源的时候，发现目前配置了几千条数据，没有清理，产生了大量垃圾数据，服务每隔2min 去请求，导致ingress 负载增加）
- 网络问题：
- 文档管理：定位问题不好定位，文档目录不清晰，没有接口文档，没有数据库表设计文档，那么关于API的接口说明，入参出参说明，这将带来很多附带的工作量，而文档数据的统计，又是一件很麻烦的事情。
- 自动化测试过程中，变化是最大的挑战！！！
- 版本分支影响大
- 环境管理：不同的服务影响，搭建了自己独立的测试环境，微服务环境
- “目标”一致：工作的目标设定和leader对自动化工作的期望，站的角度不同，理解不同，因此期望的结果不同。
-
自动化用例管理
- 测试用例本身使用目录的形式进行管理，
- 所有的公共布冯放到一个目录中进行管理，可以供其他的项目进行调用
数据库
-
概念
-
数据库事务
- 数据库操作序列，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。 事务由事务开始与事务结束之间执行的全部数据库操作组成
- 1、原子性(Atomicity)：事务中的全部操作在数据库中是不可分割的，要么全部完成，要么全部不执行。 [1]
- 2、一致性(Consistency)：几个并行执行的事务，其执行结果必须与按某一顺序 串行执行的结果相一致。 [1]
- 3、夺隔离性(Isolation)：事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务必须是透明的。 [1]
- 4、夺持久性(Durability):对于任意已提交事务，系统必须保证该事务对数据库的改变不被丢失，即使数据库出现故障。
- 对于事务的隔离性，DBMS是采用锁机制来实现的。当多个事务同时更新数据库中相同的数据时，只允许持有锁的事务能更新该数据，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会更新该数据。
-
-
架构
-
数据库 mysql 主备环境备份机制（原理）
-
目的
- 实时灾备，用于故障切换
- 读写分离，提供查询服务
- 备份，避免影响业务
-
必要条件
- 主库开启binlog日志（设置log-bin参数）
- 主从server-id不同
- 从库服务器能连通主库
-
原理
- 1.从库的IO线程向主库的主进程发送请求，主库验证从库，交给主库IO线程负责数据传输;
- 2.主库IO线程对比从库发送过来的master.info里的信息，将binlog文件信息，偏移量和binlog文件名等发送给从库
- 3.从库接收到信息后，将binlog信息保存到relay-bin中，同时更新master.info的偏移量和binlog文件名
- 4.从库的SQL线程不断的读取relay-bin的信息，同时将读到的偏移量和文件名写道relay-log.info文件，binlog信息写进自己的数据库，一次同步操作完成。
- 5.完成上次同步后，从库IO线程不断的向主库IO线程要binlog信息
-
从库如果也要做主库，也要打开log_bin 和log-slave-update参数
-
问题及解决方法
-
mysql主从复制存在的问题：
- 主库宕机后，数据可能丢失
- 从库只有一个sql Thread，主库写压力大，复制很可能延时
-
解决方法
-
半同步复制—解决数据丢失的问题
- 5.5集成到mysql，以插件的形式存在，需要单独安装
- 确保事务提交后binlog至少传输到一个从库
- 不保证从库应用完这个事务的binlog
- 性能有一定的降低，响应时间会更长
- 网络异常或从库宕机，卡主主库，直到超时或从库恢复
-
并行复制—-解决从库复制延迟的问题
- 社区版5.6中新增
- 并行是指从库多线程apply binlog
- 库级别并行应用binlog，同一个库数据更改还是串行的(5.7版并行复制基于事务组)
- set global slave_parallel_workers=10;
-
-
-
-
-
性能指标
-
衡量数据库性能的主要指标包括事务吞吐率和响应时间，同样，测试的时候也主要是考虑这两个指标。事务吞吐率是指数据库操作的速率，即每秒能完成多少事务，由于MySQL InnoDB默认的模式是自动提交，所以也可以近似地将其看作每秒查询数。
-
响应时间指的是响应请求的总耗时，包括等待时间、执行时间及传输数据的时间。现实中，我们往往过于看重事务吞吐率，而忽略了响应时间，在生产环境下，应该意识到，合理的响应时间范围内的事务吞吐率才有意义。因为，如果没有稳定、良好的用户体验，事务吞吐率再高也没有什么意义。
-
产品的设计哲学往往决定了它的优势和劣势，或者说安全、效率、价格、稳定这些因素往往不可兼得。所以我们进行测试的目的不是要证明存在一个完美的产品，而是在损失可以接受的范围内，进行合理地软硬件配置。
-
我们可以依据基准测试的数据来猜测系统大概还有多少性能余量，但由于测试工具存在一定的局限性，因此很难用它来模拟真实场景，所以需要谨慎对待基准测试的数据。
-
一个好的基准测试，应满足如下的一些要素
- 有现实意义：基准测试需要具有现实意义，工作负荷、样本数据、系统配置应该和我们测试的目的相关，这样才更有实际意义。
- 具有可观察性、易理解、文档化：基准测试必须充分文档化，其他人在阅读文档时能够知道你的软硬件环境配置是如何进行测试的，可能还要附上你的配置文件。并不是所有的人都是专业的，如果你不说明自己的系统、软件版本、负载等信息，其他人在其他系统上可能会得到不同的测试结果。测试结果往往要在一定的上下文中才有意义，比如一个数据库的I/O测试可能需要包含如下信息：负载是什么样的？使用了什么软硬件、什么测试工具进行测试？数据库是什么版本？测试环境是如何部署的？数据文件多大？数据写入频率如何？数据文件磁盘空间占比如何？使用何种方式写入数据文件？使用何种方式写日志文件？使用独立表空间还是共享表空间？使用的是什么文件系统？使用的是什么I/O调度算法？磁盘阵列是什么RAID级别？有带电池的RAID卡吗？信息记录得越详细越好，不仅方便自己以后参考，也方便其他人对比不同配置下的测试结果。
- 可运行且具有可重复性：基准测试是可以重复进行得到类似结果的。所以务必要减少干扰因素，尽可能让其他人可以按照你文档描述的步骤得到一样的结果。当然，也不能忽视干扰的存在，比如定时守护，其他用户的操作等。对于云上的环境来说，由于对其他用户不可见，因此相对于传统的主机环境来说，更加难以确认干扰。基于此，我们需要熟悉数据流的各个环节，比如负载均衡设备、Web服务器、数据库服务器、应用服务器、存储设备等，将这些环节映射到我们的模型中，可以帮助我们发现一些之前被忽略的干扰源。
- 收集足够的信息：基准测试应该尽可能地收集信息，比如内存占用、I/O性能、CPU性能等。收集尽可能多的信息总是一件好事，因为这样做有利于分析问题和发现问题。
- 有分析结果：要对基准测试结果进行分析、看和我们预期的是否一样，和经验常识是否一致。不能只提供数据而不提供分析结果。
- 要对测试结果进行解释和说明：我们应该说明测试结果中的一些异常状况，比如是否有错误、异常或干扰，如果有一些不可理解的地方，也请描述出来，也许有经验的其他人员可以帮助你进行分析。如果和我们预期的不一致，那么也有可能是我们的测试方法有问题，或者被其他的因素干扰了。总之，如果测试结果有很多不能解读的地方，那么建议不要在公开场合发布。此外，因为基准测试很耗时，所以有时会让初级工程师进行基准测试，然后让高级工程师查看性能记录，并分析和解释基准测试数据。这样做并不好，最好是在进行基准测试的时候就能够实时查看。
-
-
索引
-
Mysql查看执行计划
- desc / explain sql 语句
-
-
对比
-
Redis MySQL 区别
- 内存数据库 和关系型数据库，磁盘
-
-
常见问题
-
Join相关
-
两表join，大表和小表左右顺序应该如何
- 果两个表一样大，效率是一样的。 如果两个表的数据量相差很大，那效率上是有区别的。 一般来说，小表去join大表，效率要比大表去join小表高的多。 通常SQL会自动去选择效率好的查询方案。 所以写SQL尽量先查询和过滤数据量小的表，再去join大的表。
-
left right inner join 区别
-
inner
- 只保留两张表中完全匹配的结果集
-
left
- 返回左表所有的行，即使在右表中没有匹配的记录
-
right
- 会返回右表所有的行，即使在左表中没有匹配的记录
-
full（与inner相反）
- 返回左表和右表中所有没有匹配的行
-
-
-
数据库 死锁
-
SQL
-
三个字段，查询出出现两次的产品
- 使用having进行过滤
-
删除线上某表数据的一条名称为“韩梅梅”的数据
-
亿级数据表，添加字段
- 复制这个表的结构创建新的表xx_temp，然后在新的表增加你要的字段，然后再把数据一批批插入到新表xx_temp，最后旧表改为_bak，新表去掉_temp。
- CREATE TABLE 新表 SELECT * FROM 旧表 WHERE 1=2
-
只出现一次的数据的和
- select sum(uid) from cash having count(uid)>0 \G;
-
-
-
数据库锁机制
-
数据库引擎
-
InnoDB ｜ MyISAM对比
-
是否支持事务
- InnoDB支持事务
- MyISAM不支持
-
锁方式
-
InnoDB支持行锁
- 在使用for update的时候，在明确使用主键或者索引的时候才会是行锁，否则就是表锁。
-
MyISAM只支持表锁
-
-
存放索引的方式
-
InnoDB是聚集索引
- 数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。
- 因此，主键不应该过大，因为主键太大，其他索引也都会很大。
-
MyISAM是非聚集索引，数据文件是分离的，
- 索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
-
-
查询具体行数的差异
- InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。
- MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；
-
是否支持全文索引
- Innodb不支持全文索引
- MyISAM支持全文索引，查询效率上MyISAM要高于Innodb；
-
-
Linux
-
你最常用Linux命令（强制退出）
-
Linux data 格式化时间戳 –> date +%F
-
定时任务为什么不用crontab ，用jenkins – »待补充
-
网络相关命令
-
iptables
-
route命令
-
curl
-
格式化返回结果
- curl -v http://… | python -m json.tool
-
-
-
查询一个目录下有多少个*.py的文件
- ls -l |wc -l
代码检视（code review）
安全测试
-
安全保障的安全措施
-
安全 Appcheck –>二进制扫描
-
安全如何保证，做了哪些工作
-
跨站脚本攻击原理
-
威胁建模（使用了哪些手段）
- 仿冒
- 权限提升
- 否认
-
web测试主要做哪些安全验证，对应的测试工具是什么
- SQL注入
- 跨站脚本攻击
- JS注入
可靠性测试
-
可靠性怎么测试
- 使用DFR-runner对环境进行注入，比如CPU注入、内存注入、磁盘注入、线程状态注入、组合注入、网络嗅探拦截、I/O注入等等
app兼容性
- SDK调用原理
- app测试区别