（SUB）测开情景问题

使用Redis来存储商品信息，商品图片等静态⻚面;针对该功能如何设计测试方案?需要考虑哪些点?

可以参考这篇博客：https://www.cnblogs.com/chenxiaomeng/p/16736024.html

验证基本功能
缓存增加：

增加缓存，校验功能和数据是否正确，DB 中的数据跟 Redis 是否一致，缓存过期时间与设计是否一致；

缓存更新：

更新缓存，校验功能和数据是否正确，DB 中的数据跟 Redis 是否一致；缓存过期时间与设计是否一致；

对同一条数据并发执行更新和查询操作，校验功能和数据是否正确，DB 中的数据跟 Redis 是否一致；缓存过期时间与设计是否一致；

缓存删除：

删除缓存，校验功能和数据是否正确，再次请求，缓存是否被正确写入，DB 中的数据跟 Redis 是否一致；

缓存过期：

设置 Redis 过期时间，校验缓存是否正常过期失效。再次写入缓存，缓存过期时间被更新。（可通过修改服务器时间或手动修改缓存的 TTL）

缓存读取：

校验数据在缓存和 DB 中都存在时，系统功能是否正常；

校验数据在 DB 存在，但缓存中不存在时，系统功能是否正常；

校验数据在缓存和 DB 中都不存在时，系统功能是否正常；

验证 DB 返回的数据异常时，没有去缓存；

验证特殊场景
缓存超时：

校验缓存查询达到超时时间后，未返回指定的数据，对系统的影响。

缓存穿透：

不断查询一个 DB 和缓存中一定不存在的数据，验证返回数据为空。

缓存雪崩：

校验缓存是否采用了相同的过期时间。如果缓存大指量同时失效，验证系统功能是否正常，性能指标是否正常。

缓存击穿：

缓存中的数据没有人查询过 ，第一次就大并发的访问；

缓存中的某条数据刚好失效后，就进行大并发访问，校验功能是否正常，各项性能指标是否正常。

缓存预热：

大批量缓存在同一时间点过期，验证缓存预热耗时及预热时机。

在缓存预热期间请求更新接口和查询接口，验证返回数据的正确性。

缓存上限：

校验缓存淘汰参数配置与预期一致：增加缓存至达到 maxmemory 限制时（可修改 redis.conf 配置文件中配置的最大可用内存值），再次请求查询，数据返回正确，且缓存淘汰正确。

缓存停服：

校验关闭缓存服务后，系统功能和性能的运行情况。

验证重启 Redis 服务后，请求查询返回的数据正确，DB 中的数据跟 Redis 一致。

测试并发：

并发请求缓存中有的数据，校验返回数据是否正确，各项性能指标是否正常。

并发请求缓存中没有但 DB 中有的数据，校验返回数据是否正确，各项性能指标是否正常。

并发请求缓存中没有 DB 中也没有的数据，校验返回数据是否为空，各项性能指标是否正常。

性能测试：一般用 redis-benchmark 测试一些场景的性能基准，比如：

对比单机和集群 Redis 吞吐量；

评估不同类型的存储性能；

对比开启和关闭持久化的吞吐量；

对比调优前后的吞吐量；

对比不同版本的 Redis 的吞吐量；
————————————————

                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
                        
原文链接：https://blog.youkuaiyun.com/nuist_NJUPT/article/details/129677355

手机app崩溃闪退

闪退定义

闪退的原因

设备碎片化：由于设备极具多样性，App在不同的设备上可能有表现不同。

代码错误：应用程序中存在bug或逻辑错误。应用程序中存在死锁、竞争条件或其他线程相关的问题。

资源耗尽，应用程序过度使用CPU、网络或其他资源。

第三方库或服务问题，应用程序依赖的第三方库或服务出现问题，比如版本太低。

杀毒软件误删app运行时环境

排查APP闪退

1. 查看崩溃日志，通过开发者工具或日志记录，查看崩溃日志，找到具体的错误信息和崩溃位置。

2. 重现问题，尝试重现闪退的步骤，确保能够准确触发崩溃。

3. 分析代码，根据崩溃日志和重现的步骤，分析代码并查找潜在的问题，这块对测试人员的要求比较高，可以同开发一块排查。

4. 内存监测，使用内存分析工具检查应用程序的内存使用情况，查看是否存在内存泄漏或过度使用的情况。

5. 测试环境，在不同的设备和操作系统上进行测试，检查是否存在兼容性问题。

6. 第三方库和服务，检查应用程序所使用的第三方库和服务是否有更新或修复的版本可用。

7. 手动调试，如果以上方法仍无法解决问题，可以尝试使用调试工具进行手动调试，以找到具体的问题，一般都由开发来做。

App崩溃的测试用例设计：

1. 验证在有不同的屏幕分辨率，操作系统和运营商的多个设备上的App行为。
2. 用新发布的操作系统版本验证App的行为。
3. 验证在如隧道，电梯等网络质量突然改变的环境中的App行为。
4. 通过手动网络从蜂窝更改到Wi-Fi ，或反过来，验证App行为。
5. 验证在没有网络的环境中的App行为。
6. 验证来电/短信和设备特定的警报（如警报和通知）时的App行为。
7. 通过改变设备的方向，以不同的视图模式，验证App行为。
8. 验证设备内存不足时的App行为。
9. 通过用测试工具施加载荷验证App行为。

总结：

app测试过程中，出现闪退时，先保存现场，导出对应的日志信息，然后找复现路径。

不管是必现还是偶现的，都应该提交bug记录：

（1）若是必现闪退时，则描述清楚，如，

使用XX设备（android11）进入XX详情页面时，应用闪退（操作步骤、日志信息参考详情）

（2）若是非必现问题，则需要描述清晰，在哪个模块，哪个页面进行了哪些操作出现闪退（操作步骤、日志信息参考详情）

网站打不开

可能存在以下原因：

1、网站服务器问题：目标服务器可能出现故障（500）或正在进行维护（503）过载（504），导致无法正常访问网站。

2、网络连接问题：我们的网络连接可能存在问题，如断网、网络延迟或不稳定的连接，会影响到网站的正常访问。

3、DNS解析问题：域名无法正确解析为IP地址会导致网站无法打开。

4、防火墙或安全设置：网站可能设置了严格的防火墙或安全措施，导致某些IP地址或访问方式被阻止。

5、网络运营商问题

6、地区ip禁止访问

7、

对于网站打不开的问题，可以按照以下步骤进行排查和解决：

1、检查网络连接：首先确保自己的网络连接正常。可尝试访问其他网站，检查是否能够正常打开。

2、测试其他设备或网络：如问题只在特定设备或网络上出现，可能与设备或网络设置有关。可尝试使用其他设备或连接到其他网络进行访问。

3、检查DNS解析：可以使用ping、nslookup等命令查询是否解析出IP，如果没有，则可能是DNS解析问题。可刷新DNS缓存、更换DNS服务器等方式解决。

4、检查防火墙或安全设置：如果网站在其他网络或设备上可以正常访问，而只在当前网络或设备上无法打开，可能是IP地址被屏蔽了。可尝试通过代理IP进行访问，绕过防火墙或安全限制。

朋友圈刷新慢

所在地区服务器问题（限流，负载太高）

弱网问题（地区信号不好，附近基站问题，所处环境问题）

手机缓存太多

手机中有其他占用网速的应用

手机设备老旧导致

需要更新的数据太多

有病毒拦截窃取数据

 

抖音突然加载不出来

1.手机断网：手机网卡烧了，进入无信号区等，手机卡限速

2.运营商处网络异常：手机欠费，所在区域因ip封锁等无法访问抖音

3.抖音服务器挂了

4.异地登陆

所在地区服务器问题（限流，负载太高）

弱网问题（地区信号不好，附近基站问题，所处环境问题）

手机缓存太多

手机中有其他占用网速的应用

手机设备老旧导致

需要更新的数据太多

有病毒拦截窃取数据

1.如果抖音一个地区的许多用户无法下载视频的原因。

如果抖音一个地区的许多用户无法下载视频，可能的原因如下：

服务器故障：抖音服务器出现故障或宕机，导致部分用户无法下载视频。

安全防护：抖音增加了一些安全防护措施，如IP封锁、验证码等，部分用户未能通过验证，无法下载视频。

网络问题：该地区的网络连接存在问题，导致部分用户无法连接到抖音服务器进行下载。

地域限制：因为政策、版权等原因，某些地区的用户可能会受到下载限制，无法下载视频。

针对这些情况，我们可以采取以下措施：

联系技术支持：如果是服务器故障等技术问题，可以联系抖音技术支持，及时解决问题。

检查网络连接：检查用户的网络连接是否正常，排除网络问题。

寻求帮助：如果需要通过验证码等方式进行验证，可以寻求抖音客服和相关方面的帮助。

了解政策和版权信息：如果是地域限制等问题，了解政策和版权信息，并选择合适的应对方案。

总之，针对用户无法下载视频的问题，我们需要进行调查和排查，找出具体原因，并采取相应的措施解决问题。

2.如果用户收到了银行短信提示已经扣款成功了，但是商家没有收到钱，你觉得会是什么问题？

如果用户收到了银行短信提示已经扣款成功，但是商家没有收到钱，可能的问题如下：

银行系统故障：银行系统出现故障或延迟，导致扣款信息未能及时传递到商家的账户。

网络问题：在扣款过程中，网络连接出现问题，导致扣款信息未能及时到达商家的账户。

商家系统问题：商家自身系统出现故障，未能正确处理和确认扣款信息。

银行账户信息错误：银行账户信息错误，导致扣款信息被发送到错误的账户上。

3.输入一个url，请问发生了什么?

输入一个URL时，发生了以下几个步骤：

DNS解析：浏览器会将输入的URL发送给DNS服务器，获取域名对应的IP地址。

建立TCP连接：浏览器通过IP地址与Web服务器建立TCP连接，进行数据传输。

发送HTTP请求：浏览器向Web服务器发送HTTP请求，包括请求方法、请求头和请求体等内容。

服务器处理请求：Web服务器接收到请求后，解析请求信息，并根据请求内容返回相应的资源文件。

接收并解析响应：浏览器接收到服务器响应后，开始解析HTML，CSS和JavaScript等前端资源文件。

渲染页面：浏览器根据解析的资源文件，渲染出完整的网页，呈现给用户。

断开TCP连接：当所有资源文件都被下载并渲染完毕后，浏览器与Web服务器断开TCP连接。

以上是一些基本的流程，具体过程可能还包括缓存、压缩、安全协议等一系列操作。总的来说，输入一个URL意味着向服务器请求特定的资源文件，进行网络通信和数据交换。

4.如何实现一个用户登录功能？

要实现用户登录功能，通常需要以下步骤：

创建一个用户数据库，包括用户名、密码等信息。

在用户界面中，提供一个登录表单，要求用户输入用户名和密码。

当用户提交表单时，服务器端应该验证用户名和密码是否匹配，如果匹配则将用户登录状态保存到会话（session）中。

如果用户已经登录，则可以允许他们访问受保护的页面，否则需要重定向到登录页面，并提示用户输入正确的用户名和密码。

为了安全起见，密码应该加密存储在数据库中，而不是明文存储。在验证用户名和密码时，应该使用安全的哈希算法进行比较。

另外，还可以考虑添加其他安全机制，例如使用验证码来防止自动化攻击，或记录登录尝试次数，以便在有人暴力破解密码时及时发现并采取措施

用户登录实现
登录功能
思路：
1.接收客户端的请求（接收参数：姓名、密码）
2.参数的非空判断
如果参数为空，
通过消息模型对象返回结果（设置状态、设置提示信息，回显数据）
将消息模型对象设置到request作用域中
请求转发到登录页面
return
3、通过用户姓名查询用户对象
4、判断用户对象是否为空
如果参数为空，
通过消息模型对象返回结果（设置状态、设置提示信息，回显数据）
将消息模型对象设置到request作用域中
请求转发到登录页面
return
5、将数据库中查询到的用户密码与前台传递的密码作比较
如果不相等
通过消息模型对象返回结果（设置状态、设置提示信息，回显数据）
将消息模型对象设置到request作用域中
请求转发到登录页面
return
如果相等，表示登录成功
将用户信息设置到session作用域中
重定向跳转到首页
我们这里还需要一个分层，分别是controller层、service层、mapper（dao）层。

controller层
1.接收客户端的请求（接收参数：姓名、密码）
2.调用service层的方法，返回消息模型
3.判断消息模型的状态码
如果状态码失败
将消息模型对象设置到request作用域中，请求转发到login.jsp
如果状态码成功
将消息模型对象设置到session作用域中，重定向到index.jsp

service层
1.参数的非空判断
如果参数为空，
通过消息模型对象返回结果（设置状态、设置提示信息，回显数据）
2.调用dao层的查询方法，通过用户名查询用户对象
3.判读用户对象是否为空
通过消息模型对象返回结果（设置状态、设置提示信息，回显数据）
4.判断数据库中查询到的用户密码与前台传递过来的密码作比较
如果不成功，通过消息模型对象返回结果（设置状态、设置提示信息，回显数据）
5.登录成功，成功状态、提示信息、用户对象设置成消息模型对象，并return

Mapper层

定义对应的接口
也就是前面配置Mybatis的mapper层。

其他工具类

消息模型对象（数据响应）

原文链接：https://blog.youkuaiyun.com/A_Fierce/article/details/127077068

 

5.高并发下减少事务带来的性能消耗？

数据库事务
在高并发场景下，事务的性能消耗可能会成为瓶颈，因此可以考虑采用以下方法来减少事务带来的性能负担：

减小事务的粒度。将一个大的事务拆分成多个较小的事务，以减少锁定资源的时间和范围，从而提高并发性。

尽量避免长事务。长事务会占用锁资源的时间较长，对系统的处理能力造成压力，因此应该尽量缩短事务的执行时间。

采用乐观锁机制。在某些场景下，使用乐观锁代替悲观锁可以提高系统的并发性能。乐观锁假设在读取数据时不会有其他事务修改数据，只在提交时检查是否与更新前一致。这样可以避免很多无谓的锁等待。

合理设计数据库索引。适当的索引可以加快查询速度，减少锁冲突和死锁的风险，从而提高并发性能。

使用缓存技术。将经常访问的数据缓存在内存中，可以避免频繁查询数据库，减少锁竞争，提高系统响应速度。

使用分布式事务方案。在大型高并发系统中，可以使用分布式事务机制来实现数据一致性和高可用性。分布式事务可以将事务拆分成多个子事务在不同节点上执行，并通过协调器来保证一致性。

在高并发场景中，为了提高系统的性能和吞吐量，可以通过以下几点来优化和调整Spring事务的配置：

1. 设置事务隔离级别为READ_COMMITTED： 事务隔离级别越低，对系统性能的影响越小。在高并发场景中，如果没有特殊需求，推荐将事务隔离级别设置为READ_COMMITTED。
2. 调整事务传播行为： 事务的传播行为决定了在方法调用链中事务的边界，不同的传播行为对性能有影响。在高并发场景中，推荐使用事务传播行为为REQUIRED，这样多个方法调用可以共享同一个事务，减少频繁的事务开启和提交。
3. 调整事务超时时间： 事务的超时时间决定了一个事务的最长执行时间。在高并发场景中，可以根据实际情况适当调整事务超时时间，避免因为某个事务执行时间过长导致其他事务阻塞。
4. 使用批量操作： 在高并发场景中，频繁地执行单个事务操作会增加数据库的压力。可以通过使用批量操作的方式，将多个操作合并在一个事务中，减少与数据库的交互次数，提高性能和吞吐量。
5. 调整数据库连接池的配置： 数据库连接池的大小和配置对系统性能也有重要影响。在高并发场景中，可以适当调整数据库连接池的最大连接数、最小空闲连接数等参数，以满足系统的并发需求。
6. 缓存查询结果： 对于一些查询频率较高且结果相对稳定的查询，可以将查询结果缓存起来。这样可以避免频繁地查询数据库，提高系统的性能和吞吐量。
7. 使用异步事务处理： 在高并发场景中，可以将一些耗时较长的事务处理改为异步方式。通过将耗时操作异步执行，可以释放系统资源，提高并发处理能力。

6.如果一个API接口出现一个不稳定出现的bug，如何去确定？

如果一个API接口出现一个不稳定出现的bug，可以采用以下方法进行排查和确定：

确认问题是否能够重现。在调试过程中，首先要确认问题是否能够重现，如果不能够重现，则需要检查问题的具体表现和环境变化，并尝试模拟相关场景。

查看日志输出。通过查看系统的日志输出，可以了解接口的请求参数、响应数据以及可能出现的错误信息等，从而帮助快速定位问题。

使用调试器进行分析。通过使用调试器，可以逐步跟踪代码执行过程，并查找可能存在的问题，例如变量赋值、方法调用等。

分析代码逻辑。对于复杂的代码逻辑，需要仔细分析各个分支的执行顺序和条件判断，并查找可能出现的漏洞和缺陷。

进行性能测试和压力测试。通过进行性能和压力测试，可以了解接口在高并发和大负载情况下的运行状况，从而确定是否存在性能问题，并进行相应优化。

参考相关文档和社区论坛。可以参考相关技术文档、开发者社区论坛等来了解其他用户或开发者的经验和建议，可能会有意想不到的收获。

总之，排查不稳定的bug是一个复杂的过程，需要仔细分析和多方协作，同时也需要不断尝试各种方法，才能快速解决问题.

7.如果你是测试人员，提交了bug，开发告诉你不存在，如何处理？

如果作为测试人员提交了一份bug报告，而开发人员回复说该问题不存在，可以采取以下措施：

确认bug是否真实存在。首先，测试人员应该再次确认该bug是否确实存在，如果存在的话，需要提供尽可能多的证据来支持这个结论。

与开发人员沟通。测试人员应该积极与开发人员沟通，详细说明问题出现的具体场景，以及如何重现问题。同时，也需要听取开发人员的建议和解释，从不同角度思考问题，并寻求共同解决方法。

查找其他证据。测试人员可以在代码、日志、数据库等方面查找其他证据，来进一步支持bug是否存在的结论。例如，可以查看日志输出，检查数据库中的数据是否正确等。

寻求第三方意见。如果无法确定是否存在bug，则可以向其他测试人员或专家请求帮助，寻求第三方意见，从而得到更全面的评估和建议。

总之，测试人员应该始终保持客观和严谨的态度，在确认bug是否存在时要尽可能地提供证据和数据，与开发人员进行充分的沟通和协作，并寻求多方支持和建议，来最终确定问题的本质和解决方案

8.访问页面加载缓慢的原因以及如何解决？

http请求次数太多

解决：减少http请求次数。

①　图片地图：把多张图片整合到一张图片中，以位置定位超链接。

②　CSS Sprites合并图片，通过指定CSS的backgroud-image和backgroud-position来显示元素。

③　合并JS脚本和CSS样式表。

④　使用外部JS和CSS文件。

接收数据时间过长，如下载资源过大

解决：对HTTP传输进行压缩。

即在js，css、图片等资源已经压缩的基础上，在HTTP传输过程中的再次压缩。

客户端可以通过Accept-Encoding头来声明浏览器支持的压缩方式，服务端通过Content-Encoding来启用压缩，配置压缩的文件类型，压缩方式。gzip使用无损压缩，压缩效果最佳，已经成为使用最为普遍、支持的浏览器最多的数据压缩格式。

还可以采用图片和视频压缩技术、懒加载、延迟加载等方式来优化。

大量脚本或样式表文件。

script没有async和defer时，JS文件将在下载后立即执行。这种情况下，script放在顶部会阻塞页面呈现，在网速慢的情况下会导致“白屏”，直到脚本下载完毕才继续呈现页面。

因此，script放在底部可以让页面尽快呈现。
https://blog.youkuaiyun.com/zhouziyu2011/article/details/71330739

当网页中包含大量的脚本或样式表文件时，会加重浏览器的渲染负担，导致页面加载缓慢。可以通过打包合并脚本和样式表文件、使用外部链接等方式来优化。压缩js和css

CSS、JavaScript、图片等需要重复加载

解决：静态资源统一放在一个静态域名上，减轻重复下载静态资源的负担。

cookie影响

解决：减小cookie的影响。

①　去除没有必要的cookie，如果网页不需要cookie就完全禁掉。

②　将cookie的大小减到最小：减小HTTP请求报文的大小，提高响应速度。

③　设置合适的过期时间：cookie信息将存储到硬盘上，即使浏览器退出cookie还会存在，只要cookie未被清除且还在过期时间内，该cookie就会在访问对应域名时发送给服务器。

④　通过使用不同的domain减少cookie的使用：cookie在访问对应域名下的资源时都会通过HTTP请求发送到服务器，但在访问一些资源，如js，css和图片时，大多数情况下cookie是多余的，可以使用不同的domain来存储这些静态资源，这样访问这些资源时就不会发送多余的cookie，从而提高响应速度。

网页资源过多

解决：使用CDN部署网络以提高下载速度，可以先通过免费的CDN供应商来分发网页资源。
原因：DNS解析速度
DNS解析是从域名到IP的解析。DNS解析包括往复解析的次数及每次解析所花费的时间，它们两者的积即是DNS解析所耗费的总时间。许多人无视了DNS解析的因素，其实它对网站解析速度也是十分重要的。可以更换延迟比较低的DNS服务器。

服务器端处理效率低下。

如果服务器端处理请求的效率较低，也会导致页面加载缓慢。可以通过优化服务器端代码、使用缓存等方式来提高处理效率。

浏览器问题。

浏览器的不同版本和性能也会影响页面加载速度。可以使用更快的浏览器版本、更新浏览器等方式来优化。

总之，要提高网页的加载速度，需要综合考虑网络、资源、服务器端处理效率和前端代码优化等因素，并采用相应的技术手段进行优化。

9.针对评论功能，你如何设计接口，主要回答需要传递的参数有哪些？

针对评论功能，我建议设计如下接口，需要传递以下参数：

获取评论列表
接口地址：/api/comments
请求方式：GET
请求参数：
article_id（文章ID，必填）
page_index（页码，可选，默认为1）
page_size（每页显示数量，可选，默认为20）
添加评论
接口地址：/api/comments
请求方式：POST
请求参数：
article_id（文章ID，必填）
content（评论内容，必填）
user_id（用户ID，必填）
删除评论
接口地址：/api/comments/:comment_id
请求方式：DELETE
请求参数：
comment_id（评论ID，必填）
修改评论
接口地址：/api/comments/:comment_id
请求方式：PUT
请求参数：
comment_id（评论ID，必填）
content（评论内容，必填）
user_id（用户ID，必填）
回复评论
接口地址：/api/comments/reply
请求方式：POST
请求参数：
comment_id（评论ID，必填）
content（回复内容，必填）
user_id（用户ID，必填）
点赞评论
接口地址：/api/comments/like
请求方式：POST
请求参数：
comment_id（评论ID，必填）
user_id（用户ID，必填）
以上是针对评论功能的基本接口设计，具体实现时还需要考虑接口的安全性、鲁棒性和性能等方面。

10.app页面白屏了什么原因？

当界面白屏时，可以按照以下步骤进行排查：

检查网络连接是否正常，确保 URL 地址正确。

打开控制台，查看是否有报错信息。

检查接口访问是否有请求。

检查路由是否有 path 错误，导致加载了不存在的页面。

从 JS 和 CSS 方面检测，排除网络问题后，如果还是白屏，那一般都是 CSS 和 JS 加载造成的。CSS 和 JS 会造成阻塞渲染。

App页面白屏可能有以下原因：

网络问题。App页面需要从服务器加载数据，如果网络状况不良或者服务器响应时间过长，会导致页面无法正常加载。

JavaScript错误。页面中的JavaScript代码出现错误，可能会导致页面无法正常渲染。可以通过查看浏览器控制台输出来确定是否存在此类问题。

样式表文件编译错误。如果样式表文件存在编译错误，也会导致页面无法正常显示。可以通过检查样式表文件语法和使用的工具版本等方面来排查问题。

缺少必要的资源文件。如果页面缺少必要的资源文件，例如图片、字体文件等，也会导致页面无法正常显示。

服务器端处理效率低下。如果服务器端处理请求的效率较低，也会导致页面无法正常加载。可以通过优化服务器端代码、使用缓存等方式来提高处理效率。

设备兼容性问题。在一些老旧的设备上，可能存在对最新技术支持不完善，导致页面无法正常显示。

针对以上问题，可以采用以下方法进行解决：

加强网络连接质量，优化服务器端处理效率，避免出现因网络或服务器问题导致的页面空白问题。

写好前端代码，避免出现JavaScript错误和样式表文件编译错误，可以通过打包合并文件、代码检查等方式来优化。

确保所有必备的资源文件都已正确加载，避免出现页面空白的情况。

针对不同设备调整页面代码和样式，以确保在不同设备上都能正常显示。

总之，在开发App页面时需要做好充分的测试和优化工作，以提高页面的稳定性和质量

11.全链路压测中，找到了某一个服务器CPU负载率100%，磁盘和内存使用率正常，请问你会怎么去分析可能的原因？

在全链路压测中，如果发现某一个服务器的CPU负载率达到100%，而磁盘和内存使用率正常，可能的原因有以下几点：

程序代码问题。不合理或者错误的程序代码可能导致CPU资源占用过高，如代码死循环、递归调用等。

数据库访问性能问题。数据库的访问性能较低，导致CPU等待响应时间过长，从而占用了大量CPU资源。

第三方服务调用问题。在系统调用第三方服务时，如果第三方服务响应时间过长或者存在异常，都可能导致当前服务器CPU资源占用过高。

垃圾回收机制问题。垃圾回收机制是一种自动管理内存的技术，在执行时会消耗大量的CPU资源。如果垃圾回收机制的配置不合理或者存在其他问题，也可能导致CPU资源占用过高。

为了分析CPU负载率过高的原因，可以采取以下措施：

分析系统日志。通过查看系统日志，可以了解服务器在运行过程中的具体操作和事件，从而判断是否出现了异常情况。

查看CPU监控数据。通过查看CPU监控数据，可以了解CPU使用情况的变化趋势和占用率，进一步确定CPU资源占用过高的具体时间段和原因。

通过性能诊断工具进行分析。可以使用性能诊断工具来分析服务器在运行过程中的性能瓶颈，从而找到CPU占用率过高的原因。

进行代码优化或者调整配置参数。根据定位出的问题，可以采取相应的措施进行优化或者调整，例如优化数据库访问性能、修改垃圾回收机制配置等。

总之，在全链路压测中，如果发现了某一个服务器CPU负载率过高，需要针对性地进行分析和定位，并采取相应的措施解决问题。

12.添加购物车请求后发生了什么？

一般情况下，添加购物车请求会将用户选择的商品信息发送给后台服务器。服务器会在数据库中查询该商品是否存在，并更新购物车信息。如果商品不存在，则会返回错误信息给前端；如果商品存在，则会返回成功信息，并将购物车信息存储到数据库中。同时，服务器还会根据用户的身份和权限计算购物车中商品的价格、折扣和运费等信息，以便后续结算和支付操作。最后，服务器会向前端返回更新后的购物车信息，以供用户查看和修改.

13.决策树的测试用例设计？

在决策树的测试用例设计中，主要考虑以下几个方面：

覆盖率
决策树的测试用例应该尽可能地覆盖所有的节点和边，以确保各种情况都能够得到充分的测试。在实际测试中，通常会使用不同的测试用例来覆盖不同的路径和条件，例如边界值测试、等价类划分等。

隔离性
为了避免不同测试用例之间相互影响，测试用例应该具有隔离性。这意味着每个测试用例都应该是独立的，并且不受其他测试用例的影响。

策略选择
在设计测试用例时，需要考虑到具体的测试策略，如黑盒测试、白盒测试等。不同的测试策略有不同的重点和目标，因此需要针对具体的场景选择适当的策略和方法。

数据准备
在测试决策树时，需要准备好合适的测试数据，以检验决策树的正确性和可靠性。测试数据应该具有典型性和代表性，以覆盖不同的情况和场景。

评估方法
在测试完成后，需要对测试结果进行评估和分析，以确定决策树的质量和可靠性。评估方法可以包括比较测试结果与预期结果之间的差异、计算测试覆盖率等。

综上所述，决策树的测试用例设计需要考虑多个方面，包括覆盖率、隔离性、策略选择、数据准备和评估方法等。在实际测试中，需要结合具体的场景和要求，采用不同的方法和技术来设计和实施测试用例，以确保测试覆盖率和测试质量。

决策树性能的评估方法通常包括以下几个方面：

准确率
决策树分类器的准确率是评估其性能的重要指标之一。准确率是指分类器在测试集上正确分类的样本数占总样本数的比例，通常用百分数表示。准确率越高，说明分类器的性能越好。

召回率
召回率（Recall）是指分类器正确识别出的正例占所有正例的比例。召回率越高，说明分类器对正例的识别能力越强。

精确率
精确率（Precision）指的是被分类器预测为正例中实际为正例的样本比例。精确率越高，说明分类器对负例的排除能力越强。

F1值
F1值是综合考虑召回率和精确率的指标，它是召回率和精确率的调和平均数。F1值越高，说明分类器的性能越好。

ROC曲线
ROC曲线是衡量分类器性能的常用工具之一。ROC曲线是以False Positive Rate（FPR）为横轴，True Positive Rate（TPR）为纵轴，绘制出来的曲线。ROC曲线的面积（AUC）通常用来衡量分类器的性能，AUC越大，说明分类器的性能越好。

混淆矩阵
混淆矩阵是一种用于表示分类器预测结果的矩阵。混淆矩阵可以用来计算准确率、召回率、精确率等指标。

综上所述，决策树性能的评估方法包括准确率、召回率、精确率、F1值、ROC曲线和混淆矩阵等多个方面，需要结合具体的场景和需求进行综合评估。在实际应用中，需要根据具体情况选择合适的评估方法和指标，并进行全面的性能测试和分析。

前端bug还是后端bug

常用抓包工具：fiddler、F12
常用判断方法：

1.检查错误信息：首先查看错误信息或日志，它们通常会提供有关错误的详细信息和位置。如果错误信息指向前端的特定代码或文件，那么很可能是前端 bug；如果它指向后端的代码或文件，那么很可能是后端 bug。

2.检查网络请求和响应：观察网络请求和响应可以帮助确定问题发生的位置。在浏览器的开发者工具中查看网络请求和响应，观察请求和响应的参数、数据和格式。如果问题出现在请求或响应的格式、参数或数据处理上，那么可能是后端 bug；如果问题出现在响应的展示、渲染或交互上，那么可能是前端 bug。

3.进行调试（debug）和日志记录：使用调试工具或添加日志记录来跟踪代码执行过程。通过在关键代码位置添加断点或日志语句，可以观察程序的执行流程、变量的值和错误的堆栈信息。通过调试和日志记录，可以更准确地确定问题在哪一侧发生。

 

上传头像失败原因

 

一、原因分析

1、权限问题

　　现在的程序都是需要经过用户授权，才能访问相册

2、照片格式

　　图片的格式一般有PNG，JPG等，但是IOS11后的手机拍照出来的格式是HEIC,假如程序没有对这种情况做处理，会发生上传失败

3、图片太大

　　现在的新手机分辨率比较高，拍出来的照片一般都很大，程序处理不好，会造成上传失败

4、尺寸大小

　　现在的app一般都对对图片的尺寸有做一定的限制

5、内存泄露

　　　用户可能频繁的操作用户头像上传，程序没有处理好资源释放，也会失败

6、网络问题

　　客户端和服务端交互，都是需要走网络的，在网络差等弱网情况下，可能会造成上传失败

7、服务器异常

　　服务器的在高负载运行，对客户端没有很好的响应或者是响应慢或超时，也会造成失败

二、分析思路

1、fiddler等代理抓包工具对程序进行抓包

用户头像上传，是需要经过接口的，通过代理工具先排查是前端还是后端接口问题

2、假如是后端问题，则需要通过成熟的elk工具或登录服务器使用命令查询此用户的失败时间点等去查询日志，去进一步分析

 

如何测试请求的幂等性

接口幂等性：用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生副作用。

支付案例：用户购买商品后支付，支付扣款成功，返回结果的时候网络异常，此时钱已经扣了。如果用户再次点击按钮，进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条，即没有保证接口的幂等性。

使用幂等性可以防止以下问题：

前端重复提交表单： 在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。

用户恶意进行刷单： 例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。

接口超时重复提交： 很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。

消息进行重复消费： 当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。

1）要测试删除接口的幂等性，可以通过连续调用删除 -> 查询 -> 删除 -> 再查询四个接口来实现。

2）业务测试应该聚焦业务的幂等性，并设计各种异常场景的测试用例，来验证是否发生重复扣款。

实现幂等一般有3种方案
1.MVCC(多版本并发控制):在数据更新时需要去比较持有数据的版本号，版本号不一致的操作无法成功
2.表去重:构建唯一性索引,保证某一类数据一旦执行完毕，后续同样的请求再也无法成功写入
3.TOKEN机制:为每一次操作生成一个唯一性的凭证，也就是token。