Một trong những vấn đề mà các nhà cung cấp phần mềm đa sản phẩm thường gặp phải là sự trùng lặp năng lực của các kỹ sư - nhà phát triển, người thử nghiệm và quản trị viên cơ sở hạ tầng - trong hầu hết mọi nhóm. Điều này cũng áp dụng cho các kỹ sư đắt tiền - chuyên gia trong lĩnh vực thử tải.
Thay vì thực hiện các nhiệm vụ trực tiếp và sử dụng kinh nghiệm độc đáo của mình để xây dựng quy trình kiểm thử tải, chọn phương pháp, số liệu tối ưu và viết autotest phù hợp với cấu hình tải, các kỹ sư thường phải triển khai cơ sở hạ tầng thử nghiệm từ đầu, định cấu hình công cụ tải và nhúng chúng mình trong hệ thống CI, thiết lập giám sát và công bố báo cáo.
Bạn có thể tìm giải pháp cho một số vấn đề về tổ chức trong thử nghiệm mà chúng tôi sử dụng tại Công nghệ Tích cực trong . Và trong phần này, tôi sẽ nói về khả năng tích hợp các bài kiểm tra tải vào một đường ống CI chung bằng cách sử dụng khái niệm “kiểm tra tải như một dịch vụ” (load testing as a service). Bạn sẽ tìm hiểu cách thức và hình ảnh docker nào của nguồn tải có thể được sử dụng trong quy trình CI; cách kết nối các nguồn tải với dự án CI của bạn bằng mẫu bản dựng; quy trình thử nghiệm trông như thế nào để chạy thử nghiệm tải và xuất bản kết quả. Bài viết có thể hữu ích cho các kỹ sư kiểm thử phần mềm và kỹ sư tự động hóa trong CI, những người đang suy nghĩ về kiến trúc của hệ thống tải của họ.
Bản chất của khái niệm
Khái niệm kiểm tra tải như một dịch vụ ngụ ý khả năng tích hợp các công cụ tải Apache JMeter, Yandex.Tank và các khung của riêng bạn vào một hệ thống tích hợp liên tục tùy ý. Bản trình diễn sẽ dành cho GitLab CI, nhưng các nguyên tắc là chung cho tất cả các hệ thống CI.
Kiểm tra tải dưới dạng dịch vụ là một dịch vụ tập trung để kiểm tra tải. Thử nghiệm tải được chạy trong nhóm đại lý chuyên dụng, kết quả được xuất bản tự động trong Trang GitLab, Influx DB và Grafana hoặc trong các hệ thống báo cáo thử nghiệm (TestRail, ReportPortal, v.v.). Tự động hóa và mở rộng quy mô được triển khai đơn giản nhất có thể - bằng cách thêm và tham số hóa mẫu gitlab-ci.yml thông thường trong dự án GitLab CI.
Ưu điểm của phương pháp này là toàn bộ cơ sở hạ tầng CI, tác nhân tải, hình ảnh docker của nguồn tải, đường ống thử nghiệm và báo cáo xuất bản được duy trì bởi bộ phận tự động hóa tập trung (kỹ sư DevOps), trong khi các kỹ sư kiểm tra tải có thể tập trung nỗ lực vào phát triển thử nghiệm và phân tích kết quả của họ, mà không cần giải quyết các vấn đề về cơ sở hạ tầng.
Để đơn giản hóa mô tả, chúng tôi sẽ giả định rằng ứng dụng đích hoặc máy chủ đang thử nghiệm đã được triển khai và định cấu hình trước (có thể sử dụng các tập lệnh tự động trong Python, SaltStack, Ansible, v.v. cho việc này). Sau đó, toàn bộ khái niệm về kiểm tra tải như một dịch vụ phù hợp với ba giai đoạn: chuẩn bị, thử nghiệm, công bố báo cáo. Thêm chi tiết về sơ đồ (tất cả các hình ảnh đều có thể nhấp):
Các khái niệm và định nghĩa cơ bản trong thử nghiệm tải
Khi thực hiện kiểm tra tải trọng, chúng tôi cố gắng tuân thủ , sử dụng thuật ngữ thích hợp và số liệu được đề xuất. Tôi sẽ đưa ra một danh sách ngắn các khái niệm và định nghĩa chính trong kiểm thử tải.
đại lý tải - một máy ảo mà ứng dụng sẽ được khởi chạy - nguồn tải (Apache JMeter, Yandex.Tank hoặc mô-đun tải tự viết).
Mục tiêu kiểm tra (mục tiêu) - máy chủ hoặc ứng dụng được cài đặt trên máy chủ sẽ phải chịu tải.
Kịch bản kiểm thử (test case) - một tập hợp các bước được tham số hóa: hành động của người dùng và phản ứng dự kiến đối với những hành động này, với các yêu cầu và phản hồi mạng cố định, tùy thuộc vào các tham số đã chỉ định.
Hồ sơ hoặc kế hoạch tải (hồ sơ) - tại (Phần 4.2.4, trang 43) cấu hình tải xác định các số liệu quan trọng đối với một thử nghiệm cụ thể và các tùy chọn để thay đổi các tham số tải trong quá trình thử nghiệm. Bạn có thể xem các ví dụ về cấu hình trong hình.
Bài kiểm tra — một tập lệnh với một bộ tham số được xác định trước.
Kế hoạch kiểm thử (test-plan) - một tập hợp các bài kiểm tra và một hồ sơ tải.
Testran (chạy thử) - một lần chạy thử nghiệm với kịch bản tải được thực hiện đầy đủ và báo cáo nhận được.
Yêu cầu mạng (request) — Một yêu cầu HTTP được gửi từ một tác nhân đến một mục tiêu.
Phản hồi của mạng (phản hồi) — Một phản hồi HTTP được gửi từ đích đến tác nhân.
Mã phản hồi HTTP (trạng thái phản hồi HTTP) - mã phản hồi tiêu chuẩn từ máy chủ ứng dụng.
Một giao dịch là một chu trình yêu cầu-phản hồi hoàn chỉnh. Một giao dịch được tính từ khi bắt đầu gửi yêu cầu (request) đến khi hoàn thành nhận phản hồi (response).
Trạng thái giao dịch - liệu có thể hoàn thành thành công chu trình yêu cầu-phản hồi hay không. Nếu có bất kỳ lỗi nào trong chu kỳ này, thì toàn bộ giao dịch được coi là không thành công.
Thời gian đáp ứng (độ trễ) - thời gian từ khi kết thúc gửi yêu cầu (request) đến khi bắt đầu nhận được phản hồi (response).
Tải chỉ số - các đặc tính của dịch vụ có tải và tác nhân tải được xác định trong quá trình thử tải.
Các chỉ số cơ bản để đo các thông số tải
Một số phương pháp thường được sử dụng và khuyến nghị nhất (p. 36, 52) các số liệu được hiển thị trong bảng bên dưới. Các chỉ số tương tự cho tác nhân và mục tiêu được liệt kê trên cùng một dòng.
Số liệu cho tác nhân tải
Số liệu của hệ thống đích hoặc ứng dụng đang được thử nghiệm dưới tải
Số vCPU và ký ức RAM,
Đĩa - Đặc tính "sắt" của tác nhân tải
CPU, Sử dụng bộ nhớ, đĩa - tính năng động của CPU, bộ nhớ và tải đĩa
trong quá trình thử nghiệm. Thường được đo bằng tỷ lệ phần trăm của
giá trị khả dụng tối đa
thông lượng mạng (trên tác nhân tải) - thông lượng
giao diện mạng trên máy chủ,
nơi cài đặt tác nhân tải.
Thường được đo bằng byte trên giây (bps)
thông lượng mạng(trên mục tiêu) - băng thông giao diện mạng
trên máy chủ mục tiêu. Thường được đo bằng byte trên giây (bps)
người dùng ảo- số lượng người dùng ảo,
thực hiện các kịch bản tải và
bắt chước hành động của người dùng thực
Trạng thái người dùng ảo, Passed/Failed/Total — số lượng thành công và
trạng thái không thành công của người dùng ảo
cho các kịch bản tải, cũng như tổng số của chúng.
Người ta thường kỳ vọng rằng tất cả người dùng đều có thể hoàn thành
tất cả các nhiệm vụ của bạn được chỉ định trong cấu hình tải.
Bất kỳ lỗi nào cũng có nghĩa là người dùng thực sẽ không thể
giải quyết vấn đề của bạn khi làm việc với hệ thống
Yêu cầu mỗi giây (phút)- số lượng yêu cầu mạng mỗi giây (hoặc phút).
Một đặc điểm quan trọng của tác nhân tải là số lượng yêu cầu mà nó có thể tạo ra.
Trên thực tế, đây là sự bắt chước quyền truy cập vào ứng dụng của người dùng ảo
Phản hồi mỗi giây (phút)
- số lượng phản hồi của mạng mỗi giây (hoặc phút).
Một đặc điểm quan trọng của dịch vụ mục tiêu: bao nhiêu
tạo và gửi phản hồi cho các truy vấn với
chất tải
Trạng thái phản hồi HTTP- số lượng mã phản hồi khác nhau
từ máy chủ ứng dụng mà tác nhân tải nhận được.
Ví dụ: 200 OK có nghĩa là cuộc gọi thành công,
và 404 - không tìm thấy tài nguyên
Độ trễ (thời gian phản hồi) - thời gian từ cuối
gửi yêu cầu (request) trước khi bắt đầu nhận phản hồi (response).
Thường được đo bằng mili giây (ms)
Thời gian phản hồi giao dịch- thời gian của một giao dịch đầy đủ,
hoàn thành chu kỳ yêu cầu-phản hồi.
Đây là thời gian tính từ lúc bắt đầu gửi yêu cầu (request)
cho đến khi hoàn thành nhận được phản hồi (response).
Thời gian giao dịch có thể tính bằng giây (hoặc phút)
theo nhiều cách: xem xét mức tối thiểu,
tối đa, trung bình và, ví dụ, phân vị thứ 90.
Các bài đọc tối thiểu và tối đa là cực đoan
trạng thái hoạt động của hệ thống.
Phân vị thứ chín mươi được sử dụng phổ biến nhất,
vì nó cho thấy hầu hết người dùng,
vận hành thoải mái ở ngưỡng hiệu suất hệ thống
Giao dịch mỗi giây (phút) - số lượng hoàn thành
giao dịch mỗi giây (phút),
nghĩa là, ứng dụng có thể chấp nhận bao nhiêu và
xử lý các yêu cầu và đưa ra các phản hồi.
Trên thực tế, đây là thông lượng của hệ thống
Trạng thái giao dịch , Đạt / Không đạt / Tổng - số
thành công, không thành công và tổng số giao dịch.
Đối với người dùng thực không thành công
giao dịch sẽ thực sự có nghĩa là
không có khả năng làm việc với hệ thống đang tải
Sơ đồ kiểm tra tải
Khái niệm về kiểm tra tải rất đơn giản và bao gồm ba giai đoạn chính mà tôi đã đề cập: Chuẩn bị-Kiểm tra-Báo cáo, nghĩa là chuẩn bị các mục tiêu thử nghiệm và đặt tham số cho các nguồn tải, sau đó thực hiện các thử nghiệm tải và cuối cùng là tạo và xuất bản báo cáo thử nghiệm.
Ghi chú sơ đồ:
- QA.Tester là chuyên gia trong lĩnh vực kiểm thử tải,
- Mục tiêu là ứng dụng đích mà bạn muốn biết hành vi của nó khi tải.
Bộ phân loại các thực thể, các giai đoạn và các bước trong sơ đồ
Các giai đoạn và bước
Chuyện gì đang xảy ra
Có gì ở lối vào
đầu ra là gì
Chuẩn bị: giai đoạn chuẩn bị cho thử nghiệm
thông số tải
Cài đặt và khởi tạo
người sử dụng
thông số tải,
lựa chọn các chỉ số và
chuẩn bị kế hoạch kiểm tra
(tải hồ sơ)
Tùy chọn tùy chỉnh cho
khởi tạo đại lý tải
Kế hoạch kiểm tra
Mục đích thử nghiệm
VM
triển khai đám mây
máy ảo với
đặc điểm cần thiết
Cài đặt VM cho tác nhân tải
Kịch bản tự động hóa cho
tạo máy ảo
VM được cấu hình trong
đám mây
Env
Thiết lập và chuẩn bị hệ điều hành
môi trường cho
công việc đại lý tải
Cài đặt môi trường cho
đại lý tải
Kịch bản tự động hóa cho
cài đặt môi trường
Chuẩn bị sẵn môi trường:
Hệ điều hành, dịch vụ và ứng dụng,
cần thiết cho công việc
đại lý tải
tảiAgents
Cài đặt, cấu hình và tham số hóa
chất tải.
Hoặc tải xuống một hình ảnh docker từ
nguồn tải được cấu hình sẵn
Tải hình ảnh docker nguồn
(YAT, JM hoặc framework tự viết)
Cài đặt
đại lý tải
Thiết lập và sẵn sàng
để làm việc đại lý tải
Kiểm tra: giai đoạn thực hiện kiểm tra tải. Nguồn là tác nhân tải được triển khai trong nhóm tác nhân chuyên dụng cho GitLab CI
Phụ tải
Khởi động tác nhân tải
với kế hoạch thử nghiệm đã chọn
và thông số tải
Tùy chọn người dùng
để khởi tạo
đại lý tải
Kế hoạch kiểm tra
Mục đích thử nghiệm
Nhật ký thực thi
kiểm tra tải
Nhật ký hệ thống
Động lực của những thay đổi trong số liệu mục tiêu và tác nhân tải
Chạy đại lý
Thực hiện đại lý
vô số kịch bản thử nghiệm
phù hợp với
tải hồ sơ
Tải tương tác đại lý
cho mục đích thử nghiệm
Kế hoạch kiểm tra
Mục đích thử nghiệm
Logs
Bộ sưu tập nhật ký "thô"
trong quá trình thử tải:
tải hồ sơ hoạt động đại lý,
trạng thái của mục tiêu thử nghiệm
và VM đang chạy tác nhân
Nhật ký thực thi
kiểm tra tải
Nhật ký hệ thống
Metrics
Thu thập số liệu "thô" trong quá trình thử nghiệm
Động lực của những thay đổi trong số liệu mục tiêu
và đại lý tải
Báo cáo: giai đoạn chuẩn bị báo cáo thử nghiệm
Máy phát điện
xử lý thu thập
hệ thống tải và
hệ thống giám sát "thô"
số liệu và nhật ký
Hình thành báo cáo trong
hình thức con người có thể đọc được
có thể với các yếu tố
các nhà phân tích
Nhật ký thực thi
kiểm tra tải
Nhật ký hệ thống
Động lực của những thay đổi trong số liệu
tác nhân mục tiêu và tải
Nhật ký "thô" đã xử lý
ở dạng phù hợp với
tải lên bộ nhớ ngoài
Báo cáo tải trọng tĩnh,
con người có thể đọc được
Xuất bản
Công bố báo cáo
về tải
thử nghiệm bên ngoài
dịch vụ
Chế biến "thô"
nhật ký ở định dạng phù hợp
để dỡ hàng ra bên ngoài
kho lưu trữ
Đã lưu ở bên ngoài
báo cáo lưu trữ trên
tải, phù hợp
để phân tích con người
Kết nối nguồn tải trong mẫu CI
Hãy chuyển sang phần thực hành. Tôi muốn trình bày một số dự án trong công ty chúng tôi đã triển khai khái niệm kiểm tra tải như một dịch vụ.
Đầu tiên, với sự trợ giúp của các kỹ sư DevOps, chúng tôi đã tạo một nhóm tác nhân chuyên dụng trong GitLab CI để chạy thử nghiệm tải. Để không nhầm lẫn chúng trong các mẫu với các mẫu khác, chẳng hạn như nhóm lắp ráp, chúng tôi đã thêm thẻ vào các tác nhân này, : trọng tải. Bạn có thể sử dụng bất kỳ thẻ dễ hiểu nào khác. Họ hỏi Người chạy GitLab CI.
Làm thế nào để tìm ra sức mạnh cần thiết bằng phần cứng? Các đặc điểm của tác nhân tải - đủ số lượng vCPU, RAM và Đĩa - có thể được tính toán dựa trên thực tế là Docker, Python (đối với Yandex.Tank), tác nhân GitLab CI, Java (đối với Apache JMeter) sẽ chạy trên tác nhân . Đối với Java trong JMeter, bạn cũng nên sử dụng tối thiểu 512 MB RAM và giới hạn trên là .
Do đó, dựa trên kinh nghiệm của chúng tôi, chúng tôi khuyên bạn nên sử dụng ít nhất 4 vCPU, RAM 4 GB, SSD 60 GB cho các tác nhân tải. Thông lượng của card mạng được xác định dựa trên các yêu cầu của cấu hình tải.
Chúng tôi chủ yếu sử dụng hai nguồn tải - hình ảnh docker của Apache JMeter và Yandex.Tank.
là một công cụ nguồn mở từ Yandex để kiểm tra tải. Kiến trúc mô-đun của nó dựa trên trình tạo yêu cầu HTTP dựa trên lượt truy cập không đồng bộ hiệu suất cao của Phantom. Xe tăng có chức năng giám sát tích hợp các tài nguyên của máy chủ đang được kiểm tra thông qua giao thức SSH, có thể tự động dừng kiểm tra trong các điều kiện được chỉ định, có thể hiển thị kết quả cả trong bảng điều khiển và ở dạng biểu đồ, bạn có thể kết nối các mô-đun của mình vào nó để mở rộng chức năng. Nhân tiện, chúng tôi đã sử dụng Tank khi nó chưa phổ biến. Trong bài viết "» bạn có thể đọc câu chuyện về cách chúng tôi thực hiện kiểm thử tải với nó vào năm 2013 là một trong những sản phẩm của công ty chúng tôi.
là một công cụ kiểm tra tải mã nguồn mở từ Apache. Nó có thể được sử dụng tốt như nhau để thử nghiệm cả ứng dụng web tĩnh và động. JMeter hỗ trợ một số lượng lớn các giao thức và cách để tương tác với các ứng dụng: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, v.v.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) và IMAP(S), cơ sở dữ liệu thông qua JDBC, có thể thực thi các lệnh shell và làm việc với các đối tượng Java. JMeter có một IDE để tạo, sửa lỗi và thực hiện kế hoạch kiểm thử. Ngoài ra còn có một CLI cho hoạt động dòng lệnh trên bất kỳ hệ điều hành tương thích Java nào (Linux, Windows, Mac OS X). Công cụ này có thể tự động tạo báo cáo kiểm tra HTML.
Để dễ sử dụng trong công ty của chúng tôi, để người thử nghiệm có khả năng tự thay đổi và thêm môi trường, chúng tôi đã tạo các bản dựng hình ảnh docker của các nguồn tải trên GitLab CI với việc xuất bản lên nội bộ . Điều này giúp kết nối chúng trong đường ống để kiểm tra tải nhanh hơn và dễ dàng hơn. Cách thực hiện docker Push vào sổ đăng ký qua GitLab CI - xem .
Chúng tôi đã lấy tệp docker cơ bản này cho Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Và đối với Apache JMeter cái này:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Bạn có thể đọc cách hệ thống tích hợp liên tục của chúng tôi hoạt động trong bài viết "'.
Mẫu và đường dẫn
Một ví dụ về mẫu để tiến hành thử tải có sẵn trong dự án . Trong Bạn có thể đọc hướng dẫn sử dụng mẫu. Trong chính mẫu (tệp ) có ghi chú về những gì mỗi bước chịu trách nhiệm.
Mẫu rất đơn giản và thể hiện ba giai đoạn kiểm tra tải được mô tả trong sơ đồ trên: chuẩn bị, kiểm tra và xuất bản báo cáo. Chịu trách nhiệm về việc này : Chuẩn bị, kiểm tra và báo cáo.
- Sân khấu nên được sử dụng để định cấu hình trước các mục tiêu thử nghiệm hoặc kiểm tra tính khả dụng của chúng. Môi trường cho các nguồn tải không cần phải được định cấu hình, chúng được tạo sẵn dưới dạng hình ảnh docker và được đăng trong sổ đăng ký docker: chỉ cần chỉ định phiên bản mong muốn ở giai đoạn Kiểm tra. Nhưng bạn có thể xây dựng lại chúng và tạo các hình ảnh đã sửa đổi của riêng mình.
- Sân khấu được sử dụng để chỉ định nguồn tải, chạy thử nghiệm và lưu trữ các thành phần thử nghiệm. Bạn có thể chọn bất kỳ nguồn tải nào: Yandex.Tank, Apache JMeter, của riêng bạn hoặc tất cả cùng nhau. Để vô hiệu hóa các nguồn không cần thiết, chỉ cần bình luận hoặc xóa công việc. Điểm vào cho các nguồn tải:
- Các tham số khởi chạy cho Yandex.Tank được chỉ định trong tệp .,
- Các tham số khởi động Apache JMeter được chỉ định trong tệp .
Lưu ý: Mẫu cấu hình lắp ráp được sử dụng để thiết lập tương tác với hệ thống CI và không ngụ ý đặt logic kiểm tra trong đó. Đối với các bài kiểm tra, điểm vào được chỉ định, nơi đặt tập lệnh bash điều khiển. Phương pháp chạy thử nghiệm, tạo báo cáo và bản thân các kịch bản thử nghiệm phải được thực hiện bởi các kỹ sư QA. Trong bản demo, đối với cả hai nguồn tải, yêu cầu trang chính Yandex được sử dụng làm thử nghiệm đơn giản nhất. Các tập lệnh và tham số kiểm tra nằm trong thư mục .
- Tại sân khấu bạn cần mô tả cách xuất bản kết quả kiểm tra thu được ở giai đoạn Kiểm tra lên các kho lưu trữ bên ngoài, chẳng hạn như lên Trang GitLab hoặc các hệ thống báo cáo đặc biệt. Trang GitLab yêu cầu thư mục ./public không trống và chứa ít nhất một tệp index.html sau khi kiểm tra hoàn tất. Bạn có thể đọc về các sắc thái của dịch vụ Trang GitLab. .
Ví dụ về cách xuất dữ liệu:
- từ JMeter đến ,
- từ Yandex.Tank sang .
Hướng dẫn thiết lập đăng bài:
- thống kê HTML trong ,
- đến InfluxDB và sau đó đến .
Trong ví dụ demo, đường ống có kiểm tra tải và hai nguồn tải (bạn có thể tắt nguồn không cần thiết) trông như sau:
Apache JMeter có thể tự tạo báo cáo HTML, vì vậy sẽ có lợi hơn nếu lưu nó trong Trang GitLab bằng các công cụ tiêu chuẩn. Đây là cách báo cáo JMeter của Apache trông giống như:
Trong ví dụ demo cho Yandex.Tank, bạn sẽ chỉ thấy trong phần dành cho Trang GitLab. Trong quá trình thử nghiệm, Tank có thể lưu kết quả vào cơ sở dữ liệu InfluxDB và từ đó chúng có thể được hiển thị, chẳng hạn như trong Grafana (cấu hình được thực hiện trong tệp ). Đây là cách báo cáo của Tank trong Grafana:
Tóm tắt thông tin
Trong bài viết, tôi đã nói về khái niệm "kiểm thử tải như một dịch vụ" (load testing as a service). Ý tưởng chính là sử dụng cơ sở hạ tầng của nhóm tác nhân tải được định cấu hình trước, hình ảnh docker của nguồn tải, hệ thống báo cáo và một đường dẫn kết hợp chúng trong GitLab CI dựa trên mẫu .gitlab-ci.yml đơn giản (ví dụ ). Tất cả điều này được hỗ trợ bởi một nhóm nhỏ các kỹ sư tự động hóa và được nhân rộng theo yêu cầu của các nhóm sản phẩm. Tôi hy vọng điều này sẽ giúp bạn trong việc chuẩn bị và thực hiện một kế hoạch tương tự trong công ty của bạn. Cảm ơn bạn đã chú ý!
Tái bút: Tôi muốn gửi lời cảm ơn sâu sắc đến các đồng nghiệp của tôi, Sergey Kurbanov và Nikolai Yusev, vì đã hỗ trợ kỹ thuật trong việc triển khai khái niệm thử nghiệm tải như một dịch vụ trong công ty của chúng tôi.
Tác giả: - Phó Trưởng phòng Công nghệ và Quy trình Phát triển (DevOps) tại Positive Technologies
Nguồn: www.habr.com