Có ai có thể xác định rõ ràng các cấp độ kiểm thử này không vì tôi thấy rất khó để phân biệt khi làm TDD hoặc kiểm thử đơn vị. Xin vui lòng nếu bất cứ ai có thể giải thích làm thế nào, khi nào để thực hiện những điều này?
Câu trả lời:
Tóm tắt:
Kiểm tra đơn vị - Bạn kiểm tra từng đoạn mã riêng lẻ. Suy nghĩ từng tệp hoặc lớp.
Kiểm thử tích hợp - Khi đặt một số đơn vị tương tác với nhau, bạn cần phải tiến hành kiểm thử Tích hợp để đảm bảo rằng việc tích hợp các đơn vị này với nhau không gây ra bất kỳ lỗi nào.
Kiểm thử hồi quy - sau khi tích hợp (và có thể sửa), bạn nên chạy lại các kiểm thử đơn vị của mình. Đây là thử nghiệm hồi quy để đảm bảo rằng các thay đổi tiếp theo không phá vỡ bất kỳ đơn vị nào đã được thử nghiệm. Kiểm thử đơn vị bạn đã thực hiện đã tạo ra các kiểm thử đơn vị có thể chạy đi chạy lại để kiểm tra hồi quy.
Kiểm tra chấp nhận - khi người dùng / khách hàng / doanh nghiệp nhận được chức năng, họ (hoặc bộ phận kiểm tra của bạn) sẽ tiến hành kiểm tra chấp nhận để đảm bảo rằng chức năng đáp ứng yêu cầu của họ.
Bạn cũng có thể muốn điều tra thử nghiệm hộp trắng và hộp đen. Ngoài ra còn có kiểm tra hiệu suất và tải cũng như kiểm tra "'ưu điểm" cần xem xét.
Kiểm tra đơn vị: khi nó không thành công, nó sẽ cho bạn biết đoạn mã nào của bạn cần được sửa.
Kiểm tra tích hợp: khi nó không thành công, nó cho bạn biết rằng các phần của ứng dụng của bạn không hoạt động cùng nhau như mong đợi.
Kiểm tra chấp nhận: khi nó không thành công, nó cho bạn biết rằng ứng dụng đang không làm những gì khách hàng mong đợi.
Kiểm tra hồi quy: khi nó không thành công, nó cho bạn biết rằng ứng dụng không còn hoạt động như trước đây nữa.
Dưới đây là lời giải thích đơn giản cho từng thử nghiệm được đề cập và khi nào chúng được áp dụng:
Kiểm thử đơn vị Kiểm thử đơn vị được thực hiện trên một đơn vị độc lập (thường là một lớp hoặc phương pháp) và nên được thực hiện bất cứ khi nào một đơn vị đã được thực hiện hoặc cập nhật một đơn vị đã được hoàn thành.
Điều này có nghĩa là nó sẽ chạy bất cứ khi nào bạn viết một lớp / phương thức, sửa lỗi, thay đổi chức năng ...
Kiểm tra tích hợp Kiểm tra tích hợp nhằm mục đích kiểm tra mức độ tương tác của một số đơn vị với nhau. Loại thử nghiệm này nên được thực hiện Bất cứ khi nào hình thức liên lạc mới được thiết lập giữa các đơn vị hoặc bản chất của sự tương tác giữa chúng đã thay đổi.
Điều này có nghĩa là nó chạy bất cứ khi nào một đơn vị được viết gần đây được tích hợp vào phần còn lại của hệ thống hoặc bất cứ khi nào một đơn vị tương tác với các hệ thống khác đã được cập nhật (và hoàn thành thành công các bài kiểm tra đơn vị của nó).
Kiểm tra hồi quy Kiểm tra hồi quy được thực hiện bất cứ khi nào có bất kỳ thay đổi nào trong hệ thống, để kiểm tra xem không có lỗi mới nào được đưa vào.
Điều này có nghĩa là nó được chạy sau tất cả các bản vá, nâng cấp, sửa lỗi. Kiểm thử hồi quy có thể được xem như một trường hợp đặc biệt của kiểm thử đơn vị kết hợp và kiểm thử tích hợp.
Kiểm tra chấp nhận Các kiểm tra chấp nhận được thực hiện bất cứ khi nào có liên quan để kiểm tra xem một hệ thống con (có thể là toàn bộ hệ thống) đáp ứng toàn bộ thông số kỹ thuật của nó.
Điều này có nghĩa là nó chủ yếu chạy trước khi hoàn thành một nhiệm vụ mới có thể phân phối hoặc thông báo đã hoàn thành một nhiệm vụ lớn hơn. Hãy xem đây là bước kiểm tra cuối cùng của bạn để biết rằng bạn đã thực sự hoàn thành các mục tiêu của mình trước khi chạy đến gặp khách hàng / ông chủ và thông báo chiến thắng.
Đây ít nhất là cách tôi học được, mặc dù tôi chắc chắn rằng có những quan điểm trái ngược khác. Dù bằng cách nào, tôi hy vọng điều đó sẽ hữu ích.
Tôi sẽ thử:
Unit Test: phương pháp đơn của tôi có hoạt động chính xác không? (KHÔNG có phụ thuộc hoặc phụ thuộc bị chế nhạo)
Kiểm tra tích hợp: hai mô-đun được phát triển riêng biệt của tôi có hoạt động chính xác khi đặt cùng nhau không?
Kiểm tra hồi quy: Tôi có vi phạm điều gì bằng cách thay đổi / viết mã mới không? (chạy thử nghiệm đơn vị / tích hợp với mọi cam kết là thử nghiệm hồi quy về mặt kỹ thuật (tự động)). Thường được sử dụng hơn trong ngữ cảnh QA - thủ công hoặc tự động.
Kiểm tra chấp nhận : kiểm tra được thực hiện bởi khách hàng, rằng anh ta "chấp nhận" SW được giao
Không thể bình luận (danh tiếng xuống thấp: - |) nên ...
@Andrejs tạo ra một điểm tốt xung quanh sự khác biệt giữa các môi trường liên quan đến từng loại thử nghiệm.
Bài kiểm tra đơn vị thường được chạy trên máy của nhà phát triển (và có thể trong quá trình xây dựng CI) với sự phụ thuộc giả tạo vào các tài nguyên / hệ thống khác.
Kiểm tra tích hợp theo định nghĩa phải có (một số mức độ) tính sẵn có của các phụ thuộc; các tài nguyên và hệ thống khác đang được gọi để môi trường mang tính đại diện hơn. Dữ liệu để thử nghiệm có thể bị chế nhạo hoặc một tập hợp con nhỏ bị xáo trộn của dữ liệu sản xuất thực.
Kiểm thử UAT / Acceptance phải thể hiện trải nghiệm thực tế cho QA và các nhóm kinh doanh chấp nhận phần mềm. Vì vậy, cần tích hợp đầy đủ và khối lượng dữ liệu thực tế và tập dữ liệu được che / làm mờ đầy đủ để mang lại hiệu suất thực tế và trải nghiệm người dùng cuối.
Các "ilities" khác cũng có khả năng cần môi trường càng gần với thực tế càng tốt để mô phỏng trải nghiệm sản xuất, ví dụ: kiểm tra hiệu suất, bảo mật, ...