Селиванов П.А., Кучер М.Ю., Белов Ю.С., Калужский филиал федерального государственного бюджетного образовательного учреждения высшего образования «Московский государственный технический университет имени Н.Э. Баумана (национальный исследовательский университет)», Калуга, fn1-kf@mail.ru

Подходы к тестированию
в программной инженерии

В статье содержится информация о важности тестирования приложений во время разработки программного обеспечения. Оно нужно для того, чтобы находить ошибки и улучшать ПО, и проводится для снижения рисков, так как поиск и устранение проблем происходит заранее. Здесь же будут рассмотрены два качества ошибки, которые влияют на оценку приложения его пользователем. Также в статье описываются некоторые методы тестирования, такие как тестирование «белого» и «черного ящика», их недостатки и преимущества, а также автоматизированное регрессионное тестирование. Далее будет описан процесс тестирования, состоящий из четырех шагов: разработки плана тестирования, разработки тестов, создания и выполнения тестов и регистрации результатов. Каждый этап содержит объяснения. Затем разобран вопрос о тестировании в agile-командах, то есть о том, насколько оно для них важно и как должно быть осуществлено в данном методе организации разработки. В конце будет рассказано о приложении Postman, которое используется для запуска тестов к API, а именно о том, какие в нем существуют типы переменных, принципах работы и преимуществах

Основная идея тестирования

Как правило, начинающие разработчики не видят важности в тестировании программ. Они не понимают, что это необходимо. Им это кажется ненужной и лишней тратой времени. Они говорят: «Зачем тестировать код, если он отлично работает».

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

Далее мы рассмотрим, как на клиентов влияет частота ошибок в работе приложения. Затем рассмотрим, насколько важна степень критичности этих ошибок [2]. Если в программном обеспечении существует редкая ошибка, которая приводит к зависанию на несущественное время, мало заметное пользователю, то она не имеет большого значения. Но если она происходит часто, то это не остается незамеченным и раздражает пользователя.

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

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

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

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

Существуют общеизвестные методы тестирования, о которых следует узнать первым делом, столкнувшись с понятием «тестирование». Далее приведены концепции, разделенные по принципу степени ознакомленности тестировщика с кодом.

Тестирование «Черный ящик» – это простое тестирование, как будто программа представляет собой «черный ящик» [3]. Это одна из самых распространенных форм и способ описать целую категорию. При этом тестировании важность имеют только входные и выходные данные. Не имеет значения, как именно обрабатываются входные данные, чтобы получить результат. О коде или о том, как он работает, ничего не известно, то есть для данного набора входных данных программное обеспечение должно генерировать уже известный тестировщику выходной результат. Большинство испытаний проводится именно таким образом, потому что они не предвзяты. Система либо работает, либо нет. Оно имеет определенные преимущества над другими видами тестирования. Например, упрощает тестирование, поскольку рассматриваются только вход и выход, тестировщику не требуется иметь технических навыков, тестирование с точки зрения пользователя и некоторые другие. Но имеет и недостатки, т.к. причины ошибок не видны, из-за чего бывают трудности при составлении тест-кейсов.

Тестирование «белого ящики» – это когда присутствует понимание некоторых внутренних компонентов системы и, возможно, имеется доступ к фактическому исходному коду, который используется для тестирования. Тестирование «белого ящика» противоположно тестированию «черного ящика [4]. При нем имеется некоторое представление о том, что происходит внутри программного обеспечения. Например, существует код, выполняющий сложные расчеты, и в нем есть часть кода, которая выполняется только при определенных условиях, значит, можно создавать тесты, которые будут учитывать выполнение этого условия. В тестировании «черного ящика» нет возможности узнать о существовании этого условия, поэтому есть вероятность, что какая-то часть кода не будет покрыта тестами или их будет очень много [5].

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

Автоматизированное тестирование – это такое тестирование, в котором выполнение теста и верификация результатов являются автоматизированными [6]. Таким образом, можно автоматизировать тестирование веб-приложения, запустив скрипты, которые открывают веб-страницу, вводят нужные данные, нажимают нужные кнопки, а затем проверяют результаты на странице. Также возможно автоматизировать тестирование API, написав сценарии, которые вызывают API с различными параметрами, а затем, проверив результаты, которые возвращаются. Все больше и больше тестов автоматизируются, потому что ручное выполнение сценариев утомительно, подвержено ошибкам и дорогостоящее, особенно в agile-среде, где один и тот же набор тестов может потребоваться запускать каждые две недели, чтобы убедиться, что ничего не сломалось.

Регрессионное тестирование – в основном выполняется для проверки того, что система все еще работает так, как раньше. Цель регрессионного тестирования заключается в том, чтобы убедиться, что программное обеспечение не утратило своей функциональности. Это чрезвычайно важно для agile-методологий разработки, где программное обеспечение разрабатывается постепенно и существует возможность, что добавление новых функций может изменить существующие. Большинство автоматизированных тестов являются регрессионными. Вся цель автоматизации тестирования в том, чтобы проводить одни и те же тесты несколько раз и не тратить на это большое количество времени.

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

• Нагрузочное тестирование.
• Приемочное тестирование.
• Функциональное тестирование.
• Исследовательское тестирование.
• Тестирование производительности.
• Тестирование восстановления.
• Тестирование безопасности.
• Стресс-тестирование.
• Тестирование простоты и комфорта работы.
• Тестирование доступности.

И это далеко не все виды тестирования.

Процесс тестирования

Организации имеют разные представления о том, как должно быть организовано тестирование и какой процесс следует соблюдать. Один из самых распространенных процессов представлен на рис.1. Так же существует множество формальных спецификаций, созданных различными организациями, которые охватывают «процесс тестирования» [7]. Идея здесь заключается не в том, чтобы описать идеальный процесс тестирования, а в том, чтобы дать представление о том, каков процесс тестирования в целом и что он влечет за собой. Рассмотрим, по каким шагам может быть организован процесс тестирования.

Рисунок 1. Процесс тестирования

Шаг 1. Разработка плана тестирования

Тестирование обычно начинается с разработки плана тестирования, в котором, как правило, содержатся ответы на следующие вопросы:

• Как все будет проверено?
• Какова наша стратегия тестирования?
• Какие испытания мы будем проводить?
• Какие функции мы будем тестировать?
• Каков график работы?

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

Шаг 2. Разработка тестов

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

Шаг 3. Создание и выполнение тестов

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

Шаг 4. Регистрация результатов

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

Тестирование в agile-командах

Стандартный процесс тестирования, как правило, сталкивается с некоторыми проблемами в agile-командах, ведь именно в них новые функции реализуются каждые две недели или около того [8]. Многие команды пытаются либо строго следовать стандартным процессам тестирования, либо полностью отказываются от них. Хотя могли бы работать вместе с ними в жизненном цикле разработки программного обеспечения agile.

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

Запросы к API при помощи приложения Postman

Postman – это легкое и быстрое дополнение к Chrome и приложение Windows, Linux, Mac, которое используется для запуска запросов к API. Запросы могут быть организованы в группы, а тесты могут быть созданы с проверками для определенных условий ответа. Благодаря своим функциям это очень хороший и удобный инструмент тестирования API. Можно создавать разные виды HTTP-запросов – GET, POST, PUT, PATCH и DELETE. К запросам можно добавить заголовки. Рассмотрим наиболее интересные функции: переменные, сценарий предварительного запроса, среды и тесты [10].

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

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

Если нужно переключиться между разными учетными данными или изменить какие-то переменные на время – это значит, что нужно использовать окружения. Путем переключения окружения и без изменения запроса можно отправлять различные параметры API.

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

После получения ответа Postman позволяет проверить результат. Это делается на вкладке «Тесты». В случае если ответ в JSON, его можно преобразовать в массив и работать с ним через индексы, точку или цикл.

Заключение

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

1. Кудеяров Ю.А. Испытания (тестирование) программного обеспечения средств измерений [Электронный ресурс] : учебное пособие / Ю.А. Кудеяров. – Электрон. дан. – М.: АСМС, 2010. – 106 с. – Режим доступа: https://e.lanbook.com/book/69295. – Загл. с экрана.
2. Барашко Е.Н., Морозов М.Д. Особенности современных средств разработки и тестирования программного обеспечения // В сборнике: Технические науки: проблемы и решения. Сборник статей по материалам V международной научно-практической конференции . 2017. – С. 44-48.
3. Котляров В.П. Основы тестирования программного обеспечения [Электронный ресурс]: учебное пособие / В.П. Котляров. – Электрон. дан. – М.: 2016. – 248 с. – Режим доступа: https://e.lanbook.com/book/100352. – Загл. с экрана.
4. Ушаков М. Тестирование приложений при разработке. Функциональное и модульное тестирование. // «Системный администратор», № 1-2, 2014 г. – С. 89-93.
5. Learn [Электронный ресурс]. – Режим доступа: https://learn.org/articles/How_Does_a_Software_Testing_Engineer_Do.html. – Заглавие с экрана. – (Дата обращения: 16.10.2018).
6. Лопатина К.И., Темникова Е.А. Ручное и автоматизированное тестирование программного обеспечения отличия и взаимозаменяемость. // «Вестник современных исследований», № 10-1 (13), 2017 г. – С. 75- 77.
7. Старолетов С.М. Основы тестирования и верификации программного обеспечения [Электронный ресурс] : учебное пособие / С.М. Старолетов. – Электрон. дан. – СПб: Лань, 2018. – 344 с. – Режим доступа: https://e.lanbook.com/book/110939. – Загл. с экрана.
8. Гибкая методология разработки программного обеспечения [Электронный ресурс] : учебное пособие. – Электрон. дан. – М.:, 2016. – 153 с. – Режим доступа: https://e.lanbook.com/book/100590. – Загл. с экрана.
9. Сергеева А. Виртуальные машины в тестировании. На примере Alloy Navigator .// «Системный администратор», № 10, 2014 г. – С. 68-73.
10. Васильева М.В., Ванюлин А.Н. Обзор систем автоматического тестирования программного обеспечения. // Cборник материалов Международной заочной научно-практической конференции (24 марта 2017 г.), 2017. – С. 42-46.

Ключевые слова: регрессионное тестирование, автоматизированное тестирование, agile-тестирование, тестирование API, Postman.

Approaches to testing in software engineering

Selivanov P.A., Kucher M.Yu., Belov Yu.S., Bauman Moscow State Technical University (Kaluga Branch) Kaluga, e-mail: fn1-kf@mail.ru

Abstract: This article provides information about the importance of application testing during software development. It is necessary in order to find errors and improve the software and is carried out to reduce risks, as the search and Troubleshooting occurs in advance. It will also consider two qualities of the error that affect the evaluation of the application by its user. The article also describes some testing methods, such as white box and black box testing, their advantages and disadvantages, as well as automated regression testing. The following process will describe the testing, which consists of 4 steps: test plan development, test development, test creation and execution, and results registration. Each stage will contain an explanation. Then the question of testing in agile teams is discussed, that is, how important it is for them and how it should be implemented in this method of development organization. At the end, we will talk about the Postman application, which is used to run tests to the API, what types of variables exist in it, how it works and the advantages of it.

Keywords: regression testing, automated testing, agile testing, API testing, Postman.

Комментарии могут оставлять только зарегистрированные пользователи