Различные виды тестирования ПО

Сравните разные виды тестирования ПО: модульное, интеграционное, функциональное, приемочное тестирование и другие варианты.

Sten Pittet Sten Pittet

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

Сравнение тестирования в ручном и в автоматическом режиме

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

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

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

Виды тестирования

Модульные тесты

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

Интеграционное тестирование

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

Функциональные тесты

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

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

Сквозные тесты

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

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

Приемочное тестирование

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

Тестирование производительности

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

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

Smoke-тестирование

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

Smoke-тесты полезно запускать сразу после создания новой сборки (для определения, можно ли запускать более ресурсоемкие тесты) или сразу после развертывания (чтобы убедиться, что приложение работает правильно в новой, только что развернутой среде).

Как автоматизировать тесты

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

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

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

Благодаря Bitbucket Pipelines каждая отправка кода в репозиторий проверяется

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

Глубокое тестирование

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

Так стоит ли, с учетом всего сказанного, выполнять тестирование вручную? Если отвечать на этот вопрос кратко — да. И особое внимание следует уделить глубокому тестированию, целью которого является выявление неочевидных ошибок.

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

Дополнительный комментарий к теме тестирования

В завершение этого руководства важно поговорить о целях тестирования. Важно проверять не только то, могут ли пользователи использовать ваше приложение («Я могу войти в систему», «Я могу сохранить объект»), но и может ли система не выходить из строя при вводе недопустимых данных или выполнении непредвиденных действий. Вы должны понимать, что произойдет, если пользователь сделает опечатку, попытается сохранить неполную форму или воспользуется неверным API. Необходимо проверять, может ли пользователь скомпрометировать данные или получить доступ к ресурсу, к которому не должен иметь доступа. Хороший комплект тестов должен пытаться сломать ваше приложение и помогать вам в анализе его предельных возможностей.

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