Kiểm tra khả năng mở rộng là gì? Học với ví dụ
Thomas Hamilton
⚡ Tóm tắt thông minh
Kiểm thử khả năng mở rộng đo lường cách ứng dụng hoạt động khi tải người dùng, khối lượng dữ liệu hoặc tốc độ giao dịch tăng hoặc giảm, từ đó tiết lộ điểm chính xác mà tại đó hiệu năng ngừng mở rộng và xác định nút thắt cổ chai gây ra hiện tượng này.
Kiểm thử khả năng mở rộng là gì?
Kiểm tra khả năng mở rộng Kiểm thử khả năng mở rộng là một phương pháp kiểm thử phi chức năng, đo lường hiệu suất của hệ thống hoặc mạng khi số lượng yêu cầu của người dùng được tăng hoặc giảm. Mục đích của kiểm thử khả năng mở rộng là để đảm bảo hệ thống có thể xử lý sự gia tăng dự kiến về lưu lượng người dùng, khối lượng dữ liệu và tần suất giao dịch. Nó kiểm tra khả năng của hệ thống trong việc đáp ứng nhu cầu ngày càng tăng.
Kiểm thử khả năng mở rộng là một loại hình con của kiểm tra năng suấtVì vậy, nó tập trung vào hành vi của một ứng dụng khi được triển khai trên một hệ thống lớn hơn hoặc khi hoạt động dưới tải trọng quá mức. Kỹ thuật phần mềmKiểm thử khả năng mở rộng (Scalability Testing) đo lường điểm mà tại đó ứng dụng ngừng mở rộng và xác định nguyên nhân dẫn đến điều đó.
Tại sao cần kiểm thử khả năng mở rộng?
Các vấn đề về dung lượng hiếm khi xuất hiện trong quá trình kiểm thử chức năng. Chúng thường nổi lên vào ngày giao dịch bận rộn nhất trong năm, khi một chiến dịch tiếp thị được triển khai, hoặc khi một tập dữ liệu đã âm thầm phát triển trong hai năm cuối cùng làm chậm mọi truy vấn. Kiểm thử khả năng mở rộng giúp phát hiện những giới hạn đó trong một môi trường được kiểm soát trước tiên. Cụ thể, nó giúp bạn:
- Xác định cách ứng dụng mở rộng quy mô khi khối lượng công việc tăng lên và điểm mà đường cong đó chững lại.
- Xác định giới hạn người dùng truy cập đồng thời cho ứng dụng web trước khi thời gian phản hồi trở nên không thể chấp nhận được.
- Xác định sự suy giảm hiệu năng phía máy khách và trải nghiệm người dùng cuối khi chịu tải, chẳng hạn như tốc độ hiển thị màn hình chậm.
- Xác định độ ổn định và khả năng suy giảm hiệu suất phía máy chủ, bao gồm tình trạng quá tải CPU, rò rỉ bộ nhớ và cạn kiệt nhóm kết nối.
Mối quan hệ này dễ hình dung nhất dưới dạng một đường cong: thông lượng tăng lên cùng với tải trọng gia tăng cho đến khi tài nguyên bị bão hòa, sau đó số lượng người dùng bổ sung chỉ làm tăng thêm độ dài hàng đợi.
Các loại kiểm thử khả năng mở rộng
Khả năng mở rộng không phải là một thuộc tính duy nhất, vì vậy một kế hoạch kiểm thử thường bao gồm nhiều khía cạnh. Bốn loại dưới đây là những loại mà hầu hết các nhóm đều đo lường, và hai loại đầu tiên quyết định hình dạng của môi trường kiểm thử.
| Kiểu | Cái gì được chia tỷ lệ? | Bài kiểm tra chứng minh điều gì? |
|---|---|---|
| Khả năng mở rộng theo chiều dọc (mở rộng quy mô) | CPU, bộ nhớ hoặc dung lượng lưu trữ được thêm vào một máy chủ duy nhất | Một máy được nâng cấp có thể hấp thụ thêm bao nhiêu tải trọng, và giới hạn của máy đơn nút nằm ở đâu. |
| Khả năng mở rộng theo chiều ngang (mở rộng quy mô) | Các máy chủ, container hoặc node bổ sung phía sau bộ cân bằng tải. | Liệu thông lượng có tăng gần như tỷ lệ thuận với số lượng nút được thêm vào hay không, hay liệu tài nguyên dùng chung có giới hạn mức thông lượng đó hay không. |
| Khả năng mở rộng chức năng | Các tính năng, mô-đun hoặc dịch vụ mới | Liệu chức năng bổ sung có thể được tích hợp mà không làm ảnh hưởng đến các giao dịch hiện có hay không? |
| Khả năng mở rộng quản trị | Người dùng, người thuê nhà, nhóm hoặc môi trường cần quản lý | Liệu quy trình tuyển dụng, phân quyền và giám sát có còn hoạt động hiệu quả khi tổ chức phát triển hay không? |
Mở rộng theo chiều dọc đơn giản hơn vì kiến trúc hiếm khi thay đổi, nhưng một máy đơn lẻ luôn có giới hạn. Mở rộng theo chiều ngang loại bỏ giới hạn đó và cải thiện khả năng chịu lỗi, nhưng đổi lại là độ trễ mạng, tính nhất quán dữ liệu và chi phí phối hợp — tất cả những điều này cần phải đo lường chứ không phải giả định.
Cần kiểm tra những gì trong kiểm thử khả năng mở rộng?
Khả năng mở rộng được đánh giá dựa trên các số liệu đo lường, chứ không phải ấn tượng ban đầu. Hãy ghi lại các thuộc tính sau ở mỗi bước tải để có thể thấy được xu hướng, chứ không chỉ là con số cuối cùng.
| đặc tính | Nó nói với bạn điều gì |
|---|---|
| Thời gian đáp ứng | Khoảng thời gian giữa yêu cầu của người dùng và phản hồi của hệ thống; khoảng thời gian này nên giữ nguyên khi số lượng yêu cầu đồng thời tăng lên. |
| Chuyển đổi màn hình | Tốc độ chuyển đổi giữa các trang hoặc giao diện khi tải trang. |
| Thông lượng | Khối lượng yêu cầu được xử lý trên mỗi đơn vị thời gian; một điểm bão hòa đánh dấu giới hạn khả năng mở rộng. |
| Đo thời gian | Thời gian phiên, thời gian khởi động lại, thời gian in, thời gian giao dịch và thời gian thực thi tác vụ. |
| Hiệu năng so với số lượng người dùng | Diễn biến của từng chỉ số khi số lượng người dùng đồng thời được thêm vào từng bước. |
| Yêu cầu mức giá | Số yêu cầu mỗi giây, số giao dịch mỗi giây và số lượt truy cập mỗi giây |
| Sử dụng mạng | Băng thông tiêu thụ và độ trễ gói dữ liệu giữa các tầng |
| Sử dụng CPU và bộ nhớ | Chi phí tài nguyên cho mỗi giao dịch; con số tăng dần thường báo hiệu sự rò rỉ. |
| Bộ đếm máy chủ web | Số lượng yêu cầu và phản hồi mỗi giây, độ sâu hàng đợi và số kết nối bị từ chối. |
| Hiệu suất dưới tải | Hành vi tổng hợp khi tất cả các chỉ số được đọc cùng nhau ở thời điểm cao nhất. |
Chiến lược kiểm thử cho kiểm thử khả năng mở rộng
Chiến lược kiểm thử khả năng mở rộng (Scalability Testing) sẽ khác nhau tùy thuộc vào loại ứng dụng đang được kiểm thử. Nếu một ứng dụng truy cập vào... cơ sở dữ liệuCác thông số kiểm thử sẽ bao gồm kích thước cơ sở dữ liệu so với số lượng người dùng, v.v.
Điều kiện tiên quyết để kiểm tra khả năng mở rộng
- Khả năng phân phối tải — Kiểm tra xem công cụ kiểm tra tải có cho phép tạo tải từ nhiều máy móc và điều khiển từ một điểm trung tâm hay không.
- Operahệ thống ting — Kiểm tra xem sao các hệ điều hành Các tác nhân tạo tải và tác nhân kiểm thử tải hoạt động dưới chế độ đó.
- Bộ xử lý — Kiểm tra xem loại CPU nào cần thiết cho tác nhân người dùng ảo và máy chủ kiểm thử tải.
- Bộ nhớ — Kiểm tra xem bao nhiêu bộ nhớ là đủ cho tác nhân người dùng ảo và máy chủ kiểm thử tải.
- Môi trường thử nghiệm — Kiểm tra xem môi trường thử nghiệm Quá trình sản xuất được mô phỏng khá sát sao để kết quả có thể được áp dụng.
Cách thực hiện kiểm tra khả năng mở rộng
- Xác định một quy trình lặp lại để thực hiện các bài kiểm tra khả năng mở rộng trong suốt vòng đời của ứng dụng.
- Xác định tiêu chí về khả năng mở rộng
- Danh sách rút gọn các công cụ phần mềm cần thiết để chạy thử nghiệm tải
- Đặt môi trường thử nghiệm và định cấu hình phần cứng cần thiết để thực hiện kiểm tra khả năng mở rộng
- Lập kế hoạch cho các kịch bản kiểm thử cũng như các bài kiểm thử khả năng mở rộng.
- Tạo và xác minh tập lệnh người dùng ảo
- Tạo và xác minh các kịch bản kiểm tra tải
- Thực hiện các bài kiểm tra
- Đánh giá kết quả
- Tạo các báo cáo cần thiết
Kế hoạch kiểm tra khả năng mở rộng
Trước khi thực sự tạo các bài kiểm thử, hãy xây dựng một kế hoạch kiểm thử chi tiết. Đây là một bước quan trọng để đảm bảo rằng bài kiểm thử đáp ứng yêu cầu của ứng dụng.
Sau đây là các thuộc tính để tạo ra một Kế hoạch kiểm tra để kiểm tra khả năng mở rộng.
- Các bước cho tập lệnhKịch bản kiểm thử cần có các bước chi tiết để xác định chính xác các hành động mà người dùng sẽ thực hiện.
- Dữ liệu thời gian chạyKế hoạch kiểm thử cần xác định bất kỳ dữ liệu nào cần thiết trong quá trình vận hành để tương tác với ứng dụng.
- Kiểm tra theo hướng dữ liệuNếu các đoạn mã cần dữ liệu thay đổi trong quá trình chạy, bạn cần hiểu rõ tất cả các trường yêu cầu dữ liệu này.
Ví dụ về kiểm thử khả năng mở rộng
Hãy xem xét một cửa hàng trực tuyến dự kiến có 2,000 người mua sắm cùng lúc trong một đợt giảm giá theo mùa. Nhóm thống nhất một tiêu chí đạt yêu cầu trước tiên: giao dịch thanh toán phải hoàn tất trong vòng chưa đầy ba giây đối với 95% người dùng, với tỷ lệ lỗi dưới một phần trăm.
Bài kiểm tra sau đó chạy cùng một kịch bản duyệt-tìm kiếm-giỏ hàng-thanh toán với 250, 500, 1,000, 1,500 và 2,000 người dùng ảo. Thời gian phản hồi duy trì ở mức gần hai giây với 1,000 người dùng, tăng lên 2.8 giây ở 1,500 người dùng và đạt chín giây ở 2,000 người dùng trong khi CPU cơ sở dữ liệu hoạt động ở mức 98%. Do đó, giới hạn khả năng mở rộng là khoảng 1,500 người dùng, và điểm nghẽn nằm ở tầng cơ sở dữ liệu — chứ không phải các máy chủ ứng dụng mà nhóm đã lên kế hoạch bổ sung.
Công cụ kiểm tra khả năng mở rộng
Kiểm thử khả năng mở rộng cần một công cụ có thể tạo tải từ nhiều máy cùng một lúc và báo cáo kết quả tập trung. Việc lựa chọn thường phụ thuộc vào ngôn ngữ lập trình chính của nhóm và các giao thức đang được kiểm thử.
| Công cụ | Scripting | Phù hợp nhất với |
|---|---|---|
| Apache JMeter | Kế hoạch kiểm thử GUI cộng với XML, Java dựa | Hỗ trợ nhiều giao thức khác nhau, bao gồm JDBC, JMS, LDAP và SOAP. |
| Grafana k6 | JavaKịch bản hoặc TypeScript | Các bài kiểm thử API và microservice được tích hợp vào quy trình CI/CD. |
| Gatling | JavaNgôn ngữ chuyên dụng Kotlin hoặc Scala (DSL) | Số lượng người dùng ảo cao trên mỗi máy chủ tiêm mã độc, kèm theo báo cáo HTML chi tiết. |
| giống châu chấu | Trơn Python | Python các nhóm cần mở rộng khả năng của máy khách vượt ra ngoài giao thức HTTP. |
| LoadRunner | Các kịch bản giống C được ghi lại trong VuGen | Hệ thống máy tính doanh nghiệp quy mô lớn với các ứng dụng cũ và ứng dụng đóng gói sẵn. |
Các trình chạy được lưu trữ trên đám mây như BlazeMeterLoadView và Gatling Enterprise được xây dựng trên nền tảng của một số công cụ này và rất đáng để cân nhắc khi cần thực hiện thử nghiệm với hàng chục nghìn người dùng ảo hoặc lưu lượng truy cập từ nhiều khu vực địa lý khác nhau. Bạn có thể tìm hiểu thêm về danh mục này trong hướng dẫn. công cụ kiểm tra hiệu suất.
Những thách thức và phương pháp tốt nhất trong kiểm thử khả năng mở rộng
Kết quả về khả năng mở rộng đáng thất vọng nhất tracHãy quay lại phần thiết lập thử nghiệm thay vì ứng dụng. Đây là những vấn đề thường xuyên tái diễn, và những thói quen giúp ngăn ngừa chúng.
Những thách thức chung
- Môi trường có kích thước nhỏ — Một hệ thống thử nghiệm với bộ nhớ bằng một nửa so với hệ thống sản xuất lại báo cáo một điểm nghẽn không tồn tại trong môi trường sản xuất.
- Mô hình khối lượng công việc không thực tế — Các kịch bản không có thời gian suy nghĩ hoặc thay đổi dữ liệu sẽ truy cập vào bộ nhớ cache mà người dùng thực sẽ bỏ sót.
- Kết quả nhiễu — Tự động mở rộng quy mô, thu gom rác và phần cứng đám mây dùng chung khiến hai lần chạy giống hệt nhau cho kết quả khác nhau.
- Khả năng quan sát mỏng — Nếu không có số liệu thống kê phía máy chủ, kết quả chậm cho thấy có điều gì đó bị lỗi, nhưng không cho biết lỗi cụ thể là gì.
- Chi phí — Việc tạo ra lưu lượng truy cập đồng thời rất cao đòi hỏi một hệ thống máy phát tải riêng, điều này rất dễ dẫn đến việc thiếu ngân sách.
Các phương pháp hay nhất
- Trước khi chạy lần đầu, hãy thống nhất các tiêu chí đạt yêu cầu, chẳng hạn như tỷ lệ phần trăm thời gian phản hồi và mức trần tỷ lệ lỗi.
- Tăng tải theo từng bước đã lên kế hoạch và duy trì ở mỗi mức tải đủ lâu để hệ thống ổn định.
- Thay đổi dữ liệu kiểm thử cho mỗi người dùng ảo để việc lưu vào bộ nhớ đệm không làm sai lệch kết quả.
- Thu thập các chỉ số về ứng dụng, cơ sở dữ liệu và cơ sở hạ tầng cùng với các số liệu phía máy khách.
- Lưu trữ các kịch bản kiểm thử trong hệ thống quản lý phiên bản và chạy kiểm tra khả năng mở rộng ngắn gọn trên mỗi bản dựng, sau đó chạy toàn bộ quá trình trước khi phát hành.
- Hãy so sánh xu hướng giữa các phiên bản khác nhau thay vì chỉ đánh giá một báo cáo riêng lẻ.
Kiểm thử khả năng mở rộng so với kiểm thử tải
Hai khái niệm này thường bị nhầm lẫn vì cả hai đều tạo ra tải trọng. Sự khác biệt nằm ở câu hỏi mà mỗi khái niệm trả lời: Kiểm thử khả năng mở rộng hỏi hệ thống có thể phát triển đến mức nào, trong khi đó, kiểm thử khả năng mở rộng lại hỏi hệ thống có thể phát triển đến mức nào, trong khi kiểm thử khả năng mở rộng hỏi hệ thống có thể phát triển đến mức nào, còn kiểm thử khả năng mở rộng hỏi hệ thống có thể phát triển đến mức nào, trong khi kiểm thử khả năng mở rộng hỏi hệ thống có thể phát triển đến mức nào, trong kiểm tra tải đặt câu hỏi liệu nó có đáp ứng được khối lượng công việc đã dự kiến hay không.
| Cơ sở | Kiểm tra khả năng mở rộng | Kiểm tra Tải |
|---|---|---|
| Tập trung | Nó tập trung vào hiệu suất của các trang web, phần mềm, phần cứng và ứng dụng của bạn khi có những thay đổi về kích thước hoặc dung lượng hệ thống để đáp ứng nhu cầu ngày càng tăng. | Kiểm thử tải tập trung vào việc kiểm tra ứng dụng dưới tải trọng lớn, để xác định điểm mà thời gian phản hồi của hệ thống bị suy giảm. |
| Mẫu tải | Tải trọng được tăng dần từng bước, và tài nguyên có thể được bổ sung giữa các bước. | Tải được duy trì ở mức đỉnh dự kiến trong một khoảng thời gian cố định. |
| Câu hỏi đã được trả lời | Hệ thống này có thể phát triển đến mức nào và những giới hạn nào đang đặt ra cho nó? | Liệu hệ thống này có đạt được các mục tiêu đã đề ra hiện nay không? |
| Đầu ra điển hình | Giới hạn về khả năng mở rộng, điểm nghẽn và kế hoạch năng lực | Đạt hay không đạt mục tiêu về thời gian phản hồi và thông lượng. |
Cả hai đều nằm dưới kiểm thử phi chức năng ô dù bên cạnh căng thẳng thử nghiệm, kiểm tra đột biến, kiểm tra độ bền và kiểm tra khối lượngvà một chiến lược tối ưu hiệu năng hiệu quả thường chạy nhiều chiến lược như vậy trên cùng một kịch bản.
