Автоматизация тестирования
•Télécharger en tant que PPTX, PDF•
0 j'aime•257 vues
Доклад на конференции Kolesa/Web 1.0
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Автоматизация тестирования
Similaire à Автоматизация тестирования (20)
Plus de Колёса Крыша Маркет
Автоматизация тестирования
- 2. Уровни тестирования • Запуск кода программистом(Smoke test) • Статический анализ кода (code review) • Автоматизированное регрессионное тестирование • Ручное тестирование (nf, imprv, bug) • Анализ дизайна
- 3. Код ревью ?
- 5. Польза ? • Улучшается качество кода • Находятся глупые ошибки(опечатки) в реализации • Повышается степень совместного владения кодом • Код приводится к единому стилю написания • Хорошо подходит для обучения “новичков”, быстро набирается навык • Распространение знаний • Обеспечение обмена опытом внутри команды.
- 6. Стоимость качества Из статьи B. Boehm and V. Basili «Software Defect Reduction Top 10 List» (IEEE Computer, IEEE Computer Society, Vol. 34, No.1, January 2001, pp. 135-137.)
- 7. Или так Если стоимость усилий, необходимых для обнаружения и устранения ошибки на стадии написания кода, принять за единицу
- 8. Дефекты которые могут быть найдены в рамках код ревью : • Обращение к переменной которой не существует или не присвоено значение • Переменные которые не используются или не корректно объявлены • Не выполняемые ветки кода • Пропущенная или неверная логика (бесконечные циклы) • Излишне сложные конструкции • Отклонение от стандартов программирования • Уязвимости в безопасности • Нарушение синтаксиса в код
- 9. Преимущества внедрения код ревью • Ранее исправление дефектов до проведения тестирования • Уменьшение времени и стоимости тестирования • Сокращение итераций между процессами регистраций и починки багов
- 11. Причины внедрения 1. Ручное тестирование требует длительного времени. 2. Сокращение подверженных ошибкам задач тестирования 3. Освобождение времени для выполнения лучшей работы 4. Страховочная сетка 5. Быстрое получение отклика 6. Тесты являются самой актуальной документацией 7. Возврат инвестиций
- 12. 1. Ручное тестирование требует длительного времени Пример с платными услугами - По мере роста приложения время на тестирования возрастает иногда экспоненциально - Необходимость вводить данные в UI - Подготовка данных для множества различных сценариев
- 13. Пример Действие Ручное Автоматизированное Ввод данных ~10*5 секунд = 50 секунд ~10*0,1 = 1 секунда Нажатие кнопки “Подать” 1 секунда 0,5 секунд Промодерировать объявление в админке секунд 30 5 секунд Поиск параметров с данными на странице объявления ~10*5 секунд = 50 ~10*0.5= 5 секунд Сравнение данных 10*2 секунды = 20 секунд ~10*0.5=5 секунд Итого ~ 150 секунд ~16,5 секунд
- 14. 2. Ручной процесс подвержен ошибкам
- 15. 2. Ручной процесс подвержен ошибкам - Написанные сценарии очень быстро надоедают - Пропуск простейших дефектов - Соблазн срезать углы при жестких временных рамках В результате серьезные проблемы остаются незамеченным
- 16. 3. Автоматизация освобождает людей для выполнения лучшей работы • Возможность больше уделять времени для исследовательского тестирования • Больше энергии для творческой работы • Обдумывание разных сложных сценариев В результате не тратим уйму времени на утомительные ручные сценарии
- 17. 4. Автоматизированные тесты предоставляют “Страховочную сетку” Замечательное чувство уверенности - Мгновенная обратная связь - Если нет тестов то страховочной сеткой служат тестировщики Пример: рефакторинг какого либо важного функционала
- 18. 4. Автоматизированные тесты предоставляют “Страховочную сетку”
- 19. 5. Автоматизированные тесты обеспечивают ранний и частый отклик • Быстрое выявление ошибок • Дешевые исправления дефектов
- 20. 6. Тесты означают замечательную документ - Живая спецификация - Всегда актуальная, так как тесты поддерживаются и запускаются при каждом пуше
- 21. 7. Возврат инвестиций и окупаемость • Освобождает дополнительное время - Возможность исправления допущенных ошибок до фиксации в системе управления версиями - Помогает разрабатывать надежный код
- 22. 7. Возврат инвестиций и окупаемость
- 23. Препятствия? - Это работа тестировщиков - Боль перемен - Начальные инвестиции - Постоянно меняющийся код - Страх - Старые привычки
- 24. Автоматизация - не серебряная пуля! - Все же есть тесты, которые требуют человеческих глаз, ушей и разума. - Не стоить писать автотесты на одноразовые сценарии - Теперь команде надо постоянно поддерживать десятки или даже сотни тестовых сценариев
- 26. Codeception - Фреймворк для тестирования PHP приложений - Комплексное тестирование - Модульное тестирование - Создан на основе фреймворка PHPUnit.
- 27. Уровни автоматизации • Unit тесты • Functional тесты • Acceptance (приемочные) тесты Все в едином стиле
- 28. Приемочные тесты - Требует реального запуска браузера (Chrome, Firefox) - Можно проверить элементы на видимость на странице - Можно проверить выполнения JavaScript - Медленные - Требует запуска Selenium WebDriver
- 30. Функциональные тесты - Не требуют реального запуска браузера (Chrome, Firefox) - Нельзя проверить элементы на видимость на странице - Нельзя проверить выполнение JavaScript - Быстрые - Не требуют запуска Selenium WebDriver - Использует PHP Browser - Может отправлять Get, Post, Ajax запросы
- 31. Статистика ~ 1000 тестов на 3 проектах Время прохождения тестов: Колёса ~ 8 минуты Крыша ~ 7 минуты Маркет ~ 4 минуты
- 32. Проблемы роста - Сложность поддержки тестов при росте их количества - Нестабильность (Selenium, инфраструктура) - Рост времени прохождения тестов
- 33. Оптимизация - Переписываем приемочные тесты в функциональные (если можно) - Включаем SingleMode/LongMode - Пересматриваем тест сценарии - Служебные методы для генерации тестовых данных
- 34. Цели - Увеличивать количество тестов - Поддерживать стабильность тестов - Контролировать время прохождения тестов - Постоянный рефакторинг тестов
- 36. 1 блок аксептанс теста
- 37. 2 блок аксептанс теста
- 38. 3 блок аксептанс теста
- 40. 1 блок функционального теста
- 41. 2 блок функционального теста
- 42. 3 блок функционального теста
Notes de l'éditeur
- Всем привет! Меня зовут Абылхаир, я работаю в компании чуть более 2 лет, занимался ручным тестированием, сейчас больше времени занимаюсь автоматизацией тестирования. Сегодня вы с Вами поговорим о процессе тестирования в нашей компании, точнее рассмотрим некоторые уровни тестирования. Для начало думаю будет правильно вспомнить что такое тестирование и для чего оно нужно?
- Теперь давайте рассмотрим уровни тестирования в нашей компании. Уровни тестирования: Запуск кода программистом (Smoke test) Статический анализ кода (код ревью) Автоматизированное регрессионное тестирование Ручное тестирование (new feature, improvement, bug) Анализ дизайна (авторский надзор) Мы с Вами рассмотрим подробно 2 пункта Статический анализ кода и Автоматизированное тестирование.
- Что такое статический анализ кода и что это дает ? Код ревью это инженерная практика когда программист предоставляет свой код другим программистам для чтения и комментирования перед тем как вылить этот код в продакшен. То есть это анализ кода с целью выявить ошибки, недочеты, расхождения в стиле написания кода,
- Кроме этого благодаря процессу код ревью можно на ранних стадиях разработки ПО найти и исправить важные баги, которые сложно воспроизвести при динамичном тестировании. А как мы знаем чем баг находится ранее тем он обходится дешевле. То есть исправление ошибок на уровне код ревью абсолютно ничего не стоит. (надо найти график стоимости ошибок взять с презентации культура есть еще фотки в загрузках), привести пример тойоту, в 2009 году из бага в ПО (не механического )компании пришлось отозвать 9 миллионов тачек по всему миру, что повлекло за собой убытки в размере 3 млрд долларов и самое печальное что 4 человека которые сидели в салоне погибли.
- В итоге хочется сказать что код ревью не только полезный но и необходимый этап разработки. Ежедневное ревью кода - это хорошая практика обмена опытом и обнаружения ошибок, особенно, если дело касается новых технологий и проектов со сложной бизнес логикой. Просматривая ревью коллег, можно как обнаружить новые способы решения той или иной задачи, так и поделиться опытом, как сделать лучше и правильнее. Как результат, команда прогрессирует быстрее, технический уровень разработчиков выравнивается, улучшается понимание целей, качество проекта возрастает, всевозможные конфликты в команде, на почве "кривого кода", решаются на самых ранних стадиях. А для заказчика это приносит денежные результаты, качественный код легче, быстрее и дешевле сопровождать. Единственный недостаток ревью является Если вы и ваши коллеги не уделяете время тому, чтобы CR был сделан, причем сделан быстро, тогда CR может стать причиной недовольства людей в коллективе
- А теперь давайте поговорим об автоматизации тестирования в нашей компаний. Возможно есть люди которые знают про автоматизацию, о ее преимуществах, возможно и нет, поэтому думаю будет правильно если мы для начала поймем что это, для чего нужно и какие есть причины внедрения автоматизации в проект. Серьезные команды сосредоточены на том, чтобы постоянно иметь работающее программное обеспечение, что позволяет им выдавать выпуск с нужной частотой. Достижение этой цели требует постоянного полного тестирования, в свою очередь полное тестирование ПО становится практически нереальным без автоматизации. Грубо говоря автоматизация тестирования - это комплекс мер и действий направленные на автоматизацию сценариев использования того или иного продукта. И есть несколько причин для внедрения автоматизации в проект. Автоматизация тестов - основная практика гибкой методологий(канбан, скрум). Гибкие проекты зависят от автоматизации. Достаточно хорошая автоматизация позволяет команде часто выдавать высококачественный код. Современную разработку программного обеспечения тяжело представить без автоматического тестирования — по сути это единственный способ защитить продукт от разрушительных изменений. Автоматизация - ключ к успешной гибкой разработке. Какие есть причины внедрения автоматизации.
- Самая главная причина по которой команды стремятся к автоматизации, состоит в том, что ручное тестирование просто отнимает очень много времени. Хочу рассмотреть 1 пример. Давайте представим что нам надо проверить на регрессию форму подачи объявления. К примеру возьмем категорию “Продажа квартир”. Чтобы подать объяву в эту категорию нам надо к примеру заполнить 10 обязательных полей. Потом промодерировать объяву и проверить те ли данные отображаются на странице объявления которые мы указывали ? Рассмотрим первый случай ручного тестирования: Ввод данных, ~10*5 секунд = 50 секунд Нажатие кнопки “Подать” = 1 секунда Промодерировать объявление в админке ~ секунд 30, если это уже опытный тестировщик Поиск параметров с данными на странице объявления ~10*5 секунд = 50 секунд. Сравнение данных, 10*2 секунды = 20 секунд. Итого: ~ 150 секунд. Рассмотрим автоматизированный вариант: Ввод данных, ~10*0,1 = 1 секунда Нажатие на кнопку “ПОдать” 0,5 секунд Промодерировать объявления в админке 5 секунд Поиск параметров на странице объявления ~10*0.5= 5 секунд Сравнение данных ~10*0.5=5 секунд Итого: 16,5 секунд По мере роста приложения время на полное его тестирования также возрастает, иногда экспоненциально. Главная цель гибких команд это иметь каждый день рабочий продукт. Выполнение регрессивных тестов вручную отнимает все больше и больше времени. Чтобы тестирование не отставало от кодирования, либо программистам придется помогать в проведении ручных тестов, либо команде придется нанимать дополнительных ручных тестировщиков. Ручное тестирование множество разнообразных сценариев может занять уйму времени особенно, если приходится вручную вводить данные в пользовательском интерфейсе. ПОдготовка данных для множества различных сценариев может стать неподъемной задачей. В результате может быть протестировано лишь ограниченное количество сценариев, и важные дефекты останутся незамеченными. К примеру порефакторили код на стороне апи касательно платных услуг. Вот теперь представьте процесс ручного тестирования 8 платных услуг 3 проектов на 12 платформах.
- Повторяющиеся ручное тестирование, особенно по написанным сценариям, очень быстро надоедает. Это прямой путь к ошибкам и пропуску даже простейших дефектов. Люди, выполняющие ручное тестирование пропускают шаги, а то и целые тесты. Если перед командой стоят жесткие сроки, возникает соблазн “Срезать углы”, в результате чего серьезные проблемы остаются незамеченными.
- Запуск всех модульных и регрессивных тестов в рамках непрерывной сборки означает, что больше времени можно уделить исследовательскому тестированию. Поскольку вы не тратите время на выполнение утомительных ручных сценариев, ваша энергия сохраняется для более сложной и творческой работы, обдумывание разных сценариев и изучения работы приложения.
- Знание о том что код имеет хорошее покрытие автоматизированными регрессивными тестами, дает замечательное чувство уверенности. Конечно, любые изменения могут дать неожиданный эффект, но мы узнаем об этом в течении каких-то минут. Не имея “Страховочной сетки” в виде автоматизированного комплекса тестов, программисты могут начать воспринимать в качестве такой сетки самих тестировщиков.
- Быстрое выявление ошибок означает что их дешевле исправлять, ежели в продакшне.
- Когда автоматизированы тесты, иллюстрирующие примеры желаемого поведения, она становится “Живой” документацией, описывающей работу систему. Так же они всегда являются актуальной, так как запускается при каждом пуше.
- Автоматизация высвобождает дополнительное время для тестировщиков и членов команды, чтобы сконцентрироваться на своевременном выводе на рынок правильного продукта. Важный компонент окупаемости тестирования заключается в способе исправления дефектов. Команды, полагающиеся на ручные тесты, часто находят ошибки по истечению значительного времени после написания кода, содержащего эти ошибки. Они работают в режиме исправления “Ошибки дня” вместо того, чтобы выявлять первоначальную причину ошибки с соответствующим изменением кода. Когда программисты запускают комплекты автоматизированных тестов в своих песочницах, то эти регрессивные тесты позволяют выявлять ошибки еще до фиксации кода в системе управления версиями. Это обеспечивает замечательную окупаемость, сокращает технический долг и позволяет разрабатывать надежный код.
- Также кроме причин внедрения, есть и препятствия. Причины: Позиция программистов - это работа тестировщиков. Боль перемен Начальные инвестиции Постоянные меняющийся код Страх Старые привычки Но у нас в команде с препятствиями нет проблем, может и были, но я не застал этот период. Некоторые виды тестов требуют человеческих глаз, ушей разума. В эту категорию попадают тестирование удобства и исследовательское тестирование. Другие тесты, которые могут не стоить вложений в автоматизацию - это одноразовые тесты и тесты которые никогда не дают сбоев. В таких случаях автоматизация может помочь только в подготовке сценариев для последующей оценки удобства.
- В общем автоматизация не серебряная пуля, которая разом решает все задачи тестирования, теперь команде приходится поддерживать десятки или даже сотни тестовых сценариев. В общем, автоматизированное тестирование не имеет смысла для маленьких, и краткосрочных проектов, поскольку первоначальные расходы слишком высоки. Кроме того, если вы тестируете вещи, которые требуют человеческого понимания (human touch), такие как юзабилити (usability), то тестировщик-человек будет гораздо лучше.
- Какое соотношение видов автоматизированных тестов должно быть ? Здесь привести пример с картинкой пирамиды. Процентный разброс может различаться. Вся суть в том, что у вас должно быть намного больше низкоуровневых юнит-тестов, чем высокоуровневых тестов через GU
- В нашей компании было принято решение использовать фреймворк Codeception. Обычно, новые возможности веб приложений тестируются путем открытия соответствующей страницы в браузере, на которой возможно нужно заполнить некоторые поля и отправить форму, после чего разработчики, тестеры могут увидеть, каким получится результат. Codeception это многофункциональный фреймворк для тестирования PHP-приложений. Он может выполнять комплексное тестирование, а также тестирование отдельных элементов веб-приложений. Codeception позволяет тестировать различные варианты поведения посетителя сайта. Таким образом, можно сэмулировать поведение реального посетителя, который взаимодействует с элементами интерфейса чтобы убедиться в правильной работе приложения в различных случаях.
- Существует 3 уровня автоматизации тестирования: Уровень модульного тестирования Уровень функционального тестирования Уровень тестирования через пользовательский интерфейс (GUI) (Приемочное тестирование) Уровень модульного тестирования (Unit Test layer) Под автоматизированными тестами на этом уровне понимаются Компонентные или Модульные тесты написанные разработчиками. Тестировщикам никто не запрещает писать такие тесты, которые будут проверять код, конечно же, если их квалификация позволяет это. Наличие подобных тестов на ранних стадиях проекта, а также постоянное их пополнение новыми тестами, проверяющими «баг фиксы», убережет проект от многих серьезных проблем. Уровень функционального тестирование (Functional Test Layer non-ui) Как правило не всю бизнес логику приложения можно протестировать через GUI слой. Это может быть особенностью реализации, которая прячет бизнес логику от пользователей. Именно по этой причине по договоренности с разработчиками, для команды тестирования может быть реализован доступ напрямую к функциональному слою, дающий возможность тестировать непосредственно бизнес логику приложения, минуя пользовательский интерфейс. Уровень тестирования через пользовательский интерфейс (GUI Test Layer) На данном уровне есть возможность тестировать не только интерфейс пользователя, но также и функциональность, выполняя операции вызывающую бизнес логику приложения. С нашей точки зрения, такого рода сквозные тесты дают больший эффект нежели просто тестирование функционального слоя, так как мы тестируем функциональность, эмулируя действия конечного пользователя, через графический интерфейс.
- Самым популярным является “Модульное тестирование”(Юнит тестинг). В случае веб приложений, тестирование моделей и контроллеров в изоляции друг от друга не гарантирует работоспособность всего приложения. Для полной проверки приложения Вы должны написать функциональные и приемочные тесты. В Codeception мы получаем возможность писать модульные, функциональные и приемочные тесты в едином стиле. Но в реалиях кодесепшн понятие функциональное и приемочное немного видоизменяется. Давайте рассмотрим уровни тестирования в рамках кодсепшн: Приемочные тесты : Требует реального запуска браузера (Chrome, Firefox) Можно проверить элементы на видимость на странице Можно проверить выполнения JavaScript-a Медленные Требует запуска Selenium WebDriver-a
- Как работатет? Грубая схема примерно такая : Codeception -> SeleniumServer-> WebDriver-> Chrome.
- Функциональные тесты: Не требует запуска реального браузера Нельзя проверить элементы на видимость на странице Нельзя проверить выполнение JavaScript Быстрые Не требуют запуска Selenium WebDriver Использует PhpBrowser Может отправлять Get Post Ajax запросы
- Хотел привести немного статистики: 1000 тестов на 3 проектах Время прохождения тестов: Колеса ~ 8 минут Крыша ~ 7 минут Маркет ~ 4 минуты
- Какие есть прКакие есть проблемы ? Проблемы роста Сложность поддержки при росте их количества Нестабильность Рост времени прохождения тестовоблемы?
- Оптимизация: Переписываем приемочные тесты в функциональные (если можно) Включаем LongModeTests Пересматриваем тест сценарии Запуск тестов потоками
- Цели: Увеличивать количество тестов Поддерживать стабильность тестов Контролировать время прохождения тестов Постоянный рефакторинг тестов Предлагаю рассмотреть 2 примера реализации одной и той же сценарии в разных реализациях: Аксептанс и функционал. Если че потом рассказать в конце краткое резюме, что автоматизировать, как автоматизировать, что тесты это 3 д (дорого долго добро)!