В прошлой статье про тестирование калькулятора мы занимались ручным тестированием. Это эквивалент любого другого ручного труда: может быть эффективно, но плохо масштабируется, и вообще это не инженерный подход.
А вот — инженерный. В этой статье разберём на базовом уровне основные подходы к инженерному тестированию.
Что такое автотесты
Автотесты — это тесты, которые выполняет компьютер, а не человек. Внутри автотест это тоже программа, цель которой — протестировать, как работает другая программа.
Автотест делается и работает так:
- Программист берёт часть программы, которую он тестирует, и прикидывает, какие данные она должна вернуть, если в неё попадут другие данные.
- Затем программист собирает нужные ему для тестов комбинации данных на вход и на выход, которые должны быть в идеальной ситуации.
- После этого он добавляет в тест специально неправильные данные и ожидаемый ответ в этом случае.
- Когда все проверочные данные готовы, он оборачивает их в код и пишет тест — программу-тестировщика, которая обращается к программе-жертве и смотрит, как та отреагирует на разные данные.
После этого тестировщики смотрят на тестовые и реальные результаты и делают вывод, правильно работает эта часть программы или нет.
Автотесты делятся по масштабам тестирования на юнит-тесты, сервисные тесты и интеграционные тесты.
Юнит-тесты
Юниты — это отдельные модули или части программы, каждый из которых отвечает за что-то своё.
Юнит-тесты проверяют работу отдельных юнитов: берут модуль и прогоняют его по всем своим тестам. Чем меньше и проще модуль, тем проще сделать юнит-тест и прогнать его по модулю. Модулем может быть что угодно — функция, метод класса, часть API и так далее.
Юнит-тесты — самые простые в обслуживании и написании. Работают быстро, проверяют модуль вдоль и поперёк, но есть нюанс: если в программе больше одного модуля, то просто протестировать их по одному недостаточно — они могут работать классно поодиночке, но вместе работать плохо. Чтобы проверить работу нескольких модулей вместе, делают сервисные тесты.
Тестировщик: кто это такой, что он делает и как им стать
Зарплата 113 тысяч за то, чтобы ломать программы
Что почитать начинающему тестировщику
Как создать простой калькулятор на JavaScript
UX-тест простого калькулятора на JavaScript
Тестируем и исправляем калькулятор на JavaScript
Какой софт нужен, чтобы стать тестировщиком
Что такое альфа- и бета-версии
End-to-End-тестированиеСервисные тесты
Задача сервисного теста — протестировать работу нескольких модулей вместе: как они запускаются, передают друг другу данные и правильно ли решают свою общую задачу как одно целое.
Это уже сложнее, чем юнит-тесты, зато помогает понять, как модули работают вместе. Правда, не все используют сервисные тесты, а переходят сразу к интеграционным, но знать про них тоже полезно.
Интеграционные тесты
Эти тесты проверяют, как работают все модули сразу или даже как работает вся программа.
Интеграционные тесты — самые сложные, потому что если меняется что-то хотя бы в одном модуле, то, скорее всего, нужно будет переделать весь интеграционный тест. Это дорого и занимает много времени, поэтому в компаниях стараются делать так:
- писать побольше юнит-тестов, прям чтобы было много;
- сервисных тестов писать поменьше;
- а интеграционных — ещё меньше, в идеале один или два, и всё.
Минусы автотестов
Если бы всё можно сделать автотестами, которые не пропускают ни одной ошибки в программе, то в разработке ПО наступил бы идеальный мир. Но у автотестов тоже есть минусы.
Стоимость разработки. Так как автотест — это тоже программа, на её разработку тоже нужны время и деньги. Чем сложнее автотест, тем больше ресурсов на него нужно. Иногда проще разбить один большой тест на много тестов поменьше, чем разрабатывать огромную универсальную тест-машину.
Поддержка. Там, где разработка, там и поддержка ПО. Автотесты тоже нужно поддерживать в актуальном состоянии: следить за правильностью тестируемых параметров, текущими названиями классов и методов и версиями тестируемого софта.
Выбор тестов. Чтобы написать хороший автотест, нужно перед этим определиться, а что именно он будет тестировать. Иногда на это уходит столько же времени, сколько и на пару юнит-тестов, а иногда и больше. Если ошибиться на этом этапе, тест может сработать вхолостую и пользы для проекта не будет.
Вот пример: если бы мы автотестировали калькулятор, то мы бы могли сделать тесты с числами 1, 2, 3, 4, 5 … 9999. В нашей голове это максимальное значение, которое людям нужно в обычной жизни. Мы даже не подумаем, что кому-то в нашем калькуляторе понадобится число длиной 17 знаков. А ведь именно на таком числе наш калькулятор и сломался.
Умение программировать. Сейчас появляются инструменты, которые упрощают задачу тестировщика, но без знания алгоритмов пока ещё никуда. Чем лучше инженер по тестированию умеет программировать и строить в голове нужные алгоритмы для проверки, тем круче у него всё получается. Про это как раз в следующем разделе.
Где этому научиться
Можно прочитать нашу подборку книг для новичков — там книги идут по возрастанию сложности, и лучше читать их по порядку. А можно прийти в Практикум и полностью освоить профессию тестировщика за несколько месяцев. По времени будет столько же, а пользы в сто раз больше.
