Тестирование
Тестирование (Quality Assurance) предназначено не для поиска или исправления ошибок, а для их предотвращения, профилактики (для выявления несоответствий требованиям и ошибок различного рода).
В идеале, тестеру хорошо бы проверять ТЗ, общий план проекта и бизнес-стратегию на наличие ошибок.
Где-то, например, в программах для медицинской техники или для оборудования космодрома, этот этап работы может стоить кому-то жизни, а государству - пары миллионов долларов убытка.
Принципы деятельности специалистов-тестировщиков регламентированы в таком документе, как ISTQB, и в книге под названием «Foundations of software testing» ("Основы тестирования программного обеспечения").
Что касается организации процесса, то тестирование может проходить в режиме waterfall-подхода. В этом случае тестеры работают в завершающей стадии проекта либо по методологии agile - здесь мы получаем готовую версию после каждой итерации. Собственно итерация процесса тестирования состоит из планирования, условий, определенной истории взаимодействий, документации, многоплановой проверки и завершения с архивацией тестов.
Базовые виды тестов
- модульные (unit-testing) - полуавтоматическое тестирование
- интеграционные (integration testing) - проверяются связи между модулями
- системные (проверка системы в целом)
- приемочные тесты (аcceptance-тесты) - проводится в присутствии клиента при сдаче проекта
На последнем этапе появляются альфа- и бета-версии продукта.
Типы предназначения
- функциональные (что приложение делает) / нефункциональные (как оно это делает)
- внешние (они же black box – тестирование черного ящика) / внутренние (они же структурные или white box – тестирование белого ящика)
- регрессионное тестирование (проверка после внесения изменений)
- тест-поддержка (она же maintenance testing - поддержка обновлений)
- динамические / статические тесты
Популярный мнемонический прием для самоконтроля в работе тестировщиков и составителей ТЗ звучит как «все должно быть SMART»:
- Specific — как можно более точное описание требований
- Measureable — доступная измеримость всех задействованных величин
- Attainable — достижимые с технической точки зрения требования
- Realizeable — практически достижимые требования в отношении трудовых ресурсов
- Traceable — точное соответствие продукта изначальной идее, цели и процесса.
Нагрузочное тестирование принято считать более сложным, но и тут есть более масштабный инструментарий (JMeter, HP LoadRunner (Mercury), IBM Rational Performance Tester, Oracle Application Quality Management) и упрощенный (hammerora, Apache ab, openload, Neoload).
Техники тестирования черного ящика
- метод группировки ошибок по так называемым эквивалентным классам (он же equivalence liartitioning)
- методика boundary value analysis – анализа граничных значений, которая применяется по большей части при целочисленных значениях
- техника проверки перехода состояний (она же state transition testing)
- таблица решений (или decision table testing) - минимизирует количество уникальных комбинаций
- тестирование с применением сценариев (или use-case based)
- интуитивно-опытное тестирование (соответственно, exlierience-based) основано на знании о базовых ошибках;
«случайное» тестирование – методом проб и ошибок (аd-hoc или monkey) - исследовательское тестирование (оно же exliloratory testing).
Unit tests (Модульные тесты)
Каждая сложная программная система состоит из отдельных частей - модулей, выполняющих ту или иную функцию в составе системы. Для того, чтобы удостовериться в корректной работе всей системы, необходимо вначале протестировать каждый модуль системы по отдельности. В случае возникновения проблем при тестировании системы в целом это позволяет проще выявить модули, вызвавшие проблему, и устранить соответствующие дефекты в них. Такое тестирование модулей по отдельности получило называние модульного тестирования.
Модульное тестирование заключается в тестировании отдельных методов/функций классов, компонентов/модулей ПО. Модульные тесты, как правило, довольно дешевы для автоматизации и могут быть запущены очень быстро с помощью сервера непрерывной интеграции. Они разделяются на 2 вида:
- Black box tests - мокаются зависимости класса, метод которого тестируется
- White box tests - мокаются зависимости метода, который тестируется
Integration tests (Интеграционные тесты)
Коротко это: тесты проверяющие правильность работы инфраструктуры.
Интеграционные тесты проверяют, что различные модули или службы, используемые вашим приложением, хорошо работают вместе. Например, это может быть тестирование взаимодействия с базой данных или проверка того, что микросервисы работают вместе, как ожидалось. Эти типы тестов более дороги в выполнении, поскольку они требуют, чтобы работали один или несколько частей приложения (когда сервис с которым тестируется интеграция зависит от другого сервиса, необходима работа сразу нескольких сервисов).
Интеграционные и модульные тесты проверяют поведение отдельных частей сервиса. Интеграционные тесты позволяют убедиться в том, что сервисы могут взаимодействовать со своими клиентами и зависимостями. Модульные тесты подтверждают корректность логики сервиса. Но ни те ни другие не охватывают весь сервис целиком. Чтобы проверить работу всего сервиса, мы продвинемся вверх по пирамиде и посмотрим, как создаются компонентные тесты.
Компонентные тесты
Являются формой приемочного тестирования сервисов. Компонентный тест проверяет работу сервиса в изоляции, используя заглушки вместо его зависимостей. Шаблон «Компонентный тест сервиса» тестирует отдельно взятый сервис.
Представьте, что нужно убедиться в надлежащей работе сервиса. Иными словами, мы хотим написать приемочные тесты, которые работают с сервисом как с единым целым и проверяют его поведение через его API. Для этого можно написать практически сквозные тесты и развернуть сервис Order вместе со всеми его транзитивными зависимостями. Но, как вы уже должны понимать, это медленный, ненадежный и затратный подход.
Компонентное тестирование — гораздо лучший способ написания приемочных тестов для сервисов.
При тестировании зависимости сервиса подменяются заглушками и симулируют их работу. Они могут даже использовать фиктивные версии таких компонентов, как базы данных, размещая их в оперативной памяти.
Сквозные
Коротко это: тесты использующие инфраструктуру (тестирование методом «черного ящика»).
Лучше сделать так, чтобы они были основаны на пользовательских путешествиях, которые описывают перемещения пользователя по системе. Например, проверку создания, пересмотра и отмены заказа можно объединить в один тест. Сквозное тестирование, как и приемочное, сосредоточено на бизнес-аспектах приложения, а значит такие тесты лучше писать на высокоуровневом языке DSL, доступном для понимания людям, которые занимаются бизнес-процессами.
Чтобы провести такое тестирование, нужно развернуть большое количество сервисов, вполне вероятно, что развертывание одного из них окажется неудачным, из-за чего тест окажется ненадежным.
подразделяются на варианты:
- Functional tests (Функциональные тесты)
- Acceptance testing (Приемочное тестирование)
- End-to-end tests (Сквозные тесты)
Рассмотрим их подробнее.
Functional tests (Функциональные тесты)
Проверяют результат действия и не проверяют промежуточные состояния системы при выполнении этого действия.
Иногда возникает путаница между интеграционными тестами и функциональными тестами, поскольку они оба требуют, чтобы несколько компонентов взаимодействовали друг с другом. Разница в том, что интеграционный тест может просто подтвердить, что вы можете запрашивать базу данных, в то время как функциональный тест должен ожидать получения определенного значения из базы данных, как это определено требованиями продукта.
Иногда функциональные тесты бывают двух видов:
- Тестирование «белого ящика» (white box) - тестирование на соответствие требованиям со знанием внутренней реализации системы (есть в наличии исходный код).
- Тестирование «черного ящика» (black box) - тестирование на соответствие требованиям без знания внутренней реализации системы (согласно технической спецификации).
Acceptance testing (Приемочное тестирование)
Коротко это: тесты от лица пользователя (customer-а), один тест может зависеть от другого (сессия пользователя).
Приемочные тесты описывают предпочтительное поведение, которое наблюдают его клиенты, игнорируя внутреннюю реализацию.
Приемочные тесты - это формальные тесты, выполняемые для проверки того, удовлетворяет ли система своим бизнес-требованиям. Эти тесты формируются на основе пользовательских историй или сценариев. Они требуют, чтобы все приложение было запущено и работало и было сосредоточено на воспроизведении поведения пользователя. Но они также могут пойти дальше и измерить производительность системы и отклонить изменения, если определенные цели не достигнуты.
End-to-end tests (Сквозные тесты)
Коротко: более простой вариант Acceptance testing (один тест не зависит от второго теста, но сессия пользователя может использоваться)
Сквозное тестирование воспроизводит поведение пользователя с программным обеспечением в полной среде приложения. Он проверяет, что различные пользовательские потоки работают должным образом и могут быть такими простыми, как загрузка веб-страницы или вход в систему, или гораздо более сложные сценарии проверки уведомлений по электронной почте, онлайн-платежей и т.д.
Сквозные тесты очень полезны, но их сложно выполнять, и их сложно поддерживать, когда они автоматизированы. Рекомендуется провести несколько ключевых сквозных тестов и больше полагаться на типы тестирования более низкого уровня (модульные и интеграционные тесты), чтобы иметь возможность быстро выявлять критические изменения.
Smoke testing (Дымовое тестирование)
Коротко: более простой вариант End-to-end tests (тесты на самый критичный функционал).
Дымовые тесты - это базовые тесты, которые проверяют базовую функциональность приложения. Они предназначены для быстрого выполнения, и их цель - дать вам уверенность в том, что основные функции вашей системы работают должным образом.
Дымовые тесты могут быть полезны сразу после создания новой сборки, чтобы решить, можно ли запускать более дорогие тесты, или сразу после развертывания, чтобы убедиться, что приложение работает правильно в недавно развернутой среде.
Performance testing (Тестирование производительности)
Тесты производительности проверяют поведение системы при значительной нагрузке. Эти тесты нефункциональны и могут иметь различную форму для понимания надежности, стабильности и доступности платформы. Например, это может быть наблюдение за временем отклика при выполнении большого количества запросов или наблюдение за тем, как система ведет себя со значительным объемом данных.
Тесты производительности по своей природе довольно затратны в реализации и выполнении, но они могут помочь вам понять, не приведут ли новые изменения к ухудшению вашей системы.
Обычно бывает двух видов:
- Нагрузочное тестирование (load testing) - тестирование предназначено для проверки работоспособности системы при стандартных нагрузках и для определения максимально возможного пика, при котором система работает правильно.
- Стресс тестирование (stress testing) - тестирование предназначено для проверки работоспособности системы при нестандартных нагрузках и для определения максимально возможного пика, при котором система работает правильно. Так же предназначено для выявления результатов, при которых система переходит в нерабочее состояние.
Regression testing (регрессионное тестирование)
Регрессионное тестирование проводится с целью проверить, не влияют ли новые функции, улучшения и исправленные дефекты на существующую функциональность продукта и не возникают ли старые дефекты.
Mutation Testing (Мутационное тестирование)
Данное тестирование вносит небольшие изменения программы, например измененное поведение определенной функции, в результате такая функция называется Mutant. Чтобы оценить качество существующих тестов, тесты работают с функциям-мутантами, и если тест не упал с ошибкой, то тест плохо написан (ведь Mutant жив). Если мутировавшая программа дает неудачные тесты, это называется убитым мутантом.
Penetration testing (Тестирование на проникновение)
Тестирование на проникновение (penetration testing) является популярным во всем мире способом произвести оценку состояния защищенности сетевого периметра. Суть таких тестов заключается в санкционированной попытке обойти существующий комплекс средств защиты информационной системы. В ходе тестирования специалист по анализу защищенности выполняет роль злоумышленника, мотивированного на нарушение информационной безопасности сети заказчика. Предоставление услуги тестирования на проникновения основывается на методологиях OSSTMM (The Open Source Security Testing Methodology Manual), PTES (The penetration testing execution standard) и включает:
- Пассивный сбор информации;
- Сканирование портов;
- Определение типов и видов сетевого оборудования;
- Определение типов и видов ОС в инфраструктуре сети;
- Определение типов и видов смежной периферии в инфраструктуре сети;
- Определение типов и видов специализированных устройств или их совокупности;
- Сбор баннеров и поиск публичных эксплойтов;
- Сбор и анализ полученной информации;
- Определение "точек входа";
- Описание векторов атаки;
- Попытки эксплуатации;
- Подтверждение полученных векторов;
- Составление отчета.
Usability testing (тестирование удобства)
Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Выявлять проблемы, связанные со специфическим механизмом интерфейса определять, существуют ли проблемы с удобностью интерфейса для навигации, использования основного функционала.
Localization testing (тестирование локализации)
Тестирование локализации - это процесс тестирования локализованной версии программного продукта. Проверка правильности перевода элементов интерфейса пользователя, проверка правильности перевода системных сообщений и ошибок, проверка перевода раздела "Помощь"/"Справка" и сопроводительной документации.
Тестирование документации
Проверяется полнота описаний функций API, её понятность.
Иерархия тестов
- Components
- Projects
- Project 1
- Project 2
- Components
- Suites
- Suite 1 (Scenario)
- Suite 2 (Scenario)
- Components
- Cases
- Case 1 (Sub scenario)
- Case 2 (Sub scenario)
- Step 1
- Step 2
И на последок схема работы тестов.
