какие виды тестирования можно автоматизировать
Методы автоматизированного тестирования
Данная статья скорее является размышлениями на тему необходимости, целесообразности и обоснованности применения автоматизированных тестов, нежели погружением в то, как именно их применять.
Компоненты системы
Современная информационная система – большой, сложный и комплексный продукт, состоящий из множества компонентов:
Этапы жизненного цикла системы
В процессе жизненного цикла любая информационная система проходит через несколько этапов, среди которых для целей обзора имеет смысл выделить:
Методы тестирования
Среди методов тестирования информационных систем, коих существует множество, выделим следующие, как наиболее часто используемые:
Технологии тестирования
Рассмотрим какие технологии можно применить для модульного тестирования и покрытия кода тестами.
Как в ходе выполнения проекта, так и при развитии системы, изменения в ее алгоритмы вносятся в соответствии с техническими заданиями, хотя данный документ может иметь различные названия. В технических заданиях, как правило, описываются критерии приемки: как мы и заказчик убедимся в том, что заказанный функционал работает верно.
В качестве примера можно привести такой упрощенный критерий:
Автоматизированное тестирование лишено данных недостатков. Конечно, возникает отдельная задача кодирования данного теста на основании критериев приемки, но это скорее дисциплинирующий фактор.
Инструменты автоматизированного тестирования
В зависимости от платформы, применяются различные инструменты тестирования. Рассмотрим те инструменты, которые можно применить на платформе 1С:
Преимущества применения технологий тестирования
Как и у любой активности, в случае применения тестирования есть свою плюсы и минусы.
Проведенный опрос показал, что к минусам причисляют:
Концепции автоматического тестирования
Здравствуйте, меня зовут Дмитрий Карловский и у меня, к сожалению, нет времени писать большую статью, но очень хочется поделиться некоторыми идеями. Поэтому позвольте потестировать на вас небольшую заметку о программировании. Речь сегодня пойдёт об автоматическом тестировании:
Задачи автоматического тестирования
От более важного к менее:
Ортогональные классификации
На всякий случай подчеркну, что речь идёт исключительно про автоматическое тестирование.
Объекты тестирования
Типы тестов
Виды процессов тестирования
Количество тестов
Чем больше тестов, тем медленнее идёт разработка.
Полнота тестирования
Чем полнее тесты, тем быстрее идёт рефакторинг и тестирование, и как следствие поставка новой функциональности.
Бизнес приоритеты
Стратегии тестирования
В зависимости от приоритетов, можно выделить несколько основных стратегий:
Пример приложения
Чтобы моя аналитика не была совсем уж голословной, давайте создадим простейшее приложение из двух компонент. Оно будет содержать поле ввода имени и блок с выводом приветствия, адресованного этому имени.
Тем, кто не знаком с этой нотацией, предлагаю взглянуть на эквивалентный TypeScript код:
Компонентное тестирование
При этом подходе мы используем реальные зависимости всегда, когда это возможно.
Что следует мокать в любом случае:
Итак, сперва пишем тест на вложенный компонент:
А теперь добавляем тесты на внешний компонент:
Как можно заметить, всё, что нам потребовалось — это публичный интерфейс компонент. Обратите внимание, нам всё равно через какое свойство и как передаётся значение в Output. Мы проверяем именно требования: чтобы выводимое приветствие соответствовало введённому пользователем имени.
Модульное тестирование
Для модульных тестов необходимо изолировать модуль от остального кода. Когда модуль никак не взаимодействует с другими модулями, тесты получаются такими же, как и компонентные:
Если же модулю нужны другие модули, то они заменяются заглушками и мы проверяем, что коммуникация с ними происходит как ожидается.
И, наконец, тесты, получается, проверяют не требования (напомню — должно выводиться приветствие с подставленным именем), а реализацию (внутри вызывается такой-то метод с такими-то параметрами). А это значит, что тесты получаются хрупкими.
Хрупкие тесты — такие тесты, которые ломаются при эквивалентных изменениях реализации.
Эквивалентные изменения — такие изменения реализации, которые не ломают соответствие кода функциональным требованиям.
Test Driven Development
Алгоритм TDD довольно прост и весьма полезен:
Если мы пишем хрупкие тесты, то на шаге рефакторига они будут постоянно падать, требуя исследования и корректировки, что снижает производительность программиста.
Интеграционные тесты
Чтобы побороть оставшиеся после модульных тестов кейсы, придумали дополнительный вид тестов — интеграционные. Тут мы берём несколько модулей и проверяем, что взаимодействуют они правильно:
Ага, у нас получился тот самый последний компонентный тест. Иначе говоря, мы так или иначе написали все компонентные тесты, проверяющие требования, но дополнительно зафиксировали в тестах конкретную реализацию логики. Как правило это избыточно.
Вручную или автоматически: Пара слов о тестировании приложений
Автоматизированное тестирование — это одна из самых обсуждаемых тем среди инженеров по контролю качества. Новые системы тестирования программного обеспечения появляются постоянно, и каждый новый фреймворк получает титул лучшего.
Однако автоматизированное тестирование основывается на предположении, что программа используется так, как это задумали разработчики. Если полагаться только на автоматические тесты, то вскоре в коде появятся ошибки, и в то же время вы получите слабое представление о качестве интерфейса приложения.
Что касается ручного тестирования, то ему уделяют всё меньше внимания, поскольку такой процесс изнуряет сотрудников, а на роль исполнителя подойдет только специалист с особым складом ума. Однако «ручные» тесты отнюдь не уступают автоматизированным. Дело здесь в том, что подходы обладают разными областями применимости, поэтому сегодня мы рассмотрим некоторые достоинства и недостатки каждого решения.
Автоматизированное тестирование
По мнению Сары Фитжи (Sarah Fittje), инженера контроля качества в компании Project A Ventures, если тест подразумевает выполнение большого числа повторяющихся задач, то его имеет смысл автоматизировать. Классический пример — регрессионное тестирование, позволяющее обнаружить серьёзные баги, поэтому его важно регулярно проводить в полном объеме до запуска конечного продукта (кстати, если вам интересно, можете почитать руководство для QA-специалистов от Сары, его вы можете найти по ссылке).
При этом не стоит думать, что настройка автоматических тестов позволит серьезно сэкономить. Написание и поддержка написанных скриптов требует определенных навыков в области QA, которыми обладают не все тестировщики, следовательно, компании придется платить своим специалистам больше (однако штат тестировщиков все же удастся сократить).
Также стоит отметить, что достаточно сложно внедрять автоматизированные тесты для большого приложения с большим функционалом – так вы рискуете потерять видение общей картины и не сможете покрыть тестами весь функционал. Однако настраивая систему автоматизированного тестирования с первых дней проекта, вы получаете возможность ускорить циклы контроля качества и наладить последовательную проверку работы приложения.
Однако важно понимать, что автоматизированное тестирование не сможет помочь в определении недостатков внешнего вида интерфейса и качества взаимодействия пользователя с продуктом. Рассмотрим направления для применения автоматизации:
Тестирование графического интерфейса
Этот тип тестирования нацелен на проверку front-end-части приложения. Без помощи автоматизации очень трудно учесть все возможные комбинации взаимодействия пользователя с интерфейсом в веб-браузерах, мобильных устройствах и прочих системах (важно понимать, что такой тест не сможет оценить UX, как было отмечено выше).
Регрессионное тестирование
С помощью этого типа тестирования разработчики находят баги, вызванные улучшениями функций приложения. Под давлением частых обновлений разработчикам приходится трудиться в бешеном ритме и иногда идти на компромиссы, чем непременно пользуются баги, «закрадываясь» в код программного обеспечения. Вручную отследить недочеты каждого релиза достаточно проблематично.
Функциональное тестирование
Это тестирование для проверки выполнения функциональных требований, то есть работает ли приложение в соответствии с ожиданиями. Определяется, насколько точно реализуются задуманные функции, проводится анализ на соответствие стандартам, оценивается защищённость решения. На повторение функционального тестирования уходит много времени, даже при небольшом изменении в приложении, поэтому выполнять все действия «руками» может быть накладно.
Ручное тестирование
Автоматизированное тестирование помогает добиться высокого качества, но на данный момент оно ещё не заменило ручные тесты полностью. Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.
Пока пользователь привыкает к приложению, он способен ошибаться, не завершать нужные шаги, вводить неожиданные значения и так далее. Пользователи знают гораздо меньше о вашем продукте, но в итоге именно они будут им пользоваться. Поэтому клиентское одобрение — самый ценный индикатор качества интерфейса.
Когда для оценки работы программы ключевую роль начинают играть поведенческие особенности человека и интуиция, то стоит обратить внимание на ручное тестирование — здесь важнее поставить себя на место пользователя. Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.
Пара юзкейсов ручного тестирования:
Юзабилити-тестирование
Это тестирование служит для проверки удобства использования приложения с точки зрения пользователя. Такую расплывчатую по своим целям задачу компьютер решить не может — машине нужны четкие формулировки.
Ad hoc тестирование
Разовое тестирование, направленное на проверку одного аспекта программы. Для такого типа тестирования нет формально определённых правил, оно проводится импровизационно — тестировщик может использовать любые доступные средства для поиска багов. Фактически ad hoc тесты – это попытка «угадать» возможную ошибку.
Комбинированный вариант
Как мы отметили выше, разные типы тестирования обладают разными сферами применимости. Автоматические тесты не заменят ручные, но они могут быть использованы для экономии рабочего времени при отработке больших однообразных наборов действий. Ручное же тестирование выполняется долго, но без него не обойтись, если вы хотите добиться высокого качества продукта. На данный момент только комбинация этих подходов способна обеспечить высокие стандарты по отношению к функциональности и удобству использования продукта.
В качестве примера такого подхода Сара Фитжи приводит процесс тестирования онлайн-магазина natue, когда после успешного внедрения новых функций в тестовом проекте, QA-команда запускала автоматизированное регрессионное тестирование.
«Пока выполнялась автоматизированная проверка, мы одновременно проводили ручное тестирование новых функций, учитывая промежуточные результаты регрессионного теста, – рассказывает Сара. – Если во время ручного или автоматизированного тестирования обнаруживались баги, то они исправлялись, а тесты запускались заново». Если же все проходило успешно, то команда Сары повторяла проверку уже перед самим запуском финальной версии.
Еще один пример приводит Стивен Аллен (Steven Allen), инженер компании TestGrid.io. Он говорит, что в iOS полноценное автоматизированное тестирование долгое время было недоступно. Несколько лет назад Apple начали выпускать инструменты для автоматизации, но они пока что не совершенны. Поэтому использовать только средства автоматизации не получается – приходится прибегать к ручному тестированию.
Разработчики автоматизируют тесты, чтобы работать эффективнее и успевать больше, но нельзя описать скриптами все возможные варианты использования приложения и учесть все ошибки. Некоторые вещи очень легко пропустить – например, если на экране входа появилось лишнее поле ввода пользовательского имени, но при этом всё остальное работает правильно.
«Очень сложно написать идеальный код для автоматических тестов, – говорит Джозеф Миллар (Joseph Millar), специалист отдела контроля качества компании Lucid Software. – Если разработчик допустит ошибку в скриптах, он рискует пропустить большой пласт ошибок, тогда как при ручном тестировании эти недочеты, скорее всего, будут обнаружены. Поэтому так важно использовать оба метода при разработке приложений. Один для экономии времени, второй для «шлифовки».
Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать
Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать «все». Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?
Исчерпывающее тестирование невозможно. Это один из ключевых принципов тестирования программного обеспечения. Перед тем, как начнется автоматизация тестирования, вам необходимо принять решение на основе данных о том, что вы будете автоматизировать, а что нет, и в каком приоритете. При принятии решения о том, что автоматизировать, следует учитывать несколько основных моментов, например уровень автоматизации, на котором вы будете создавать свои тесты. Автотесты можно разделить на три основных уровня: модульные тесты, интеграционные тесты и UI тесты. Вы должны оценить плюсы и минусы написания тестов на каждом из этих уровней, прежде чем приступать к их написанию.
Независимо от того, какой уровень автоматического тестирования вы выполняете, цель должна заключаться в автоматизации того, что приносит наибольшую пользу и учитывание областей, всегда тестируемых для каждого релиза, и областей, которые трудно тестировать вручную. Вам также следует обратить внимание на области, в которых требуется обрабатывать огромные объемы данных. Все эти факторы необходимо учитывать перед автоматизацией. Если вы создаете автотесты вслепую или по своей прихоти, это увеличивает вероятность того, что вы не получите от них столько пользы, сколько следовало бы.
Ниже подробно описаны пять критических областей/факторов, о которых следует помнить, когда вы рассматриваете возможность интеграции автоматического тестирования в свой текущий рабочий процесс.
Автоматизируйте ваши смоук тесты
Смоук тесты очень важно выполнять для получения уверенности, что ваше приложение функционирует на базовом уровне, после каждого изменения или при создании нового билда. Смоук тесты могут быть интегрированы в пайплайн CI / CD, чтобы убедиться, что блокирующие ошибки обнаруживаются на ранней стадии. Смоук тесты гарантируют, что наиболее важные аспекты и основные компоненты приложения работают правильно. Они тестируют области, которые всегда должны работать, и могут помочь вам понять, достаточно ли стабильна сборка или приложение для продолжения дальнейшего тестирования. Автоматизация смоук тестов может:
Помочь быстро обнаружить блокирующие ошибки, например, не загружается приложение/веб-страница, пользователь не может войти в систему, пользователь не может создать учетную запись или платежные сервисы не работают.
Обеспечивает более быстрое устранение новых и регрессионных багов. Смоук тесты по своей природе имеют большой охват и небольшую глубину. Это приводит к тому, что тестируется широкий спектр тест-кейсов, не углубляясь в приложение. Когда эти критические области заработают, вы сможете глубже изучить приложение, чтобы протестировать другие функции.
Приводит к меньшему количеству ручного труда и экономит время. Путем интеграции ваших автотестов в пайплайн CI/CD ваши смоук тесты сворершают проверку до завершения сборки. Это означает, что сборка не передается QA, если автотесты не пройдут смоук.
Автоматизируйте тесты, которые выполняются всегда, например, регрессионные тесты или тесты, которые всегда находятся в начале каждого рабочего процесса.
Это позволяет вам иметь набор стабильных тестов, жизненно важных для приложения. Например, создание учетной записи пользователя необходимо будет выполнить до того, как пользователь сможет войти в систему и просмотреть панель управления, совершать платежи и т. д. Создавая набор автоматизированной регрессии, вы можете:
Запускать тесты, которые быстро выявляют любые ошибки, возникающие в результате изменений в программном обеспечении. Эти изменения могут быть новыми функциями или исправлениями багов.
Иметь набор стабильных тестов. Регрессионные тесты обычно предназначены для существующих функций, что означает, что эти функции не являются новыми и были протестированы раньше. Это предотвращает появление флаки автотестов, из за которых вам пришлось бы тратить много времени на ручное тестирование, так как вы не уверены, действительно ли тесты провалились или нет.
Экономить время, так как теперь вы можете сосредоточить свои усилия на ручном тестировании на большем количестве крайних кейсов.
Автоматизируйте обширные тесты
Исчерпывающие тесты, такие как ввод больших наборов данных, тестирование формы или тесты, требующие от тестировщика многократного выполнения одного и того же процесса, но с большим разнообразием данных, должны быть автоматизированы. Вы можете создавать автотесты на основе данных, которые позволяют сэкономить время. Для различных форм автотесты позволяют вам быстро тестировать различные комбинации входных данных, например, отсутствуют ли поля, являются ли они неполными и т. д. Тестирование на основе данных очень полезно, поскольку оно позволяет вам изменять только данные, а не тестовый сценарий, чтобы получить разные результаты. Такие тесты очень многоразовые и эффективные.
Автоматизируйте тесты, требующие нескольких конфигураций
Автоматизируйте ваши тесты производительности
Ваш следующий шаг
Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.
говориМ о тестировании
простым языком
Виды тестирования по степени автоматизации
Но почему же автоматизированное тестирование до сих пор не вытеснило ручное? В чем плюсы и минусы каждого из них? Давайте разбираться.
Ручное тестирование
Ручное (мануальное) тестирование — это тестирование без помощи каких-либо программ, автоматизирующих работу.
Например, чтобы протестировать работу формы авторизации, мы сами заходим на сайт и вручную заполняем поля «Имя» и «Пароль». То есть мы выступаем в роли обычного пользователя продукта.
Напомню, что ручное тестирование строится на методах тестирования. Сюда относятся и техники тест-дизайна, и техники, основанные на опыте. Просто еще раз хочу обратить внимание, что тестирование — это заранее продуманная деятельность по сравнению фактического результата с ожидаемым, а не просто поиск ошибок «методом тыка».
Плюсы ручного тестирования:
Минусы ручного тестирования:
Автоматизированное тестирование
Автоматизированное тестирование предполагает использование специального программного обеспечения (помимо тестируемого) для контроля выполнения тестов и сравнения ожидаемого результата работы программы с фактическим.
Этот тип тестирования помогает автоматизировать часто повторяющиеся, но необходимые для максимизации тестового покрытия, задачи.
Это отдельная дисциплина искусства тестирования. Значительная часть эффективности работы отдела тестирования зависит от того, какие задачи отданы для автоматизации и как эта автоматизация была осуществлена.
Подходы к автоматизации
Ниже представлена пирамида автоматизации Майка Кона, которая иллюстрирует эффективный подход к автоматизации тестирования.
Ширина каждого уровня пирамиды показывает, сколько тестов должно быть на каждом уровне по сравнению с другими.
На нижнем уровне пирамиды находятся компонентные автотесты. Это тесты, которые проверяют на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки. Например, можно сделать тест на добавление одного товара в корзину. Или проверку одного вычисления на калькуляторе.
Средний уровень занимают интеграционные автотесты, которые верифицируют бизнес-поведение (но не через GUI). Такие тесты иногда называют API тестами. API — это интерфейс, который позволяет общаться напрямую с программой, минуя пользовательский интерфейс.
Например, вместо того, чтобы зайти на сайт, выбрать нужный товар и положить его в корзину, автотесты могут напрямую сказать сайту, отправив запрос “положи товар в корзину”.
Верхний уровень пирамиды — автотесты пользовательского интерфейса, которые непосредственно затрагивают пользовательский интерфейс. Например, проверяем отображение или изменение информации о сумме покупок в корзине через пользовательский интерфейс.
Что можно автоматизировать?
Давайте в качестве примера рассмотрим несколько программ автоматизации.
1. Программы для помощи в черноящичном тестировании. Например:
— автоматическое создание аккаунтов пользователя;
— запросы к базе данных и генерация файлов формата, утвержденного системой VISA, используя извлеченные данные;
— генерация транзакции покупки в нашем магазине и т.д.
2. Программы для регрессионного тестирования. Это специальное ПО, созданное для буквального воспроизведения действий тестировщика.
Например, согласно тест-кейсу мы должны:
— войти в систему,
— выбрать товар,
— положить его в корзину,
— заплатить,
— удостовериться, что баланс на кредитной карте уменьшается на сумму покупки.
Чтобы исполнить этот тест-кейс, мы должны запустить браузер, ввести имя пользователя и пароль, нажать на кнопку «Вход»… и, в конце концов, сравнить фактический и ожидаемый результаты. Теперь представьте себе, что некая программа делает те же самые действия за вас.
Такое ПО, как правило, поддерживает режим «Запись / Воспроизведение», т.е. когда мы нажимаем на кнопку «Запись» и начинаем кликать мышками и клацать клавишами клавиатуры, ПО записывает наши действия и, когда мы закончили, генерирует код. Этот код мы можем запустить с этим же ПО, и оно воспроизведет все наши клики и клацы, т.е. буквально будет водить курсором мышки, набирать текст и т.д.
3. Программы для тестирования скорости и надежности. Это программы, которые помогают проводить стрессовое и нагрузочное тестирование.
Плюсы и минуса автоматизации
Преимущества:
Недостатки:
Смешанное/полуавтоматизированное тестирование
Здесь ручной подход сочетается с автоматизированным. Например, с помощью программы создается новый аккаунт, а потом вручную генерируются транзакции покупки.
Почему ручное тестирование не вымерло?
Да, автоматизация значительно сокращает время на тестирование определенных фич. Плюс есть вещи, которые просто невозможно проверить вручную. Но не стоит забывать и о ее стоимости. Не все продукты финансово могут потянуть автоматизацию. Да и не всегда требуется что-то автоматизировать.
Также вручную можно протестировать практически любое приложение, в то время как автоматизировать стоит только стабильные системы. То есть мы не можем, по крайней мере на сегодняшний день, автоматизировать все проверки.
Автоматизированное тестирование используется главным образом для регрессии. Кроме того, некоторые виды тестирования, например, исследовательское тестирование, могут быть выполнены только вручную.
Автоматизация начинается с ручного тестирования. То есть для того, чтобы начать процесс автоматизации тестирования, нужно точно знать, что и как вы собираетесь делать. Идеальный автотест базируется на ручном тест-кейсе с должным уровнем детализации.
Ручное тестирование существует, так как невозможно автоматизировать все проверки и автоматизация не всегда финансово выгодна.
На реальных проектах часто используется комбинация ручного и автоматизированного тестирования. Уровень автоматизации зависит от многих факторов: тип проекта, особенности постановки производственных процессов в компании, финансовых возможностей и т.п.
Оба вида тестирования имеют как преимущества, так и недостатки. Комбинация обоих — хороший способ получить от тестирования максимальный результат.