Көп өнімі бар бағдарламалық жасақтаманы жеткізушілер жиі кездесетін мәселелердің бірі - әр командада дерлік инженерлердің - әзірлеушілердің, тестерлер мен инфрақұрылым әкімшілерінің құзыреттерінің қайталануы. Бұл сондай-ақ қымбат инженерлерге - жүктемені сынау саласындағы мамандарға қатысты.
Тікелей міндеттерін орындаудың және жүктемені сынау процесін құру, әдістемені, оңтайлы көрсеткіштерді таңдау және жүктеме профильдеріне сәйкес автотесттер жазу үшін бірегей тәжірибесін пайдаланудың орнына, инженерлер жиі сынақ инфрақұрылымын нөлден бастап орналастыруға, жүктеу құралдарын конфигурациялауға және оларды ендіруге тура келеді. CI жүйелерінде өздерін бақылауды және есептерді жариялауды орнатады.
Positive Technologies-те біз қолданатын тестілеуден кейбір ұйымдастырушылық мәселелердің шешімін таба аласыз . Және бұл жерде мен «қызмет ретінде жүктемені тестілеу» (қызмет ретінде жүктеуді тестілеу) тұжырымдамасын қолдана отырып, жүктеме сынақтарын жалпы CI құбырына біріктіру мүмкіндігі туралы айтатын боламын. Жүктеме көздерінің докерлік кескіндерін CI құбырында қалай және қандай пайдалануға болатынын білесіз; құрастыру үлгісін пайдаланып CI жобасына жүктеу көздерін қосу жолы; жүктеме сынақтарын орындау және нәтижелерді жариялау үшін демонстрациялық құбыр қандай көрінеді. Мақала өздерінің жүктеме жүйесінің архитектурасы туралы ойлайтын CI-дағы бағдарламалық жасақтаманы сынау инженерлері мен автоматтандыру инженерлері үшін пайдалы болуы мүмкін.
Тұжырымдаманың мәні
Қызмет ретінде жүктемені тестілеу тұжырымдамасы жүктеу құралдарын Apache JMeter, Yandex.Tank және өзіңіздің жеке құрылымдарыңызды еркін үздіксіз интеграциялық жүйеге біріктіру мүмкіндігін білдіреді. Демонстрация GitLab CI үшін болады, бірақ принциптер барлық CI жүйелеріне ортақ.
Қызмет ретінде жүктемені сынау - жүктемені сынауға арналған орталықтандырылған қызмет. Жүктеу сынақтары арнайы агент пулдарында орындалады, нәтижелер GitLab Pages, Influx DB және Grafana жүйелерінде немесе сынақ есеп беру жүйелерінде (TestRail, ReportPortal, т.б.) автоматты түрде жарияланады. Автоматтандыру және масштабтау мүмкіндігінше қарапайым - GitLab CI жобасында әдеттегі gitlab-ci.yml үлгісін қосу және параметрлеу арқылы жүзеге асырылады.
Бұл тәсілдің артықшылығы мынада: бүкіл CI инфрақұрылымы, жүктеме агенттері, жүктеме көздерінің докерлік кескіндері, сынақ құбырлары және жариялау есептері орталықтандырылған автоматтандыру бөлімі (DevOps инженерлері) арқылы қамтамасыз етіледі, ал жүктемені сынау инженерлері өз күштерін сынақты әзірлеуге бағыттай алады. және инфрақұрылымдық мәселелермен айналыспай, олардың нәтижелерін талдау.
Сипаттаманың қарапайымдылығы үшін сынақтан өтіп жатқан мақсатты қолданба немесе сервер алдын ала орналастырылған және конфигурацияланған деп есептейміз (бұл үшін Python, SaltStack, Ansible және т.б. автоматтандырылған сценарийлерді пайдалануға болады). Содан кейін қызмет ретінде жүктемені тестілеудің барлық тұжырымдамасы үш кезеңге сәйкес келеді: есептерді дайындау, сынау, жариялау. Диаграмма бойынша қосымша мәліметтер (барлық суреттерді басуға болады):
Жүктемелерді сынаудағы негізгі түсініктер мен анықтамалар
Жүктеме сынақтарын жүргізген кезде біз ұстануға тырысамыз , сәйкес терминологияны және ұсынылған көрсеткіштерді пайдаланыңыз. Мен жүктемені тестілеудегі негізгі ұғымдар мен анықтамалардың қысқаша тізімін беремін.
Агентті жүктеңіз - қолданба іске қосылатын виртуалды машина - жүктеу көзі (Apache JMeter, Yandex.Tank немесе өздігінен жазылған жүктеме модулі).
Сынақ мақсаты (мақсат) - жүктелетін сервер немесе серверде орнатылған қолданба.
Сынақ сценарийі (тест жағдайы) - параметрленген қадамдар жиынтығы: көрсетілген параметрлерге байланысты тіркелген желі сұраулары мен жауаптары бар пайдаланушы әрекеттері және осы әрекеттерге күтілетін реакциялар.
Профиль немесе жүктеме жоспары (профиль) - in (4.2.4-бөлім, 43-бет) жүктеме профильдері нақты сынақ үшін маңызды көрсеткіштерді және сынақ кезінде жүктеме параметрлерін өзгерту опцияларын анықтайды. Суретте профильдердің мысалдарын көруге болады.
Сынақ — алдын ала анықталған параметрлер жиынтығы бар сценарий.
Сынақ жоспары (тест жоспары) - сынақтар жиынтығы және жүктеме профилі.
Тестран (сынау) - толық орындалған жүктеме сценарийімен және алынған есеппен бір сынақты орындаудың бір итерациясы.
Желі сұрауы (сұраныс) — Агенттен мақсатқа жіберілген HTTP сұрауы.
Желілік жауап (жауап) — Мақсаттан агентке жіберілген HTTP жауабы.
HTTP жауап коды (HTTP жауаптарының күйі) – қолданба серверінің стандартты жауап коды.
Транзакция – сұрау-жауаптың толық циклі. Мәміле сұрау салу (сұрау салу) жіберілген сәттен бастап жауап (жауап) алу аяқталғанға дейін есептеледі.
Транзакция күйі - сұрау-жауап циклін сәтті аяқтау мүмкін болды ма. Егер осы циклде қандай да бір қателік орын алса, онда бүкіл транзакция сәтсіз деп саналады.
Жауап беру уақыты (кідіріс) - сұрау салуды (сұрау салуды) жіберудің аяқталуынан жауап (жауап) алудың басына дейінгі уақыт.
Көрсеткіштерді жүктеңіз — жүктемені сынау процесінде анықталған жүктелген қызмет пен жүк агентінің сипаттамалары.
Жүктеме параметрлерін өлшеуге арналған негізгі көрсеткіштер
Әдістемеде ең жиі қолданылатын және ұсынылғандардың кейбірі (36, 52 б.) көрсеткіштер төмендегі кестеде көрсетілген. Агент пен мақсатқа арналған ұқсас көрсеткіштер бір жолда берілген.
Жүктеу агентіне арналған көрсеткіштер
Жүктемеде тексерілетін мақсатты жүйенің немесе қолданбаның көрсеткіштері
Саны vCPU және есте сақтау Жедел Жадтау Құрылғысы,
диск - жүк агентінің «темір» сипаттамалары
Орталық Есептеуіш Бөлім, Жад, дискіні пайдалану - процессордың, жадтың және дискінің жүктелуінің динамикасы
тестілеу процесінде. Әдетте пайызбен өлшенеді
максималды қол жетімді мәндер
желі өткізу қабілеті (жүктеме агенті бойынша) - өткізу қабілеті
сервердегі желілік интерфейс,
жүк агенті орнатылған жерде.
Әдетте секундына байтпен өлшенеді (бит/с)
желі өткізу қабілеті(мақсат бойынша) - желі интерфейсінің өткізу қабілеті
мақсатты серверде. Әдетте секундына байтпен өлшенеді (бит/с)
Виртуалды пайдаланушылар- виртуалды пайдаланушылар саны,
жүктеме сценарийлерін іске асыру және
нақты пайдаланушы әрекеттеріне еліктеу
Виртуалды пайдаланушылардың күйі, Өтілді/Сәтсіз/Барлығы — сәтті және саны
виртуалды пайдаланушылардың сәтсіз күйлері
жүктеу сценарийлері үшін, сондай-ақ олардың жалпы саны.
Әдетте барлық пайдаланушылар аяқтай алды деп күтілуде
жүктеу профилінде көрсетілген барлық тапсырмаларыңыз.
Кез келген қате нақты пайдаланушы жасай алмайтынын білдіреді
жүйемен жұмыс істеу кезінде мәселеңізді шешіңіз
Секундтағы сұраулар (минут)- секундына (немесе минутына) желілік сұраулар саны.
Жүктеу агентінің маңызды сипаттамасы оның қанша сұрау жасай алатындығы болып табылады.
Шын мәнінде, бұл виртуалды пайдаланушылардың қолданбаға қол жеткізуіне еліктеу
Секундтағы жауаптар (минут)
- секундына (немесе минутына) желілік жауаптардың саны.
Мақсатты қызметтің маңызды сипаттамасы: қанша
көмегімен сұрауларға жауаптарды жасау және жіберу
жүктеу агенті
HTTP жауап күйі— әртүрлі жауап кодтарының саны
жүктеу агенті алған қолданба серверінен.
Мысалы, 200 OK сәтті қоңырауды білдіреді,
және 404 - ресурс табылмады
Кідіріс (жауап уақыты) - аяқталу уақыты
жауап (жауап) алуды бастамас бұрын сұрау (сұраныс) жіберу.
Әдетте миллисекундпен (мс) өлшенеді
Транзакцияға жауап беру уақыты— бір толық транзакцияның уақыты,
сұрау-жауап циклінің аяқталуы.
Бұл сұраныс (сұраныс) жіберілген сәттен бастап уақыт.
жауап (жауап) алу аяқталғанға дейін.
Транзакция уақытын секундтармен (немесе минуттармен) өлшеуге болады
бірнеше жолмен: минимумды қарастырыңыз,
максимум, орташа және, мысалы, 90-процентиль.
Ең төменгі және максималды көрсеткіштер экстремалды
жүйе өнімділігі күйі.
Тоқсаныншы процентиль ең жиі пайдаланылады,
пайдаланушылардың көпшілігі көрсеткендей,
жүйе өнімділігінің шегінде ыңғайлы жұмыс істейді
Секундтағы транзакциялар (минут) - толық саны
секундтағы транзакциялар (минут),
яғни, өтініш қаншалықты қабылдай алды және
сұрауларды өңдеу және жауаптар беру.
Шын мәнінде, бұл жүйенің өткізу қабілеті
Транзакция күйі , Өтті / Өтпеді / Барлығы - саны
сәтті, сәтсіз және транзакциялардың жалпы саны.
Нағыз пайдаланушылар үшін сәтсіз
транзакция шын мәнінде білдіреді
жүктеме кезінде жүйемен жұмыс істеу қабілетсіздігі
Жүктемені тексеру схемасы
Жүктемені сынау тұжырымдамасы өте қарапайым және мен жоғарыда айтқан үш негізгі кезеңнен тұрады: Дайындау-сынақ-есеп, яғни сынақ мақсаттарын дайындау және жүктеме көздері үшін параметрлерді орнату, содан кейін жүктеме сынақтарын орындау және соңында сынақ есебін жасау және жариялау.
Схемалық ескертулер:
- QA.Tester – жүктемені сынау бойынша сарапшы,
- Мақсат - жүктелген кезде оның әрекетін білгіңіз келетін мақсатты қолданба.
Диаграммадағы субъектілердің, кезеңдердің және қадамдардың классификаторы
Кезеңдер мен қадамдар
Не болып жатыр
Кіреберісте не бар
Шығарылым қандай
Дайындаңыз: тестілеуге дайындық кезеңі
LoadParameters
Баптау және инициализациялау
пайдаланушы
жүктеме параметрлері,
көрсеткіштерді таңдау және
сынақ жоспарын дайындау
(жүктеу профилі)
үшін теңшелетін опциялар
жүктеу агентін инициализациялау
Тест жоспары
Тестілеудің мақсаты
VM
Бұлтты орналастыру
бар виртуалды машина
қажетті сипаттамалар
Жүктеу агентіне арналған VM параметрлері
үшін автоматтандыру сценарийлері
VM құру
VM конфигурацияланған
бұлтты
Энв
ОЖ орнату және дайындау
үшін орта
жүктеу агентінің жұмысы
үшін орта параметрлері
жүк агенті
үшін автоматтандыру сценарийлері
орта параметрлері
Дайын орта:
ОЖ, қызметтер мен қолданбалар,
жұмыс үшін қажет
жүк агенті
LoadAgents
Орнату, конфигурациялау және параметрлеу
жүктеу агенті.
Немесе докер кескінін жүктеп алу
алдын ала конфигурацияланған жүктеме көзі
Бастапқы докер кескінін жүктеңіз
(YAT, JM немесе өздігінен жазылған құрылым)
Параметрлер
жүк агенті
Орнату және дайын
жұмыс жүктемесінің агентіне
Тест: жүктеме сынақтарын орындау кезеңі. Көздер GitLab CI үшін арнайы агент пулдарында орналастырылған жүктеу агенттері болып табылады
жүк
Жүктеу агентін іске қосу
таңдалған сынақ жоспарымен
және жүктеме параметрлері
Пайдаланушы опциялары
инициализация үшін
жүк агенті
Тест жоспары
Тестілеудің мақсаты
Орындау журналдары
жүктеме сынақтары
Жүйе журналдары
Мақсат көрсеткіштері мен жүктеу агентіндегі өзгерістер динамикасы
Агенттерді іске қосыңыз
Агентті орындау
көптеген сынақ сценарийлері
сәйкес
жүк профилі
Жүктеу агентінің әрекеттесуі
тестілеу мақсатында
Тест жоспары
Тестілеудің мақсаты
Журналдар
«Шикі» журналдар жинағы
жүктемені сынау кезінде:
агент әрекетінің жазбаларын жүктеу,
сынақ нысанасының күйі
және агентті басқаратын VM
Орындау журналдары
жүктеме сынақтары
Жүйе журналдары
Метрика
Тестілеу кезінде «шикі» көрсеткіштерді жинау
Мақсат көрсеткіштерінің өзгеру динамикасы
және жүктеу агенті
Есеп: сынақ есебін дайындау кезеңі
генератор
Өңдеу жиналды
жүктеу жүйесі және
«шикі» мониторинг жүйесі
көрсеткіштер мен журналдар
Есепті қалыптастыру
адам оқи алатын пішін
элементтермен мүмкін
сарапшылар
Орындау журналдары
жүктеме сынақтары
Жүйе журналдары
Метрикалардың өзгеру динамикасы
мақсатты және жүктеме агенті
Өңделген «шикі» журналдар
қолайлы форматта
сыртқы жадқа жүктеп салады
Статикалық жүктеме туралы есеп,
адам оқи алады
Жариялау
Есепті жариялау
жүктеме туралы
сыртқы тестілеу
қызметі
Өңделген «шикі»
сәйкес пішімде журналдар
сыртқа түсіру үшін
қоймалар
Сырттан сақталған
сақтау есептері қосулы
жүктеме, қолайлы
адамға талдау жасау үшін
CI үлгісіндегі жүктеме көздерін қосу
Практикалық бөлікке көшейік. Мен компаниядағы кейбір жобаларда қалай болатынын көрсеткім келеді біз қызмет ретінде жүктемені тестілеу тұжырымдамасын енгіздік.
Біріншіден, DevOps инженерлеріміздің көмегімен жүктеме сынақтарын жүргізу үшін GitLab CI жүйесінде арнайы агенттер пулын жасадық. Үлгілерде оларды құрастыру пулдары сияқты басқалармен шатастырмау үшін біз осы агенттерге тегтерді қостық, : жүк. Сіз кез келген басқа түсінікті тегтерді пайдалана аласыз. Олар сұрайды GitLab CI жүгірушілері.
Қажетті қуатты аппараттық құрал арқылы қалай білуге болады? Жүктеу агенттерінің сипаттамалары - vCPU, жедел жады және дискінің жеткілікті саны - агентте Docker, Python (Yandex.Tank үшін), GitLab CI агенті, Java (Apache JMeter үшін) жұмыс істеуі керек екендігіне негізделе отырып есептелуі мүмкін. . JMeter астында Java үшін кем дегенде 512 МБ жедел жадты пайдалану ұсынылады және жоғарғы шек ретінде: .
Осылайша, біздің тәжірибемізге сүйене отырып, жүктеу агенттері үшін кемінде 4 vCPU, 4 ГБ жедел жады, 60 ГБ SSD пайдалануды ұсынамыз. Желілік картаның өткізу қабілеті жүктеме профилінің талаптары негізінде анықталады.
Біз негізінен екі жүктеу көзін қолданамыз - Apache JMeter және Yandex.Tank докер кескіндері.
жүктеуді тексеруге арналған Яндекстің ашық бастапқы көзі болып табылады. Оның модульдік архитектурасы Phantom компаниясының жоғары өнімді асинхронды хит негізіндегі HTTP сұрау генераторына негізделген. Резервуарда SSH протоколы арқылы сынақтан өтіп жатқан сервер ресурстарының кірістірілген мониторингі бар, белгіленген шарттарда сынақты автоматты түрде тоқтата алады, нәтижелерді консольде де, графиктер түрінде де көрсете алады, модульдерді қосуға болады. функционалдығын кеңейту үшін. Айтпақшы, біз танкті ол әлі негізгі емес кезде қолдандық. мақаласында «» сіз 2013 жылы онымен жүкті тестілеуді қалай орындағанымыз туралы әңгімені оқи аласыз біздің компанияның өнімдерінің бірі болып табылады.
Apache ұсынған ашық бастапқы жүктеуді тексеру құралы болып табылады. Оны статикалық және динамикалық веб-қосымшаларды сынау үшін бірдей жақсы пайдалануға болады. JMeter көптеген протоколдар мен қолданбалармен өзара әрекеттесу тәсілдерін қолдайды: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET және т.б.), SOAP / REST веб-қызметтері, FTP, TCP, LDAP, SMTP(S), POP3( S) ) және IMAP(S), JDBC арқылы дерекқорлар қабық командаларын орындай алады және Java нысандарымен жұмыс істей алады. JMeter тест жоспарларын жасауға, жөндеуге және орындауға арналған IDE бар. Сондай-ақ кез келген Java-үйлесімді операциялық жүйеде (Linux, Windows, Mac OS X) пәрмен жолы жұмысы үшін CLI бар. Құрал HTML сынақ есебін динамикалық түрде жасай алады.
Біздің компанияда пайдаланудың қарапайымдылығы үшін, тестілеушілердің өздері қоршаған ортаны өзгерту және қосу мүмкіндігі үшін біз GitLab CI жүйесінде жүктеме көздерінің докерлік кескіндерін ішкі нұсқада жариялаумен жасадық. . Бұл жүктеме сынақтары үшін оларды құбырларға қосуды тезірек және жеңілдетеді. GitLab CI арқылы тізілімге docker push-ті қалай жасауға болады - қараңыз .
Біз Yandex.Tank үшін осы негізгі докер файлын алдық:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Ал Apache JMeter үшін бұл:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Біздің үздіксіз интеграциялық жүйеміз қалай жұмыс істейтінін мақаладан оқи аласыз »«.
Үлгі және құбыр
Жүктеме сынақтарын жүргізуге арналған үлгі үлгісі жобада қол жетімді . The Үлгіні пайдалану нұсқауларын оқуға болады. Үлгінің өзінде (файл ) әрбір қадам не үшін жауапты екені туралы ескертпелер бар.
Үлгі өте қарапайым және жоғарыдағы диаграммада сипатталған жүктемені тексерудің үш кезеңін көрсетеді: есептерді дайындау, сынақтан өткізу және жариялау. Бұған жауапты : Дайындау, тексеру және есеп беру.
- Кезең сынақ мақсаттарын алдын ала конфигурациялау немесе олардың қолжетімділігін тексеру үшін пайдаланылуы керек. Жүктеме көздеріне арналған ортаны конфигурациялаудың қажеті жоқ, олар докер кескіндері ретінде алдын ала құрастырылған және докер тізілімінде орналастырылған: сынақ кезеңінде қажетті нұсқаны көрсетіңіз. Бірақ сіз оларды қайта құра аласыз және өзіңіздің өзгертілген кескіндеріңізді жасай аласыз.
- Кезең жүктеу көзін көрсету, сынақтарды іске қосу және сынақ артефактілерін сақтау үшін пайдаланылады. Сіз кез келген жүктеу көзін таңдай аласыз: Yandex.Tank, Apache JMeter, жеке немесе барлығы бірге. Қажет емес көздерді өшіру үшін жай ғана түсініктеме беріңіз немесе тапсырманы жойыңыз. Жүктеме көздеріне кіру нүктелері:
- Yandex.Tank үшін іске қосу параметрлері .,
- Apache JMeter іске қосу параметрлері файлда көрсетілген .
Ескертпе: Құрастыру конфигурациясының үлгісі CI жүйесімен өзара әрекеттесуді орнату үшін пайдаланылады және оған сынақ логикасын орналастыруды білдірмейді. Сынақтар үшін бақылау bash сценарийі орналасқан кіру нүктесі көрсетіледі. Сынақтарды орындау, есептерді жасау және сынақ сценарийлерінің өздерін QA инженерлері жүзеге асыруы керек. Демонстрацияда екі жүктеу көздері үшін де Яндекс негізгі бетінің сұрауы ең қарапайым сынақ ретінде пайдаланылады. Сценарийлер мен сынақ параметрлері каталогта .
- Сахнада Сынақ кезеңінде алынған сынақ нәтижелерін сыртқы жадтарға, мысалы, GitLab беттеріне немесе арнайы есеп беру жүйелеріне жариялау жолын сипаттау қажет. GitLab беттері ./public каталогының бос болмауын және сынақтар аяқталғаннан кейін кем дегенде index.html файлын қамтуын талап етеді. GitLab Pages қызметінің нюанстары туралы оқуға болады. .
Деректерді экспорттау мысалдары:
- JMeterден бастап ,
- Яндекс.Танктен .
Орнату нұсқауларын жариялау:
- HTML статикасы ,
- InfluxDB, содан кейін .
Демонстрациялық мысалда жүктеме сынақтары және екі жүктеме көзі бар құбыр желісі (қажетсізін өшіруге болады) келесідей көрінеді:
Apache JMeter HTML есебін өзі жасай алады, сондықтан оны стандартты құралдарды пайдаланып GitLab беттерінде сақтау тиімдірек. Apache JMeter есебі осылай көрінеді:
Yandex.Tank үшін демонстрациялық мысалда сіз тек көресіз GitLab беттеріне арналған бөлімде. Тестілеу кезінде танк нәтижелерді InfluxDB дерекқорына сақтай алады және сол жерден оларды, мысалы, Grafana-да көрсетуге болады (конфигурация файлда орындалады) ). Графанада Танктің есебі осылай көрінеді:
Резюме
Мақалада мен «сервис ретінде жүктеуді тестілеу» (жүкті тестілеу қызмет ретінде) түсінігі туралы айттым. Негізгі идея – жүк агенттерінің алдын ала конфигурацияланған пулдарының инфрақұрылымын, жүк көздерінің докер кескіндерін, есеп беру жүйелерін және оларды қарапайым .gitlab-ci.yml үлгісіне негізделген GitLab CI жүйесінде біріктіретін құбыр желісін пайдалану (мысал). ). Мұның барлығын автоматтандыру инженерлерінің шағын тобы қолдайды және өнім командаларының сұранысы бойынша қайталанады. Бұл сіздің компанияңызда ұқсас схеманы дайындауға және енгізуге көмектеседі деп үміттенемін. Назар аударғаныңызға рақмет!
П.С. Әріптестерім Сергей Курбанов пен Николай Юсевке біздің компанияда қызмет ретінде жүктемені тестілеу тұжырымдамасын енгізуге техникалық көмек көрсеткені үшін үлкен алғыс айтқым келеді.
автор: - Орынбасар Positive Technologies компаниясының технология және даму процестерінің (DevOps) басшысы
Ақпарат көзі: www.habr.com