一、測試計劃

1. 目標

   • 驗證核心功能穩定性與正確性
   • 覆蓋典型業務場景（B 端+ C 端）
   • 保證多租戶、Pipeline、LLM 調用等關鍵模塊無阻礙
   • 收集并修復 Beta 發布前的主要缺陷

2. 范圍

   • 功能測試：文檔上傳／檢索、Pipeline 配置、LLM 問答、權限控制
   • 兼容性測試：多操作系統、多瀏覽器、多硬件配置
   • 性能測試：并發檢索吞吐、LLM 并發調用時延
   • 安全測試：多租戶隔離與權限邊界

3. 資源與角色

   • 測試負責人：吳佳峻
   • 支撐人員：后端開發（范興堃）、前端開發（葉佩霖）

4. 時間安排

   階段	時間	產出
   測試準備	2025/05/20–05/22	測試計劃、測試環境搭建
   功能 & 兼容性	2025/05/23–05/28	測試用例執行
   性能 & 安全	2025/05/29–06/02	性能報告、安全驗證
   缺陷修復回歸	2025/06/03–06/07	回歸測試報告
   總結與驗收	2025/06/08–06/10	測試總結、出口評估

二、測試環境與矩陣

備注：所有環境均在有線網絡（100 Mbps 以上）下測試。

三、測試過程與方法

用例設計

• 場景測試 (Scenario Testing)
  • B 端管理員：私有化部署 → 上傳內網文檔 → 配置多租戶權限 → 流水線問答
  • B 端終端用戶：在限定權限下執行問答 → 驗證權限邊界
  • C 端學習者：上傳 PDF → 自助配置默認 Pipeline → 一鍵問答 → 收藏與分享
• 邊界值 & 異常場景
  • 非法文件格式上傳、超大文件上傳、網絡中斷重連
  • 并發 50+ 請求、LLM 超時重試

執行方式

• 手工執行關鍵功能測試、兼容性測試
• 自動化腳本（Postman + pytest）跑回歸用例
• JMeter 并發壓測 LLM 服務

Apifox 自動化測試

• 在 Apifox 中，基于 OpenAPI/Swagger 文檔一鍵導入全部接口定義，生成統一的測試集合（Collection）。

• 為每個功能模塊（文檔上傳、向量檢索、Pipeline 執行、LLM 調用等）編寫了 >100 條斷言豐富的接口用例，包括狀態碼、響應字段、Schema 校驗、性能閾值等。

• 在本地與 CI 環境中均通過 Apifox CLI 執行：

  apifox run --project-id=<PID> --collection-id=<CID> --report report.json
  

• 結合 pytest 進行二次封裝，實現了接口返回內容與數據庫狀態聯動校驗，覆蓋了典型正、異常、邊界場景。

Apifox 壓力測試

• 針對文檔檢索與 LLM 調用兩大核心接口，使用 Apifox 的「壓力測試（Load Testing）」功能：
  • 并發配置：模擬 50、100、200 并發用戶，持續 5 分鐘；
  • Ramp-up 設置：在 60 秒內平滑增加至目標并發；
  • 斷言：90% 響應時間 ≤ 500ms，錯誤率 ≤ 1%；
  • 報告：生成柱狀響應時延分布、TPS 曲線、錯誤明細等。
• 結果表明，200 并發下檢索接口平均時延 320ms，錯誤率 0.8%，滿足 SLAs。
  

Apifox 定時測試

• 在 Apifox 云平臺創建 每日凌晨 2:00 定時執行任務：
  • 自動運行全量自動化用例集；
  • 輸出 HTML 和 JSON 格式測試報告，并通過飛書機器人推送結果摘要；
  • 若失敗用例 ≥ 1，則立即告警至相關開發者群。
• 持續監測關鍵接口穩定性，確保線上環境在任意時刻均在可控狀態。

與 CI/CD 集成

• 在 GitHub Actions 中集成 Apifox 測試步驟：

  - name: Run Apifox Tests
    run: apifox run --project-id=$PID --collection-id=$CID --report report.json
  - name: Upload Report
    uses: actions/upload-artifact@v3
    with:
      name: apifox-report
      path: report.json
  

• 每次 PR 合并 main 分支即觸發全量接口回歸與快速壓測，未通過時報紅并阻止發布。

缺陷管理

• 所有 Bug 記錄于 GitHub Issues，標記 Severity 和 Priority

• 測試中發現 28 個缺陷，全部在 Beta 發布前完成驗證與關閉

四、測試結果

1. Bug 概況

   • 共發現缺陷 28 條
     • Critical：2 （并發下檢索超時、權限繞過）
     • Major：8 （中文 PDF 解析失敗、Pipeline 順序異常）
     • Minor：18 （UI 文本溢出、按鈕樣式錯位等）
   • Issue 記錄率：100%，修復率：100%

2. 性能指標

   • 并發檢索吞吐：≥ 120 req/s（90% 響應 < 300 ms）
   • LLM 并發調用：支持 ≥ 20 并發，平均時延 1.2 s

3. 覆蓋率

   • 自動化用例：220 條
   • 代碼覆蓋率：82%（主干組件 > 90%）

4. 場景測試通過率

   場景	用例數	通過	通過率
   B 端管理員	40	40	100%
   B 端終端用戶	35	33	94%
   C 端學習者	45	45	100%
   異常 & 邊界場景	30	28	93%

五、Beta 版本出口條件（Exit Criteria）

1. 缺陷要求
   • 無未修復的 Critical 缺陷
   • Major 缺陷 ≤ 2 且不影響主要業務
2. 用例通過率 ≥ 95%
3. 性能達標：并發吞吐 + 時延滿足 SLAs
4. 安全驗證：多租戶隔離、權限管控無繞過
5. 文檔完善：用戶安裝指南、API 文檔、常見問題俱全

六、經驗與后續建議

• 文檔早規劃：測試初期即生成“快速上手”與“故障排查”文檔，減少測試與運維溝通成本。
• 場景驅動：場景測試覆蓋真實用戶流程，比單純功能測試更能提前暴露集成問題。
• 持續集成：自動化測試與 CI/CD 深度結合，實現“提交即測”，質量反饋更及時。
• 性能監控：Beta 發布后上線 Prometheus + Grafana 監控面板，實時跟蹤系統健康度。

結語
本次 Beta 測試覆蓋了 RAGnarok 的主要功能與典型場景，所有關鍵缺陷均已修復，性能與兼容性達標。