1. Unit testing - Kiểm thử thành phần/đơn vị
Unit testing đề cập đến các kiểm thử để chứng thực (xác minh - verify) chức năng của một phần riêng biệt của code, thường ở mức hàm (function level). Trong một môi trường hướng đối tượng (object-oriented environment), kiểm thử đơn vị thường được sử dụng ở mức lớp (class) và kiểm thử các đơn vị nhỏ nhất bao gồm các hàm constructor và destructor.
Loại kiểm thử này thường được viết bởi các DEV như công việc của họ trong việc code (loại test white-box), để bảo đảm rằng từng hàm riêng biệt hoạt động đúng theo mong muốn. Một hàm có thể có nhiều kiểm thử, để bắt được các trường hợp hoặc các nhánh trong code. Unit testing một mình không thể bảo đảm chức năng của một bộ phận của phần mềm mà là sử dụng để bảo đảm rằng các khối kiến trúc của phần mềm làm việc độc lập với nhau.
Unit testing (kiểm thử đơn vị) cũng được gọi là component testing (kiểm thử thành phần).
2. Integration testing - Kiểm thử tích hợp (đơn vị)
Integration testing là một loại kiểm thử phần mềm mà tìm kiếm để kiểm tra các giao diện giữa các thành phần dựa vào thiết kế của phần mềm. Các thành phần phần mềm có thể được tích hợp lại với nhau theo cách lặp đi lặp lại (từng phần nhỏ ghép lại với nhau, rồi ghép tiếp phần nhỏ khác vào nữa, hành động này lặp lại cho đến khi kết hợp toàn bộ phần mềm) hoặc tất cả các thành phần cùng tích hợp một lần (gọi là “big bang”). Thông thường trước đây được xem là một cách làm tốt hơn từ khi nó cho phép các vấn đề về giao diện được xác định vị trí nhanh hơn và cố định.
Integration testing làm việc để tìm ra lỗi (defect) trong các giao diện và giao tiếp giữa các thành phần (mô-đun). Các nhóm thành phần phần mềm đã được kiểm thử lớn dần từng bước tương ứng với các yếu tố của thiết kế kiến trúc đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống.
3. System testing - Kiểm thử hệ thống
System testing kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu.
Kiểm thử tích hợp hệ thống chứng thực rằng hệ thống đã được tích hợp với các hệ thống bên ngoài hoặc hệ thống thứ ba đã được xác định trong các yêu cầu hệ thống.
4. Regression testing - Kiểm thử hồi qui
Regression testing tập trung vào việc tìm kiếm lỗi sau khi xảy ra việc thay đổi code. Đặc biệt, nó tìm kiếm theo cách hồi qui (đệ qui) hoặc kiểm tra các bug cũ có bị lại hay không. Hồi qui như vậy xảy bất cứ khi nào mà chức năng phần mềm trước đây làm việc đúng đã ngưng làm việc theo mong đợi. Điển hình, hồi qui xảy ra như là một kết quả không mong muốn của việc thay đổi chương trình, khi phần code của phần mềm mới được phát triển xung độ với code cũ đang có. Phương pháp thông thường của kiểm tra hồi quy là bao gồm việc chạy lại các kiểm thử trước đây và kiểm tra xem có lỗi đã được fixed trước đây bị lỗi lại (bị lại các lỗi cũ đã fixed rồi). Độ sâu của việc kiểm thử phụ thuộc vào các giai đoạn trong quá trình phát hành và rủi ro của các tính năng được thêm vào. Chúng có thể được hoàn thành – vì việc thay đổi đã thêm vào sau bản phát hành hoặc coi nó là mạo hiểm, rất hời hợt, bao gồm các kiểm thử trường hợp đúng (positive) trên từng chức năng – nếu các thay đổi được thêm vào trước khi phát hành hoặc coi nó ít rủi ro.
T3H chúc các bạn học tốt Testing
0 nhận xét:
Đăng nhận xét