Kiểm thử tự động bằng Selenium: khi nào nên và khi nào không

Kiểm thử tự động bằng Selenium điều khiển trình duyệt thật để bấm và nhập như người dùng, nên nó kiểm tra được thứ kiểm thử API không thấy. Đổi lại, đây là loại kiểm thử đắt và dễ hỏng nhất, nên chỉ nên dùng cho vài luồng thật ổn định.

Tóm tắt nhanh

• Selenium kiểm tra được luồng người dùng thật, nhưng chỉ nên dùng cho vài luồng quan trọng.
• Ba chi phí riêng: bộ chọn giao diện, ma trận môi trường và thời gian chờ.
• Luồng càng đổi giao diện thường xuyên càng ít đáng tự động hoá bằng trình duyệt.
• Bộ chọn theo vị trí là nguyên nhân hỏng phổ biến nhất; bộ chọn theo vai trò ổn định hơn.
• Phần lớn kiểm tra nên nằm ở tầng API hoặc tầng đơn vị, không ở trình duyệt.

Selenium làm được gì và không làm được gì

Selenium mở trình duyệt, tìm phần tử, bấm, nhập và đọc kết quả. Vì chạy trên trình duyệt thật, nó bắt được lỗi mà kiểm thử API bỏ qua: nút bị che, biểu mẫu không gửi, thông báo lỗi không hiện, luồng chuyển trang sai.

Nó không đánh giá được thẩm mỹ, tốc độ cảm nhận hay mức dễ hiểu. Nó cũng không thay được kiểm thử thủ công cho các tình huống hiếm. Điều nó làm tốt nhất là lặp lại một luồng đã biết, trên nhiều trình duyệt, với cùng dữ liệu.

Giới hạn quan trọng nhất là tính ổn định của giao diện. Mỗi lần đổi bố cục, đổi nhãn hoặc đổi thư viện giao diện, bộ chọn có thể hỏng dù nghiệp vụ không đổi. Vì vậy câu hỏi không phải "có nên dùng Selenium" mà là "luồng nào đủ ổn định để dùng".

Ba chi phí riêng của kiểm thử giao diện

Ba chi phí này cộng lại thường lớn hơn chi phí viết kiểm thử ban đầu. Vì vậy khi ước lượng, đừng chỉ tính thời gian viết lần đầu; hãy tính thời gian sửa trong một năm.

Một chi phí thứ tư ít được gọi tên là thời gian đọc kết quả. Một bộ kiểm thử trình duyệt chạy 40 phút và đỏ ở ba chỗ khiến người trực phải mở trình duyệt xem lại, chụp màn hình và so sánh. Nếu việc này lặp lại mỗi tuần, chi phí đọc kết quả có thể vượt chi phí chạy tay.

Bảng quyết định: bốn tình huống

Bảng này tránh được sai lầm phổ biến là tự động hoá mọi thứ vì "đã có công cụ". Một luồng còn đang đổi mỗi tuần sẽ khiến bộ kiểm thử hỏng liên tục, và đội sẽ bỏ chạy nó. Chờ hai đến ba tuần cho giao diện ổn định thường rẻ hơn.

Ví dụ một bộ chọn không ổn định và cách sửa

Giả sử kiểm thử tìm nút "Thanh toán" bằng cách lấy phần tử thứ ba trong một danh sách. Cách này đúng hôm nay và sai ngay khi ai đó thêm một nút phía trước.

Nguyên tắc chung: chọn phần tử theo thứ người dùng nhận biết, không theo thứ mã nguồn sắp xếp. Một thuộc tính dành riêng cho kiểm thử, đặt trên phần tử quan trọng, rẻ hơn nhiều so với việc sửa bộ chọn mỗi tháng.

Ma trận môi trường: bao nhiêu tổ hợp là đủ

Mỗi tổ hợp trình duyệt và kích thước màn hình là một lần chạy. Nếu có bốn trình duyệt và ba kích thước, bạn có mười hai tổ hợp, và thời gian chạy tăng gấp mười hai.

Cách chọn hợp lý là dựa trên dữ liệu người dùng thật, không dựa trên danh sách trình duyệt phổ biến. Chọn một tổ hợp cho phần lớn người dùng, một tổ hợp cho nhóm còn lại, và một kích thước nhỏ để bắt lỗi bố cục. Ba đến bốn tổ hợp thường đủ cho một sản phẩm nội bộ.

Với sản phẩm có người dùng ở nhiều thiết bị, nên tách bộ kiểm thử theo mức ưu tiên: bộ nhanh chạy mọi lần phát hành, bộ đầy đủ chạy theo lịch. Chạy toàn bộ ma trận cho mọi thay đổi nhỏ là cách nhanh nhất để đội bỏ qua kết quả.

Một bước đệm trước khi dùng Selenium

Trước khi mở trình duyệt, hãy kiểm tra xem lỗi có thể bắt ở tầng thấp hơn không. Ba câu hỏi sau thường loại được phần lớn trường hợp không cần Selenium.

Lỗi nằm ở dữ liệu hay ở giao diện? Nếu dữ liệu sai, kiểm thử API sẽ bắt được và chạy nhanh hơn nhiều lần. Chỉ khi dữ liệu đúng mà màn hình vẫn sai mới cần đến trình duyệt.

Lỗi có tái hiện bằng một thành phần riêng không? Nếu chỉ một ô nhập hoặc một bảng bị sai, kiểm thử thành phần đủ và rẻ hơn.

Luồng có đi qua nhiều trang và nhiều bước xác thực không? Đây là trường hợp Selenium có giá trị nhất, vì chỉ trình duyệt mới mô phỏng được chuỗi bước đó.

Nếu cả ba câu trả lời đều nghiêng về tầng thấp hơn, hãy viết kiểm thử ở tầng thấp và giữ Selenium cho luồng quan trọng nhất.

Khi nào nên dùng công cụ khác

Nếu mục tiêu là kiểm tra dữ liệu vào ra, kiểm thử API rẻ hơn, nhanh hơn và ổn định hơn. Nếu mục tiêu là kiểm tra một thành phần giao diện riêng lẻ, kiểm thử thành phần nhanh hơn trình duyệt đầy đủ. Nếu mục tiêu là kiểm tra tải, cần công cụ đo tải chứ không phải Selenium.

Selenium đáng dùng khi cần chứng minh một luồng nghiệp vụ chạy được từ đầu đến cuối trên trình duyệt thật, đặc biệt khi luồng đi qua nhiều trang và nhiều bước xác thực. Với các trường hợp còn lại, hãy chọn công cụ rẻ hơn.

Nếu bạn cần một chiến lược kiểm thử phân tầng cho hệ thống đang vận hành, WinSell xây dựng phần mềm theo yêu cầu theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.

Câu hỏi thường gặp

Selenium có còn phù hợp cho dự án mới không?

Còn, nếu dự án cần kiểm thử trên trình duyệt thật và đội đã quen công cụ. Điều cần cân nhắc là chi phí bảo trì, không phải tuổi của công cụ. Nếu phần lớn kiểm tra có thể làm ở tầng API, hãy đặt phần lớn ở đó và dùng Selenium cho vài luồng quan trọng.

Nên viết bao nhiêu kiểm thử Selenium?

Nên giới hạn theo số luồng nghiệp vụ quan trọng, thường từ ba đến mười luồng với sản phẩm nội bộ. Con số này không nên tăng theo số màn hình, vì mỗi màn hình thêm vào là thêm chi phí bảo trì mà không thêm nhiều giá trị.

Làm sao giảm thời gian chờ trong kiểm thử?

Chờ theo điều kiện thay vì chờ theo số giây cố định, và tách dữ liệu kiểm thử để không phụ thuộc trạng thái hệ thống. Nếu một bước phải chờ lâu, hãy kiểm tra xem nguyên nhân là mạng, dữ liệu hay giao diện; tăng thời gian chờ chỉ che vấn đề.

Kiểm thử Selenium có cần chạy trên máy của từng người không?

Không. Nên chạy trên một môi trường cố định để kết quả so sánh được. Chạy trên máy từng người sẽ cho kết quả khác nhau do phiên bản trình duyệt và dữ liệu, và đội sẽ mất thời gian tranh luận về môi trường thay vì sửa lỗi.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026. Nội dung được rà soát theo thực tiễn kiểm thử trình duyệt trong đội phát triển phần mềm. Bài viết mang tính tham khảo; lựa chọn công cụ phụ thuộc loại sản phẩm và năng lực của đội.

Bài viết liên quan: ứng dụng AI trong kiểm thử phần mềm, chi phí sử dụng AI agent, AI coding là gì và kiến trúc phần mềm là gì.