Что такое автоматическое тестирование?

В этом уроке вы ознакомитесь с преимуществами автоматического тестирования и доступными видами тестов. Вы также узнаете, каким должен быть хороший тест и какие инструменты тестирования вам доступны.

Что такое автоматическое тестирование?

В процессе автоматического тестирования используется специальное программное обеспечение, которое выполняет ваш код и сравнивает фактические результаты с ожидаемыми. Такой подход можно сравнить с диагностическим или ручным тестированием, в ходе которого сотрудник, как правило, выполняет определенные инструкции, приведенные в плане тестирования, проверяя работу функций программного обеспечения на соответствие ожиданиям.

У ручного тестирования есть свои преимущества. Тем не менее по мере расширения базы кода ручное тестирование всех компонентов (включая граничные случаи) может стать избыточным, слишком сложным и приводить к возникновению ошибок. Автоматическое тестирование может помочь устранить некоторые из этого бремени и позволить тестировщикам вручную сосредоточиться на том, что они делают лучше всего: гарантируя, что у пользователей будет положительный опыт работы с вашим программным обеспечением.

Пирамида тестирования

Когда мы думаем об автоматическом тестировании, обычно можно разделить тесты на слои. Майк Кон в своей книге Succeeding with Agile (Гибкая разработка ПО) предлагает концепцию пирамиды тестирования.

Хотя это упрощенная версия модели Кона, концепция иллюстрирует, что основное внимание уделяется написанию тестов, которые проверяют базовые уровни программного обеспечения (выноска 1 в пирамиде), такие как функции, классы и методы. Вы постепенно сокращаете усилия, так как функции объединяются, например на уровне пользовательского интерфейса (пользовательский интерфейс) (выноска 2 в пирамиде). Идея заключается в том, что если вы можете убедиться, что каждый компонент нижнего уровня работает должным образом в изоляции, тесты на более высоких уровнях должны проверять только, что несколько компонентов работают вместе, чтобы получить ожидаемый результат.

На каком этапе необходимо писать тесты?

Во многом это зависит от ваших потребностей и опыта в написании тестов.

Добавлять тесты в код никогда не поздно, даже если он уже написан и развернут. Это в особенности важно для функциональных возможностей, в которых часто возникают ошибки и которые требуют усиленного внимания со стороны команды тестировщиков.

Если вы относитесь к тестированию непрерывной интеграции и конвейерам непрерывной доставки, две концепции вы услышите о непрерывном тестировании и перемещении влево.

Под непрерывным тестированием понимается проведение тестов на ранних стадиях процесса разработки по мере внесения любого изменения на протяжении конвейера. Под сдвигом влево понимается ведение процесса разработки с учетом требований к качеству программного обеспечения и более раннему тестированию.

Например, разработчики часто добавляют тестовые случаи по мере разработки их функций и запускают весь набор тестов перед отправкой изменений в конвейер. Этот подход позволяет гарантировать, что создаваемая функция соответствуют ожиданиям и не приводит к нарушению работы других компонентов.

Вот короткое видео, в котором Abel Wang, cloud Advocate at Microsoft, объясняет, как обеспечить качество в плане DevOps.

Спросите Абель

Смена влево часто требует, чтобы тестировщики участвовали в процессе разработки, даже до написания любого кода для функции. Сравните это с моделью передачи, где команда тестирования представлена новыми функциями для тестирования только после разработки и записи программного обеспечения. Ошибка, обнаруженная в конце процесса, может повлиять на расписание доставки команды, и ошибки могут быть обнаружены недели или даже через несколько месяцев после того, как разработчик первоначально создал эту функцию.

Компромиссное решение

При автоматическом тестировании существует компромисс. Хотя автоматическое тестирование позволяет тестировщикам сосредоточить свое время на проверке взаимодействия с конечным пользователем, разработчикам может потребоваться больше времени на написание и обслуживание кода тестирования.

Тем не менее, точка автоматического тестирования заключается в том, чтобы тестировщики получали только код высокого качества, код, который был проверен как ожидалось. Таким образом, разработчики могут отказаться от некоторого времени, обработав меньше ошибок или избегая перезаписи кода из-за пограничного случая, который они первоначально не рассмотрели.

Дополнительные преимущества

К дополнительным преимуществам автоматического тестирования можно отнести оптимизацию документации и упрощение рефакторинга кода.

Документация

Планы ручного тестирования могут выступать в качестве документов, содержащих описание требуемого поведения программного обеспечения и причин, по которым были реализованы те или иные функции.

Автоматические тесты могут использоваться в тех же целях. Код автоматических тестов часто имеет удобный для восприятия формат. Предоставляемые вами входные данные соответствуют значениям, которые может ввести пользователь. Каждый связанный вывод указывает результат, который должны ожидать пользователи.

На самом деле, многие разработчики следуют методу разработки на основе тестов (TDD), написав свой тестовый код перед реализацией новой функции. Этот подход подразумевает написание набора тестов (спецификаций), которые изначально завершаются неудачно. Далее разработчик постепенно пишет код, реализующий функциональную возможность, до тех пор, пока все тесты не будут пройдены успешно. Таким образом, в рамках этого процесса в спецификациях документируются требования к приложению и гарантируется, что для реализации функции будет написан минимально необходимый объем кода.

Рефакторинг

Предположим, вам требуется выполнить рефакторинг большой базы кода, чтобы повысить скорость работы некоторых его частей. Как гарантировать, что в результате рефакторинга не будет нарушена работа приложения?

Автоматические тесты служат типом контракта. То есть вы указываете входные данные и ожидаемые результаты. При наличии набора успешно выполняющихся тестов вы получаете более широкие возможности для экспериментов с кодом и его рефакторинга. При внесении любого изменения вам достаточно запустить тесты и убедиться, что они по-прежнему успешно выполняются. После выполнения целей рефакторинга вы можете отправить изменения в конвейер сборки, чтобы все могли воспользоваться преимуществами, но с более низким риском чего-то критического.

Какие существуют виды автоматического тестирования?

Существует множество видов автоматического тестирования. Каждый тест служит отдельной задачей. Например, вы можете провести тесты системы безопасности и проверить, что доступ к компоненту программного обеспечения или его отдельным функциям могут получать только пользователи с соответствующими разрешениями.

Когда мы упоминаем непрерывную интеграцию и конвейер сборки, обычно мы ссылаемся на тестирование разработки. Под тестированием разработки понимается набор тестов, которые выполняются перед развертыванием приложения в тестовой или рабочей среде.

Например, тестирование lint, форма анализа статического кода, проверяет исходный код, чтобы определить, соответствует ли он руководству по стилю вашей команды. Согласованное форматирование кода позволяет значительно упростить его восприятие и работу с ним.

В этом модуле вы будете работать с модульным тестированием и тестированием покрытия кода.

В рамках модульного тестирования проверяются базовые компоненты вашей программы или библиотеки, такие как отдельные функции или методы. Вы указываете необходимые входные данные и связанные с ними ожидаемые результаты. Средство выполнения теста выполняет каждый тест и проверяет, совпадают ли фактические и ожидаемые результаты.

Например, предположим, у вас есть функция, которая выполняет арифметическую операцию, которая включает разделение. Можно указать несколько значений, которые вы ожидаете, что пользователи будут вводить вместе со значениями edge-регистра, такими как 0 и -1. Если определенный вход создает ошибку или исключение, можно убедиться, что функция создает ту же ошибку.

Тестирование покрытия кода вычисляет процент кода, охватываемого модульными тестами. Тестирование покрытия кода может включать условные ветви в код, чтобы обеспечить охват функции.

Чем больше объем протестированного кода, тем меньше будет в дальнейшем риск возникновения ошибок в непроверенном коде. Вам не нужно достичь 100 процентов покрытия кода. На самом деле, при запуске вы, скорее всего, обнаружите, что у вас есть низкий процент, но это дает вам отправную точку, из которой можно добавить дополнительные тесты, охватывающие проблемный или часто используемый код.

Изоляция модульных тестов

При изучении модульного тестирования можно услышать такие термины, как макеты, заглушки и внедрение зависимостей.

Помните, что модульный тест должен проверять отдельную функцию или метод, а не способ взаимодействия нескольких компонентов. Но если у вас есть функция, которая вызывает базу данных или веб-сервер, как это сделать?

Не только вызов изоляции внешнего разрыва службы, но и может замедлить работу. Если база данных или веб-сервер отключена или недоступна, вызов также может нарушить тестовый запуск.

С помощью таких методов, как имитация и внедрение зависимостей, можно создавать компоненты, которые имитируют эту внешнюю функциональность. Ниже вы получите пример в этом модуле.

В дальнейшем вы можете провести тесты интеграции, чтобы проверить корректность работы приложения с реальными базой данных или веб-сервером.

Каковы отличительные признаки хорошего теста?

Вы сможете лучше определить хороший тест, как вы получаете опыт написания собственных тестов и чтения тестов, написанных другими. Ниже приведены некоторые рекомендации по началу работы:

• Не тестируйте ради тестирования: ваши тесты должны служить цели, помимо того, чтобы быть контрольным элементом, чтобы перекреститься. Напишите тесты, которые проверяют, работает ли критически важный код и не нарушает существующую функциональность.
• Оставьте тесты короткими: тесты должны завершиться как можно быстрее, особенно в тех, которые происходят на этапах разработки и сборки. Когда тесты выполняются по мере перемещения каждого изменения через конвейер, они не хотят быть узким местом.
• Убедитесь, что тесты повторяются: тестовые запуски должны создавать одинаковые результаты каждый раз, независимо от того, выполняете ли они на компьютере, компьютере коллеги или в конвейере сборки.
• Следите за тем, чтобы тесты были сосредоточены: распространенный неправильный способ заключается в том, что тесты предназначены для покрытия кода, написанного другими пользователями. Обычно тесты должны охватывать только код. Например, если вы используете в проекте библиотеку графики с открытым исходным кодом, тестировать ее не нужно.
• Выберите правильную степень детализации: например, если вы выполняете модульное тестирование, отдельный тест не должен объединять или тестировать несколько функций или методов. Проверяйте каждую функцию отдельно и лишь затем используйте тесты интеграции для тестирования взаимодействия между несколькими компонентами.

Какие типы средств тестирования доступны?

Средства тестирования, которые вы используете, зависят от типа создаваемого приложения и типа тестирования, которое вы хотите выполнить. Например, с помощью Selenium можно выполнять тестирование пользовательского интерфейса во многих типах веб-браузеров и операционных систем.

Существует множество средств тестирования, ориентированных практически на любые языки программирования, которые вы можете использовать для создания приложения.

Например, при работе с приложениями Java вы можете проводить тестирование lint с помощью средства Checkstyle и модульное тестирование с использованием средства JUnit.

В этом модуле мы будем использовать NUnit для модульного тестирования, так как он популярен в сообществе .NET.