Có hợp lý không khi không có tiêu chí đạt / không đạt cho bài kiểm tra căng thẳng


10

Để rõ ràng, bài kiểm tra căng thẳng tôi đã viết đều đặn làm tăng tải cho hệ thống cho đến khi nó đạt đến điểm phá vỡ. Về mặt lý thuyết, nó chạy vô thời hạn, nhưng vì tài nguyên hệ thống là hữu hạn, nên nó sẽ thất bại sau một thời gian. Tôi có một tải dự kiến ​​cho hệ thống, nhưng điều này được kiểm tra riêng trong một thử nghiệm tải . Mục đích của bài kiểm tra căng thẳng này là tìm hiểu xem tôi có thể tải bao nhiêu cho hệ thống trước khi tôi cần thực hiện mở rộng quy mô.


Tôi đang trong quá trình viết một bài kiểm tra căng thẳng cho một hệ thống, và tôi tự hỏi liệu nó có hợp lý để có tiêu chí đạt / không đạt. Theo bản chất của thử nghiệm, tải tăng dần cho đến khi nó đạt đến điểm phá vỡ (tức là nó thất bại ). Tôi rõ ràng không biết điểm đột phá này là gì trước đó, và do đó, không có kỳ vọng về tải trọng mà hệ thống có thể xử lý (dù sao về mặt lý thuyết).

Bây giờ tôi có các bài kiểm tra hiệu suất khác để kiểm tra hệ thống theo tải trọng dự kiến, v.v., tôi có thể dễ dàng đặt tiêu chí đạt / không đạt và tôi có thể sử dụng các tiêu chí này làm cơ sở cho bài kiểm tra căng thẳng của mình. Nói cách khác, tôi có thể đặt đường cơ sở tối thiểu để bài kiểm tra căng thẳng của mình đạt được, nhưng tôi không chắc liệu đây có phải là điều đúng hay không (đây có phải là 'sao chép' bài kiểm tra khác của tôi không?).

Tôi hy vọng ai đó có nhiều kinh nghiệm hơn trong thử nghiệm hiệu suất có thể giúp tôi ra khỏi đây. Những tiêu chí vượt qua / thất bại nào khác được sử dụng khi kiểm tra căng thẳng (nếu có)?


1
Nếu bạn không vượt qua / thất bại, tại sao bạn lại làm bài kiểm tra?
RemcoGerlich

@RemcoGerlich Vậy tôi có thể biết giới hạn của hệ thống không? Điều này sẽ giúp lập kế hoạch năng lực, v.v.
Alex

Tôi nghĩ rằng lập kế hoạch năng lực là nơi bạn quyết định tải tối thiểu mà hệ thống của bạn cần để có thể xử lý (do đó, bạn có một tiêu chí không đạt).
RemcoGerlich

@RemcoGerlich Có thể tôi đã nhầm lẫn các điều khoản của mình, nhưng về cơ bản tôi có tải dự kiến ​​(được kiểm tra riêng), nhưng tôi đang sử dụng bài kiểm tra căng thẳng này để xác định tại thời điểm nào (tức là số lượng người dùng) tôi sẽ cần quy mô cơ sở hạ tầng. Đây là một thử nghiệm riêng vì các thay đổi đối với hệ thống có thể thay đổi tải mà hệ thống có thể xử lý, không thể nhìn thấy trong thử nghiệm tải.
Alex

@Alex, không, bạn chưa hiểu điều khoản của mình. Bạn đang mô tả chính xác một bài kiểm tra căng thẳng. Vấn đề bạn gặp phải là không có lỗi / thất bại liên quan đến kiểm tra căng thẳng, do đó không thể dễ dàng chạy bằng các công cụ "kiểm tra đơn vị".
David Arno

Câu trả lời:


10

Trong một bài kiểm tra căng thẳng, công việc của bạn không phải là xác định mức độ căng thẳng mà đối tượng có thể thực hiện. Đó là để đo lường sự căng thẳng cần có trước khi nó thất bại.

Bạn có thể sử dụng các tiêu chí hiệu suất để xác định thất bại căng thẳng là gì. Nhưng kết quả của một bài kiểm tra căng thẳng không vượt qua / thất bại. Đó là "thất bại sau 90 giờ dưới mức sử dụng 100% với thông gió bị xâm phạm 50%".


một câu hỏi. Có nên kiểm tra căng thẳng gây ra sự cố hệ thống? Nói cách khác. Là sự cố mà chúng ta coi là "thất bại"?
Laiv

3
@laiv Các bài kiểm tra căng thẳng nên gây căng thẳng. Và chứng minh làm thế nào đối tượng phản ứng với sự căng thẳng đó. Nếu nó gây ra sự cố hệ thống cần được ghi lại. Các bài kiểm tra căng thẳng được cho là gây ra thất bại và cho thấy những gì nó cần để gây ra chúng. Sự cố hệ thống là một thất bại, giả sử hệ thống bị hỏng không thành công yêu cầu. Họ thường làm.
candied_orange

1

Nó phụ thuộc vào các yêu cầu, nếu các yêu cầu của bạn chỉ định rằng kết quả mong đợi cho hiệu suất ứng dụng là X và thực sự bạn đã nhận được Y, vì vậy đó là Thất bại.
Nếu bạn không có yêu cầu được xác định, vì vậy bạn có thể nhấn mạnh hệ thống của mình và thu thập dữ liệu ranh giới, sau đó tìm ra và xử lý các giới hạn này.


0

Bạn có thể dễ dàng cập nhật bài kiểm tra căng thẳng chính của mình để hỗ trợ xác minh vượt qua / thất bại QA, đại loại như "có thể đạt / duy trì tải X mà không bị hỏng". Lý tưởng với X là cấu hình (ví dụ cho các nhánh phát hành khác nhau).

Kết quả sẽ là failnếu hệ thống bị hỏng trước khi tải đến X và passnếu nó không bị hỏng . Bạn chỉ cần ngừng tăng tải khi đạt đến giá trị X trong kịch bản "duy trì".

IMHO một thử nghiệm tự động như thế này có thể rất hữu ích trong bối cảnh CI / CD, đặc biệt là trên các ngành sản xuất.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.