В этой статье мы рассмотрим практические примеры применения регрессионного тестирования. Но прежде чем перейти к ним, освежим ваше понимание или познакомим вас с тем, что представляет собой регрессионное тестирование и почему оно играет ключевую роль. После этого мы разберём несколько конкретных примеров.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Содержание:
- Что такое регрессионное тестирование?
- Когда необходимо регрессионное тестирование?
- Как проводится регрессионное тестирование?
- Пример регрессионного тестирования
- Заключение
1. Что такое регрессионное тестирование?
В процессе разработки программного обеспечения часто вносятся изменения в код, и предсказать их влияние на связанные функции бывает сложно. Чтобы справиться с этой непредсказуемостью и гарантировать высокое качество продукта, регрессионное тестирование должно стать неотъемлемой частью жизненного цикла сборки ПО.
Например, продукт X обладает функцией, которая запускает цепочку событий: проверку, подтверждение и отправку автоматических писем при нажатии на определённые кнопки. Допустим, была обнаружена проблема в процессе отправки писем. Для её исправления разработчики вносят небольшие изменения в код. Хотя изменения касаются только функциональности отправки писем, регрессионное тестирование не ограничится проверкой этого участка. Важно также протестировать процессы проверки и подтверждения, чтобы убедиться, что изменения не вызвали неполадок в других частях системы, даже самых незначительных.
При этом для выполнения регрессионного тестирования не требуется знание сложных языков программирования, таких как Java или Python. Этот тип тестирования позволяет убедиться, что внесённые изменения не повлияли на другие, связанные компоненты программы. Тестирование считается успешным, если все выявленные ошибки исправлены, а остальная часть системы работает корректно.
Каждая новая сборка проходит функциональное тестирование, где проверяется как новый, так и существующий функционал. Это необходимо для того, чтобы убедиться, что все части программы взаимодействуют между собой без сбоев. Кроме того, старые функции проверяются на предмет стабильной работы, что подтверждает отсутствие нарушений в ранее исправленных или протестированных модулях.
Таким образом, регрессионное тестирование представляет собой набор тестов, направленных на выявление дефектов в уже проверенных участках системы, чтобы гарантировать их стабильную работу после изменений.
2. Когда необходимо регрессионное тестирование?
Регрессионное тестирование необходимо проводить всякий раз, когда в спецификации или структуре кода системы вносятся изменения. Этот процесс включает серию тестов, цель которых — убедиться, что внесённые модификации не оказали негативного влияния на связанные и несвязанные компоненты программного обеспечения.
3. Как проводится регрессионное тестирование?
При проведении регрессионного тестирования необходимо соблюдать несколько важных условий.
Во-первых, должны быть подготовлены отчеты о неполадках в коде. Когда эти отчеты подтверждаются и проблемный участок кода выявлен, он проходит анализ для выяснения причин и природы ошибки. Следующим шагом становится внесение необходимых исправлений в затронутые области. После устранения всех проблем тестировщики приступают к выполнению регрессионного тестирования. Для этого выбираются тесты, входящие в регрессионный набор.
Тесты в этом случае делятся на две категории:
- Тесты для проверки всех изменённых участков кода.
- Тесты для проверки тех областей, которые, вероятнее всего, могли пострадать из-за этих изменений.
Примечание редакции: вас также может заинтересовать статья 7 лучших практик регрессионного тестирования
4. Пример регрессионного тестирования
Рассмотрим пример, как регрессионное тестирование проводится в проекте по разработке программного обеспечения для обработки изображений. Этот пример основан на реальной ситуации и покажет, как можно использовать как ручное, так и автоматизированное регрессионное тестирование.
Прежде чем углубиться в детали, давайте рассмотрим несколько повседневных примеров различных методов регрессионного тестирования и их ключевых задач:
- Регрессия багов (Bug Regression): В этом случае повторно тестируются проблемы, которые были отмечены разработчиками как исправленные.
- Проверка старых исправлений (Old fix method): Перепроверяются все ранее исправленные ошибки и баги, чтобы убедиться, что эти области остались неизменными. В этом заключалась изначальная идея регрессионного тестирования.
- Проверка перехода (Conversion/Port method): Программа переносится на другую платформу. Регрессионное тестирование проводится для проверки успешной интеграции программы на новой платформе. Основные изменения касаются новой среды.
- Проверка конфигурации (Configuration method): В этом случае используется более поздняя модель приложения или устройства, и программа запускается в этой новой среде. Этот метод похож на тестирование перехода на другую платформу, но в данном случае код и платформа остаются прежними, изменяется лишь среда и некоторые модули.
- Проверка общей функциональности (General Functional method): Тут проводится повторное тестирование в большем масштабе. Проверяются все области, включая те, которые ранее работали правильно, чтобы убедиться, что новые изменения не нарушили их работу. Это одна из целей автоматизированного регрессионного тестирования.
- Верификация сборки (Build Verification): Этот метод является неотъемлемой частью регрессионного тестирования, так же как и частью жизненного цикла тестирования любого программного обеспечения. Для того, чтобы новый билд прошёл этот метод, не требуется большого количества тест-кейсов или сложных наборов тестов. Обычно билд проверяется вручную на наличие явных ошибок или неисправностей, чтобы определить, стоит ли его вообще тестировать, и правильно ли интегрированы все изменения. Если билд не проходит smoke test (первичную проверку), его полностью отклоняют, а не возвращают на доработку с отчётами об ошибках.
- Проверка локализации (Localization method): Программа адаптируется к использованию на другом языке и с учётом другой культуры. Это требует множества тестов, включая как старые, так и новые, так как большинство старых тестов будут изменены для работы в новой языковой среде.
Регрессионное тестирование не только выявляет скрытые проблемы, но и может сочетаться с другими методами тестирования, так как любой тест может быть использован повторно. Таким образом, любой тест может стать регрессионным.
Теперь перейдём к примерам реального проекта.
Пример ручного регрессионного тестирования
Рассмотрим, как проводилось регрессионное тестирование на проекте по разработке программного обеспечения для обработки изображений.
На этом проекте регрессионное тестирование выполнялось вручную после каждой итерации разработки. Таким образом процесс зависел от уже выполненных тестовых случаев и проводился на протяжении всего проекта. Команда регулярно запускала определённый набор тестов, включавший более 150 тест-кейсов. Эти тесты периодически пересматривались, чтобы исключить устаревшие случаи и актуализировать существующие.
Такой подход позволял команде поддерживать сбалансированный набор тестов в диапазоне от 150 до 200 кейсов, что помогало избегать хаоса и избыточности в тестировании.
В итоге периодические регрессионные тесты выявили, что опции галереи изображений часто подвергались изменениям. При каждом изменении зависимые функции выходили из строя и начинали работать некорректно.
Описание проекта №1
Этот проект был посвящён разработке приложения для захвата и обработки изображений на последней версии Android, созданного для технологической компании, специализирующейся на цифровой обработке изображений, таких как сохранение, отображение и печать.
Приложение уже было интегрировано с фирменной камерой, что значительно улучшало качество снимков, позволяя владельцам совместимых Android-устройств делать фотографии в высоком разрешении. Команда проекта регулярно проводила общие стендапы, чтобы отслеживать прогресс.
Проект длился около трёх лет и включал от 5 до 15 специалистов на разных этапах разработки. В частности, на проекте работало до пяти тестировщиков, которые занимались проверкой качества продукта.
Пример автоматизированного регрессионного тестирования
Автоматизированное тестирование, безусловно, является самым быстрым способом выявления большого количества неисправностей, позволяя проводить множество тестов за короткий промежуток времени. Это значительно ускоряет процесс подготовки продукта к развертыванию и выпуску.
В следующем проекте автоматизация тестовых наборов сэкономила много времени, затрачиваемого на повторение тестов. В результате были выявлены проблемы, которые не обнаружились во время ручного тестирования. Эти недостатки были найдены на этапе автоматизации благодаря характерным для данного типа тестов интервалам ожидания. Если тест не проходит в установленный срок, он считается неуспешным и повторяется до тех пор, пока не будет выполнен успешно.
Хотя это может показаться утомительным, такой подход является единственным эффективным способом выявления редких проблем. Если не обнаружить проблему сразу, она, скорее всего, останется незамеченной при ручном тестировании, так как ни один тестировщик не станет бесконечно повторять тест-кейсы вручную.
Описание проекта №2
Как уже было сказано, регрессионные тесты могут выполняться между сборками и различными версиями релиза. В этом примере рассмотрим, как тест-кейсы выполняются на трёх разных сборках одного и того же программного обеспечения (Сборка №1, №2 и №3), которые работают в разных средах.
Сборка №1
Сначала необходимо определить все требования к сборке, после чего команда проекта приступает к разработке структуры и макета.
Когда структура готова, команда QA начинает работать над тестами. Предположим, что их около 1000, чтобы обеспечить эффективное и тщательное тестирование программного обеспечения.
После завершения написания тестов начинается тестирование самого программного обеспечения. Если все запланированные тесты проходят успешно, продукт передаётся клиенту для заключительного этапа, который обычно называется приемочным тестированием. Если эта последняя стадия тестирования проходит удачно, продукт разворачивается в производство.
2-я сборка
После успешного завершения первой сборки клиент решил добавить несколько дополнительных функций и предоставил все необходимые требования и ресурсы. Команда проекта начала работу, а команда QA параллельно приступила к созданию тестов для этих новых функций. На этот раз они разработали 200 новых тестов, доведя общее количество до 1200 тестов для обеих версий.
Затем команда QA запустила тесты на новой сборке и одновременно проверила старые компоненты с помощью ранее созданных 1000 тестов. Это ключевой момент, поскольку важно убедиться, что новые функции не нарушили работу существующих, что и является сутью регрессионного тестирования.
После завершения обоих этапов тестирования продукт снова был передан клиенту для обязательного приемочного тестирования. Как и прежде, успешное прохождение этой стадии позволяет развернуть новую сборку в производственной среде.
Этот сценарий наглядно показывает, как можно эффективно управлять регрессионным тестированием, особенно при добавлении новых функций, что важно учитывать в проектах с долгосрочной перспективой.
3-я сборка
Несмотря на удовлетворённость второй сборкой, клиент, решает убрать одну из функций, например, “Рекламу”. После принятия этого решения и удаления функции следующий шаг — исключить все тест-кейсы, связанные с рекламой. В данном случае оказалось 100 таких тестов. После этого команда QA выполняет оставшиеся тесты, чтобы убедиться, что все другие функции продолжают работать исправно после удаления рекламы. Эта процедура также классифицируется как регрессионное тестирование.
Заключение
В этой статье мы рассмотрели примеры регрессионного тестирования, которые могут послужить отличной основой для вашего обучения. Они способны вдохновить вас на внедрение подобных практик в вашем проекте, однако важно помнить, что в тестировании программного обеспечения не существует универсального решения. Главное — выбирать подходы, которые помогают поддерживать стабильность системы.
Многие компании совмещают автоматизированное и ручное тестирование, чтобы охватить все аспекты работы продукта и соответствовать требованиям проекта. Не стоит забывать, что ваш выбор должен основываться на потребностях пользователей, особенностях вашей ниши, а также на бюджете и доступных ресурсах. Следите за современными трендами в тестировании и используйте эти знания для разработки эффективной стратегии.
Перевод статьи «7 Applicable Regression Testing Examples».