Spike testing trong kiểm thử phần mềm là gì? Tìm hiểu với ví dụ

⚡ Tóm tắt thông minh

Kiểm thử đột ngột (Spike Testing) đưa một ứng dụng vào chịu tải cực lớn đột ngột, rồi sau đó rút tải đi một cách đột ngột. Mục tiêu là để tìm hiểu xem hệ thống có chịu được cú sốc đó hay không và, quan trọng không kém, liệu nó có phục hồi sau đó hay không.

  • Mô hình tải: Lưu lượng truy cập tăng đột biến, vượt xa mức bình thường, duy trì trong thời gian ngắn rồi giảm xuống.
  • 🎯 Mục tiêu chính: Xác định xem hệ thống có bị lỗi hay không, và liệu lỗi đó có được xử lý một cách nhẹ nhàng hay không.
  • 🔄 Phục hồi sức khỏe là điều quan trọng: Việc khôi phục lại thời gian phản ứng bình thường sau khi cơn tăng đột biến xảy ra cũng quan trọng như việc sống sót qua cơn đó.
  • 📈 Các yếu tố kích hoạt thực tế: Các chương trình khuyến mãi chớp nhoáng, phát hành vé đột xuất, lưu lượng truy cập lan truyền và các tác vụ xử lý hàng loạt theo lịch trình.
  • 🛠️ dụng cụ: JMeter Cả LoadRunner và các công cụ khác đều mô phỏng quá trình tăng tải tức thời chứ không phải tăng tải dần dần.
  • 📊 Những gì để xem: Tỷ lệ lỗi, độ sâu hàng đợi và thời gian cần thiết để trở lại trạng thái ban đầu.

Kiểm thử đột biến là gì?

Thử nghiệm tăng đột biến là gì?

Kiểm tra đột biến là một loại thử nghiệm phần mềm trong đó một ứng dụng phần mềm được thử nghiệm với mức tăng và giảm cực lớn về tải lưu lượng. Mục đích chính của thử nghiệm tăng đột biến là đánh giá hành vi của ứng dụng phần mềm khi tải của người dùng tăng hoặc giảm đột ngột và xác định thời gian phục hồi sau khi tải của người dùng tăng đột biến.

Spike testing được thực hiện để ước tính điểm yếu của ứng dụng phần mềm.

Kiểm tra đột biến
Kiểm tra đột biến

Mục tiêu của thử nghiệm Spike

Mục tiêu của thử nghiệm Spike là để xem hệ thống phản ứng như thế nào trước sự tăng giảm đột ngột của tải người dùng. Trong Software Engineering Spike testing giúp xác định hiệu suất hệ thống sẽ suy giảm khi có tải cao đột ngột.

Một mục tiêu khác của Spike testing là xác định thời gian phục hồi. Giữa hai lần tải người dùng tăng đột biến liên tiếp, hệ thống cần một thời gian để ổn định. Thời gian phục hồi này nên càng thấp càng tốt.

Cách thực hiện kiểm tra tăng đột biến

Dưới đây là các bước đơn giản để thực hiện Spike testing:

Bước 1) Xác định khả năng chịu tải

Xác định khả năng tải người dùng tối đa của ứng dụng phần mềm của bạn.

Bước 2) Chuẩn bị môi trường thử nghiệm

Chuẩn bị Môi trường thử nghiệm và định cấu hình nó để ghi lại các thông số hiệu suất.

Bước 3) Xác định tải dự kiến

Áp dụng tải tối đa dự kiến ​​cho Ứng dụng phần mềm của bạn bằng cách sử dụng Công cụ kiểm tra hiệu suất Của bạn lựa chọn.

Bước 4) Tăng tải

Tăng nhanh tải cho hệ thống trong một khoảng thời gian nhất định.

Bước 5) Đặt tải trở lại bình thường

Giảm tải dần dần về mức ban đầu.

Bước 6) Phân tích kết quả

Phân tích các biểu đồ và số liệu hiệu suất như Thất bại, Thời gian thực hiện, Người dùng ảo, v.v.

Ví dụ về các kịch bản thử nghiệm tăng đột biến

  • Khi một cửa hàng Thương mại Điện tử tung ra các ưu đãi đặc biệt với mức giảm giá lớn chẳng hạn như vào Thứ Sáu Đen.
  • Khi một ứng dụng web đang phát trực tiếp một chương trình TV yêu thích.
  • Khi đợt giảm giá chớp nhoáng đang diễn ra trên một trang web giao dịch hàng ngày.
  • Khi nội dung nhất định của một trang web lan truyền trên Internet.
  • Một hệ thống mới được phát hành để sản xuất và nhiều người dùng muốn truy cập vào hệ thống.
  • Mất điện có thể khiến tất cả người dùng mất quyền truy cập vào hệ thống. Sau khi sự cố mất điện được giải quyết, tất cả người dùng sẽ đăng nhập lại vào hệ thống cùng lúc.

Kịch bản phục hồi khi tải tăng đột biến

Ba tình huống khôi phục chính có thể được cấu hình để bảo vệ chống lại Spike là:

  1. Sử dụng nền tảng đám mây như AWS, Azure để tự động tăng dung lượng máy chủ song song với tải của người dùng
  2. Không cho phép một số người dùng truy cập ứng dụng để hệ thống không phải chịu tải nặng. Điều này ngăn những người vượt quá tải trọng thiết kế tối đa xâm nhập vào hệ thống. Do đó bảo vệ hệ thống khỏi mối đe dọa tải quá mức.
  3. Quản trị viên trang cho phép người dùng tham gia hệ thống. Tuy nhiên với cảnh báo rằng họ có thể phải đối mặt với phản ứng chậm do tải nặng. Điều này có thể dẫn đến ảnh hưởng xấu đến hiệu suất của hệ thống. Tuy nhiên, người dùng sẽ có thể làm việc với hệ thống.

Ưu điểm và nhược điểm của thử nghiệm đột biến

Dưới đây là những ưu điểm và nhược điểm của Spike testing:

Ưu điểm Nhược điểm
Hiệu suất của phần mềm phải được duy trì bằng mọi giá. Tuy nhiên, khi tải của bất kỳ hệ thống nào tăng quá mức thì khả năng xảy ra sự cố là rất cao. Kiểm tra tăng đột biến giúp kiểm tra tình huống như vậy. Nhược điểm duy nhất của Spike testing là nó là một quá trình thử nghiệm tốn kém. Vì vậy, nó cần thiết lập các điều kiện thử nghiệm đặc biệt. Tuy nhiên, trong thời gian dài hơn, nó chắc chắn sẽ mang lại ROI tích cực.
Trong phương pháp thử nghiệm tiêu chuẩn, các tình huống xấu đến trường hợp xấu nhất có thể không được giải quyết. Tuy nhiên, bỏ qua chúng không có nghĩa là chúng sẽ không bao giờ xảy ra. Vì vậy, mọi phần mềm nên sẵn sàng cho những khả năng như vậy. Một trong những trường hợp xấu nhất là tải có thể được đánh giá và giảm thiểu với sự trợ giúp của thử nghiệm tăng đột biến.  

Công cụ kiểm tra đột biến

1) JMeter

Apache JMeter là một công cụ kiểm tra tăng đột biến mã nguồn mở java. Nó được thiết kế đặc biệt để tải hành vi kiểm tra chức năng và đo lường hiệu suất. Công cụ kiểm tra hiệu suất này có thể được sử dụng để phân tích và đo lường hiệu suất của ứng dụng web hoặc nhiều dịch vụ khác nhau. Ngày nay, nó được sử dụng rộng rãi để kiểm tra chức năng, kiểm tra máy chủ cơ sở dữ liệu.

2) LoadRunner

LoadRunner là một công cụ kiểm tra tải dành cho Windows và Linux, cho phép thử nghiệm đột biến trang web và các ứng dụng khác. Nó giúp xác định hiệu suất và kết quả của ứng dụng ngay cả khi tải nặng.

Bài kiểm tra này phù hợp với nhóm kiểm thử hiệu năng như thế nào?

Kiểm thử hiệu năng là một thuật ngữ chung. Các biến thể dưới đây chỉ khác nhau ở dạng tải trọng tác dụng và thời gian duy trì tải trọng đó, đó là lý do tại sao chúng thường bị nhầm lẫn với nhau.

Loại thử nghiệm Mẫu tải Câu hỏi nó trả lời
Kiểm tra tải Dự kiến ​​tải trọng cao điểm, thời gian ngắn. Hệ thống có đạt được mục tiêu đề ra trong điều kiện lưu lượng giao thông cao điểm bình thường không?
Bài kiểm tra về áp lực Tăng công suất vượt quá khả năng cho đến khi hỏng hóc Nó bị hỏng ở đâu, và liệu nó có bị hỏng một cách êm ái không?
thử nghiệm tăng đột biến Sự tăng vọt đột ngột, sau đó là sự rút lui. Liệu nó có thể tồn tại và phục hồi sau cú sốc giao thông?
kiểm tra độ bền Tải trọng bình thường được duy trì trong nhiều giờ. Hiệu năng có giảm dần theo thời gian không?
thử nghiệm ngâm Tải trọng duy trì trong một thời gian dài Có hiện tượng rò rỉ bộ nhớ hoặc cạn kiệt tài nguyên không?
Kiểm tra độ ổn định Tải trọng thay đổi tùy theo điều kiện Hệ thống có duy trì được độ tin cậy khi điều kiện thay đổi không?
Kiểm tra khối lượng Người dùng thông thường, dung lượng dữ liệu rất lớn. Liệu hệ thống có đáp ứng được khi cơ sở dữ liệu phát triển?

Thử nghiệm độ bền và thử nghiệm ngâm thường được coi là đồng nghĩa. Trong cách sử dụng thông thường, cả hai đều duy trì tải trọng ổn định trong thời gian dài. Ở những nơi các nhóm phân biệt chúng, kiểm thử độ bền tập trung vào việc liệu thời gian phản hồi có tăng lên hay không, trong khi kiểm thử độ bền lâu tập trung vào mức tiêu thụ tài nguyên như bộ nhớ, xử lý tập tin và nhóm kết nối. Chạy một trong hai thường cung cấp bằng chứng cho cả hai.

Các chỉ số quan trọng cần thu thập trong quá trình thử nghiệm

Một lần chạy thử nghiệm hiệu năng chỉ tốt khi bạn ghi lại được những gì cần thiết trong quá trình thực thi. Hãy ghi lại sáu thông số này ở cả phía máy chủ và phía máy khách, sau đó so sánh chúng với mức cơ bản thay vì chỉ dựa vào cảm tính.

metric Nó nói với bạn điều gì Dấu hiệu cảnh báo
Thời gian phản hồi trung bình Trải nghiệm người dùng điển hình Bất kỳ sự dịch chuyển hướng lên nào trong suốt quá trình chạy
thời gian phản hồi ở phân vị thứ 95 Trải nghiệm của những người dùng chậm nhất Cao hơn mức trung bình rất nhiều, nghĩa là không nhất quán.
Thông lượng Số yêu cầu được xử lý mỗi giây Giảm dần trong khi tải trọng không đổi
Tỷ lệ lỗi Tỷ lệ yêu cầu thất bại hoặc hết thời gian chờ Bất kỳ sự tăng nào vượt quá ngưỡng đã thỏa thuận
Sử dụng CPU và bộ nhớ Khả năng dự trữ tài nguyên máy chủ Ký ức leo lên và không bao giờ trở lại
Kết nối cơ sở dữ liệu và luồng Kiệt sức ở hồ bơi Số lượng tăng đều đặn mà không cần phát hành

Hãy đọc giá trị trung bình và phần trăm cùng nhau. Mức trung bình 800 ms với phân vị thứ 95 là 900 ms mô tả một hệ thống hoạt động ổn định. Cùng mức trung bình đó nhưng với phân vị thứ 95 là 9 giây có nghĩa là cứ 20 người dùng thì có một người gặp sự cố, và mức trung bình đang che giấu điều đó.

Hãy quan sát hình dạng, chứ không chỉ giá trị. Trong bất kỳ bài kiểm tra kéo dài nào, đường biểu diễn tài nguyên nằm ngang là dấu hiệu đạt yêu cầu, còn đường biểu diễn tăng lên là dấu hiệu rò rỉ, ngay cả khi con số tuyệt đối vẫn nằm trong giới hạn cho phép tại thời điểm kết thúc quá trình kiểm tra.

Kiểm tra đột biến: Những điểm chính cần lưu ý

  • kiểm thử phần mềm là một loại thử nghiệm phần mềm trong đó một ứng dụng phần mềm được thử nghiệm với mức tăng và giảm cực lớn về tải lưu lượng.
  • Cách tiếp cận phù hợp để thực hiện thử nghiệm tăng đột biến là tăng số lượng người dùng một cách bất ngờ, sau đó giảm tải ngay lập tức.
  • Tải không mong muốn là thuộc tính chính của thỏa thuận.
  • Ví dụ về các kịch bản thử nghiệm Spike trong đời thực là – khi một cửa hàng Thương mại điện tử tung ra các ưu đãi đặc biệt với mức giảm giá lớn chẳng hạn như vào Thứ Sáu Đen. Ngoài ra, khi một ứng dụng web đang phát trực tiếp một chương trình TV yêu thích.
  • JMeter là một trong những công cụ hữu ích để thực hiện kiểm tra tăng đột biến.

Câu Hỏi Thường Gặp

Kiểm tra độ bền bằng cách tăng tải dần dần cho đến khi hệ thống bị hỏng, để tìm ra giới hạn chịu tải. Kiểm tra xung lực áp dụng tải trọng cực đại ngay lập tức, để xem liệu một cú sốc đột ngột có gây ra hỏng hóc mà việc tăng tải dần dần không gây ra hay không.

Một hệ thống vẫn hoạt động nhưng không bao giờ khôi phục lại thời gian phản hồi bình thường thì vẫn gây thất vọng cho những người dùng truy cập sau khi lưu lượng truy cập tăng đột biến. Thời gian phục hồi là chỉ số phản ánh tác động thực sự đến hoạt động kinh doanh.

Hãy dựa vào một sự kiện thực tế thay vì một con số làm tròn. Lưu lượng truy cập trong quá khứ từ một đợt bán hàng hoặc ra mắt sản phẩm trước đó, nhân với mức tăng trưởng dự kiến ​​kể từ đó, sẽ cho ra một mục tiêu khả thi.

Các mô hình AI được đào tạo dựa trên dữ liệu lưu lượng truy cập lịch sử, lịch tiếp thị và các tín hiệu bên ngoài dự báo thời điểm xảy ra các đợt tăng đột biến, cho phép các nhóm chủ động mở rộng quy mô cơ sở hạ tầng thay vì chỉ phản ứng sau khi sự việc đã xảy ra.

Đúng vậy. Các công cụ AI có thể trích xuất hồ sơ đỉnh lưu lượng từ nhật ký truy cập sản xuất, tái tạo hình dạng thực sự của các đợt tăng đột biến trong quá khứ thay vì một sự thay đổi đột ngột nhân tạo.

Tóm tắt bài viết này với: