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ế.

Locator và selector khác nhau như thế nào?

Trong thực hành automation, hai từ này thường dùng thay thế nhau: 'selector' nhấn mạnh CÚ PHÁP để tìm phần tử (ví dụ chuỗi CSS hay XPath), còn 'locator' là khái niệm rộng hơn trong công cụ như Playwright — một đối tượng đại diện cho phần tử, có thể tạo từ selector, từ role, từ text, hay từ data-testid. Nói ngắn gọn: mọi selector đều dùng được để tạo locator, nhưng locator không nhất thiết chỉ dựa trên selector CSS/XPath.

Vì sao nên ưu tiên data-testid hơn class hay id do CSS-in-JS tự sinh?

Class hay id do công cụ CSS-in-JS (như styled-components, emotion) tự sinh thường có chuỗi ký tự ngẫu nhiên, có thể đổi mỗi lần build lại dù giao diện không hề thay đổi về nghiệp vụ. Thuộc tính data-testid do đội phát triển chủ động gắn thêm chỉ với mục đích phục vụ kiểm thử, không liên quan style hay logic hiển thị, nên gần như không đổi khi refactor CSS hay đổi thư viện UI — giúp locator bền hơn hẳn theo thời gian.

Khi nào bắt buộc phải dùng XPath thay vì CSS selector?

Phần lớn trường hợp, CSS selector hoặc locator ngữ nghĩa (role, text, data-testid) đã đủ dùng và dễ đọc hơn XPath. XPath chỉ thật sự cần khi phải tìm phần tử dựa trên nội dung văn bản kết hợp điều hướng phức tạp mà CSS không hỗ trợ, ví dụ tìm phần tử cha từ phần tử con. Ngay cả khi đó, nên viết XPath TƯƠNG ĐỐI, ngắn, dựa trên thuộc tính ổn định — tránh XPath tuyệt đối kiểu /html/body/div[2]/div[3]... vì chỉ cần thêm/bớt 1 thẻ là vỡ ngay.

Đội FE dùng CSS-in-JS khiến class đổi ngẫu nhiên mỗi lần build. Loại locator nào nên ưu tiên để test không vỡ theo? A. class CSS do công cụ tự sinh B. XPath tuyệt đối tính từ thẻ html C. data-testid do đội dev chủ động gắn cho phần tử D. Chỉ số vị trí (nth-child) trong danh sách phần tử

✅ Đáp án: C. data-testid không phụ thuộc style hay cấu trúc DOM tự sinh, nên vẫn ổn định dù class đổi liên tục.

Thuộc tính data-testid có đặc điểm gì khiến nó phù hợp làm locator cho test tự động? A. Được đội dev gắn riêng cho mục đích test, không liên quan style/logic hiển thị B. Tự động sinh ngẫu nhiên mỗi lần trang tải lại C. Chỉ tồn tại trên trình duyệt Chrome D. Thay thế hoàn toàn vai trò của CSS trong giao diện

✅ Đáp án: A. Vì không phục vụ style, data-testid gần như không đổi khi refactor giao diện, giúp locator bền vững.

Vì sao nên tránh XPath tuyệt đối như /html/body/div[2]/div[3]/button? A. Vì Playwright không hỗ trợ chạy XPath B. Vì chỉ cần thêm/bớt 1 thẻ trong cây DOM là locator vỡ ngay C. Vì XPath chạy chậm hơn CSS selector gấp 10 lần D. Vì XPath không thể dùng để click phần tử

✅ Đáp án: B. XPath tuyệt đối gắn cứng với toàn bộ đường dẫn DOM, chỉ một thay đổi nhỏ ở cấu trúc trang cũng đủ làm sai đường dẫn.

Trong Playwright, page.getByRole('button', { name: 'Đăng nhập' }) dùng để làm gì? A. Tìm phần tử theo vai trò accessibility (ví dụ nút bấm) kết hợp tên hiển thị/accessible name B. Tìm phần tử theo class CSS chính xác C. Tìm toàn bộ phần tử có thẻ button trên trang, bất kể nội dung D. Chỉ dùng được khi phần tử có thuộc tính data-testid

✅ Đáp án: A. getByRole tìm theo vai trò ARIA (button, textbox, link...) kết hợp accessible name, phản ánh đúng cách người dùng/trình đọc màn hình nhận diện phần tử.

Điều gì KHÔNG nên làm khi chọn locator cho một dự án automation nhiều ngôn ngữ (vi/en/ja)? A. Ưu tiên data-testid hoặc role không phụ thuộc ngôn ngữ hiển thị B. Dùng locator theo text cố định của 1 ngôn ngữ làm nguồn locator DUY NHẤT cho mọi môi trường C. Kết hợp getByTestId với filter khi cần thu hẹp phạm vi tìm kiếm D. Trao đổi với đội FE để thống nhất quy ước đặt data-testid

✅ Đáp án: B. Locator theo text sẽ vỡ ngay khi đổi ngôn ngữ hiển thị; nên ưu tiên thuộc tính không đổi theo ngôn ngữ như data-testid hoặc role kết hợp key ổn định.

Locator & Selector cho người mới: chọn phần tử bền vững (CSS, XPath, data-testid)

Bài cho người mới: học cách chọn locator selector bền vững qua app TMĐT ShopEasy — id, class, CSS, XPath, text, role, data-testid; vì sao selector giòn dễ vỡ; code Playwright getByRole/getByTestId/XPath chạy được; công cụ inspect; 2 tình huống thật, nhiều mockup, 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 & phần tử bạn sẽ chọn

⭐ TL;DR — Locator selector là cách xác định phần tử trên giao diện để Playwright thao tác đúng chỗ. Bài này bám màn đăng nhập ShopEasy: bạn học các loại locator (id, class, CSS, XPath, text, role, data-testid), vì sao selector giòn dễ vỡ khi UI đổi, cách viết locator Playwright thật (getByRole/getByTestId/CSS/XPath), và công cụ inspect để tìm phần tử. Có 2 tình huống thực tế, nhiều mockup và trắc nghiệm cuối bài.

Chào bạn mới! Khi mới học automation, bước đầu tiên và quan trọng nhất là dạy công cụ (như Playwright) cách 'tìm' đúng phần tử trên giao diện để thao tác — bước này gọi là chọn locator selector. Chọn sai sẽ khiến test chạy không ổn định: hôm nay chạy được, mai đổi 1 dòng CSS là gãy, dù tính năng thực tế vẫn hoạt động bình thường. Bài này dùng màn hình đăng nhập của app TMĐT ShopEasy làm ví dụ xuyên suốt: bạn sẽ học các loại locator phổ biến (id, class, CSS, XPath, text, role, data-testid), cách chọn loại bền vững nhất, viết locator thật bằng Playwright, và dùng công cụ inspect để tìm phần tử nhanh.

Màn hình đăng nhập ShopEasy, chú thích 4 loại locator khác nhau trên các phần tử

📖 Locator: cách xác định một phần tử cụ thể trên giao diện để công cụ automation (như Playwright) biết thao tác đúng lên phần tử đó — có thể dựng từ id, class, CSS, XPath, text, role hay data-testid.

2. Vấn đề: selector giòn khiến test dễ vỡ

Hãy tưởng tượng bạn viết locator cho nút 'Đăng nhập' trên ShopEasy bằng cách mở DevTools, thấy class hiển thị là '.css-a8f3k2', rồi copy nguyên chuỗi đó vào test. Cách này chạy đúng ngay lúc viết, vì tại thời điểm đó class thật sự tồn tại. Vấn đề là nhiều dự án hiện đại dùng công cụ CSS-in-JS hoặc bundler tự sinh tên class ngẫu nhiên mỗi lần build lại — dù bạn không sửa gì về giao diện hay nghiệp vụ.

Kết quả là sau một lần deploy bình thường, class đó đổi thành '.css-x92mtq', và locator cũ không còn tìm thấy phần tử nào nữa. Test báo lỗi đỏ dù tính năng đăng nhập trên thực tế vẫn hoạt động hoàn hảo — đây chính là 'báo động giả' (false alarm), một trong những lý do phổ biến nhất khiến đội ngũ dần mất niềm tin vào bộ test tự động. Bài học cốt lõi: locator giòn không chỉ tốn công sửa, mà còn làm giảm giá trị của cả automation.

📖 Selector giòn: selector dễ vỡ khi giao diện thay đổi dù chỉ một chút, ví dụ dựa vào class tự sinh, vị trí thứ tự phần tử, hay XPath tuyệt đối gắn cứng toàn bộ cây DOM.

3. Locator cơ bản: id, class, CSS selector

id là loại locator cơ bản và thường ổn định nhất trong nhóm locator kiểu cấu trúc, vì theo chuẩn HTML, id phải là DUY NHẤT trên toàn trang — ví dụ '#email-input' trên màn đăng nhập ShopEasy. Nếu đội dev đặt tay và giữ nguyên id này, đây là lựa chọn tốt. class CSS (ví dụ '.btn-primary') cũng dùng được, nhưng kém ổn định hơn vì một class có thể gắn cho nhiều phần tử, và dễ đổi khi đội thiết kế chỉnh style.

CSS selector phức hợp (ví dụ 'div.card > button:nth-child(2)') cho phép tìm phần tử dựa trên cấu trúc lồng nhau, hữu ích khi phần tử không có id/class riêng. Nhưng đây cũng là loại giòn nhất trong nhóm CSS, vì chỉ cần đội FE đổi thứ tự phần tử hay thêm 1 lớp bọc div, toàn bộ đường dẫn CSS có thể sai lệch. Nên xem CSS selector phức hợp là lựa chọn cuối cùng, không phải mặc định.

💡 Ưu tiên id/CSS selector dựa trên thuộc tính CỐ ĐỊNH do đội dev đặt tay (ví dụ #email-input), tránh id/class do công cụ build tự sinh chuỗi ngẫu nhiên.

4. Locator theo text & role (accessibility)

Locator theo text tìm phần tử dựa trên nội dung hiển thị, ví dụ page.getByText('Quên mật khẩu?') trên ShopEasy. Cách này trực quan, dễ đọc, và gần với cách người dùng thật nhìn vào trang. Tuy nhiên, nó có nhược điểm rõ ràng: nếu app hỗ trợ đa ngôn ngữ (vi/en/ja) và bạn chạy test trên bản dịch khác, text sẽ đổi và locator vỡ ngay lập tức.

Locator theo role dựa trên chuẩn accessibility (ARIA) — ví dụ 'button', 'textbox', 'link' — kết hợp với accessible name (tên mà trình đọc màn hình sẽ đọc lên). Cách này vừa bền hơn text thuần (không phụ thuộc CSS/DOM), vừa có lợi ích phụ: buộc bạn phải đảm bảo phần tử có accessibility đúng chuẩn, gián tiếp cải thiện chất lượng UI cho người dùng khuyết tật.

📖 role (accessibility): vai trò của phần tử theo chuẩn ARIA/accessibility (ví dụ button, textbox, link), giúp locator tìm phần tử theo đúng cách người dùng và trình đọc màn hình nhận diện, không phụ thuộc cấu trúc HTML bên dưới.

5. data-testid: locator dành riêng cho test

Trong số mọi loại locator, data-testid thường được xem là lựa chọn BỀN NHẤT cho automation, vì nó là thuộc tính HTML tuỳ chỉnh (ví dụ data-testid='btn-login') do chính đội phát triển chủ động thêm vào CHỈ để phục vụ kiểm thử — không liên quan gì tới style hiển thị hay logic nghiệp vụ. Khi đội FE đổi thư viện CSS, đổi cấu trúc DOM, hay thậm chí dịch lại toàn bộ text sang ngôn ngữ khác, data-testid vẫn giữ nguyên nếu không ai chủ đích xoá nó.

Bảng các loại locator phổ biến và độ bền tương ứng khi giao diện ShopEasy thay đổi

📖 data-testid: thuộc tính HTML tuỳ chỉnh do đội phát triển chủ động gắn thêm chỉ để phục vụ automation, không ảnh hưởng style hay logic hiển thị, nên gần như không đổi khi refactor giao diện.