CYBERSOFT
Đăng nhập

Chạy test tự động trên CI/CD (GitHub Actions) cho người mới: từ workflow YAML tới report tự động

Chuyên công nghệNền tảngNgười mớiChuẩn SEO
🗓 1 tháng trước19 phút đọc·👁 522 lượt xem👤 315 người đọc

Bài cho người mới: học chạy test tự động trên CI/CD qua app TMĐT ShopEasy bằng GitHub Actions. Vì sao cần chạy test trên CI, cấu trúc workflow YAML cơ bản, chạy Playwright headless, lưu report/trace làm artifact, badge pass/fail, chạy song song (sharding), hai tình huống thật (quên chạy test trước merge gây bug lọt production, thiếu trình duyệt trên CI), nhiều mockup giao diện, FAQ và trắc nghiệm 5 câu. Chuẩn SEO, dẫn về khóa Tester CyberSoft.

1. Tóm tắt nhanh & pipeline bạn sẽ dựng

⭐ TL;DR — Chạy test trên CI/CD nghĩa là để GitHub Actions tự động cài đặt và chạy bộ test Playwright mỗi khi có push hoặc mở Pull Request, thay vì phải tự tay bấm chạy trên máy cá nhân. Bài này bám app TMĐT ShopEasy: bạn học vì sao cần CI, cấu trúc workflow YAML cơ bản, cách chạy Playwright headless trên CI, lưu report/trace làm artifact, badge pass/fail, và chạy song song (sharding) để rút ngắn thời gian. CyberSoft Academy dạy automation & CI/CD testing bài bản từ zero tới đi làm — https://cybersoft.edu.vn/software-testing-chuyen-nghiep-tu-zero-toi-duoc-nhan-viec-manual-automation-testing/. Nhiều hình minh hoạ và trắc nghiệm cuối bài.

Chào bạn mới! Ở bài Page Object Model, bạn đã học cách viết script Playwright chạy được trên máy cá nhân. Nhưng script chạy tốt trên máy bạn không có nghĩa là dự án đã an toàn — nếu chỉ có bạn biết chạy nó, và chỉ chạy khi bạn nhớ, thì code lỗi vẫn có thể lọt vào nhánh chính bất cứ lúc nào đồng đội khác quên chạy test. Đây chính là lý do cần chạy test trên CI/CD (Continuous Integration/Continuous Delivery): biến việc chạy test từ 'thói quen cá nhân' thành 'quy trình tự động, luôn xảy ra' mỗi khi có push hoặc Pull Request. Chúng ta sẽ học qua pipeline thật của ShopEasy, dùng GitHub Actions — công cụ CI miễn phí, tích hợp sẵn trong GitHub.

Pipeline CI: từ push code tới report tự động (ShopEasy) trigger on: push/PR npx playwright test upload-artifactPush codegit push / mở PRGitHub Actionsnhận sự kiện, khởi tạo máy ảoChạy Playwrightheadless, toàn bộ test suiteReport/ArtifactHTML report + trace lưu lại
Sơ đồ pipeline: push code kích hoạt CI, CI chạy Playwright, kết quả lưu thành report/artifact
📖 CI/CD: quy trình tự động hoá việc tích hợp (build, chạy test) và triển khai code mỗi khi có thay đổi, thay vì làm thủ công.

2. Vấn đề & vì sao chạy test trên CI quan trọng

Hãy hình dung nhóm ShopEasy có 5 lập trình viên, mỗi người viết code trên nhánh riêng rồi mở Pull Request để merge vào main. Nếu quy trình chỉ dựa vào việc 'mỗi người tự chạy test trước khi push', điều gì xảy ra khi một người đang gấp deadline, quên chạy, hoặc chỉ chạy đúng phần code mình sửa mà bỏ sót ảnh hưởng tới phần khác? Test có thể vẫn tồn tại trong repo, đầy đủ và chạy được — nhưng nếu không ai bắt buộc chạy nó, nó chẳng khác gì không tồn tại.

Chỉ chạy tay trên máy cá nhân, so với chạy tự động trên CI Tiêu chíChỉ chạy tay/localChạy tự động trên CIKhi nào test được chạyChỉ khi ai đó nhớ và tự chạyTự động mỗi lần push hoặc mở Pull RequestMôi trường chạyMáy mỗi người một khác (OS, phiên bản Node...)Cùng 1 máy ảo sạch, cấu hình giống hệt nhau mỗi lầnPhát hiện lỗiCó thể merge nhầm code lỗi vì quên chạy testChặn merge nếu test đỏ, phát hiện lỗi trước khi vào mainBằng chứng cho teamChỉ người chạy biết kết quảMọi người trong team đều thấy badge + report công khaiReport/trace khi failThường bị mất khi tắt máy hoặc đổi việc khácLưu lại làm artifact, xem lại bất cứ lúc nàoChạy test trên CI không thay thế chạy local — nó là lớp bảo vệ cuối trước khi code vào nhánh chính.
Bảng so sánh: chỉ chạy test tay/local, so với chạy tự động trên CI mỗi lần push/PR

Vấn đề còn sâu hơn: ngay cả khi ai đó có chạy test, máy của họ có thể khác máy của người khác — phiên bản Node.js khác, đã cài sẵn trình duyệt từ trước, hoặc có biến môi trường 'may mắn' đúng. Test 'pass trên máy tôi' không đảm bảo pass trên máy đồng đội, và càng không đảm bảo pass trên môi trường sẽ deploy thật. Đây là lý do cần một nơi chạy test THỐNG NHẤT, TỰ ĐỘNG, và KHÔNG PHỤ THUỘC vào việc ai đó có nhớ hay không — đó chính là CI.

📖 Continuous Integration (CI): phần 'tích hợp liên tục' của CI/CD: mỗi khi có code mới, hệ thống tự động build và chạy test để phát hiện lỗi sớm, trước khi code vào nhánh chính.

CI/CD gồm 2 phần: Continuous Integration (CI) — tự động build và chạy test mỗi khi có thay đổi code; và Continuous Delivery/Deployment (CD) — tự động đưa code đã qua kiểm tra tới môi trường staging/production. Bài này tập trung vào phần CI, cụ thể là cách kích hoạt Playwright chạy tự động. Về bản chất, một máy chủ CI như GitHub Actions sẽ: nhận sự kiện (push/Pull Request), khởi tạo một máy ảo 'sạch', cài đặt dự án từ đầu, chạy test, rồi báo kết quả — tất cả không cần con người can thiệp.

Nếu bạn muốn đi làm vị trí Automation Tester hoặc SDET, kỹ năng đọc hiểu và chỉnh sửa workflow CI/CD gần như là bắt buộc — vì hầu hết công ty hiện nay đều chạy test tự động trên pipeline, không còn chạy tay đơn thuần. Nội dung automation & CI/CD testing được dạy bài bản, có dự án thực chiến, trong khoá Software Testing chuyên nghiệp (Manual + Automation) của CyberSoft Academy: https://cybersoft.edu.vn/software-testing-chuyen-nghiep-tu-zero-toi-duoc-nhan-viec-manual-automation-testing/

💡 Nếu công ty bạn chưa dùng CI, đừng đợi 'ai đó khác' setup — một workflow CI/CD cơ bản chỉ mất khoảng 30 phút để dựng, và giá trị nó mang lại (chặn bug trước khi vào main) là ngay lập tức.

3. Cấu trúc workflow YAML cơ bản của GitHub Actions

Một workflow GitHub Actions là 1 file YAML nằm trong thư mục .github/workflows/ của repo. File này có 3 phần chính: 'name' (tên workflow, hiển thị trên GitHub), 'on' (khai báo sự kiện nào kích hoạt, ví dụ push hoặc pull_request), và 'jobs' (danh sách công việc cần làm, mỗi job chạy trên 1 máy ảo riêng, gồm nhiều 'steps' chạy tuần tự).

▶ Bước 1: Trong repo ShopEasy, tạo thư mục .github/workflows/ nếu chưa có, rồi tạo file tests.yml bên trong.

▶ Bước 2: Khai báo 'name' cho workflow và 'on: push, pull_request' để chạy tự động trên cả hai sự kiện, giới hạn nhánh main.

▶ Bước 3: Khai báo job 'test' chạy trên 'ubuntu-latest', đây là máy ảo Linux sạch do GitHub cấp phát mỗi lần chạy.

yaml
# .github/workflows/tests.yml
name: Run Playwright Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Cai dat dependencies
        run: npm ci

      - name: Cai dat trinh duyet Playwright
        run: npx playwright install --with-deps

      - name: Chay Playwright tests
        run: npx playwright test
🔒

Nội dung bị khoá

Bạn đang xem bản xem trước. Đăng nhập để mở khoá toàn bộ bài viết và tất cả tài liệu Tester/QA.

Đã xem 25% nội dung
  • Đọc trọn vẹn mọi bài viết
  • Lưu bài & ghi chú cá nhân
  • Theo dõi tiến độ đã đọc
  • Luyện phỏng vấn, ISTQB, Mock
Đăng nhập để đọc tiếp

Chưa có mã? Lấy mã qua Fanpage / Zalo CyberSoft.

0

💬 Bình luận (0)

Bạn có thể đọc mọi bình luận. Đăng nhập để bình luận

Chưa có bình luận nào. Hãy là người đầu tiên!