Bối cảnh và vấn đề nghiên cứu

Trong quy trình sản xuất và phát triển phần mềm hiện đại, số lượng ứng dụng và trang web được phát hành ngày càng gia tăng nhằm đáp ứng nhu cầu tự động hóa và đơn giản hóa các hoạt động đời sống, kinh doanh. Tuy nhiên, mức độ phức tạp của các hệ thống web kéo theo nguy cơ tiềm ẩn nhiều lỗi phần mềm nghiêm trọng, có thể dẫn đến những thiệt hại lớn nếu không được phát hiện và xử lý kịp thời. Hoạt động kiểm thử phần mềm đóng vai trò bắt buộc nhằm xác định lỗi, đảm bảo sản phẩm vận hành đúng và đủ so với yêu cầu đặc tả ban đầu.

Thực tế tại các dự án phần mềm cho thấy, việc kiểm thử các hệ thống lớn với hàng trăm hoặc hàng ngàn trường hợp kiểm thử (test cases) nếu chỉ phụ thuộc hoàn toàn vào kiểm thử thủ công (Manual Testing) sẽ tiêu tốn rất nhiều thời gian, chi phí và nguồn nhân lực. Bên cạnh đó, các dự án thường có sự tái sử dụng các module tính năng tương đồng giữa các phiên bản hoặc cần cập nhật, bổ sung, loại bỏ tính năng theo yêu cầu thay đổi của khách hàng. Khi đó, kiểm thử tự động (Automation Testing) trở thành giải pháp cấp thiết nhằm hỗ trợ kiểm thử hồi quy, rút ngắn chu kỳ phản hồi kết quả và tối ưu hóa chi phí vận hành cho doanh nghiệp.

Theo số liệu từ báo cáo của Hội nghị quốc tế về kiểm thử phần mềm và kiểm thử tự động được tác giả trích dẫn, tỷ lệ phân bổ giữa lập trình viên và kiểm thử viên trên thế giới là 3:1, trong khi tại Việt Nam tỷ lệ này hiện ở mức 5:1, cho thấy lĩnh vực kiểm thử phần mềm trong nước vẫn đang đi sau và đối mặt với sự thiếu hụt về nguồn lực chuyên trách. Từ bối cảnh thực tiễn đó, đề tài "Ứng dụng công cụ kiểm thử tự động Selenium bằng ngôn ngữ lập trình Java cho ứng dụng web thương mại điện tử" được thực hiện.

Mục tiêu nghiên cứu của đề tài được xác định cụ thể như sau:

  1. Mục tiêu chung: Ứng dụng thành công công cụ kiểm thử tự động Selenium bằng ngôn ngữ Java cho ứng dụng web thương mại điện tử.
  2. Mục tiêu cụ thể:
    • Xây dựng được các kịch bản kiểm thử (test suites).
    • Thiết lập bản báo cáo kiểm thử (Test Report).
    • Ghi nhận và tạo bằng chứng cho các trường hợp kiểm thử thất bại (Failed test cases).
    • Xây dựng framework WebDriver theo mô hình hướng đối tượng trang (Page Object Model - POM).

Đối tượng và phạm vi nghiên cứu:

  • Đối tượng nghiên cứu: Ngôn ngữ lập trình Java, công cụ kiểm thử tự động Selenium, ứng dụng web thương mại điện tử Swag Labs.
  • Phạm vi không gian: Đề tài được thực hiện trong quá trình thực tập tại Công ty cổ phần Phần mềm Quốc tế 3S Huế.
  • Phạm vi thời gian: Nghiên cứu và thực nghiệm từ ngày 02/10/2023 đến ngày 07/01/2024.

Cơ sở lý thuyết và phương pháp

Khóa luận thiết lập nền tảng nghiên cứu dựa trên các lý thuyết tiêu chuẩn về công nghệ phần mềm và quy trình đảm bảo chất lượng:

  • Vòng đời kiểm thử phần mềm (STLC): Gồm 6 giai đoạn chuẩn từ phân tích yêu cầu (Requirement Analysis), lập kế hoạch (Test Planning), thiết kế kịch bản (Test Case Design & Development), thiết lập môi trường (Test Environment Setup), thực thi kiểm thử (Test Execution) đến đóng chu trình kiểm thử (Test Cycle Closure).
  • Các cấp độ kiểm thử phần mềm: Kiểm thử đơn vị (Unit Testing), kiểm thử tích hợp (Integration Testing - với các cách tiếp cận BigBang, Top-Down, Bottom-Up, Sandwich/Hybrid), kiểm thử hệ thống (System Testing) và kiểm thử chấp nhận (Acceptance Testing).
  • Kỹ thuật kiểm thử: Tập trung vào kỹ thuật kiểm thử hộp đen (Black Box Testing) thông qua các phương pháp phân vùng tương đương (Equivalence Partitioning), phân tích giá trị biên (Boundary Value Analysis) và bảng quyết định (Decision Table); đối chiếu với kỹ thuật kiểm thử hộp trắng (White Box Testing).
  • Khung lý thuyết kiểm thử ứng dụng web: Bao quát 6 phương diện gồm kiểm thử chức năng (Functionality Testing: liên kết, biểu mẫu, cookies, cơ sở dữ liệu, cú pháp HTML/CSS), kiểm thử khả năng sử dụng (Usability Testing: điều hướng, nội dung), kiểm thử giao diện (UI Testing), kiểm thử độ tương thích (Compatibility Testing: trình duyệt, hệ điều hành), kiểm thử hiệu suất (Performance Testing) và kiểm thử bảo mật (Security Testing).
  • Kiến trúc tự động hóa: Mô hình hướng đối tượng trang (Page Object Model - POM) và thư viện Selenium WebDriver kết hợp trình quản lý dự án Apache Maven.

Phương pháp nghiên cứu thực tế được tác giả triển khai bao gồm:

  • Phương pháp nghiên cứu tài liệu: Thu thập, tổng hợp các tài liệu kỹ thuật về ngôn ngữ lập trình Java, framework Selenium, công cụ Maven và các tiêu chuẩn kiểm thử phần mềm.
  • Phương pháp quan sát, tổng hợp: Khảo sát cấu trúc thực tế và các luồng nghiệp vụ trên trang web Swag Labs, bao gồm các cụm chức năng: Đăng nhập/Đăng xuất, Quản lý giỏ hàng (thêm/xóa sản phẩm), Quản lý đặt hàng (nhập/hủy thông tin đơn hàng) và Sắp xếp sản phẩm.
  • Phương pháp phân tích và thiết kế kỹ thuật: Thiết kế kiến trúc framework WebDriver theo mô hình POM nhằm phân tách mã nguồn kiểm thử; thiết kế chi tiết bộ kịch bản kiểm thử, cơ chế xuất báo cáo kết quả tự động và mẫu báo cáo lỗi (Bug Report).

Nguồn dữ liệu:

  • Dữ liệu thực nghiệm thu thập trực tiếp từ giao diện, mã nguồn HTML/CSS và luồng tương tác trên ứng dụng web thương mại điện tử Swag Labs.
  • Dữ liệu cấu hình môi trường lập trình và các thư viện điều khiển trình duyệt của Selenium.

Thiết kế và triển khai

Là một đề tài xây dựng và thực thi giải pháp kỹ thuật kiểm thử phần mềm, khóa luận triển khai hệ thống kiểm thử tự động với các thành phần công nghệ và cấu trúc sau:

1. Môi trường và công nghệ sử dụng

  • Ngôn ngữ lập trình: Java.
  • Công cụ tự động hóa cốt lõi: Selenium WebDriver (sử dụng thư viện lập trình để tương tác với trình duyệt).
  • Công cụ quản lý dự án: Apache Maven, phục vụ việc quản lý cấu hình và các gói phụ thuộc (dependencies).
  • Thiết lập môi trường hệ thống: Cấu hình biến môi trường hệ điều hành bao gồm biến JAVA_HOME trỏ tới thư mục cài đặt Java JDK và cập nhật đường dẫn bin vào biến hệ thống Path; cấu hình biến môi trường cho Apache Maven trỏ tới thư mục bin tương ứng.

2. Kiến trúc mô hình Page Object Model (POM)

Tác giả áp dụng mẫu thiết kế POM để phân tách mã nguồn kiểm thử thành hai tầng độc lập:

  • Tầng đối tượng trang (Page Classes): Khai báo và lưu trữ các định danh phần tử giao diện (Web Elements: nút bấm, ô nhập liệu, nhãn hiển thị) cùng các phương thức hành động đại diện cho nghiệp vụ của từng trang cụ thể.
  • Tầng kịch bản kiểm thử (Test Scripts): Chứa các ca kiểm thử kế thừa và gọi các phương thức từ tầng đối tượng trang để thực thi xác minh kết quả. Cấu trúc này giúp giảm thiểu việc trùng lặp mã lệnh, tăng tính module hóa và dễ dàng cập nhật khi giao diện ứng dụng web thay đổi.

3. Hiện thực hóa các hàm xử lý tương tác

Hệ thống xây dựng các hàm điều khiển cốt lõi:

  • Các hàm tiện ích tương tác cơ bản: Hàm thực hiện nhấn vào phần tử giao diện (click) và hàm trích xuất chuỗi ký tự hiển thị (get text) để phục vụ việc so sánh với kết quả mong đợi.
  • Các hàm nghiệp vụ giỏ hàng và sản phẩm: Xây dựng các phương thức chuyên biệt bao gồm addProBackpack() (thêm ba lô vào giỏ hàng), addProBikeLight() (thêm đèn xe đạp vào giỏ hàng), removeProBackpack() (xóa sản phẩm ba lô khỏi giỏ hàng) và getShoppingCart() (truy xuất thông tin hiển thị của giỏ hàng).

4. Quy trình ghi nhận kết quả và xử lý lỗi

  • Cơ chế chụp ảnh tự động: Khi một trường hợp kiểm thử gặp lỗi hoặc thất bại (Failed), hệ thống tự động ghi lại ảnh chụp màn hình (screenshot) tại thời điểm xảy ra sự cố để làm bằng chứng kiểm thử (Attachment trong Bug Report).
  • Báo cáo kiểm thử tự động: Xuất bảng tổng hợp trực quan về số lượng ca kiểm thử thành công (Pass), ca kiểm thử thất bại (Fail) và chi tiết thông điệp lỗi.

Nội dung chính theo từng chương

Chương 1: Cơ sở lý thuyết về kiểm thử phần mềm

Chương này cung cấp hệ thống lý luận nền tảng về hoạt động đảm bảo chất lượng phần mềm:

  • Khái niệm, vai trò và mục đích: Xác định kiểm thử phần mềm là hoạt động tìm kiếm khiếm khuyết nhằm đảm bảo phần mềm vận hành chính xác theo yêu cầu khách hàng, giúp giảm thiểu rủi ro và tiết kiệm chi phí sửa chữa khi phát hiện lỗi sớm.
  • Quy trình kiểm thử phần mềm (STLC): Phân tích chi tiết đầu vào, hoạt động và đầu ra của 6 giai đoạn:
    1. Xác định yêu cầu (Requirement Analysis): Phân tích tài liệu đặc tả, làm rõ yêu cầu chức năng/phi chức năng; đầu ra là tài liệu giải đáp nghiệp vụ.
    2. Lập kế hoạch kiểm thử (Test Planning): Xác định phạm vi, thời gian, nguồn lực nhân sự/thiết bị, tiêu chuẩn chấp nhận; đầu ra là kế hoạch kiểm thử và ước lượng thời gian.
    3. Thiết kế kịch bản kiểm thử (Test Case Design & Development): Xây dựng test cases, dữ liệu kiểm thử, xác định độ ưu tiên; đầu ra là bộ kịch bản kiểm thử hoàn chỉnh.
    4. Thiết lập môi trường kiểm thử (Test Environment Setup): Chuẩn bị máy chủ, mạng, thực hiện smoke test kiểm tra tính sẵn sàng của môi trường.
    5. Thực hiện kiểm thử (Test Execution): Chạy kịch bản kiểm thử, so sánh kết quả thực tế với kết quả mong đợi, tái kiểm thử (re-test); đầu ra là báo cáo lỗi và kết quả thực thi.
    6. Đóng chu trình kiểm thử (Test Cycle Closure): Đánh giá tiêu chí hoàn thành, tổng kết bài học kinh nghiệm và lập báo cáo kết quả dự án.
  • Các cấp độ kiểm thử: Phân định ranh giới giữa Unit Testing (do lập trình viên thực hiện), Integration Testing (kiểm tra giao tiếp giữa các module theo 4 cách tiếp cận), System Testing (đánh giá toàn diện hệ thống tích hợp) và Acceptance Testing (người dùng/khách hàng nghiệm thu).
  • Kỹ thuật kiểm thử và cấu trúc Bug Report: Làm rõ ưu nhược điểm của kiểm thử hộp đen và kiểm thử hộp trắng. Đưa ra cấu trúc chuẩn của một báo cáo lỗi gồm 10 trường dữ liệu: Project, Bug ID, Title, Status, Environment, Description, Step to reproduce, Actual results, Expected results, Severity, Attachment.

Chương 2: Tổng quan về kiểm thử ứng dụng web

Chương 2 đi sâu vào đặc thù của ứng dụng chạy trên nền tảng web và tự động hóa kiểm thử:

  • Kỹ thuật kiểm thử ứng dụng web: Trình bày chi tiết cách thức thực hiện kiểm tra chức năng (liên kết, cookies, form nhập liệu, HTML/CSS, database), kiểm tra tính khả dụng (điều hướng, bố cục nội dung), kiểm tra giao diện (màu sắc, phông chữ máy chủ ứng dụng/web), kiểm tra tương thích đa trình duyệt/hệ điều hành, kiểm tra hiệu suất và kiểm tra an ninh bảo mật.
  • Quy trình kiểm thử tự động 5 bước: Lựa chọn công cụ (Test tool selection) -> Xác định phạm vi (Define scope) -> Lập kế hoạch, thiết kế và phát triển (Planning, Design, Development) -> Thực thi kiểm thử (Test Execution) -> Bảo trì (Maintenance).
  • Khảo sát các công cụ phổ biến: Giới thiệu các giải pháp kiểm thử như Appium (cho ứng dụng di động iOS/Android), Katalon Studio, Robot Framework (Python, tiếp cận hướng từ khóa/dữ liệu), TestComplete (công cụ thương mại có phí sau 30 ngày dùng thử) và Postman (chuyên kiểm thử tự động API trong CI/CD).
  • So sánh kiểm thử tự động và kiểm thử thủ công: Chương này đưa ra bảng so sánh chi tiết giữa hai phương thức tiếp cận dựa trên 14 tiêu chí kỹ thuật và kinh tế.
Tiêu chí Kiểm thử tự động Kiểm thử thủ công
Định nghĩa Sử dụng các công cụ để thực hiện kiểm thử bộ kịch bản kiểm thử Kiểm thử viên kiểm thử trực tiếp trên các ứng dụng phần mềm
Thời gian xử lý Nhanh hơn (tiết kiệm hơn 80% thời gian khi thực thi test case) Tùy thuộc vào tester và trường hợp kiểm thử
Kiểm thử ngẫu nhiên Không cho phép Có thể kiểm thử ngẫu nhiên (Ad-hoc)
Đầu tư ban đầu Số vốn ban đầu khá cao, hiệu quả về mặt lâu dài Số vốn thấp, không dùng lâu dài, phải liên tục cập nhật
Độ tin cậy Đáng tin cậy, thực thi chính xác bởi công cụ và mã code Không có độ chính xác tuyệt đối, dễ mắc lỗi con người
Yêu cầu đầu tư Tập trung chủ yếu vào công cụ và kỹ thuật Đầu tư mạnh vào số lượng nguồn nhân lực
Hiệu quả chi phí Không hiệu quả nếu kiểm thử hồi quy với quy mô nhỏ Ghi nhận đơn giản trên Word/Excel, phù hợp dự án ngắn
Báo cáo kiểm thử Tự động xuất, các bên liên quan đăng nhập xem trực tiếp Thường được ghi lại thủ công trên Excel hoặc Word
Giao diện người dùng Không có tương tác người dùng, không đánh giá được trải nghiệm Cho phép quan sát thực tế, đánh giá tính thân thiện UI
Kiểm thử hiệu suất Bắt buộc sử dụng công cụ (Load, Stress, Spike Testing) Không khả thi để thực hiện bằng sức người
Chạy hàng loạt Chạy hàng loạt script, có thể lên lịch thực thi ban đêm Không thể thực hiện chạy hàng loạt tự động
Kiến thức lập trình Yêu cầu bắt buộc đối với nhân sự Không đòi hỏi bắt buộc
Tiếp cận lý tưởng Phù hợp khi bộ test case cần chạy lặp lại thường xuyên Hữu ích khi test case chỉ chạy 1-2 lần
Kiểm thử xác minh build (BVT) Rất hữu ích và tối ưu cho BVT Tốn nhiều thời gian và gặp nhiều khó khăn
Rủi ro tiến độ (Deadlines) Không có rủi ro trễ tiến độ do máy móc thực thi Rủi ro cao do phụ thuộc sức người và thời gian hạn hẹp
Framework áp dụng Dùng Data-Driven, Keyword-Driven, Hybrid Framework Dùng guidelines, checklists, quy trình nghiêm ngặt
Phạm vi áp dụng Regression Testing, Performance, lặp lại nhiều lần Exploratory Testing, Usability Testing, ứng dụng đổi liên tục
  • Đánh giá ưu nhược điểm: Tác giả nhấn mạnh kiểm thử tự động có ưu thế vượt trội về độ chính xác, tốc độ và khả năng tái sử dụng kịch bản, nhưng nhược điểm là chi phí đầu tư ban đầu cao, đòi hỏi nhân sự có kỹ năng lập trình và không thể thay thế con người trong việc đánh giá trực quan cảm xúc người dùng.

Chương 3: Xây dựng công cụ kiểm thử tự động Selenium cho ứng dụng web Swag Labs

Nội dung chương 3 trình bày toàn bộ quá trình hiện thực hóa giải pháp:

  • Phân tích thành phần Selenium: Trình bày vai trò của 4 thành phần trong hệ sinh thái Selenium gồm Selenium IDE (record/playback kịch bản), Selenium Grid (chạy kiểm thử phân tán song song trên nhiều trình duyệt/máy tính), Selenium RC (thư viện cũ) và Selenium WebDriver (giao diện lập trình trực tiếp với trình duyệt, khắc phục nhược điểm của RC).
  • Mô tả bài toán nghiệp vụ trên Swag Labs: Xác định các chức năng trọng tâm cần tự động hóa:
    • Chức năng Đăng nhập/Đăng xuất: Xây dựng phương pháp kiểm thử đối chiếu bằng cách sử dụng tài khoản chuẩn (standard_user) làm mốc tham chiếu hành vi đúng, sau đó chạy kịch bản đăng nhập với các tài khoản chứa lỗi mô phỏng (problem_user) để phát hiện sai lệch chức năng.
    • Chức năng Quản lý giỏ hàng: Kiểm thử các thao tác thêm sản phẩm vào giỏ, xóa sản phẩm khỏi giỏ, kiểm tra thông tin số lượng, tiêu đề và hình ảnh hiển thị của sản phẩm.
    • Chức năng Quản lý sản phẩm: Kiểm thử danh mục và sắp xếp sản phẩm.
    • Chức năng Quản lý đặt hàng: Kiểm thử quy trình điền thông tin khách hàng, xác nhận đơn và hủy đơn hàng.
  • Xây dựng 4 bộ kịch bản kiểm thử chi tiết:
    • Bảng 3-1: Bộ kịch bản kiểm thử Đăng nhập (kiểm tra trường hợp hợp lệ, để trống tài khoản, sai mật khẩu, tài khoản bị khóa).
    • Bảng 3-2: Bộ kịch bản kiểm thử Quản lý sản phẩm (hiển thị danh sách, kiểm tra bộ lọc sắp xếp giá và tên).
    • Bảng 3-3: Bộ kịch bản kiểm thử Quản lý giỏ hàng (thêm/xóa sản phẩm từ trang chủ và từ trang chi tiết).
    • Bảng 3-4: Bộ kịch bản kiểm thử Quản lý đặt hàng (quy trình checkout, xác thực dữ liệu đầu vào First Name, Last Name, Postal Code).
  • Kết quả thực thi: Chạy tự động các test suites, hiển thị kết quả kiểm thử đạt (Pass), phân tích các trường hợp thất bại (Fail) khi chạy trên tài khoản lỗi, trích xuất hình ảnh chụp màn hình làm bằng chứng và tổng hợp bản báo cáo kiểm thử.

Kết quả và đóng góp

Khóa luận đã hoàn thành các mục tiêu nghiên cứu với các kết quả cụ thể được ghi nhận trong văn bản:

  • Xây dựng thành công framework kiểm thử tự động: Hoàn thiện khung làm việc Selenium WebDriver bằng ngôn ngữ lập trình Java dựa trên mô hình thiết kế Page Object Model (POM), đảm bảo tính module hóa và dễ bảo trì.
  • Phát triển 4 bộ kịch bản kiểm thử chức năng: Thiết kế và lập trình hoàn chỉnh các bộ test cases bao phủ 4 phân hệ chính của trang web thương mại điện tử Swag Labs: Đăng nhập/Đăng xuất (Bảng 3-1), Quản lý sản phẩm (Bảng 3-2), Quản lý giỏ hàng (Bảng 3-3) và Quản lý đặt hàng (Bảng 3-4).
  • Cơ chế thu thập bằng chứng lỗi tự động: Xây dựng cơ chế chụp ảnh màn hình tự động cho các ca kiểm thử thất bại (Fail), giúp kiểm thử viên nhanh chóng xác định nguyên nhân lỗi mà không cần chạy lại kịch bản bằng tay.
  • Tự động hóa báo cáo kiểm thử: Thiết lập hệ thống tạo báo cáo kiểm thử (Test Report) tổng hợp số lượng ca thành công, thất bại và chi tiết nhật ký lỗi.

Đóng góp về mặt giải pháp và phương pháp:

  • Đề xuất quy trình thiết kế kiểm thử đối chiếu: Sử dụng tài khoản chuẩn (standard_user) làm cơ sở đối chiếu hành vi giao diện với các tài khoản có lỗi (problem_user), giúp phát hiện các khiếm khuyết hiển thị hình ảnh và tính năng một cách tự động.
  • Giá trị đóng góp thực tiễn: Khóa luận cung cấp một mô hình ứng dụng kiểm thử tự động hoàn chỉnh từ khâu cấu hình công cụ (JDK, Maven, Selenium), thiết kế mã nguồn theo chuẩn POM cho đến xuất báo cáo, giải quyết bài toán tiết kiệm thời gian (hơn 80% so với kiểm thử thủ công khi chạy lặp lại) và nhân lực tại đơn vị thực tập (Công ty cổ phần Phần mềm Quốc tế 3S Huế).

Hạn chế và hướng nghiên cứu tiếp

Khóa luận nêu rõ các hạn chế kỹ thuật của công cụ và phạm vi thực nghiệm:

  • Hạn chế của công cụ Selenium:
    • Chỉ hỗ trợ kiểm thử cho các ứng dụng chạy trên nền tảng web, không hỗ trợ ứng dụng máy tính (Desktop) hoặc kiểm thử chuyên sâu cho ứng dụng di động độc lập.
    • Khả năng kiểm tra và xác thực hình ảnh (visual testing) còn hạn chế so với tương tác phần tử văn bản và mã HTML.
    • Đòi hỏi cấu hình môi trường ban đầu phức tạp hơn so với các công cụ thương mại (như UFT, Silk Test).
    • Yêu cầu đường truyền mạng ổn định trong suốt quá trình chạy kiểm thử; có nguy cơ gây quá tải bộ nhớ RAM nếu việc quản lý khởi tạo và giải phóng trình duyệt không được tối ưu hóa.
  • Hạn chế về phạm vi đề tài: Các kịch bản kiểm thử mới chỉ tập trung vào các luồng chức năng chính trên trang web mẫu Swag Labs trong khoảng thời gian thực tập có hạn.

Hướng nghiên cứu tiếp được tác giả định hướng:

  • Mở rộng phạm vi kịch bản kiểm thử tự động sang các luồng nghiệp vụ phức tạp hơn của các hệ thống thương mại điện tử thực tế.
  • Khai thác thành phần Selenium Grid để thực thi song song các bộ kịch bản kiểm thử trên nhiều hệ điều hành và nhiều trình duyệt web khác nhau (Chrome, Firefox, Safari, Edge) nhằm kiểm tra khả năng tương thích toàn diện.
  • Tối ưu hóa hiệu năng kịch bản kiểm thử và nghiên cứu tích hợp quy trình kiểm thử tự động vào đường ống tích hợp liên tục/triển khai liên tục (CI/CD).

Giá trị tham khảo

Báo cáo khóa luận là tài liệu học thuật và thực hành phù hợp cho các nhóm đối tượng sau:

  • Sinh viên các ngành Hệ thống thông tin quản lý, Công nghệ thông tin, Kỹ thuật phần mềm: Tài liệu cung cấp hướng dẫn rõ ràng về cách thiết lập môi trường phát triển (cấu hình biến hệ thống cho JDK và Maven qua Advanced System Settings) và cấu trúc dự án kiểm thử theo mô hình Page Object Model (POM).
  • Kiểm thử viên (Tester/QA) bắt đầu chuyển từ kiểm thử thủ công sang kiểm thử tự động: Bảng so sánh 14 tiêu chí kỹ thuật tại Chương 2 (Bảng 2.1) cung cấp cái nhìn tổng quan và chuẩn xác để lựa chọn phương pháp kiểm thử phù hợp cho từng giai đoạn dự án.
  • Các nhà nghiên cứu và kỹ sư phần mềm quan tâm đến tự động hóa web: Các phần thiết kế kịch bản cho module giỏ hàng và thanh toán là mẫu tham khảo hữu ích cho việc xây dựng bộ kịch bản kiểm thử hồi quy cho các website thương mại điện tử.

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

1. Khóa luận này lựa chọn ứng dụng web nào làm đối tượng thử nghiệm và tập trung vào các chức năng gì?

Khóa luận sử dụng ứng dụng web thương mại điện tử Swag Labs làm đối tượng thử nghiệm. Các chức năng chính được lựa chọn để xây dựng kịch bản kiểm thử tự động bao gồm: Đăng nhập/Đăng xuất, Quản lý sản phẩm (hiển thị danh mục, sắp xếp), Quản lý giỏ hàng (thêm/xóa sản phẩm) và Quản lý đặt hàng (nhập thông tin người nhận, tính toán đơn giá, hủy/xác nhận đơn hàng).

2. Framework kiểm thử tự động trong đề tài được xây dựng dựa trên kiến trúc nào và sử dụng công cụ gì?

Framework được xây dựng theo mô hình hướng đối tượng trang (Page Object Model - POM) bằng ngôn ngữ lập trình Java, sử dụng thư viện tự động hóa Selenium WebDriver và công cụ quản lý dự án Apache Maven. Mô hình POM giúp phân tách riêng biệt giữa kho lưu trữ đối tượng giao diện (Page Classes) và mã kịch bản kiểm tra (Test Cases).

3. Tác giả sử dụng phương pháp nào để phát hiện lỗi chức năng trên trang web Swag Labs?

Tác giả áp dụng phương pháp kiểm thử đối chiếu: Sử dụng tài khoản chuẩn (standard_user) làm hệ quy chiếu hành vi đúng, sau đó lập trình kịch bản tự động đăng nhập vào tài khoản lỗi mô phỏng (problem_user). Bằng cách so sánh kết quả thực tế giữa hai tài khoản, hệ thống sẽ tự động chỉ ra các tính năng hoạt động sai lệch và chụp ảnh màn hình lỗi.

4. Quy trình kiểm thử tự động được đề tài chuẩn hóa theo các bước nào?

Theo Chương 2, quy trình kiểm thử tự động gồm 5 bước tuần tự:

  1. Chọn công cụ hỗ trợ kiểm thử (Test tool selection).
  2. Xác định phạm vi kiểm thử tự động (Define the scope of Automation).
  3. Lập kế hoạch, thiết kế và phát triển kịch bản (Planning, Design, and Development).
  4. Thực thi kiểm thử (Test Execution).
  5. Bảo trì kịch bản kiểm thử (Maintenance).

5. Cấu trúc một bản báo cáo lỗi (Bug Report) được tác giả quy định gồm những thông tin nào?

Một Bug Report chuẩn trong khóa luận bao gồm 10 trường dữ liệu: Project (Tên dự án), Bug ID (Mã lỗi), Title (Mô tả ngắn gọn về Bug), Status (Trạng thái), Environment (Môi trường test), Description (Miêu tả chi tiết), Step to reproduce (Các bước tái hiện lỗi), Actual results (Kết quả thực tế), Expected results (Kết quả mong đợi), Severity (Mức độ nghiêm trọng) và Attachment (Đính kèm bằng chứng ảnh/tệp/URL).

Kết luận

Khóa luận tốt nghiệp của tác giả Trần Khánh Thư đã hệ thống hóa toàn diện cơ sở lý luận về quy trình kiểm thử phần mềm, đồng thời triển khai thành công framework kiểm thử tự động Selenium WebDriver trên nền tảng ngôn ngữ Java theo mô hình Page Object Model (POM). Thông qua việc áp dụng thực nghiệm trên ứng dụng web thương mại điện tử Swag Labs, đề tài đã xây dựng được 4 bộ kịch bản kiểm thử hoàn chỉnh, thiết lập cơ chế tự động ghi nhận bằng chứng lỗi và xuất báo cáo kiểm thử trực quan. Công trình mang tính ứng dụng kỹ thuật rõ nét, cung cấp tài liệu tham khảo thực tế cho sinh viên ngành Hệ thống thông tin quản lý và các kiểm thử viên phần mềm trong việc tối ưu hóa quy trình kiểm định chất lượng web.