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

Trong quy trình phát triển phần mềm hiện đại, kiểm thử là một giai đoạn thiết yếu nhằm xác định mức độ phù hợp của hệ thống so với yêu cầu đặc tả, phát hiện lỗi lập trình và đảm bảo chất lượng vận hành trước khi chuyển giao tới người dùng. Theo tác giả Vương Thị Thu Phương trong khóa luận tốt nghiệp ngành Công nghệ thông tin (Đại học Hòa Bình, 2023), vai trò của chuyên viên kiểm thử phần mềm (Tester) mang tính chất sống còn đối với các doanh nghiệp sản xuất phần mềm. Nếu sản phẩm không được kiểm tra toàn diện, nguy cơ bị khách hàng từ chối tiếp nhận và hoàn trả sẽ gia tăng đáng kể.

Thực tiễn phát triển phần mềm ghi nhận sự tách biệt ngày càng rõ nét giữa phát triển giao diện phía máy khách (Client) và hệ thống xử lý phía máy chủ (Server). Cả hai thành phần này thường được xây dựng độc lập trên các nền tảng và ngôn ngữ lập trình khác nhau, kết nối thông qua giao diện lập trình ứng dụng (API). Tuy nhiên, trên thực tế, công tác kiểm thử API tại nhiều dự án thường bị đẩy xuống giai đoạn cuối của vòng đời sản phẩm, hoặc người kiểm thử chỉ dừng lại ở việc gọi thủ công từng API đơn lẻ theo danh sách từ nhóm lập trình. Việc trì hoãn đến khi hoàn thiện giao diện người dùng (GUI) mới tiến hành kiểm thử gây ra sự chậm trễ trong tiến độ phát triển, tốn kém chi phí sửa lỗi và gây khó khăn cho việc phân định lỗi thuộc về phía máy khách hay máy chủ.

Nhằm giải quyết bất cập này và tối ưu hóa thời gian cũng như chi phí phát hiện lỗi, đề tài xác định 3 mục tiêu và nhiệm vụ nghiên cứu cụ thể:

  1. Tìm hiểu tổng quan về kiểm thử phần mềm và phương pháp kiểm thử API có sự trợ giúp của công cụ chuyên dụng.
  2. Nghiên cứu vai trò, phương pháp và ứng dụng của công cụ Postman trong hoạt động kiểm thử Web API.
  3. Phân tích nghiệp vụ, thiết kế bộ trường hợp kiểm thử (testcase) cho các chức năng của một website thực tế; ứng dụng các tính năng nâng cao của Postman (như quản lý biến môi trường, kịch bản tiền xử lý, kịch bản kiểm tra tự động và chạy kiểm thử hàng loạt) để thực thi kiểm thử API.

Đối tượng nghiên cứu của khóa luận là công cụ kiểm thử Postman, giao thức truyền tải siêu văn bản (HTTP/HTTPS), các định dạng dữ liệu trao đổi (JSON, XML) và kiến trúc RESTful API. Phạm vi nghiên cứu thực nghiệm được giới hạn trên hệ thống Web API thuộc môi trường kiểm thử của website giáo dục trực tuyến "Eduquiz" (tại địa chỉ máy chủ thử nghiệm https://api-dev.vn), tập trung vào hai phân hệ xác thực cơ bản gồm chức năng Đăng ký tài khoản, chức năng Đăng nhập hệ thống và kiểm thử hiệu năng phản hồi khi có nhiều yêu cầu đồng thời.

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

Khóa luận thiết lập nền tảng lý thuyết dựa trên các khái niệm tiêu chuẩn trong kiến trúc hệ thống mạng và kiểm thử phần mềm:

  • API và Web API: Giao diện lập trình ứng dụng (API) được định nghĩa là tập hợp các phương thức và giao thức cho phép các chương trình, thư viện giao tiếp và trao đổi dữ liệu với nhau. Web API là hình thức triển khai cho phép các ứng dụng trao đổi dữ liệu qua mạng Internet thông qua giao thức HTTP hoặc HTTPS, với dữ liệu phản hồi thường được định dạng theo cấu trúc JSON hoặc XML.
  • Giao thức HTTP trong kiến trúc RESTful: Hoạt động trao đổi dữ liệu tuân theo chu trình Yêu cầu (Request) và Phản hồi (Response). Một yêu cầu chuẩn bao gồm 4 thành phần: Địa chỉ tài nguyên (URL), Phương thức thao tác (Method: GET, POST, PUT, DELETE), Tiêu đề (Headers) và Thân dữ liệu (Body). Phản hồi từ máy chủ bao gồm Thân dữ liệu và Mã trạng thái phản hồi (Status Code).
  • Mã trạng thái HTTP (HTTP Status Code): Khóa luận phân loại hệ thống mã trạng thái gồm: nhóm 1xx (Thông tin), nhóm 2xx (Thành công - tiêu biểu là 200 OK, 201 Created), nhóm 3xx (Chuyển hướng), nhóm 4xx (Lỗi từ phía máy khách - như 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 408 Request Timeout, 422 Unprocessable Content), và nhóm 5xx (Lỗi từ phía máy chủ - như 500 Internal Server Error, 502 Bad Gateway).
  • Mô hình Kim tự tháp tự động hóa (Automation Pyramid): Lý thuyết chỉ rõ chi phí xây dựng, bảo trì và thời gian phản hồi kiểm thử tăng dần từ tầng đáy (Unit Test) lên tầng giữa (API Testing) và đạt mức cao nhất tại tầng đỉnh (GUI Testing). Do đó, chiến lược kiểm thử tự động hiệu quả cần tập trung nhiều vào tầng Unit Test và API Testing nhằm phát hiện lỗi logic sớm mà không phụ thuộc vào tiến độ xây dựng giao diện người dùng.

Phương pháp nghiên cứu được triển khai thông qua quy trình 4 bước có cấu trúc:

  • Bước 1: Phân tích tài liệu kỹ thuật API: Đọc hiểu tài liệu API (API Documentation do lập trình viên cung cấp) để nắm bắt các hàm, tham số đầu vào, kiểu dữ liệu trả về và quy tắc logic nghiệp vụ.
  • Bước 2: Thiết kế trường hợp kiểm thử (Testcase): Xây dựng bảng kịch bản sử dụng (Use Case) và bảng đặc tả testcase chi tiết (gồm Mã testcase, Mục đích kiểm thử, Dữ liệu đầu vào, Kết quả mong muốn, Kết quả thực tế và Trạng thái Đạt/Không đạt).
  • Bước 3: Thiết lập môi trường kiểm thử trên công cụ: Cấu hình không gian làm việc (Workspace), định nghĩa bộ biến môi trường (Environments) để tham số hóa địa chỉ endpoint và dữ liệu dùng chung.
  • Bước 4: Thực thi kiểm thử và đánh giá: Gửi các request với các tập dữ liệu biên, dữ liệu hợp lệ và không hợp lệ; sử dụng script kiểm tra kết quả tự động; thực hiện kiểm thử hiệu năng và lập báo cáo đánh giá chất lượng dịch vụ Web API.

Nguồn dữ liệu thực nghiệm được thu thập trực tiếp từ các phản hồi (HTTP Response Body, Status Code, Response Time, Response Size) của máy chủ dịch vụ api-dev.vn khi xử lý các tập dữ liệu kiểm thử giả lập.

Thiết kế và triển khai

Khóa luận tổ chức kiến trúc kiểm thử tự động hóa trên công cụ Postman thông qua các thành phần chức năng:

  • Tổ chức Bộ sưu tập (Collections): Toàn bộ các yêu cầu HTTP phục vụ kiểm thử hai phân hệ Đăng ký và Đăng nhập được phân nhóm theo thư mục chức năng, cho phép cấu hình tham số, tiêu đề chung và quản lý trình tự thực thi có hệ thống.
  • Quản lý Môi trường (Environments): Tác giả khởi tạo môi trường mang tên "TN1", thiết lập các biến để tái sử dụng trên toàn bộ bộ sưu tập, tiêu biểu như biến dang_ky lưu trữ giá trị đường dẫn https://api-dev.vn/auth/api/v1/register. Biến môi trường được tham chiếu linh hoạt trong các request thông qua cú pháp hai dấu ngoặc nhọn {{dang_ky}}.
  • Kịch bản tiền xử lý (Pre-request Script): Ứng dụng ngôn ngữ JavaScript để sinh dữ liệu kiểm thử động trước khi request được gửi đi. Cụ thể, tác giả lập trình đoạn mã tự động tạo chuỗi tên người dùng ngẫu nhiên theo cấu trúc Name - xxxxx (với xxxxx là dãy 5 chữ số ngẫu nhiên) và gán vào biến {{name}} trong phần Body của request, hạn chế việc phải nhập thủ công dữ liệu kiểm thử trùng lặp.
  • Kịch bản kiểm tra tự động (Tests Script): Viết mã khẳng định (assertions) bằng JavaScript trong tab Tests để tự động đánh giá phản hồi ngay sau khi nhận Response từ máy chủ. Các kiểm tra tiêu chuẩn gồm:
    • Khẳng định mã trạng thái HTTP trả về: Kiểm tra trạng thái 200 OK thông qua cú pháp hàm pm.response.to.have.status(200).
    • Khẳng định thời gian phản hồi: Xác minh thời lượng xử lý của máy chủ có nằm trong ngưỡng cho phép (dưới 400ms) bằng cú pháp pm.expect(pm.response.responseTime).to.be.below(400).
    • Trích xuất và lưu trữ dữ liệu động: Lấy chuỗi token xác thực từ thân phản hồi của lệnh đăng nhập thành công (jsonData.access_token) và lưu tự động vào biến môi trường token bằng cú pháp pm.environment.set("token", jsonData.access_token) để phục vụ cho các yêu cầu kế tiếp.
  • Bộ chạy tự động (Collection Runner): Thiết lập cấu hình chạy tự động toàn bộ bộ sưu tập "User Test Collection" với tham số lặp lại 3 chu kỳ (Iterations: 3) và thời gian trễ giữa các yêu cầu là 2500ms (Delay: 2500ms), giúp tự động hóa quá trình kiểm thử hồi quy và thống kê trực quan số lượng kiểm thử thành công (Passed) hoặc thất bại (Failed).
  • Kiểm thử hiệu năng (Performance Testing): Cấu hình kịch bản tạo tải ảo gửi đồng thời 100 người dùng (100 virtual users) và 200 người dùng (200 virtual users) vào endpoint của hệ thống Eduquiz để ghi nhận và đối chiếu thời gian đáp ứng trung bình của máy chủ.

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

Mở đầu

Phần mở đầu tập trung phân tích bối cảnh phát triển của ngành công nghệ phần mềm tại Việt Nam, nêu bật vị trí của kiểm thử phần mềm trong chu trình phát triển sản phẩm. Tác giả chỉ ra tính cấp thiết của việc áp dụng kiểm thử API sớm để kiểm soát lỗi dữ liệu giữa client và server một cách độc lập, qua đó xác định mục đích, đối tượng, phạm vi nghiên cứu và bố cục tổng quát gồm 4 chương của khóa luận.

Chương 1: Tổng quan về kiểm thử API

Nội dung chương 1 hệ thống hóa toàn bộ lý luận chuyên ngành về API, Web API và giao thức mạng. Tác giả phân tích chi tiết bản chất của giao thức HTTP/HTTPS với cơ chế Request - Response; mô tả các thành phần cấu tạo nên một yêu cầu (URL, phương thức GET, POST, PUT, DELETE, Headers, Body) và phản hồi từ máy chủ. Định dạng dữ liệu JSON (cấu trúc cặp khóa - giá trị) và XML (cấu trúc thẻ node) được đối chiếu rõ nét. Chương này cũng phân tích mô hình Kim tự tháp tự động hóa để chứng minh lợi thế tiết kiệm chi phí và thời gian của API Testing so với kiểm thử giao diện (GUI), đồng thời diễn giải ý nghĩa của các nhóm mã trạng thái HTTP thường gặp từ 1xx đến 5xx.

Chương 2: Ứng dụng công cụ Postman trong kiểm thử API

Chương 2 trình bày tổng quan về công cụ Postman (được ghi nhận có hơn 8 triệu nhà phát triển sử dụng tại thời điểm nghiên cứu) và các lý do lựa chọn công cụ này: khả năng truy cập đa nền tảng, quản lý Collections, khả năng cộng tác chia sẻ môi trường làm việc, tham số hóa biến môi trường (Environments), viết kiểm thử tự động, công cụ gỡ lỗi (Console), chạy kiểm thử hàng loạt bằng Collection Runner hoặc Newman và khả năng tích hợp liên tục (CI). Tác giả hướng dẫn chi tiết quy trình thao tác với các loại request (GET, POST), cách viết Pre-request Script bằng JavaScript để tạo biến ngẫu nhiên, cách lập trình Tests Script để kiểm tra mã trạng thái và thời gian đáp ứng, cũng như các bước thiết lập thông số trong Collection Runner và cấu hình biến môi trường.

Chương 3: Thực nghiệm kiểm thử API trong web "Eduquiz"

Chương 3 là phần trọng tâm thực nghiệm của khóa luận, áp dụng các kỹ thuật đã nghiên cứu vào kiểm thử hệ thống API của website giáo dục "Eduquiz" (nền tảng cung cấp giải pháp ôn thi trực tuyến). Tác giả thiết lập quy trình kiểm thử 4 bước, lập bảng kịch bản sử dụng (Use Case) và thiết kế hệ thống trường hợp kiểm thử chi tiết cho hai chức năng:

  • Chức năng Đăng ký tài khoản (POST https://api-dev.vn/auth/api/v1/register): Xây dựng 6 trường hợp kiểm thử (TC_01 đến TC_06) bao quát các tình huống dữ liệu biên và dữ liệu bất thường:
    • TC_01: Để trống toàn bộ các trường thông tin đầu vào (first_name, last_name, username, email, mobile, password, password_confirmation, type). Kết quả trả về mã lỗi 422 Unprocessable Content, thời gian đáp ứng 386ms, kích thước 746B; thân phản hồi thông báo chi tiết 7 lỗi bắt buộc.
    • TC_02: Nhập email sai cú pháp (ananhgmail.com) và số điện thoại sai định dạng (09808777899). Hệ thống trả về mã lỗi 422, thời gian 426ms, thông báo yêu cầu địa chỉ email hợp lệ.
    • TC_03: Nhập email và số điện thoại chứa khoảng trắng ở đầu, cuối và có ký tự đặc biệt (lan&anhgmail.com, 0)53462105). Hệ thống trả về mã lỗi 422, thời gian 343ms, thông báo lỗi định dạng email.
    • TC_04: Nhập email (vuonganhsoaica@gmail.com) và số điện thoại (0353462105) đã tồn tại trong cơ sở dữ liệu. Kết quả trả về mã lỗi 422, thời gian 400ms, thông báo username đã được sử dụng. (and 2 more errors).
    • TC_05: Nhập toàn bộ thông tin trùng khớp với một tài khoản đã có sẵn trong hệ thống. Kết quả trả về mã lỗi 422, thời gian 398ms, báo lỗi trùng lặp dữ liệu.
    • TC_06: Nhập đầy đủ và chính xác tất cả các trường dữ liệu hợp lệ chuẩn đầu vào. Kết quả trả về phản hồi thành công {"success": true} với thời gian đáp ứng 403ms.
  • Chức năng Đăng nhập (POST https://api-dev.vn/auth/api/v1/login): Xây dựng 6 trường hợp kiểm thử (TC_01 đến TC_06):
    • TC_01: Để trống cả trường username và password. Máy chủ trả về mã 200 OK (thời gian 326ms, kích thước 506B), thân phản hồi hiển thị thông báo lỗi logic: Email là bắt buộc khi username là empty.
    • TC_02: Nhập đúng username (postman) nhưng nhập sai password (123@123). Máy chủ phản hồi mã lỗi 500 Internal Server Error, kích thước phản hồi 2.19KB.
    • TC_03: Nhập đúng username nhưng bỏ trống hoàn toàn trường password. Kết quả trả về lỗi hệ thống.
    • TC_04: Chèn khoảng trắng vào trường username hoặc password. Máy chủ trả về mã lỗi 500 Internal Server Error.
    • TC_05: Nhập tài khoản và mật khẩu không tồn tại trên hệ thống. Máy chủ trả về mã lỗi 500 Internal Server Error.
    • TC_06: Nhập chính xác thông tin tài khoản và mật khẩu hợp lệ. Hệ thống xác thực thành công, trả về mã 200 OK kèm mã thông báo truy cập dạng Bearer token: 21930|ePaCS8a4yzpTqlX2JcgtgKbed2HXxPQvfDiqMWRb.
  • Kiểm thử hiệu năng: Thực hiện đo lường tải bằng cách gửi 100 người dùng và 200 người dùng đồng thời vào hệ thống để thống kê biểu đồ thời gian đáp ứng (Response time).

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

Chương cuối tổng kết các kết quả đạt được, đánh giá ưu điểm và hạn chế của phương pháp kiểm thử API bằng Postman, đồng thời vạch ra hướng phát triển mở rộng kiểm thử tự động trong tương lai.

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

Khóa luận đã ghi nhận đầy đủ kết quả kiểm thử chức năng trên hệ thống thực tế thông qua các số liệu đo lường cụ thể được tổng hợp tại bảng dưới đây:

Mã kiểm thử Chức năng kiểm thử Mục đích kiểm thử / Dữ liệu đầu vào Mã trạng thái HTTP Thời gian phản hồi (ms) Đánh giá kết quả
TC_01 Đăng ký tài khoản Để trống toàn bộ các trường thông tin 422 Unprocessable Content 386 ms Đạt (Pass)
TC_02 Đăng ký tài khoản Email/SĐT không đúng định dạng chuẩn 422 Unprocessable Content 426 ms Đạt (Pass)
TC_03 Đăng ký tài khoản Dữ liệu chứa khoảng trắng và ký tự đặc biệt 422 Unprocessable Content 343 ms Đạt (Pass)
TC_04 Đăng ký tài khoản Email và số điện thoại đã tồn tại 422 Unprocessable Content 400 ms Đạt (Pass)
TC_05 Đăng ký tài khoản Trùng khớp hoàn toàn tài khoản đã có 422 Unprocessable Content 398 ms Đạt (Pass)
TC_06 Đăng ký tài khoản Dữ liệu nhập hợp lệ, chuẩn đầu vào 422 / 200 (success: true) 403 ms Đạt (Pass)
TC_01 Đăng nhập hệ thống Để trống cả username và password 200 OK (kèm thông báo lỗi) 326 ms Không đạt (Fail logic)
TC_02 Đăng nhập hệ thống Đúng username, sai password 500 Internal Server Error Không xác định Không đạt (Lỗi 500)
TC_03 Đăng nhập hệ thống Đúng username, bỏ trống password 500 / Lỗi hệ thống Không xác định Không đạt (Lỗi 500)
TC_04 Đăng nhập hệ thống Nhập khoảng trắng vào username/password 500 Internal Server Error Không xác định Không đạt (Lỗi 500)
TC_05 Đăng nhập hệ thống Tài khoản không tồn tại trên hệ thống 500 Internal Server Error Không xác định Không đạt (Lỗi 500)
TC_06 Đăng nhập hệ thống Nhập chính xác username và password 200 OK (trả về Bearer token) Không xác định Đạt (Pass)

Về kiểm thử hiệu năng, khóa luận ghi nhận số liệu thống kê thời gian phản hồi khi tăng tải từ 100 người dùng đồng thời lên 200 người dùng đồng thời gửi request tới hệ thống, phản ánh khả năng chịu tải của máy chủ Eduquiz tại thời điểm thử nghiệm.

Thông qua kết quả kiểm thử, tác giả đã chỉ ra một khiếm khuyết kỹ thuật nghiêm trọng trong phân hệ máy chủ của Eduquiz: API chức năng Đăng ký đã xử lý kiểm tra tính hợp lệ dữ liệu (validation) rất tốt khi trả về mã lỗi chuẩn 422 Unprocessable Content kèm thông báo lỗi cụ thể cho từng trường dữ liệu; ngược lại, API chức năng Đăng nhập xử lý ngoại lệ chưa hoàn thiện. Khi người dùng nhập sai thông tin xác thực, bỏ trống trường dữ liệu hoặc chèn khoảng trắng, máy chủ không trả về các mã lỗi máy khách hợp lý (thuộc nhóm 4xx) mà làm phát sinh ngoại lệ chưa kiểm soát dẫn đến mã lỗi 500 Internal Server Error hoặc trả về mã 200 OK nhưng thân phản hồi lại chứa thông báo lỗi.

Từ các phát hiện trên, tác giả đề xuất giải pháp đối với đội ngũ phát triển website Eduquiz: Cần tiến hành tái cấu trúc bộ điều khiển (Controller) của API Đăng nhập, bổ sung các lớp kiểm tra dữ liệu đầu vào (Request Validation), chuẩn hóa việc xử lý ngoại lệ để máy chủ trả về các mã trạng thái HTTP nhất quán (mã 400 Bad Request hoặc 422 Unprocessable Content) thay vì để hệ thống sập và báo lỗi máy chủ 500.

Đóng góp chính của đề tài là xây dựng được một quy trình mẫu hoàn chỉnh về kiểm thử Web API sử dụng công cụ Postman: từ phân tích tài liệu API, lập kịch bản kiểm thử, tham số hóa biến môi trường, viết script kiểm tra tự động mã trạng thái và thời gian đáp ứng, cho đến việc ứng dụng Collection Runner để tự động hóa quy trình kiểm thử hồi quy trên một sản phẩm giáo dục thực tế.

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

Khóa luận còn tồn tại một số hạn chế nhất định đã được tác giả chỉ ra hoặc phản ánh qua phạm vi thực hiện:

  • Phạm vi kiểm thử hạn chế: Nghiên cứu mới chỉ tập trung thực nghiệm trên hai chức năng xác thực cơ bản là Đăng ký và Đăng nhập của website Eduquiz, chưa mở rộng sang các phân hệ nghiệp vụ cốt lõi phức tạp hơn của hệ thống như tạo đề thi, nộp bài kiểm tra hay chấm điểm tự động.
  • Hạn chế về công cụ kiểm thử hiệu năng: Việc sử dụng tính năng kiểm thử hiệu năng trên Postman chỉ cung cấp các chỉ số đo lường tải ở mức độ cơ bản với quy mô nhỏ (100 và 200 người dùng ảo), chưa phân tích sâu được các thông số nghẽn cổ chai của hạ tầng mạng, bộ nhớ RAM hay tỷ lệ sử dụng CPU của máy chủ.
  • Tính phụ thuộc: Quá trình kiểm thử phụ thuộc hoàn toàn vào tính đầy đủ và chính xác của tài liệu API do nhóm lập trình cung cấp.

Về hướng phát triển tiếp theo, tác giả đề xuất:

  • Mở rộng phạm vi thiết kế kịch bản và thực thi kiểm thử tự động cho toàn bộ các chức năng Web API còn lại trên nền tảng Eduquiz.
  • Tích hợp công cụ Newman vào quy trình tích hợp liên tục/triển khai liên tục (CI/CD) của dự án phần mềm để tự động kích hoạt các bộ kiểm thử API mỗi khi có bản build mã nguồn mới.
  • Kết hợp nghiên cứu và áp dụng các công cụ kiểm thử hiệu năng chuyên sâu (như JMeter) để đánh giá khả năng chịu tải quy mô lớn và khả năng mở rộng của hệ thống máy chủ.

Giá trị tham khảo

Khóa luận tốt nghiệp của sinh viên Vương Thị Thu Phương mang lại giá trị tham khảo thiết thực cho:

  • Sinh viên chuyên ngành Công nghệ thông tin và Kỹ thuật phần mềm: Tài liệu cung cấp hướng dẫn từng bước từ lý thuyết đến thực hành về quy trình kiểm thử Web API; là tài liệu tham khảo trực tiếp cho các đồ án môn học liên quan đến Kiểm thử phần mềm, Nhập môn công nghệ phần mềm hoặc Khóa luận tốt nghiệp hướng kiểm thử chất lượng hệ thống.
  • Chuyên viên kiểm thử (Manual Tester và Automation Tester mới vào nghề): Khóa luận hệ thống hóa phương pháp sử dụng công cụ Postman không chỉ ở mức độ gửi request thủ công thông thường, mà đi sâu vào việc viết code tự động hóa bằng JavaScript (Pre-request Script, Tests Script), cách quản lý biến môi trường và sử dụng Collection Runner.
  • Phần nội dung có giá trị tham khảo cao nhất: Chương 2 (các mẫu cú pháp JavaScript kiểm tra mã trạng thái, kiểm tra thời gian đáp ứng và lưu token) và Chương 3 (bảng kịch bản testcase chi tiết cùng dữ liệu phân tích phản hồi lỗi 422 và 500 trên hệ thống thực tế).

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

1. Mục tiêu cốt lõi mà khóa luận hướng tới là gì?
Khóa luận tập trung nghiên cứu cơ sở lý luận về kiểm thử Web API, làm chủ các tính năng nâng cao của công cụ Postman (Environments, Pre-request Script, Tests Script, Collection Runner) và áp dụng thiết kế, thực thi bộ trường hợp kiểm thử cho các chức năng Đăng ký, Đăng nhập và kiểm thử hiệu năng trên website giáo dục trực tuyến "Eduquiz".

2. Tại sao tác giả nhấn mạnh việc thực hiện kiểm thử API sớm thay vì chờ đợi kiểm thử giao diện người dùng (GUI)?
Dựa trên mô hình Kim tự tháp tự động hóa, kiểm thử GUI đòi hỏi chi phí bảo trì cao và thời gian thực thi lâu. Việc kiểm thử API sớm cho phép kiểm tra trực tiếp logic trao đổi dữ liệu phía máy chủ mà không phụ thuộc vào giao diện, giúp phát hiện và sửa chữa lỗi lập trình ngay từ đầu vòng đời phát triển, giảm thiểu chi phí và rút ngắn tiến độ dự án.

3. Khóa luận đã phát hiện ra lỗi kỹ thuật nghiêm trọng nào trong phân hệ Đăng nhập của website Eduquiz?
Khi thực hiện kiểm thử với các dữ liệu đầu vào không hợp lệ (nhập sai mật khẩu, chèn khoảng trắng, bỏ trống mật khẩu hoặc tài khoản không tồn tại), hệ thống xử lý ngoại lệ không tốt và trả về mã lỗi máy chủ 500 Internal Server Error thay vì trả về các mã trạng thái máy khách chuẩn (nhóm mã 4xx như 400 Bad Request hoặc 422 Unprocessable Content) kèm thông điệp hướng dẫn người dùng.

4. Kỹ thuật Pre-request Script và Tests Script trong Postman được tác giả triển khai nhằm mục đích gì?
Pre-request Script được sử dụng để lập trình đoạn mã JavaScript tự động tạo chuỗi tên ngẫu nhiên dạng Name - xxxxx (với 5 chữ số ngẫu nhiên) gán vào biến môi trường trước khi gửi request. Tests Script được dùng để viết các câu lệnh assertion bằng JavaScript kiểm tra tự động xem mã trạng thái trả về có đúng là 200 OK hay không, thời gian đáp ứng có nhỏ hơn 400ms hay không, và tự động trích xuất chuỗi token từ phản hồi để lưu vào biến môi trường phục vụ cho các yêu cầu xác thực sau đó.

5. Kết quả kiểm thử chức năng Đăng ký tài khoản trên Eduquiz cho thấy API này xử lý dữ liệu ngoại lệ ra sao?
API Đăng ký xử lý kiểm tra tính hợp lệ dữ liệu chặt chẽ: khi dữ liệu đầu vào bị để trống, sai định dạng email/số điện thoại hoặc trùng lặp tài khoản trong cơ sở dữ liệu, máy chủ đều trả về mã trạng thái chuẩn 422 Unprocessable Content cùng cấu trúc mảng JSON liệt kê cụ thể từng lỗi nghiệp vụ (như first name là bắt buộc, Email không đúng định dạng, username đã được sử dụng).

Kết luận

Khóa luận "Nghiên cứu và ứng dụng công cụ Postman trong kiểm thử web API" của tác giả Vương Thị Thu Phương đã hệ thống hóa đầy đủ cơ sở lý luận về kiến trúc RESTful API, giao thức HTTP và mô hình kiểm thử tự động hóa. Đề tài triển khai thành công việc ứng dụng các tính năng nâng cao của Postman để thiết kế, thực thi kiểm thử chức năng và đo lường hiệu năng trên hệ sinh thái dịch vụ web của website giáo dục Eduquiz. Kết quả nghiên cứu không chỉ chỉ ra các khiếm khuyết trong cơ chế xử lý ngoại lệ của hệ thống máy chủ thực tế mà còn cung cấp một tài liệu tham khảo có cấu trúc rõ ràng về phương pháp kiểm thử API tự động hóa cho sinh viên và kỹ sư phần mềm.