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

Trong quy trình phát triển phần mềm, việc đảm bảo chất lượng hệ thống trước khi bàn giao cho người dùng cuối là một công đoạn quan trọng. Tài liệu nghiên cứu "Kiểm thử trên hệ thống The Guru99 Bank" được thực hiện bởi sinh viên Phạm Quốc Anh (MSSV: 1921006653), dưới sự hướng dẫn của TS. Đinh Nguyễn Thúy Nguyệt thuộc Khoa Công nghệ Thông tin, Trường Đại học Tài chính – Marketing (tháng 4 năm 2023). Đề tài tập trung vào việc áp dụng các kỹ thuật và quy trình kiểm thử phần mềm thực nghiệm trên nền tảng ứng dụng ngân hàng trực tuyến Guru99 Bank.

Bối cảnh thực tiễn của đề tài xuất phát từ đặc thù của hệ thống tài chính - ngân hàng, nơi đòi hỏi độ chính xác, tính toàn vẹn dữ liệu và độ tin cậy vận hành rất cao. Việc xuất hiện các lỗi nghiệp vụ hoặc khiếm khuyết trong giao diện nhập liệu có thể dẫn đến sai lệch thông tin giao dịch hoặc gây cản trở thao tác của người dùng.

Mục tiêu và nhiệm vụ nghiên cứu của đồ án bao gồm:

  1. Hệ thống hóa cơ sở lý luận về kiểm thử phần mềm: định nghĩa, vai trò, các nguyên tắc cốt lõi, các cấp độ kiểm thử và các kỹ thuật kiểm thử phổ biến (hộp đen, hộp trắng, hộp xám).
  2. Khảo sát và phân tích đặc tả yêu cầu nghiệp vụ của ứng dụng web The Guru99 Bank cho hai nhóm đối tượng người dùng chính (Manager và Customer).
  3. Thiết kế bộ kịch bản kiểm thử (Test Case) chi tiết qua hai phiên bản thực hiện nhằm kiểm tra toàn diện giao diện và các ràng buộc dữ liệu đầu vào.
  4. Thực thi kiểm thử, phát hiện khiếm khuyết phần mềm (Bug), ghi nhận các bước tái hiện và phân loại kết quả kiểm thử.
  5. Tổng hợp báo cáo kiểm thử qua hai phiên bản, đánh giá mức độ ổn định và chỉ ra các lỗi tồn đọng của hệ thống.

Đối tượng nghiên cứu là hệ thống ngân hàng trực tuyến The Guru99 Bank (phát triển cho Guru99 Tech). Phạm vi nghiên cứu giới hạn ở việc kiểm thử chức năng (Functional Testing) và kiểm thử giao diện người dùng (UI Testing) thông qua phương pháp kiểm thử thủ công, thực hiện trên trình duyệt Google Chrome từ phiên bản 27 trở lên. Đề tài không bao gồm kiểm thử tự động (Automation Testing) và các loại kiểm thử phi chức năng như kiểm thử hiệu năng hay kiểm thử chịu tải (Stress Testing).

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

Khung lý thuyết và khái niệm

Tác giả hệ thống hóa các định nghĩa nền tảng về kiểm thử phần mềm từ các nguồn tài liệu học thuật và tiêu chuẩn kỹ thuật:

  • Định nghĩa theo Myer (1979): Kiểm thử là quá trình thực thi một chương trình với mục đích tìm ra lỗi, bao gồm các hoạt động từ kiểm tra mã nguồn đến chạy thử chương trình.
  • Định nghĩa theo IEEE Std 610.12 (1990): Kiểm thử phần mềm là quá trình phân tích các yếu tố phần mềm để phát hiện những khác biệt giữa chương trình với các điều kiện yêu cầu và đánh giá các đặc điểm của các yếu tố phần mềm.
  • Quan điểm của Daniel Galin: Kiểm thử là quá trình do nhóm chuyên viên kiểm thử thực hiện, trong đó đơn vị phần mềm, nhóm tích hợp hoặc toàn bộ hệ thống được chạy thử nghiệm trên máy tính tuân theo các quy trình và ca kiểm thử được thiết lập trước.
  • Quan điểm của Beizer về kiểm thử hồi quy (Regression Testing): Là sự lặp lại các kiểm tra nhằm chứng minh các thay đổi không làm thay đổi ngoài ý muốn hành vi vận hành ban đầu của phần mềm.

Đồ án trình bày 7 nguyên tắc kiểm thử phần mềm cốt lõi:

  1. Kiểm thử đưa ra lỗi: Kiểm thử chỉ chứng minh phần mềm có lỗi, không thể chứng minh phần mềm không có lỗi.
  2. Kiểm thử cạn kiệt là không thể: Không thể kiểm tra mọi tổ hợp dữ liệu đầu vào và kịch bản; cần dựa trên phân tích rủi ro và mức độ ưu tiên.
  3. Kiểm thử càng sớm càng tốt: Bắt đầu sớm trong vòng đời phát triển giúp phát hiện lỗi sớm và giảm chi phí sửa đổi.
  4. Sự tập trung của lỗi: Lỗi thường tập trung vào một số mô-đun hoặc chức năng chính.
  5. Nghịch lý thuốc trừ sâu: Lặp lại cùng một tập hợp test case sẽ làm giảm khả năng tìm ra lỗi mới; cần thường xuyên cập nhật test case.
  6. Kiểm thử phụ thuộc vào ngữ cảnh: Chiến lược kiểm thử thay đổi tùy theo loại ứng dụng (ví dụ: web khác với mobile).
  7. Không có lỗi - Sai lầm: Việc không tìm thấy lỗi không đồng nghĩa với việc sản phẩm đã hoàn thiện hoặc đáp ứng đúng kỳ vọng người dùng nếu thiết kế test case bị lệch hướng.

Các cấp độ kiểm thử được phân tích theo mô hình phát triển thác nước:

  • Kiểm thử đơn vị (Unit Testing): Kiểm tra các hàm, thủ tục, lớp hoặc phương thức riêng lẻ, thường do lập trình viên thực hiện.
  • Kiểm thử tích hợp (Integration Testing): Kiểm tra sự giao tiếp và tương tác giữa các đơn vị tích hợp, gồm kiểm thử cấu trúc, chức năng, hiệu năng và chịu tải.
  • Kiểm thử hệ thống (System Testing): Đánh giá toàn diện hệ thống hoàn chỉnh, gồm kiểm thử chức năng (giao diện, luồng nghiệp vụ), kiểm thử hiệu năng và kiểm thử bảo mật (mức ứng dụng và mức hệ thống).
  • Kiểm thử chấp nhận sản phẩm (Acceptance Testing): Do khách hàng hoặc bên thứ ba thực hiện, bao gồm hình thức Alpha Test và Beta Test.

Phương pháp kiểm thử thực tế áp dụng

Nghiên cứu sử dụng phương pháp thực nghiệm dựa trên kỹ thuật kiểm thử hộp đen (Black-box Testing), tập trung vào kiểm thử hướng dữ liệu vào/ra dựa trên đặc tả kỹ thuật (Specification-based Testing) mà không can thiệp vào cấu trúc mã nguồn.

Các kỹ thuật thiết kế test case được vận dụng bao gồm:

  • Phân lớp tương đương (Equivalence Partitioning).
  • Phân tích giá trị biên (Boundary Value Analysis).
  • Kiểm thử luồng nghiệp vụ (Business Flow Testing).
  • Kiểm thử giao diện người dùng (UI Testing).

Nguồn dữ liệu thực nghiệm được thu thập trực tiếp từ việc tương tác trên giao diện web của hệ thống The Guru99 Bank qua tài khoản demo, ghi nhận trạng thái phản hồi thực tế so với kết quả mong đợi.

Thiết kế và triển khai kiểm thử hệ thống

Hệ thống The Guru99 Bank phân quyền theo hai vai trò với các nhóm chức năng tương ứng:

Nhóm chức năng Vai trò Manager (Quản lý) Vai trò Customer (Khách hàng)
Quản lý khách hàng New Customer, Edit Customer, Delete Customer Không có quyền
Quản lý tài khoản New Account (Saving, Current), Edit Account, Delete Account Không có quyền
Giao dịch tài chính Deposit, Withdrawal, Fund Transfer (chuyển từ tài khoản bất kỳ) Fund Transfer (chỉ chuyển từ tài khoản chính chủ)
Truy vấn & Báo cáo Balance Enquiry, Mini Statement (5 giao dịch gần nhất), Customized Statement Balance Enquiry, Mini Statement (chỉ tài khoản cá nhân), Customized Statement
Hệ thống Change Password, Login & Logout Change Password, Login & Logout

Hệ thống đặt ra 110 quy tắc kỹ thuật đối với các trường dữ liệu đầu vào (T1 đến T110) và 49 ràng buộc kiểm tra hợp lệ chức năng (F1 đến F49), tiêu biểu gồm:

  • Ràng buộc định dạng: Mã định danh không chứa ký tự đặc biệt hoặc chữ (T1–T3); tên, thành phố, tiểu bang không chứa số hoặc ký tự đặc biệt (T4–T17); mã PIN bắt buộc 6 chữ số (T21, T73); số điện thoại không vượt quá 15 số (T23–T26); email phải đúng định dạng chuẩn (T27–T28); tất cả các trường không được chứa khoảng trắng ở vị trí đầu tiên (T3.1, T7, T9, T14, T17.1, T22, T26, T29...).
  • Ràng buộc nghiệp vụ chức năng: Số tiền gửi ban đầu khi tạo tài khoản mới tối thiểu 500 (F31); không cho phép chuyển tiền khi tài khoản nguồn không đủ số dư (F7, F11); tài khoản nguồn và đích không được trùng nhau (F6, F10); chỉ xóa khách hàng khi không còn tài khoản vãng lai hoặc tiết kiệm đang hoạt động (Delete Customer); lọc báo cáo giao dịch yêu cầu ngày bắt đầu không được lớn hơn ngày kết thúc (F40, F42).

Cấu trúc kịch bản kiểm thử (Test Case Specification) được chuẩn hóa theo các trường: Test Case ID, TC Description, Steps, Test Data, Expected Result, Status (Open), Test Result (Passed/Failed), Noted (mã Bug tương ứng).

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

Chương 1: Tổng quan

Chương 1 cung cấp nền tảng lý luận toàn diện về kỹ thuật kiểm thử phần mềm. Tác giả trình bày các định nghĩa học thuật, phân tích vai trò của kiểm thử trong việc giảm thiểu rủi ro, tăng cường tính bảo mật và tối ưu chi phí dự án. Nội dung chương đào sâu vào 7 nguyên tắc kiểm thử, phân định rõ 4 cấp độ kiểm thử (đơn vị, tích hợp, hệ thống, chấp nhận), đồng thời so sánh chi tiết ưu nhược điểm của ba trường phái kiểm thử: hộp đen, hộp trắng và hộp xám.

Chương 2: Giới thiệu về ứng dụng kiểm thử

Chương 2 mô tả chi tiết bài toán thực tế trên hệ thống ngân hàng trực tuyến The Guru99 Bank. Tác giả trình bày mục tiêu, phạm vi giới hạn của dự án kiểm thử (chỉ kiểm thử chức năng/giao diện trên Google Chrome ≥ 27), bảng phân quyền giữa Manager và Customer, bảng mô tả chi tiết nghiệp vụ từng mô-đun cùng danh mục 110 yêu cầu kỹ thuật (T1–T110) và 49 quy tắc xác thực chức năng (F1–F49).

Chương 3: Danh sách Test Case

Chương 3 trình bày các ca kiểm thử chi tiết được thiết kế và thực thi qua hai phiên bản:

  • Phiên bản thứ nhất (TC01 đến TC31): Tập trung kiểm thử các trường dữ liệu và ràng buộc trên phân hệ mở tài khoản mới (New Account) và tạo thông tin khách hàng mới (New Customer), bao gồm kiểm tra trường bắt buộc, ký tự đặc biệt, định dạng email, độ dài mã PIN và khoảng trắng đầu dòng.
  • Phiên bản thứ hai (TC32 đến TC67): Mở rộng kiểm thử cho các phân hệ xóa tài khoản (Delete Account), xóa khách hàng (Delete Customer), chỉnh sửa tài khoản (Edit Account) và cập nhật thông tin khách hàng (Edit Customer).

Chương 4: Danh sách Bug

Chương 4 ghi nhận, mô tả và phân tích các lỗi phát sinh trong quá trình thực thi kiểm thử. Mỗi bug được ghi nhận theo cấu trúc chuẩn: Bug ID, Summary, Description, Steps to Reproduce, Expected Result và Observed Result:

Bug ID Tóm tắt lỗi (Summary) Mô tả chi tiết hành vi quan sát
Bug01 Error link does not exist in New Account Người dùng nhập đúng và đủ thông tin ở màn hình New Account rồi bấm Submit thì hệ thống chuyển hướng sang trang không tồn tại kèm thông báo "Customer don't not exist".
Bug02 Error link does not exist in New Customer Tương tự Bug01, khi nhập đầy đủ thông tin hợp lệ tại màn hình New Customer và nhấn Submit, hệ thống điều hướng đến liên kết lỗi.
Bug03 Users can enter disallowed formats after getting a leading whitespace error Khi trường nhập liệu xuất hiện cảnh báo "First character can not have space", nếu người dùng nhập tiếp các ký tự không hợp lệ khác (ký tự đặc biệt, chữ cái...), thông báo lỗi không đổi mà vẫn giữ nguyên thông báo lỗi khoảng trắng.
Bug04 User enters more than 6 digits, there is no error message Tại trường mã PIN, khi người dùng nhập số lượng ký tự vượt quá 6 chữ số (ví dụ: 12345...), hệ thống không hiển thị thông báo lỗi vượt quá độ dài quy định.
Bug05 User who presses Reset still has an error message of the fields Sau khi nhập sai để hiển thị thông báo lỗi, người dùng nhấn nút Reset nhưng các thông báo lỗi trên các trường vẫn không bị xóa đi.
Bug06 If the user enters more than 15 numbers in the Mobile Number field, there is no error message Trường số điện thoại cho phép nhập nhiều hơn 15 chữ số mà không có thông báo giới hạn ký tự.

Tại phiên bản thứ hai, báo cáo ghi nhận việc kiểm thử lại (re-test/regression) đối với Bug ID 01 và Bug ID 02 trên build sửa lỗi V2.

Chương 5: Kết luận

Chương 5 tổng kết toàn bộ tiến trình kiểm thử qua hai phiên bản, bao gồm số liệu thống kê thành viên tham gia báo cáo, tổng số test case đã triển khai, số lượng bug phát hiện trong từng giai đoạn và tổng số khiếm khuyết được định danh trên toàn bộ hệ thống The Guru99 Bank.

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

Nghiên cứu mang lại các kết quả thực nghiệm cụ thể:

  1. Xây dựng hoàn chỉnh bộ 67 kịch bản kiểm thử (Test Case) chi tiết, bao phủ các trường hợp kiểm thử biên, dữ liệu hợp lệ và không hợp lệ cho 6 phân hệ cốt lõi (New Account, New Customer, Delete Account, Delete Customer, Edit Account, Edit Customer).
  2. Phát hiện và ghi nhận 6 lỗi hệ thống nghiêm trọng và trung bình (từ Bug01 đến Bug06) liên quan đến định tuyến liên kết (broken links), xử lý sự kiện giao diện (nút Reset), kiểm soát độ dài dữ liệu (PIN > 6 số, SĐT > 15 số) và cơ chế cập nhật thông báo lỗi động (lỗi khoảng trắng đầu dòng).
  3. Thực hiện kiểm thử hồi quy trên bản sửa lỗi V2 cho các lỗi điều hướng chính, đóng góp tài liệu kiểm thử chuẩn mực phục vụ kiểm soát chất lượng phần mềm.

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

Hạn chế được tác giả và văn bản xác định:

  • Phạm vi kiểm thử chỉ dừng lại ở phương pháp thủ công (Manual Testing), chưa áp dụng các công cụ kiểm thử tự động hóa (Automation Testing).
  • Môi trường kiểm thử bị giới hạn trên trình duyệt Google Chrome (phiên bản 27 trở lên), chưa đánh giá tính tương thích đa trình duyệt (Cross-browser Testing).
  • Chưa triển khai các loại kiểm thử phi chức năng như kiểm thử tải, kiểm thử hiệu năng và kiểm thử bảo mật chuyên sâu.

Hướng phát triển tiếp theo của đề tài:

  • Mở rộng kịch bản kiểm thử tự động hóa bằng các framework kiểm thử web.
  • Bổ sung kiểm thử hiệu năng và chịu tải cho các giao dịch chuyển tiền (Fund Transfer) và báo cáo tùy chỉnh (Customized Statement) khi có nhiều người dùng đồng thời.

Giá trị tham khảo

Tài liệu này có giá trị ứng dụng và tham khảo thực tiễn:

  • Đối với sinh viên ngành Công nghệ thông tin và Kỹ thuật phần mềm: Là tài liệu mẫu hữu ích về quy trình xây dựng tài liệu kiểm thử phần mềm, từ khâu trích xuất đặc tả yêu cầu, viết test case chuẩn format đến lập báo cáo bug.
  • Đối với người học môn Kiểm thử phần mềm: Phần Chương 1 và Chương 2 cung cấp hệ thống lý thuyết cô đọng cùng phương pháp ánh xạ yêu cầu nghiệp vụ ngân hàng thành các ràng buộc kỹ thuật rõ ràng.

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

1. Đồ án áp dụng phương pháp kiểm thử nào làm chủ đạo trên hệ thống The Guru99 Bank?
Đồ án sử dụng phương pháp kiểm thử hộp đen (Black-box Testing) dựa trên đặc tả kỹ thuật, tập trung vào kiểm thử chức năng và kiểm thử giao diện người dùng.

2. Hai nhóm vai trò người dùng trong hệ thống The Guru99 Bank có sự phân quyền như thế nào?
Hệ thống phân quyền cho Manager (có toàn quyền quản lý khách hàng, mở/sửa/xóa tài khoản, nộp/rút tiền và xem số dư mọi tài khoản) và Customer (chỉ có quyền tra cứu số dư, chuyển tiền, xem sao kê và đổi mật khẩu trên tài khoản chính chủ).

3. Lỗi Bug03 trong báo cáo kiểm thử mô tả vấn đề gì?
Bug03 mô tả lỗi cập nhật thông báo: khi một trường gặp lỗi chứa khoảng trắng đầu dòng (First character can not have space), nếu người dùng tiếp tục nhập sai định dạng khác (ký tự đặc biệt, chữ số), thông báo lỗi không cập nhật theo lỗi mới mà vẫn bị giữ nguyên cảnh báo khoảng trắng.

4. Quy định về số tiền gửi ban đầu khi tạo tài khoản mới (New Account) trong tài liệu là bao nhiêu?
Theo quy tắc ràng buộc chức năng F31 của hệ thống, số tiền gửi ban đầu (Initial deposit) bắt buộc phải từ 500 trở lên; nếu nhỏ hơn 500 hệ thống phải báo lỗi.

5. Phạm vi nghiên cứu của đồ án có thực hiện kiểm thử tự động hay kiểm thử hiệu năng không?
Không. Văn bản nêu rõ kiểm thử tự động hóa và các kiểm thử phi chức năng (như kiểm thử hiệu năng, kiểm thử chịu tải) nằm ngoài phạm vi nghiên cứu của đề tài.

Kết luận

Đồ án "Kiểm thử trên hệ thống The Guru99 Bank" của tác giả Phạm Quốc Anh đã hệ thống hóa chặt chẽ cơ sở lý thuyết kiểm thử phần mềm và ứng dụng thành công kỹ thuật kiểm thử hộp đen vào thực nghiệm hệ thống ngân hàng trực tuyến. Thông qua việc thiết kế 67 ca kiểm thử và phát hiện 6 lỗi nghiệp vụ - giao diện điển hình, công trình đã phản ánh chính xác quy trình kiểm soát chất lượng phần mềm theo chuẩn mực học thuật và thực tiễn. Đây là tài liệu tham khảo có giá trị cao cho sinh viên chuyên ngành Công nghệ thông tin trong học phần Kỹ thuật kiểm thử phần mềm.