Мы используем куки, чтобы пользоваться сайтом
было удобно.
Тестирование (testing) программного обеспечения – это процесс исследования ПО с целью выявления ошибок и определения соответствия между реальным и ожидаемым поведением ПО, осуществляемый на основе набора тестов, выбранных определённым образом. В более широком смысле тестирование ПО – это техника контроля качества программного продукта, включающая в себя проектирование тестов, выполнение тестирования и анализ полученных результатов.
Тестирование – важный этап процесса разработки ПО, потому что с его помощью в той или иной мере обеспечивается безопасность, надёжность и удобство создаваемого продукта. В настоящее время существует множество подходов и методик к решению задачи тестирования ПО, но эффективное тестирование сложных программных систем — процесс творческий, не сводящийся к следованию строгим и чётким правилам.
Опишем основные этапы тестирования ПО с точки зрения STLC (software testing life cycle):
Модульное тестирование – это процесс исследования ПО, при котором тестируется минимально возможный компонент, например отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.
Ссылки:
Интеграционное тестирование – это процесс исследования ПО, при котором тестируются интерфейсы между компонентами или подсистемами.
Ссылки:
Системное тестирование – это процесс исследования ПО, при котором тестируется интегрированная система на её соответствие требованиям заказчика. Альфа- и бета-тестирование относятся к подкатегориям системного тестирования.
Ссылки:
Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие.
Функциональное тестирование (functional testing) – тестирование ПО, направленное на проверку реализуемости функциональных требований. При функциональном тестировании проверяется способность ПО правильно решать задачи, необходимые пользователям.
Ссылки:
Тестирование производительности (performance testing) – тестирование ПО, позволяющее осуществлять оценку быстродействия программного продукта при определённой нагрузке. Тест производительности выполняется до и после проведения оптимизации с целью выявить изменения в производительности. Если оптимизация не удаётся и производительность снижается, то программист может отказаться от неудачной оптимизации. В случае повышения производительности величину этого повышения можно сравнить с ожидаемыми результатами, чтобы убедиться в успешности оптимизации. Задачей теста производительности является выявление фактов повышения и понижения производительности для обнаружения неудачных оптимизаций.
Ссылки:
Нагрузочное тестирование (load testing) – тестирование ПО, позволяющее осуществлять оценку быстродействия программного продукта при плановых, повышенных и пиковых нагрузках. Осуществление нагрузочного тестирования перед вводом системы в промышленную эксплуатацию позволяет избегать неожиданных потерь в производительности через полгода—год, когда система будет заполнена данными.
Ссылки:
Стресс-тестирование (stress testing) – тестирование ПО, которое оценивает надёжность и устойчивость системы в условиях превышения пределов нормального функционирования. Это проверка программы в таких стрессовых ситуациях как наличие большого объёма входных параметров, нехватка дискового пространства или маломощный процессор.
Стресс-тестирование предназначено для проверки настроенного решения и серверной группы на одновременное обслуживание большого количества пользователей. При таком тестировании проверяется не только серверная группа, но и влияние, оказываемое настройками на производительность системы в целом и её отказоустойчивость. Для проведения такого тестирования необходимо иметь набор компьютеров, эмулирующих работу групп пользователей.
Ссылки:
Тестирование стабильности (stability/endurance/soak testing) – тестирование ПО, при котором проверяется работоспособность системы при длительном тестировании со средним уровнем нагрузки.
Ссылки:
Тестирование совместимости (compatibility testing) — тестирование ПО, которое проверяет работоспособность системы в определённом окружении.
Ссылки:
Тестирование безопасности (security testing) – тестирование ПО, которое проверяет фактическую реакцию встроенных в систему защитных механизмов на проникновение злоумышленников.
Ссылки:
Тестирование на проникновение (penetration testing) – тестирование, при котором симулируется реальная атака на систему. Эта симуляция позволяет оценить способность имеющихся средств безопасности противостоять угрозе со стороны злоумышленника. Также тестирование на проникновение позволяет обнаружить уязвимости нулевого дня.
Ссылки:
Тестирование безопасности веб-приложений (web application security testing) – тестирование, направленное на обнаружение системных уязвимостей, а также поиск возможностей их использования. Оно включает в себя и оценку риска возникновения уязвимостей в веб-приложении.
Развитие различных стандартов обеспечения безопасности веб-приложений во многом опирается на комьюнити и открытые проекты. Так, например, открытый проект обеспечения безопасности веб-приложений (OWASP) разработал стандарт OWASP ASVS.
Стандарт описывает основу для тестирования технических средств контроля безопасности веб-приложений, которые используются для защиты от уязвимостей, таких как межсайтовый скриптинг (XSS) и SQL-инъекции.
Ссылки:
Тестирование безопасности API (API security testing) – тестирование ПО, позволяющее выявить уязвимости программного интерфейса приложения и веб-служб. Тестирование безопасности API применяется для предотвращения несанкционированного доступа и злоупотребления программным интерфейсом. API-интерфейсы особенно уязвимы для таких угроз, как атаки "человек посередине" (MITM), инъекции API и отказ в обслуживании (DoS).
Ссылки:
Тестирование безопасности приложения (application security testing) – группа методов тестирования, которые используются для поиска и устранения уязвимостей в программных приложениях. Эти методы включают тестирование, анализ и отчётность о состоянии безопасности программного приложения на протяжении всего жизненного цикла разработки программного обеспечения (SSDLC).
Ссылки:
Статическое тестирование безопасности приложений (SAST) – тестирование исходного кода ПО средствами статического анализатора с целью обнаружения участков кода, содержащих потенциальные уязвимости.
Ссылки:
Динамическое тестирование безопасности приложений (DAST) – тестирование ПО средствами динамического анализатора с целью обнаружить потенциальные уязвимости времени исполнения. Оно может включать поиск проблем с использованием скриптов, утечкой памяти, обработкой файлов cookie, аутентификацией, выполнением сторонних компонентов.
Ссылки:
Интерактивное тестирование безопасности приложений (IAST) – тестирование ПО, состоящее в обнаружении проблем безопасности в режиме реального времени, анализируя исходный код, поток данных, конфигурацию и сторонние библиотеки. IAST также подходит для тестирования API.
Ссылки:
Тестирование безопасности мобильных приложений (MAST) – методология тестирования, объединяющая статический анализ, динамический анализ и исследование данных, генерируемых мобильными приложениями. Таким образом обеспечивается комплексное тестирование системы безопасности, а также решаются проблемы, связанные со спецификой мобильных платформ. Например, обнаруживаются jailbreaking, вредоносные сети Wi-Fi и утечки данных с мобильных устройств.
Ссылки:
Анализ компонентного состава программного обеспечения (SCA) – анализ состава приложения, идентифицирующий зависимости. Целью анализа является оценка безопасности используемых зависимостей и определение их соответствия лицензиям.
Ссылки:
Тестирование чёрного ящика (black box) — тестирование ПО, при котором тестировщик имеет доступ к ПО только через интерфейсы заказчика либо через внешние интерфейсы, позволяющие другому компьютеру или процессу подключаться к системе для тестирования. Этот подход до сих пор является самым распространённым в повседневной практике, но у него есть ряд недостатков. Например, некоторые ошибки возникают достаточно редко и потому их трудно найти и воспроизвести.
Ссылки:
Тестирование белого ящика (white box) — тестирование ПО, при котором тестировщик имеет доступ к исходному коду программы и может писать код, связанный с библиотеками тестируемого ПО. К тестированию белого ящика относят методики: чтения программ, формальные просмотры программ, инспекции. Этот метод позволяет заглянуть внутрь "чёрного ящика" и сосредоточиться на внутренней информации, которая и определяет поведение программы. Основной трудностью является сложность отслеживания вычислений времени выполнения. При тестировании программы происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведёт к перебору всех возможных путей. Даже для средних по сложности программ число таких путей может достигать десяток тысяч.
Ссылки:
Альфа-тестирование – это процесс имитации реальной работы разработчиков с программным продуктом или реальная работа потенциальных пользователей с системой.
Ссылки:
Бета-тестирование – это распространение версий с ограничениями для некоторой группы лиц с целью проверки содержания допустимо минимального количества ошибок в программном продукте.
Ссылки:
Регрессионное тестирование (regression testing) – тестирование ПО, при котором проводится проверка ранее найденных ошибок, а также проверка основной функциональности. Проводится, как правило, на каждой новой версии программного продукта. Регрессионное тестирование является наиболее важной фазой тестирования непосредственно перед окончанием работ над продуктом, так как непосредственно перед релизом продукта крайне необходимо проверить не только основную функциональность, но и то, что ни одна из ранее найденных ошибок не повторяется в финальной версии. Являясь неотъемлемой частью функционального тестирования, регрессионное тестирование позволяет гарантировать, что изменения, связанные с устранением дефектов, не оказали негативного воздействия на остальные функциональные области приложения.
Ссылки:
Дымовое тестирование (smoke testing) — тестирование ПО, при котором выполняется набор тестов, после которого можно сказать, что программный продукт запускается. Если ошибок при запуске не происходит, то дымовой тест считается пройденным. Если программа не прошла дымовой тест, то её отправляют на доработку. Дело в том, что разработчики пишут различные компоненты приложения отдельно. После объединения компонентов может случиться так, что совместно они работать не cмогут. В таком случае нет смысла тестировать продукт в целом.
Ссылки:
Ручное тестирование (manual testing) – тестирование, при котором не используются программные средства для выполнения тестов и проверки результатов выполнения.
Ссылки:
Автоматизированное тестирование (automated testing) – тестирование, при котором используются программные средства для выполнения тестов и проверки результатов выполнения. Автоматизированное тестирование несомненно приносит пользу и экономит время и ресурсы компании.
В процессе разработки часто бывает так, что новая версия с исправленными ошибками выпускается каждый день, а иногда и несколько раз в день. В таком случае в первую очередь стоит автоматизировать дымовое тестирование. Это поможет убедиться в том, что программа запускается после сборки новой версии. Автоматический тест справится с подобной задачей за считанные секунды, и сборку можно будет считать успешной. Если же этим будет заниматься человек, то времени на проверку будет уходить гораздо больше. Таким образом, автоматизация дымового тестирования – это неплохая экономия времени отдела тестирования.
Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них: HP LoadRunner, HP QuickTest Professional, HP Quality Center, TestComplete.
Автоматизация в целом не только экономит время на разработку, но и увеличивает надёжность и безопасность создаваемых продуктов. Очевидны также преимущества для тестировщиков: надёжность проверки продукта возрастает, время на тестирование сокращается, работа тестирующего становится менее стрессовой. Конечно, автоматические тесты не могут полностью заменить ручное тестирование, но могут облегчить работу инженера-тестировщика ПО.
Ссылки:
По мере продвижения проекта стоимость устранения дефектов ПО может экспоненциально возрастать. Инструменты статического и динамического анализа помогают предотвратить эти затраты благодаря обнаружению программных ошибок на ранних этапах жизненного цикла ПО.
Динамический анализ кода (runtime analysis) – способ анализа программы непосредственно при её выполнении. При динамическом анализе проблемы в исходном коде находятся по мере их возникновения. Процесс анализа можно разбить на несколько этапов: подготовка исходных данных, проведение тестового запуска программы, сбор необходимых параметров и анализ полученных данных.
Ссылки:
Статический анализ кода (static analysis) — анализ программы, производимый без реального выполнения исследуемых программ. Статический анализ кода позволяет обнаружить дефекты в исходном коде до того, как код будет готов для запуска.
На практике разработчики могут использовать как статический, так и динамический анализ для ускорения процессов разработки и тестирования, а также для повышения качества исходного продукта.
Ссылки:
0
0
0
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте, отфильтровано ли письмо в одну из следующих стандартных папок:
0