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

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

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

Позже вы получите другое письмо о том, что что-то сломалось. То, что началось как увлекательное путешествие, быстро превратилось в кошмар с исправлением ошибок. Что вы могли бы сделать по-другому, чтобы этого не произошло?

Войдите в мир создания тестов для вашего программного обеспечения.

Идея, стоящая за тестированием

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

Тестирование может помочь вам в этом. Однако есть два основных направления тестирования: ручное и автоматическое.

Ручное тестирование

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

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

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

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

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

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

Автоматизированное тестирование

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

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

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

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

Добавив больше тестов, вы можете убедиться, что ваша функция работает так, как задумано, для всех типов ввода. При тестировании термин «крайние случаи» часто используется для обозначения того, что случай является одним из таких крайних случаев. Например, что если кто-то введет в блоге 1 000 000 символов?

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

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

1. Юнит тестинг

Первый тип тестирования называется юнит тестированием. «Юнит» в программном обеспечении обычно относится к функции. Это потому, что функция обычно является основным строительным блоком любого программного обеспечения. Вы пишете несколько функций и используете их вместе для достижения некоторой функциональности. Функции, которые предоставляет операционная система, также были протестированы создателями в какой-то момент, поэтому вам не нужно тестировать их.

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

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

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

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

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

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

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

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

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

Существует два основных подхода к интеграционному тестированию: восходящий подход и нисходящий подход.

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

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

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

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

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

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

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

Для игрового цикла 2019 года Call of Duty выпустила бета-версию Modern Warfare. Они делают это, так как было бы слишком дорого создавать автоматизированное тестирование для чего-то более сложного, чем шутер от первого лица AAA. Дешевле просто заставить настоящих людей играть в дерьмо из игры и находить ошибки.

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

Заключение

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

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

About the Author

Ergashev Lazizbek

Добрый день, дорогие мои читатели, позвольте мне рассказать вам немного о себе. Я Лазизбек Эргашев, я веб-разработчик из Узбекистана. В основном я использую laravel/php для бэкэнда и vuejs/javascript для фронтэнда. Основная цель моего блога - поделиться с вами своим опытом и знаниями.

View All Articles