Kế Hoạch Kiểm Thử Website Thư Viện Trường Đại Học Ngân Hàng TP.HCM

Một kế hoạch kiểm thử website thư viện hiệu quả bắt đầu từ việc nắm vững nền tảng lý luận. 68 trang · Trường Đại Học Ngân Hàng TP.HCM.

• Trường học: Trường Đại Học Ngân Hàng TP.HCM
• Đề tài: Kế Hoạch Kiểm Thử Website Thư Viện Trường Đại Học Ngân Hàng TP.HCM
• Địa điểm: TP.HCM

Mục lục chi tiết

• LỜI CAM ĐOAN
• LỜI MỞ ĐẦU
• 1. CHƯƠNG 1: CƠ SỞ LÝ LUẬN
• 1.1. Tổng quan về kiểm thử phần mềm
• 1.2. Mục tiêu của kiểm thử phần mềm
• 1.3. Quy trình kiểm thử phần mềm
• 1.3.1. Lập kế hoạch
• 1.3.2. Thiết kế test case (thiết kế trường hợp kiểm thử)
• 1.3.3. Phát triển test script
• 1.3.4. Thực hiện kiểm thử
• 1.3.5. Đánh giá quá trình kiểm thử
• 1.4. Các cấp độ kiểm thử phần mềm
• 1.4.1. Unit Test (Kiểm thử đơn vị)
• 1.4.2. Integration Test (Kiểm thử tích hợp)
• 1.4.3. System Test (Kiểm thử hệ thống)
• 1.5. Các phương pháp kiểm thử phần mềm
• 1.5.1. Kiểm thử hộp đen (Black box testing)
• 1.5.2. Kiểm thử hộp trắng (White box testing)
• 1.5.3. Kiểm thử hộp xám
• 2. CHƯƠNG 2: MÔ TẢ HỆ THỐNG VÀ PHƯƠNG PHÁP TIẾP CẬN HỆ THỐNG
• 2.1. Mô tả nghiệp vụ của thư viện
• 2.2. Cách tiếp cận hệ thống
• 3. CHƯƠNG 3: LẬP KẾ HOẠCH KIỂM THỬ WEBSITE THƯ VIỆN ĐẠI HỌC NGÂN HÀNG
• 3.1. Ánh xạ hệ thống
• 3.2. Lập kế hoạch kiểm thử cho các nghiệp vụ
• 3.2.1. Mục tiêu kiểm thử
• 3.2.2. Xác định phạm vi kiểm thử
• 3.2.3. Cách tiếp cận
• 3.2.4. Tiêu chí kiểm thử thành công / thất bại
• 3.2.5. Tiêu chí đình chỉ và kết thúc kiểm thử
• 3.2.6. Quản lý kiểm thử
• 3.2.6.1. Các công việc được lập kế hoạch
• 3.2.6.2. Môi trường kiểm thử
• 3.2.6.3. Công cụ kiểm thử
• 3.2.6.4. Lịch trình công việc
• 4. CHƯƠNG 4: THIẾT KẾ TEST CASE CHO CÁC CHỨC NĂNG CỦA WEBSITE
• 4.1. Kiểm thử nghiệp vụ
• 4.2. Kiểm thử User Interface
• 4.3. Kiểm thử Security/Session
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng quan kế hoạch kiểm thử website thư viện BUH từ A Z

Một kế hoạch kiểm thử website thư viện hiệu quả bắt đầu từ việc nắm vững nền tảng lý luận. Đây là giai đoạn xác định các khái niệm, mục tiêu và quy trình cốt lõi để đảm bảo chất lượng phần mềm. Theo tài liệu nghiên cứu của Nguyễn Thị Trà My (2023), kiểm thử phần mềm không chỉ là tìm lỗi, mà còn là quá trình xác minh hệ thống đáp ứng đúng yêu cầu kỹ thuật và nhu cầu thực tế của người dùng. Đối với website Đại học Ngân hàng BUH, mục tiêu này càng trở nên quan trọng khi nó ảnh hưởng trực tiếp đến trải nghiệm học tập và nghiên cứu của hàng ngàn sinh viên. Một quy trình kiểm thử bài bản sẽ giúp xây dựng niềm tin, cung cấp thông tin chính xác về mức độ chất lượng và quan trọng hơn là ngăn ngừa các lỗi tiềm ẩn trước khi website được triển khai rộng rãi. Quá trình này bao gồm nhiều cấp độ, từ kiểm thử đơn vị (Unit Test) do lập trình viên thực hiện, đến kiểm thử hệ thống (System Test) để đánh giá toàn bộ sản phẩm. Việc hiểu rõ các cấp độ và phương pháp này là tiền đề để xây dựng một kế hoạch toàn diện, giúp tối ưu hóa nguồn lực và mang lại hiệu quả cao nhất.

1.1. Định nghĩa và mục tiêu cốt lõi của kiểm thử phần mềm

Theo định nghĩa chuẩn, kiểm thử phần mềm là quá trình đánh giá một hệ thống bằng phương pháp thủ công hoặc tự động để xác minh rằng nó đáp ứng các yêu cầu đã được chỉ định. Mục tiêu chính không chỉ dừng lại ở việc tìm lỗi. Tài liệu gốc nhấn mạnh bốn mục tiêu trọng tâm: (1) Xác định hệ thống có đáp ứng các thông số kỹ thuật hay không. (2) Đánh giá liệu hệ thống có thực sự đáp ứng nhu cầu của người dùng cuối (sinh viên, giảng viên). (3) Cung cấp thông tin về mức độ chất lượng và tạo dựng sự tự tin cho các bên liên quan. (4) Quan trọng nhất là ngăn ngừa lỗi ngay từ các giai đoạn đầu của chu trình phát triển. Việc này giúp giảm thiểu chi phí sửa chữa và đảm bảo sản phẩm cuối cùng đạt tiêu chí chấp nhận (acceptance criteria). Áp dụng vào website thư viện Đại học Ngân hàng, các mục tiêu này đảm bảo chức năng tra cứu tài liệu trực tuyến hay mượn trả sách online phải hoạt động chính xác và ổn định.

1.2. Quy trình 5 bước kiểm thử website thư viện chuẩn

Tài liệu nghiên cứu đề xuất một quy trình kiểm thử chuyên nghiệp gồm 5 bước. Bước đầu tiên là Lập kế hoạch, nơi các chiến lược, phạm vi và nguồn lực được xác định, kết quả là một bản test plan mẫu. Bước thứ hai là Thiết kế test case, giai đoạn quan trọng để đảm bảo mọi tình huống kiểm thử đều bao phủ hết các yêu cầu. Tại đây, việc xây dựng test case chi tiết cho từng chức năng là bắt buộc. Bước ba là Phát triển test script, áp dụng cho kiểm thử tự động. Bước bốn là Thực hiện kiểm thử, bao gồm việc thiết lập môi trường kiểm thử (test environment) và chạy các test case đã chuẩn bị. Cuối cùng, bước năm là Đánh giá quá trình kiểm thử, nơi các kết quả được phân tích, thống kê lỗi và tạo báo cáo kiểm thử (test report). Quy trình này tạo ra một vòng đời kiểm thử khép kín, đảm bảo không bỏ sót các khâu quan trọng.

II. Thách thức khi kiểm thử website thư viện ĐH Ngân Hàng

Việc kiểm thử website thư viện Đại học Ngân hàng TP.HCM không chỉ là một công việc kỹ thuật mà còn đối mặt với nhiều thách thức về nghiệp vụ và yêu cầu người dùng. Hệ thống này không chỉ là một trang web thông tin đơn thuần mà là một công cụ học tập phức tạp, phục vụ nhiều đối tượng khác nhau từ sinh viên, học viên cao học đến cán bộ viên chức. Mỗi đối tượng lại có những quyền hạn và nhu cầu sử dụng riêng, đòi hỏi hệ thống phải xử lý logic phân quyền một cách chính xác. Thách thức lớn nhất là đảm bảo tính toàn vẹn dữ liệu và sự ổn định của các chức năng cốt lõi như tra cứu tài liệu trực tuyến, quản lý tài khoản người dùng thư viện, và quy trình mượn trả sách online. Bất kỳ một sai sót nào, dù là nhỏ nhất, cũng có thể gây gián đoạn quá trình học tập và nghiên cứu. Do đó, việc xác định rõ ràng các nghiệp vụ phức tạp và các yêu cầu cấp thiết về chất lượng là bước đi đầu tiên và quan trọng nhất trong toàn bộ kế hoạch kiểm thử.

2.1. Phân tích nghiệp vụ hệ thống quản lý thư viện BUH

Nghiệp vụ của hệ thống quản lý thư viện BUH khá đa dạng. Người dùng chính là sinh viên, được cấp thẻ để mượn sách trực tiếp. Trước đó, họ có thể tra cứu thông tin sách trên website để biết số lượng và vị trí. Quy trình mượn sách tại quầy yêu cầu thủ thư quét mã vạch sách và thẻ sinh viên để kiểm tra các điều kiện: tình trạng sách, thời gian đào tạo của sinh viên, số sách đang nợ. Hệ thống cũng phải ghi nhận đầy đủ thông tin mượn trả để phục vụ các lần sau. Đặc biệt, chức năng gia hạn tài liệu được thực hiện trực tuyến, yêu cầu hệ thống xử lý logic về số lần gia hạn và tổng thời gian mượn tối đa. Việc mô tả chi tiết các nghiệp vụ này giúp xác định chính xác các kịch bản kiểm thử (test scenario) cần thiết, đảm bảo không bỏ sót các luồng xử lý quan trọng.

2.2. Yêu cầu cấp thiết về đảm bảo chất lượng website

Tính cấp thiết của việc kiểm thử xuất phát từ vai trò trung tâm của thư viện trong hoạt động đào tạo. Đồ án của Nguyễn Thị Trà My (2023) chỉ rõ: "Thực hiện các hoạt động kiểm thử website thư viện sẽ giúp phát hiện ra các trường hợp gặp lỗi khi người dùng truy cập vào web, từ đó sẽ phát triển website hoàn thiện hơn, hoạt động hiệu quả hơn." Chất lượng website không chỉ được đo lường bằng việc không có lỗi, mà còn ở kiểm thử khả năng sử dụng (usability testing), đảm bảo giao diện thân thiện, dễ dùng. Hơn nữa, với dữ liệu cá nhân của hàng ngàn người dùng, kiểm thử bảo mật (security testing) là yêu cầu bắt buộc để chống lại các truy cập trái phép. Cuối cùng, kiểm thử hiệu năng (performance testing) cần được thực hiện để chắc chắn rằng website không bị quá tải vào các thời điểm truy cập cao điểm, chẳng hạn như mùa thi.

III. Phương pháp lập kế hoạch kiểm thử website thư viện

Để xây dựng một kế hoạch kiểm thử website thư viện thành công, cần một phương pháp tiếp cận có hệ thống và khoa học. Tài liệu nghiên cứu đã đề xuất một kế hoạch chi tiết, bắt đầu từ việc xác định rõ mục tiêu và phạm vi. Mục tiêu không chỉ là tìm lỗi, mà là đảm bảo website không có lỗi, đáp ứng yêu cầu người dùng và tạo dựng sự tín nhiệm. Việc phân định rõ ràng các tính năng sẽ được kiểm thử và các tính năng nằm ngoài phạm vi giúp tập trung nguồn lực hiệu quả. Phương pháp tiếp cận chính được lựa chọn là kiểm thử hộp đen (Black box testing), tức là kiểm thử từ góc nhìn của người dùng cuối mà không cần quan tâm đến cấu trúc mã nguồn bên trong. Cách tiếp cận này rất phù hợp để đánh giá các chức năng nghiệp vụ như đăng nhập, đổi mật khẩu, gia hạn tài liệu. Toàn bộ quá trình được thực hiện thủ công, cho phép kiểm thử viên linh hoạt và sâu sát hơn trong việc đánh giá trải nghiệm người dùng.

3.1. Xác định mục tiêu và phạm vi của hoạt động kiểm thử

Mục tiêu chính của kế hoạch là "tìm ra càng nhiều lỗi website càng tốt" và "đảm bảo rằng website đang được kiểm tra không có lỗi, đáp ứng được yêu cầu của người dùng". Để cụ thể hóa, phạm vi kiểm thử được xác định rõ ràng. Các tính năng nằm trong phạm vi bao gồm: Đăng nhập, Đổi mật khẩu, Gia hạn tài liệu, và Tra cứu tài liệu. Ngược lại, các tính năng nằm ngoài phạm vi là các yêu cầu phi chức năng như hiệu suất, bảo mật, và các trang thông tin đơn giản (Giới thiệu, Tin tức, Liên hệ). Việc xác định phạm vi rõ ràng như vậy giúp nhóm kiểm thử tập trung vào các nghiệp vụ cốt lõi, nơi có nguy cơ xảy ra lỗi cao nhất và ảnh hưởng lớn nhất đến người dùng. Đây là một bước quan trọng trong việc quản lý tài nguyên và thời gian dự án.

3.2. Lựa chọn phương pháp và môi trường kiểm thử phù hợp

Phương pháp được chọn là kiểm thử hộp đen, cho phép kiểm thử viên đóng vai trò là người dùng cuối để tương tác với hệ thống. Phương pháp này giúp phát hiện các lỗi về giao diện, luồng nghiệp vụ và các chức năng không đúng với đặc tả. Về môi trường kiểm thử (test environment), kế hoạch yêu cầu một máy tính cá nhân có kết nối Internet và cài đặt trình duyệt Google Chrome trên hệ điều hành Windows 10. Các công cụ hỗ trợ chính là Microsoft Word để soạn thảo Test Plan và Microsoft Excel để viết và quản lý các Test Case. Sự đơn giản trong môi trường và công cụ giúp giảm thiểu chi phí và cho phép bất kỳ ai cũng có thể tham gia vào quá trình kiểm thử mà không yêu cầu các phần mềm chuyên dụng đắt tiền.

IV. Hướng dẫn xây dựng test case cho website thư viện BUH

Việc xây dựng test case là trái tim của hoạt động kiểm thử thực thi. Đây là quá trình cụ thể hóa các kịch bản kiểm thử (test scenario) thành các bước thực hiện chi tiết, dữ liệu đầu vào và kết quả mong đợi. Đối với kế hoạch kiểm thử website thư viện, mỗi chức năng nghiệp vụ quan trọng đều được thiết kế một bộ test case riêng, sử dụng các kỹ thuật phù hợp để đảm bảo độ bao phủ cao. Ví dụ, chức năng Đăng nhập và Gia hạn tài liệu sử dụng kỹ thuật Bảng quyết định (Decision Table) để kiểm tra tất cả các tổ hợp điều kiện logic. Trong khi đó, chức năng Đổi mật khẩu lại sử dụng kỹ thuật Chuyển đổi trạng thái (State Transition) để kiểm tra các luồng thay đổi mật khẩu phức tạp. Cách tiếp cận này không chỉ giúp tìm ra lỗi một cách có hệ thống mà còn là tài liệu kiểm thử website quan trọng để tái sử dụng trong tương lai.

4.1. Kỹ thuật thiết kế test case bằng phương pháp hộp đen

Tài liệu gốc đã áp dụng hiệu quả các kỹ thuật kiểm thử hộp đen để thiết kế test case. Kỹ thuật Bảng quyết định được sử dụng cho các chức năng có nhiều điều kiện đầu vào và các hành động tương ứng. Ví dụ, với chức năng cho mượn sách, bảng quyết định giúp liệt kê tất cả các tổ hợp điều kiện như "Có thẻ sinh viên", "Số lượng sách còn trong kho", "Số sách đang mượn", "Số lần quá hạn". Kỹ thuật Chuyển đổi trạng thái lại phù hợp với chức năng Đổi mật khẩu, nơi hệ thống có các trạng thái khác nhau (ví dụ: nhập sai mật khẩu lần 1, lần 2, sai quá 5 lần bị khóa). Việc áp dụng các kỹ thuật này đảm bảo các trường hợp kiểm thử được tạo ra một cách logic, có hệ thống, giảm thiểu việc bỏ sót các tình huống quan trọng.

4.2. Ví dụ test case cho chức năng đăng nhập và gia hạn tài liệu

Để minh họa, hãy xem xét test case cho chức năng đăng nhập. Các trường hợp được thiết kế bao gồm: (1) Mã số thẻ và Mật khẩu đều đúng - Kết quả mong đợi: Đăng nhập thành công. (2) Mã số thẻ đúng, Mật khẩu sai - Kết quả mong đợi: Thông báo lỗi. (3) Mã số thẻ sai, Mật khẩu đúng - Kết quả mong đợi: Thông báo lỗi. (4) Cả hai đều sai - Kết quả mong đợi: Thông báo lỗi. Đối với chức năng gia hạn tài liệu, các test case được xây dựng dựa trên các điều kiện như "Số lần đã gia hạn là 0", "Số lần đã gia hạn là 1", "Số lần đã gia hạn là 2 (tối đa)". Mỗi trường hợp đều có kết quả mong đợi rõ ràng về thông báo hiển thị và trạng thái của nút "Gia hạn". Những ví dụ này cho thấy cách một test plan mẫu được hiện thực hóa thành các bước kiểm tra cụ thể.

V. Kết quả thực tiễn từ kế hoạch kiểm thử website BUH

Giai đoạn thực thi và đánh giá là lúc một kế hoạch kiểm thử website thư viện chứng tỏ giá trị của nó. Dựa trên bộ test case đã thiết kế, quá trình kiểm thử được tiến hành một cách cẩn thận và kết quả được ghi nhận chi tiết. Kết quả tổng hợp cho thấy một bức tranh toàn cảnh về chất lượng của các chức năng được kiểm thử. Đáng chú ý, tất cả các test case được thực hiện cho bốn nghiệp vụ chính (Đăng nhập, Đổi mật khẩu, Gia hạn tài liệu, Cho mượn sách) đều cho kết quả "Pass", nghĩa là hoạt động đúng như mong đợi. Tỷ lệ thành công 100% cho các chức năng quan trọng này là một tín hiệu tích cực, cho thấy chất lượng mã nguồn ở mức tốt. Tuy nhiên, việc ghi nhận và báo cáo kết quả không chỉ dừng lại ở con số. Nó còn bao gồm việc tạo ra các tài liệu quan trọng như ma trận truy xuất và báo cáo tổng kết, làm cơ sở cho các hoạt động bảo trì và phát triển trong tương lai.

5.1. Báo cáo kiểm thử và ma trận truy xuất nguồn gốc

Một báo cáo kiểm thử (test report) chuyên nghiệp không thể thiếu bảng đánh giá kết quả. Theo tài liệu, tổng cộng có 21 test case đã được thực hiện cho 4 chức năng, với tỷ lệ Pass Rate đạt 100%. Bảng đánh giá chi tiết số lượng test case đạt/không đạt cho từng chức năng, cung cấp một cái nhìn định lượng rõ ràng. Bên cạnh đó, Ma trận truy xuất nguồn gốc (Traceability Matrix) được sử dụng để ánh xạ các yêu cầu (requirements) với các test case tương ứng. Ma trận này đảm bảo rằng không có yêu cầu nào bị bỏ sót trong quá trình kiểm thử. Ví dụ, yêu cầu "Req1: Đăng nhập" được bao phủ bởi 4 test case (TC01 đến TC04). Công cụ này cực kỳ hữu ích trong các dự án lớn để quản lý và đảm bảo độ bao phủ kiểm thử.

5.2. Đánh giá tỷ lệ thành công và quy trình quản lý lỗi

Tỷ lệ thành công 100% là một kết quả lý tưởng. Tuy nhiên, trong thực tế, việc phát hiện lỗi là không thể tránh khỏi. Một kế hoạch kiểm thử tốt phải có sẵn tiêu chí đình chỉ và kết thúc. Tài liệu đề xuất tiêu chí đình chỉ là khi "30% trường hợp thử nghiệm không thành công", lúc này việc kiểm thử sẽ tạm dừng để đội phát triển khắc phục lỗi. Tiêu chí kết thúc là "100% tất cả các trường hợp thử nghiệm quan trọng phải vượt qua". Mặc dù trong trường hợp này không phát hiện lỗi nào (không cần đến quy trình quản lý lỗi (bug tracking)), việc xác định trước các tiêu chí này cho thấy sự chuẩn bị kỹ lưỡng và chuyên nghiệp, sẵn sàng đối phó với mọi tình huống có thể xảy ra trong quá trình triển khai một đồ án tốt nghiệp kiểm thử phần mềm.

VI. Hướng phát triển cho kế hoạch kiểm thử website tương lai

Không có kế hoạch nào là hoàn hảo. Việc nhìn nhận các hạn chế và đề ra hướng phát triển trong tương lai là dấu hiệu của một nghiên cứu có giá trị thực tiễn. Kế hoạch kiểm thử website thư viện được trình bày trong tài liệu, dù đạt được những kết quả tích cực, vẫn còn những điểm có thể cải thiện. Việc chỉ tập trung vào kiểm thử thủ công và một số chức năng nhất định là một hạn chế về phạm vi. Hướng phát triển trong tương lai cần mở rộng quy mô kiểm thử, áp dụng các công cụ tự động để tăng hiệu suất và khám phá các loại kiểm thử phức tạp hơn như kiểm thử phi chức năng (non-functional testing). Những đề xuất này không chỉ giúp hoàn thiện website thư viện của trường mà còn là những kinh nghiệm quý báu cho các dự án phần mềm tương tự trong môi trường học thuật.

6.1. Hạn chế của đề tài và các bài học kinh nghiệm

Tác giả đã thẳng thắn nhìn nhận những hạn chế của đề tài. Thứ nhất, nghiên cứu chưa áp dụng được các công cụ kiểm thử tự động, vốn có thể tiết kiệm thời gian và công sức đáng kể, đặc biệt là trong kiểm thử hồi quy. Thứ hai, phạm vi kiểm thử còn hẹp, chưa bao phủ hết toàn bộ các chức năng của website, đặc biệt là các khía cạnh kiểm thử phi chức năng như hiệu năng và bảo mật. Cuối cùng, việc kiểm thử chỉ giới hạn trên một trình duyệt và hệ điều hành cụ thể. Bài học rút ra là một chiến lược kiểm thử toàn diện cần kết hợp cả kiểm thử thủ công và tự động, đồng thời phải mở rộng phạm vi ra nhiều nền tảng khác nhau để đảm bảo tính tương thích.

6.2. Đề xuất cải tiến quy trình và ứng dụng công cụ tự động

Hướng phát triển của đề tài rất rõ ràng và thiết thực. Tương lai của dự án này nên tập trung vào hai mảng chính. Một là, mở rộng quy mô kiểm thử trên một hệ thống phức tạp hơn, bao phủ toàn bộ các chức năng của website thư viện. Hai là, nghiên cứu và áp dụng các công cụ kiểm thử tự động như Selenium hoặc Katalon Studio. Việc tự động hóa các test case cho các chức năng ổn định như đăng nhập, tìm kiếm sẽ giải phóng thời gian của kiểm thử viên, cho phép họ tập trung vào các loại kiểm thử đòi hỏi sự sáng tạo và phân tích sâu hơn, chẳng hạn như kiểm thử khả năng sử dụng (usability testing) hoặc kiểm thử thăm dò. Đây là bước đi cần thiết để nâng cao chất lượng và sự chuyên nghiệp của quy trình kiểm thử phần mềm tại trường.

Nội dung chính

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

Thư viện trường đại học là cơ sở vật chất trọng yếu phục vụ công tác giảng dạy, học tập và nghiên cứu khoa học, góp phần nâng cao chất lượng giáo dục toàn diện. Tại Trường Đại học Ngân hàng TP. Hồ Chí Minh (HUB), thư viện sở hữu nguồn tài liệu phong phú với gần 80.000 bản tài liệu và hệ thống cơ sở dữ liệu điện tử đa dạng. Tuy nhiên, hoạt động quản lý thư viện truyền thống thủ công đòi hỏi chuỗi công việc phức tạp và tốn nhiều công sức của đội ngũ thủ thư. Việc tin học hóa thông qua website thư viện giúp người dùng dễ dàng tra cứu vị trí, trạng thái tài liệu, đồng thời tự thực hiện các nghiệp vụ như gia hạn mượn sách trực tuyến mọi lúc, mọi nơi. Để hệ thống vận hành thông suốt và đáp ứng tốt nhu cầu bạn đọc, hoạt động kiểm thử phần mềm đóng vai trò then chốt nhằm phát hiện và khắc phục các lỗi phát sinh trong quá trình sử dụng.

Xuất phát từ thực tiễn đó, tác giả Nguyễn Thị Trà My (sinh viên lớp DH36CDS02, MSSV 030236200085) đã thực hiện đồ án chuyên ngành ngành Hệ thống Thông tin Quản lý với đề tài: "Lập kế hoạch và thực hiện hoạt động kiểm thử cho website của thư viện Trường Đại học Ngân hàng", dưới sự hướng dẫn của giảng viên Hồ Thị Linh (hoàn thành ngày 28 tháng 04 năm 2023).

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

1. Nắm vững cơ sở lý thuyết tổng quan về quy trình, cấp độ và các phương pháp kiểm thử phần mềm.
2. Xác định các thông tin cơ bản về cấu trúc và các thành phần chức năng cần kiểm thử trên website thư viện.
3. Xác định các yêu cầu kỹ thuật và lựa chọn kỹ thuật thiết kế ca kiểm thử (Test Case) phù hợp.
4. Xây dựng bản kế hoạch kiểm thử chi tiết, ước lượng tài nguyên, chi phí và lịch trình thực hiện.
5. Thiết kế và thực thi các Test Case cho các chức năng trọng yếu gồm: Đăng nhập, Đổi mật khẩu, Gia hạn tài liệu và Cho mượn sách.

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

• Đối tượng nghiên cứu: Quy trình lập kế hoạch và hoạt động kiểm thử cho website Thư viện Trường Đại học Ngân hàng TP.HCM.
• Phạm vi nội dung: Đồ án tập trung nghiên cứu lý thuyết kiểm thử phần mềm và áp dụng phương pháp kiểm thử hộp đen thủ công để thiết kế Test Case cho 4 nghiệp vụ: Đăng nhập, Đổi mật khẩu, Gia hạn tài liệu và Cho mượn sách.
• Phạm vi loại trừ: Đồ án không thực hiện kiểm thử đối với các chức năng thông tin tĩnh hoặc xử lý đơn giản không có dữ liệu nhập phức tạp (Giới thiệu, Tin tức, Liên hệ, Sách mới, Hướng dẫn, Đảm bảo chất lượng, Lịch làm việc, Hỏi - Đáp), đồng thời không kiểm thử hiệu suất phần cứng và các hệ thống bên ngoài.

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

Đồ án xây dựng nền tảng nghiên cứu dựa trên các khái niệm và nguyên lý chuẩn mực trong kỹ thuật kiểm thử phần mềm:

• Khái niệm và mục tiêu kiểm thử: Kiểm thử phần mềm là quá trình thực hiện hoặc đánh giá một hệ thống/thành phần hệ thống bằng phương tiện thủ công hoặc tự động nhằm xác minh sự thỏa mãn các yêu cầu đặc tả, đánh giá mức độ chất lượng và phát hiện lỗi để ngăn ngừa rủi ro vận hành.
• Quy trình kiểm thử 5 bước: Bao gồm (1) Lập kế hoạch kiểm thử (Test Plan); (2) Thiết kế trường hợp kiểm thử (Test Case design); (3) Phát triển kịch bản kiểm thử (Test Script development); (4) Thực hiện kiểm thử (Test Execution); (5) Đánh giá quá trình kiểm thử và báo cáo kết quả.
• Cấp độ kiểm thử: Phân cấp theo 4 mức độ phát triển gồm Kiểm thử đơn vị (Unit Test), Kiểm thử tích hợp (Integration Test), Kiểm thử hệ thống (System Test) và Kiểm thử chấp nhận (Acceptance Test).
• Phương pháp kiểm thử:
  • Kiểm thử hộp đen (Black box testing): Kiểm thử hướng dữ liệu dựa trên bản đặc tả yêu cầu người dùng mà không cần can thiệp vào mã nguồn nội bộ.
  • Kiểm thử hộp trắng (White box testing): Kiểm thử dựa trên cấu trúc giải thuật và đường dẫn dòng lệnh bên trong mã nguồn.
  • Kiểm thử hộp xám (Gray box testing): Kết hợp giữa việc hiểu biết một phần cấu trúc bên trong để thiết kế ca kiểm thử và thực thi ở góc độ người dùng.
• Kỹ thuật thiết kế Test Case hộp đen được sử dụng:
  • Kỹ thuật Bảng quyết định (Decision Table Testing): Áp dụng cho các chức năng có nhiều điều kiện đầu vào kết hợp tạo ra các hành động đầu ra tương ứng.
  • Kỹ thuật Chuyển đổi trạng thái (State Transition Testing): Dựa vào sự thay đổi điều kiện đầu vào làm biến chuyển trạng thái xử lý của hệ thống.
  • Phân vùng tương đương và Phân tích giá trị biên: Dùng để xác định các lớp giá trị hợp lệ và không hợp lệ của các trường dữ liệu.

Phương pháp nghiên cứu thực tế được tác giả triển khai là kiểm thử thủ công (Manual Testing) theo phương pháp kiểm thử hộp đen. Quá trình tiếp cận hệ thống được củng cố nhờ trải nghiệm thực tế 3 năm học tập và sử dụng dịch vụ thư viện HUB của chính tác giả. Nguồn dữ liệu phục vụ nghiên cứu gồm tài liệu đặc tả nghiệp vụ thư viện, quy chế mượn trả của trường và hệ thống website thư viện thực tế tại địa chỉ https://library.hub.edu.vn.

Thiết kế và triển khai kế hoạch kiểm thử

Hoạt động kiểm thử được tổ chức có hệ thống thông qua các quy định cụ thể về môi trường, công cụ, phân công nhân sự và tiêu chí đánh giá chất lượng.

Môi trường và công cụ kiểm thử

• Môi trường phần cứng và phần mềm: Máy tính cá nhân có kết nối Internet; hệ điều hành Windows 10; trình duyệt web Google Chrome.
• Công cụ hỗ trợ:
  • Microsoft Office Word 2013: Sử dụng để soạn thảo tài liệu Kế hoạch kiểm thử (Test Plan).
  • Microsoft Office Excel 2013: Sử dụng để thiết kế, quản lý danh sách các Ca kiểm thử (Test Case) và ghi nhận kết quả.

Phân công vai trò và trách nhiệm

Họ và tên	Vai trò	Trách nhiệm chính
Nguyễn Thị Xuân Đào	Test Manager	Lập kế hoạch kiểm thử tổng thể, quản lý và theo dõi tiến độ hoạt động kiểm thử.
Nguyễn Thị Trà My	Test Designer	Thiết kế và viết các Test Case; sắp xếp mức độ ưu tiên và chuẩn bị dữ liệu kiểm thử (Test Data).
Nguyễn Thị Trà My	Tester	Trực tiếp thực thi Test Case cho 4 chức năng; đánh giá kết quả, viết báo cáo và phối hợp xử lý lỗi.

Lịch trình công việc

Hạng mục công việc	Sản phẩm bàn giao	Thời gian thực hiện
Lập kế hoạch kiểm thử	Tài liệu Test Plan	4 ngày
Đánh giá và xem lại tài liệu kế hoạch	Tài liệu Test Plan	4 ngày
Thiết kế các test case	Tài liệu Test Case	2 ngày
Viết chi tiết các test case	Tài liệu Test Case	4 ngày
Xem lại và chuẩn hóa test case	Tài liệu Test Case	2 ngày
Thực thi các test case trên website	Tài liệu Test Case	4 ngày
Ghi nhận và đánh giá kết quả kiểm thử	Báo cáo kiểm thử	2 ngày

Tiêu chí kiểm thử và quản lý rủi ro

• Tiêu chí thành công / thất bại: Ca kiểm thử thành công khi kết quả thực tế trùng khớp với kết quả mong đợi; thất bại khi kết quả thực tế khác biệt hoặc không xuất hiện phản hồi.
• Tiêu chí đình chỉ: Tạm dừng quá trình thử nghiệm khi có từ 30% số trường hợp kiểm thử bị thất bại để nhóm phát triển tiến hành sửa lỗi.
• Tiêu chí kết thúc: 100% các trường hợp thử nghiệm quan trọng phải được thực thi và đạt kết quả Pass.
• Biện pháp xử lý rủi ro: Chuẩn bị máy tính dự phòng để tránh lỗi hệ điều hành; tham khảo tài liệu chuyên môn trên các diễn đàn để bổ trợ kỹ năng công cụ; phân bổ lại khối lượng công việc khi thời gian thực tế vượt dự kiến.

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

Chương 1. Cơ sở lý luận

Chương này trình bày hệ thống hóa cơ sở lý thuyết về kiểm thử phần mềm. Tác giả phân tích chi tiết định nghĩa, mục tiêu (ngăn ngừa lỗi, đánh giá chất lượng, đáp ứng yêu cầu kỹ thuật và người dùng) và quy trình chuẩn 5 bước. Chương 1 làm rõ 4 cấp độ kiểm thử (Unit, Integration, System, Acceptance Test) cùng các kỹ thuật hộp đen, hộp trắng và hộp xám.

Bên cạnh đó, tác giả phân loại các hoạt động kiểm thử website chuyên biệt bao gồm: kiểm thử chức năng (liên kết, biểu mẫu form, cookie/session, cơ sở dữ liệu, HTML/CSS), kiểm thử bảo mật, khả năng sử dụng, tính tương thích trên trình duyệt/thiết bị, trải nghiệm giao diện máy chủ và kiểm thử hiệu suất. Chương 1 cũng chuẩn hóa cấu trúc của một Test Case hoàn chỉnh gồm 6 thành phần: Mã Test Case (ID), Mô tả mục đích (Description), Dữ liệu kiểm thử (Test Data), Các bước thực hiện (Test Steps), Kết quả mong muốn (Expected Result) và Kết quả thực tế (Test Result).

Chương 2. Mô tả hệ thống và phương pháp tiếp cận hệ thống

Chương 2 tập trung khảo sát thực trạng nghiệp vụ và cấu trúc của hệ thống thư viện HUB. Về mặt nghiệp vụ, hoạt động mượn sách diễn ra trực tiếp tại quầy thủ thư thông qua việc quét mã vạch thẻ sinh viên (kiểm tra hạn đào tạo, số lần nợ sách, số lần trễ hạn) và quét mã vạch sách (kiểm tra danh mục và số lượng khả dụng). Quy trình trả sách cũng được thủ thư quét mã vạch để ghi nhận, trường hợp trễ hạn hoặc hỏng sách sẽ bị xử phạt. Nghiệp vụ gia hạn được hỗ trợ thực hiện trực tuyến trên website thông qua tài khoản cá nhân.

Hệ thống phục vụ đa dạng nhóm đối tượng gồm: Sinh viên HUB, Học viên Cao học, Nghiên cứu sinh, Sinh viên ngoài HUB, Cán bộ viên chức và Người lao động của trường. Hệ thống phần mềm bao gồm 5 nhóm chức năng chính:

1. Đăng nhập: Xác thực người dùng qua Mã số thẻ và Mật khẩu.
2. Tra cứu tài liệu: Hỗ trợ 3 cấp độ tìm kiếm gồm Tìm cơ bản, Tìm nâng cao và Tìm chi tiết theo nhan đề, tác giả, môn học và tình trạng kho sách.
3. Mượn trả sách: Ghi nhận lịch sử và theo dõi trạng thái tài liệu.
4. Gia hạn thời gian mượn trả: Cho phép kéo dài thời gian mượn sách trực tuyến.
5. Cập nhật thông tin cá nhân: Đổi mật khẩu và chỉnh sửa thông tin người dùng.

Chương 3. Lập kế hoạch kiểm thử website thư viện đại học ngân hàng

Chương 3 xây dựng khung kế hoạch kiểm thử chi tiết cho website thư viện. Tác giả xác định phạm vi kiểm thử trọng tâm vào 4 nghiệp vụ: Đăng nhập, Đổi mật khẩu, Gia hạn tài liệu và Cho mượn sách; đồng thời phân định rõ các chức năng loại trừ không kiểm thử. Chương này thiết lập môi trường thử nghiệm trên hệ điều hành Windows 10 với trình duyệt Google Chrome, quy định công cụ Word/Excel 2013, phân định vai trò giữa Test Manager (Nguyễn Thị Xuân Đào), Test Designer và Tester (Nguyễn Thị Trà My), cùng lịch trình triển khai từng bước và các mốc kiểm soát rủi ro.

Chương 4. Thiết kế test case cho các chức năng của website

Chương 4 là phần trọng tâm triển khai thiết kế và thực thi các ca kiểm thử chi tiết:

• Chức năng Đăng nhập: Áp dụng kỹ thuật Bảng quyết định với các ràng buộc: Mã số thẻ có độ dài [5, 12] ký tự, Mật khẩu có độ dài [6, 15] ký tự chứa ký tự đặc biệt. Tác giả thiết kế 4 Test Case kiểm tra các tổ hợp đúng/sai của Mã số thẻ và Mật khẩu (TC01 đến TC04), kết hợp kiểm thử giao diện (UI) và bảo mật/phiên (phân biệt hoa thường, không lưu mật khẩu trong cookie, chặn copy-paste mật khẩu, xóa trắng trường khi refresh).
• Chức năng Đổi mật khẩu: Áp dụng kỹ thuật Chuyển đổi trạng thái với mô hình 8 trạng thái (từ S1 đến S8). Hệ thống cho phép người dùng nhập sai mật khẩu cũ tối đa 5 lần (S2 đến S6). Nếu nhập đúng ở bất kỳ lần nào, hệ thống chuyển sang trạng thái chấp nhận (S7). Nếu nhập sai liên tiếp 5 lần, hệ thống tự động khóa chức năng đổi mật khẩu trong 5 phút (S8). Tác giả thiết kế 6 kịch bản kiểm thử bao phủ toàn bộ cây chuyển đổi trạng thái.
• Chức năng Gia hạn tài liệu: Quy tắc nghiệp vụ quy định thời gian mượn sách ban đầu không quá 10 ngày; sinh viên được gia hạn tối đa 2 lần, mỗi lần cộng thêm 10 ngày; tổng thời gian mượn không vượt quá 30 ngày. Bảng quyết định gồm 8 tổ hợp được rút gọn thành 4 Test Case chính kiểm tra: gia hạn lần 1 (+10 ngày, nút gia hạn vẫn sáng), gia hạn lần 2 (+10 ngày, nút gia hạn mờ đi/vô hiệu hóa), và trạng thái nút bấm sau các lần gia hạn.
• Chức năng Cho mượn sách: Kiểm tra 4 điều kiện nghiệp vụ đồng thời: (a) Có thẻ sinh viên hợp lệ; (b) Sách cần mượn có số lượng khả dụng trong thư viện (> 0); (c) Số lượng sách hiện đang giữ không vượt quá 2 cuốn (để mượn tối đa 3 cuốn); (d) Số lần quá hạn trả sách không vượt quá 5 lần. Tác giả thiết kế bảng quyết định 16 cột tổ hợp, xây dựng 8 Test Case (TC1 kiểm thử cho mượn khi thỏa 4 điều kiện; TC2 đến TC5 kiểm thử từ chối mượn khi vi phạm từng điều kiện đơn lẻ; TC6 đến TC8 kiểm thử số lượng sách tối đa được mượn thêm là 3, 2, 1 tương ứng với số sách hiện đang giữ là 0, 1, 2 cuốn).
• Ma trận truy xuất nguồn gốc (Traceability Matrix): Thiết lập mối liên kết giữa các yêu cầu chức năng (Req1 đến Req4) với toàn bộ 21 Test Case, đảm bảo tính bao phủ đầy đủ các yêu cầu đặc tả.

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

Kết quả định lượng

Đồ án đã thực hiện kiểm thử thành công trên toàn bộ 4 phân hệ chức năng với các chỉ số định lượng cụ thể:

Phân hệ chức năng	Số Test Case đạt (Pass)	Số Test Case không đạt (Fail)	Tổng số Test Case	Tỷ lệ đạt (Pass Rate)
Đăng nhập	4	0	4	100%
Đổi mật khẩu	5	0	5	100%
Gia hạn tài liệu	4	0	4	100%
Cho mượn sách	8	0	8	100%
Tổng cộng toàn hệ thống	21	0	21	100%

Các chỉ số thực thi tổng hợp của đợt kiểm thử:

• Tổng số Test Case đã thực hiện: 21 Test Case.
• Tỷ lệ thực thi (Run rate): Đạt 95,23% (tương ứng 20 Test Case ghi nhận vận hành đầy đủ các bước thực tế).
• Tỷ lệ vượt qua (Pass rate): Đạt 100% trên các ca thử nghiệm hợp lệ.
• Căn cứ theo các tiêu chí đã đề ra, website thư viện HUB đáp ứng đầy đủ điều kiện kết thúc kiểm thử.

Đóng góp của đề tài

1. Chuẩn hóa tài liệu kiểm thử: Xây dựng bộ tài liệu Kế hoạch kiểm thử (Test Plan) và biểu mẫu Ca kiểm thử (Test Case) chi tiết, khoa học, có thể áp dụng trực tiếp cho việc quản lý chất lượng các cổng thông tin thư viện đại học.
2. Ứng dụng phương pháp luận chặt chẽ: Hiện thực hóa các kỹ thuật kiểm thử hộp đen nâng cao (Bảng quyết định và Sơ đồ chuyển đổi trạng thái) vào giải quyết các bài toán nghiệp vụ thực tế có nhiều điều kiện ràng buộc phức tạp như cho mượn và gia hạn sách.
3. Đánh giá tính sẵn sàng của hệ thống: Cung cấp cơ sở dữ liệu kiểm nghiệm thực tế chứng minh website thư viện HUB vận hành chính xác các quy tắc nghiệp vụ cốt lõi và đảm bảo an toàn phiên làm việc của người dùng.

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

Hạn chế

• Hoạt động kiểm thử hoàn toàn sử dụng phương pháp thủ công (Manual Testing), chưa áp dụng các công cụ kiểm thử tự động (Automation Testing) như Selenium hay JMeter để kiểm tra hồi quy và hiệu năng tải.
• Phạm vi kiểm thử mới chỉ tập trung vào 4 chức năng chính (Đăng nhập, Đổi mật khẩu, Gia hạn tài liệu, Cho mượn sách), chưa mở rộng bao phủ toàn bộ các phân hệ và liên kết khác trên website thư viện.

Hướng nghiên cứu tiếp

• Mở rộng quy mô và độ phức tạp của các ca kiểm thử trên toàn bộ các phân hệ của website thư viện.
• Nghiên cứu và tích hợp các công cụ kiểm thử tự động nhằm nâng cao hiệu suất kiểm tra và hỗ trợ kiểm thử cơ sở dữ liệu chuyên sâu.

Giá trị tham khảo

Tài liệu đồ án là nguồn tham khảo hữu ích cho:

• Sinh viên chuyên ngành Hệ thống Thông tin Quản lý, Công nghệ Thông tin, Kỹ thuật Phần mềm đang học tập các học phần Đảm bảo chất lượng phần mềm (QA/QC) và Kiểm thử phần mềm.
• Kiểm thử viên và sinh viên thực hiện khóa luận tốt nghiệp cần mẫu tham khảo chuẩn mực về cách lập Kế hoạch kiểm thử (Test Plan), thiết kế Ma trận truy xuất nguồn gốc (Traceability Matrix) và kỹ thuật xây dựng Test Case bằng Bảng quyết định và Sơ đồ chuyển đổi trạng thái.
• Bộ phận quản trị hệ thống thư viện các trường đại học tham khảo quy trình nghiệp vụ và các tiêu chí kiểm soát chất lượng phần mềm mượn trả trực tuyến.

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

1. Quy tắc và giới hạn gia hạn tài liệu trên website Thư viện HUB được quy định như thế nào?

Sinh viên có thời gian mượn ban đầu không quá 10 ngày. Mỗi tài liệu được phép gia hạn trực tuyến tối đa 2 lần, mỗi lần cộng thêm 10 ngày vào hạn trả. Tổng thời gian mượn tối đa cho một cuốn sách không vượt quá 30 ngày tính từ ngày mượn đầu tiên. Sau khi gia hạn đủ 2 lần, nút chức năng gia hạn trên giao diện sẽ tự động mờ đi (vô hiệu hóa).

2. Những điều kiện bắt buộc để sinh viên được phép mượn sách tại thư viện là gì?

Sinh viên phải thỏa mãn đồng thời 4 điều kiện: (1) Có thẻ sinh viên hợp lệ và còn trong thời gian đào tạo; (2) Đầu sách cần mượn có số lượng khả dụng trong kho lớn hơn 0; (3) Số lượng sách hiện đang mượn không vượt quá 2 cuốn (tổng số sách mượn tối đa là 3 cuốn); (4) Số lần trả sách quá hạn trước đó không vượt quá 5 lần.

3. Kỹ thuật Chuyển đổi trạng thái được áp dụng cho chức năng Đổi mật khẩu như thế nào?

Kỹ thuật này mô hình hóa hành vi hệ thống qua 8 trạng thái (S1 đến S8). Người dùng được phép thử lại mật khẩu cũ tối đa 5 lần. Nếu nhập đúng ở bất kỳ lần nào, hệ thống chuyển sang trạng thái cấp quyền đổi mật khẩu (S7). Nếu nhập sai liên tiếp 5 lần, hệ thống sẽ kích hoạt trạng thái S8, tự động khóa chức năng Đổi mật khẩu trong thời gian 5 phút để bảo vệ tài khoản.

4. Tiêu chí đình chỉ và kết thúc kiểm thử trong đồ án được xác lập ra sao?

Quá trình kiểm thử sẽ bị đình chỉ (tạm ngừng) nếu tỷ lệ ca kiểm thử không thành công đạt từ 30% tổng số trường hợp kiểm tra, nhằm chuyển giao cho nhóm phát triển khắc phục lỗi. Quá trình kiểm thử chính thức kết thúc khi 100% tất cả các trường hợp thử nghiệm quan trọng đều vượt qua (Pass).

5. Kết quả thực thi các ca kiểm thử đạt tỷ lệ bao nhiêu?

Tổng cộng 21 Test Case đã được thiết kế và thực thi cho 4 chức năng. Toàn bộ 21 Test Case đều đạt kết quả Pass (tỷ lệ đạt 100%), tỷ lệ thực thi đạt 95,23% (20 Test Case ghi nhận đầy đủ kịch bản vận hành), đáp ứng trọn vẹn tiêu chí kết thúc kiểm thử của đồ án.

Kết luận

Đồ án chuyên ngành của tác giả Nguyễn Thị Trà My đã hoàn thành xuất sắc mục tiêu nghiên cứu lý luận kiểm thử phần mềm và triển khai kế hoạch kiểm thử thực tế cho website Thư viện Trường Đại học Ngân hàng TP.HCM. Thông qua việc ứng dụng chuẩn mực kỹ thuật Bảng quyết định và Chuyển đổi trạng thái, tác giả đã thiết kế và thực thi thành công 21 Test Case cho 4 nghiệp vụ cốt lõi với tỷ lệ đạt 100%. Công trình là tài liệu thực hành hoàn chỉnh về quy trình kiểm thử hộp đen thủ công, đồng thời tạo tiền đề thuận lợi cho việc mở rộng nghiên cứu sang lĩnh vực kiểm thử tự động trong tương lai.

Trích đoạn nội dung tài liệu

Chương 1.1 Tổng quan về kiểm thử phần mềm 1.1 Kiếm thử phần mềm là gì? Kiểm thử là quá trình thực hiện hoặc đánh giá một hệ thống hoặc thành phần hệ thông bằng phương tiện thủ công hoặc tự động để xác minh rằng nó đáp ứng các yêu cầu được chỉ định. Quá trình bao gồm tất cả các hoạt động vòng đời, cá hoạt động tĩnh và năng động, quan tâm đến việc lập kế hoạch, chuẩn bị và đánh giá các sản phẩm phần mềm và các sản phẩm công việc liên quan để xác định rằng chúng đáp ứng các yêu cầu cụ thẻ, để chứng minh rằng chúng phù hợp với mục đích và để phát hiện ra lỗi.2 Mục tiêu của kiểm thử phần mềm: Kiểm thử phần mềm thực hiện một chương trình với mục đích tìm lỗi. Đẻ: (1 Xác định xem hệ thông có đáp ứng các thông sô kỹ thuật hay không. (1 Xác định xem hệ thông có đáp ứng được nhu cầu của người dùng hay không.

E1 Có được sự tự tin và cung cấp thông tin về mức độ chất lượng. Ì Ngăn ngừa lỗi.2 Quy trình kiếm thử phần mềm: gồm có 5 bước 1.1 Lập kết hoạch Nhằm chỉ định và mô tả các loại kiêm thử sẽ được triển khai và thực hiện. Kết quả là bản kế hoạch kiểm thử phần mềm bao gồm chỉ tiết từ các loại kiểm thử, chiến lược kiểm thử, cho đến thời gian và phân định lực lượng kiểm thử viên. Các bước lập kế hoạch kiểm thử: EÌ Xác định yêu cầu kiểm thử: Xác định những gi cần phái kiểm thử dựa theo yêu cầu từ khách hàng, đặc tả yêu cầu người sử dụng.

(1 Xác định các chiến lược kiểm thử: Xác định phương thức, loại kiểm thử cần thực hiện và tiêu chí đầu ra. (| Xác đmh tài nguyên, môi trường: Xác định nguồn nhân lực và môi trường thực hiện kiểm thử (số lượng người, yêu cầu về phần cứng, phần mềm, công cụ hỗ trợ. Lập thời gian cho các giai đoạn kiểm thử: Đánh giá kế hoạch: Trưởng dự án sẽ cùng những người liên quan tham gia đánh giá xem bán kế hoạch kiểm thử có phù hợp với yêu cầu dự án chưa. Nếu chưa thì sẽ phải thực hiện sửa lại theo yêu cầu.

LK Thông báo tới các bên liên quan: Trưởng dự án sẽ gửi thông báo toàn bộ những người trong dự án có liên quan đến kế hoạch kiêm thử.2 Thiết kế test case (thiết kế trường hợp kiểm thử) Nhằm chỉ định các test case và các bước kiêm tra chỉ tiết cho mỗi phần mềm. Giai đoạn thiết kế test case là hết sức quan trọng, nó đám báo các tình huống kiểm thử bao phủ tất cả các yêu cầu. Phát triển test script Bước này thường không bắt buộc trong các loại và mức kiêm thử, chí yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các test script có khá năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở các bước thiết kế kiểm thử.4 Thực hiện kiếm thử Mục đích thực hiện kiểm tra các bước đã thiết kế và ghi nhận kết quả. Các bước thực hiện kiểm thử: :J Thiết lập môi trường và cài đặt: Dé thực hiện kiểm thử, thao tác đầu tiên cần làm là xác lập và khởi động môi trường kiêm thử.

Việc này nhằm dam bao tat ca các bộ phận liên quan (phần cứng, phan mém, máy chủ, mạng, dữ liệu. ) đã được cài đặt và sẵn sàng trước khi chính thức bắt đầu thực hiện kiêm thử. E1 Tiên hành kiêm thử theo các trường hợp kiêm thử đã chuẩn bị. O Thâm định kết quá kiêm thử: Sau khi tiễn hành kiểm thử, kết quá kiểm thử cần được xem xét đê đảm bảo kết quả nhận được là đáng tin cậy.