Выступление Андрея Сильчука об автоматическом тестировании ПО на Hub QA meetup #1.
Больше мероприятий:
https://vk.com/hub.itschool
https://facebook.com/Hub.IT.School
Quality Assurance vs Quality Control - так в чем же заключается работа специа...COMAQA.BY
Поговорим о том, что такое Quality Assurance и что такое Quality Control. Узнаем в чем заключается принципиальная разница между этими двумя понятиями\подходами. Расскажем как можно и нужно строить карьеру тестировщика. Приведем пример мировой практики от Microsoft.
Непрерывная интеграция и автотесты. Сравнительный анализ инструментовCOMAQA.BY
По-настоящему автоматизированными тесты можно назвать только тогда, когда из процесса тестирования полностью исключается человек. В идеале участие человека должно сводиться к просмотру отчетов о результатах автотестирования, которые регулярно приходят ему на почту.
Достичь этого можно только одним способом - с помощью инструментов непрерывной интеграции. Какой же инструмент лучше выбрать? Почему? Так ли этот выбор важен или можно просто взять любой из них и начать использовать?
Сравним самые популярные Java-совместимые инструменты CI и сделаем выводы!
Quality Assurance vs Quality Control - так в чем же заключается работа специа...COMAQA.BY
Поговорим о том, что такое Quality Assurance и что такое Quality Control. Узнаем в чем заключается принципиальная разница между этими двумя понятиями\подходами. Расскажем как можно и нужно строить карьеру тестировщика. Приведем пример мировой практики от Microsoft.
Непрерывная интеграция и автотесты. Сравнительный анализ инструментовCOMAQA.BY
По-настоящему автоматизированными тесты можно назвать только тогда, когда из процесса тестирования полностью исключается человек. В идеале участие человека должно сводиться к просмотру отчетов о результатах автотестирования, которые регулярно приходят ему на почту.
Достичь этого можно только одним способом - с помощью инструментов непрерывной интеграции. Какой же инструмент лучше выбрать? Почему? Так ли этот выбор важен или можно просто взять любой из них и начать использовать?
Сравним самые популярные Java-совместимые инструменты CI и сделаем выводы!
Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...COMAQA.BY
Автоматизация тестирования визуальных регрессий, как особый вид тестирования, может поставить в тупик даже опытных специалистов своей отрасли. Тем более, если речь идёт об адаптивном дизайне.
Задача тестирования адаптивной верстки не является простой, хотя бы по той причине, что требует большого времени на проверку отображения визуального контента и покрытие всей требуемой матрицы платформ, браузеров и разрешений экрана.
Тем не менее существуют способы эффективного использования таких инструментов как Galen Framework и Applitools Eyes и интеграции их в уже существующую среду тестирования.
На наглядном примере сайта, имеющего адаптивный дизайн, я расскажу о том, как можно с лёгкостью применять вышеуказанные инструменты с целью избежать как можно больше разнообразных регрессионных визуальных ошибок.
Также будут подробно рассмотрены варианты построения архитектуры тестов и организации работы с дизайном приложения в целом.
Способы организаций больших Java проектов по Автоматизированному тестированиюCOMAQA.BY
В процессе работы автоматизатора часто приходится сталкиваться с написанием новых фреймворков или модификации прежде написанных. И тут возникает ощущение, что "когда-то я уже это писал". В ходе доклада я расскажу как же решить известную задачу "не повторяться" в рамках большого проекта или кросс-проектно или почему работа автоматизатора часто требует навыков системного администрирования, программирования, "девопса".
В этом докладе вы услышите историю о том, как можно построить процесс автоматизированного тестирования и непрерывной интеграции за короткий период времени. Мы поговорим о точках роста, развития и внедрения автоматизированного тестирования на уже существующем проекте. Вы узнаете, что с чего начинать автоматизированное тестирование и как выбрать "работающую" стратегию. После доклада вы захотите избавиться или значительно сократить ручное тестирование и ручной труд у себя на проекте. Вы откроете для себя целую систему, элементы который можно будет внедрять у себя, и которые будут работать.
Доклад будет интересен всем тестировщикам, разработчикам и менеджерам проектов.
Практический доклад о том, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование.
В докладе рассмотрены основные проблемы, с которыми команда столкнулась при внедрении и способы их устранения.
Продемонстрированы результаты, которых смогли достичь в течении полугода.
Доклад содержит большое количество лайфхаков и обзоров инструментария, который использовался для достижения цели.
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
QA Fest 2016. Андрей Мясников. Тест-дизайн для чайниковQAFest
В своём докладе я расскажу вам о том, кто такие тест-аналитики, тест-дизайнеры и должны ли их роль выполнять обычные тестировщики. Также сделаю обзор основных и проверенных методик тест-дизайна. Расскажу про их плюсы и минусы.
Будем учиться тестировать не 12 часов, а головой!
“Можно ли перевернуть пирамиду?” – автоматизируем тестирование с меньшим числ...Igor Khrol
Когда мы говорим об автоматизации тестирования, чаще всего вспоминается Selenium, Microsoft Coded UI, QTP и другие аналогичные инструменты. Мы хотим воспроизводить действия ручного тестирования с максимальной точностью, чтобы можно было с уверенностью сказать, что тот или иной тест-скрипт повторяет какую-то часть сложившихся на проекте тестов. Когда же тестов становится чуть больше, то мы обнаруживаем, что наши тесты запускаются долго, работают нестабильно. После чего мы начинаем говорить о параллелизации, виртуализации, четырёхслойной архитектуре фреймворка и прочих жутко интересных вещах… Это всё очень хорошо, но главная цель где-то остаётся в стороне – контроль качества нашего продукта.
В своём докладе я попытаюсь слегка задать направление другой альтернативе: отойти от автотестов через пользовательский интерфейс в сторону более низкоуровневых, которые значительно быстрее и стабильнее. Если вас также волнует “переворачивание” пирамиды автоматизации тестирования, то приглашаю присоединиться к обсуждению этой сложной и важной темы.
Автоматизация визуального тестирования адаптивного дизайна на примере Galen F...COMAQA.BY
Автоматизация тестирования визуальных регрессий, как особый вид тестирования, может поставить в тупик даже опытных специалистов своей отрасли. Тем более, если речь идёт об адаптивном дизайне.
Задача тестирования адаптивной верстки не является простой, хотя бы по той причине, что требует большого времени на проверку отображения визуального контента и покрытие всей требуемой матрицы платформ, браузеров и разрешений экрана.
Тем не менее существуют способы эффективного использования таких инструментов как Galen Framework и Applitools Eyes и интеграции их в уже существующую среду тестирования.
На наглядном примере сайта, имеющего адаптивный дизайн, я расскажу о том, как можно с лёгкостью применять вышеуказанные инструменты с целью избежать как можно больше разнообразных регрессионных визуальных ошибок.
Также будут подробно рассмотрены варианты построения архитектуры тестов и организации работы с дизайном приложения в целом.
Способы организаций больших Java проектов по Автоматизированному тестированиюCOMAQA.BY
В процессе работы автоматизатора часто приходится сталкиваться с написанием новых фреймворков или модификации прежде написанных. И тут возникает ощущение, что "когда-то я уже это писал". В ходе доклада я расскажу как же решить известную задачу "не повторяться" в рамках большого проекта или кросс-проектно или почему работа автоматизатора часто требует навыков системного администрирования, программирования, "девопса".
В этом докладе вы услышите историю о том, как можно построить процесс автоматизированного тестирования и непрерывной интеграции за короткий период времени. Мы поговорим о точках роста, развития и внедрения автоматизированного тестирования на уже существующем проекте. Вы узнаете, что с чего начинать автоматизированное тестирование и как выбрать "работающую" стратегию. После доклада вы захотите избавиться или значительно сократить ручное тестирование и ручной труд у себя на проекте. Вы откроете для себя целую систему, элементы который можно будет внедрять у себя, и которые будут работать.
Доклад будет интересен всем тестировщикам, разработчикам и менеджерам проектов.
Практический доклад о том, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование.
В докладе рассмотрены основные проблемы, с которыми команда столкнулась при внедрении и способы их устранения.
Продемонстрированы результаты, которых смогли достичь в течении полугода.
Доклад содержит большое количество лайфхаков и обзоров инструментария, который использовался для достижения цели.
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
QA Fest 2016. Андрей Мясников. Тест-дизайн для чайниковQAFest
В своём докладе я расскажу вам о том, кто такие тест-аналитики, тест-дизайнеры и должны ли их роль выполнять обычные тестировщики. Также сделаю обзор основных и проверенных методик тест-дизайна. Расскажу про их плюсы и минусы.
Будем учиться тестировать не 12 часов, а головой!
“Можно ли перевернуть пирамиду?” – автоматизируем тестирование с меньшим числ...Igor Khrol
Когда мы говорим об автоматизации тестирования, чаще всего вспоминается Selenium, Microsoft Coded UI, QTP и другие аналогичные инструменты. Мы хотим воспроизводить действия ручного тестирования с максимальной точностью, чтобы можно было с уверенностью сказать, что тот или иной тест-скрипт повторяет какую-то часть сложившихся на проекте тестов. Когда же тестов становится чуть больше, то мы обнаруживаем, что наши тесты запускаются долго, работают нестабильно. После чего мы начинаем говорить о параллелизации, виртуализации, четырёхслойной архитектуре фреймворка и прочих жутко интересных вещах… Это всё очень хорошо, но главная цель где-то остаётся в стороне – контроль качества нашего продукта.
В своём докладе я попытаюсь слегка задать направление другой альтернативе: отойти от автотестов через пользовательский интерфейс в сторону более низкоуровневых, которые значительно быстрее и стабильнее. Если вас также волнует “переворачивание” пирамиды автоматизации тестирования, то приглашаю присоединиться к обсуждению этой сложной и важной темы.
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
зуева татьяна - опыт автоматизации тестирования в Agile проектеMagneta AI
В докладе рассказывается об опыте автоматизации тестирования приложений, написанных с использованием технологии WPF в нашем проекте:
— об истории развития автоматизации тестирования GUI в нашем проекте
— о нашем подходе к автоматизации тестирования и о системе, построенной на основе открытой .NET библиотеки White
— о полезных процессных
практиках, к которым мы пришли, и о положительной роли автоматизации в нашем процессе гибкой разработки.
Как построить свой фреймворк для автотестов?Dmitry Buzdin
Мы пройдемся по всем основным блокам построения тестового фреймворка и тому, как они связаны между собой. Вы научитесь собирать свое решение по автоматизации из библиотек с открытым кодом и делать так, чтобы они дополняли друг друга.
Hub IT School: Лекция "IT профессии" / 14.1.16
На этой лекции Людмила Денисенко из рекрутингового агентства GUID рассказала о существующих IT профессиях, их положении на рынке труда и требованиях, которые предъявляют к новичкам.
Hub AI&BigData meetup / Дмитрий Сподарец: Введение в машинное обучениеHub-IT-School
Hub IT School 26/12/15
Подпишитесь на нас в соц. сетях, чтобы не пропустить новые мероприятия!
https://www.facebook.com/Hub.IT.School/
https://vk.com/hub.itschool
Hub AI&BigData meetup / Вадим Кузьменко: Как машинное обучение помогает снизи...Hub-IT-School
Hub IT School 26/12/15
Подпишитесь на нас в соц. сетях, чтобы не пропустить новые мероприятия!
https://www.facebook.com/Hub.IT.School/
https://vk.com/hub.itschool
Видео:
https://www.youtube.com/watch?v=oVcnP_gPtyU
Hub IT School 15.12 / Олег Саламаха: "Как пройти долину смерти"Hub-IT-School
Hub Startup meetup #2 / 15.12
Олег Саламаха (CEO Prodvigator/Serpstat): Как пройти долину смерти и не прострелить себе ногу.
Мы в соц. сетях:
https://vk.com/hub.itschool
https://www.facebook.com/Hub.IT.School
Эд Изотов: "In God we trust the REST we test".Hub-IT-School
Выступление Эда Изотова про тестирование REST-систем на Hub QA meetup #1.
Больше мероприятий:
https://vk.com/hub.itschool
https://facebook.com/Hub.IT.School
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 день из-за нехватки инженеров, в то время как в автоматизации этот предел не столь явен. Правда в случае АТ в начале количество тестов будет меньше чем в МТ, т.к. Понадобиться время на написание этих тестов, фреймворка и тд.....