Kiểm tra đơn vị hoặc Kiểm tra chức năng?

Question

Gần đây tôi đã nghe nói về Kiểm tra chức năng qua Kiểm tra đơn vị.

Tôi hiểu rằng Kiểm tra đơn vị kiểm tra từng khả năng của một đoạn mã nhất định từ dạng nguyên tử nhất của nó. Nhưng còn về Kiểm tra chức năng thì sao?

Điều này nghe có vẻ như chỉ thử nghiệm nếu mã hoạt động, nhưng nó có đáng tin cậy như Kiểm tra đơn vị không?

Tôi được cho biết có hai trường phái suy nghĩ về vấn đề này. Chứng chỉ muốn kiểm tra đơn vị, những người khác thử nghiệm chức năng.

Có tài nguyên, liên kết, sách hay bất kỳ tài liệu tham khảo nào hay một trong các bạn có thể giải thích và giải thích con đường của tôi về chủ đề này không?

Cảm ơn!

Answer 1

Câu trả lời của Jason là chính xác. Các loại thử nghiệm khác nhau có các mục đích khác nhau và có thể được xếp lớp để có kết quả tốt nhất (thiết kế tốt, thông số cuộc họp, lỗi giảm).

• Đơn vị kiểm tra = ổ đĩa thiết kế (với Test-Driven Development, hoặc TDD)
• Tích hợp thử nghiệm = làm tất cả các mảnh làm việc cùng nhau
kiểm tra chấp nhận
• khách hàng = nó đáp ứng yêu cầu của khách hàng
• Hướng dẫn kiểm tra = thường bao gồm giao diện người dùng; kiểm tra chuyên dụng có thể tìm thấy những gì tự động nhớ
• Load thử nghiệm = tốt như thế nào hệ thống thực hiện với số tiền thực tế của dữ liệu

Có một số chồng chéo giữa các loại; đơn vị kiểm tra có thể xác định hành vi, ví dụ.

Và còn có những người khác; đối với hầu hết mọi người quan tâm để biết, hãy xem Software Testing.

Một điểm mọi người bỏ qua là thử nghiệm đơn vị đang kiểm tra các đoạn mã trong sự cô lập. Các bài kiểm tra đơn vị tốt không nhấn cơ sở dữ liệu, ví dụ.Điều này có hai ưu điểm: nó làm cho các bài kiểm tra chạy nhanh, do đó bạn sẽ chạy chúng thường xuyên hơn, và nó buộc bạn phải viết các lớp được ghép lỏng lẻo (thiết kế tốt hơn).

Bạn đã yêu cầu tài nguyên; Tôi đề nghị cuốn sách của Roy Osherove The Art of Unit Testing with Examples in .NET. Mặc dù không có cuốn sách nào hoàn hảo, nhưng cuốn sách này mang lại nhiều con trỏ tuyệt vời để viết các bài kiểm tra tốt.

EDIT: Và để viết các bài kiểm tra đối với phần mềm hiện có, không có gì đánh bại cuốn sách của Michael Feathers Working Effectively with Legacy Code.

Answer 2

Kiểm tra đơn vị so với thử nghiệm chức năng không phải là xor, mà là and. Thử nghiệm đơn vị là về các đơn vị thử nghiệm trong sự cô lập trong khi thử nghiệm chức năng là về thử nghiệm toàn bộ trong tích hợp (làm tất cả các đơn vị làm việc cùng nhau đúng cách?).

Cả hai đều là các thành phần cần thiết của các thực hành kỹ thuật phần mềm tốt.

Answer 3

Có một nơi cho cả hai trong hầu hết các công trình phát triển.

Kiểm tra đơn vị ở đó để kiểm tra các đơn vị mã nhỏ, để thấy rằng chúng hoạt động như mong đợi.

Kiểm tra chức năng ở đó để kiểm tra chức năng tổng thể của hệ thống như mong đợi.

Chúng ở các cấp độ khác nhau và cả hai đều nên được sử dụng.

Answer 4

Kiểm tra đơn vị và thử nghiệm chức năng có hai kết quả khác nhau.

Kiểm tra đơn vị xác minh rằng một đoạn mã nhỏ hoạt động như mong đợi. Nó thường được thực hiện bởi các nhà phát triển để đảm bảo rằng các mã hoạt động chính xác. Chúng thường được tự động hóa bởi một khung kiểm thử.

Kiểm tra chức năng xác minh rằng tính năng hoạt động như mong đợi bằng cách đi qua một lộ trình nhất định thông qua chương trình. Chúng thường được thực hiện bởi một người trên phần mềm đảm bảo rằng chương trình sẽ làm việc theo cách mà nó được cho là dành cho người dùng. Nó, như vậy, là cấp cao hơn, và do đó kiểm tra nhiều đơn vị cùng một lúc.

Tôi nghĩ cả hai đều quan trọng. Tuy nhiên, nếu bạn có các tài nguyên hạn chế và phải chọn/chọn kỹ thuật, và tôi nghĩ nó phụ thuộc vào các sản phẩm bạn tạo ra, nhưng đối với những gì tôi làm (các sản phẩm điều khiển ô tô được con người sử dụng thông qua một số nút). Nó kiểm tra và đảm bảo rằng khi người dùng nhận được sản phẩm, nó sẽ thực hiện những gì nó được yêu cầu. Điều này không có nghĩa là chúng ta nên chọn không tham gia thử nghiệm đơn vị, nhưng nếu push-to-to-shove, chức năng là quan trọng nhất để đảm bảo trải nghiệm người dùng tuyệt vời và đưa sản phẩm ra khỏi cửa.

Nếu bạn sản xuất, nói, một công cụ cơ sở dữ liệu (hoặc một số sản phẩm khác không nhất thiết phải đối mặt với người dùng), kiểm tra đơn vị có thể là những gì bạn thực sự phải làm.

Answer 5

• Kiểm tra đơn vị = mức độ chi tiết, thấp nhất.
• Kiểm tra chức năng = cấp độ mô đun, mô đun.
• Kiểm tra tích hợp = cấp ứng dụng cao hơn.
• Factory nghiệm thu = nhìn thấy nó tất cả công việc
• Site nghiệm thu = nhìn thấy nó tất cả thất bại :)

Tất cả ở trên là hữu ích nhưng chúng không loại trừ lẫn nhau. Bạn nên làm hầu hết trong số họ nhưng số lượng thời gian bạn chi tiêu cho mỗi phần phụ thuộc vào kết quả bạn nhận được từ họ, đó là tất cả. Nếu mã của bạn quá mô-đun để dễ dàng kiểm tra đơn vị, hãy dành những nỗ lực của bạn vào các bài kiểm tra chức năng. Nếu bạn đang viết một thư viện các thành phần nhỏ, hãy dành thời gian để kiểm tra chúng, và nếu bạn đang viết hệ thống kiểm soát tên lửa quân sự, bạn chắc chắn sẽ chấp nhận thử nghiệm chúng (như các vụ nổ ngay cả khi nó không thành công :))

Answer 6

Thử nghiệm đơn vị kiểm tra đơn vị mã của bạn (phương pháp, v.v.) để đảm bảo chúng thực hiện những gì bạn mong đợi.

Kiểm tra chức năng kiểm tra thiết kế hệ thống của bạn để đảm bảo các phần tương tác chính xác. Nếu bạn viết một lệnh lấy và int và trả về một chuỗi và kiểm tra nó đầy đủ, bạn có thể chắc chắn nó hoạt động. Nhưng nếu bạn không có kiểm tra hệ thống, bạn có thể không bao giờ nhận thấy rằng phần còn lại của mã cho rằng nó có thể chấp nhận một null nhưng nó không thể.

Cả hai loại thử nghiệm đều quan trọng.

chỉnh sửa: Để thêm một cái nhìn hơi khác với những gì gbjbaanb nói:

• Unit test = mã của tôi làm việc
• chức năng test = thiết kế của tôi làm việc
• thử nghiệm tích hợp = mã của tôi đang sử dụng thứ 3 của bạn bên thứ một cách chính xác (cơ sở dữ liệu, vv)
• Factory nghiệm thu = hệ thống của tôi làm việc
• Site nghiệm thu = mã của bạn sucks, điều này hoàn toàn không phải là những gì tôi yêu cầu!?!

Answer 7

Kiểm tra chức năng, còn gọi là System testing, nhằm mục đích thử nghiệm hệ thống hoàn chỉnh và xác minh các yêu cầu chức năng được thỏa mãn.

Unit testing nhằm mục đích thử nghiệm "đơn vị", tức là các chức năng hoặc phương pháp mà hệ thống đang xây dựng từ cách ly. Đôi khi nó được gọi là Kiểm tra nhà phát triển. Thử nghiệm đơn vị có thể khó sau khi thực tế, đó là lý do tại sao TDD viết kiểm tra trước mã.

Đó là bổ sung vì các đơn vị có thể hoạt động độc lập chứ không phải khi được tích hợp với nhau hoặc có thể vượt qua kiểm tra đơn vị và không đáp ứng tất cả các yêu cầu của sản phẩm.

Answer 8

Một bài kiểm tra đơn vị kiểm tra một đoạn mã và xác nhận cho một lập trình viên rằng một đoạn mã khác đang làm những gì được cho là. Trong Test Driven Development, bài kiểm tra đơn vị được viết đầu tiên và quan sát thất bại, trước khi mã được viết gây ra bài kiểm tra để vượt qua. Các lập trình viên quan tâm đến bài kiểm tra đơn vị. Kiểm tra đơn vị được thực hiện nhanh chóng.

Kiểm tra chức năng kiểm tra yêu cầu hộp đen của bạn và chứng minh rằng một phần chức năng của người dùng đã sẵn sàng. Ví dụ, nếu tôi nhấn nút lớn màu đỏ, chuông bắt đầu đổ chuông. Bài kiểm tra chức năng có thể thậm chí không phải là mã thử nghiệm. Có lẽ có một quá trình cơ khí khiến chuông rung khi nhấn nút. Khách hàng quan tâm đến Kiểm tra chức năng khi họ xác nhận rằng quy trình cấp cao nếu làm việc theo cách mà họ hiểu. Chúng thường chạy chậm.