Có các mẫu được xác định rõ ràng để kiểm tra khả năng mở rộng phần mềm không?

Question

Gần đây tôi đã trở nên khá quan tâm đến việc xác định các mẫu thử nghiệm khả năng mở rộng phần mềm. Do tính chất biến đổi của các giải pháp phần mềm khác nhau, có vẻ như có nhiều giải pháp tốt cho vấn đề phần mềm kiểm tra khả năng mở rộng vì có thiết kế và triển khai phần mềm. Đối với tôi, điều đó có nghĩa là chúng tôi có thể có thể chưng cất một số mẫu cho loại thử nghiệm này được sử dụng rộng rãi.

Vì mục đích loại bỏ sự mơ hồ, tôi sẽ nói trước rằng tôi đang sử dụng wikipedia definition thử nghiệm khả năng mở rộng.

Tôi quan tâm nhất đến các câu trả lời đề xuất tên mẫu cụ thể với mô tả kỹ lưỡng.

Answer 1

Tất cả các kịch bản thử nghiệm mà tôi biết sử dụng cùng cấu trúc cơ bản cho thử nghiệm bao gồm việc tạo một số yêu cầu trên một hoặc nhiều người yêu cầu được nhắm mục tiêu tại đại lý xử lý. Câu trả lời của Kurt là một ví dụ tuyệt vời của quá trình này. Nói chung, bạn sẽ chạy thử nghiệm để tìm một số ngưỡng và cũng chạy một số cấu hình thay thế (ít nút hơn, phần cứng khác nhau, v.v ...) để xây dựng một dữ liệu trung bình chính xác.

Người yêu cầu có thể là máy, thẻ mạng, phần mềm hoặc chuỗi cụ thể trong phần mềm tạo yêu cầu. Tất cả những gì nó làm là tạo ra một yêu cầu có thể được xử lý theo một cách nào đó.

Tác nhân xử lý là phần mềm, card mạng, máy thực sự xử lý yêu cầu và trả về kết quả.

Tuy nhiên những gì bạn làm với kết quả xác định loại bài kiểm tra bạn đang làm và họ là:

Load/Performance Testing: Đây là một trong những phổ biến nhất được sử dụng. Các kết quả được xử lý là để xem có bao nhiêu được xử lý ở các cấp độ khác nhau hoặc trong các cấu hình khác nhau. Một lần nữa những gì Kurt đang tìm kiếm ở trên là một ví dụ nếu điều này.

Kiểm tra số dư: Thực tiễn phổ biến trong việc chia tỷ lệ là sử dụng tác nhân cân bằng tải để chuyển yêu cầu đến tác nhân xử lý. Thiết lập cũng tương tự như đối với Kiểm tra tải, nhưng mục tiêu là kiểm tra phân phối các yêu cầu. Trong một số trường hợp, bạn cần đảm bảo rằng số dư yêu cầu trên toàn bộ các xử lý được thực hiện và trong các trường hợp khác, bạn cần phải đảm bảo rằng tác nhân xử lý yêu cầu đầu tiên cho một người yêu cầu cụ thể xử lý tất cả các yêu cầu tiếp theo (trang trại thường cần thiết như thế này).

An toàn dữ liệu: Với thử nghiệm này, kết quả được thu thập và dữ liệu được so sánh. Những gì bạn đang tìm kiếm ở đây là các vấn đề về khóa (chẳng hạn như một bế tắc SQL) để ngăn việc ghi hoặc thay đổi dữ liệu được sao chép vào các nút hoặc kho lưu trữ khác nhau mà bạn sử dụng trong một thời gian chấp nhận được hoặc ít hơn.

Kiểm tra ranh giới: Điều này tương tự như kiểm tra tải ngoại trừ mục tiêu không xử lý hiệu suất nhưng hiệu suất được lưu trữ bao nhiêu. Ví dụ, nếu bạn có một cơ sở dữ liệu có bao nhiêu hàng/bảng/cột, bạn có thể có trước khi hiệu suất I/O giảm xuống dưới mức chấp nhận được.

Tôi cũng khuyên bạn nên The Art of Capacity Planning làm sách tuyệt vời về chủ đề này.

Answer 2

Tôi có thể thêm một loại thử nghiệm khác vào danh sách của Robert: ngâm thử nghiệm.Bạn chọn một tải thử nghiệm phù hợp nặng, và sau đó chạy nó trong một khoảng thời gian dài - nếu kiểm tra hiệu suất của bạn thường kéo dài trong một giờ, chạy qua đêm, cả ngày hoặc cả tuần. Bạn theo dõi cả tính chính xác và hiệu suất. Ý tưởng là để phát hiện bất kỳ loại vấn đề nào tích tụ chậm theo thời gian: những thứ như rò rỉ bộ nhớ, đóng gói, các lỗi liên tục, các chỉ số cần xây dựng lại, v.v.

Đây là một loại khả năng mở rộng khác. Khi hệ thống của bạn rời khỏi cửa hàng phát triển và phát trực tiếp, nó không chỉ lớn hơn 'theo chiều ngang', bằng cách thêm nhiều tải và nhiều tài nguyên hơn, nhưng trong chiều thời gian: nó sẽ chạy không ngừng trên các máy sản xuất tuần, tháng hoặc năm, mà nó đã không được thực hiện trong phát triển.