目录

给你一支笔，你怎么测试

tcp三次握手，为什么不是两次

对面向对象和面向过程的理解

如何确保测试用例全面覆盖，保证测试的覆盖率

介绍一下TCP，UDP协议的共同点和区别

缓存击穿，缓存雪崩

jmeter的测试计划怎么编写

测试流程

黑白盒测试：

怎么对接口进行测试

功能测试：

给你一支笔，你怎么测试

功能测试

首先我们要明确它（产品）的功能是什么，那当然对于一支笔来说，它的功能最常见的就是写字。

1）笔盖是否容易开合；（按压式笔的话可以是“笔帽是否能够正常按压”）

2）笔芯能否替换；（钢笔可以是“墨水能否正常灌入”）

3）笔的出墨速度是否符合设计要求；

4）笔墨的粗细是否符合设计要求；（铅笔的话可能是笔芯的软硬程度~）

外观测试

1）笔壳颜色是否符合设计要求；

2）笔壳上的logo、文字等是否符合设计要求；

3）笔的尺寸大小是否符合设计要求；

4）笔壳的形状设计是否符合设计要求；

性能测试

笔的性能主要是书写，能否连续书写、容不容易漏墨断墨之类的。

1）将笔连续书写看出墨是否流畅；

2）将一支新的笔连续书写，查看能写多长的笔迹；

3）将一支笔从不同高度摔下，查看是否会断墨、漏墨；

安全测试

笔的安全测试主要是有没有毒（防止小孩拿去咬之类的……）、笔有没有容易伤害人的地方。

1）笔壳材质是否安全无毒；

2）笔墨是否安全无毒；

3）笔尖是否容易划伤人；

4）笔壳的外形是否有尖锐的易伤人的地方

兼容测试

1）是否能够在普通A4纸、铜版纸、卡纸等不同地方书写；

2）遇水是否会晕开（或许这个应该叫性能测试？）

易用性测试

1）笔帽上是否由挂钩，是否便于携带

tcp三次握手，为什么不是两次

三次握手才可以阻止重复历史连接的初始化（主要原因）

三次握手才可以同步双方的初始序列号

三次握手才可以避免资源浪费

三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。

我们考虑一个场景，客户端先发送了 SYN（seq = 90）报文，然后客户端宕机了，而且这个 SYN 报文还被网络阻塞了，服务端并没有收到，接着客户端重启后，又重新向服务端建立连接，发送了 SYN（seq = 100）报文（注意！不是重传 SYN，重传的 SYN 的序列号是一样的）。

客户端连续发送多次 SYN（都是同一个四元组）建立连接的报文，在网络拥堵情况下：

一个「旧 SYN 报文」比「最新的 SYN」 报文早到达了服务端，那么此时服务端就会回一个 SYN + ACK 报文给客户端，此报文中的确认号是 91（90+1）。

客户端收到后，发现自己期望收到的确认号应该是 100 + 1，而不是 90 + 1，于是就会回 RST 报文。

服务端收到 RST 报文后，就会释放连接。

后续最新的 SYN 抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。

如果是两次握手连接，就无法阻止历史连接因为在两次握手的情况下，服务端没有中间状态给客户端来阻止历史连接，导致服务端可能建立一个历史连接，造成资源浪费。

要解决这种现象，最好就是在服务端发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手。

所以，TCP 使用三次握手建立连接的最主要原因是防止「历史连接」初始化了连接。

以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。

如果只有「两次握手」，当客户端发生的 SYN 报文在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ACK 报文，所以服务端每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？

如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

对面向对象和面向过程的理解

，它是一种编程思想。聊到面向对象，我们需要聊一下面向过程的编程方式，因为面向对象是从面向过程过渡而来的。

以实际生活的案例来举一个例子，比如说洗衣服。

如果是面向过程的话，我们会将这个洗衣服任务拆解成一系列的步骤，每一个步骤就是一个函数。

第一步，打开洗衣机；

第二步，放衣服和洗衣液；

第三步，选择洗衣模式，开始洗衣；

第四步，等待洗完，拿出衣服。

如果是面向对象的编程方式，我们会拆分成人和洗衣机两个对象，再分析每一个对象，它需要做哪些事情。

人在其中需要做这三件事：

第一件打开洗衣机

第二件是放衣服和洗衣液

第三件事是洗完衣服后拿出衣服。

洗衣机在其中只需要做一件事情：

根据洗衣模式洗衣服。

在这个例子中，我们能够看出来面向过程跟面向对象，是两种不同的思维方式，处理问题的思考的角度不一样。

面相过程的思维方式，它更加注重这个事情的每一个步骤以及顺序。他比较直接高效，需要做什么可以直接开始干。

面向对象的思维方式，它更加注重事情有哪些参与者，需求里面有哪些对象，这些对象各自需要做些什么事情。将其拆解成一个个模块和对象，这样会更易于维护和拓展。

这个是面向过程跟面向对象的区别。

面向对象的三大特性：封装、继承和多态。

如何确保测试用例全面覆盖，保证测试的覆盖率

如果拿到一个比较大的功能需求，我会按照以下顺序去写测试用例以及执行

1、功能的连通性，即冒烟测试，正常的流程是否走的通

2、页面元素的检验，即检查页面字段内容、格式、边界值、数据类型、特殊字符、样式、布局等等跟业务没关系的检查，适用所有系统

3、接口测试，通过工具传参看接口能否正常响应，包括输入一些异常的数据，看接口是否有校验

4、业务逻辑检查，这个需要充分解读需求文档上的每一句话，逻辑判断控制，以及有耦合关系的模块，前置、后置等相关联的业务模块是否都正常，而不只是检查当前的功能模块没问题就可以了

5、数据库表检查，即前台提交的表单是否在对应的每一个表字段都正确的写入。例如前台支付成功以后，数据库可能会更新很多张表，商品表、订单表、统计表、日志表等等，不是支付成功就表示这个功能就没问题了

6、异常类测试，例如系统在弱网或者断网情况下页面是都有提示或者相关的判断，或者是一些交易类的功能可能会回调超时，超时代码是否有重发机制等等，具体要看你测的是什么领域的业务，都有一些特殊的场景或者异常操作，往往这些就是测试的盲点

7、兼容性测试，即你的系统或者是 App 等是否能在不同的浏览器、系统版本、手机、pad 等各种终端都能够正常运行，一般关注主流的即可

8、性能测试，本次功能根据实际用户体量是否有并发的场景，或者有批量上传、下载、大量查询等，这些都有可能引起 Cpu、内存、I/O、带宽、数据库等性能问题，这个是需要提前预判的，因为一般出了性能问题都是大问题，如果用户体量很小，可以暂时忽略

8、安全测试，一般是用专业的工具对系统进行扫描，检查系统权限、网络、端口、敏感字、加密信息、配置管理等是否有安全隐患

9、易用性测试，即开发的产品是否通俗易懂，容易操作，如果你的产品学习成本很高，业务逻辑很复杂，一个大学本科生看了半天都不会用，搞不明白，那么没人用的产品就是最大的 bug

10、回归测试，以上测试都完成之后，bug 修复完，需要对系统进行一个全量的测试，至少相关的功能点都要去执行一下。

以上就是写测试用例或者是界定测试范围的的思路，基本适用于更多场景。当然这样也不能保证 100%覆盖，这能说，做到以上几点，基本覆盖的差不多了，如果还有 bug 就是你认知以外的东西，你都想不到那当然会遗漏了。

介绍一下TCP，UDP协议的共同点和区别

TCP是面向连接的，UDP是无连接的

TCP是可靠的，UDP是不可靠的

TCP是面向字节流的，UDP是面向数据报文的

TCP只支持点对点通信，UDP支持一对一，一对多，多对多

TCP报文首部20个字节，UDP首部8个字节

TCP有拥塞控制机制，UDP没有

TCP协议下双方发送接受缓冲区都有，UDP并无实际意义上的发送缓冲区，但是存在接受缓冲区

登录界面的测试用例

面试问烂了的测试用例: 登录界面的测试用例_登录测试 不存在的用户怎么提示-CSDN博客

如何设计测试用例

设计测试用例（万能思路 + 六种设计用例方法）（详细 + 图解 + 实例）-CSDN博客

http/1.1如何优化

3.2 HTTP/1.1 如何优化？ | 小林coding

三种优化思路：

尽量避免发送http请求

在需要发送http请求时，考虑如何减少请求次数

减少服务器的http响应的数据大小

缓存击穿，缓存雪崩

缓存击穿：当用户来请求热点数据，就是因为太热点了供不应求，导致热点数据很快没了，就去数据库请求，给数据库带来巨大的压力

解决方案：

1：互斥锁：保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

2，不给热点数据设置古琦欧i时间

缓存雪崩：缓存里面的大量数据同时过期，导致用户来请求数据的时候，请求不到，就去数据库里面请求，给数据库带来巨大的压力

解决方案：

1，设置一下让这些数据不要同时过期；

2，互斥锁{**当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里），当缓存构建完成后，再释放锁。未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

3，后台更新缓存：业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。

jmeter的测试计划怎么编写

Jmeter的测试计划简单创建、四种参数化方式_jmeter测试计划-CSDN博客

添加测试计划testplan

添加线程组Tread group

添加http信息头管理器

添加http请求

添加结果树

添加完后选中线程组，右击，启动

查看结果树

测试流程

1 进行需求分析：首先得了解熟悉业务 分析需求测试点

2 编写测试计划：

3 编写目的

4 参考文档

测试概要 1 你测试的目标 2 测试的范围

5 测试规范 bug规范

6 测试策略：

冒烟测试：依据开发提测时间变动

第一轮功能测试：执行测试用例，包括边界值测试，兼容性测试，易用性测试，用户界面测试，安全性测试

第二轮功能测试：bug复测及功能验证

黑白盒测试：

白盒测试： 白盒测试也称为结构测试，主要应用于单元测试阶段，检测软件编码过程中的错误。程序员的编程经验、对编程软件的掌握程度、工作状态等因素都会影响到编程质量，导致代码错误。

方法：

1）语句覆盖:所有的“语句”都要覆盖一遍。就是设计若干个测试用例，运行被测程序，使得每一个执行语句至少执行一次。

2）判定覆盖:包含语句覆盖，每个判断T、F各一次。使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次。

3）条件覆盖:包含语句覆盖，每个条件T、F各一次是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次,但未必能覆盖全部分支。

黑盒测试：

黑盒测试又称为功能测试，主要检测软件的每一个功能是否能够正常使用。在测试过程中，将程序看成不能打开的黑盒不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。

方法：

1）等价类划分法（说明重要）

等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据划分为若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例。测试用例由有效等价类和无效等价类的代表数据组成，从而保证测试用例具有完整性和代表性。使用该方法设计测试用例主要有两个步骤:a确定等价类;b生成测试用例。

2）边界值分析法

边界值分析法是对程序输入或输出的边界值进行测试的一种黑盒测试方法。实际的测试工作证明，考虑了边界条件的测试用例比那些没有考虑边界条件的测试用例具有更高的测试回报率。这里所说的边界条件，是指输入和输入等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。

3）因果图法

因果图法也是较常用的一种黑盒测试方法，是一种简化了的逻辑图。因果图能直观地表明输入条件和输出动作之间的因果关系，能帮助测试人员把注意力集中到与程序功能有关的输入组合上。因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况

怎么对接口进行测试

1. 确定测试目标

在开始测试之前，需要明确测试的目标。这包括理解接口的功能、预期的结果和任何限制。同时，也需要了解接口的输入和输出，以便更好地编写测试用例。

2. 了解接口文档和需求

在编写测试用例之前，必须详细了解接口的文档和需求。这将帮助您了解接口的预期行为和功能。确保您理解接口的每个参数、返回结果以及可能的异常情况。

3. 编写测试用例

根据接口文档和需求，编写测试用例是非常关键的一步。每个测试用例都应该覆盖接口的不同功能和边界情况。确保测试用例的输入数据是具有代表性和全面的，可以覆盖接口的不同代码路径。测试用例应该包括正常情况和异常情况的测试。

4. 准备测试环境

在执行测试用例之前，需要准备好测试环境。这包括安装所需的依赖项和配置必要的环境变量。如果接口依赖于其他服务或数据库，请确保它们正常运行，并且测试环境中具有适当的连接。

5. 执行测试用例

现在，可以执行测试用例了。根据测试用例的输入数据和预期输出，调用接口并验证结果是否符合预期。确保记录每个测试用例的结果以供后续分析和报告。

6. 测试边界条件和异常情况

除了正常情况之外，还应该测试接口的边界条件和异常情况。这包括测试接口的最小和最大输入值，以及接口如何处理无效的输入或异常情况。确保接口在这些情况下能够正确地返回适当的错误代码和消息。

7. 进行性能测试

性能测试是测试接口的负载能力和响应时间的重要一步。通过模拟高并发的请求，可以检查接口是否能够处理大量请求而不影响其性能。确保记录响应时间和资源使用情况，并根据需求进行优化。

8. 编写测试报告

完成测试后，编写测试报告是必不可少的。测试报告应该包括测试的目标、执行的测试用例和结果、发现的问题以及对接口的评估。确保测试报告具有清晰的结构，并且易于理解和分享。

9. 修复和再测试

如果在测试中发现了问题，开发团队应该修复这些问题并进行再次测试。确保在修复问题后再次执行相关的测试用例，以确认问题是否已修复并且不会导致其他问题。

10. 持续集成和自动化测试

为了提高测试效率和质量，可以考虑将测试集成到持续集成流程中，并使用自动化测试工具进行接口测试。这样可以减少人工测试的工作量，更快地发现问题，并增加测试的覆盖范围。

总结：

测试一个接口需要从明确目标开始，了解接口文档和需求，编写全面的测试用例，准备适当的测试环境，执行测试用例并记录结果，测试边界条件和异常情况，进行性能测试，编写测试报告，修复问题并再次测试，最后考虑自动化测试。以上步骤将帮助您从0到1地测试一个接口，并确保其功能正确性和性能质量。

功能测试：

软件测试 - 功能测试（测试理论+用例设计）_功能测试方法-CSDN博客

等价划分用例：

是指程序输入域的子集。

等价类划分（Equivalance Partitioning）测试的思想：将程序的输入域划分为若干个区域（等价类），并在每个等价类中选择一个具有代表性的元素生成测试用例。该方法是常用的黑盒（Blackbox Testing）测试用例（Testcase）设计方法。

一）划分等价类

1.有效等价类与无效等价类

等价类划分可有两种不同的情况:有效等价类和无效等价类。有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合，它能检验程序是否可以实现规格说明中所规定的功能需求。无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合，它能检验程序在不符合规则的数据输入下，是否会有异常；无效等价类至少应有一个，也可能有多个，视具体情况而定。因此，设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

2.划分等价类的标准

完备测试、避免冗余。这就要求：集合（程序输入域）应划分为互不相交的一组子集，而这些子集的并集是整个集合（整个程序输入域）。

3.等价类的划分原则

(1) 若输入条件规定了取值范围或值的个数的情况下，可划分为一个有效等价类和两个无效等价类；

Eg.设置风控指标，其中权重设置范围在[-1000,1000]

保温杯的测试用例_保温杯保温能力的测试方法-CSDN博客

软件测试经典面试题（一）给你一个水杯如何测试_软件测试面试 怎么测茶壶-CSDN博客

如何进行支付功能的测试？-CSDN博客