Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười công ty phần mềm ở Việt Nam rằng đội QA của họ đang dùng tool nào để tự động hóa kiểm thử giao diện web, thì đến bảy, tám công ty sẽ trả lời: Selenium. Từ các ngân hàng lớn như VPBank, Techcombank cho tới các sàn thương mại điện tử như Tiki, Sendo, hay các công ty outsourcing như FPT Software, KMS Technology — Selenium xuất hiện gần như ở khắp nơi. Đây không phải ngẫu nhiên: Selenium là công cụ mã nguồn mở, miễn phí, hỗ trợ đa trình duyệt, đa ngôn ngữ lập trình, và quan trọng nhất — nó là chuẩn của W3C (World Wide Web Consortium).
Trong khóa học này, chúng ta đã đi qua chiến lược (khi nào nên automate, kim tự tháp kiểm thử). Bây giờ là lúc chạm tay vào công cụ cụ thể đầu tiên cho tầng UI. Bài học này là cửa ngõ — nếu bạn hiểu đúng bản chất Selenium WebDriver ngay từ đầu, các bài sau về Locators, Wait Strategies, hay Page Object Model sẽ trở nên nhẹ nhàng. Ngược lại, nếu bạn nhảy thẳng vào code mà không hiểu kiến trúc bên dưới, bạn sẽ liên tục gặp những lỗi khó hiểu và không biết vì sao.
Mục tiêu của bài này rất rõ ràng: hiểu Selenium WebDriver là gì, nó hoạt động ra sao ở tầng kiến trúc, phân biệt nó với các thành phần khác trong hệ sinh thái Selenium, và viết được đoạn script đầu tiên mở trình duyệt. Chúng ta chưa đi sâu vào cách tìm phần tử hay chờ đợi — đó là chuyện của các bài kế tiếp.
Khái niệm cốt lõi
Selenium WebDriver là gì?
Selenium WebDriver là một thư viện lập trình cho phép bạn điều khiển trình duyệt web một cách tự động, giống hệt như một người dùng thật đang thao tác: mở trang, gõ chữ vào ô tìm kiếm, nhấn nút, cuộn chuột, đọc nội dung hiển thị. Điểm mấu chốt là Selenium điều khiển trình duyệt thật (Chrome, Firefox, Edge, Safari) chứ không phải một trình duyệt giả lập. Nghĩa là những gì test của bạn "thấy" gần như chính xác với những gì người dùng cuối thấy.
Cần phân biệt rõ ba khái niệm thường bị nhầm lẫn trong hệ sinh thái Selenium:
- Selenium IDE: một extension ghi-và-phát lại (record-and-playback) trên trình duyệt, phù hợp cho người mới hoặc để làm demo nhanh, nhưng không đủ mạnh cho dự án thật.
- Selenium WebDriver: trái tim của Selenium — API lập trình để viết test bằng code. Đây là thứ bạn sẽ dùng 95% thời gian.
- Selenium Grid: hạ tầng để chạy test song song trên nhiều máy, nhiều trình duyệt cùng lúc (chúng ta sẽ chạm tới ở bài Parallel Test Execution).
Kiến trúc — điều khiến Selenium khác biệt
Đây là phần quan trọng nhất của bài. Hãy hình dung luồng giao tiếp như sau:
Test Script (Java/Python/C#/JS)
↓ gọi hàm API của WebDriver
WebDriver Client Library (ngôn ngữ của bạn)
↓ đóng gói thành request theo giao thức W3C WebDriver
↓ (HTTP/JSON gửi qua mạng nội bộ)
Browser Driver (ChromeDriver, GeckoDriver, EdgeDriver...)
↓ dịch lệnh sang lệnh điều khiển riêng của trình duyệt
Trình duyệt thật (Chrome, Firefox, Edge...)
↓
Trang web đang được kiểm thử
Hãy đọc kỹ luồng này. Khi bạn viết driver.get("https://tiki.vn"), chuyện xảy ra không hề đơn giản. Thư viện WebDriver trong code của bạn sẽ đóng gói lệnh đó thành một request HTTP theo giao thức chuẩn W3C WebDriver Protocol (định dạng JSON). Request này được gửi tới một chương trình trung gian gọi là browser driver — ví dụ ChromeDriver cho Chrome, GeckoDriver cho Firefox. Browser driver này mới là kẻ trực tiếp "nói chuyện" với trình duyệt bằng ngôn ngữ điều khiển riêng của từng hãng, ra lệnh cho trình duyệt mở trang.
Có ba hệ quả rất thực tế từ kiến trúc này mà bạn phải nhớ:
- Bạn luôn cần đúng browser driver cho đúng trình duyệt. Không có ChromeDriver thì không điều khiển được Chrome. Đây là nguồn gốc của lỗi kinh điển mà mọi người mới đều gặp (sẽ nói ở phần lỗi thường gặp).
- Phiên bản driver phải tương thích với phiên bản trình duyệt. ChromeDriver 120 thường không điều khiển được Chrome 138. Đây là "nỗi đau" muôn thuở của người dùng Selenium — may mắn là Selenium 4.6 trở lên đã có Selenium Manager tự động tải đúng driver, giúp giảm đáng kể vấn đề này.
- Giao tiếp là qua HTTP/JSON. Điều này giải thích vì sao Selenium có độ trễ nhất định giữa các lệnh, và vì sao nó chậm hơn các tool "chạy trong tiến trình trình duyệt" như Cypress (bài 12 sẽ so sánh).
W3C standard — vì sao điều đó quan trọng
Trước năm 2018, Selenium dùng một giao thức riêng gọi là JSON Wire Protocol. Từ Selenium 4, WebDriver đã trở thành chuẩn chính thức của W3C. Nghĩa là các nhà sản xuất trình duyệt (Google, Mozilla, Microsoft, Apple) đều cam kết hỗ trợ giao thức này một cách nhất quán. Với bạn — người viết test — điều này có nghĩa là code viết cho Chrome sẽ chạy được trên Firefox với thay đổi tối thiểu, và độ ổn định của việc điều khiển trình duyệt cao hơn nhiều so với trước.
Selenium hỗ trợ gì?
- Ngôn ngữ: Java, Python, C#, JavaScript, Ruby, Kotlin. Ở Việt Nam, Java và Python là hai lựa chọn phổ biến nhất trong tuyển dụng QA automation.
- Trình duyệt: Chrome, Firefox, Edge, Safari, và các trình duyệt nền tảng Chromium (như Cốc Cốc, về mặt kỹ thuật có thể điều khiển qua ChromeDriver phù hợp).
- Nền tảng: Windows, macOS, Linux.
Tình huống thực tế
Tình huống 1: Đội QA của một sàn TMĐT chuyển từ manual sang Selenium
Một công ty thương mại điện tử tầm trung ở TP.HCM (gọi là "ShopViet", khoảng 40 lập trình viên, 6 QA) mỗi lần release phải kiểm tra thủ công luồng đăng nhập, tìm kiếm sản phẩm, thêm giỏ hàng, thanh toán trên cả Chrome và Firefox. Mỗi vòng regression thủ công mất khoảng 2 ngày công cho 2 QA. Với lịch release 2 tuần một lần, mỗi tháng họ đốt gần 8 ngày công chỉ để click lại những thao tác giống hệt nhau.
Đội quyết định dùng Selenium WebDriver (Java) tự động hóa các luồng smoke test cốt lõi. Sau ba tuần xây dựng, bộ test 45 kịch bản chạy xong trong 11 phút trên Chrome, và họ cấu hình lại để chạy song song cả Firefox. Bài học rút ra: Selenium không thay thế hoàn toàn QA thủ công, nhưng nó lấy đi phần lặp đi lặp lại nhàm chán, để con người tập trung vào kiểm thử khám phá (exploratory) và trải nghiệm. Điểm mấu chốt khiến họ thành công là hiểu đúng kiến trúc — họ biết cần chuẩn bị ChromeDriver và GeckoDriver, và tại sao test đôi khi cần chờ trang tải.
Tình huống 2: Lỗi "SessionNotCreatedException" làm sập cả pipeline
Một bạn QA junior tại một startup fintech ở Hà Nội mới nhận việc, được giao maintain bộ Selenium test có sẵn. Sáng thứ Hai, toàn bộ 120 test trên CI đồng loạt đỏ với lỗi SessionNotCreatedException: This version of ChromeDriver only supports Chrome version 122. Bạn ấy hoảng vì code không hề thay đổi.
Nguyên nhân: máy CI vừa tự động cập nhật Chrome lên phiên bản 138 vào cuối tuần, trong khi ChromeDriver vẫn ghim ở 122. Vì kiến trúc Selenium tách rời client — driver — browser, chỉ cần một mắt xích lệch phiên bản là cả chuỗi đứt. Bài học rút ra: hiểu kiến trúc ba tầng giúp bạn chẩn đoán lỗi trong 5 phút thay vì mò mẫm cả buổi. Giải pháp lâu dài của họ là nâng lên Selenium 4.6+ để Selenium Manager tự quản lý driver, và ghim phiên bản Chrome trong Docker image của CI (chủ đề Docker cho Test Environments sẽ bàn kỹ ở bài 24).
Tình huống 3: Chọn Selenium hay tool khác cho một team outsourcing
Một team tại công ty outsourcing (giả định "TechBridge", làm dự án cho khách Nhật) phải quyết định dùng Selenium hay một tool mới hơn cho dự án kiểm thử web nội bộ của khách hàng. Khách hàng yêu cầu test phải chạy trên cả Chrome, Firefox, Edge và Safari vì người dùng cuối của họ trải rộng trên nhiều trình duyệt. Đội cũng có sẵn nhân sự mạnh về Java.
Họ chọn Selenium vì hai lý do: hỗ trợ Safari (điều mà nhiều tool hiện đại còn hạn chế) và tận dụng được kỹ năng Java sẵn có của team, cùng cộng đồng khổng lồ để tra cứu khi gặp vấn đề. Bài học rút ra: Selenium không phải luôn là lựa chọn tốt nhất về tốc độ hay trải nghiệm lập trình, nhưng nó thắng ở độ phủ trình duyệt, tính trưởng thành và hệ sinh thái. Việc chọn tool phải dựa trên yêu cầu thực tế của dự án, không phải theo trào lưu.
Hướng dẫn từng bước
Hãy cùng dựng môi trường và viết script Selenium đầu tiên. Ví dụ dùng Python vì cú pháp gọn, dễ đọc cho người mới — nhưng nguyên lý y hệt với Java hay C#.
Bước 1 — Chuẩn bị môi trường. Cài Python 3.8 trở lên, và cài thư viện Selenium:
pip install selenium
Bước 2 — Kiểm tra trình duyệt và driver. Với Selenium 4.6+, bạn không cần tự tải driver nữa — Selenium Manager sẽ tự động lo. Chỉ cần đảm bảo Chrome (hoặc Firefox) đã cài trên máy. Đây là một trong những cải tiến lớn nhất giúp người mới đỡ khổ.
Bước 3 — Viết script đầu tiên. Tạo file first_test.py:
from selenium import webdriver
from selenium.webdriver.common.by import ByKhởi tạo trình duyệt Chrome
driver = webdriver.Chrome()Mở một trang web
driver.get("https://www.google.com")In tiêu đề trang ra màn hình
print("Tiêu đề trang:", driver.title)Đóng trình duyệt
driver.quit()
Bước 4 — Chạy script:
python first_test.py
Nếu mọi thứ đúng, bạn sẽ thấy Chrome tự mở, vào Google, rồi tự đóng, và terminal in ra Tiêu đề trang: Google. Xin chúc mừng — bạn vừa điều khiển được trình duyệt bằng code.
Bước 5 — Hiểu từng dòng. webdriver.Chrome() tạo một phiên (session) mới và khởi động ChromeDriver phía sau. driver.get(url) gửi lệnh điều hướng. driver.title đọc tiêu đề trang thật đang hiển thị. driver.quit() đóng trình duyệt và kết thúc tiến trình driver — rất quan trọng để không để lại process rác.
Bước 6 — Thử đổi trình duyệt. Đổi webdriver.Chrome() thành webdriver.Firefox() và chạy lại. Nếu Firefox đã cài, script chạy y hệt. Đây chính là sức mạnh của chuẩn W3C — cùng một API, nhiều trình duyệt.
Lưu ý: ở bài này chúng ta chưa tương tác với phần tử (nhập chữ, click). Cách tìm phần tử bằng ID, CSS, XPath là chủ đề riêng của bài 7 (Locators), và cách chờ phần tử xuất hiện đúng lúc là bài 8 (Wait Strategies). Hãy để chúng cho các bài đó.
Lỗi thường gặp & mẹo
Lỗi 1 — "WebDriverException: chromedriver executable needs to be in PATH". Đây là lỗi kinh điển với người dùng Selenium phiên bản cũ, khi phải tự tải driver và khai báo đường dẫn. Mẹo: nâng lên Selenium 4.6 trở lên để Selenium Manager tự lo, và bỏ hẳn thói quen tải driver thủ công.
Lỗi 2 — Lệch phiên bản driver và trình duyệt (như tình huống 2). Mẹo: dùng Selenium Manager, hoặc ghim phiên bản Chrome cố định trong môi trường CI bằng Docker để tránh trình duyệt tự cập nhật gây vỡ test.
Lỗi 3 — Quên driver.quit(). Nếu script lỗi giữa chừng và không đóng driver, các tiến trình Chrome và ChromeDriver sẽ tồn đọng, ăn RAM và có thể khiến máy CI treo sau vài chục lần chạy. Mẹo: luôn đặt driver.quit() trong khối finally hoặc dùng cơ chế teardown của framework test.
Lỗi 4 — Nhầm lẫn Selenium IDE với WebDriver. Nhiều bạn mới xem video record-and-playback rồi tưởng đó là "làm automation chuyên nghiệp". Mẹo: hãy đầu tư học WebDriver bằng code ngay từ đầu — đó mới là kỹ năng nhà tuyển dụng cần.
Lỗi 5 — Kỳ vọng Selenium test được backend hay API. Selenium chỉ điều khiển giao diện trình duyệt. Kiểm thử API là chuyện của Postman, REST Assured hay requests (các bài 1, 15, 16). Dùng đúng công cụ cho đúng việc.
Mẹo về hiệu năng: Selenium chậm hơn kiểm thử ở tầng thấp vì phải giao tiếp HTTP với trình duyệt thật. Vì thế, theo tinh thần kim tự tháp kiểm thử ở bài 5, đừng lạm dụng Selenium cho mọi thứ — chỉ dùng nó cho những luồng end-to-end thật sự cần kiểm chứng trên giao diện.
Bài tập thực hành
- Dựng môi trường: Cài Python và thư viện
selenium. Viết lại script ở phần hướng dẫn, chạy thành công, chụp lại kết quả in ra terminal.
- Điều hướng nhiều trang: Sửa script để mở lần lượt
https://tiki.vnrồihttps://shopee.vn, mỗi trang in radriver.titlevàdriver.current_url. Quan sát độ trễ giữa các lệnh — đó chính là biểu hiện của giao tiếp HTTP trong kiến trúc.
- Đổi trình duyệt: Chạy cùng script trên cả Chrome và Firefox. Ghi lại xem có gì khác biệt về tốc độ khởi động và kết quả không.
- Cố tình tạo lỗi để hiểu kiến trúc: Tắt mạng internet rồi chạy script mở một trang web. Đọc kỹ thông báo lỗi và tự lý giải: lỗi này phát sinh ở tầng nào trong luồng client → driver → browser → web?
- Viết mô tả kiến trúc: Bằng lời của chính bạn, vẽ lại sơ đồ 4 tầng của Selenium và giải thích chuyện gì xảy ra khi gọi
driver.get(). Nếu giải thích trôi chảy cho một đồng nghiệp không chuyên hiểu được, bạn đã nắm vững bài này.
Tóm tắt
Selenium WebDriver là công cụ mã nguồn mở phổ biến nhất cho tự động hóa kiểm thử giao diện web, và là chuẩn chính thức của W3C. Điều cốt lõi bạn phải mang theo sau bài này là kiến trúc bốn tầng: test script của bạn gọi thư viện WebDriver, thư viện đóng gói lệnh thành request HTTP/JSON theo giao thức W3C, gửi tới browser driver (ChromeDriver, GeckoDriver...), và driver mới trực tiếp điều khiển trình duyệt thật. Hiểu luồng này giúp bạn chẩn đoán phần lớn lỗi thường gặp — đặc biệt là lỗi lệch phiên bản driver và trình duyệt.
Bạn cũng đã phân biệt được Selenium IDE, WebDriver và Grid; biết Selenium hỗ trợ đa ngôn ngữ, đa trình duyệt, đa nền tảng; và tự tay viết được script đầu tiên mở trình duyệt bằng code. Từ Selenium 4.6, Selenium Manager tự động quản lý driver, gỡ bỏ một trong những rào cản lớn nhất với người mới.
Đây mới là bước khởi đầu. Bài tiếp theo, chúng ta sẽ học cách tìm phần tử trên trang bằng ID, Name, CSS Selector và XPath — kỹ năng nền tảng để bắt đầu tương tác thật sự với trang web. Hẹn gặp lại bạn ở bài về Locators.