Тестирование программного обеспечения 101: начните с типов тестирования программного обеспечения

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

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

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

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

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

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

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

Без тестирования программного обеспечения во время разработки вы бы знали, работает ли ваше программное обеспечение, только когда оно достигнет конечного пользователя!

Как это работает?

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

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

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

Вот некоторые из преимуществ тестирования программного обеспечения:

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

Тестирование черного ящика против белого ящика

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

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

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

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

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

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

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

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

Автоматизация против ручного тестирования

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

Ручное тестирование:

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

Тестирование автоматизации:

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

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

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

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

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

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

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

Основные функциональные методологии:

• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование
• Приемочное тестирование
• Регрессионное тестирование
• Дымовые испытания

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

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

Давайте подробнее рассмотрим каждый шаг!

Модульное тестирование

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

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

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

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

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

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

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

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

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

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

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

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

Специализированные функциональные методологии

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

Регрессионное тестирование

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

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

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

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

Дымовое испытание

Дымовое тестирование (иногда называемое тестированием на работоспособность) используется для быстрого тестирования только самых важных функций. Эти тесты проверяют простые, но основные функции, такие как «Программа запускается?» или «Интерфейс открывается / закрывается?».

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

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

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

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

Многие нефункциональные методологии пересекаются по фокусу из-за субъективного характера их определения.

Лучшие нефункциональные методики:

• Тестирование производительности
• Тестирование безопасности
• Юзабилити-тестирование
• Тест на совместимость
• Нагрузочное тестирование

Давайте подробнее рассмотрим каждую из этих методологий.

Тестирование производительности

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

Тестирование безопасности

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

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

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

Юзабилити-тестирование

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

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

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

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

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

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

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

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

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

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

Например, представьте, что вы разрабатываете онлайн-видеоигру. Вы можете провести стресс-тест, пригласив в игру одновременно столько игроков, сколько сможете. Затем вы можете записать, как работает сервер (скорость, отклик и т. Д.), А также узнать, когда сервер выходит из строя (точка останова).

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

Жизненный цикл тестирования программного обеспечения

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

Давайте подробнее рассмотрим каждый из этих 6 шагов:

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

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

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

План тестирования

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

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

Разработка тестового случая

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

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

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

Настройка тестовой среды

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

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

Выполнение теста

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

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

Завершение тестового набора и анализ

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

Отсюда вы можете:

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

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

Лучшие практики тестирования программного обеспечения

• Не полагайтесь полностью на автоматическое тестирование. Автоматические тесты ищут только те дефекты, которые программист знает, что искать. Убедитесь, что у вас есть хотя бы один набор ручных тестов для выявления неожиданных дефектов.
• Напишите тестовые примеры на простом языке или псевдокоде вместе с вашим кодом. Ваши менеджеры и новые члены команды будут благодарить вас за то, что вы сэкономили время на синтаксический анализ сценария тестирования.
• Используйте только контролируемые изолированные испытательные среды, чтобы избежать посторонних помех. Использование персонального компьютера или общедоступного облака подвергает ваши тесты ложным переменным, которые могут повлиять на производительность или результат.
• Выберите конкретные и поддающиеся количественной оценке показатели. И для спецификаций, и для тестовых случаев убедитесь, что ваши метрики измеряют только один атрибут и могут отслеживаться численно, чтобы облегчить составление отчетов.
• Тестируйте перед заключительным этапом проверки качества. Это разделяет рабочую нагрузку тестирования на весь процесс и сэкономит вам время, которое часто теряется при ремонте неисправного центрального компонента.
• Сделайте пошаговые тесты. Создайте подусловия в своих тестах, чтобы отслеживать, где программа не проходит в тесте.
• Максимальное тестовое покрытие. Постарайтесь охватить 100% возможных вариантов использования, чтобы подготовить программу к любому входу или среде.
• Попросите членов команды создать тесты для модульного и интеграционного тестирования. Чтобы избежать предвзятости подтверждения, попросите другого разработчика создать тесты для вашей программы. Это хороший прием, когда внешнее тестирование недоступно.
• Используйте понятные названия тестов. Назовите свои тесты после условия или требования, которое они проверяют. Избегайте пустых имен вроде Test1или performanceTestв пользу StressTest_10000user.
• Используйте инструменты тестирования программного обеспечения, такие как Selenium и Reflect. За тестированием бывает сложно следить. Используйте автоматизированные фреймворки / инструменты, чтобы упростить тестирование и сделать их более доступными для всей вашей команды.