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

Khóa luận tốt nghiệp "Xây dựng bộ khung phục vụ việc kiểm thử web tự động" (tên tiếng Anh: Building a Framework for Automated Web Application Penetration Testing) do sinh viên Trần Thanh Tài thực hiện dưới sự hướng dẫn của TS. Nguyễn Tấn Cầm tại Khoa Mạng máy tính và Truyền thông, Trường Đại học Công nghệ Thông tin – Đại học Quốc gia TP. Hồ Chí Minh (năm 2023), thuộc chương trình đào tạo Kỹ sư ngành An toàn thông tin.

Về bối cảnh thực tiễn, tác giả nhận định sự phát triển của công nghệ và Internet đã khiến các ứng dụng web trở thành hạ tầng thiết yếu trong đời sống, từ các dịch vụ tiêu dùng hàng ngày đến các hệ thống công nghệ cao. Sau giai đoạn bùng nổ nhu cầu sử dụng Internet do tác động của đại dịch Covid-19, nguy cơ mất an toàn thông tin gia tăng khi các đối tượng tấn công mạng liên tục tìm kiếm và khai thác các lỗ hổng ứng dụng web. Song song với đó, quy trình kiểm thử phần mềm (KTPM) thủ công truyền thống bộc lộ nhược điểm lớn về chi phí, nguồn nhân lực và thời gian thực thi, đặc biệt là sự đội chi phí mỗi khi ứng dụng có bản cập nhật mới. Do đó, việc nghiên cứu và xây dựng một bộ khung (framework) hỗ trợ tự động hóa kiểm thử chức năng và quét an ninh ứng dụng web là yêu cầu thực tế cấp thiết.

Theo văn bản khóa luận, mục tiêu nghiên cứu được xác định cụ thể gồm 4 nhiệm vụ:

  1. Xây dựng bộ khung có khả năng kiểm thử web một cách tự động.
  2. Xây dựng được bộ report chi tiết cho kết quả của từng module.
  3. Thực hiện mô hình Page Object Model (POM) để quản lý bộ khung kiểm thử.
  4. Đánh giá hiệu quả, mức độ chính xác và tốc độ phản ứng của hệ thống kiểm thử web tự động.

Phạm vi nghiên cứu của đề tài bao gồm 3 nội dung trọng tâm:

  1. Cách thức kiểm thử web tự động.
  2. Kỹ thuật scan lỗ hổng web.
  3. Kỹ thuật bất đồng bộ trong JavaScript.

Đối tượng nghiên cứu của khóa luận được phân thành 3 nhóm hệ thống:

  • Các website thương mại điện tử, bán hàng trực tuyến.
  • Các website thuộc lĩnh vực đặt vé du lịch.
  • Các website và dịch vụ mạng hỗ trợ tra cứu thông tin nguồn (OSINT) của các trang web khác.

Về phương pháp thực hiện, tác giả tiến hành:

  • Thu thập, tìm hiểu và tổng hợp tài liệu chuyên ngành cùng các tài liệu hướng dẫn kỹ thuật liên quan.
  • Tham khảo các video mô tả, tài liệu giải thích kỹ thuật và các phương pháp triển khai công cụ hỗ trợ kiểm thử.
  • Thiết kế hệ thống và tiến hành các cuộc thử nghiệm thực tế để đo lường, đánh giá hiệu năng và độ chuẩn xác của framework.

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

Khóa luận tiếp cận cơ sở lý thuyết kiểm thử từ định nghĩa nền tảng của Glen Myers: kiểm thử là quá trình thực thi một chương trình với mục đích phát hiện ra lỗi. Nghiên cứu hệ thống hóa các khái niệm, quy trình và kỹ thuật kiểm thử phần mềm tiêu chuẩn:

  • Vòng đời và quy trình kiểm thử: Thiết kế loạt trường hợp thử nghiệm (test cases) theo kế hoạch chi tiết nhằm tối đa hóa xác suất phát hiện lỗi.
  • Kiểm thử hộp trắng (White-Box Testing - WBT, hay Glass-Box Testing, Clear-Box Testing): Kiểm tra cấu trúc lệnh nội bộ, đường dẫn logic và các điều kiện thực thi của mã nguồn.
  • Kiểm thử hộp đen (Black-Box Testing - BBT): Tập trung kiểm tra tính đúng đắn của chức năng dựa trên dữ liệu đầu vào và kết quả đầu ra mà không xem xét mã nguồn bên trong; tập trung vào lỗi giao diện, cấu trúc dữ liệu bên ngoài, lỗi khởi tạo hoặc kết thúc chương trình.
  • Kiểm thử hộp xám (Gray-Box Testing): Kết hợp giữa việc kiểm tra cấu trúc mã nguồn bên ngoài (cấu trúc HTML tagname) và kiểm tra chức năng giao diện theo luồng tương tác thực tế.
  • Mô hình kiểm tra ứng dụng web: Xem xét ứng dụng web trên kiến trúc máy khách - máy chủ (Client - Server) 3 lớp: lớp dịch vụ người dùng, lớp xử lý dịch vụ và lớp dữ liệu dịch vụ; qua đó xác định các hạng mục kiểm thử gồm: giao diện người dùng, chức năng web, kiểm tra phía máy chủ, cơ sở dữ liệu, khả năng bảo mật và hiệu năng.

Các công cụ và khung công nghệ chính được tác giả lựa chọn để xây dựng hệ thống gồm:

  • WebdriverIO: Khung tự động hóa kiểm thử mã nguồn mở cho Node.js, hiện thực hóa đặc tả API W3C WebDriver của Selenium. WebdriverIO được chọn do tốc độ phản hồi nhanh, tính ổn định cao, tương thích mạnh với JavaScript ở phía front-end, hỗ trợ các mô hình kiểm thử hướng hành vi (BDD) và hướng phát triển theo kiểm thử (TDD), đồng thời tương thích với các framework kiểm thử như Jasmine, Mocha, Cucumber và hỗ trợ nhiều trình duyệt (Chrome, Edge, Firefox, Safari, PhantomJS).
  • Allure Report: Công cụ tạo báo cáo kiểm thử trực quan, đa ngôn ngữ, cung cấp biểu đồ thống kê kết quả kiểm thử, tỷ lệ thành công/thất bại và chụp ảnh màn hình các bước gặp lỗi.
  • Mô hình Page Object Model (POM): Mẫu thiết kế phần mềm giúp tách biệt cấu trúc mã kịch bản kiểm thử và các thành phần giao diện (elements) của từng trang, tối ưu hóa khả năng kế thừa và tái sử dụng mã nguồn.
Công nghệ / Công cụ Vai trò trong hệ thống
Node.js & JavaScript Môi trường thực thi và ngôn ngữ lập trình chính cho framework
WebdriverIO Điều khiển trình duyệt, tương tác tự động với DOM ứng dụng web
Mocha Framework tổ chức và thực thi kịch bản kiểm thử (test runner)
Allure Report Tạo báo cáo tổng quan, trực quan hóa trạng thái và lỗi của kịch bản kiểm thử
Live Server & VS Code Môi trường phát triển và kiểm tra hiển thị báo cáo kiểm thử dạng HTML

Thiết kế và triển khai

Hệ thống được thiết kế theo cấu trúc module hóa với các khối chức năng độc lập nhằm tiếp nhận dữ liệu đầu vào (URL trang web mục tiêu), thực hiện thu thập dữ liệu kỹ thuật, rà quét lỗ hổng và kiểm thử chức năng tự động.

1. Môi trường triển khai

Môi trường thực nghiệm của hệ thống được thiết lập trên máy tính cá nhân chạy hệ điều hành Windows kết hợp hệ thống máy ảo Linux, với cấu hình kỹ thuật cụ thể:

  • Bộ nhớ RAM: 8 GB.
  • Bộ nhớ lưu trữ: 80 GB SSD.
  • Nền tảng ứng dụng: Visual Studio Code, Trình duyệt Google Chrome, WebdriverIO, Allure Report, Live Server, Node.js, Mocha.

Cấu trúc thư mục dự án được tổ chức khoa học nhằm quản lý tách biệt giữa mã nguồn thu thập metadata, kịch bản kiểm thử và hệ thống báo cáo:

  • allure-report & AllureReport: Chứa khuôn mẫu và cấu hình sinh báo cáo tự động của Allure.
  • node_modules: Các gói thư viện phụ thuộc và thiết lập lõi của WebdriverIO.
  • test/black box: Chứa các module tương tác lấy thông tin trang theo mô hình kiểm thử hộp đen.
  • test/page object: Chứa các lớp cơ sở (page base, common) quản lý các phần tử (element) và hàm dùng chung.
  • test/spec: Phân tách thành hai thư mục con gồm test white box và test black box để quản lý các tệp kịch bản kiểm thử.
  • test/testReport: Chứa bản ghi tạm thời và công cụ xuất báo cáo kiểm thử.
  • test/whiteBox: Chứa mã nguồn tương tác phục vụ mô hình kiểm thử hộp xám.
  • test/toolScan: Chứa các script tích hợp các công cụ quét lỗ hổng ứng dụng web.
  • Các tệp cấu hình: wdio.conf.js (thiết lập trình duyệt Chrome, log, reporter), package.json, package-lock.json, jsconfig.json.

2. Kiến trúc các module chính

Hệ thống bao gồm 4 module nghiệp vụ chính:

Module Metadata Collector

Chức năng chính là thu thập thông tin hạ tầng, mạng và cấu hình bảo mật liên quan đến tên miền mục tiêu. Module nhận đầu vào là URL, vận hành trên Node.js thông qua WebdriverIO để truy xuất tự động đến các dịch vụ tra cứu OSINT trực tuyến. Nhằm đảm bảo hệ thống không bị gián đoạn khi một dịch vụ tra cứu gặp sự cố, tác giả thiết lập cơ chế chịu lỗi: nếu một trang lấy thông tin bị hỏng hoặc nghẽn mạng, chương trình sẽ thử tải lại tối đa 3 lần trong vòng 10 giây; nếu vẫn thất bại, hệ thống sẽ ghi nhận trạng thái lỗi và tự động chuyển sang trang kế tiếp.

Dịch vụ tra cứu OSINT Đường dẫn truy xuất tuyệt đối / Phương thức Dữ liệu trích xuất
Whois.com whois.com/whois/<domain> Tên miền, ID đăng ký, ngày cập nhật, ngày hết hạn, nhà đăng ký, thông tin liên hệ, máy chủ DNS
AbuseIPDB abuseipdb.com/check/<ip> ISP, Usage Type, Hostname, Quốc gia, Thành phố, mức độ cảnh báo độc hại
crt.sh crt.sh/?q=<domain> Danh sách chứng chỉ SSL/TLS, ID chứng chỉ, ngày phát hành/hết hạn, Matching Identities, thuật toán khóa (RSA 2048-bit)
DNSlytics dnslytics.com/ip/<ip> Xếp hạng Alexa, nhà cung cấp hạ tầng máy chủ, địa chỉ IPv4, DNS server đầu tiên, máy chủ thư tín (MX) ưu tiên cao nhất
GreyNoise viz.greynoise.io/ip/<ip> Bản chất lưu lượng IP, mức độ tin cậy (Trust Level), danh mục dịch vụ (như Social Media)
IPalyzer ipalyzer.com/ Tra cứu GeoIP, vị trí địa lý, trạng thái danh sách đen (Spamhaus, Barracuda, SpamCop, Blocklist.de), trạng thái cổng/dịch vụ (HTTPS, SMTP, RDP, SSH)
BGPView bgpview.io/ip/<ip> Số hiệu mạng ASN, Tiền tố BGP (Prefix), Tên tổ chức sở hữu, Định tuyến Upstream/Downstream
Security Headers securityheaders.com/ Các tiêu đề bảo mật HTTP (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Permissions-Policy, Cache-Control)
SecurityTrails securitytrails.com/domain/<domain> Bản ghi DNS toàn diện: A, AAAA, MX, NS, SOA, CNAME, TXT
Shodan shodan.io/search Thiết bị mạng, các cổng dịch vụ đang mở (Top Ports: 80, 8080, 8443, 8081...), tổ chức hạ tầng

Module Vulnerability Checker

Module tiếp nhận URL và các dữ liệu trích xuất từ Metadata Collector, sau đó kích hoạt các công cụ rà quét bảo mật chuyên biệt (như Vulpro, Rapid, Pyfiscan...) để phát hiện các lỗ hổng bảo mật phổ biến thuộc danh mục OWASP.

Module Automation Test (Gray-Box Testing)

Module kiểm thử tự động được phân chia thành hai tầng kiểm tra:

  • Test Common (Kiểm tra cấu trúc chung): Thực hiện tự động kiểm tra cấu trúc mã nguồn HTML để xác định sự tồn tại của các thẻ (tagname) thiết yếu như div, footer, form, header, meta, section, table. Quy trình tìm kiếm thẻ được thiết lập với chu kỳ thăm dò mỗi 500 mili-giây một lần; nếu sau 5 giây vẫn không tìm thấy thẻ, trường hợp thử nghiệm sẽ được đánh dấu thất bại (false). Toàn bộ quá trình quét thẻ chỉ mất dưới 5 giây đối với trang web có đầy đủ cấu trúc.
  • Test Private (Kiểm thử chức năng chuyên biệt): Áp dụng cho các trang web được phân tích và viết kịch bản riêng theo mô hình Page Object Model. Tác giả áp dụng cơ chế tối ưu hóa tài nguyên bằng cách thực thi Test Private trên chính phiên làm việc (browser instance) của trình duyệt vừa hoàn thành Test Common, giúp giảm thiểu thời gian khởi tạo (setup) và dọn dẹp (teardown) môi trường.

Hệ thống Report và Synthesis Processing

Dữ liệu từ ba module (Metadata Collector, Automation Test, Vulnerability Checker) được dẫn truyền về khối xử lý trung tâm (Synthesis and processing) để chuẩn hóa định dạng, sau đó lưu trữ tại final report dưới định dạng HTML và xuất báo cáo Allure Report chi tiết. Framework áp dụng nguyên tắc vận hành tuần tự, không chạy song song các tác vụ nhằm tránh quá tải bộ nhớ và triệt tiêu xung đột phiên làm việc (xung đột API, trạng thái đăng nhập/đăng xuất).

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

Chương 1: Giới thiệu tổng quan

Chương 1 xác định lý do chọn đề tài xuất phát từ nhu cầu bảo đảm an ninh mạng và giảm thiểu chi phí kiểm thử thủ công trong bối cảnh các ứng dụng web phát triển nhanh chóng. Tác giả thiết lập hệ thống 4 mục tiêu nghiên cứu cụ thể, xác định phạm vi nghiên cứu về kỹ thuật kiểm thử tự động, quét lỗ hổng và cơ chế bất đồng bộ trong JavaScript, đồng thời phân nhóm các đối tượng nghiên cứu thực nghiệm.

Chương 2: Kiến thức nền tảng

Chương này tập trung trình bày hệ thống lý thuyết về kiểm thử phần mềm, so sánh chi tiết phương pháp kiểm thử hộp trắng và kiểm thử hộp đen. Tác giả phân tích mô hình kiến trúc ứng dụng web 3 lớp và các tiêu chuẩn kiểm thử tương ứng. Đồng thời, chương 2 giới thiệu chi tiết về công cụ WebdriverIO (các ưu điểm về hiệu năng, các framework hỗ trợ như Jasmine, Mocha, Cucumber) và công cụ Allure Report cùng các tính năng phân tích xu hướng kiểm thử trực quan.

Chương 3: Phân tích thiết kế hệ thống

Chương 3 trình bày kiến trúc tổng thể của bộ khung kiểm thử tự động với 4 module: Metadata Collector, Vulnerability Checker, Automation Test và Final Report. Tác giả chi tiết hóa cơ chế hoạt động của từng module, thiết lập lưu đồ luồng dữ liệu, quy định cơ chế thử lại (retry) khi mạng gặp sự cố đối với Metadata Collector, phân tách kiểm thử hộp xám thành Test Common và Test Private, đồng thời đưa ra kiến trúc tổng hợp báo cáo.

Chương 4: Triển khai, thực nghiệm và đánh giá

Chương 4 mô tả cấu hình môi trường thực thi và cấu trúc thư mục mã nguồn của dự án. Nội dung cốt lõi của chương là kết quả thực nghiệm chi tiết:

  • Thực nghiệm trích xuất metadata thành công trên các mục tiêu thực tế gồm tên miền facebook.com và uit.vn, hiển thị đầy đủ dữ liệu từ Whois, AbuseIPDB, crt.sh, DNSlytics, GreyNoise, IPalyzer, BGPView, Security Headers, SecurityTrails và Shodan.
  • Triển khai kịch bản Automation Test trên website thương mại điện tử thử nghiệm saucedemo.com (Saurce) và practice.automationtesting. Kịch bản kiểm thử bao gồm: kiểm tra thẻ HTML (Test Common), kiểm tra trang đăng nhập với tài khoản hợp lệ (standard_user / mật khẩu secret_sauce), kiểm tra trang danh mục sản phẩm Home Page (hiển thị sản phẩm, bộ lọc sắp xếp, giá tiền, chức năng thêm vào giỏ hàng), kiểm tra trang giỏ hàng (Cart page) và quy trình thanh toán (Check out).

Chương 5: Kết luận và hướng phát triển

Chương 5 tổng kết mức độ hoàn thành so với các mục tiêu đề ra ban đầu, đánh giá khả năng vận hành của bộ khung và nêu rõ các hạn chế tồn tại cùng các hướng nâng cấp trong tương lai.

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

Về kết quả thực nghiệm, khóa luận đã xây dựng thành công bộ khung kiểm thử tự động tích hợp, đạt được các kết quả cụ thể có số liệu ghi nhận trong văn bản:

  • Thu thập siêu dữ liệu hoàn chỉnh: Hệ thống trích xuất chính xác các thông số kỹ thuật mạng phức tạp. Điển hình đối với mục tiêu uit.vn và facebook.com, hệ thống thu thập được thông tin ASN (ví dụ AS45903 của CMC Telecom, AS10403 của FPT Telecom), dải IP, vị trí địa lý, trạng thái kiểm tra trên 4 tổ chức giám sát danh sách đen (Barracuda, Blocklist.de, SpamCop, Spamhaus), các tiêu đề HTTP bảo mật (X-Frame-Options, X-Content-Type-Options) và thống kê mở cổng dịch vụ từ Shodan (ghi nhận 24.619 kết quả liên quan với các cổng chính: cổng 80 có 5.818 bản ghi, cổng 8080 có 286 bản ghi, cổng 8443 có 179 bản ghi).
  • Tự động hóa kiểm thử cấu trúc và chức năng: Kịch bản Test Common hoàn thành việc kiểm tra các thẻ HTML cơ bản trong thời gian dưới 5 giây. Kịch bản Test Private mô phỏng thành công luồng nghiệp vụ mua sắm trực tuyến khép kín trên saucedemo.com, bao gồm đăng nhập hệ thống, duyệt danh mục, tương tác giỏ hàng và nhập dữ liệu hóa đơn giao hàng.
  • Hệ thống báo cáo đa dạng: Kết quả thử nghiệm được kết xuất tự động dưới dạng báo cáo HTML tổng hợp và hệ thống báo cáo đồ họa trực quan Allure Report, ghi nhận chi tiết trạng thái pass/fail và hình ảnh chụp màn hình tương ứng.

Về mặt đóng góp, nghiên cứu đã đề xuất một giải pháp kết hợp giữa kiểm thử chức năng giao diện người dùng (E2E testing) và thu thập thông tin an ninh mạng/rà quét lỗ hổng trong một quy trình thống nhất. Việc ứng dụng mô hình Page Object Model giúp mã nguồn có tính module hóa cao, dễ bảo trì và mở rộng khi cấu trúc trang web thay đổi.

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

Khóa luận chỉ ra một số hạn chế kỹ thuật cụ thể trong quá trình thiết kế và triển khai:

  • Chế độ thực thi: Hệ thống chưa áp dụng cơ chế chạy song song (parallel execution) mà vận hành hoàn toàn tuần tự. Mặc dù việc chạy song song giúp rút ngắn thời gian, nhưng tác giả quyết định chọn chạy tuần tự để giảm tải tài nguyên phần cứng cho máy thử nghiệm, đồng thời phòng tránh các lỗi xung đột phiên làm việc như xung đột gọi API, trạng thái login/logout.
  • Tương thích môi trường duyệt web: Bộ khung hiện tại mới chỉ được cấu hình, triển khai và đánh giá thực nghiệm trên trình duyệt Google Chrome, chưa kích hoạt thử nghiệm đồng bộ trên các trình duyệt khác mà WebdriverIO hỗ trợ (như Edge, Firefox, Safari).
  • Tính phụ thuộc của Test Private: Kịch bản kiểm thử chuyên sâu (Test Private) vẫn phụ thuộc vào việc phân tích và viết mã kịch bản thủ công từ lập trình viên cho từng giao diện web riêng biệt.
  • Phụ thuộc dịch vụ bên thứ ba: Hiệu năng của module Metadata Collector phụ thuộc chặt chẽ vào độ ổn định đường truyền Internet và tính khả dụng của các API/dịch vụ OSINT công cộng.

Hướng phát triển tiếp theo được định hướng:

  • Tối ưu hóa hiệu năng để hỗ trợ chạy thử nghiệm song song có kiểm soát.
  • Mở rộng phạm vi tương thích trên nhiều trình duyệt web khác nhau.
  • Bổ sung và tích hợp thêm các bộ công cụ rà quét lỗ hổng chuyên sâu bám sát các tiêu chuẩn cập nhật của OWASP.

Giá trị tham khảo

Báo cáo khóa luận là tài liệu tham khảo kỹ thuật hữu ích đối với:

  • Sinh viên chuyên ngành An toàn thông tin, Mạng máy tính và Công nghệ phần mềm đang tìm kiếm mô hình kết hợp giữa kiểm thử phần mềm tự động (Automation Testing) và đánh giá an ninh web (Web Penetration Testing).
  • Các kỹ sư kiểm thử (QA/QC Engineer) hoặc chuyên viên kiểm thử bảo mật (Security Tester) quan tâm đến việc áp dụng WebdriverIO kết hợp mô hình Page Object Model (POM) và Allure Report trên môi trường Node.js.
  • Phần đáng tham khảo nhất của công trình là chương 3 và chương 4, đặc biệt là phương pháp tích hợp tự động các nguồn dữ liệu OSINT (Whois, crt.sh, BGPView, GreyNoise, Security Headers...) vào quy trình đánh giá bước đầu của ứng dụng web, cùng với giải pháp thiết kế module kiểm tra cấu trúc DOM (Test Common) độc lập với kịch bản chức năng (Test Private).

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

1. Bộ khung kiểm thử trong khóa luận sử dụng công nghệ cốt lõi nào để tự động hóa tương tác web và xuất báo cáo?
Framework được xây dựng dựa trên nền tảng Node.js, sử dụng WebdriverIO (triển khai API W3C WebDriver của Selenium) kết hợp framework kiểm thử Mocha để thực thi tương tác tự động với trình duyệt Google Chrome. Hệ thống sử dụng Allure Report để tạo báo cáo kiểm thử trực quan và kết xuất báo cáo tổng hợp dưới dạng tệp HTML.

2. Module Metadata Collector tích hợp những nguồn dữ liệu trực tuyến nào để thu thập thông tin web mục tiêu?
Module tích hợp tự động 10 dịch vụ tra cứu mạng và an ninh trực tuyến, gồm: Whois.com (thông tin đăng ký tên miền), AbuseIPDB (danh tiếng IP), crt.sh (chứng chỉ số), DNSlytics (thông tin DNS và xếp hạng), GreyNoise (phân tích lưu lượng IP), IPalyzer (vị trí GeoIP và blacklist), BGPView (định tuyến BGP và ASN), Security Headers (tiêu đề an ninh HTTP), SecurityTrails (bản ghi DNS chi tiết) và Shodan (cổng mở và dịch vụ mạng).

3. Cơ chế xử lý của hệ thống khi một website trong module Metadata Collector gặp sự cố là gì?
Khi một trang web cung cấp dữ liệu gặp sự cố không tải được, chương trình sẽ tự động tải lại trang đó tối đa 3 lần trong khoảng thời gian 10 giây. Nếu sau thời gian này vẫn không có phản hồi, hệ thống sẽ ghi nhận lỗi/thất bại và tự động chuyển sang trang lấy thông tin kế tiếp mà không làm gián đoạn toàn bộ quy trình kiểm thử.

4. Module Automation Test phân chia kiểm thử hộp xám thành các phần nào và hoạt động ra sao?
Module được chia thành hai phần: Test Common và Test Private. Test Common thực hiện kiểm tra tự động xem trang web có đầy đủ các thẻ HTML cơ bản (div, footer, form, header, meta, section, table) hay không, với cơ chế thăm dò mỗi 500ms trong tối đa 5 giây. Test Private được viết riêng cho từng website mục tiêu theo mô hình POM để kiểm tra giao diện và luồng nghiệp vụ chức năng (như đăng nhập, lọc sản phẩm, giỏ hàng, thanh toán), chạy nối tiếp trên chính phiên trình duyệt của Test Common.

5. Vì sao tác giả lựa chọn phương án thực thi kiểm thử tuần tự thay vì chạy song song?
Mặc dù cơ chế chạy song song giúp rút ngắn tổng thời gian kiểm thử, tác giả chọn phương án chạy tuần tự nhằm tránh gây quá tải bộ nhớ và tài nguyên cho máy thực nghiệm, đồng thời ngăn ngừa triệt để các xung đột trạng thái không mong muốn trong quá trình kiểm thử như xung đột lệnh gọi API, phiên đăng nhập (login) và đăng xuất (logout).

Kết luận

Khóa luận tốt nghiệp của sinh viên Trần Thanh Tài đã giải quyết trọn vẹn mục tiêu thiết kế và hiện thực hóa bộ khung kiểm thử ứng dụng web tự động trên nền tảng WebdriverIO, Node.js và mô hình Page Object Model. Hệ thống thể hiện tính ứng dụng thực tiễn cao qua việc tích hợp đa dạng các nguồn dữ liệu OSINT để thu thập siêu dữ liệu hạ tầng mạng, kết hợp kiểm thử cấu trúc HTML và kiểm thử luồng chức năng thương mại điện tử. Công trình cung cấp một tài liệu tham khảo chi tiết về quy trình kỹ thuật, cấu trúc mã nguồn và phương pháp tổ chức dữ liệu báo cáo phục vụ công tác đảm bảo chất lượng và an toàn thông tin web.