软件测试之博客系统项目实战（补充和解析部分）

文章目录

一、测试用例
二、兼容性测试
三、性能测试之接口化测试（jmeter和postman部分）
- 接⼝⾃动化项⽬实战解析及补充
总结

一、测试用例

二、兼容性测试

兼容性测试
9.1浏览器兼容
9.1.1 ie
9.1.1.1 登录页面

9.1.1.2 博客首页

9.1.1.3 博客详情页

9.1.1.4 博客编辑页

9.1.2 谷歌

9.1.2.1 登录页面

9.1.2.2 博客首页

9.1.2.3 博客详情页

9.1.2.4 博客编辑页

9.1.3 百度

9.1.3.1 登录页面

9.1.3.2 博客首页

9.1.3.3 博客详情页

9.1.3.4 博客编辑页

9.2 系统兼容

9.2.1客户端

9.2.2 移动端

9.2.2.1 安卓（红米k60pro）

9.2.1.1 登录页面

9.2.1.2 博客首页

9.1.1.3 博客详情页

9.1.1.4 博客编辑页

9.2.2.2 苹果

2.2.1 登录页面
2.2.2 博客首页
2.2.3 博客详情页

2.2.4 博客编辑页

三、性能测试之接口化测试（jmeter和postman部分）

8.1 登录页面

Jmeter

Postman

8.2 列表页

Postman：

Jmeter：

8.3详情页

Jmeter

Postman:

8.4 编辑页（add）

提加博客

Postman

根据上面图片，修改json下的内容，可以再在postman上发布博客，并且编辑发布成功。

Jmeter

8.5 jmeter 布局（每个请求都加了断言）

8.6 jmeter博客系统压测

8.6.1

8.6.2

8.6.3

8.7 性能测试报告（性能测试：响应时间，吞吐量等）

部分重要测试报告：

响应时间

吞吐量：

随着时间变化的响应时间：

8.8 根据性能测试报告进行分析

8.8.1 总体概览

本次性能测试的总执行时长约为 3 分钟（17:40 至 17:43），共执行了 625 个请求样本。整体通过率为 98.56%，失败率为 1.44%，从表面上看系统稳定性尚可，但深入分析后会发现存在严重的性能瓶颈和错误。

核心问题在于："列表页请求"性能极差，是整个系统的瓶颈所在，且其错误率高达 5.59%，严重影响用户体验和系统可用性。

8.8.2.关键指标深度分析

响应时间 (Response Times)

平均响应时间 (Average):

总平均值: 48,325 ms (约 48 秒) ------ 这是一个极其糟糕的指标，远超任何可接受的用户体验标准（通常要求在 2-5 秒内）。

各接口对比:

列表页请求: 平均 20,993 ms (约 21 秒)，是所有接口中最慢的。

其他接口（登录、添加博客、用户信息、详情页）平均响应时间均在 30-55 ms 之间，表现优秀。

百分位数 (Percentiles):

90th pct (90% 用户体验): 总体为 15,848 ms (约 16 秒)。

95th pct: 26,980 ms (约 27 秒)。

99th pct: 68,638 ms (约 69 秒)。

最大值 (Max): 高达 126,972 ms (约 2分6秒)。

分析: 百分位数曲线图显示，随着百分位数升高，响应时间急剧增加，特别是 90% 以后，说明有大量请求的响应时间非常长，用户体验极差。这主要是由"列表页请求"的异常高延迟造成的。

随时间变化 (Response Times Over Time):

图表清晰地显示，"列表页请求"的响应时间（黄色线）从测试开始就持续攀升，在最后阶段达到峰值超过 100,000 ms。

其他接口的响应时间基本保持稳定在低位。

结论: "列表页请求"的性能不是偶发问题，而是随着负载增加而持续恶化，表明系统存在资源耗尽或处理逻辑缺陷。
吞吐量 (Throughput)

总吞吐量 (Transactions/s): 3.58 TPS。

各接口吞吐量:

列表页请求: 0.82 TPS ------ 由于其响应时间过长，导致单位时间内能处理的请求数量极少。

其他接口吞吐量均在 0.99 - 1.24 TPS 之间，表现正常。

Hits Per Second (每秒点击数): 曲线呈三角形，最高点约 5.5 HPS，说明测试负载是逐步加压再释放的。但在负载高峰时，系统未能维持稳定性能，响应时间反而急剧上升，表明系统无法承受此压力。
错误率 (Errors)

总错误率: 1.44% (9 个错误)。

按接口分析:

列表页请求: 5.59% 的错误率 (8 个错误)，是唯一出现错误的接口。

其他接口错误率为 0%。

错误类型分析:

主要错误 (8/9): Non HTTP response code: org.apache.http.TruncatedChunkException。错误信息明确指出："Truncated chunk (expected size: 8,192; actual size: X)"。

次要错误 (1/9): Value expected to match regexp 'SUCCESS', but it did not match: 'FAIL'。这是一个断言失败，可能与业务逻辑相关，但根源很可能也是因为"列表页请求"返回了错误内容。

错误原因推断:

TruncatedChunkException 是一个典型的网络或服务端问题。它意味着客户端期望接收一个完整的数据块（chunk），但实际收到的数据不完整。

结合"列表页请求"响应时间极长、随时间递增的特点，最可能的原因是：

服务端处理超时或崩溃: 服务器在处理"列表页请求"时，因数据库查询复杂、数据量大、内存不足等原因，导致处理缓慢甚至中途失败，未能将完整的响应发送给客户端。

网络连接中断: 在长时间等待响应的过程中，网络连接被中间设备（如负载均衡器、防火墙）或客户端主动关闭。

应用服务器配置问题: 如 Tomcat 或 Nginx 的 maxHttpHeaderSize, client_max_body_size, keepalive_timeout 等参数设置不当，导致大响应或长连接被截断。

8.8.3 核心问题定位

综合以上分析，可以得出以下结论：

"列表页请求"是本次性能测试中的唯一瓶颈和故障源。

它的性能问题表现为：响应时间极长（平均 21 秒，最大 2 分多钟）。错误率极高（5.59%）。性能随时间恶化（响应时间持续增长）。拖累整体性能（拉低了总平均响应时间和吞吐量）。其他接口（登录、添加博客等）性能表现良好，证明系统的基础架构和大部分功能是健康的。

8.8.4 改进建议

针对"列表页请求"存在的严重性能问题，建议从以下几个方面进行排查和优化：

服务端代码与数据库优化
审查 SQL 查询: 检查"列表页"对应的后端 SQL 语句。是否存在全表扫描、缺少索引、复杂的 JOIN 或子查询？使用 EXPLAIN 分析执行计划，对慢查询进行优化。
分页与懒加载: 如果列表页数据量巨大，确保实现了高效的分页机制（如基于游标的分页），避免一次性加载全部数据。
缓存策略: 对于不经常变动的列表数据，考虑引入 Redis 或 Memcached 进行缓存，显著减少数据库压力和响应时间。
异步处理: 如果列表页需要聚合多个服务或进行复杂计算，考虑将其部分逻辑异步化，先返回一个快速的骨架页面，再通过 AJAX 加载详细数据。
服务器资源配置与调优
监控资源: 在下一次测试时，同时监控应用服务器（CPU、内存、I/O）、数据库服务器（CPU、内存、IOPS、连接数）的资源使用情况。确认是否存在资源瓶颈。
调整 JVM 参数: 如果是 Java 应用，检查堆内存大小 (-Xmx) 是否足够，GC 日志是否频繁 Full GC。
调整 Web 服务器参数: 检查 Nginx/Apache/Tomcat 的配置，特别是与连接、超时、缓冲区相关的参数。
Tomcat: 调整 connectionTimeout, socketBuffer, maxHttpHeaderSize。
Nginx: 调整 proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout, proxy_buffer_size, proxy_buffers。
目标: 确保这些参数足够大，能够容纳"列表页"可能产生的大响应和长处理时间，避免因超时或缓冲区不足导致 TruncatedChunkException。
客户端与网络层面
增加客户端超时时间: 在 JMeter 中，适当增加 HTTP 请求的超时时间（Connect Timeout, Response Timeout），以排除因客户端过早放弃连接而导致的错误。
检查网络: 确认测试环境网络稳定，没有丢包或高延迟。如果可能，尝试在更靠近应用服务器的机器上运行测试，排除网络因素。
测试方案改进
隔离测试: 下次测试时，单独对"列表页请求"进行压力测试，以便更精确地定位问题。

增加监控: 在测试过程中，结合 APM (Application Performance Management) 工具（如 SkyWalking, Pinpoint, New Relic）进行链路追踪，精确定位是哪个方法或数据库操作耗时最长。

模拟真实场景: 确保测试数据量和用户行为模式接近生产环境，以便发现真实的性能瓶颈。

接⼝⾃动化项⽬实战解析及补充

3.1 需求分析

理解业务需求，若是针对未参与的项⽬实施接⼝⾃动化，应与业务⼈员、产品经理等沟通，了解接⼝

所⽀持的业务场景和业务逻辑。根据业务需求，明确接⼝需要实现的具体功能，如数据的获取、修

改、删除等操作，以及接⼝的输⼊输出要求。分析接⼝之间的依赖关系，确定接⼝的调⽤顺序和依赖

条件。

3.2 挑选接⼝

博客系统中接⼝较少，可以针对所有的接⼝实施⾃动化测试。

若是⼤型项⽬，可按照接⼝⾃动化流程中⸺挑选接⼝内容参考挑选

==执⾏测试⽤例 ==

⽤例执⾏顺序不是我们想要的？

3.6.1 指定⽤⼾执⾏顺序

在使⽤pytest进⾏测试时，有时候我们需要按照特定的顺序来运⾏测试⽤例，尤其是在涉及到测试⽤例

之间的依赖关系时。pytest本⾝并不直接⽀持通过配置来改变测试⽤例的默认运⾏顺序，pytest-order

是⼀个第三⽅插件，专⻔⽤于控制测试⽤例的执⾏顺序。⾸先，你需要安装这个插件：

python 复制代码

代码块 
pip install pytest-order==1.3.0

既可以⽤在测试类上，也可以⽤在测试⽅法上，以测试类为例：

python 复制代码

代码块 
@pytest.mark.order(1)
def test_one():
assert True
@pytest.mark.order(2)
def test_two():
assert True

执⾏结果：

3.7 ⽣成测试报告并分析结果

• 测试时间：

测试执⾏时间从19:15:56 持续到 19:15:58，总共耗时 1 秒 357 毫秒。测试时间与测试⽤例数量成正

⽐。⽤例数量越多，测试时间越⻓。通过优化测试脚本、并⾏执⾏和分布式测试环境，可以显著缩短
测试时间。

• 测试⽤例总数：

1 2 3 4 5 6 7共有 33 个测试⽤例，⾼测试⽤例总数通常表⽰测试覆盖范围⼴，能够更全⾯地验证接⼝功能；低测试

⽤例总数可能意味着测试覆盖不全⾯，存在遗漏的⻛险。
• 通过率：

饼图显⽰了测试的通过率为 100%，这意味着所有 30 个测试⽤例都成功执⾏，没有失败的测试⽤例。

通过率是衡量接⼝质量和测试效果的关键指标。在测试环境中，通过率应达到95%以上

总结

以上就是软件测试之博客系统项目实战（补充和解析部分）的全部内容了，喜欢博主写的内容可以一键三连，支持博主！！！