Какие виды тестирования бывают в программировании

Виды Тестирования Программного Обеспечения

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

1. Функциональные
2. Нефункциональные
3. Связанные с изменениями

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

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов:

• Функциональное тестирование (Functional testing)
• Тестирование безопасности (Security and Access Control Testing)
• Тестирование взаимодействия (Interoperability Testing)

Нефункциональные виды тестирования

Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, «Как» система работает. Далее перечислены основные виды нефункциональных тестов:

• Все виды тестирования производительности:
  • нагрузочное тестирование (Performance and Load Testing)
  • стрессовое тестирование (Stress Testing)
  • тестирование стабильности или надежности (Stability / Reliability Testing)
  • объемное тестирование (Volume Testing)

  Связанные с изменениями виды тестирования

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

  • Дымовое тестирование (Smoke Testing)
  • Регрессионное тестирование (Regression Testing)
  • Тестирование сборки (Build Verification Test)
  • Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

  ОБРАТНАЯ СВЯЗЬ:

  Задать вопрос

  Сообщить об ошибке

  Публикация материалов

  Обмен ссылками

  Какие бывают этапы и виды тестирования: подробный разбор

  

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

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

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

  Почему важно тестировать программы

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

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

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

  Инженер по тестированию — с нуля до трудоустройства за 4 месяца

  • Постоянная поддержка от наставника и учебного центра
  • Помощь с трудоустройством
  • Готовое портфолио к концу обучения
  • Практика с первого урока

  Вы получите именно те инструменты и навыки, которые позволят вам найти работу

  Какие бывают этапы тестирования

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

  Проработка требований к продукту

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

  Анализ требований

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

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

  Когда все требования к продукту понятны, остается разработать план тестирования. В него входит:

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

  Читайте также: Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько зарабатывает и что надо знать

  Создание тестовой документации

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

  Тестирование

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

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

  Эксплуатация и поддержка

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

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

  Читайте также: Какие навыки нужны тестировщику и как им стать

  Какие бывают виды тестирования

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

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

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

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

  По характеру сценариев

  Сценарий в тестировании — это описание того, как пользователь будет взаимодействовать с готовым продуктом. В эту группу входят два вида тестирования: позитивных сценариев и негативных.

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

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

  

  По критериям запуска программы или кода

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

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

  

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

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

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

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

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

  Эти сценарии запускаются на специальных инструментах для автоматизации тестирования, которые эмулируют действия пользователя и анализируют результаты выполнения.

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

  

  По объектам тестирования

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

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

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

  Функциональное тестирование делится на подвиды:

  • Unit-тестирование (также модульное тестирование) — проводится во время создания исходного кода. На этом этапе тестируются отдельные компоненты приложения. Тестировщики пишут тесты, чтобы убедиться, что каждый компонент будущей программы работоспособен и дает правильные результаты при различных входных данных.
  • Интеграционное тестирование. На следующем этапе тестируется то, как компоненты будущего приложения взаимодействуют между собой.
  • Системное тестирование (End-to-end тестирование). На этом этапе специалисты тестируют все компоненты программы как единое приложение. Тестировщики проверяют, что продукт корректно обрабатывает различные сценарии и ситуации.
  • Приемочное тестирование. На последнем этапе продукт тестирует уже клиент или заказчик. Они проверяют, соответствует ли проект их ожиданиям и требованиям. А еще убеждаются, что программа дает правильные результаты и работает без ошибок.

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

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

  Читайте также: Я знал, что быть тестировщиком — мое призвание: история Кирилла Куртова

  Нефункциональное тестирование делится на подвиды:

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

  

  По степени знания системы

  Эта группа объединяет в себе виды, которые используются в зависимости от этого, насколько тестировщик знаком с тестируемым продуктом.

  Тестирование «черного ящика» — это способ проверки программного обеспечения, когда тестировщик не знает внутренней структуры или деталей работы самой программы. Он смотрит на нее как на «черный ящик», и проверяет, как система взаимодействует с внешним миром и выполняет свои функции.

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

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

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

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

  Этот подход позволяет объединить преимущества обоих типов тестирования и обеспечить более полное и всестороннее тестирование программного обеспечения.

  Под группу «по степени знания системы» также подходит еще несколько видов тестирования:

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

  

  По времени проведения тестирования

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

  1. Альфа-тестирование — это этап тестирования программного обеспечения, который происходит перед его официальным выпуском и предполагает проверку продукта внутри компании-разработчика или ограниченной группой тестировщиков. Альфа-тестирование помогает выявить возможные проблемы и ошибки перед предоставлением продукта пользователю.
  2. Дымовое тестирование — это быстрая проверка программного обеспечения, которую выполняют после внесения значительных изменений или обновлений в код. Этот вид тестирования напоминает «пробный пуск» программы, чтобы убедиться, что основные функции работают без критических ошибок.
  3. Если после дымового тестирования в продукт добавляют какую-то фичу или просто хотят убедиться, что все предыдущие функции работают правильно, то проводят регрессионное тестирование. Тестировщики убеждаются, что новая функция работает правильно и выполняет свои задачи так, как ожидается, а все остальное не вызывает новых ошибок.
  4. Приемочное тестирование выполняют представители заказчика, чтобы удостовериться, что продукт вышел качественным, и что за него можно заплатить деньги. Чтобы успешно пройти приемочное тестирование, обычно нужно просто выполнить тесты, которые доказывают соответствие программы требованиям.
  5. И последний этап — бета-тестирование. Тестировщики предоставляют готовую программу ограниченной группе реальных пользователей, которые могут сами с ней повзаимодействовать. Юзеры выявляют дополнительные проблемы, получить обратную связь от пользователей и улучшить программу перед ее окончательным выпуском для широкой аудитории.

  

  Итог

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

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

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

  1. По характеру сценариев: тестирование позитивных сценариев, тестирование негативных сценариев.
  2. По критериям запуска программы или кода: статическое тестирование, динамическое тестирование.
  3. По степени автоматизации тестирования: ручное тестирование, автоматизированное тестирование.
  4. По объектам тестирования: функциональное тестирование (куда входит unit-тестирование, интеграционное тестирование, системное тестирование, приемочное тестирование и тестирование интерфейса пользователя) и нефункциональное тестирование (куда входит нагрузочное тестирование, тестирование на проникновение, тестирование совместимости, стресс-тестирование, тестирование на отказоустойчивость, тестирование на восстановление).
  5. По степени знания системы: тестирование «черного ящика», тестирование «белого ящика», тестирование «серого ящика», тестирование по документации (или формальное тестирование) и интуитивное тестирование.
  6. По времени проведения тестирования: альфа-тестирование, дымовое тестирование, регрессионное тестирование, приемочное тестирование, бета-тестирование.

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

  Профессия «Инженер по тестированию»

  • Смените профессию за 4 месяца — короткий путь в IT
  • Познакомьтесь с этапами разработки и жизненным циклом ПО
  • Узнайте всё о техниках тест-дизайна
  • Разберитесь с системами управления тестированием и системами баг-трекинга
  • Научитесь работать с API и базами данных

  Блочное тестирование

  Блочное (модульное, unit testing) тестирование наиболее понятное для программиста. Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.

  Не всякий класс легко покрыть unit тестами. При проектировании нужно учитывать возможность тестируемости и зависимости класса делать явными. Чтобы гарантировать тестируемость можно применять TDD методологию, которая предписывает сначала писать тест, а потом код реализации тестируемого метода. Тогда архитектура получается тестируемой. Распутывание зависимостей можно осуществить с помощью Dependency Injection. Тогда каждой зависимости явно сопоставляется интерфейс и явно определяется как инжектируется зависимость — в конструктор, в свойство или в метод.

  Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks. Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемое поведение.

  По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears, в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.

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

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

  Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент — это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.

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

  Хорошая статья по интеграционному тестированию мне попалась лишь однажды — Scenario Driven Tests. Прочтя ее и книгу Ayende по DSL DSLs in Boo, Domain-Specific Languages in .NET у меня появилась идея как все-таки устроить интеграционное тестирование.

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

  1) Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами:

  $SectionNames = Введение, Текст статьи, Заключение, Литература

  2) Другой пример. При конвертировании нужно разбивать геометрические фигуры на примитивы. Разбиение считается удачным, если в сумме все примитивы полностью покрывают оригинальную фигуру. Из присланных документов выберем различные фигуры и для них напишем свои спецификации. Факт покрываемости фигуры примитивами можно отразить так:

  Понятно, что для проверки подобных спецификаций потребуется движок, который бы считывал спецификации и проверял их соответствие поведению программы. Я такой движок написал и остался доволен данным подходом. Скоро выложу движок в Open Source. (UPD: Выложил)

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

  Системное тестирование

  Системное — это тестирование программы в целом. Для небольших проектов это, как правило, ручное тестирование — запустил, пощелкал, убедился, что (не) работает. Можно автоматизировать. К автоматизации есть два подхода.

  Первый подход — это использовать вариацию MVC паттерна — Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.

  Второй подход — использовать специальные инструменты для записи действий пользователя. То есть в итоге запускается сама программа, но щелканье по кнопкам осуществляется автоматически. Для .NET примером такого инструмента является White библиотека. Поддерживаются WinForms, WPF и еще несколько GUI платформ. Правило такое — на каждый use case пишется по скрипту, который описывает действия пользователя. Если все use case покрыты и тесты проходят, то можно сдавать систему заказчику. Акт сдачи-приемки должен подписать.

  Какие бывают виды тестирования

  Классификации: по запуску кода на исполнение, по доступу к коду и архитектуре и другие.

  

  Анастасия Хамидулина
  Автор статьи
  8 июля 2022 в 10:58

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

  Этапы тестирования

  Как написать тест-кейс

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

  2️⃣ Планирование тестирования. На этом этапе разрабатывают стратегию, план, тестовый стенд. Это нужно, чтобы упростить работу.

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

  3️⃣ Разработка тестов. Сюда относят создание и описание процедуры тестирования, сценариев, наборов тестовых данных.

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

  5️⃣ Отчеты о тестировании. Создают метрики и составляют окончательные отчеты, готово ли ПО к выпуску.

  6️⃣ Анализ результатов тестирования. Или анализ дефектов, который выполняет команда разработчиков вместе с клиентом. Решают, какие дефекты исправить, а какие — отклонить. Например, потому что поведение ПО на самом деле корректное, то есть ожидаемое.

  7️⃣ Повторное тестирование дефекта. Когда команда разработчиков устраняет дефект, тестировщики проводят повторную проверку.

  8️⃣ Регрессионное тестирование. Обычно для каждой интеграции нового, модифицированного или исправленного ПО создают небольшую тестовую программу. Она состоит из подмножества тестов. Это нужно, чтобы убедиться, что последняя версия ничего не испортила, — программа всё еще работает правильно.

  9️⃣ Завершение теста. К этому этапу переходят, когда решают, что проверка пройдена и поведение ПО соответствует критериям. Архивируют сведения об основных выходных данных, результаты, журналы и документы. Их используют в качестве справочных материалов для будущих проектов.

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

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

  Джефф Каролло
  «Как тестируют в Google»

  Виды тестирования

  �� По запуску кода на исполнение

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

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

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

  �� По доступу к коду и архитектуре

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

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

  Метод «серого ящика». Совокупность двух предыдущих методов. В первом методе тестировщик не смотрит на код, не знает структуру программы, во втором — смотрит и знает. В методе «серого ящика» тестировщик знает только структуры данных приложения. Он пытается составить тестовые наборы так, чтобы выявить ошибки, связанные с неправильным использованием данных или программы.

  Освоить эти и другие методы можно на курсе Skypro «Инженер по тестированию». За 12 месяцев даем всё необходимое для уверенного старта в профессии: навыки ручного и автоматического тестирования, автоматизации, работы с системами баг-трекинга и программирования. Преподаватели — действующие тестировщики, которые дают актуальные знания и навыки, а не сухую теорию. А кураторы и наставники поддерживают и помогают разобраться со сложными темами.

  Инженер-тестировщик: новая работа через 9 месяцев
  Получится, даже если у вас нет опыта в IT

  

  �� По уровню тестирования

  Модульное

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

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

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

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

  Компоненты тестируют по очереди или все вместе. Первый вариант самый удобный: можно быстрее обнаружить и исправить проблемы с интерфейсом.

  Уровень интеграционного тестирования можно разделить на:

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

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

  Системное

  Это тестирование программной системы, чтобы оценить ее по всем требованиям.

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

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

  На уровне системного тестирования иногда используют:

  Monkey-тест

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

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

  Дымовое тестирование, или smoke-тестирование

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

  Дымовое тестирование помогает обнаружить серьезные дефекты на ранних этапах разработки и таким образом сэкономить ресурсы.

  Приемочное

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

  ✅ Пользовательское приемочное тестирование (UAT). Его выполняет клиент, часто на собственном оборудовании. Может быть частью процесса передачи между любыми двумя фазами разработки.

  ✅ Эксплуатационные приемочные испытания (OAT). Их используют, чтобы проверить предварительный выпуск продукта, услуги или системы. OAT — это распространенный тип нефункционального тестирования ПО. Его в основном применяют в проектах разработки и обслуживания программного обеспечения.

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

  �� По методу выполнения тестовых сценариев

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

  Автоматизированное. Специалист использует специальные программы, чтобы пройти сценарии пользователя. Это помогает сократить время тестирования и упростить процесс. Автоматизированное тестирование не воспроизводит всё, что делает человек. Зато полезно для регрессионного тестирования, если набор сценариев разработали правильно.

  На курсе Skypro «Инженер по тестированию» освоите и ручное, и автоматическое тестирование. Если учиться по 10–12 часов в неделю — через 9 месяцев станете уверенным новичком в профессии и сможете найти новую работу. А центр карьеры поможет составить классное резюме и подготовиться к техническому собеседованию.

  Принципы программного тестирования

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

  Выявление дефектов

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

  Исчерпывающее тестирование невозможно

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

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

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

  Раннее тестирование экономит время и деньги

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

  В этом случае тестировщик работает параллельно с разработчиком. К примеру, пока разработчик пишет код первой версии, тестировщик разрабатывает тест-кейсы.

  Тест-кейс — это документ, где специалист прописывает последовательность действий, условия и параметры для проведения тестирования.

  Кластеризация, или скопление дефектов

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

  «Парадокс пестицидов»

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

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

  Тестирование зависит от контекста

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

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

  Заблуждения об отсутствии ошибок

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

  Главное о видах тестирования ПО

  • Тестирование — важная часть процесса разработки программного обеспечения. Основа контроля качества и работоспособности продукта.
  • Это сложный поэтапный процесс. Перед выполнением теста анализируют требования, разрабатывают стратегию тестирования, создают и описывают процедуры.
  • Есть несколько видов тестирования программного обеспечения. Например, статическое — без запуска программы, динамическое — с запуском, пассивное — на основе системных журналов. Без доступа или с доступом к коду — методы «черного и белого ящиков». С программными средствами или без них — ручное и автоматизированное.
  • Чтобы получить хороший результат, специалисты учитывают в своей работе семь основных принципов тестирования: цель тестирования — не отсутствие ошибок, а их проверка и обнаружение; исчерпывающее тестирование невозможно; ранее тестирование экономит время и деньги; принцип скопления дефектов; «парадокс пестицидов»‎; тестирование зависит от контекста и заблуждение об отсутствии ошибок.

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

  Преподаватели — руководители направления тестирования в ВТБ, Skyeng. Дадут актуальные знания и помогут собрать портфолио. В конце получите диплом государственного образца.

  Похожие публикации:

  1. Debug что это за папка
  2. Как включить звук на телефоне
  3. Как закрыть окно qt python
  4. Как посчитать сумму в экселе в столбце