Agenda
Автоматизация? Какая еще автоматизация? Автоматическое тестирование ПО. Зачем вообще?
Отличие от мануального тестирования ПО, или Ручник vs человек разумный.
Имею желание, но не имею возможности, или какие знания были бы полезны в этой области.
Когда стоит внедрять автоматизацию.
ROI и другие непонятные слова на три буквы.
3. Кто этот парень перед нами?
Имя: Андрей Сильчук
Возраст: 27 лет
Место работы: DataArt
Должность: Project Manager
Увлечения: фигурное катание, Star Wars,
snowboarding
4. Agenda
• Автоматизация? Какая еще автоматизация?
• Автоматическое тестирование ПО. Зачем вообще?
• Отличие от мануального тестирования ПО, или Ручник vs человек
разумный.
• Имею желание, но не имею возможности, или какие знания были бы
полезны в этой области.
• Когда стоит внедрять автоматизацию. ROI и другие непонятные
слова на три буквы.
5. Что такое автоматическое
тестирование (АТ)?
• Автоматизированное (автоматическое) тестирование является
составной частью процесса тестирования. Оно использует программные
средства для выполнения тестов и проверки результатов пробега этих
тестов, что помогает сократить время тестирования и упростить его
процесс.
• Automation QA - это QA engineer обеспечивающий создание, отладку и
поддержку работоспособного состояния тест скриптов, тестовых
наборов и инструментов для автоматизированного тестирования.
6. Подходы к АТ
• Тестировние на GUI уровне. Эмуляция дествий пользователя, часто
record-replay мехнизм. Автоматизация black-box тестирования (иногда
с элементами серого ящика)
• Тестирование на уровне кода, автоматизация Unit-тестирвоания
(модульное тестирование)
End-user testing/UI testing
Code-level testing
7. End-User testing VS Unit testing
• Реальная система
• Record & Replay
• End to end
• Выполняются QA
End User Tests
• А что если UI не готов?
• Высокий Maintenance - UI меняется
• Покрытие
• Flexibility – Не видна обратная связь
с компонентами
• Code level тесты.
• Написаны на AUT языке
• Маленький maintenance
• Выполняются Dev
Unit Tests
• Стерильная система (mock)
• Не находит интеграционных проблем
• Узкие тесты – используют один метод
• Обычно пишутся Dev, который и
написал сам компонент
8. Основные инструменты АТ
• Selenium
• QTP
• JUnit
• Microsoft UI Automation
• Coded UI
• Load Runner
• etc .
9. Что может быть покрыто АТ?
• Functional:
• Unit tests
• Integration testing
• End-User testing
• UI:
• Позиция элементов, внешний вид, наполнение, типы ввода и
фильтрация ввода
• Performance and stability
10. Manual vs Automation
Ручное Автоматизированное
Задание входных
значений
Гибкость в задании данных. Позволяет использовать разные
значения на разных циклах прогона тестов, расширяя покрытие
Входные значения строго заданы
Проверка результата Гибкая, позволяет тестировщику оценивать нечетко
сформулиррованные критерии
Строгая. Нечетко
сформулированные критерии
могут быть проверены только
путём сравнения с эталоном
Повторяемость Низкая. Человеческий фактор и нечеткое определение данных
приводят к неповторяемости тестирования
Высокая
Надежность Низкая. Длительные тестовые циклы приводят к снижению
внимания у тестировщика
Высокая, не зависит от длины
тестового цикла
Чувствительность к
незначительным
изменениям в
продукте
Зависит от детальности описания процедурыю Обычно
тестировщик в состоянии выполнить тест, если внешний вид
продукта и текст сообщений несколько изменились
Высокая. Незначительные
изменения в интерфейсе часто
ведут к коррекции эталонов
Скорость выполнения
тестового набора
Низкая Высокая
11. + Manual vs Automation
• Возможность неформального тестирования
• Возможность гибкой оценки результатов
• Возможность использования исследовательской техники
тестирования
• Возможность полностью имитировать работу пользователя,
использовать пользовательские сценарии
• Не очень чувствителен к изменению продукта
12. - Manual vs Automation
• Занимает много времени и ресурсов
• Не всегда надежно
• В ряде случаев практически невозможно
13. + Automation vs Manual
• Занимают меньше время на выполнение
• Имеют высокую надежность
• Позволяют выполнить тестирование, практически невыполнимое
человеком(например нагрузочное тестирование)
14. - Automation vs Manual
• Чувствителен к малейшим изменениям в продукте
• Редко позволяет сделать гибкое тестирование и гибкую оценку
результатов
• Нет возможности тестировать неформально и используя
исследовательскую технику тестирования
• Часто требует много времени на создание и поддержку тестов
15. Когда стоит приступать к АТ?
• Часть функционала на которую запланирована автоматизация готова
и протестирована мануально
• Большое кол-во предварительных данных для тестирования (DB, XML,
etc.), большое количество деталей для проверки
• UI стабилен
• Необходима длительная нагрузка на систему (Performance)
• Большое количество регрессии
16. Стадии процесса АТ
Принятие
решения о
внедрении
автоматическо
го
тестирования
Выбор
инструменталь
ных средств
Внедрение
автоматическ
ого
тестирования
Планирование,
проетирование
и разработка
Выполнение
тестов,
упарвление
процессом
тестирования
Оценка и
усовершенство
вание
процесса
17. ROI
ROI = (Gain - Investments)/Gain *100%
Gain - расчётная стоимость тестирования без автоматизации
Investments - расходы на создание и выполнение автоматической
библиотеки тестов за тот же период, что был использован для вычисления
расчётной стоимости тестирования без автоматизации
18. ROI
Первая версия:
(Время на выполнение тестирования вручную) -
(Время на изучение + время на реорганизацию процесса + время на создание
тестов + время на поддержу + время на исследование дефекта и анализ
результатов) = Экономия времени при использовании автоматического
тестирования
19. ROI
Все последующие версии:
Время на выполнение тестирования вручную – (время на поддержу тестов
+ время на создание тестов + время на исследование дефекта и анализ
результатов) = Экономия времение при использовании автоматического
тестирования
21. Что может пригодиться юному
автоматизатору?
• Знания основ мануального тестирования https://www.google.com.ua
• Скриптование. Начиная от простейших cmd и shell скриптов и
заканчивая более сложными вещами (например js)
• Знания WebServices , SOAPUI (Rest and SOAP) http://www.w3schools.com/
• XML and XPATH
• DHTML
• ООП https://www.udemy.com/java-tutorial/
• Регулярные выражения ( http://regexone.com/ )
Рассказать про себя.
Как зовут
Где работаешь
Кем работаешь
Зачем ты здесь
Хобби и увлечения
…..
Рассказать про себя.
Как зовут
Где работаешь
Кем работаешь
Зачем ты здесь
Хобби и увлечения
…..
Описание курса….
Первые попытки «автоматизации» появились в эпоху операционных систем DOS. Тогда она заключалась в выдаче приложению команд через командную строку и анализе результатов. Чуть позднее добавились удаленные вызовы через API для работы по сети. Впервые об автоматизированном тестировании упоминается в книге Фредерика Брукса «Мифический человеко-месяц», где говорится о перспективах использования модульного тестирования. Но по-настоящему автоматизация тестирования стала развиваться только в 1980-х годах.
Существует два основных подхода к автоматизации тестирования: тестирование на уровне кода и тестирование пользовательского интерфейса (в частности, GUI-тестирование). К первому типу относится, в частности, модульное тестирование. Ко второму — имитация действий пользователя с помощью специальных тестовых фреймворков.
Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны.
Этот тип тестирования обычно выполняется программистами.
Интеграцио́нное тести́рование (англ. Integration testing, иногда называется англ. Integration and Testing, аббревиатура англ. I&T) — одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования.
Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приёмным и требованиям надежности. Тестирование этих проектируемых единиц — объединения, множества или группы модулей — выполняется через их интерфейс, с использованием тестирования «чёрного ящика».
Существует два основных подхода к автоматизации тестирования: тестирование на уровне кода и тестирование пользовательского интерфейса (в частности, GUI-тестирование). К первому типу относится, в частности, модульное тестирование. Ко второму — имитация действий пользователя с помощью специальных тестовых фреймворков.
Selenium – целое семейство иснструментов для тестирования Web-приложений о котором мы поговорим позже подробней. Бесплатный
QTP - HP QuickTest Professional (QTP) — один из ведущих[1] инструментов автоматизации функционального тестирования, является флагманским продуктом компании HP в своей линейке. Для разработки автоматизированных тестов QTP использует язык VBScript, и поддерживает следующие технологии[2]: Windows® Presentation Foundation, Web services, Macromedia Flex, Ajax, Delphi, .NET, J2EEWeb, Visual Basic, ActiveX, Java, Oracle, SAP Solution, TE, PowerBuilder, Siebel, PeopleSoft, VisualAge, Stingray.
Платен. Имеет репозиторий объектов
JUnit — библиотека для модульного тестирования программного обеспечения на языке Java.
Созданный Кентом Беком и Эриком Гаммой, JUnit принадлежит семье фреймворков xUnit для разных языков программирования, берущей начало в SUnit Кента Бека для Smalltalk.
Microsoft UI Automation – API позволяет получить доступ к, идентифицировать и управлять элементами пользовательского интерфейса десктопных приложений
Coded UI Test – это решение для автоматизации UI-тестов, которое появилось в Microsoft Visual Studio 10. Позволяет автоматизировать как web-приложения, так и desktop-приложения.
Достоинства:
полная интеграция с TFS. Огромное количество возможностей при работе с .NET технологиями. Поддержка от Microsoft;
наличие встроенного инструмента записи / воспроизведения тестов. Правда, запись доступна только в IE;
отлично справляется с AJAX запросами в веб-приложениях;
позволяет искать веб-элементы по нескольким критериям поиска (нечеткое совпадение);
можно автоматизировать Silverlight 4;
подходит для тестирования Windows desktop-приложений.
Недостатки:
Coded UI Test – довольно дорогое удовольствие, так как запись тестов доступна только в Ultimate и Premium версиях Visual Studio. В Professional версии есть возможность только запуска тестов;
ограниченные возможности для тестирования веб-приложений. На данный момент поддерживается только IE 7, IE 8 и Firefox 3.6;
отсутствие регулярных обновлений. Изменения доступны только с выпуском очередных версий или дополнений Visual Studio;
при использовании инструмента записи / воспроизведения генерируется слишком много кода;
для тестирования веб-приложений есть проблемы при поиске требуемого окна;
для простейших команд требуется писать много кода;
низкая скорость работы (как минимум, при сравнении с Selenium).
HP LoadRunner — утилита для автоматизированного нагрузочного тестирования. Программа может выполнять как тестирование различных приложений, так и тестирование сайтов различного уровня сложности. Подключая виртуальных пользователей выполняющих различные скрипты (действия), по различным сценариям. Программа имеет соответствующие наборы инструментов для проведения тестирования. Так же в состав HP LoadRunner входит набор инструментов для работы по различным протоколам с приложением (удаленно, через прокси-сервер и т.п.)
Задачки по расчету:
Задачки по расчету:
Задачки по расчету:
У нас есть проект в котором планируется имплементация 7 фич. Известно что на каждую фичу если тестировать мануально надо потратить 30 часов. А на автоматизацию одной фичи необходимо потратить 60 часов.
Каких данных не хватает для расчета РОИ?
Не хватает время на реогрганизацию процесса (изучение автоматического тула + договориться об имплементации автоматизации....) + время на выполнение тестов (анализ результатов + репортинг) + время на поддежку тестов + время на исследование дефекта.
На реоганизацию надо 50. Выполнение тестов 40 на весь проект.... Время на поддержку – 50. На исследование деффекта – 30.
Решение – 7*30 – (7*60 + 50 + 40 + 50 + 30) = 210 – (420+ 170)= 210 – 590 – НЕ ВЫГОДНО
А теперь посчитаем что у нас тестирование должно проходить на 5 Операционках.... (не или 5 версий продукта будет...)
Решение – 7*30*5 – (7*60 + 50 + 40*5 (если тесты бегают паралельно то времени понадобится меньше) + 50 + 30*5) =
1050 – (420 + 50 + 200 + 50 + 150) = 1050 – 870 – ВЫГОДНО
Ручное тестирование и автоматизированное – два совершенно разных процесса, точнее, два способа выполнить один и тот же процесс. Их динамика отличается, и типы ошибок, которые они пытаются обнаружить, также отличаются. Соответственно, напрямую их сравнивать по стоимости или по количеству обнаруженных ошибок, бессмысленно.
Обсуждаем график, у кого какие мысли почему так нарисовано...
В случае мануального тестирования мы в какой-то момент упремся в потолок того что мы прогнать за 1 день из-за нехватки инженеров, в то время как в автоматизации этот предел не столь явен. Правда в случае АТ в начале количество тестов будет меньше чем в МТ, т.к. Понадобиться время на написание этих тестов, фреймворка и тд.....
