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

Tài liệu nghiên cứu 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, tổng hợp lý thuyết và thực hành, cung cấp kiến thức chuyên sâu

Người đăng

Ẩn danh
68
2
0

Phí lưu trữ

30 Point

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.

Tóm tắt và mô tả trên trang này được tạo với sự hỗ trợ của AI. Nếu bạn thấy nội dung không chính xác hoặc có vấn đề, vui lòng Báo lỗi nội dung.

11/07/2025

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.

Nhận biết được 4 những lỗi không phải do phần mềm mà do dữ liệu dùng đề kiểm thử, môi trường kiêm thử, hoặc các bước kiêm thử gây ra. Nếu thực sự lỗi xáy ra do quá trình kiêm thử, cần phải sửa chữa và kiểm tra lại từ đầu.5 Đánh giá quá trình kiếm thử Bao gồm xem xét và đánh giá kết quá kiêm thử lỗi, chỉ định các yêu cầu thay đôi và tính toán số liệu liên quan đến quá trình kiểm thử (chăng hạn số giờ, thời gian kiểm tra, số lượng lỗi.) Các bước đánh giá quá trình kiểm thử: C1 Thống kê số lượng lỗi. O Phân tích kết quả kiểm thử và yêu cầu sửa chữa: Chỉ định và đánh giá sự khác biệt giữa kết quả mong đợi và kết quả thực tế, tống hợp và gửi thông tin yêu cầu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để kiểm tra sau đó. O Đánh giá chất lượng sản phẩm kiêm thử: Từ những kết quả kiểm thử, nhóm kiêm thử sẽ xem xét, đánh giá chất lượng sản phẩm.

LÌ Thông báo tới các bên liên quan: Trưởng dự án sẽ thông báo cho các bên liên quan về kết quá kiểm thử đạt được.3 Các cấp độ kiểm thứ phần mềm Kiểm thử phần mềm gồm có 4 cấp độ: Unit test (Kiểm thử đơn vị), Integration Tests (Kiém thir tich hop), System Tests (Kiém thir hé thong) va Acceptance Tests (Kiém thir chấp nhận). Tùy theo yêu cầu và đặc trưng của từng hệ thống, khá năng và thời gian cho phép của dự án, khi lập kế hoạch, người quản lý dự án sẽ quyết định những loại kiểm thử được sử dụng.1 Unit Test (Kiểm thử đơn vị) Unit (Đơn vị) là một thành phần phần mềm nhỏ nhất có thê kiêm thử được. Các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit. Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, vi vậy thường không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiêm thử.

Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc 5 phục cũng tương đổi đễ dàng vì chỉ khoanh vùng trong một đơn vị đang kiêm tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chỉ phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó. Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm.

Thông thường, Unit Test đòi hỏi kiêm thử viên có kiến thức về thiết kế và code của chương trình. Mục đích của kiêm thử đơn vị là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của đơn vị. Điều này thường đòi hỏi tất cả các nhánh bên trong unit đều phải được kiêm tra dé phat hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một unit.

Thực tế việc chọn lựa các nhánh đề đơn giản hóa việc kiêm thử và bao phủ hết unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán đề chọn lựa. Cùng với các mục kiêm thử khác, unit test cũng đòi hỏi phái chuẩn bị trước test case (ca kiêm thử) hoặc test seript (kịch bán kiêm thử), trong đó chí định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các test case và test script này nên được giữ lại đề tái sử dụng. (Nguồn: https://timoday.vn/tong-quan-ve-kiem-thu-phan-mem-2/, 2020) 1.2 Integration Test (Kiém thir tich hop) Integration test là kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thiện.

Trong khi unit test kiêm tra các thành phần và đơn vị riêng lẻ thì integration test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. Hai muc tiéu chinh cua integration test: CO Phát hiện lỗi giao tiếp xảy ra giữa các unit. L1 Tích hợp các unit đơn lẻ thành các hệ thông nhỏ và cuối cùng là nguyên hệ thông hoàn chỉnh chuẩn bị cho kiêm thử ở mức hệ thống. Trong unit test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cầu trúc nội tại của unit.

Có một số phép kiểm thử đơn giản trên giao tiếp giữa unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự được kiểm tra đầy đủ khi các unit tích hợp với nhau trong khi thực hiện kiêm thử tích hợp. Trừ một số ít ngoại lệ, integration test chỉ nên thực hiện trên những umt đã được kiểm tra cân thận trước đó bằng unit test, va tat cả các lỗi mức unit đã được sửa chữa. (Nguồn: https://timoday.vn/tong-quan-ve-kiem-thu-phan-mem-2/, 2020) 1. System Test (Kiểm thử hệ thống) System test là một phương pháp theo dõi và đánh giá hành vi của sản phẩm hoặc hệ thống phần mềm hoàn chính và đã được tích hợp đầy đủ, dựa vào đặc tả và các yêu cầu chức năng đã được xác định trước.

System test bắt đầu khi tất cá các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thông, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thông.

Điểm khác nhau then chốt giữa integration test và system test là system test chú trọng các hành vi và lỗi trên toàn hệ thống, còn integration test chú trọng sự giao tiếp giữa các unit hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường, unit test và integration test cần phải thực hiện trước để bảo đảm mọi unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện system test. Sau khi hoàn thành integration test, mdt hé thong phan mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiêm thử viên bắt đầu kiểm thử phần mềm như một hệ thông hoàn chỉnh.

Việc lên kế hoạch cho system test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. System test thực hiện kiểm thử cá các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiêm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chăng hạn các lỗi “tắc nghẽn” hoặc chiếm dụng bộ nhớ.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ