Стенд в ит что это

Стенд для нагрузочного тестирования: от DEV до PROD

Меня зовут Василий Кудрявцев, и вот уже 10 лет я занимаюсь нагрузочным тестированием, а из них последние 1,5 года – в компании РТЛабс.

И сегодня мы поговорим не об инструментах или общих подходах (для этого есть курсы – один из крупных веду я, а еще у многих есть коллеги-эксперты и тот самый чатик в телеге на 3400+ участников), а об области, которую обычно обходят стороной или собирают на коленке — тестовые стенды для нагрузочного тестирования.

Здесь, на Госуслугах, мы пока только конструируем мечту каждого нагрузочника — свой отдельный, выделенный, рабочий (!) тестовый стенд. Особенно это мечта актуальна для небольших продуктовых команд.

Тем не менее, за последний год мы увеличили количество проводимых тестов почти в 10 раз и команду раза в два. Где же мы проводим более 1000 нагрузочных тестов в год без отдельного стенда, спросите вы? Ответ: мы использовали все стенды по максимуму, под шум (крики) продуктовых команд! 🙂

Я попробовал обобщить личный опыт последних лет, успехи прорыва в результативности тестов и, соответственно, в повышении производительности, которого мы смогли достичь в компании за последнее время.

Договоримся о терминологии

1. НТ — нагрузочное тестирование, для меня это синоним тестирования производительности. В НТ входят всевозможные подвиды тестов, направленные на проверку показателей производительности системы: время отклика, пропускная способность, % успешных операций или доступность, утилизация ресурсов.
2. Максимальная производительность — уровень пропускной способности системы, после которого система перестаёт удовлетворять предъявленным к ней требованиям — по времени отклика, доступности, утилизации ресурсов.
3. Тест определения максимальной производительности — ступенчатое повышение нагрузки на систему до достижения этого самого уровня.

Как у нас организована нагрузка

Инструменты:

• Основной — Gatling
• Протоколы – наиболее часто это REST-ы и web по http, бывают и скрипты нагрузки на БД / очереди
• Запуск тестов в Jenkins
• Мониторинг в Grafana + Clickhouse
• Для мониторинга генераторов нагрузки — Prometheus
• Redis и Postgres для хранения тестовых данных, FTP для больших файлов

В общем, всё как у взрослых людей. В следующих статьях расскажем об этом подробнее, если интересно. А сейчас едем дальше.

3+ регулярно нагружаемые крупные системы:

• Единый портал государственных услуг (ЕПГУ)
• Единая система идентификации и аутентификации (ЕСИА)
• Система межведомственного электронного взаимодействия (СМЭВ, шина данных)
• …и еще с десяток периодически нагружаемых прикладных систем и сервисов

Основные типы тестов:

• Проверка стабильной нагрузки — короткий тест с заданным tps
• Стресс-тесты — проверка работы под большой нагрузкой в течение короткого времени
• Классическая максимальная производительность

Команда инженеров:

1 лид и 4 нагрузочника разного опыта и происхождения, со средним опытом в НТ = ~3 года

Вернемся к нагрузочным стендам

Разделим типы стендов на несколько категорий и поймём, что же можно на них тестировать и какие риски / ограничения нужно держать в уме:

1. DEV — стенд разработки
2. UAT — стенд регрессионного функционального тестирования
3. LT — отдельный стенд нагрузочного тестирования
4. PROD — стенд на базе инфраструктуры Продуктивного контура

Каждый опишем с нескольких сторон по такой схеме:

• Summary — короткое резюме от меня
• Жиза — как мы используем этот стенд
• Что можно — какие тесты можно проводить
• Команда — кто здесь понадобится нагрузочнику, насколько самостоятельно выполнение тестов
• Pros and cons — основные + / —
• Advice — совет напоследок обзора стенда

DEV — место бурлящей жизни и регулярной поломки разработчиками

Summary: Отличное место для нагрузки пилотных решений или новых микросервисов, но задержаться на нём для исследований бывает сложно. Особенно, если архитектура монолитная.

Жиза: Не самый активный стенд именно для нагрузки, но супер-массовые новые сервисы сначала тестим здесь — социальные выплаты, сервисы для выборов, онлайн-запись в школы. Конечно же, в микросервисах, особенно часто в кубере. Здесь не проверить какой-нибудь scaling, но 50-70% проблем на данном стенде мы закрывали, хоть пользовались им не так часто, как стоило бы.

Отступление в рамках темы

Отдельного внимания здесь в описании DEV заслуживает наше детище для Системы межведомственного электронного взаимодействия (СМЭВ). Изначально мы планировали собрать стенд LT, но заказчики-разработчики пожелали проверять новые решения и тюнинг/рефакторинг старых здесь и сейчас. У нас вышел эдакий Монстр, которого мы прозвали DEV-LT! По необходимости могли и мощностей накинуть для достижения нужных цифр, но и не ждали отлаженных новых релизов и прочих pipeline-ов для проверки разных гипотез.

В итоге за пару месяцев мы протестили отказоустойчивость при отключении разных сервисов системы, протюнили с десяток компонент и повысили общую производительность системы раза в три (с учётом пост-тестов на других стендах, конечно же). Это был суровый марафон, но глаза горели у всех!

Что можно: стресс-тесты и общая максимальная производительность всего комплекса здесь бессмысленны. Только точечный тюнинг и проверка отдельных компонентов тестами со стабильными потоками (количество открытых соединений / thread-ов) или подачей стабильной нагрузки.

Команда: Если времени мало, то практически в онлайне с разработчиком. Если побольше — в режиме чатика. Очень удобно поработать devops-ом: сделать «кнопку» для разработчика и дать ему «пофрустрировать» самому до желаемого результата. Не забудьте про мониторинг, чтобы он получал удовольствие! Главное вовремя остановить, не доводить до уровня «хочу 100к tps выжать, 12 ночи всего, запускаю ещё тест!»

Pros and cons:

+ экономит время тюнинга на поздних этапах, что особенно актуально для багов по производительности (все мы знаем, они бывают ОЧЕНЬ дорогими)

+ можно запускать «на коленке» и получать реальный value

– не подходит для основательных выводов по максималке / не применить к PROD — нужны дополнительные тесты на других контурах

– стенд обычно шаток и разработчики любят его ломать, а иногда его потом сложно восстановить

– сложно с тестированием интеграций, DEV, как правило, изолирован

Advice: Совет подойдёт и для других стендов — «одно изменение за раз!». Разработчики любят побежать азартно вперёд, и применить много «оптимизаций» между тестами за один раз. Потом приходится часто искать, что именно улучшило или ухудшило производительность. Поэтому лучше стараться делать одно улучшение/изменение за раз и оценивать тестом, хотя бы коротким.

UAT (стенд регрессионного функционального тестирования) — относительно стабильный контур по сборкам, но слабый по железу

Summary: Как и для ФТ — хороший стенд для проверки новых релизов по старой функциональности (применимо и для НТ). Так и хочется добавить к нему железа, и пусть весь мир (другие стенды) подождут. Но в итоге тестов будет ждать и остальная команда.

Жиза: С этого стенда мы начинали в РТЛабс проводить регулярное НТ — в данном случае проверка релизов на не-ухудшение производительности. В частности, на небольшом железе мы сравниваем «выдерживание» ступени стабильной нагрузки по основным показателям производительности. Дефектов обычно находится не так много, как хотелось бы, потому что у этого стенда всегда много «но» по сравнению с PROD. И это несмотря на то, что по конфигурации компонентов он к нему ближе, чем любой другой.

Что можно: Лучше проводить тесты стабильной нагрузки 10-60 минут. Длительность зависит от вашей ступени стабильной нагрузки, за которую вы сможете адекватно оценить показатели производительности. Если у вас быстрая система с 100-500+ tps и временем отклика в пределах секунды (шина данных, например), то хватит и коротких тестов. Если что-то пользовательское с множеством сценариев — лучше погонять подольше и заодно оценить надежность.

Команда: Как правило, лучший друг нагрузочника — это функциональщик. В данном случае вдвойне, так как это его стенд! Он подскажет, когда и сборка более-менее стабильна и когда можно поломать стенд тестами. С дефектами тут сложнее, чем на DEV — у нас по крайней мере были наводки и на инфраструктурные сбои, а разбор может быть не таким быстрым, как хотелось бы.

Pros and cons:

+ хороший стенд для старта нагрузочного тестирования в плане стабильности и отладки (в том числе на новых готовящихся версиях системы). И для того, чтобы потом куда-то переезжать с тестами на другие стенды

+ обычно неплохая поддержка со стороны ФТ и сопровождения, так как релизы должны ехать в PROD без простоев. А вы, в том числе, занимаете время подготовки релиза 🙂

– придётся выбирать время для тестов, чтобы не мешать ФТ

– сильную нагрузку целиком на систему не подать ввиду слабости стенда по железу, то есть сложно оценить максимальную производительность в целом

Advice: Не убивайте стенд, пожалейте функциональщиков! Не только проведением нагрузки днём, но и забиванием БД тестовыми или созданными в тестах данными. Проработайте процедуры очистки.

LT (отдельный стенд нагрузочного тестирования)

На какой хватит средств какой построите, такой и будет! Но в любом случае он лучше остальных стендов, потому что СВОЙ.

Summary: Здесь всё понятно — идеальный стенд практически для любых целей НТ. Не надо сидеть по ночам / ждать пока он освободится (в пределах одной тестируемой системы, конечно). В некоторых банках даже построили интеграционные стенды НТ. Правда пока я не видел стенд, выдерживающий 100% нагрузку по профилю с Прода, со всех каналов-систем.

Жиза: Выше я рассказывал о том, как мы применяем стенд DEV-LT. Пока мы видим неплохую пользу в совмещении целей для этого контура с учетом имеющейся инфраструктуры PROD для больших тестов (об этом ниже).

Из опыта других компаний могу сказать, что отдельный контур это действительно долго, дорого и замечательно. Причём для стабильного стенда крупной системы «долго» — это скорее всего минимум год, а «дорого» — не только закупка оборудования, но ещё и отдельная команда админов разного профиля. Ведь у вас небольшой PROD, а значит нужны инженеры СПО, ППО, DBA и т.д.

При этом на других стендах можно и нужно ловить 80-90% проблем. Это значит, что в микросервисной архитектуре огромные стенды становятся всё менее полезными.

Что можно: ВСЁ. Ну, правда. Интеграционные нагрузочные тесты можно проводить с эмуляторами, хорошо идут регрессионные тесты, стресс-тест/максималка/надежность/отказоустойчивость и любые другие, которые вы ещё себе придумаете между релизами.

Команда: Если хотите работать эффективно, а не чинить стенд неделями, когда ребята с PROD / тестовых контуров смогут уделить вам время, то только отдельная команда. Если стенд небольшой, можно не выделять отдельно системных администраторов / DBA на задачи одного этого стенда. Но инженеры ППО точно нужны — системы нужно и поднимать с нуля и поддерживать (поднимать) после регулярных тестов и релизов, которые будут их ломать.

Pros and cons:

+ подходит для всех нужных нагрузочных тестов (с интеграционным НТ может быть сложно, но возможно!)

+ не нужно ждать очередь на стенд, есть время для улучшений / экспериментов

+ можно готовить нужные наборы тестовых данных, тестировать объемы

– дорого и долго — и по подготовке железа, и в поддержке

– команде сопровождения нужно долго набираться опыта

– бывает сложно отслеживать все изменения на PROD / тестовых контурах, чтобы тестовый стенд НТ был актуален

Advice: Не надейтесь, что стенд НТ взлетит быстро, особенно если команда собирается с нуля. Исключения — небольшие и простые системы, по ним и PROD просто и быстро собрать.

И раз уж у вас отдельный стенд — пробивайте получение копии БД с PROD (урезанной, обезличенной), это повысит качество тестирования.

Ещё совет— не делайте прогнозирование / домножение результатов, полученных на стенде НТ, для PROD, если у вас LT сильно меньше по ресурсам. Горизонтальное масштабирование — непростая штука. Да простят меня мастера-архитекторы – иногда позволяю себе «умножить на 2» производительность, полученную на стенде НТ, который в 2 раза слабее Прода по ресурсам, при микросервисной архитектуре и не загруженности всех узлов по метрикам серверов. Можно предположить, что на Прод будет не хуже.

Сравнение производительности простой web-ки на node.js при увеличении ресурсов машины в 2 раза.

Как-то студенты курса по НТ проводили простой эксперимент по оценке влияния повышения ресурсов сервера, на котором крутилась простая веб-страничка c node.js под капотом, практически ничего не делающая. Результат налицо. Теперь храню эту картинку и показываю всем, кто любит «умножать на 10».

PROD (стенд на базе инфраструктуры Продуктивного контура) – опасно, но крайне эффективно

Summary: Мало кто вас сюда пустит. Но если пустит — польза не только в качестве достоверных результатов, но и в тренировке для команды поддержки PROD. Только нежнее с боевой инфрой! И не забывайте про очистку от разного мусора после тестов.

Жиза: Чтобы быть уверенными в высокой доступности новых, серьёзных по нагрузке сервисов, финальные тесты мы проводим здесь. Особенно это актуально, когда у нас мало времени, например, при запуске срочных выплат населению страны последних пары лет.

Пользователи Госуслуг засыпают, а мы собираемся на ночной zoom и аккуратно тестируем на PROD-инфраструктуре. Тюним на месте, записываем изменения конфигов «на лету» себе в тикеты «на утро». Отдельно заказываем новые VM туда, где понимаем, что не успеем дотюниться до запуска сервиса.

Конечно, для этого нужна аккуратная и дотошная подготовка скриптов для очистки мусора после тестов и выверенный чёткий план тестирования с автоматизацией запуска тестов.

Что можно: Конечно, не всё. В первую очередь это стресс-тесты — короткие, точные, до первых узких мест, чтобы затем произвести тюнинг. Можно сразу в онлайне, чтобы не уходить потом на ещё одни работы. Не получится использовать инфраструктуру PROD, если у вас интенсивная пользовательская нагрузка 24/7 и нет микросервисов, которые вы можете изолировать от влияния на пользователей на 99%+.

Команда: Берите с собой в онлайн ВСЕХ ключевых участников проекта — разработку, сопровождение PROD, специалистов по сети, виртуализации, железу. В общем, всех, кто будет (а лучше не будет, не зря же делается НТ) разбираться с проблемами PROD в день запуска нового сервиса. Ведь это же боевая тренировка!

Для тех, кто по каким-то причинам не хочет в этом участвовать, есть отличный аргумент — или мы сейчас проконтролируем что будет, или будем смотреть на это в онлайне, на живых пользователях и чинить, теряя SLA.

Pros and cons:

+ не только НТ, но и тренировка для команды

+ в нехватке времени можно тюнить на лету (конечно, сохраняя улучшения в репозиториях)

– требуется хорошая подготовка плана и скриптов очистки

– не для каждого сервиса возможно НТ на инфраструктуре PROD

Advice: Все же помнят хорошую практику: всё что выкатывается на PROD должно тестироваться? Это же касается и ваших скриптов НТ, тестовых данных, скриптов очистки от мусора после НТ. Всё должно быть протестировано на младших контурах, считайте, что это такой же релиз.

Ну и конечно, так как НТ на PROD — это часто ночные работы, не замучайте команду в ночь перед запуском важных сервисов. Если не успеваете, лучше ребятам поспать ночь и с утра уже готовиться к проблемам на PROD, быстрее будут реагировать.

Во всём нужна мера, потому что, как говорил один мой знакомый менеджер: «Работа отнимает всё отведенное на неё время».

Вместо заключения

Как видите, у каждого стенда НТ найдутся свои нюансы, а главное – своя польза. Уже давно прошли те времена, когда подрядчик требовал нагрузочный стенд, а заказчик закупал его месяцами, тратя огромные деньги. С новыми средствами НТ и микросервисной архитектурой тесты можно проводить на разных этапах и на разных стендах достаточно быстро.

Я бы описал рекомендованный путь становления процессов НТ в компании по части стендов так:

UAT – отсюда можно стартовать регрессионное НТ

DEV – для новых сервисов, которые будут нагружены

PROD – когда отдельного стенда НТ нет, а ожидается новая большая нагрузка

LT – когда уже научитесь тестировать, поймете систему и действительно сможете использовать дорогое удовольствие с пользой

Конечно, эти стенды у вас могут называться по-другому, типы тестов тоже. Я старался использовать плюс-минус общепринятые понятия. На закрепление терминологии не претендую.

Пишите в комментариях про ваш опыт использования тестовых стендов для НТ. Буду рад почерпнуть что-то новое, в том числе по поводу плюсов и минусов каждого.

Всем результативного НТ и рабочих стендов!

• госуслуги
• нагрузочное тестирование
• тестовый стенд
• performance testing
• load testing
• тестирование по

Электронные учебные стенды

Если вы учились в учебном заведении технической направленности, то видели и знаете, что такое учебные стенды. С понятийной точки зрения учебные стенды являются отдельным видом технических средств обучения и представляют собой комплекс взаимосвязанных компонентов, имитирующих часть функционала системы или устройства. Долгое время стенды играли роль наиболее наглядного средства обучения, демонстрируя учащимся устройство сложных систем, хоть и в упрощенном виде, и принцип их работы. На них также отрабатывались навыки работы с различными системами и устройствами.

В то же время для стендов характерны существенные недостатки, связанные, главным образом, с высокой стоимостью, сложностью разработки и ограниченной функциональностью. Развитие информационных технологий позволило найти доступную и функциональную альтернативу учебным стендам — электронные учебные стенды.

Электронный учебный стенд

Электронный учебный стенд — компьютерная модель изучаемой системы. Это может быть модель целой системы или ее отдельных элементов в 3D формате с программируемыми взаимосвязями между компонентами. Благодаря технологии трехмерного моделирования электронные учебные стенды не только с высокой точностью передают внешний вид учебных объектов, но и наглядно представляют их в действии. В наглядности электронные стенды не уступают физическим аналогам, а в ряде случаев и превосходят их, ведь при необходимости 3D-модели могут демонстрировать скрытые процессы, происходящие с объектом, а при работе с компьютерной моделью не возникает проблем с ограниченностью пространства. Использовать электронный учебный стенд можно на любом устройстве, от проектора до планшетного компьютера, в то время как комплект классических учебных стендов «в железе» почти всегда требует отдельного помещения.

Для реалистичности изучаемого объекта и наглядности взаимодействия его компонентов связи между ними программируются. Это также позволяет сделать электронный стенд интерактивным — обучаемый, используя соответствующий интерфейс, может взаимодействовать с различными элементами стенда, использовать инструмент и необходимые приспособления. Взаимодействие с компьютером в некоторой степени уступает в эффективности выполнению операций с реальными физическими объектами, однако в учебном процессе этот недостаток сглаживают три фактора:

1. Электронный стенд позволяет каждому учащемуся отработать навыки взаимодействия с объектом столько раз, сколько это необходимо для усвоения материала, тогда как при большом количестве обучаемых в группе или классе попробовать свои силы на классическом, реальном стенде получится далеко не у каждого.
2. Электронные стенды можно запрограммировать так, чтобы обучаемые могли выполнять различные ситуационные задачи. Количество вариантов таких задач практически не ограничено, как и их сложность.
3. У электронных стендов нет физического износа, их практически невозможно сломать, в связи с чем отпадает необходимость в периодическом ремонте, свойственном традиционным стендам в учебных заведениях с большим количеством учащихся.

Исходя из всего вышесказанного, можно сделать вывод о том, что у дорогих и неудобных учебных стендов есть гораздо более доступная альтернатива. И для большинства учебных заведений электронные стенды будут иметь ряд значительных преимуществ:

• наглядность, в том числе и за счет демонстрации скрытых процессов и показа объектов на местах их размещения с помощью технологии трехмерного моделирования;
• высокая функциональность, позволяющая применять электронные учебные стенды для отработки ситуационных задач, сложность и количество которых ограничивается желанием заказчика;
• высокая окупаемость, ведь электронные стенды требуют вложений только на стадии разработки, не нуждаются в периодическом ремонте и расходах на содержание дополнительных помещений и т.д.

В свою очередь, затраты на разработку электронных стендов не выше затрат на разработку стендов в металле, так как первые не требуют закупки сложного оборудования или создания дополнительных макетов.

В компании «Иторум» вы можете заказать разработку электронных учебных стендов разной отраслевой направленности. Обширный опыт, команда компетентных специалистов и набор современных средств разработки позволяет в сжатые сроки создавать учебные компьютерные модели любого вида и сложности. Чтобы получить консультацию или заказать услугу, оставьте заявку в форме обратной связи или позвоните по тел. 8495-120-80-55.

Тестирование в IT — это просто.

Для желающих приобщиться к IT технологиям калитка стать тестировщиком считается открытой для всех желающих. Давайте разбираться в чем состоит работа тестировщика.

Про термины.

Что такое тестирование? Тестирование — это процесс проверки соответствия поведения программы с требованиями к ней.

Пример: программа считающая 2+2, требование: результат должен быть равен 5. Получаем программу запускаем, показывает результат 4 — не соответствует требованию, оформляем баг и идем пить смузи и серфить в айфончике.

Баг (bug) — факт несоответствия поведения программы с требованиями к ней.

Тестовый стенд — совокупность аппаратуры, софта и определенных настроек для тестирования продукта.

Тест-кейс — сценарий проведения испытания программы. Обычно первым пунктом указывается описание тестового стенда. Это должно быть максимально детальное описание. Далее сценарий, также максимально подробно описаны действия и ожидаемый результат. Текст должен быть предельно понятен ребенку и не допускать никаких вторых или третьих толкований.

Тест-план — набор тест-кейсов для выполнения цикла тестирования. Например: регрессионный тест-план, предрелизный тест-план, релизный тест-план, приемочный тест-план, дымовой тест-план. После выполнения тест-плана и получения по нему отчета руководство проекта обычно принимает решение о успешности этапа разработки проекта или неуспешности.

Тестировщик — отрицание.

Для начала давайте определимся — в чем состоит основная работа тестировщика?

Он тестировщик, значит тестирование! Нет.

Он тестировщик, значит в поиске багов! Нет.

Эээ… получить безглючный продукт? Это цель, это не основная работа.

Так вот, основная работа состоит в сборке тестового стенда и создания начальных условий для тестирования. Это самая важная и основная работа тестировщика. На все остальное тестировщик тратит меньше времени.

Итак, тестовый стенд, что может быть известно? Как написано в терминах — первым пунктом тест-кейса должно быть описание тестового стенда. а стенд — это совокупность аппаратуры, софта и настроек для тестирования продукта.

Описание развертывания тестового стенда должно быть:

• максимально подробным.
• актуальным на данный момент.
• содержать описание проверки, а лучше программу, которую запустил и получил статус, что все правильно — это сэкономит кучу времени.

Сложность стенда тестирования зависит от сложности продукта, можно выделить несколько семейств продуктов: сетевая инфраструктура, серверные приложения, десктопные приложения, веб-приложения. Тестовый стенд для каждого из них отличается. Наиболее сложный — продукт сетевой инфраструктуры. Необходимо в виртуальной среде развернуть несколько виртуалок и объединить их в подсеть. После чего проверить, что все правильно на каждой виртуалке. Как это сделать, если виртуалок 400? Правильно, программой и выгрузкой ее работы в лог, 400 логов собираем, объединяем, получаем статус от каждой виртуалки. Насчет 400 я приврал конечно, но 10-15 виртуалок легко могут использоваться.

Поэтому — развертывание тестового стенда это основная часть работы тестировщика.

Тестировщик — гнев.

Значительная часть работы тестировщика уходит на составление отчетов о тестировании. По результату тестирования оформляется общий отчет по выполненному тест-кейсу, а также отдельно описывается каждый баг. Если работа идет в рамках тест-плана (несколько тест-кейсов), то отчет пишется по тест-плану, где перечисляются тест-кейсы в таблице и напротив пишется пройден или нет. Слово “нет” обычно не пишется, а пишется идентификатор бага, заведенного в систему или идентификаторы, если их несколько.

Тестировщик — торг.

Общий алгоритм работы тестировщика следующий:

• получает задачу провести тестирование продукта такой версии согласно такого тест-кейса или тест-плана. Тест-план обычно сбрасывается менеджеру по тестированию и он уже делит список тест-кейсов на подчиненных ему тестировщиков. Тестировщик получает перечень тест-кейсов.
• готовит тестовый стенд согласно требований тест-кейса. Отлично, если выбранные кейсы используют один и тот же стенд, это ускорит работу. Хуже, если для каждого кейса нужен свой стенд.
• проверяет развернутый стенд, что все правильно сделал.
• выполняет сценарий тестирования с отметкой каждого пункта в сценарии.
• оформляет отчет по тест-кейсу. Отчет отправляется или менеджеру по тестированию, который потом объединит все отчеты в один или выгружается в баг-трекинг систему, где объединение произойдет автоматически.
• в случае найденного бага, выполняет поиск похожего бага в баг-трекинг системе, в случае отсутствия похожего бага — оформляет, где указывает полный номер версии продукта, шаги приводящие к багу, ожидаемый результат из тест-кейса и полученный результат, логи и скриншоты, если они позволят ускорить разбор причины возникновения бага.
• берет следующий сценарий.

Тестировщик — депрессия.

Разделяют несколько подходов к тестированию продукта, даже не подходов, а процессов. Это: QA — Quality Assurance, QC — Quality Control и Testing. В чем отличия? Кем я хочу стать? Кто из них тестировщик?

Quality Assurance (обеспечение качества) — ставит целью выпустить продукт максимального качества с момента начала разработки и до выпуска продукта затрагивая все аспекты разработки.

Quality Control (контроль качества) — продукт уже есть, надо измерить его качество.

Testing — процесс проверки качества продукта, разработки тест-кейсов и планов тестирования с оценкой охвата тестирования. Этот процесс является частью вышестоящих QA и QC.

Чистый тестировщик — это участник процесса Testing. Но наиболее интересен здесь QA, т.к. только в этом случае процесс тестирования идет параллельно разработке и большинство проблем можно исправить заранее малой кровью. Это произойдет, если к отделу обеспечения качества будут прислушиваться, иначе это не работает.

Тестировщик — принятие.

Основные аспекты работы я описал. Что еще осталось? На самом деле не очень мало.

Следует постоянно изучать существующие тест-кейсы в проекте и научиться определять процент покрытия функциональности продукта тест-кейсами. В этом случае лучше просить помощи более опытных коллег, для каждого продукта будет свой алгоритм.

Исследовательское тестирование — есть такой вид тестирования. Это процесс тестирования, который не описан в тест-кейсах. Данный подход позволяет посмотреть тестировщику на продукт со стороны пользователя и выполнить действия, которые ни в одном тест-кейса не описаны. Что может привести к ошибке.

Автоматизация — даже без полноценного подхода к автоматизации тестирования это не пустой звук. Работа тестировщика не простая, нужно всегда много держать в голове, выполнять много работы руками, это все тяжким грузом оседает на подсознательном уровне и рано или поздно тестировщик понимает, что занимается совсем не тем. Допустим: есть кейс для проверки корректности логина в систему, в тест-кейсе представлен набор логин и пароль из 10 примеров, их нужно ввести по очереди и получить уведомление от системы, где логин прошел, а где нет. После чего написать отчет. Вроде все просто. Время на этот кейс — 30 минут. Продукт собирается каждую ночь, этот кейс входит в план дымового тестирования, т.е. выполняется на каждой версии в первую очередь. Сколько хватит тестировщика и когда он всех пошлет, чтобы сбежать от такой работы. 10 раз можно выполнить этот кейс, а 100? А если проект на много лет? Поэтому я считаю, что любому тестировщику нужна отдушина. Автоматизация его труда является прекрасной отдушиной. Берем и замеряем время на выполнение задач, разбиваем на типы работ: подготовка стенда, ознакомление с тест-кейсом, выполнение, оформление багов, написание отчета. Подготовка стенда много времени занимает — отлично, автоматизируй это! Не знаешь как? Встречи команды бывают? Обозначь вопрос и тебе подскажут или даже помогут это сделать. И так далее маленькими шажками оптимизируй работу и потом ты уже не думаешь, что завтра с утра надо опять этот кейс с логинами проходить, а думаешь как тебе разрешение экрана в Windows автоматически менять для проверки работы продукта или по сигналу правого глаза отключать сетевую карту ровно на 5 секунд. В любом, даже в самом технологически развитом болоте все чахнет и стоит привнести в этот мир немного красок и света как все налаживается.

Основные методы тестирования:

• белый ящик — про проект все известно, исходный код доступен для исследования, вся документация открыта.
• черный ящик — проект не известен, есть только описанные пары входное значение и выходное значение.
• серый ящик — сборная солянка, что-то доступно, что-то закрыто.

По опыту — белого ящика я не видел ни разу. Обычно это черный ящик с доступом к программистам, которые тебе не рады.

Виды тестирования:

• модульное тестирование (unit-test) — тестирование отдельных функций в коде, пишется программистами.
• интеграционное тестирование — тестирование цепочки модульных тестов или проверка интерфейсов, пишется программистами. Активно используется как отдельная функциональность на серверных продуктах.
• регрессионное тестирование — тестирование старой функциональности после ввода новой. Мы не сломали, что у нас работало до этого.
• нагрузочное тестирование — замер экстремальных показателей продукта и сохранение результатов. В последующем результаты анализируются, чтобы выяснить с какого момента стало лучше/хуже и что именно надо править. Стенд должен быть развернут на реальном железе без виртуалок.
• системное тестирование — проверка работы программы на системе с разной конфигурацией, чтобы выяснить какое оборудование продукту нужно для штатной работы. Системное тестирование выполняется без виртуалок на реальном железе.
• предрелизное и релизное тестирование — проверка работы продукта для присвоения версии релиз кандидат или релиз. Отчет по тестированию анализируется руководством проекта для принятия решения — можно ли присваивать продукту статус релиз кандидат или релиз.
• приемочное тестирование — проверка готовности продукта к началу продаж, отправляется менеджеру продукта с рекомендацией выпустить данную версию продукта в продажу. Менеджер продукта по своей цепочке пропускает этот отчет и если получает от всех “добро” — продукт в продаже.

Должности и обязанности в тестировании.

Тестировщик — специалист выполняющий работу по сценариям тестирования с последующим отчетом и регистрацией багов.

Тест-дизайнер — специалист разрабатывающий тест-кейсы и планы тестирования, четко понимает процент охвата функциональности продукта тест-кейсами. Является интерфейсом между командой разработки и командой контроля качества. Присутствует на встречах и там и тут. Знает куда движется проект и как он будет это все тестировать. Также знает способности каждого тестировщика, чтобы ранжировать по сложности тест-кейсы.

Менеджер по тестированию — организовывает работу команды контроля качества, занимается процессами увольнения, приема и ротации сотрудников. Обеспечивает команду аппаратными и программными средствами. Своевременно доводит до руководства проблемы и потребности в работе команды контроля качества. Совместно с менеджером проекта принимает решения о готовности продукта и стремится выпустить максимально качественный продукт. Занимается ростом профессионального уровня членов команды.

Авто-тестировщик — специалист, который с помощью программы заменяет действия тестировщика. В результате получается журнал тестирования, где указано, что прошло успешно, а что нет. Но с момента обнаружения бага, работа авто-тестировщика и тестировщика совпадает полностью, оформление бага обычно происходит в ручную. Именно должности “авто-тестировщик” я не видел, устраивались как “программист”.

Есть еще разные направления тестирования, допустим: тестирование локализаций продукта на разные языки, тестирование документации, нагрузочное тестирование. В таких случаях, тестирование проводят не тестировщики, а технические писатели в случае локализаций и документации и исследователи в случае нагрузочного тестирования.

Работа тестировщиком многогранна и необъятна, у меня были случаи, когда сотрудники хотели уйти в программирование или devops и я всегда их отговаривал. Приоритет следующий — в тестировании я не ограничен в технологиях, у меня куча и еще 100 вариантов сделать какую-то вещь. Остальные специалисты жестко ограничены стеком технологий. И такая свобода позволяет всегда находить что-то новое и интересное в профессии тестировщика.

Интересные баги из практики.

• логи и ненужная информация: регистрация в логе токена для логина в продукт, регистрация логина и пароля в открытом виде — один раз понадобилось программисту убедиться, что он правильно все присваивает и вот, убрать то это он забыл. Как это еще код-ревью прошло — никто не знает. Логам стоит уделять отдельное внимание, там можно много интересного найти. Да, если при работе программы лог разрастался и заканчивалось место на диске — продукт падал.
• для установки продукта надо 115 мб. пространства, оставляю ровно 115 мб., ставлю продукт, устанавливаю защитный ключ — продукт падает с ошибкой. Отметка об успешной установке продукта есть, продукт не работает, компьютер заблокирован.
• продукт устанавливается на медленную виртуалку (1 гб память, 1 ядро, Windows 8.1). Статуса успешной установки нет, установщик прекращает работу без сообщений об ошибке. В дальнейшем, все работает нормально, но статуса то нет. Проблема была в команде sleep(1000); Установка происходила в другом потоке и по окончанию поток не успевал закончить работу (медленная виртуалка), программист посчитал, что секунды ему должно хватить, а это не так. В результате статус не записывался, т.к. корневой поток заканчивал работу раньше вспомогательного.

Что такое сборка стенда и чем отличается от деплоя ?

Скажите Что такое сборка стенда и деплой стенда и чем они отличаются ?

Как и для чего делать сборку стенда и деплой Какие программные инструменты для этого используется?

#2 SALar

Отправлено 18 октября 2018 — 11:52

Попробуй найти книгу: https://www.ozon.ru/. ail/id/7243884/ «Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ».

Мне ее рекомендовал очень крутой специалист. Сам я ее только полистал.

facebook (Дети диаграммы Ганта)