Thử nghiệm tính năng so với đơn vị kiểm tra

Question

Tôi đang đọc Osherove của "The Art of Đơn vị kiểm tra", và mặc dù tôi đã chưa thấy anh ấy nói gì về việc thử nghiệm hiệu suất, hai suy nghĩ vẫn vượt qua tâm trí tôi:

• Performance kiểm tra thường không thể là kiểm tra đơn vị, bởi vì kiểm tra hiệu suất thường cần phải chạy trong thời gian dài.
• Kiểm tra hiệu suất thường không thể là kiểm tra đơn vị, vì các vấn đề về hiệu suất thường biểu hiện ở mức tích hợp hoặc hệ thống (hoặc ít nhất là logic của một bài kiểm tra đơn vị cần thiết để tạo lại hiệu suất của môi trường tích hợp liên quan đến một thử nghiệm đơn vị).

Riêng lý do đầu tiên đã nêu ở trên, tôi nghi ngờ việc kiểm tra hiệu suất sẽ được xử lý bởi khung kiểm thử đơn vị (chẳng hạn như NUnit).

Câu hỏi của tôi là: những phát hiện/độ nghiêng của tôi có tương ứng với suy nghĩ của cộng đồng không?

Answer 1

Tôi đồng ý với những phát hiện/học hỏi của bạn. Kiểm tra đơn vị thực sự chỉ kiểm tra một phần của hệ thống, bỏ qua, chế nhạo hoặc giả mạo phần còn lại khi cần thiết. Kiểm thử tích hợp (hoặc kiểm tra hồi quy) kiểm tra hầu hết hoặc tất cả các đơn vị làm việc cùng nhau, và đó là thước đo thực sự thực sự.

Answer 2

Kiểm tra hiệu suất có thể được thực hiện rất tốt từ các bài kiểm tra đơn vị.

Ví dụ: kiểm tra đơn vị có thể ném nhiều tham số khác nhau vào một phương thức và xác minh phương thức trả về kết quả mong đợi. Một thử nghiệm hiệu suất có thể thực hiện kiểm tra đơn vị đó 1000 lần (hoặc bất kỳ giá trị nào có ý nghĩa đối với bạn) trong khi ghi lại tất cả mọi thứ từ CPU và bộ đếm ngay xuống mỗi lần kiểm tra.

Answer 3

Trong một số trường hợp, bạn có thể sử dụng các kiểm tra đơn vị để đảm bảo rằng một thao tác hoàn tất trong một khoảng thời gian nhất định. Nếu bạn muốn thêm nhiều tính năng hơn vào hoạt động của mình, nhưng bạn không muốn hi sinh hiệu suất, bạn có thể sử dụng các kiểm thử đơn vị để khẳng định điều đó. Tất nhiên, các bài kiểm tra đơn vị này phụ thuộc vào máy, nhưng bạn có thể ném một số biến hoặc cấu hình bổ sung vào phương trình.

Answer 4

Tất cả phụ thuộc vào những gì bạn gọi là thử nghiệm hiệu suất. Khi mã tối ưu hóa vi mô tôi thường sử dụng một cái gì đó rất giống với thử nghiệm đơn vị (tôi nên gọi nó là kiểm tra hiệu suất đơn vị?). Đó là cơ bản những gì tôi làm trong question (mặc dù không quan tâm ở đó để thực sự sử dụng một khung kiểm tra đơn vị). Nhưng tôi cũng làm những việc này để tối ưu hóa mã sản xuất C++ của tôi trong khuôn khổ thử nghiệm đơn vị BOOST.

Thực sự có nhiều loại thử nghiệm hiệu suất ở các cấp khác nhau và với các mục đích khác nhau (kiểm tra ứng suất tải nặng, lược tả, tối ưu hóa vi mô). Kiểm tra hiệu suất mà bạn đang nói đến trong câu hỏi của bạn dường như ở cấp độ thử nghiệm chức năng. Một cấp độ mà bạn có thể sẽ không sử dụng khung kiểm thử đơn vị.

Answer 5

Kiểm tra đơn vị sẽ không mất thời gian để thực hiện vì bạn chỉ đang thử nghiệm một đơn vị/hệ thống rất cụ thể. Giống như nếu hệ thống của bạn đang thử nghiệm là ClassA: IClassA, bạn làm mocking/stubbing và chỉ kiểm tra hành vi của ClassA, và không nên thử nghiệm hành vi khác với ClassA, chẳng hạn như nếu ClassA sử dụng ClassB. Bạn nên tiêm một mô hình của ClassB thay vì bê tông để đạt được điều này. Trong điều khoản của các thử nghiệm hiệu suất, nó có ý nghĩa để vẫn sử dụng một khuôn khổ thử nghiệm như NUnit/MBUnit/MavenThought, chỉ cần giữ các xét nghiệm này trong một hội đồng riêng biệt và không gọi chúng như là một phần của bài kiểm tra đơn vị của bạn.

Vì vậy, nếu bạn sử dụng Rake để gọi kiểm tra của bạn, một số nhiệm vụ của bạn có thể trông giống như:

Rake Test:All   #Run all unit tests 
Rake Test:Acceptance #Run all acceptance tests 
Rake Test:Performance #Run all performance tests 
Rake Test:Integration #Run all integration tests 

Sau đó, với hội nhập liên tục của bạn, thử nghiệm: Tất cả, luôn gọi sau khi một xây dựng thành công, trong khi đó thử nghiệm : Hiệu suất được gọi vào lúc 12 giờ sáng một lần mỗi ngày.

Answer 6

Tôi đồng ý rằng kiểm tra hiệu suất không thể là kiểm tra đơn vị nhưng không có lý do gì chúng tôi không thể có một bộ kiểm tra khác gọi là kiểm tra hiệu suất. Nói rộng ra các bài kiểm tra thuộc hai loại

a) Đơn vị xét nghiệm

b) Tích hợp kiểm tra

Chúng tôi chạy thử nghiệm hội nhập lại cơ sở dữ liệu thực tế (thay vì trong bộ nhớ) để đảm bảo các script sql, Hibernate kho lưu trữ hoạt động như mong đợi

Ý tưởng của tôi là chúng tôi có thể thêm một bộ kiểm thử khác gọi là kiểm tra hiệu suất là một phần của bản dựng hàng đêm để kiểm tra hiệu suất của một số chức năng nhất định. Điều này là quan trọng để theo dõi các số liệu thống kê sau khi một mã lại bao thanh toán hoặc để đánh giá nếu những thay đổi cho một phần của ứng dụng có thể có hậu quả ngoài ý muốn khác.

Tôi đã xem qua JunitPerf có thể giúp tôi đạt được mục tiêu này.

Answer 7

Tôi nhớ năm trước Microsoft đã ủng hộ các lập trình viên kiểm thử hiệu suất của từng cá nhân bằng cách sử dụng Visual Studio Net Application Center Test (ACT). Có (vẫn có thể được ra khỏi đó) một phương pháp toàn bộ để thực hiện Phân tích chi phí giao dịch (TCA) trên cá nhân của asp. Điều đó nói rằng các asps có thể được kiểm tra bằng cách sử dụng một trình điều khiển web và các đối tượng giả có thể để cô lập mã được thử nghiệm (đó là bắt chước truy cập DB nếu nó không được phát triển).

Cách tiếp cận này có thể được theo sau với bất kỳ thử nghiệm Đơn vị nào mà bạn có trình điều khiển và tùy chọn, một khung đối tượng giả để xử lý bất kỳ phụ thuộc nào chưa được viết. Cách tiếp cận này cũng đã trở nên phổ biến với SOAPUI \ LOADUI. Ngoài ra, tôi khuyên bạn nên cô lập các câu lệnh SQL riêng lẻ có thể được kiểm tra (tối ưu hóa) dựa trên một thiết kế cơ sở dữ liệu đã cho. Điều này (DB) thử nghiệm hiệu suất đơn vị SQL có thể được thực hiện sớm trong SDLC và nó sẽ khám phá cơ hội tối ưu hóa truy vấn.

Về chi phí và giá trị: Tôi đã tìm thấy thử nghiệm hiệu suất UNIT sớm, sử dụng đối tượng Mock phù hợp, sẽ xác định rò rỉ bộ nhớ và sử dụng CPU quá mức và đĩa IO sớm trong SDLC nhưng tôi sẽ 'chọn anh đào' mã kiểm tra các mục nguy cơ cao hơn.

Answer 8

Có sự khác biệt tương phản giữa kiểm tra đơn vị và thử nghiệm hiệu suất. Đầu tiên và quan trọng nhất, kiểm tra đơn vị là để kiểm tra các ứng dụng chống lại các yêu cầu chức năng của nó. ví dụ: bạn muốn đảm bảo nhấp vào tab Trang chủ mà trang web điều hướng đến nhà trong khi kiểm tra hiệu suất là một loại thử nghiệm không hoạt động. Ở đây bạn quan tâm đến sự ổn định và khả năng phản ứng của ứng dụng theo một tải người dùng cụ thể trong một khoảng thời gian nhất định.