QA 工程師的第一條 GitHub Actions Pipeline

<h1 QA 工程師的第一條 GitHub Actions Pipeline</h1 <hr <h2 目錄</h2 <ol <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E4%BA%BA%E5%B7%A5%E8%A7%B8%E7%99%BC" 為什麼我的測試要靠人工觸發才跑</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E6%98%AF%E4%BB%80%E9%BA%BC" GitHub Actions 是什麼，用 QA 的語言說</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E5%9B%9B%E5%80%8B%E6%A6%82%E5%BF%B5" 四個你需要懂的概念</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E7%AC%AC%E4%B8%80%E6%A2%9D workflow" 第一條 workflow：PR 開出來就跑測試</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E7%9C%8B%E7%B5%90%E6%9E%9C" 跑完測試，怎麼看結果</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E4%BE%BF%E5%AE%9C%E4%BA%86" 2026 年跑 CI 比以前便宜了</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E4%B8%8B%E4%B8%80%E6%AD%A5" 下一步可以做什麼</a </p </li </ol <hr <h2 為什麼我的測試要靠人工觸發才跑</h2 <p 我之前的工作流程是這樣的：</p <ol <li <p RD 說「我改完了」</p </li <li <p 我去測</p </li <li <p 測完說「可以上了」</p </li </ol <p 每一個環節都靠人工。測試什麼時候跑，取決於我有沒有空、有沒有被通知到、有沒有忘記。</p <p 這個流程有一個很大的問題：<strong 每次測試的起點是人，而人是不穩定的。</strong </p <p 有時候 RD 忘記通知，功能就直接合進去了。有時候我在忙別的，測試就晚了一天。有時候上線後才發現某個基本流程壞掉，但那個功能上週就改了，只是沒有人跑測試。</p <p GitHub Actions 解決的就是這個問題：<strong 讓測試的觸發點從「人」變成「事件」。</strong </p <hr <h2 GitHub Actions 是什麼，用 QA 的語言說</h2 <p GitHub Actions 是一個自動化系統，當你的 code repository 發生某件事（有人開 PR、有人 merge、有人推 commit），它就自動去做你指定的工作。</p <p 對 QA 來說，最常用的場景是：</p <blockquote <p <strong 有人開 PR → 自動跑測試 → 回報結果</strong </p </blockquote <p 你設定好規則之後，不需要任何人手動觸發。只要有 PR 開出來，測試就跑。跑完告訴你通過還是失敗。</p <p 這件事聽起來很技術，但設定起來並不難——它的核心就是一個 YAML 檔案。</p <hr <h2 四個你需要懂的概念</h2 <p 在看任何 GitHub Actions 設定之前，先把這四個詞搞清楚：</p <pre <code Workflow └── Trigger（什麼時候跑） └── Job（做什麼大工作） └── Step（一步一步怎麼做） </code </pre <p <strong Workflow</strong ：整個自動化流程的描述，存成一個 <code .yml</code 檔案放在 <code .github/workflows/</code 資料夾。</p <p <strong Trigger</strong ：什麼事件會觸發這個 workflow。常用的：</p <ul <li <p <code push</code ：有人推 code</p </li <li <p <code pull request</code ：有人開 PR 或更新 PR</p </li <li <p <code schedule</code ：定時跑（像 cron job）</p </li <li <p <code workflow dispatch</code ：手動觸發</p </li </ul <p <strong Job</strong ：一個 workflow 裡可以有多個 job，每個 job 跑在獨立的虛擬機器上，job 之間可以設定相依關係。</p <p <strong Step</strong ：Job 裡的每一個步驟。可以是 shell 指令，也可以是別人寫好的 action（GitHub Marketplace 有很多現成的）。</p <hr <h2 第一條 workflow：PR 開出來就跑測試</h2 <p 以下是一個最基本的範例，讓你在每次 PR 的時候自動跑 Python 的測試：</p <pre <code class="language yaml" .github/workflows/run tests.yml name: Run Tests on PR on: pull request: branches: [main, develop] 只在這兩個 branch 的 PR 觸發 jobs: test: runs on: ubuntu latest 用 GitHub 提供的 Ubuntu 虛擬機 steps: name: 拉下程式碼 uses: actions/checkout@v4 name: 安裝 Python uses: actions/setup python@v5 with: python version: '3.11' name: 安裝相依套件 run: pip install r requirements.txt name: 跑測試 run: pytest tests/ v </code </pre <p 這個檔案放進去之後，每次有人對 <code main</code 或 <code develop</code 開 PR，GitHub 就會自動：</p <ol <li <p 啟動一台乾淨的 Ubuntu 虛擬機</p </li <li <p 把 code 拉下來</p </li <li <p 安裝 Python 和套件</p </li <li <p 跑 pytest</p </li </ol <p 全程不需要任何人手動做任何事。</p <hr <h2 跑完測試，怎麼看結果</h2 <p 跑完之後，PR 頁面下方會出現一個 checks 的狀態：</p <ul <li <p ✅ 綠色：所有測試通過</p </li <li <p ❌ 紅色：有測試失敗，可以點進去看 log</p </li </ul <p 這個狀態可以設成「必須通過才能 merge」，讓 RD 沒辦法在測試紅燈的情況下把 code 合進去。</p <p <strong 上傳測試報告當 artifact：</strong </p <p 如果你想保留每次跑的測試報告，可以加一個步驟：</p <pre <code class="language yaml" name: 上傳測試報告 uses: actions/upload artifact@v4 if: always() 不管測試通過失敗都上傳 with: name: test report path: reports/ retention days: 14 </code </pre <p <code if: always()</code 很重要——如果不加，測試失敗的時候這一步就會被跳過，你就看不到失敗的 log 了。</p <hr <h2 2026 年跑 CI 比以前便宜了</h2 <p 2026 年 1 月，GitHub 把 hosted runner 的費用降了最多 39%。</p <p 對 QA 來說，最實際的意義是：<strong 如果你用 GitHub Actions 跑自動化測試，成本比之前低不少。</strong </p <p Public repository 的 runner 使用依然免費。Private repository 有每月的免費額度（Free 方案 2000 分鐘/月），超過才計費。對於中小型專案，通常免費額度就夠了。</p <hr <h2 下一步可以做什麼</h2 <p 第一條 workflow 跑通之後，可以往這幾個方向延伸：</p <table style="min width: 50px;" <colgroup <col style="min width: 25px;" <col style="min width: 25px;" </colgroup <tbody <tr <th colspan="1" rowspan="1" <p 方向</p </th <th colspan="1" rowspan="1" <p 怎麼做</p </th </tr <tr <td colspan="1" rowspan="1" <p 跑 Android Appium 測試</p </td <td colspan="1" rowspan="1" <p 加 <code reactivecircus/android emulator runner</code </p </td </tr <tr <td colspan="1" rowspan="1" <p 跑多個 Python/Node 版本</p </td <td colspan="1" rowspan="1" <p 用 <code matrix</code 策略</p </td </tr <tr <td colspan="1" rowspan="1" <p 定時回歸測試</p </td <td colspan="1" rowspan="1" <p trigger 改成 <code schedule: cron</code </p </td </tr <tr <td colspan="1" rowspan="1" <p 測試失敗時通知 Slack</p </td <td colspan="1" rowspan="1" <p 加 Slack notification action</p </td </tr <tr <td colspan="1" rowspan="1" <p 發布測試報告到 GitHub Pages</p </td <td colspan="1" rowspan="1" <p 加 Allure report + gh pages deploy</p </td </tr </tbody </table <p GitHub Actions 的好處是每一個擴充都是獨立的步驟，你可以慢慢加，不需要一次全部設定好。</p <p 先讓最基本的「PR 開出來就跑測試」跑通，其他的等你需要的時候再加。</p <hr <p <em 參考資料：</em <a target=" blank" rel="noopener noreferrer nofollow" href="https://docs.github.com/en/actions" <em GitHub Actions 官方文件</em </a <em ／ </em <a target=" blank" rel="noopener noreferrer nofollow" href="https://github.com/resources/insights/2026 pricing changes for github actions" <em GitHub Actions 2026 定價調整</em </a </p