Автоматизация тестирования - это пот, кровь и слезы

Editor's Notes

• #3: меня зовут Максим и я автоматизатор. На самом деле я разработчик вынужденный в настоящее время скрываться за табличкой начальник отдела, но в душе я автоматизатор. Автоматизацией тестирования я занимаюсь уже больше 10 лет, и ей посвящены многие статьи в моем блоге и твиттере. Этот доклад готовился к одной из конференций, но в силу ряда причин никуда не попал. Подумалось, что потраченный труд не должен пропадать зря - поэтому получился вот этот видеокаст. 1.5 года назад я участвовал в первом выпуске подкаста RadioQA (кстати, если вы его еще не слушаете, то настойчиво рекомендую). Так вот, в том выпуске разговор шел о вовлечении разработчиков в тестирование. Одним из удобных способов это сделать я считаю автоматизацию тестирования.
• #4: В подкасте я говорил, и готов это сделать сейчас, что автоматизация тестирования - это пот, кровь и сопли. Причем действует строгое соотношение “больше пота = меньше крови”. Полностью избавиться от крови не получится (хотя бы потому что мозольки лопаться будут), но уменьшить ее количество можно.
• #5: Думаю многие из вас занимаются автоматизацией тестирования, или хотят этим заниматься. В чем, на мой взгляд, основная проблема в этой области? Парадокс заключается в том, что многие не понимают зачем им эта автоматизация нужна и как ею правильно пользоваться, как внедрять. Определить то, зачем автоматизация нужна - самое важное. От этого будет плясать все остальное. И многое здесь зависит от того продукта, который вы тестируете. Дальше определяетесь какие инструменты вы будете использовать и в бой. Забегая вперед скажу, что одним написанием тестов дело далеко не ограничивается. План внедрения автоматизации: зачем нужна автоматизация? какие инструменты использовать? запуск тестов анализ тестов рождение новых тестов (процесс написания новых тестов будет менятся, имхо не следует заострять на этом внимание в первое время)
• #6: Рассмотрим для примера наш случай - продукт по защите виртуализации. Задача vGate - расширить возможности контроля безопасности при работе с виртуальными инфраструктурами на базе vSphere и Hyper-V. Контролируем действия администраторов
• #8: Особенности разработки vGate: Очередная особенность vGate - это то, что он большей частью работает не сам не себе, а внутри софта который делает виртуализацию. Поэтому иногда баг в vGate - это "умершая" виртуализация у заказчика. И проверить vGate - это в т.ч заюзать максимально полно всю функциональность платформы виртуализации (порядка 1000 методов в API) это важно и как с точки зрения "не завалили сервак", так и "не оставили дырку" Сложные конфигурации включают до 10 машин. В качестве платформы для запуска используем VMware ESXi и Workstation. Даже для проверки Hyper-V Так как мы, в том числе проходим сертификацию в ФСТЭК - требования к качеству очень высокие. И это не связано с тем, как нас проверяют. А с тем, что проблему очень сложно (на грани "невозможно") исправить после релиза. факапы все равно происходят, человеческий фактор никто не отменял. поэтому большое внимание уделяем автоматизации. время перепроверки не менее года Итого: нам нужно иметь возможность проверки действий администраторов виртуальных инфраструктур на разных платформах виртуализации и всех способах развертывания vGate не допуская регрессии качества продукта.
• #13: Тестируем мы всяко-разнообразно. Многое навеяно "историческими причинами", многое уже поменяли, многое еще предстоит написать (например веб) Сейчас мы стараемся автоматизировать проверки всей новой функциональности. Не покрываются автотестами UI и часть функциональности сетапов. Текущий UI(десктоп) автоматизировать сложно,эффективность сомнительна,а гемора море.Новый веб в чисто UI части пока постигает та же участь
• #18: Обратить внимание на mock-stub. Самая распространенная ошибка при использовании моков - не “краснить” тест
• #19: Начнем с последних двух: gtest - тестирование сетевой библиотеки, библиотеки для работы с Windows-службами, реестром sikulu - работа по скриншоту. есть “особенности”, но в целом помогает
• #20: Особенности: XML-based programming language (функции, параметры, условия, циклы) Возможности запуска внешних программ, пересылка файлов Есть возможность параллелизации Задержки при резолве имен хостов (решается hosts) Пришли к этому инструменту проанализировав наши потребности и те наработки, которые уже были на тот момент. Техническое решение имеет долгую историю и изначально началось с "велосипеда",недостатки которого со временем вылились в поиски нов. способа. Решение и сейчас остается достаточно сложно и обладает рядом недостатков, но главную задачу выполняет - отломанную функциональность ловит Этими тестами заведуют тестировщики, и ими проверяются ядро vGate и его часть работающая с защитой VMware Стенды под VMware разворачиваются руками, потому как автоматом это сделать наверно можно - но очень сложно. Оно и руками не всегда получается...Очень ресурсоёмкая и капризная зверюга
• #22: В качестве движка юзается PowerShell,что удобно тк все управление HyperV реализовано через ps-cmdletы.Изображать из себя пользователя -легко Самая главная фишка: возможность выполнять шаги по настройке,проверке и тп на разных серверах в рамках одного тестового сценария. тесты на powerslim целиком вотчина разрабов. Они вольны сами определять где, когда и какие тесты запускать Эти тесты можно запускать на машинах программистов, параллельно с разработкой кода, подкладывая на свой стенд новые компоненты Для Hyper-V есть эталонная лаба, под которую пишутся тест и от которой клонируются остальные. При этом в снепшоты ничего не загоняется. Стараемся все настраивать скриптами. У нас винда - поэтому PowerShell.
• #23: Эти тесты можно запускать на машинах программистов, параллельно с разработкой кода, подкладывая на свой стенд новые компоненты Для Hyper-V есть эталонная лаба, под которую пишутся тест и от которой клонируются остальные. При этом в снепшоты ничего не загоняется. Стараемся все настраивать скриптами. У нас винда - поэтому PowerShell.
• #24: Обратите внимание на то, что тест выполняет действия на разных машинах. Действия = запуск PowerShell команд (включая достаточно сложный код с функциями)
• #25: В PowerShell работает, а в Fitnesse может не заработать сразу Нет IDE и ее плюшек. Но - новая версия FitNesse немного получше. Plugin в sublime «Я хочу писать тесты на языке программирования, а не на wiki». Лицо моего ведущего (сейчас руководитель разработки) после месяца “фитнеса”.
• #26: Многие путают автоматизацию тестирования UI и “через” UI. Мне порой кажется что тесты через UI - это все равно что залезать вверх по дереву забыв отстегнув парашют. Если вам повезет и вы доберетесь до нужной точки не запутавшись - то хорошо. Но вообще это везение зависит от длины строп и густоты веток. Хотя думаю, что у многих это почти единственный способ автоматизации тестирования. Ключевое слово “почти”.
• #27: Параллельно функциональному тестированию идут задаче по нагрузочному У нас эти задачи несколько отличаются от привычных многим"много пользователей, много качают".У нас польз-лей немного, но они могут захотеть включить много ВМ одновременно. У нас смотрится просадка по сетевому трафику, просадка по времени на операцию с вирт.инфрастуктурой, например старт ВМ Чтобы наши проверки прав доступа не приводили к тому, что ВМ долго стартится Пишем свои утилиты-эмуляторы, которые позволяют оценить работу БД например под большим потоком аудита.
• #28: Тесты мало написать - их надо запускать
• #29: Сборка билдов запускается каждую ночь, после сборки и прогона юнит-тестов запускается smoke-сюита Запуск покомитной сборки сейчас не используется, ресурсов не хватает Время выполнения smoke-сюиты около 1 часа (минисмок 25 мин). Проверка развертывания продукта и базовой функциональности Каждая работа в Jenkins запускает свой набор тестовых сюит (иногда пересекающийся) на заданном, конфигурируемом окружении. Перед запуском нужное окружение включается, настраивается под запуск конкретного набора. Потом запускаются тяжеловесы, часть идет около 2-3 часов, есть и по 8. Проверять надо на всех вариантах поддерживаемой вирт.инфраструктуры и способах развертывания продукта. Комбинаций много, но не все автоматиз Из трудностей которые мы постоянно решаем: время прогона, дробление работ на мелкие, оптимизация производительности стендов
• #30: Существует одна работа-шаблон (параметризуемая), которая все собственно и делает и никаких явных параметров не хранит. Запускаемые работы, где задается набор окружения, набор тестов, настроек продукта, передают все это хозяйство шаблон-исполнитель, который и производит непосредственный запуск процедуры Это дает возможность держать и редактировать все экшены в одном месте, а кастомизации делать снаружи и по необходимости Включается машина, прогоняются настроечные скрипты, поехали тесты Возвращаясь к настройкам и кастомизации Jenkins-работы. Сейчас есть проблема в размытии места хранения этого всего. Что то живет вместе с исходниками продукта (тесты частью живут вместе с базовым кодом),а что то в настройках Jenkins Настройки живут как в самой работе, так и скриптах, которые она использует (мы активно пользуем PowerShell) Получается не очень хорошо: надо понимать что и где искать. И у обоих способов есть проблемы: Изменение настроек Jenkins влияет на всех, кто использует эту работу, 1/N Есть проблемы с параллельным тестированием разных версий продукта, у нас это недавно появилось 2/N Проблема поискать и найти нужные тебе настройки 3/N Все настройки Jenkins не под гитом. Есть плагины по истории изменений, но это не так удобно. 4/4 У нас нет отдельных DevOps
• #32: Если зеленые, то вопросов нет. Хотя… если у вас зеленые тесты больше 2х дней подряд, то похоже надо убедиться что разработчики хоть что-нибудь делают :)
• #33: Кроме того "успешно-неуспешно" важно еще контролировать время выполнения тестов и кол-во запущенных тестов у меня в практике были случаи когда часть тестов просто переставала запускаться и это долгое время никто не видел Время выполнения интересно смотреть для обнаружения изменений в продукте приводящих к его замедлению С "красно-зелено" в тестах вроде все ясно. Красно может быть из-за баги в продукте, тесте или окружении. Влияние багов окружения на тесты может приводить к "моргающим" тестам, когда от запуску к запуску тест то зеленый, то красный Имхо борьба с "морганиями" самая "веселая" активность при автоматизации проверок. У нас нет автоматического перезапуска свалившихся тестов. каждый фейл разбирается индивидуально.Часто таким образом находятся интересные баги Это могут быть так называемые "test war", когда тесты мешают друг другу. Тоже веселая штука. А может бага в продукте, проявляющаяся в условиях последовательного выполнения определенных шагов: то есть по отдельности сюиты зеленые, а вместе - печаль Снепшот стендов, если есть “краснота” баги обнаруженные тестами, которыми занимаются программисты никуда не пишутся - просто сразу чиним баги обнаруженные тестами, которыми занимаются тестировщики, попадают в TFS,откуда чинятся с высоким приоритетом (так как проверка красная) Сейчас мы такого не делаем, но на прошлом месте во время запуска тестов еще анализировалась стабильность работы продукта: утечки, например
• #34: Мало увидеть что “все плохо”. Важный параметр автотестов - это сложность диагостики, “что именно пошло не так и почему” Смотреть рез-ты можно в Jenkins (рез-ты первого уровня да/нет, причина в первом приближении, например какая сюита отвалилась) Fitnesse умеет сам хранить и показывать результаты запусков Но если запускать много сюит, а у нас их больше 100 (на Hv), то хочется видеть рез-ты сюит одного запуска в 1 месте Для этого результат выполнения fit-тестов(xml) заносим в базу и показываем все вместе Процесс запуска и рез-т выполнения этих тестов записывается в базу, откуда потом самописанной штукой делаются отчеты по прогонам Отчеты достаточно подробны и по сути своей напоминают раскрашенные логи запусков
• #35: каждый релиз с чумаком ? не, не каждый. Кашпировского еще призываем, шаманов и прочих экстрасексов ))) Все баги найти и зачинить нельзя. Тестирование можно только прекратить, что иногда и делается, пока идет стабилизация.
• #36: Как я уже говорил - UI и сетапные сценарии (там тоже UI) не автоматизируем, поэтому для релиза одних "зеленых" автотестов недостаточно Релизимся когда все критикалы пофикшены, тесты зел(или понятно почему красные и мы это не чиним) и готова куча доков Где то недели за 2 до предполагаемой даты релиза все фиксы только после бурного обсуждения. Если что-нибудь серьезное и пересборка, это повод двигаться.
• #37: Тесты мало написать - их надо запускать
• #38: Кстати про проверку самого теста. Я настойчиво рекомендую делать тест сначала красным, убедиться что проверка работает. Это можно сделать еще до написания фичи в продукте (ATDD), а можно вводя преднамеренные ошибки в настройках например При определении того,кто будет писать тест,учитывается предметная область изменений и ужеимеющ. "кубики" для проверок.Где проще-там и делаем Часть разработчиков сама пишет тесты (не только юнит) - им так удобнее заводить и проверять Часть договаривается с тестировщиками и обеспечивает их "ручками" для проверк
• #40: перепроверка - около года на 1 человека legacy: Начните писать тесты на фиксы (может даже через UI), начните писать новый код с тестами Изучаете новый язык - изучайте тестовые инструменты к нему при выборе ATF учитывайте архитектуру вашего приложения и то окружение в котором он работает Контроль за временем выполнения Научиться писать тесты можно, главное начать, Но нужно понимать, что жить с ними долго и дружно, поддерживать их - это труд, постоянный, часто нудный, но без него никак
• #41: перепроверка - около года на 1 человека legacy: Начните писать тесты на фиксы (может даже через UI), начните писать новый код с тестами Изучаете новый язык - изучайте тестовые инструменты к нему при выборе ATF учитывайте архитектуру вашего приложения и то окружение в котором он работает Контроль за временем выполнения Научиться писать тесты можно, главное начать, Но нужно понимать, что жить с ними долго и дружно, поддерживать их - это труд, постоянный, часто нудный, но без него никак
• #42: Итого: В реальной жизни формула не работает идеально
• #43: Итого: колебания кол-ва крови Важно понимать, что бесплатной автоматизации не будет. Постоянная поддержка автотестов: если много изменений постоянно, гибкая архитектура и т.д. - будет адово, если не предусматривать заранее соломки (опыт, иначе просто потеря времени). Так как продукт развивается - то тесты обязаны развиваться (меняться) Автоматизация - это работа всей команды Автоматизация - это постоянная работа. И пот, кровь и слезы...