Lộ trình Kỹ sư QA (Tester): Ajax, CSR, SSR, SWAs, và PWAs là gì? Giải thích cho Kỹ sư QA

Chào mừng bạn đến với loạt bài viết “Lộ trình Kỹ sư QA (Tester)”. Trong hành trình trở thành một Kỹ sư Đảm bảo Chất lượng giỏi, việc hiểu biết về cách các ứng dụng web hiện đại được xây dựng và hoạt động là vô cùng quan trọng. Thế giới web ngày càng phát triển, từ những trang tĩnh đơn giản đến các ứng dụng phức tạp, tương tác cao. Sự thay đổi này mang đến cả cơ hội và thách thức mới cho công việc kiểm thử của chúng ta. Hôm nay, chúng ta sẽ cùng tìm hiểu về một số khái niệm cốt lõi định hình nên web hiện đại: AJAX, CSR, SSR, SWAs và PWAs, và quan trọng hơn cả, ý nghĩa của chúng đối với một Kỹ sư QA.

Nếu bạn đang theo dõi loạt bài này, chắc hẳn bạn đã làm quen với các Lộ trình học Kỹ sư QA (Tester) 2025, hiểu được Đảm bảo Chất lượng là gì, và cả cách Phát triển Tư duy QA. Những kiến thức nền tảng đó sẽ giúp bạn tiếp thu chủ đề này một cách dễ dàng hơn.

Web Truyền Thống và Bước Đột Phá AJAX

Trước khi đi sâu vào các khái niệm hiện đại, hãy nhớ lại cách web hoạt động ban đầu. Khi bạn truy cập một trang web, trình duyệt gửi yêu cầu đến máy chủ, máy chủ xử lý và trả về toàn bộ trang HTML. Mỗi khi bạn click vào một liên kết hoặc gửi một form, toàn bộ trang web sẽ được tải lại. Điều này đơn giản, dễ hiểu, nhưng mang lại trải nghiệm người dùng khá chậm và giật cục.

AJAX (Asynchronous JavaScript and XML)

AJAX không phải là một công nghệ duy nhất, mà là một kỹ thuật sử dụng kết hợp nhiều công nghệ sẵn có (JavaScript, XML/JSON, XMLHttpRequest object) để cho phép các ứng dụng web giao tiếp với máy chủ một cách bất đồng bộ (asynchronously). Điều này có nghĩa là trình duyệt có thể gửi và nhận dữ liệu từ máy chủ ở “phông nền” mà không làm gián đoạn trải nghiệm hiện tại của người dùng (không cần tải lại toàn bộ trang).

Thay vì tải lại toàn bộ trang khi người dùng thực hiện một hành động (ví dụ: thêm sản phẩm vào giỏ hàng), AJAX cho phép trang web chỉ gửi yêu cầu cập nhật thông tin đó đến máy chủ, nhận phản hồi (thường là dữ liệu JSON), và JavaScript sẽ cập nhật một phần nhỏ trên trang hiện tại (ví dụ: cập nhật số lượng sản phẩm trong giỏ hàng hiển thị trên header). Tên ban đầu có “XML”, nhưng ngày nay hầu hết sử dụng JSON để truyền dữ liệu.

Ví dụ đơn giản về ý tưởng AJAX (sử dụng Fetch API hiện đại):


// Giả định có một nút "Load More Data"
document.getElementById('loadMoreBtn').addEventListener('click', function() {
  fetch('/api/data') // Gửi yêu cầu bất đồng bộ đến URL /api/data
    .then(response => response.json()) // Xử lý phản hồi thành JSON
    .then(data => {
      // Cập nhật một phần của trang web với dữ liệu nhận được
      document.getElementById('contentArea').innerHTML = '<p>' + data.message + '</p>';
    })
    .catch(error => {
      console.error('Error fetching data:', error);
      // Xử lý lỗi, ví dụ: hiển thị thông báo lỗi cho người dùng
    });
});

Tại sao Kỹ sư QA cần quan tâm đến AJAX?

  • Kiểm thử Tải bất đồng bộ: Các hành động người dùng không còn đồng bộ với việc tải lại trang. Điều này đòi hỏi QA phải kiểm tra xem nội dung mới có được tải và hiển thị chính xác không, đặc biệt là khi mạng chậm hoặc có độ trễ.
  • Trạng thái trang và Lịch sử trình duyệt: Vì trang không tải lại hoàn toàn, URL trên thanh địa chỉ có thể không thay đổi, hoặc thay đổi một cách “ảo” bằng cách sử dụng History API (để tạo cảm giác điều hướng). QA cần kiểm thử xem các nút Back/Forward của trình duyệt có hoạt động đúng mong đợi không, đặc biệt trong các ứng dụng SPA (Single-Page Application) mà chúng ta sẽ nói đến sau.
  • Hiệu năng và Phản hồi: AJAX giúp trang web nhanh hơn, nhưng các yêu cầu bất đồng bộ cũng có thể gây ra vấn đề nếu không được quản lý tốt. QA cần kiểm thử thời gian phản hồi của các yêu cầu AJAX, và đảm bảo trang web vẫn “có cảm giác” nhanh và mượt mà cho người dùng. Bạn có thể tham khảo bài viết về Kiểm thử Tải, Sức chịu tải và Hiệu năng.
  • Xử lý lỗi: Các lỗi xảy ra trong yêu cầu AJAX có thể không hiển thị dưới dạng trang lỗi truyền thống. QA cần kiểm tra xem ứng dụng có xử lý các phản hồi lỗi từ server (ví dụ: 404, 500) một cách khéo léo và thân thiện với người dùng không.
  • Kiểm thử tự động: Trong các script kiểm thử tự động (ví dụ: Selenium, Playwright, Cypress – bạn có thể xem các bài viết về các công cụ tự động hóa Frontend), bạn cần sử dụng các phương thức chờ (wait) phù hợp để đảm bảo các yêu cầu AJAX đã hoàn thành và nội dung mới đã xuất hiện trước khi tương tác với nó.
  • Sử dụng DevTools: Công cụ DevTools của trình duyệt (đặc biệt là tab Network) trở thành người bạn thân thiết để theo dõi các yêu cầu AJAX, xem dữ liệu gửi/nhận và kiểm tra trạng thái phản hồi. Nếu chưa quen, hãy tìm hiểu về Sử dụng Công cụ Dev Tools của Trình duyệt.

Chiến Lược Render: CSR và SSR

Khi nói về cách một trang web hiển thị nội dung, có hai chiến lược render chính:

SSR (Server-Side Rendering)

Trong SSR, máy chủ xử lý request và tạo ra toàn bộ trang HTML hoàn chỉnh trước khi gửi nó đến trình duyệt. Trình duyệt nhận file HTML này và có thể hiển thị nội dung ngay lập tức cho người dùng. JavaScript sau đó sẽ được tải và chạy ở phía trình duyệt để làm cho trang trở nên tương tác (gọi là quá trình “hydration”).

Ưu điểm (từ góc độ người dùng/QA):

  • Thời gian hiển thị nội dung đầu tiên nhanh: Người dùng thấy nội dung (text, hình ảnh) gần như ngay lập tức.
  • Tốt cho SEO: Các bot tìm kiếm dễ dàng đọc được nội dung HTML hoàn chỉnh.

Nhược điểm (từ góc độ người dùng/QA):

  • Tương tác chậm hơn ban đầu: Mặc dù thấy nội dung nhanh, người dùng có thể phải chờ JavaScript tải và chạy xong mới có thể tương tác được (thời gian Time to Interactive – TTI).
  • Tải lại toàn bộ trang khi điều hướng: Với các ứng dụng truyền thống sử dụng SSR thuần túy, mỗi lần click vào liên kết sẽ tải lại toàn bộ trang (trừ khi kết hợp với AJAX).
  • Tải nặng cho máy chủ: Máy chủ phải thực hiện nhiều công việc xử lý và render HTML cho mỗi request.

Kiểm thử với SSR:

  • Kiểm tra thời gian hiển thị nội dung đầu tiên (First Contentful Paint – FCP).
  • Kiểm tra thời gian Time to Interactive (TTI).
  • Kiểm tra xem trang có hiển thị chính xác nội dung ban đầu từ server không.
  • Kiểm thử quá trình “hydration” – đảm bảo JavaScript chạy đúng và làm cho các thành phần trên trang trở nên tương tác mà không gây lỗi.
  • Kiểm tra các lỗi server-side có được hiển thị thân thiện trên trang không.

CSR (Client-Side Rendering)

Trong CSR, máy chủ gửi về một file HTML rất nhỏ, thường chỉ chứa một cấu trúc cơ bản và một thẻ `

Mục lục

→ Chỉ mục