Еден од проблемите со кои често се соочуваат продавачите на софтвер со повеќе производи е дуплирањето на надлежностите на инженерите - програмери, тестери и администратори на инфраструктура - на речиси секој тим. Ова важи и за скапи инженери - специјалисти во областа на тестирање на оптоварување.
Наместо да ги извршуваат своите директни должности и да го користат своето уникатно искуство за да изградат процес на тестирање на оптоварување, да изберат методологија, оптимални метрики и да пишуваат автоматски тестови во согласност со профилите на оптоварување, инженерите честопати мора да распоредат инфраструктура за тестирање од почеток, да ги конфигурираат алатките за оптоварување и да ги вградат се во CI системи, воспоставуваат мониторинг и објавување на извештаи.
Можете да најдете решенија за некои организациски проблеми при тестирањето што ги користиме во Позитивни технологии во . И во овој, ќе зборувам за можноста за интегрирање на тестовите за оптоварување во заеднички CI гасовод користејќи го концептот „тестирање на оптоварување како услуга“ (тестирање на оптоварување како услуга). Ќе научите како и кои докерски слики од извори на оптоварување може да се користат во гасоводот CI; како да ги поврзете изворите на оптоварување со вашиот CI проект користејќи образец за изградба; како изгледа демо-цевководот за извршување на тестови за оптоварување и објавување на резултатите. Статијата може да биде корисна за инженерите за тестирање софтвер и инженерите за автоматизација во CI кои размислуваат за архитектурата на нивниот систем за оптоварување.
Суштината на концептот
Концептот на тестирање на оптоварување како услуга подразбира можност за интегрирање на алатките за оптоварување Apache JMeter, Yandex.Tank и вашите сопствени рамки во произволен систем за континуирана интеграција. Демото ќе биде за GitLab CI, но принципите се заеднички за сите CI системи.
Тестирањето на оптоварување како услуга е централизирана услуга за тестирање на оптоварување. Тестовите за вчитување се извршуваат во наменски базени на агенти, резултатите се објавуваат автоматски во GitLab Pages, Influx DB и Grafana или во системите за известување за тестови (TestRail, ReportPortal итн.). Автоматизацијата и скалирањето се спроведуваат што е можно поедноставно - со додавање и параметризирање на вообичаениот шаблон gitlab-ci.yml во проектот GitLab CI.
Предноста на овој пристап е што целата CI инфраструктура, агентите за оптоварување, докерските слики на изворите на оптоварување, цевките за тестирање и објавувањето извештаи се одржуваат од централизиран оддел за автоматизација (инженери на DevOps), додека инженерите за тестирање на оптоварување можат да ги фокусираат своите напори на развој на тестови и анализа на нивните резултати, без да се занимаваат со инфраструктурни прашања.
За поедноставност на описот, ќе претпоставиме дека целната апликација или серверот што се тестира веќе се распоредени и конфигурирани однапред (за ова може да се користат автоматизирани скрипти во Python, SaltStack, Ansible итн.). Тогаш целиот концепт на тестирање на оптоварување како услуга се вклопува во три фази: подготовка, тестирање, објавување на извештаи. Повеќе детали за дијаграмот (сите слики може да се кликнат):
Основни концепти и дефиниции при тестирање на оптоварување
Кога вршиме тестови за оптоварување, се обидуваме да се придржуваме , користете соодветна терминологија и препорачана метрика. Ќе дадам краток список на главните концепти и дефиниции во тестирањето на оптоварувањето.
Вчитување агент - виртуелна машина на која ќе се стартува апликацијата - изворот на оптоварување (Apache JMeter, Yandex.Tank или самонапишан модул за оптоварување).
Цел на тестот (цел) - сервер или апликација инсталирана на серверот што ќе биде предмет на вчитување.
Тест сценарио (тест случај) - збир на параметризирани чекори: кориснички дејства и очекувани реакции на овие дејства, со фиксни мрежни барања и одговори, во зависност од наведените параметри.
Профил или вчитај план (профил) - во (Дел 4.2.4, стр. 43) профилите на оптоварување ги дефинираат метриките кои се клучни за одреден тест и опциите за менување на параметрите на оптоварувањето за време на тестот. Можете да видите примери на профили на сликата.
Тест — скрипта со однапред одреден сет на параметри.
Тест план (тест-план) - збир на тестови и профил на оптоварување.
Тестран (теструн) - една повторување на извршување на еден тест со целосно извршено сценарио за оптоварување и примениот извештај.
Мрежно барање (барање) — Барање HTTP испратено од агент до цел.
Мрежен одговор (одговор) — Одговор на HTTP испратен од целта до агентот.
Код за одговор на HTTP (статус на одговори на HTTP) - стандарден код за одговор од серверот на апликацијата.
Трансакцијата е целосен циклус на барање-одговор. Трансакцијата се брои од почетокот на испраќање барање (барање) до завршување на добивањето одговор (одговор).
Статус на трансакција - дали беше можно успешно да се заврши циклусот барање-одговор. Ако имало грешка во овој циклус, тогаш целата трансакција се смета за неуспешна.
Време на одговор (латентност) - времето од крајот на испраќањето барање (барање) до почетокот на добивањето одговор (одговор).
Вчитај метрика — карактеристиките на натоварената услуга и средството за оптоварување утврдени во процесот на тестирање на оптоварувањето.
Основни метрики за мерење на параметрите на оптоварување
Некои од најчесто користените и препорачаните во методологијата (стр. 36, 52) метриката е прикажана во табелата подолу. Слични метрики за агентот и целта се наведени на истата линија.
Метрика за агентот за оптоварување
Метрика на целниот систем или апликација што се тестира под оптоварување
Број vCPU и меморијата RAM меморија,
Диск - „железни“ карактеристики на средството за оптоварување
Процесорот, Меморија, употреба на диск - динамика на процесорот, меморијата и вчитувањето на дискот
во процес на тестирање. Обично се мери како процент од
максимални достапни вредности
пропусната моќ на мрежата (на оптоварување агент) - пропусната моќ
мрежен интерфејс на серверот,
каде што е инсталиран агентот за оптоварување.
Обично се мери во бајти во секунда (bps)
пропусната моќ на мрежата(на цел) - пропусен опсег на мрежен интерфејс
на целниот сервер. Обично се мери во бајти во секунда (bps)
Виртуелни корисници- бројот на виртуелни корисници,
спроведување на сценарија за оптоварување и
имитирајќи вистински кориснички дејства
Статус на виртуелни корисници, Положено/Неуспешно/Вкупно — број на успешни и
неуспешни статуси на виртуелни корисници
за сценарија за оптоварување, како и нивниот вкупен број.
Генерално се очекува дека сите корисници можеа да завршат
сите ваши задачи наведени во профилот за вчитување.
Секоја грешка ќе значи дека вистинскиот корисник нема да може
решете го вашиот проблем кога работите со системот
Барања во секунда (минута)- бројот на мрежни барања во секунда (или минута).
Важна карактеристика на агентот за оптоварување е колку барања може да генерира.
Всушност, ова е имитација на пристап до апликацијата од виртуелни корисници
Одговори во секунда (минута)
- бројот на мрежни одговори во секунда (или минута).
Важна карактеристика на целната услуга: колку
генерира и испраќа одговори на прашања со
агент за товарење
Статус на одговор на HTTP— број на различни кодови за одговор
од апликацискиот сервер добиен од агентот за оптоварување.
На пример, 200 OK значи успешен повик,
и 404 - дека ресурсот не е пронајден
Латентност (време на одговор) - време од крајот
испраќање барање (барање) пред да почне да добива одговор (одговор).
Обично се мери во милисекунди (ms)
Време на одговор на трансакцијата- време на една целосна трансакција,
завршување на циклусот барање-одговор.
Ова е време од почетокот на испраќањето на барањето (барањето)
до завршување на добивањето одговор (одговор).
Времето на трансакцијата може да се мери во секунди (или минути)
на неколку начини: земете го предвид минимумот,
максимум, просечен и, на пример, 90-ти перцентил.
Минималните и максималните отчитувања се екстремни
статус на перформансите на системот.
Деведесеттиот перцентил е најчесто користен,
како што покажува повеќето корисници,
удобно работи на прагот на перформансите на системот
Трансакции во секунда (минута) - бројот на комплетни
трансакции во секунда (минута),
односно колку апликацијата можела да прифати и
обработуваат барања и издаваат одговори.
Всушност, ова е пропусната моќ на системот
Статус на трансакција , Положено / Неуспешно / Вкупно - број
успешни, неуспешни и вкупниот број на трансакции.
За вистински корисници неуспешни
трансакцијата всушност ќе значи
неможност за работа со системот под оптоварување
Шематски дијаграм за тестирање на оптоварување
Концептот на тестирање на оптоварување е многу едноставен и се состои од три главни фази, кои веќе ги споменав: Подготви-Тест-Извештај, односно подготовка на цели за тестирање и поставување параметри за изворите на оптоварување, потоа извршување на тестови за оптоварување и, на крајот, генерирање и објавување извештај за тестирање.
Шематски белешки:
- QA.Tester е експерт за тестирање на оптоварување,
- Target е целната апликација за која сакате да го знаете нејзиното однесување под оптоварување.
Класификатор на ентитети, фази и чекори во дијаграмот
Фази и чекори
Што се случува
Што има на влезот
Кој е излезот
Подгответе: фаза на подготовка за тестирање
Оптоварување параметри
Поставување и иницијализација
корисник
параметри на оптоварување,
избор на метрика и
подготовка на тест план
(вчитај профил)
Прилагодени опции за
иницијализација на агентот за оптоварување
Тест план
Цел на тестирањето
VM
Распоредување на облак
виртуелна машина со
потребни карактеристики
Поставки за VM за агент за оптоварување
Скрипти за автоматизација за
Креирање VM
VM конфигуриран во
облак
Завист
Поставување и подготовка на ОС
средина за
работа агент за оптоварување
Поставки за животната средина за
агент за оптоварување
Скрипти за автоматизација за
поставки на околината
Подготвена околина:
ОС, услуги и апликации,
неопходни за работа
агент за оптоварување
LoadAgents
Инсталација, конфигурација и параметаризација
агент за товарење.
Или преземање докер слика од
претходно конфигуриран извор на оптоварување
Вчитајте ја сликата на докерот на изворот
(YAT, JM или само-напишана рамка)
Поставки
агент за оптоварување
Поставете и спремни
да работи оптоварување агент
Тест: фаза на извршување на тестови за оптоварување. Изворите се агенти за оптоварување распоредени во наменски базени на агенти за GitLab CI
Товар
Вклучување на агентот за вчитување
со избран план за тестирање
и параметри на оптоварување
Кориснички опции
за иницијализација
агент за оптоварување
Тест план
Цел на тестирањето
Дневници за извршување
тестови за оптоварување
Системски дневници
Динамика на промени во метриката на целите и агентот за оптоварување
Стартувај агенти
Извршување агент
многу тест скрипти
во согласност со
вчитај профил
Интеракција со агент за вчитување
заради тестирање
Тест план
Цел на тестирањето
Дневници
Колекција на „суровини“ трупци
за време на тестирање на оптоварување:
евиденција за активност на агентот за оптоварување,
состојба на целта за тестирање
и VM што го води агентот
Дневници за извршување
тестови за оптоварување
Системски дневници
Метрика
Собирање на „суровини“ метрики за време на тестирањето
Динамика на промени во метриката на целите
и агент за товарење
Извештај: фаза на подготовка на извештајот од тестот
Генератор
Собрана обработка
систем за товарење и
систем за следење „суров“
метрика и логови
Формирање на извештај во
читлива форма за луѓе
можно со елементи
аналитичари
Дневници за извршување
тестови за оптоварување
Системски дневници
Динамика на промени во метриката
цел и агент за оптоварување
Обработени „суровини“ логови
во формат погоден за
поставувања на надворешна меморија
Извештај за статичко оптоварување,
читлив за луѓе
Објави
Објавување на извештајот
за товарот
тестирање во екстерно
услуга
Обработени „суровини“
логови во соодветен формат
за истовар на надворешен
сводови
Зачувано во надворешно
извештаи за складирање на
оптоварување, погоден
за човечка анализа
Поврзување на извори на оптоварување во CI шаблон
Да преминеме на практичниот дел. Сакам да покажам како на некои проекти во компанијата го имплементиравме концептот на тестирање на оптоварување како услуга.
Прво, со помош на нашите инженери DevOps, создадовме посветен базен на агенти во GitLab CI за извршување на тестови за оптоварување. За да не ги мешаме во шаблони со други, како што се монтажни базени, додадовме ознаки на овие агенти, : оптоварување. Можете да користите други разбирливи ознаки. Тие прашуваат GitLab CI Runners.
Како да ја дознаете потребната моќност по хардвер? Карактеристиките на агентите за оптоварување - доволен број vCPU, RAM и диск - може да се пресметаат врз основа на фактот дека на агентот треба да работат Docker, Python (за Yandex.Tank), агентот GitLab CI, Java (за Apache JMeter). . За Java под JMeter, исто така се препорачува да користите минимум 512 MB RAM и, како горна граница, .
Така, врз основа на нашето искуство, препорачуваме да користите најмалку 4 vCPU, 4 GB RAM, 60 GB SSD за агенти за оптоварување. Пропусната моќ на мрежната картичка се одредува врз основа на барањата на профилот на оптоварување.
Ние главно користиме два извори на оптоварување - Apache JMeter и Yandex.Tank docker слики.
е алатка со отворен код од Yandex за тестирање на оптоварување. Неговата модуларна архитектура се заснова на асинхрониот генератор на барања за HTTP на Phantom со високи перформанси. Резервоарот има вградено следење на ресурсите на серверот што се тестира преку протоколот SSH, може автоматски да го прекине тестот под одредени услови, може да ги прикаже резултатите и во конзолата и во форма на графикони, можете да ги поврзете вашите модули да ја прошири функционалноста. Патем, Тенк го користевме кога сè уште не беше мејнстрим. Во статијата "» можете да ја прочитате приказната за тоа како извршивме тестирање на оптоварување со него во 2013 година е еден од производите на нашата компанија.
е алатка за тестирање на оптоварување со отворен код од Apache. Може да се користи подеднакво добро за тестирање и статични и динамички веб-апликации. JMeter поддржува огромен број протоколи и начини за интеракција со апликациите: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, итн.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) и IMAP(S), бази на податоци преку JDBC, можат да извршуваат команди на школка и да работат со Java објекти. JMeter има IDE за креирање, дебагирање и извршување на тест планови. Исто така, постои CLI за работа со командна линија на кој било оперативен систем компатибилен со Java (Linux, Windows, Mac OS X). Алатката може динамички да генерира извештај за HTML тест.
За лесно користење во рамките на нашата компанија, за способноста на самите тестери да ја менуваат и додадат околината, направивме конструкции на докер слики од извори на оптоварување на GitLab CI со објавување на интерната . Ова го прави побрзо и полесно нивното поврзување во цевководи за тестови на оптоварување. Како да направите докер притиснување до регистарот преку GitLab CI - видете .
Ја зедовме оваа основна докер-датотека за Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]И за Apache JMeter ова:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Можете да прочитате како функционира нашиот систем за континуирана интеграција во статијата "".
Шаблон и цевковод
Во проектот е достапен пример за образец за спроведување тестови за оптоварување . Во Можете да ги прочитате упатствата за користење на шаблонот. Во самиот шаблон (датотека ) има белешки за што е одговорен секој чекор.
Шаблонот е многу едноставен и ги демонстрира трите фази на тестирање на оптоварување опишани во дијаграмот погоре: подготовка, тестирање и објавување извештаи. Одговорен за ова : Подгответе, тестирајте и пријавите.
- Фаза треба да се користи за претходно конфигурирање на тест цели или проверка на нивната достапност. Околината за изворите на оптоварување не треба да се конфигурира, тие се претходно изградени како слики на докер и објавени во регистарот на докер: само наведете ја саканата верзија во фазата на тестирање. Но, можете да ги обновите и да направите свои модифицирани слики.
- Фаза се користи за одредување на изворот на оптоварување, извршување тестови и складирање на тест артефакти. Можете да изберете кој било извор на оптоварување: Yandex.Tank, Apache JMeter, свој или сите заедно. За да ги оневозможите непотребните извори, само коментирајте или избришете ја работата. Влезни точки за извори на оптоварување:
- Параметрите за стартување за Yandex.Tank се наведени во .,
- Параметрите за стартување на Apache JMeter се наведени во датотеката .
Забелешка: Шаблонот за конфигурација на склопот се користи за поставување на интеракција со системот CI и не подразбира поставување на тест логика во него. За тестови, се одредува влезната точка, каде што се наоѓа контролната баш скрипта. Начинот на извршување на тестови, генерирање извештаи и самите скрипти за тестирање мора да бидат имплементирани од инженери за QA. Во демото, за двата извори на оптоварување, барањето за главната страница на Yandex се користи како наједноставен тест. Скриптите и тест параметрите се во директориумот .
- На сцената треба да опишете како да ги објавите резултатите од тестот добиени во фазата на тестирање на надворешни складишта, на пример, на страници на GitLab или специјални системи за известување. GitLab Pages бара директориумот ./public да не биде празен и да содржи барем датотека index.html по завршувањето на тестовите. Можете да прочитате за нијансите на услугата GitLab Pages. .
Примери за извоз на податоци:
- од JMeter до ,
- од Yandex.Tank до .
Инструкции за поставување објавување:
- HTML статика во ,
- на InfluxDB и потоа на .
Во демо примерот, цевководот со тестови за оптоварување и два извори на оптоварување (можете да го оневозможите непотребниот) изгледа вака:
Apache JMeter може сам да генерира HTML извештај, па затоа е попрофитабилно да го зачувате во GitLab Pages користејќи стандардни алатки. Вака изгледа извештајот на Apache JMeter:
Во демо-примерот за Yandex.Tank, ќе видите само во делот за GitLab Pages. За време на тестирањето, резервоарот може да ги зачува резултатите во базата на податоци InfluxDB и оттаму може да се прикажат, на пример, во Графана (конфигурацијата се врши во датотеката ). Вака изгледа извештајот на Тенк во Графана:
Краток преглед
Во написот, зборував за концептот на „тестирање на оптоварување како услуга“ (тестирање на оптоварување како услуга). Главната идеја е да се користи инфраструктурата на претходно конфигурирани базени на агенти за оптоварување, докерски слики од извори на оптоварување, системи за известување и цевковод што ги комбинира во GitLab CI врз основа на едноставен шаблон .gitlab-ci.yml (пример ). Сето ова е поддржано од мал тим инженери за автоматизација и се повторува на барање на тимовите за производи. Се надевам дека ова ќе ви помогне во подготовката и спроведувањето на слична шема во вашата компанија. Ти благодарам за вниманието!
П.С. Сакам да им се заблагодарам на моите колеги Сергеј Курбанов и Николај Јусев за техничката помош при имплементацијата на концептот на тестирање на оптоварување како услуга во нашата компанија.
Автор: - заменик Раководител на технологија и развојни процеси (DevOps) во Positive Technologies
Извор: www.habr.com