Что сначала функциональное или регрессивное тестирование
Перейти к содержимому

Что сначала функциональное или регрессивное тестирование

  • автор:

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

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

  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 и базами данных

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

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

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

    Тестирование ПО — процесс испытания программного продукта с целью проверки соответствия между реальным и ожидаемым поведением программы. Существует несколько видов тестирования. Как правило, выделяют функциональное и нефункциональное.

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

    Функциональное тестирование — вид тестирования, при котором проверяем ЧТО делает программный продукт. Например, проверка API, базы данных, пользовательского интерфейса, функциональности тестируемого продукта. Проверяется на соответствие спецификациям, бизнес-требованиям. Основано на требованиях клиента.

    Нефункциональное тестирование — вид тестирования, при котором проверяется КАК работает программный продукт: производительность, масштабируемость, нагрузка, UX и т.д. Основано на ожиданиях клиента. Пример: авторизация произошла за 2 секунды.

    Отличия функционального и нефункционального тестирований

    При функциональном тестировании:

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

    При нефункциональном тестировании:

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

    Этапы функционального тестирования

    1. Определить и проанализировать, какую функциональность необходимо протестировать. Перед началом необходимо изучить тестируемый функционал: какие у нее требования, как она должна работать, как пользователь будет её использовать.
    2. Написать тест-кейсы. В них тестировщик пошагово описывает сценарий проверки определенной функциональности.
    3. Подготовка тестовых данных. Для тестирования используются данные, которые максимально приближены к тем, что могут использовать пользователи. Сбор тестовых данных основывается на требованиях.
    4. Проведение тестирования. Происходит сравнение фактического результата и ожидаемого.
    5. Составление отчета по результатам тестирования. По завершении тестирования необходимо собрать отчет с результатами прогонки тестов, списком багов и рекомендациями по улучшению продукта.

    Виды тестирования, применяемые при функциональном тестировании

    • модульное тестирование — выполняется разработчиками на этапе разработки приложения. Цель модульного тестирования заключается в проверке работы отдельной функциональности.
    • интеграционное тестирование — проверка того, что модули работают корректно как группа. Тестирование интеграции очень важный этап, так как модули могут быть созданы разными разработчиками.
    • системное тестирование — проводится на полноценной и полностью интегрированной системе для подтверждения, что система работает согласно исходным требованиям.
    • регрессионное тестирование — проводится после того, как в приложение были внесены какие-либо изменения. Этот вид тестирования важно проводить, так как любые изменения могут затронуть или сломать уже существующий функционал.
    • sanity тестирование или санитарное тестирование — очень похоже на регрессионное. Оно проводится, когда тестировщик получает новую сборку с минорными изменениями. Разница между этими двумя видами заключается в том, что если при регрессе мы проводим полное тестирование приложения, то при санити мы тестируем какую-то одну функциональность.
    • smoke-тестирование или дымовое тестирование — проводится для того, чтобы убедиться, что наиболее критичный функционал приложения работает так, как должен.

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

    Системы управления тестированием:

    • TestIT — система управления тестированием, которая была создана тестировщиками для тестировщиков. С её помощью удобно хранить тест-кейсы, составлять тест-планы, создавать прогоны и управлять ими.
    • TestRail — удобно создавать чек-листы, тест-кейсы и прогоны, выгружать результаты прогонов, отчеты о тестировании и сами тест-кейсы в формат CSV. Также сравнивать результаты нескольких прогонов. Он поддерживает интеграцию с различными баг-трекинговыми системами (Jira, YouTrack и т.д.).
    • Allure — с его помощью удобно управлять ручным и автоматизированным тестированием. Легко разрабатывать тест-кейсы и чек-листы, создавать тестовые прогоны и собирать статистику по результатам тестирования.

    Инструменты для работы с БД:

    • DBeaver — универсальный инструмент для управления БД с удобным интерфейсом. С помощью него можно работать с различными СУБД: MySQL, PostgreSQL, SQLite, Oracle и другими.
    • SQL Developer — графический интерфейс для работы с БД и выполнения SQL-запросов. С его помощью можно создавать и выполнять запросы, исследовать базы данных и отслеживать ошибки.
    • HeidiSQL — графическая оболочка для работы с MySQL, PostgreSQL и Microsoft SQL Server. Она может быть использована для создания, изменения и удаления таблиц, вставки и удаления данных, создания SQL-запросов и многого другого.

    Инструменты для тестирования API:

    • Postman — с его помощью можно составлять и отправлять запросы, собирать коллекции и делиться ими с коллегами. Также в Postman можно писать автотесты для тестирования API.
    • SoapUI — с помощью данного инструмента можно легко и удобно тестировать как SOAP, так и REST-сервисы. Можно проверять работоспособность веб-сервисов, устанавливать доступность, работу различных запросов и отслеживать получение ответов.
    • Swagger UI — инструмент для описания и проверки API-методов. К каждому запросу есть пример ответа и описание приходящих в них параметров. Не требует установки на устройство пользователя.
    • Kibana — инструмент визуализации и анализа данных в реальном времени, отслеживания трендов и прогнозирования будущих событий.
    • Graylog — система для сбора, хранения, мониторинга и анализа логов из различных источников в режиме реального времени. Позволяет сохранять большие объемы логов и анализировать их, используя поисковые запросы и фильтры.
    • Android Studio и Xcode — можно собирать логи с мобильных устройств — Android и Xcode соответственно — в режиме реального времени. Удобно собирать, читать и анализировать логи.
    • Android Studio — с помощью инструмента Android Virtual Device Manager можно создавать и управлять виртуальными устройствами с операционной системой Android. При эмуляции устройств есть возможность протестировать приложение в различных состояниях (медленное подключение к интернету, прерывания, маленький объем памяти устройства и т.д.).
    • Xcode — в данном инструменте есть возможность симуляции различных устройств Apple от iPod до Apple TV. В отличии от эмуляции с помощью Android Studio, Apple Simulator имитирует лишь часть функциональности физического устройства.
    • BrowserStack — это сервис для тестирования веб-сайтов и мобильных приложений на различных устройствах и браузерах, без необходимости устанавливать их на локальном компьютере. Он предоставляет обширную коллекцию реальных устройств, операционных систем и браузеров, которые могут быть использованы для тестирования веб-сайтов и мобильных приложений на реальных устройствах в режиме онлайн.

    Можно ли автоматизировать функциональное тестирование и для чего

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

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

    Существует много инструментов для автоматизации функционального тестирования. Про самые популярные мы поговорим ниже:

    • Selenium — один из самых популярных инструментов для автоматизации тестирования веб-приложений. Selenium позволяет работать на различных операционных системах (Windows, Mac, Linux) и браузерах (Chrome, Firefox и т.д), поддерживает различные языки для написания скриптов.
    • Appium — это кроссплатформенный инструмент для автоматизации тестирования мобильных приложений (нативные, гибридные и веб). Позволяет создавать и запускать тесты на реальных устройствах и эмуляторах, использовать различные языки программирования для написания тестов.
    • Katalon Studio — инструмент для автоматизации API, веб, десктоп и мобильных приложений. Для написания тестовых скриптов используется язык программирования Java или Groovy. Плюс данного инструмента — для работы с ним достаточно начальных знаний языков программирования. Благодаря чему он отлично подходит для новичков.
    • Ranorex Studio — еще один универсальный инструмент для автоматизации тестирования. Этот инструмент, как и предыдущий, хорошо подойдет для новичков, так как поддерживает возможность создания тестов без написания кода.

    В заключение

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

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

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

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

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

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

    Black Box

    Summary: Мы не знаем, как устроена тестируемая система.

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

    Согласно ISTQB, тестирование черного ящика – это:

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

    Почему именно «черный ящик»? Тестируемая программа для тестировщика – как черный непрозрачный ящик, содержания которого он не видит. Целью этой техники является поиск ошибок в таких категориях:

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

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

    Пример:

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

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

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

    Техники тест-дизайна, основанные на использовании черного ящика, включают:

    • классы эквивалентности;
    • анализ граничных значений;
    • таблицы решений;
    • диаграммы изменения состояния;
    • тестирование всех пар.

    Преимущества:

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

    Недостатки:

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

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

    White Box

    Summary: Нам известны все детали реализации тестируемой программы.

    Тестирование методом белого ящика (также прозрачного, открытого, стеклянного ящика или же основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации обязательны для этой техники. Тестирование белого ящика – углубление во внутреннее устройство системы за пределы ее внешних интерфейсов.

    Согласно ISTQB: тестирование белого ящика – это:

    • тестирование, основанное на анализе внутренней структуры компонента или системы;
    • тест-дизайн, основанный на технике белого ящика – процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.

    Почему «белый ящик»? Тестируемая программа для тестировщика – прозрачный ящик, содержимое которого он прекрасно видит.

    Пример:

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

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

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

    Преимущества:

    1. тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса;
    2. можно провести более тщательное тестирование с покрытием большого количества путей выполнения программы.

    Недостатки:

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

    Сравнение Black Box и White Box

    Grey Box

    Summary: Нам известны только некоторые особенности реализации тестируемой системы.

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

    Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.

    Пример:

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

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

    Статическое и динамическое тестирование

    По критерию запуска программы (исполняется ли программный код) выделяют еще два типа тестирования: статическое и динамическое.

    1. Статическое тестирование

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

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

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

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

    Виды статического тестирования:

    • вычитка исходного кода программы;
    • проверка требований.

    2. Динамическое тестирование

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

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

    Динамическое тестирование является частью процесса валидации программного обеспечения.

    Кроме того, динамическое тестирование может включать разные подвиды, каждый из которых зависит от:

    • Доступа к коду (тестирование черным, белым и серым ящиками).
    • Уровня тестирования (модульное интеграционное, системное и приемочное тестирование).
    • Сферы использования приложения (функциональное, нагрузочное, тестирование безопасности и пр.).

    Ручное и автоматизированное

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

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

    Мифы о ручном тестировании:

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

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

    Автоматизированное тестирование (automation testing) предполагает использование специального программного обеспечения (помимо тестируемого) для контроля выполнения тестов и сравнения ожидаемого фактического результата работы программы. Этот тип тестирования помогает автоматизировать часто повторяющиеся, но необходимые для максимизации тестового покрытия, задачи.

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

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

    Существует несколько основных видов автоматизированного тестирования:

    • Автоматизация тестирования кода (Code-driven testing) – тестирование на уровне программных модулей, классов и библиотек (фактически, автоматические юнит-тесты).
    • Автоматизация тестирования графического пользовательского интерфейса (Graphical user interface testing) – специальная программа (фреймворк автоматизации тестирования) позволяет генерировать пользовательские события– нажатия клавиш, клики мышкой, и отслеживание реакции программы на эти действия: соответствует ли она спецификации.
    • Автоматизация тестирования API (Application Programming Interface) – тестирование программного интерфейса программы. Тестируются интерфейсы, предназначенные для взаимодействия, например, с другими программами или с пользователем. Здесь, опять же, как правило, используются специальные фреймворки.

    Для составления автоматизированных тестов QA-специалист должен уметь программировать. Автоматические тесты – это полноценные программы, просто предназначенные для тестирования.

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

    Сравнение ручного и автоматизированного тестирования

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

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

    Вручную можно протестировать практически любое приложение, в то время как автоматизировать стоит только стабильные системы .Автоматизированное тестирование используется, главным образом, для регрессии. Кроме того, некоторые виды тестирования, например, ad-hoc или исследовательское тестирование могут быть выполнены только вручную.

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

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

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

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

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

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

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

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

    Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функционтальности компонента или системы в целом.

    1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

    Тестирование функциональности может проводиться в двух аспектах:

    • Требования.
    • Бизнес-процессы.

    Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

    Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

    Преимущества функционального тестирования:

    • имитирует фактическое использование системы.

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

    • возможность упущения логических ошибок в программном обеспечении;
    • вероятность избыточного тестирования.

    Достаточно распространенной является автоматизация функционального тестирования.

    2. Тестирование безопасности (Security and Access Control Testing)

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

    Принципы безопасности программного обеспечения

    Общая стратегия безопасности основывается на трех основных принципах:

    1. Конфиденциальность.
    2. Целостность.
    3. Доступность.
    Конфиденциальность

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

    Целостность

    Существует два основных критерия при определении понятия целостности:

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

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

    3. Тестирование взаимодействия или Interoperability Testing

    Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

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

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

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

    1.Все виды тестирования производительности

    Тестирование производительности ( Performance testing ).

    Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:

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

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

    Объемное тестирование ( Volume Testing )

    Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит:

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

    Тестирование стабильности или надежности( Stability / Reliability Testing)

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

    В англоязычной терминологии вы можете так же найти еще один вид тестирования — Load Testing — тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

    2. Тестирование Установки (Installation Testing)

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

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

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

    В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого часто пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии (в случае неудачи). Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя — это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.

    3. Тестирование удобства пользования (Usability Testing)

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

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

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

    • Производительность, эффективность ( efficiency) — сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д. (меньше — лучше).
    • Правильность ( accuracy) — сколько ошибок сделал пользователь во время работы с приложением (меньше — лучше).
    • Активизация в памяти ( recall ) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя).
    • Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше).
    Уровни проведения

    Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке — тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода и, как следствие, улучшить качество продукта в целом.

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

    Советы по улучшению удобства пользования:
    • Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример: если поле требует цифровое значение,то логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок.
    • Для повышения юзабилити существующих приложений можно использовать цикл Демминга (Plan-Do-Check-Act), собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.
    Заблуждения о тестировании удобства пользования:
    • Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

    • Тестирование удобства пользования можно провести без участия эксперта

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

    4. Тестирование на отказ и восстановление (Failover and Recovery Testing)

    Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).

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

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

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

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

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

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

    • Симулировать внезапный отказ электричества на компьютере (обесточить компьютер).
    • Симулировать потерю связи с сетью (выключить сетевой кабель, обесточить сетевое устройство).
    • Симулировать отказ носителей (обесточить внешний носитель данных).
    • Симулировать ситуацию наличия в системе неверных данных (специальный тестовый набор или база данных).

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

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

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

    5. Конфигурационное тестирование (Configuration Testing)

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

    В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

    • Проект по профилированию работы системы.
      Цель Тестирования: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы.
    • Проект по миграции системы с одной платформы на другую.
      Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.

    Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как тестирование портируемости(portability testing: The process of testing to determine the portability of a software product.).

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

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

    1. Дымовое тестирование (Smoke Testing)

    Понятие дымовое тестирование пошло из инженерной среды:

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

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

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

    Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.

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

    2. Регрессионное тестирование (Regression Testing)

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

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

    Сам по себе термин «регрессионное тестирование», в зависимости от контекста использования, может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования:

    • Регрессия багов (Bug regression) — попытка доказать, что исправленная ошибка на самом деле не исправлена.
    • Регрессия старых багов (Old bugs regression) — попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.
    • Регрессия побочного эффекта (Side effect regression) — попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения.

    3. Тестирование сборки (Build Verification Test)

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

    4. Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

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

    Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

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

    Уровни тестирования программного обеспечения

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

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

    1. Компонентное или Модульное тестирование (Component or Unit Testing)

    Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks — каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов (Bug Tracking System).

    Один из наиболее эффективных подходов к компонентному (модульному) тестированию — это подготовка автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (test-driven development) или подход тестирования вначале (test first approach). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор, пока все тесты не будут успешно пройдены.

    Разница между компонентным и модульным тестированием:

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

    2. Интеграционное тестирование (Integration Testing)

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

    Уровни интеграционного тестирования:

    • Компонентный интеграционный уровень ( Component Integration testing) проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
    • Системный интеграционный уровень (System Integration Testing) — проверяется взаимодействие между разными системами после проведения системного тестирования.

    Подходы к интеграционному тестированию:

    • Снизу вверх (Bottom Up Integration):

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

    • Сверху вниз (Top Down Integration):

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

    • Большой взрыв («Big Bang» Integration):

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

    3. Системное тестирование (System Testing)

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

    Можно выделить два подхода к системному тестированию:

    • на базе требований (requirements based) — для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования.
    • на базе случаев использования (use case based) — на основе представления о способах использования продукта создаются случаи использования системы (Use Cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест-кейсы (test cases), которые должны быть протестированы.

    4. Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing)

    Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing) — формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

    • определения удовлетворения системой приемочным критериям;
    • вынесения решения заказчиком или другим уполномоченным лицом принятия приложения.

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

    • Продукт достиг необходимого уровня качества.
    • Заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

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

    Схема классификации тестирования:Рис. 2.2. Схема, на которой все способы классификации показаны одновременно.

    results matching » «

    No results matching » «

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *