Học Tester ở đâu tốt và thực chiến?

CyberSoft Tester cung cấp lộ trình học kiểm thử phần mềm từ cơ bản đến nâng cao: manual testing, automation với Playwright/Selenium, kiểm thử API, performance và AI testing, bám sát công việc thật của doanh nghiệp.

Người mới, chưa biết gì có học Tester được không?

Được. Lộ trình bắt đầu từ khái niệm test case, bug report rồi nâng dần lên automation và AI testing, kèm luyện phỏng vấn và CV để đi làm được.

AI Testing là gì và học như thế nào?

AI Testing là việc dùng AI (như Claude) để sinh test case, review, tăng độ phủ và tăng tốc kiểm thử. CyberSoft Tester có chuyên mục AI trong Testing và AI Agent trong Testing.

Có luyện thi ISTQB và phỏng vấn không?

Có. Nền tảng có ngân hàng câu hỏi ISTQB tự chấm, luyện phỏng vấn QA và mock interview mô phỏng thực tế.

Hook (beforeEach/afterEach...) trong test automation là gì?

Hook là các hàm đặc biệt chạy TỰ ĐỘNG vào những thời điểm cố định quanh vòng đời test: trước tất cả test (beforeAll), trước mỗi test (beforeEach), sau mỗi test (afterEach), sau tất cả test (afterAll). Bạn không gọi hook trực tiếp — công cụ test (như Playwright) tự gọi đúng lúc, giúp gom phần chuẩn bị/dọn dẹp dùng chung ra khỏi từng test riêng lẻ.

beforeEach và beforeAll khác nhau ở điểm nào?

beforeAll chạy đúng 1 lần duy nhất, trước khi bất kỳ test nào trong describe bắt đầu — phù hợp cho việc chuẩn bị tốn thời gian và không đổi giữa các test (ví dụ đọc file dữ liệu mẫu 1 lần). beforeEach chạy lại từ đầu trước MỖI test — phù hợp cho việc cần trạng thái sạch, độc lập ở mỗi test (ví dụ đăng nhập lại để test không phụ thuộc thứ tự chạy).

Không viết afterEach dọn dẹp thì có sao không?

Có thể chạy được vài test đầu, nhưng dữ liệu do test trước tạo ra (sản phẩm trong giỏ, tài khoản vừa đăng ký...) sẽ còn tồn tại khi test sau chạy. Điều này khiến test sau nhận trạng thái không như mong đợi, dễ fail ngẫu nhiên hoặc chỉ fail khi chạy theo đúng thứ tự nhất định — rất khó debug vì lỗi 'ẩn' trong dữ liệu sót lại từ trước, không nằm ở chính đoạn code đang test.

Mục đích chính của việc dùng test.describe để nhóm nhiều test lại là gì? A. Gộp các test cùng một màn hình/tính năng vào một khối, để dùng chung hooks và dễ đọc, dễ tìm khi có lỗi B. Làm test chạy song song nhanh hơn tự động C. Ẩn bớt log lỗi khi test fail D. Thay thế hoàn toàn việc đặt tên file test

✅ Đáp án: A. describe nhóm các test liên quan vào 1 khối, nhờ đó hooks (beforeEach/afterEach...) khai báo bên trong áp dụng chung cho cả nhóm, và người đọc dễ hình dung phạm vi test.

test.beforeEach() trong 1 test.describe sẽ chạy vào lúc nào? A. Chỉ 1 lần duy nhất, trước test đầu tiên của cả file B. Trước MỖI test trong describe đó, lặp lại nhiều lần C. Sau khi tất cả test trong describe đã chạy xong D. Chỉ chạy khi test trước đó bị fail

✅ Đáp án: B. beforeEach lặp lại trước mỗi test, giúp mỗi test bắt đầu từ một trạng thái chuẩn bị giống nhau (ví dụ đã đăng nhập) mà không phụ thuộc test chạy trước nó.

Vì sao nên viết afterEach để xoá sản phẩm khỏi giỏ hàng sau mỗi test cart? A. Để test chạy nhanh hơn đáng kể B. Để tránh dữ liệu (sản phẩm trong giỏ) từ test trước làm sai kết quả của test chạy sau C. Vì Playwright bắt buộc phải có afterEach mới chạy được test D. Để tự động sinh báo cáo test đẹp hơn

✅ Đáp án: B. Không dọn dẹp sau mỗi test khiến dữ liệu (như sản phẩm còn trong giỏ) tồn tại sang test kế tiếp, gây fail ngẫu nhiên khó debug — afterEach giải quyết đúng vấn đề này.

Khi nào nên dùng beforeAll thay vì beforeEach cho phần chuẩn bị dữ liệu? A. Khi phần chuẩn bị tốn thời gian và giống hệt nhau cho mọi test, không cần lặp lại mỗi lần B. Khi mỗi test cần một trạng thái đăng nhập độc lập, khác nhau C. Khi muốn dữ liệu bị xoá ngay sau từng test D. Khi test cần chạy độc lập, không phụ thuộc kết quả của test khác

✅ Đáp án: A. beforeAll phù hợp cho việc tốn thời gian và không đổi giữa các test (đọc file dữ liệu mẫu 1 lần); còn beforeEach phù hợp khi mỗi test cần trạng thái riêng, độc lập với test khác.

Vai trò của file .gitignore trong một dự án automation là gì? A. Khai báo các hook beforeEach/afterEach dùng chung B. Liệt kê những tệp/thư mục KHÔNG nên đưa vào git, như node_modules/, báo cáo test, trace C. Cấu hình baseURL và trình duyệt chạy test D. Chứa dữ liệu mẫu (tài khoản, sản phẩm) dùng cho test

✅ Đáp án: B. .gitignore giúp loại các tệp sinh ra khi chạy test (node_modules/, playwright-report/, trace...) khỏi git, giữ repo gọn nhẹ và tránh commit nhầm dữ liệu không cần thiết.

Cấu trúc dự án test & hooks (beforeEach/afterEach) cho người mới: tổ chức bền vững (có code chạy được)

Bài cho người mới: học cấu trúc dự án test & test hooks (beforeEach/afterEach) qua app TMĐT ShopEasy. Cấu trúc thư mục chuẩn tests/fixtures/config, đặt tên file/test, nhóm bằng describe, vòng đời 4 hook, hai tình huống thật (lặp code đăng nhập, thiếu afterEach gây rác dữ liệu), 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 & màn hình bạn sẽ test

⭐ TL;DR — Cấu trúc dự án test là cách tổ chức thư mục, đặt tên file/test và nhóm test (describe) sao cho ai đọc cũng hiểu ngay. Test hooks (beforeAll/beforeEach/afterEach/afterAll) là các hàm chạy tự động quanh vòng đời test, giúp gom phần chuẩn bị và dọn dẹp dùng chung ra khỏi từng test. Bài này bám màn giỏ hàng của app TMĐT ShopEasy: bạn học thư mục chuẩn tests/fixtures/config, cách viết test.describe kèm beforeEach/afterEach bằng Playwright chạy được thật, và hai tình huống thật cho thấy cái giá phải trả khi thiếu hooks. Nhiều hình minh hoạ và trắc nghiệm cuối bài.

Chào bạn mới! Khi vừa học automation, phản xạ tự nhiên là mở thư mục dự án, tạo ngay 1 file test đầu tiên, rồi cứ thế thêm file mới mỗi khi có tính năng cần test — không theo quy tắc thư mục hay đặt tên nào cả. Cách này chạy được với vài test đầu tiên. Nhưng khi số lượng test tăng lên, và mỗi test đều cần đăng nhập, dọn dữ liệu trước/sau khi chạy, bạn sẽ thấy cùng một đoạn code chuẩn bị/dọn dẹp lặp đi lặp lại ở khắp nơi, còn file test thì nằm lộn xộn không theo trật tự nào. Cấu trúc dự án test rõ ràng, cộng với test hooks, chính là cách giải quyết cả hai vấn đề: có nơi cố định cho từng loại tệp, và có chỗ cố định để chạy phần chuẩn bị/dọn dẹp dùng chung. Chúng ta sẽ học qua màn giỏ hàng thật của ShopEasy, có hình minh hoạ và code Playwright chạy được.

Màn hình test: giỏ hàng ShopEasy, chú thích badge còn sót sản phẩm do thiếu dọn dẹp giữa các test

📖 Cấu trúc dự án test: cách tổ chức thư mục, đặt tên file/test, và nhóm test (describe) của một dự án automation, sao cho bất kỳ ai đọc cũng nhanh chóng biết tệp nào chứa gì và cần sửa ở đâu.

2. Vấn đề: dự án test không có cấu trúc & không dùng hooks

Hãy hình dung một dự án automation ShopEasy sau 3 tháng phát triển không theo quy tắc nào: có file tên test1.js, có file tên checkTest.js, có file tên gio_hang_v2_final.js nằm cùng thư mục gốc. Không ai biết chắc file nào đang được dùng, file nào là bản nháp cũ còn sót lại. Khi cần sửa test giỏ hàng, bạn phải mở từng file để tìm, tốn thời gian chỉ để xác định 'mình nên sửa ở đâu'.

Vấn đề thứ hai, sâu hơn, là thiếu hooks. Mỗi test giỏ hàng đều cần đăng nhập trước; không dùng beforeEach, nghĩa là 5 dòng code đăng nhập được copy-paste vào từng test. Không dùng afterEach để xoá giỏ hàng sau mỗi test, nghĩa là test chạy sau 'thừa hưởng' luôn sản phẩm mà test chạy trước để lại — dẫn tới kết quả sai lệch không phải vì tính năng lỗi, mà vì dữ liệu bẩn tồn đọng. Cả hai vấn đề — cấu trúc lộn xộn và thiếu hooks — cộng dồn lại khiến bộ test ngày càng khó tin tưởng, và mỗi lần có lỗi lại mất rất nhiều thời gian chỉ để tìm ra nguyên nhân thật sự.

📖 Hook: hàm đặc biệt trong công cụ test (như Playwright) chạy tự động vào thời điểm cố định quanh vòng đời test — trước/sau tất cả test, hoặc trước/sau mỗi test — thay vì phải gọi thủ công trong từng test.

3. Cấu trúc dự án test là gì & nguyên tắc đặt tên

Cấu trúc dự án test gồm hai phần gắn liền nhau: (1) cách chia thư mục — tệp nào nằm ở đâu, và (2) cách đặt tên — tên file, tên test, tên nhóm test nói lên điều gì. Một dự án có cấu trúc tốt trả lời được ngay câu hỏi: 'Tôi cần sửa test đăng nhập, nên mở file nào?' mà không cần tìm kiếm hay đoán mò.

Nguyên tắc đặt tên phổ biến trong Playwright: mỗi màn hình/luồng nghiệp vụ có 1 file *.spec.js riêng (login.spec.js, cart.spec.js, checkout.spec.js), tên file nói rõ nó test cái gì. Bên trong file, dùng test.describe('ShopEasy - Tên tính năng', ...) để nhóm các test liên quan, và mỗi test('mô tả hành vi cụ thể', ...) nên mô tả rõ ràng bằng câu tiếng Việt hoặc tiếng Anh dễ hiểu, tránh viết tắt khó đoán như test('tc1').

💡 Đặt tên test bắt đầu bằng động từ mô tả hành vi (ví dụ 'thêm sản phẩm vào giỏ hàng thành công', 'giỏ hàng trống khi vừa đăng nhập') — khi test fail, chỉ nhìn tên là đoán ngay được nên mong đợi gì.

4. Cấu trúc thư mục dự án automation chuẩn

Một dự án Playwright chuẩn thường tách rõ các khu vực: thư mục tests/ chứa các file *.spec.js (mỗi luồng nghiệp vụ 1 file), thư mục fixtures/ chứa dữ liệu mẫu dùng lại giữa nhiều test, cùng với playwright.config.js ở gốc dự án để cấu hình chung, và .gitignore để loại các tệp không nên đưa vào git.

Cấu trúc thư mục chuẩn của một dự án automation Playwright: tests/, fixtures/, config, .gitignore

text

shopeasy-automation/
├── tests/
│   ├── login.spec.js     # kich ban test dang nhap
│   └── cart.spec.js      # kich ban test gio hang
├── fixtures/
│   └── test-data.json    # du lieu mau: tai khoan, san pham...
├── playwright.config.js  # cau hinh chung: baseURL, retries...
├── .gitignore            # loai node_modules, report khoi git
└── package.json

💡 Khi dự án lớn dần, có thể thêm thư mục pages/ cho Page Object hoặc utils/ cho hàm dùng chung — nhưng ngay từ đầu, chỉ cần tests/, fixtures/, config và .gitignore là đủ gọn để bắt đầu đúng cách.

5. Hooks là gì & vòng đời beforeAll/beforeEach/afterEach/afterAll

Playwright cung cấp 4 hook chính, đặt bên trong test.describe: test.beforeAll() chạy đúng 1 lần trước khi test đầu tiên bắt đầu; test.beforeEach() chạy lại trước MỖI test; test.afterEach() chạy sau MỖI test dù test đó pass hay fail; test.afterAll() chạy đúng 1 lần sau khi test cuối cùng đã xong. Bốn hook này tạo thành một vòng đời lặp lại: chuẩn bị chung một lần, rồi chuẩn bị riêng — chạy — dọn riêng cho từng test, và cuối cùng dọn chung một lần.