AQA Flashcards
(20 cards)
Автоматизация тестирования
это набор техник, подходов и инструментальных средств, позволяющих исключить участие человека из выполнения НЕКОТОРЫХ задач по тестированию.
Инструментальное средство автоматизированного тестирования
это программа (или набор программ), позволяющая создавать, редактировать, отслеживать и выполнять автоматизированные тесты, а также собирать статистику их выполнения.
Какие задачи решает автоматизация тестирования, зачем нужна автоматизация тестирования:
- Проверка ссылок.
- Проверка работоспособности стандартного, типичного для множества проектов функционала.
Примеры таких функций:
o Аутентификация пользователя;
o Регистрация пользователя;
o Добавление товара в корзину. - Проверка стандартных элементов управления.
- Базовая проверка безопасности.
- Тестирование производительности и нагрузочное тестирование.
- Смоук-тест для крупных систем.
- Регрессионное тестирование.
- Конфигурационное тестирование (проверка работоспособности приложения при разных настройках).
- Часто повторяющиеся тесты, простые для автоматизации.
- Длительные утомительные для человека тесты.
Цели автоматизации тестирования:
- Сократить стоимость и время тестирования;
- Снизить нагрузку на специалиста;
- Улучшить качество продукта;
- Улучшить тестовое покрытие;
- Сократить ручное вмешательство;
- Написание и запуск различных тестов;
- Обеспечить надежность выполнения тестирования;
- Оперативно предоставлять заказчику информацию о состоянии продукта.
Преимущества автоматизации
- Скорость (компьютер работает быстрее человека; мы экономим время и, как следствие, деньги);
- Надёжность (компьютер не допускает «человеческих ошибок»);
- Мощность (можно выполнить действия, недоступные человеку);
- Средства автоматизации тестирования собирают числовую информацию и представляют её в удобной для понимания человеком форме;
- Позволяет создавать и запускать большое количество тестовых сценариев и проверок, что позволяет обеспечить более полное покрытие функциональности и поведения программного обеспечения.
- Средства автоматизации тестирования в сложных ошибочных ситуациях способны выполнять «низкоуровневые действия», сложные для человека.
Недостатки автоматизации.
- Необходим квалифицированный персонал;
- Необходима грамотная стратегия разработки и управления тестами, тестовыми данными и т.п.;
- Необходимы специальные инструментальные средства (зачастую – ОЧЕНЬ дорогие);
- В случае серьёзных изменений в приложении многие автоматизированные тесты становятся бесполезными и/или требуют серьёзной переработки;
- На автоматизацию часто возлагают неоправданные надежды, что ведёт к срывам сроков и прочим проблемам;
- Все области применения продукта не могут быть автоматизированы. Там будут определенные ограничения в определенных областях.
Ко всем ли проектам применима автоматизация?
1)Ваше приложение имеет большое количество функций, требующих проверки на регрессе;
2)Масштаб проекта и долго идущие планы на его развитие, хотя бы больше года. В этом случае также пора задуматься об уменьшении ручного труда с переходом в автоматизацию.
3)Частые релизы. Если ваш проект увеличивается, релизы ускоряются, но штат сотрудников QA остается прежним, то стоит приступать к автоматизации, многие рутинные операции получится быстрее проверять.
4)Усложнение технологий, в котором проверить «вручную» сложно. Перелопачивать действительно большой объем данных, с которым мы можем столкнуться разве что в BigData, не имеет смысла. Например, сложно вручную проверить все связи между микросервисами или в IoT (Internet of Things).
Автоматизированное тестирование может быть нецелесообразным на:
- Небольшие проекты: Для очень малых приложений или проектов с ограниченным функционалом ручное тестирование может быть более эффективным и менее затратным.
- Часто меняющиеся требования: Если проект находится на ранних стадиях разработки или его требования часто меняются, поддержка автоматизированных тестов может оказаться затратной и времязатратной.
- Творческие проекты: В проектах, связанных с дизайном, искусством или другими креативными областями, ручное тестирование часто лучше, т.к. используется преимущественно юзабилити тестирование.
- Прототипы и MVP: Для прототипов или минимально жизнеспособных продуктов (MVP) чаще всего важнее быстрое получение обратной связи, а не полное тестирование.
- Уникальные сценарии: Если проект включает уникальные сценарии или нестандартные функции, автоматизация может быть сложной и трудоемкой.
- Малые команды: В небольших командах может не хватать ресурсов для разработки и поддержки автоматизированных тестов.
Тесты, которые должны быть автоматизированы.
- Бизнес-критические пути: фичи или пользовательские сценарии, при падении которых будет нанесен существенный урон бизнесу.
- Тесты, которые должны прогоняться на каждом билде/релизе приложения – например, smoke, sanity, регресс.
- Тесты, которые нужно прогонять на разных конфигурациях – разных операционных системах и браузерах.
- Тесты, которые используют один и тот же сценарий, но разные данные для каждого прогона (тесты, управляемые данными).
- Тесты, которые завязаны на большие объемы данных (например, заполнение очень больших форм).
- Тесты, которые могут быть использованы для тестирования производительности (стресс, нагрузочное тестирование).
- Тесты, которые занимают много времени на выполнение и могут быть запущены во время перерывов или ночью.
- Тесты, во время которых необходим захват изображения, чтобы доказать, что приложение ведет себя верно, или проверка того, что ряд веб-страниц одинаково выглядит в разных браузерах.
Тесты, которые не нужно автоматизировать.
- Тесты, которые прогоняются только один раз или незначительное количество раз.
- Тесты пользовательского опыта и удобства использования, требующие реакции пользователя на простоту использования приложения.
- Тесты, которые нужно запустить очень срочно. Обычно новая, только что разработанная фича требует быстрой обратной связи, и ее тестируют вручную.
- Тесты, которые требуют доменного знания и опыта – исследовательское тестирование.
- Прерывающиеся тесты. Тесты с предсказуемыми результатами не особенно ценны. Чтобы получить наилучший выхлоп от автоматизации, тесты должны давать предсказуемые и надежные результаты, чтобы проходить pass/fail условия.
- Тесты, требующие визуального подтверждения. Однако мы можем делать скриншоты страниц во время автотестов, а затем вручную проверять их.
- Тесты, где присутствуют конфигурации, различные настройки.
- Тесты, которые не могут быть на 100% автоматизированы, не должны быть автоматизированы вообще, если только их автоматизация не сэкономит значительное время.
End-to-end тестирование
это процесс тестирования приложения на всех уровнях - начиная с фронтенда и заканчивая бэкэндом, включая интерфейс и конечные точки. Это проверка (валидация) приложения полностью, от начала до конца, вместе со всеми зависимостями. Тестируется весь user flow (путь пользователя). Например, при разработке онлайн-магазина тестировщик «идет по пути пользователя» от входа посетителя на сайт и регистрации до завершения покупки.
Выполнение End-to-end тестирования гарантирует, что приложение проверено на основе пользовательских сценариев, которые помогают контролировать и избегать рисков, позволяя тестировщикам:
* Проверять и выполнять тестирование всего потока приложения;
* Увеличивать тестовое покрытие за счет привлечения различных подсистем;
* Обнаруживать проблемы в общей производительности приложения.
Тестовая пирамида
это визуальная метафора, описывающая различные уровни тестирования и объем тестирования на каждом слое. Пирамиду разбивают на 3 уровня (снизу вверх).
Классическая пирамида тестирования.
Нужна для группировки тестов по их важности, назначению, определения их количества и сложности.
* Unit - модульное тестирование (юнит);
* Integration - интеграционное тестирование (включает в себя системное);
* E2E - приемочное тестирование.
Уровень модульного тестирования
На этом уровне тестируют готовые к проверкам части кода, это классы, функции или методы классов.
Юнит тесты должны быть направлены на поиск ошибок в фундаменте системы.
Модульных тестов всегда должно быть больше, чтобы устранить ошибки на верхних уровнях, и потому что они выполняются быстрее всех и требуют меньше ресурсов. Разработкой занимается разработчик или автотестер.
Интеграционный уровень
Проверяет связь между модулями, или системами. Компоненты системы взаимодействуют между собой с помощью интерфейсов. На этом уровне тестируют API, взаимосвязь модулей и сервисов.
В интеграцию может входить и системное тестирование.
Системный уровень проверят продукт как единое целое, проверяет соответствие работы системы с функциональными и нефункциональными требованиями. На системном уровне выявляются такие дефекты как несовместимость с окружением, проблемы в архитектуре, отсутствующая или неверно реализованная функциональность, неудобство использования и медленная скорость работы.
Приемочное тестирование
Также часто называют E2E тестами (End-2-End) или сквозными. Суть тестирования в том, чтобы проверить, соответствует ли работа системы, макетам и бизнес-требованиям (бизнес-требования определяют смысл проекта, обосновывают его необходимость), с имитацией пользовательского использования.
Приемку могут проводить тестировщики компании или заказчик.
Таких тестов должно быть как можно меньше, потому что цель тестов состоит в проверке всего ПО на предмет зависимостей функций и модулей, связь с другими системами, и корректность работы с базами данных, поэтому E2E тесты автоматизируются и разрабатываются сложнее и дольше, могут стоить дороже.
Минус классической пирамиды тестирования:
Пирамида не очень хорошо подходит для микросервисной архитектуры. Долгое время, когда архитектура большинства проектов была монолитная, это был чрезвычайно эффективный способ организации тестов. В мире микросервисов это уже не так.
Самая большая сложность в микросервисе заключается не в самом сервисе, а в том, как он взаимодействует с другими сервисами.
Наличие слишком большого количества модульных тестов в микросервисах, которые по определению малы, также ограничивает возможности изменения кода без необходимости изменения тестов. Изменяя тесты, мы теряем некоторую уверенность в том, что код по-прежнему делает то, что должен, и это негативно влияет на скорость, с которой мы выполняем итерации.
Перевернутая пирамида тестирования.
Перевернутая пирамида — мало юнит-тестов, среднее количество интеграционных тестов, много системных тестов.
Основной смысл заключает в том, что тесты пользовательского интерфейса должны автоматизироваться в большей мере.
Плюс перевернутой пирамиды
E2E(UI) тесты дают наибольшую уверенность, что работа всей системы полностью соответствует ожиданиям конечного пользователя. Но одновременно это ловушка. С одной стороны, мы уверены в качестве продукта, а с другой — тратим огромное время на получение фидбека, что система работает после внесения каких-либо изменений. Если каждый Unit-тест выполняется за миллисекунды, Integration — за секунды, E2E может занимать несколько десятков секунд или минуты. И даже если тест выявил дефект, мы точно не знаем, в каком сервисе и в каком месте кода произошел сбой. Мы должны будем потратить достаточно много времени на поиск причины бага.
Минусы перевернутой пирамиды:
- Длинные тестовые прогоны. Время выполнения занимает намного больше времени, чем другие типы тестов, потому что оно основано на взаимодействии с визуализированными элементами пользовательского интерфейса и не обязательно имеет хуки в исходном коде;
- Сложно поддерживать, так как тесты пользовательского интерфейса сложно писать, и они очень сильно зависят даже от малейших изменений;
- Больше подходит для сценариев позитивного пути. Тестирование отрицательных путей в сквозных тестах очень затратно и долго выполняется по сравнению с тестами более низкого уровня;
- Ожидание написания модульных тестов до тех пор, пока функции не будут завершены, может привести к тому, что каждому придется несколько раз выполнить большую работу для решения проблемы.
Кубок
Уровни тестирования остаются те же E2E(UI), Integrations и Unit, но изменилось соотношение между различными уровнями, также добавлен Static слой, необходимый для тестирования на JavaScript (из-за особенностей языка), что не было учтено в классической пирамиде тестирования.
Особенности кубка и преимущества.
* Обеспечивает наилучшее сочетание скорости, стоимости и надежности.
Статический слой самый простой. Он заключается в отлове типичных, стилистических ошибок и ошибок форматирования. Модульные тесты (Unit) относительно быстро пишутся и легко запускаются. На этом уровне проверяется работа отдельно взятых узлов. Сквозные тесты(E2E) проверяют приложение с точки зрения пользователя. Они самые медленные и не стабильные. Интеграционные тесты (Integration), которые проверяют гармоничное функционирование нескольких модулей вместе, находятся посередине. Таким образом, они работают на максимально возможной скорости.
* Это очень выгодно
Чем серьезнее проблема, тем дороже она будет стоить вам в будущем.
Интеграционные и E2E тесты проверяют критические случаи, которые могут помешать клиентам использовать продукт. Следовательно, они дают более высокий уровень уверенности в том, что приложение работает именно так, как задумано разработчиками. Кроме того, интеграционные тесты охватывают сразу несколько компонентов. Таким образом, вы можете пропустить некоторые модульные тесты, но включить их в интеграционные тесты.
Интеграционные тесты легче писать, чем E2E, и они более стабильны. Учитывая все плюсы и минусы, интеграционные тесты имеют самый высокий ROI (Return on Investment, возврат инвестиций).
* Учитывается архитектура программного обеспечения
Еще одно преимущество интеграционных тестов заключается в том, что они достаточно гибкие, чтобы обрабатывать изменения кода. Напротив, модульные тесты показали себя довольно недружественными к архитектуре. Что это значит? Например, если вы решите ввести новые компоненты в код на уровне модуля, вам придется переписать весь набор модульных тестов. Таким образом, интеграционное тестирование делает акцент на дизайне, что упрощает изменение кода.
Тестовая фигура для frontend-проекта
Frontend Testing — это тип тестирования, который проверяет уровень представления 3-уровневой архитектуры.
С точки зрения непрофессионала, вы проверяете GUI — все, что видно на экране, на стороне клиента. Для веб-приложения интерфейсное тестирование будет включать проверку функциональных возможностей, таких как формы, графики, меню, отчеты и т. д., а также связанный Javascript. Тестирование внешнего интерфейса — это термин, охватывающий различные стратегии тестирования. Тестер должен хорошо понимать бизнес-требования для выполнения этого типа тестирования.
Вероятно, лучшей фигурой для данного вида тестирования является кубок:
И вот почему:
Причина № 1. Оптимальное сочетание скорости, стоимости и уверенности
Никто не станет спорить, что чем выше вдоль пирамиды (или кубка) вы поднимаетесь, тем больше времени уходит на тесты.
Статическое тестирование — самое простое. Оно заключается в выявлении ошибок несоответствия типов, стилистических проблем и ошибок форматирования с помощью линтеров, средств форматирования ошибок и проверки типов. Юнит-тесты быстро пишутся и легко запускаются. На этом уровне проверяется работа отдельно взятых модулей. E2E-тесты проверяют приложение с точки зрения конечного пользователя. Они самые медленные для написания и запуска. И посередине между всем этим находятся интеграционные тесты, проверяющие слаженное функционирование нескольких взятых вместе модулей. Таким образом, именно последние тесты демонстрируют оптимальную скорость выполнения.
Следующий момент — стоимость. Бюджет каждого проекта, выделенный на тестирование, ограничен. Поэтому лучшим вариантом будет сосредоточить основное своё внимание на самых выгодных тестах. Которые ко всему прочему учитывают дизайн и создают соответствующую степень надёжности. Всё это — черты интеграционных тестов. E2E-тесты слишком дорогие. Конечно, наиболее дёшево обходятся юнит-тесты. Так почему бы не проводить только их? Ответ можно описать одним словом: уверенность.
Каждый тип тестирования имеет свои преимущества. Простые юнит-тесты решают простые проблемы. Другими словами, они могут проверить надлежащую работу отдельных модулей, но не могут гарантировать того же в случае их комбинации. Это как детали мотора. По отдельности они вроде бы функционируют нормально, а машина в целом не заводится. Юнит-тесты не обещают, что приложение в целом будет работать в соответствии со спецификацией. А интеграционные тесты предназначены как раз для этого.
Таким образом, интеграционные тесты обеспечивают наилучшее сочетание скорости, затрат и уверенности.
Причина № 2. Обещание высокого возврата инвестиций
Чем серьёзнее проблема, тем дороже обойдутся её последствия. Если юнит-тест не затронет какую-то крайне редкую ситуацию, с которой в дальнейшем столкнётся один из миллиона пользователей, это не критично. Но если в приложении не работает кнопка “Оплатить”, это проблема, которая будет стоить тысячи долларов.
То же верно и для противоположных случаев. Чем выше вдоль кубка (или пирамиды) вы поднимаетесь, тем более окупаются ваши тесты. Для этого есть несколько причин. Как мы упоминали раньше, интеграционные и Е2Е-тесты проверяют критические случаи, которые могут помешать пользователям взаимодействовать с вашим продуктом. Следовательно, они создают более высокую уверенность в том, что приложение будет работать в точности так, как и было задумано. Кроме того, интеграционные тесты охватывают сразу несколько модулей. Так что вы можете пропустить некоторые юнит-тесты, но предусмотреть их в интеграционных тестах.
Следовательно, интеграционные тесты легче писать, чем Е2Е, и они более стабильны, чем юнит-тесты. С учётом всех вышеупомянутых плюсов и минусов, именно тесты в средней части кубка обещают самую высокую окупаемость инвестиций.
Причина № 3. Создание гибкой архитектуры программного обеспечения
Ещё одно преимущество интеграционных тестов заключается в том, что они предлагают возможность для гибкого изменения кода. Юнит-тесты, наоборот, демонстрируют довольно недружелюбное отношение к архитектуре ПО. Что это значит? Например, если вы решите ввести новые компоненты в код на уровне модулей, вам придется уже на этом этапе переписывать тест-кейсы. Интеграционное тестирование делает упор на дизайн, что в свою очередь упрощает изменение кода.
Тестовая фигура для backend-проекта
Бэкенд-тестирование — это тип тестирования, который проверяет уровень приложений и базы данных 3-уровневой архитектуры.
В сложном программном приложении, таком как ERP, внутреннее тестирование повлечет за собой проверку бизнес-логики на уровне приложений. Для более простых приложений бэкэнд-тестирование проверяет серверную часть или базу данных. Это означает, что данные, введенные в интерфейс, будут проверены в базе данных. Формат базы данных может быть SQL Server, MySQL, Oracle, DB2 и т. д. Данные будут организованы в таблицы в виде записи.
Для данного вида тестирования, вероятно, наиболее оптимальное решение - классическая пирамида тестирования.
Идея: пишите больше юнит тестов, потому что они “дешевые”, быстрые и должны быть фундаментом.
Потом интеграционные, ну а UI и мануального тестирования должно быть совсем мало.
