自動化檢查
32 · 30 通過
23 項 GraphQL（pytest）+ 9 項儀表板（Playwright），含 2 個記錄缺陷的 xfail——順序無關，一份合併的 Allure 報告，經 CI 驗證
為一個不是我寫的系統做 QA：Saleor
我圍繞一個本地固定版本的 Saleor 環境搭建了獨立、基於風險的 QA 框架，記錄 4 個缺陷或候選問題，並將 VFX 經驗中的感知差分方法用於跨瀏覽器視覺回歸。
獨立 QA 個案 · Saleor 3.23（本地固定版本）· 特定時點結果 · 發現已記錄，尚未向上游提交
測試/QA探索性測試PlaywrightpytestGraphQL視覺回歸WCAGi18n
已記錄發現
4 個發現
針對本地固定環境記錄 4 個缺陷或候選問題；其中 2 個有嚴格 xfail 回歸檢查支撐；均未向上游提交
惡意輸入下的 API
0 伺服器錯誤
8 例惡意輸入從不 500；查詢成本與批量限制均生效——如實報告為確實健壯
視覺基線
40
36 條覆蓋 chromium/firefox/webkit + 4 條 chromium 專屬 i18n 基線；重跑差異為 0 像素
植入回歸
在 0.01 處抓到
0.2px 字體度量漂移觸發閘門——5,366 個差異像素，比率 0.01 超過 0.005 上限
發現的 i18n 缺口
1 處真實缺口
“Catalog”/“Fulfillment” 在 zh-Hans / zh-Hant / ko 下均以英文顯示
我做了甚麼
我拿 Saleor——一個我並沒有參與開發的大型開源電商平台（Python/Django/GraphQL）——從外部為它搭起了一套獨立 QA 框架。測試透過 GraphQL API 和管理後台驅動執行中的應用，全程不複製、不修改 Saleor 自身代碼。
它分兩塊。第一塊是一套以風險為先的功能測試框架——32 項自動化檢查涵蓋 API 健壯性、存取控制和結帳，並在本地固定環境中記錄了 4 個缺陷或候選問題。第二塊是跨瀏覽器視覺回歸工具，它抓到了一處植入回歸，並發現了一處本地化缺口。
針對本地 Saleor 3.23（固定的預構建鏡像）從外部驅動。兩條通道——pytest（GraphQL）與 Playwright（儀表板 + axe）——在 CI 中輸出一份合併的 Allure 報告；視覺套件以獨立設定執行。以下每一項都對應倉庫中的一件工件：基於風險的測試計劃、可追溯性與覆蓋圖、4 份起草的缺陷報告，以及感知差分方法記錄。
測試框架 + 已記錄發現
我由一份以風險為先的計劃入手：給 14 個領域按「出問題的可能性」和「出了會有多嚴重」評分。資金流轉和存取控制排在最前，而 i18n、視覺回歸和無障礙則當作一流的重點來對待。整套功能測試的分量，壓在四項探針上。
健壯性測試套件——以及一個誠實的正向結論
一組 8 例惡意輸入（非法 id 與列舉、first 參數的極端值、深度巢狀與別名查詢）從不返回 500——每個失敗都是一個帶類型的 GraphQL 錯誤。查詢成本與批量大小限制均生效。Saleor 健壯之處，我如實報告為健壯，並將其固化為通過的測試，而非編造缺陷。
透過權限受限的 App 令牌做 RBAC
一個僅具 MANAGE_ORDERS 的 App 令牌證明了權限邊界——它能讀取訂單，卻不能建立產品——無需脆弱的員工邀請流程。匿名與員工的門控，以及 tokenCreate（有效與錯誤憑據）也一併涵蓋。
把結帳作為 GraphQL 流程
saleor-platform 不含店面，因此客戶旅程透過 API 演練：checkoutCreate → 加入行 → 地址 → 配送方式 → 合計，每個結帳、產品與受限 App 都在各自的測試內建立並拆除。
以真實系統而非假設為準
預期結果來自執行中的應用。一項負向輸入測試斷言真實的 HTTP 400 校驗契約——上游研究預測為 200；執行中的應用並不一致，把測試建立在系統之上正好抓到了這處差異。
4 個已記錄的缺陷或候選問題
一次有結構的探索性測試，針對本地固定版本 Saleor 3.23 產出了 4 份有證據支撐的發現報告。它們是作品集中的缺陷或候選問題，不是上游已確認缺陷，且均未提交上游；提交前需先去重並遵循 Saleor 的 CLA 或安全披露流程。
結帳元數據無上限——且可匿名寫入
Checkout 上的公開 updateMetadata 映射為 no_permissions，因此一個未認證的客戶端接受了 1 MB 的值、2,000 個鍵和一個 100,000 字元的鍵，且無任何錯誤——一個低成本的儲存/DoS 向量。一個嚴格 xfail 回歸斷言期望的 100 項上限，一旦限制落地便會告警。
關聯 Saleor #19210 · 已複現（完整）· 嚴格 xfail
結帳行列表無上限
checkoutLinesAdd 在一次呼叫中接受了 73 個不同的變體行（僅受種子目錄數量限制），且一個 CheckoutLine 接受了 1 MB 的元數據值——而每行數量被正確地限制在 50。第二個嚴格 xfail 固化了期望的列表長度上限。
關聯 Saleor #19209 · 已複現（完整）· 嚴格 xfail
儀表板 WCAG 障礙
axe-core 閘門在產品建立表單上發現 12 個無可讀名稱的圖示按鈕、缺失的文件 lang、被停用的雙指縮放，以及 5 個低於 AA 的對比度節點。高置信度項優先呈現；框架生成的 ARIA role 節點在提交前標註為需人工甄別。
新發現 · axe 證據 · 提交前先去重
X-Forwarded-For 信任 → 登入限流繞過
get_client_ip 信任最左側、由客戶端提供的 X-Forwarded-For 值，因此按 IP 的登入限流鍵由攻擊者掌控、可輪換。已對照 3.23.5 源碼核實並在線上確認限流；一次乾淨的端到端偽造需要帶代理的部署，因此這是部分（源碼核實）複現，而非完整的本地利用。
關聯 Saleor #19203 · 源碼核實 · 安全披露
一個有意思的副作用：我自己反覆的 tokenCreate 探測觸發了 Saleor 按 IP 的登入限流（LOGIN_ATTEMPT_DELAYED）。我沒有硬扛，而是讓 E2E 套件只登入一次進入共享 storageState、並讓 API 夾具對限流做重試——一個真實的可測試性約束，塑造了框架的認證複用架構。
視覺回歸 + 感知方法學
截圖是最容易的部分。一套視覺回歸工具真正值錢的地方，在於它是否只在「人看了也會說這是回歸」的時候才報錯，而不會被渲染噪聲、字體抖動或重新畫出來的時間戳帶偏。真正的交付物是這份判斷力，基線和那張被抓到的回歸截圖，都是從它衍生出來的。
跨瀏覽器 / 主題 / 視口矩陣
40 條已提交基線：三個高密度管理介面（產品編輯器、設定、訂單詳情）× 桌面 1280×800 + 流動 375×812 × 淺色 + 深色 × chromium/firefox/webkit，外加一次 4 語言的 i18n 遍歷。它填補了 saleor-dashboard 自帶設定留下的空白——僅 Chrome、無基線、無 Firefox/WebKit、無流動端。
確定性槓桿
固定 deviceScaleFactor 與視口，關閉動畫與游標，等待 document.fonts.ready，將時區/語言鎖定為 UTC/en-US，在首次導覽前於 localStorage 設定主題與 UI 語言，並遮罩動態區域（id、日期、金額、地址）。回報是：連續兩次乾淨執行差異為 0 像素——這正是閘門得以收緊的前提。
按失敗模式選擇度量
pixelmatch 是零依賴預設項；若出現確定性槓桿無法消除的伽瑪/抗鋸齒漂移，SSIM 是記錄在案的升級路徑；當套件執行時長要緊時可換用 odiff；而接入託管服務（Argos / Percy / Lost Pixel）做並排 PR 評審只是更換報告器，而非重寫。
源自 VFX 合成
在電影 VFX 工作中，我負責像素級 QC——判斷哪一處像素差異是缺陷，哪一處只是媒介的噪聲底。這套工具正是把那套判斷自動化，用於 Web UI。
閾值與比率的陷阱
Playwright 的 toHaveScreenshot 暴露兩個相互獨立的容差，而它們的盲點恰好相反。一次覆蓋整頁的 3° 色相旋轉在閾值 0.15 下通過——每個像素的 YIQ 差都低於逐像素閾值，於是 pixelmatch 計得零個不同像素。僅移動標題 1px 也通過——像素太少，跨不過比率。可靠觸發失敗的是 0.2px 的字距漂移：它移動了每個字形邊緣，點亮了文本密集螢幕約 1% 的像素（比率 0.01，超過 0.005 閘門）。要抓色彩漂移，你必須調低閾值；要抓佈局位移，你必須調低比率並優先選擇文本密集目標。這一相互作用正是核心的方法學要點。
證據——被抓到的植入回歸
為證明閘門仍然咬得住，我向最密集的介面——產品編輯器——注入一處細微的字體度量 + 色彩 + 1px 漂移，然後重跑套件。它如設計般在 5,366 個差異像素處失敗（比率 0.01，超過 0.005 閘門），並標記出表單上每一個位移的標籤。
這裡展示的是乾淨基線，而非原始的 pixelmatch 差分圖。差分幀是一張只標出變化像素的暗化偽彩疊加圖，脫離左右對照便讀作視覺噪聲——因此真正承載證據的是閘門據以判定的數字，即上文那次 5,366 像素（比率 0.01）的失敗，而不是那張圖。正是它讓構建變紅。
一處真實的 i18n 缺口，以視覺方式暴露
同一次語言遍歷帶出了一個真實發現：“Catalog” 與 “Fulfillment” 在 zh-Hans、zh-Hant 與 ko 下均以英文顯示，“Translations” 在 zh-Hans 與 ko 下也保持英文——以逐語言基線與一份記錄的標籤報告捕獲。在這些寬度下無裁切或溢出。這是儀表板翻譯完整度的缺口（提交前先在上游去重），而非佈局缺陷——是一處 QA 一致性發現，而非編造的缺陷。
誠實的說明
該框架驅動的是本地固定版本 Saleor 3.23 環境，因此每項結果都是針對該構建的特定時點結論。4 個缺陷或候選問題均已記錄為草報告，但未提交、也未獲上游確認；提交前需先去重，並遵循 Saleor 的 CLA 或安全披露流程。BR-004 是源碼審查與限流現象確認，而非完整的本地利用。在一組惡意輸入測試下，API 未出現 500，成本與批量限制均生效，這是一項如實記錄的正向結果。
最穩妥的解讀：這是圍繞一個陌生生產代碼庫搭建的獨立、基於風險的 QA——一套可用框架、4 個已記錄的缺陷或候選問題，以及能抓到植入回歸的感知差分工具——而非安全審計或上游貢獻記錄。
下一步
去重並按 Saleor 的流程提交起草的報告（X-Forwarded-For 發現走安全披露路徑）；把 API 通道擴展到優惠券與支付並發以及訂單履約狀態機；在固定的 Playwright 鏡像內引導生成 Linux CI 基線，並隨確定性得到驗證把閘門向每屏 0.1 / 0.001 收緊；並植入真實翻譯，把 i18n 探針升級為完整的語言矩陣。
定位為對陌生系統的外部、基於風險的 QA——ISTQB 風格的測試設計、貼近 ITIL 的缺陷報告，以及自 VFX 合成沿用而來的感知差分方法。
查看 / 執行
基於風險的計劃、可追溯性與覆蓋圖、四份起草的缺陷報告、合併的 Allure 報告，以及帶植入回歸證據的視覺回歸工具，都在倉庫中。歡迎索取講解或對報告的唯讀查看。
索取講解