Автоматизация тестирования - это пот, кровь и слезы
•Descargar como PPTX, PDF•
0 recomendaciones•802 vistas
Под капотом автоматизации тестирования продукта для защиты виртуализации
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a Автоматизация тестирования - это пот, кровь и слезы
Similar a Автоматизация тестирования - это пот, кровь и слезы (20)
Автоматизация тестирования - это пот, кровь и слезы
- 1. Автоматизация тестирования - это пот, кровь и слезы Под капотом автоматизации тестирования продукта для защиты виртуализации Максим Шульга, Код Безопасности
- 2. О себе Шульга Максим 15 лет разрабатываю софт, 10 лет с тестами Начальник отдела разработки и тестирования “Код Безопасности” http://maxshulga.ru @maxbeard 2 Все используемые картинки являются собственностью тех, кто их запостил в Интернет
- 3. Автоматизация тестирования - это пот, кровь и слезы 3 Больше пота = меньше крови @maxbeard12
- 4. Автоматизация - как начать и не бросить? Зачем нужна автоматизация тестирования? Какие инструменты использовать? Запуск, анализ результатов тестов Как эти тесты рождаются Общие рекомендации Полезные ссылки 4 Помидоры сюда > @maxbeard12
- 5. vGate - защита VMware vSphere или Microsoft Hyper-V 5
- 6. Особенности разработки vGate (в т.ч тестирования) 6 - 95% кода это С++, много низкоуровневых частей (драйвера, сетевые протоколы, хаки) => особенности автоматизации - сертифицируемый продукт => сложности с фиксами - большое количество вариантов использования => подготовка стендов, запуск одних и тех же тестов на разном окружении @maxbeard12
- 7. Особенности разработки vGate (в т.ч тестирования) 7 - распределенное развертывание => в проверке сценариев участвуют несколько машин - 95% компонентов работают на Windows = вопросы по выбору инструментов - много legacy => есть древние непокрытые тестами куски кода @maxbeard12
- 8. Автоматизация - как начать и не бросить? Зачем нужна автоматизация тестирования? Какие инструменты использовать? Запуск, анализ результатов тестов Как эти тесты рождаются Общие рекомендации Полезные ссылки 8
- 9. Выбор инструмента Свой велосипед vs готовое решение На чем писать: 1. Язык продукта 2. Python 3. Отталкиваемся от “исторических причин” 4. Отталкиваемся от API “окружения” 5. Тулы (автоматизация В тестировании) 6. Еще что-нибудь? http://www.maxshulga.ru/2015/04/how-to-find-correct-test-framework.html 9@maxbeard12
- 10. “Уровень” тестов 10 Пагубная страсть к ритуальным сооружения? @maxbeard12
- 12. Как у нас дела с “пирамидой” тестирования? - мало юнит-тестов - много высокоуровневых - нет тестов на UI 12@maxbeard12
- 13. У нас не пирамида, у нас небоскреб :) 13 Rainer Tower Seattle 1977 год 156 м
- 14. Автоматизация - как начать и не бросить? Зачем нужна автоматизация тестирования? Какие инструменты использовать? Запуск, анализ результатов тестов Как эти тесты рождаются Общие рекомендации Полезные ссылки 14
- 15. Модульные тесты (язык продукта) Используем gtest и gmock (Google C++ test framework) Большей частью ими тестируется библиотечный код Не брезгуем несколькими проверками в одном тесте (Expect vs Assert) gtest используется не только для “канонических” юнит-тестов Моя презентация “Тестируем legacy C++” (http://www.slideshare.net/MaximShulga/legacy-c- 15355976) 15@maxbeard12
- 16. Модульные тесты - почему мало? Много хак-кода, драйвера Удобнее писать тесты на “реале” - у разработчиков есть возможность разворачивать стенды на своей машине А может просто не умеем... 16@maxbeard12
- 17. Модульные тесты - почему мало? Много хак-кода, драйвера Удобнее писать тесты на “реале” Меняешь реализацию, а тесты продолжают работать 17@maxbeard12
- 18. Инструменты для “немодульных” тестов vGate Исторические причины = STAF/STAX + C# NUnit API окружения = FitNesse + PowerSlim Язык продукты = gtest (тесты похожи на “юнит”, но работают с реальной системой) Тулы = sikuli (www.sikuli.org) используем для активации функциональности vSphere Web Client (flash) 18@maxbeard12
- 19. STAF/STAX http://staf.sourceforge.net Больше 14 лет и до сих пор живой FREE Multi-platform (Windows, Unix) Multi-agents Универсальный запускатель 19@maxbeard12
- 20. FitNesse+PowerSlim 20 FitNesse http://www.fitnesse.org/ – 10 лет, Java, C#, C++, Python PowerSlim – почти 5 лет. Quest Software, Dell, Код Безопасности https://github.com/konstantinvlasenko/PowerSlim @maxbeard12
- 24. FitNesse+PowerSlim 24 Неожиданности (непривычности) при использовании Недостаточно программерский инструмент ;) Несолидно ;) Больше про PowerSlim тут http://www.maxshulga.ru/search/label/Fitnesse @maxbeard12
- 26. Тулы для “нефункциональных” тесты Нам важно не замедлять работу пользователя с виртуальной инфраструктурой Эмуляция пользовательской нагрузки (PowerShell) Стабилизация (утечки, работа с базой) Нагрузка на сеть (iperf3) 26“Нагрузочные тесты прошли” (с) @maxbeard12
- 27. Автоматизация - как начать и не бросить? Зачем нужна автоматизация тестирования? Какие инструменты использовать? Запуск, анализ результатов тестов Как эти тесты рождаются Общие рекомендации Полезные ссылки 27@maxbeard12
- 28. Незапускаемые регулярно тесты - мертвые тесты. Jenkins (1.625.3) - наша “всея запускалка”: Сборка Скрипты развертывания Запуск тестов 28 “Утро после ночного билда”@maxbeard12
- 29. Приемы использования Jenkins и полезные расширения Параметризуемые “работы” (Job Config History) Связки из “работ” (Build Flow, Copy Artifact) Мониторинг (Build Monitor) Еще полезности: Artifact Deployer, Build timeout 29@maxbeard12
- 31. Тесты прошли. Что дальше? 31 @maxbeard12
- 32. Тесты прошли. Что дальше? Анализ результатов Контроль времени выполнения Учет количества запущенных тестов Борьба с “моргающими” тестами Багофикс 32@maxbeard12
- 33. Анализ результатов Диагностика История результатов запусков Облегчение для разбора тестов (например, логирование старт-стопа тестов в логи продукта) 33@maxbeard12
- 34. Как релизимся? Спрашивают - отвечаем - Каждый релиз с Чумаком? - Нет, не каждый. Кашпировского еще призываем, шаманов и прочих экстрасексов :) 34@maxbeard12
- 35. Как релизимся? Время полной автопроверки сейчас около 2-х рабочих дней Ручная проверка (сетапы, UI) Code freeze (1-2 недели) 35@maxbeard12
- 36. Автоматизация - как начать и не бросить? Зачем нужна автоматизация тестирования? Какие инструменты использовать? Запуск, анализ результатов тестов Как эти тесты рождаются Общие рекомендации Полезные ссылки 36@maxbeard12
- 37. Как тесты рождаются? Test first? It depends on… Обсуждение того, что будем проверять Анализ уже имеющихся “кубиков” для настройки окружения, продукта, проверок Разработчик отвечает за то, чтобы его код проверялся Боремся с “хвойными” (вечнозелеными) тестами 37@maxbeard12
- 38. Общие рекомендации по автоматизации Автоматизация - работа всей команды Разработчики должны участвовать в автоматизации 38 Теория “сухого памперса” @maxbeard12
- 39. Общие рекомендации по автоматизации Автоматизировать или нет? Если не нужно, то не надо. Вы поймете, когда нужно. Начните с малого. 39@maxbeard12
- 40. Общие рекомендации по автоматизации Начните с малого. ● legacy: Начните писать тесты на фиксы (может даже через UI), начните писать новый код с тестами ● Изучаете новый язык - изучайте тестовые инструменты к нему ● при выборе ATF учитывайте архитектуру вашего приложения и то окружение в котором он работает ● Контроль за временем выполнения 40@maxbeard12
- 41. Автоматизация тестирования - это пот, кровь и слезы 41 Больше пота = меньше крови @maxbeard12
- 42. Общие рекомендации по автоматизации 42 Больше пота = меньше крови Но коэффициент меняется... @maxbeard12
- 43. Полезные ссылки Автоматизация тестирования. С чего начинать, возможные проблемы Как перестать бояться и начать автоматизировать (А. Лянгузов) Сказка-быль о попытке оценить ROI автоматизации (Н.Макаров) Серия статей о FitNesse+PowerSlim Про Code Freeze от С.Мартыненко (http://blog.shumoos.com/archives/317) ГОСТ Р 56939-2016 Защита информации. Разработка безопасного программного обеспечения. Общие требования *линки можно увидеть на последнем слайде 43@maxbeard12
Notas del editor
- меня зовут Максим и я автоматизатор. На самом деле я разработчик вынужденный в настоящее время скрываться за табличкой начальник отдела, но в душе я автоматизатор. Автоматизацией тестирования я занимаюсь уже больше 10 лет, и ей посвящены многие статьи в моем блоге и твиттере. Этот доклад готовился к одной из конференций, но в силу ряда причин никуда не попал. Подумалось, что потраченный труд не должен пропадать зря - поэтому получился вот этот видеокаст. 1.5 года назад я участвовал в первом выпуске подкаста RadioQA (кстати, если вы его еще не слушаете, то настойчиво рекомендую). Так вот, в том выпуске разговор шел о вовлечении разработчиков в тестирование. Одним из удобных способов это сделать я считаю автоматизацию тестирования.
- В подкасте я говорил, и готов это сделать сейчас, что автоматизация тестирования - это пот, кровь и сопли. Причем действует строгое соотношение “больше пота = меньше крови”. Полностью избавиться от крови не получится (хотя бы потому что мозольки лопаться будут), но уменьшить ее количество можно.
- Думаю многие из вас занимаются автоматизацией тестирования, или хотят этим заниматься. В чем, на мой взгляд, основная проблема в этой области? Парадокс заключается в том, что многие не понимают зачем им эта автоматизация нужна и как ею правильно пользоваться, как внедрять. Определить то, зачем автоматизация нужна - самое важное. От этого будет плясать все остальное. И многое здесь зависит от того продукта, который вы тестируете. Дальше определяетесь какие инструменты вы будете использовать и в бой. Забегая вперед скажу, что одним написанием тестов дело далеко не ограничивается. План внедрения автоматизации: зачем нужна автоматизация? какие инструменты использовать? запуск тестов анализ тестов рождение новых тестов (процесс написания новых тестов будет менятся, имхо не следует заострять на этом внимание в первое время)
- Рассмотрим для примера наш случай - продукт по защите виртуализации. Задача vGate - расширить возможности контроля безопасности при работе с виртуальными инфраструктурами на базе vSphere и Hyper-V. Контролируем действия администраторов
- Особенности разработки vGate: Очередная особенность vGate - это то, что он большей частью работает не сам не себе, а внутри софта который делает виртуализацию. Поэтому иногда баг в vGate - это "умершая" виртуализация у заказчика. И проверить vGate - это в т.ч заюзать максимально полно всю функциональность платформы виртуализации (порядка 1000 методов в API) это важно и как с точки зрения "не завалили сервак", так и "не оставили дырку" Сложные конфигурации включают до 10 машин. В качестве платформы для запуска используем VMware ESXi и Workstation. Даже для проверки Hyper-V Так как мы, в том числе проходим сертификацию в ФСТЭК - требования к качеству очень высокие. И это не связано с тем, как нас проверяют. А с тем, что проблему очень сложно (на грани "невозможно") исправить после релиза. факапы все равно происходят, человеческий фактор никто не отменял. поэтому большое внимание уделяем автоматизации. время перепроверки не менее года Итого: нам нужно иметь возможность проверки действий администраторов виртуальных инфраструктур на разных платформах виртуализации и всех способах развертывания vGate не допуская регрессии качества продукта.
- Тестируем мы всяко-разнообразно. Многое навеяно "историческими причинами", многое уже поменяли, многое еще предстоит написать (например веб) Сейчас мы стараемся автоматизировать проверки всей новой функциональности. Не покрываются автотестами UI и часть функциональности сетапов. Текущий UI(десктоп) автоматизировать сложно,эффективность сомнительна,а гемора море.Новый веб в чисто UI части пока постигает та же участь
- Обратить внимание на mock-stub. Самая распространенная ошибка при использовании моков - не “краснить” тест
- Начнем с последних двух: gtest - тестирование сетевой библиотеки, библиотеки для работы с Windows-службами, реестром sikulu - работа по скриншоту. есть “особенности”, но в целом помогает
- Особенности: XML-based programming language (функции, параметры, условия, циклы) Возможности запуска внешних программ, пересылка файлов Есть возможность параллелизации Задержки при резолве имен хостов (решается hosts) Пришли к этому инструменту проанализировав наши потребности и те наработки, которые уже были на тот момент. Техническое решение имеет долгую историю и изначально началось с "велосипеда",недостатки которого со временем вылились в поиски нов. способа. Решение и сейчас остается достаточно сложно и обладает рядом недостатков, но главную задачу выполняет - отломанную функциональность ловит Этими тестами заведуют тестировщики, и ими проверяются ядро vGate и его часть работающая с защитой VMware Стенды под VMware разворачиваются руками, потому как автоматом это сделать наверно можно - но очень сложно. Оно и руками не всегда получается...Очень ресурсоёмкая и капризная зверюга
- В качестве движка юзается PowerShell,что удобно тк все управление HyperV реализовано через ps-cmdletы.Изображать из себя пользователя -легко Самая главная фишка: возможность выполнять шаги по настройке,проверке и тп на разных серверах в рамках одного тестового сценария. тесты на powerslim целиком вотчина разрабов. Они вольны сами определять где, когда и какие тесты запускать Эти тесты можно запускать на машинах программистов, параллельно с разработкой кода, подкладывая на свой стенд новые компоненты Для Hyper-V есть эталонная лаба, под которую пишутся тест и от которой клонируются остальные. При этом в снепшоты ничего не загоняется. Стараемся все настраивать скриптами. У нас винда - поэтому PowerShell.
- Эти тесты можно запускать на машинах программистов, параллельно с разработкой кода, подкладывая на свой стенд новые компоненты Для Hyper-V есть эталонная лаба, под которую пишутся тест и от которой клонируются остальные. При этом в снепшоты ничего не загоняется. Стараемся все настраивать скриптами. У нас винда - поэтому PowerShell.
- Обратите внимание на то, что тест выполняет действия на разных машинах. Действия = запуск PowerShell команд (включая достаточно сложный код с функциями)
- В PowerShell работает, а в Fitnesse может не заработать сразу Нет IDE и ее плюшек. Но - новая версия FitNesse немного получше. Plugin в sublime «Я хочу писать тесты на языке программирования, а не на wiki». Лицо моего ведущего (сейчас руководитель разработки) после месяца “фитнеса”.
- Многие путают автоматизацию тестирования UI и “через” UI. Мне порой кажется что тесты через UI - это все равно что залезать вверх по дереву забыв отстегнув парашют. Если вам повезет и вы доберетесь до нужной точки не запутавшись - то хорошо. Но вообще это везение зависит от длины строп и густоты веток. Хотя думаю, что у многих это почти единственный способ автоматизации тестирования. Ключевое слово “почти”.
- Параллельно функциональному тестированию идут задаче по нагрузочному У нас эти задачи несколько отличаются от привычных многим"много пользователей, много качают".У нас польз-лей немного, но они могут захотеть включить много ВМ одновременно. У нас смотрится просадка по сетевому трафику, просадка по времени на операцию с вирт.инфрастуктурой, например старт ВМ Чтобы наши проверки прав доступа не приводили к тому, что ВМ долго стартится Пишем свои утилиты-эмуляторы, которые позволяют оценить работу БД например под большим потоком аудита.
- Тесты мало написать - их надо запускать
- Сборка билдов запускается каждую ночь, после сборки и прогона юнит-тестов запускается smoke-сюита Запуск покомитной сборки сейчас не используется, ресурсов не хватает Время выполнения smoke-сюиты около 1 часа (минисмок 25 мин). Проверка развертывания продукта и базовой функциональности Каждая работа в Jenkins запускает свой набор тестовых сюит (иногда пересекающийся) на заданном, конфигурируемом окружении. Перед запуском нужное окружение включается, настраивается под запуск конкретного набора. Потом запускаются тяжеловесы, часть идет около 2-3 часов, есть и по 8. Проверять надо на всех вариантах поддерживаемой вирт.инфраструктуры и способах развертывания продукта. Комбинаций много, но не все автоматиз Из трудностей которые мы постоянно решаем: время прогона, дробление работ на мелкие, оптимизация производительности стендов
- Существует одна работа-шаблон (параметризуемая), которая все собственно и делает и никаких явных параметров не хранит. Запускаемые работы, где задается набор окружения, набор тестов, настроек продукта, передают все это хозяйство шаблон-исполнитель, который и производит непосредственный запуск процедуры Это дает возможность держать и редактировать все экшены в одном месте, а кастомизации делать снаружи и по необходимости Включается машина, прогоняются настроечные скрипты, поехали тесты Возвращаясь к настройкам и кастомизации Jenkins-работы. Сейчас есть проблема в размытии места хранения этого всего. Что то живет вместе с исходниками продукта (тесты частью живут вместе с базовым кодом),а что то в настройках Jenkins Настройки живут как в самой работе, так и скриптах, которые она использует (мы активно пользуем PowerShell) Получается не очень хорошо: надо понимать что и где искать. И у обоих способов есть проблемы: Изменение настроек Jenkins влияет на всех, кто использует эту работу, 1/N Есть проблемы с параллельным тестированием разных версий продукта, у нас это недавно появилось 2/N Проблема поискать и найти нужные тебе настройки 3/N Все настройки Jenkins не под гитом. Есть плагины по истории изменений, но это не так удобно. 4/4 У нас нет отдельных DevOps
- Если зеленые, то вопросов нет. Хотя… если у вас зеленые тесты больше 2х дней подряд, то похоже надо убедиться что разработчики хоть что-нибудь делают :)
- Кроме того "успешно-неуспешно" важно еще контролировать время выполнения тестов и кол-во запущенных тестов у меня в практике были случаи когда часть тестов просто переставала запускаться и это долгое время никто не видел Время выполнения интересно смотреть для обнаружения изменений в продукте приводящих к его замедлению С "красно-зелено" в тестах вроде все ясно. Красно может быть из-за баги в продукте, тесте или окружении. Влияние багов окружения на тесты может приводить к "моргающим" тестам, когда от запуску к запуску тест то зеленый, то красный Имхо борьба с "морганиями" самая "веселая" активность при автоматизации проверок. У нас нет автоматического перезапуска свалившихся тестов. каждый фейл разбирается индивидуально.Часто таким образом находятся интересные баги Это могут быть так называемые "test war", когда тесты мешают друг другу. Тоже веселая штука. А может бага в продукте, проявляющаяся в условиях последовательного выполнения определенных шагов: то есть по отдельности сюиты зеленые, а вместе - печаль Снепшот стендов, если есть “краснота” баги обнаруженные тестами, которыми занимаются программисты никуда не пишутся - просто сразу чиним баги обнаруженные тестами, которыми занимаются тестировщики, попадают в TFS,откуда чинятся с высоким приоритетом (так как проверка красная) Сейчас мы такого не делаем, но на прошлом месте во время запуска тестов еще анализировалась стабильность работы продукта: утечки, например
- Мало увидеть что “все плохо”. Важный параметр автотестов - это сложность диагостики, “что именно пошло не так и почему” Смотреть рез-ты можно в Jenkins (рез-ты первого уровня да/нет, причина в первом приближении, например какая сюита отвалилась) Fitnesse умеет сам хранить и показывать результаты запусков Но если запускать много сюит, а у нас их больше 100 (на Hv), то хочется видеть рез-ты сюит одного запуска в 1 месте Для этого результат выполнения fit-тестов(xml) заносим в базу и показываем все вместе Процесс запуска и рез-т выполнения этих тестов записывается в базу, откуда потом самописанной штукой делаются отчеты по прогонам Отчеты достаточно подробны и по сути своей напоминают раскрашенные логи запусков
- каждый релиз с чумаком ? не, не каждый. Кашпировского еще призываем, шаманов и прочих экстрасексов ))) Все баги найти и зачинить нельзя. Тестирование можно только прекратить, что иногда и делается, пока идет стабилизация.
- Как я уже говорил - UI и сетапные сценарии (там тоже UI) не автоматизируем, поэтому для релиза одних "зеленых" автотестов недостаточно Релизимся когда все критикалы пофикшены, тесты зел(или понятно почему красные и мы это не чиним) и готова куча доков Где то недели за 2 до предполагаемой даты релиза все фиксы только после бурного обсуждения. Если что-нибудь серьезное и пересборка, это повод двигаться.
- Тесты мало написать - их надо запускать
- Кстати про проверку самого теста. Я настойчиво рекомендую делать тест сначала красным, убедиться что проверка работает. Это можно сделать еще до написания фичи в продукте (ATDD), а можно вводя преднамеренные ошибки в настройках например При определении того,кто будет писать тест,учитывается предметная область изменений и ужеимеющ. "кубики" для проверок.Где проще-там и делаем Часть разработчиков сама пишет тесты (не только юнит) - им так удобнее заводить и проверять Часть договаривается с тестировщиками и обеспечивает их "ручками" для проверк
- перепроверка - около года на 1 человека legacy: Начните писать тесты на фиксы (может даже через UI), начните писать новый код с тестами Изучаете новый язык - изучайте тестовые инструменты к нему при выборе ATF учитывайте архитектуру вашего приложения и то окружение в котором он работает Контроль за временем выполнения Научиться писать тесты можно, главное начать, Но нужно понимать, что жить с ними долго и дружно, поддерживать их - это труд, постоянный, часто нудный, но без него никак
- перепроверка - около года на 1 человека legacy: Начните писать тесты на фиксы (может даже через UI), начните писать новый код с тестами Изучаете новый язык - изучайте тестовые инструменты к нему при выборе ATF учитывайте архитектуру вашего приложения и то окружение в котором он работает Контроль за временем выполнения Научиться писать тесты можно, главное начать, Но нужно понимать, что жить с ними долго и дружно, поддерживать их - это труд, постоянный, часто нудный, но без него никак
- Итого: В реальной жизни формула не работает идеально
- Итого: колебания кол-ва крови Важно понимать, что бесплатной автоматизации не будет. Постоянная поддержка автотестов: если много изменений постоянно, гибкая архитектура и т.д. - будет адово, если не предусматривать заранее соломки (опыт, иначе просто потеря времени). Так как продукт развивается - то тесты обязаны развиваться (меняться) Автоматизация - это работа всей команды Автоматизация - это постоянная работа. И пот, кровь и слезы...