Kiểm tra mô-đun là gì? Định nghĩa, ví dụ

Kiểm tra mô-đun là gì?

thử nghiệm mô-đun Kiểm thử mô-đun là một loại kiểm thử phần mềm kiểm tra các chương trình con, hàm con, lớp hoặc thủ tục riêng lẻ trong một chương trình. Thay vì kiểm thử toàn bộ chương trình phần mềm cùng một lúc, kiểm thử mô-đun khuyến nghị kiểm thử các khối cấu tạo nhỏ hơn của chương trình.

Kiểm thử mô-đun chủ yếu dựa trên phương pháp kiểm thử hộp trắng. Mục tiêu của kiểm thử mô-đun không phải là chứng minh mô-đun hoạt động đúng cách, mà là chứng minh sự hiện diện của lỗi trong đó. Sự đảo ngược này rất quan trọng: một lần chạy không tìm thấy gì chỉ xác nhận được rất ít thông tin, trong khi một lần chạy phát hiện ra lỗi đã hoàn thành nhiệm vụ của nó.

Kiểm thử ở cấp độ mô-đun cũng cho phép đưa tính song song vào quy trình kiểm thử, vì nó tạo cơ hội để kiểm thử nhiều mô-đun cùng lúc thay vì phải chờ quá trình biên dịch hoàn tất.

Tại sao phải thực hiện Kiểm tra mô-đun

Việc kiểm thử theo từng mô-đun được khuyến nghị vì nó thay đổi chi phí phát hiện lỗi.

• Xác suất phát hiện lỗi hoặc sự cố trong các phần nhỏ của chương trình sẽ cao hơn.
• Nhiều mô-đun có thể được kiểm tra đồng thời, do đó phương pháp này hỗ trợ kiểm thử song song.
• Độ phức tạp của việc kiểm thử có thể được quản lý dễ dàng, vì mỗi mô-đun được xử lý riêng biệt.
• Một lỗi được phát hiện bên trong một mô-đun là tracCó thể xử lý một lượng mã nhỏ, do đó thời gian gỡ lỗi giảm đáng kể.

Làm cách nào để thực hiện Kiểm tra mô-đun?

Thiết kế một trường hợp thử nghiệm Đây là phần quan trọng của việc kiểm thử mô-đun. Khi thiết kế các trường hợp kiểm thử cho một mô-đun, người kiểm thử phải xem xét hai điều.

• Đặc điểm kỹ thuật cho mô-đun
• Mã nguồn của mô-đun

Phân tích logic của mô-đun bằng cách sử dụng một hoặc nhiều phương pháp sau: hộp trắng các phương pháp, và sau đó bổ sung các trường hợp thử nghiệm này bằng cách áp dụng hộp đen các phương pháp cho đặc tả mô-đun. Các giá trị thực tế cũng quan trọng như các đường dẫn được chọn, vì vậy hãy chuẩn bị dữ liệu thử nghiệm Cùng với các vụ việc chứ không phải sau đó.

Sau khi thiết kế xong các trường hợp thử nghiệm, bước tiếp theo là kết hợp các mô-đun để thử nghiệm. Phương pháp được sử dụng là một trong hai cách sau: gia tăng hoặc một không tăng dần phương pháp.

• Phương pháp không gia tăng — Tất cả các mô-đun đều được kiểm tra độc lập. Đầu tiên, nó kết hợp tất cả các mô-đun lại với nhau, sau đó kiểm tra toàn bộ chương trình.
• Phương pháp tăng dần — Mỗi mô-đun được kiểm tra trước tiên và sau đó được thêm dần vào bộ sưu tập đã được kiểm thử. Quá trình này thực hiện kiểm thử lại từng bước.
• Trong kiểm thử gia tăng, có hai cách tiếp cận, từ trên xuống và từ dưới lên thử nghiệm.
• Để chạy mô-đun với dữ liệu đã chọn, cần có một trình điều khiển để cung cấp dữ liệu thử nghiệm, giám sát quá trình thực thi và thu thập kết quả.

Việc lựa chọn giữa hai phương pháp này là sự đánh đổi giữa nỗ lực thiết lập và khả năng chẩn đoán.

Trình điều khiển và các đối tượng giả lập trong kiểm thử mô-đun

Trình điều khiển được đề cập ở trên là một nửa của một cặp. Bởi vì một mô-đun đang được kiểm thử hiếm khi nằm ở đầu hoặc cuối chuỗi gọi hàm, nên người kiểm thử sẽ thay thế mã giả cho bất kỳ phần nào còn thiếu ở hai phía của nó.

• Người lái xe — thay thế mô-đun gọi nằm phía trên mô-đun đang được kiểm thử. Nó cung cấp dữ liệu kiểm thử, gọi mô-đun, giám sát quá trình thực thi và thu thập kết quả. Kiểm thử từ dưới lên phụ thuộc vào các trình điều khiển, bởi vì các mô-đun bên dưới đã sẵn sàng trước các mô-đun bên trên.
• Stub — Thay thế một mô-đun được gọi nằm bên dưới mô-đun đang được kiểm thử. Nó chấp nhận cuộc gọi và trả về một phản hồi cố định, đã biết để mô-đun đang được kiểm thử có thể hoàn thành đường dẫn của nó. Kiểm thử từ trên xuống phụ thuộc vào các stub, vì các mô-đun cấp cao hơn đã sẵn sàng trước.

Một trường hợp cụ thể đã được xử lý giúp việc ghép nối trở nên rõ ràng hơn. Nếu một mô-đun tính toán thanh toán đã hoàn tất trong khi màn hình thanh toán gọi nó thì chưa, một trình điều khiển sẽ cung cấp cho mô-đun một tập hợp các tổng giá trị đơn hàng và ghi lại kết quả trả về. Nếu dịch vụ tra cứu thuế mà mô-đun gọi cũng chưa hoàn tất, một đoạn mã giả sẽ trả về một mức thuế cố định để quá trình tính toán vẫn tiếp tục. Cả hai phần khung sườn này đều không được đóng gói; cả hai đều bị loại bỏ khi các mô-đun thực sự được đưa vào sử dụng, đó là lý do tại sao việc hiểu sai về các mô-đun giả được liệt kê sau này như một thách thức thường xuyên.

Lời khuyên mẫu cho việc kiểm tra mô-đun

Dưới đây là một vài lời khuyên cần xem xét trước khi thực hiện kiểm thử mô-đun.

• RevHãy xem xét các trường hợp thử nghiệm trước khi sử dụng chúng.
• Tránh nhầm lẫn về nguồn gốc của sự khác biệt.
• Sử dụng các công cụ kiểm thử tự động.
• Kiểm tra các biến số không nên thay đổi.
• Hoán đổi các mô-đun giữa những người kiểm thử để tránh tự kiểm thử.
• Tái sử dụng các trường hợp kiểm thử.

Lời khuyên thứ năm có tầm quan trọng hơn nhiều so với độ dài của nó. Một lập trình viên chỉ kiểm thử mô-đun vừa viết xong sẽ lặp lại những giả định đã gây ra lỗi, vì vậy việc luân chuyển các mô-đun giữa những người khác nhau là một trong những cách nâng cao chất lượng tiết kiệm nhất.

Kiểm tra đơn vị và kiểm tra mô-đun

Hai thuật ngữ này được sử dụng thay thế cho nhau trong nhiều nhóm, tuy nhiên quyền tác giả và phạm vi áp dụng lại khác nhau.

Kiểm thử mô-đun so với kiểm thử thành phần so với kiểm thử tích hợp

Kiểm thử mô-đun cũng nằm cạnh hai cấp độ khác dễ bị nhầm lẫn với nó. Bảng này phân tách chúng dựa trên nội dung được kiểm thử và người thường thực hiện việc kiểm thử.

Trong sử dụng hàng ngày kiểm tra thành phần và kiểm thử mô-đun thường được coi là cùng một hoạt động, trong khi Thử nghiệm hội nhập Quá trình chỉ bắt đầu khi mỗi mô-đun riêng lẻ đều đã hoàn thành và vượt qua một cách độc lập.

Những thách thức trong thử nghiệm mô-đun

Đây là những thách thức mà các nhóm thường gặp phải nhất khi triển khai kiểm thử mô-đun.

• Thử nghiệm không gia tăng đòi hỏi nhiều công việc hơn — Việc kết hợp mọi thứ trước tiên có nghĩa là chỉ một lỗi nhỏ cũng có thể khiến người kiểm thử phải quay lại toàn bộ chương trình.
• Kiểm tra sự hiểu lầm tăng gấp đôi — Một đoạn mã giả trả về giá trị không thực tế sẽ tạo ra kết quả màu xanh lá cây nhưng không chứng minh được điều gì.
• Việc gỡ lỗi các bài kiểm tra thường xuyên — Mã khung sườn có những lỗi riêng, và thời gian dành để sửa lỗi trình điều khiển là thời gian không được dành để kiểm tra mô-đun.
• Cần phải hiểu mã — Cách bố trí hộp trắng có nghĩa là người kiểm thử không thể đọc hiểu mô-đun sẽ không thể thiết kế các trường hợp sử dụng có ý nghĩa cho nó.

Câu Hỏi Thường Gặp