接口自动化测试项目-知识库

关于知识库项目业务介绍：

• 您好，我参与的知识库项目是一个以数据整合与高效检索为核心的Web平台，主要面向用户提供知识管理、多维度搜索及可视化分析服务。项目分为前台和后台两大模块：前台聚焦用户侧功能，包括首页热门推荐、多条件搜索（支持关键词/分类/时间筛选）、知识详情页（集成30+图表类型的数据可视化展示），以及个人中心的收藏、订阅、反馈等交互功能；我的核心职责是确保前台接口的功能稳定性和数据准确性，覆盖用户从注册登录、数据检索到交互操作的全流程体验。

知识库项目接口自动化串联场景示例

场景1：用户从登录到收藏的完整链路​​

​​功能路径​​：登录 → 搜索 → 收藏 → 验证数据一致性
​​接口链路与关键点​​：

1. ​​登录接口​​（POST /auth/login）：
   • 用账号密码登录，提取返回的user_id，后续所有操作都依赖此身份。
2. ​​全局搜索接口​​（GET /search?keyword=医疗政策）：
   • 搜索关键词，提取第一个knowledge_id（如id=1001）。
3. ​​收藏接口​​（POST /knowledge/1001/favorite）：
   • 用上一步的knowledge_id收藏知识，生成favorite_id。
4. ​​验证收藏记录​​（GET /user/favorites?user_id=xxx）：
   • 检查返回列表中是否包含knowledge_id=1001，并对比数据库的收藏时间。

场景2：越权删除他人数据​​

​​功能路径​​：用户A收藏 → 用户B尝试删除 → 拦截越权
​​接口链路与关键点​​：

1. ​​用户A收藏​​（POST /knowledge/1001/favorite）：
   • 生成favorite_id=500。
2. ​​用户B恶意调用删除接口​​（DELETE /user/favorites/500）：
   • 携带B的Token，但操作A的收藏ID。
3. ​​验证结果​​：
   • 接口返回403 Forbidden，且数据库中的favorite_id=500未被删除。

​​成果​​：

• 拦截3类越权操作，推动权限系统升级为RBAC模型，缺陷率下降70%。

场景3：搜索与缓存同步验证​​

​​功能路径​​：搜索 → 修改数据 → 验证缓存更新
​​接口链路与关键点​​：

1. ​​多条件搜索​​（GET /search/filters?category_id=3）：
   • 提取结果中的knowledge_id列表。
2. ​​后台修改数据​​：
   • 将某个知识的分类从3改为4（模拟数据更新）。
3. ​​再次搜索​​：
   • 验证结果中是否排除该知识，并检查Redis缓存cache:category_3是否失效。

​​发现问题​​：

• 数据库更新后，前端仍展示旧数据（缓存未同步）。
• ​​推动修复​​：在数据更新事务中触发Redis缓存删除，响应速度提升40%。

知识库搜索功能测试

1. 功能准确性测试​​

​​测什么​​：用户输入关键词、选分类、选时间后，结果对不对？

• ​​组合测试​​：试了30多种条件组合，比如：
  • 只搜关键词（如“医疗政策”）
  • 关键词+分类（如“医疗政策”+政府文件）
  • 关键词+时间（如“机器学习”+2023年）
• ​​发现问题​​：
  • 按“热度”排序时，老数据一直排前面 → 让开发改成“新数据权重更高”（热度=收藏数/时间差）
  • 空关键词搜索（比如只选分类）会漏数据 → 推动修复查询逻辑

---

​​2. 性能效率测试​​

​​测什么​​：很多人同时搜索会不会卡？数据改了结果是否及时更新？
​​怎么测​​：

• ​​模拟高并发​​：用JMeter模拟1000人同时搜“医疗政策” → 原来看结果要1.2秒，优化后0.35秒（加了Redis缓存热门词）
• ​​缓存刷新​​：改完数据后手动清空Redis → 保证用户下次搜到新数据（缓存命中率从68%提到92%）

---

​​3. 安全防护测试​​

​​测什么​​：防止黑客攻击和用户乱删数据。
​​怎么测​​：

• ​​输入恶意代码​​：比如搜医疗'; DROP TABLE（删表语句） → 系统拦截，正常显示结果
• ​​越权操作​​：用户A收藏的数据，用户B不能删 → 调删除接口直接报错403，数据库不变

---

​​4. 数据一致性测试​​

​​测什么​​：数据库、搜索列表、页面显示的数据是否一致？
​​怎么测​​：

• ​​改数据验证同步​​：
  • 后台改标题 → 1分钟内前台搜索必须显示新标题
  • 发现ES同步延迟5分钟 → 推动开发优化成实时同步
• ​​自动化对比​​：用脚本检查数据库的“分类”和页面显示的标签是否一致，发现过3次数据错位

面试回答策略

表忠心」策略​​

• ​​场景​​：领导问“能接受加班吗？”
• ​​回答​​：不直接答Yes/No，而是绑定「目标感」：我的原则是​​目标导向​​。比如知识库上线前，为保障搜索模块零故障，我和团队连续两周每晚复盘到10点（案例）。只要项目需要，我会全力投入（态度）。

「问题引导」策略

• ​​​场景​​：领导问“你的缺点/优点是什么？”

• 回答：“早期我在​​跨团队协作中，有时未能主动同步信息​​，这是一个我持续优化的点。
• ​​具体表现​​：比如在知识库项目初期，我专注执行测试用例，但未及时向开发同步风险（如搜索接口超时问题）。
• ​​改进动作​​：后来通过两个策略调整：
  1. ​​建立同步机制​​：每天站会分享测试进展，用飞书文档实时更新风险清单；
  2. ​​前置沟通​​：需求评审时主动提问，提前确认模糊点（如“分类筛选”是否支持多选）。
• 成果：这段经历让我深刻认识到：​​主动沟通是保障项目质量的重要环节​​，这也是我当前工作中坚持的原则。”

charles在项目中的应用

在知识库项目中，我主要运用Charles的以下核心功能解决测试痛点，以下是具体实例说明：

---

一、​​接口抓包与数据验证​​

​​功能应用​​：实时监控接口请求/响应，验证参数传递与数据一致性
​​项目案例​​：

1. 在测试「多条件搜索」功能时，通过Charles抓取GET /search/filters接口请求，发现前端错误传递了硬编码参数category=烘焙（应动态获取用户选择）
2. 对比接口返回的knowledge_id列表与数据库查询结果，发现ES同步延迟导致数据缺失，推动开发增加双写事务机制
   ​​成果​​：定位3次数据不同步缺陷，接口响应准确性提升至99.9%

---

二、​​断点调试（Breakpoints）​​

​​功能应用​​：拦截并修改请求/响应数据，验证异常处理能力
​​项目案例​​：

1. 测试收藏接口容错性时，拦截POST /knowledge/{id}/favorite响应，修改状态码为500模拟服务端异常
2. 发现前端未处理超时重试机制，导致用户重复点击产生脏数据
   ​​成果​​：推动前端增加「请求锁」机制，异常场景下用户操作失败率降低85%

---

三、​​Map Local映射测试​​

​​功能应用​​：本地文件替换线上响应，快速验证新逻辑
​​项目案例​​：

1. 在验证「热度算法优化」需求时（新数据权重提升），将搜索接口GET /search响应映射到本地JSON文件
2. 修改测试数据中"publish_time":"2023-07-01"为半年前数据，验证排序是否下降
   ​​成果​​：提前发现权重系数计算错误，避免算法缺陷上线

---

四、​​Throttle Settings网络限速​​

​​功能应用​​：模拟弱网环境，测试性能与降级策略
​​项目案例​​：

1. 设置500Kbps带宽限制测试文件下载接口GET /knowledge/{id}/download
2. 发现进度条组件在低速下载时UI卡死，推动增加分片加载动画
   ​​成果​​：弱网环境下用户流失率减少40%

---

五、​​Repeat压力测试​​

​​功能应用​​：重复发送请求验证接口幂等性
​​项目案例​​：

1. 对订阅接口POST /knowledge/{id}/subscribe进行10次快速重放
2. 发现数据库产生重复订阅记录，推动增加user_id+knowledge_id唯一索引
   ​​成果​​：拦截2类幂等性问题，关键接口稳定性达标100%

---

六、​​SSL Proxying安全分析​​

​​功能应用​