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

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

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

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

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

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

Преимущества и недостатки системного тестирования

К достоинствам системной проверки можно отнести:

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

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

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

• Системное тестирование дает понять, что с технической точки зрения ПО готово и не имеет критических ошибок. Это значит, что для релиза ему остается только пройти проверку на соответствие требованиям бизнеса и пользователей.

Недостатками системной проверки можно считать:

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

• Ввиду того, что это масштабная и трудозатратная проверка, требующая наличия инструментов автоматизации, это ещё и очень затратно.

Зачем проводится системное тестирование?

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

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

Чем системное тестирование отличается от сквозного?

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

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

Метод «черного ящика» позволяет ответить на два вопроса:

• «Что делает система?» – то есть проверка дает понять, откликается ли система на тот запрос, который к ней совершают, выполняет ли действия пользователей. Например, получится ли найти нужный товар в каталоге и добавить его в корзину для оформления заказа.

• «Как работает система?» – то есть удобство системы, насколько она понятна пользователю и соответствует ли его требованиям.

Теперь рассмотрим, какие виды системного тестирования могут проверяться по методу «черного ящика».

Функциональное.

Проверка того функционала, который указан в документации программного продукта.

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

Нагрузочное.

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

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

Восстановительное.

Это проверка возможности восстановления системы после наступившего сбоя.

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

Совместимость.

Тестирование возможности совмещения системы с другими платформами и системами.

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

Производительность.

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

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

Безопасность.

Степень защищенности системы от действий злоумышленников.

Например, можно проверить, защищена ли система от SQL–инъекций. Злоумышленник указывает специальные SQL–запросы, которые позволяют взломать систему.

Удобство использования.

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

Проверка производительности системы при условии разных параметров.

Предположим, что компания разработала веб–приложение для редактирования фотографий. Тестировщик может проверить эффективность и корректность его работы на разных версиях Windows, Linux или Mac. Если в одной из систем приложение работает некорректно, то его требуется доработать.

Отказоустойчивость.

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

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

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

1 шаг: планирование.

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

2 шаг: подготовка.

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

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

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

3 шаг: реализация.

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

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

4 шаг: проведение анализа.

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

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

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

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

Фреймворки для автоматизации тестирования.

Тестирование является достаточно рутинной деятельностью, которая имеет риски воздействия человеческого фактора. Кроме того, чаще всего это трудозатратно. Систематическое тестирование является трудоемким, поэтому компания стремится использовать инструменты автоматизации. Это позволяет не только сэкономить время проверки, но и снизить риск влияния человеческого фактора. Для этого тестировщики используют такие инструменты, как:

• Selenium

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

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

• Appium

Имеет схожий принцип действия, что и Selenium, но уже рассчитан на мобильные, а не на веб–приложения. Этот фреймворк отличается тем, что позволяет написать один и тот же скрипт тестирования как для системы Android, так и для системы iOS.

Инструменты для нагрузочного тестирования и проверки производительности.

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

• Apache JMeter

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

• LoadRunner

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

Инструменты генерации тестовых данных.

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

• Mockaroo

С его помощью тестировщик может создать случайные имена пользователей, их адреса, электронную почту, числа и даты. Также инструмент может генерировать данные в различных форматах: CSV, JSON, SQL, XML. Для тестировщиков это открывает возможность применять сгенерированные данные в различных типах проверок или осуществить их интеграцию в другие системы. Кроме того, Mockaroo дает возможность создавать настраиваемые схемы данных, в которых существуют определенные заданные правила и ограничения. Также данный инструмент позволяет генерировать данные, имеющие специфические требования или тестовые сценарии.

• Faker

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

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

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

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