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

1.

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

2.

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

3.

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

4.

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

5.

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

6.

Следует уметь различать, что:
Error — это ошибка пользователя, то есть он пытается
использовать программу иным способом (например, вводит
буквы в поля, где требуется вводить цифры). В качественной
программе предусмотрены такие ситуации и выдаются
сообщение об ошибке (error message).
Bug (defect) — это ошибка программиста (или дизайнера или ещё
кого, кто принимает участие в разработке), то есть когда в
программе, что-то идёт не так, как планировалось. Например,
внутри программа построена так, что изначально не
соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или
системы.

7.

Атрибуты дефекта
Серьезность (Severity) — характеризует
влияние дефекта на работоспособность
приложения.

8.

Градация Серьезности дефекта
Blocker - ошибка, приводящая приложение в нерабочее состояние, из-за которой дальнейшая
работа с системой или ее ключевыми функциями становится невозможна, т.е. тестирование
значительной части функциональности становится недоступно
Крит (Critical) - неправильно работающая ключевая бизнес-логика, дыра в системе
безопасности, проблема, приведшая к временному падению сервера или приводящая в
нерабочее состояние некоторую часть системы, без возможности решения проблемы,
используя другие непрямые пути (workaround).
Значительный (Major) - часть основной бизнес логики работает некорректно, есть возможность
для работы с тестируемой функцией, используя обходные пути (workaround); либо дефект с
высоким visibility – обычно не сильно влияющие на функциональность дефекты дизайна,
которые, однако, сразу бросаются в глаза.
Minor - часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или
внешний вид; либо незначительная функциональная ошибка, не нарушающая бизнес-логику
тестируемой части приложения.
Тривиальная (Trivial) - ошибка, не касающаяся бизнес-логики приложения, не оказывающая
никакого влияния на общее качество продукта, например, опечатки в тексте, несоответствие
шрифта и оттенка и т.д.

9.

Некоторые техники тест-дизайна
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал
(часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по
своему влиянию на систему значений.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения
продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в
качестве значений для позитивного тестирования берется минимальная и максимальная
границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям,
записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона
возможных значений переменной на поддиапазоны, с последующим выбором одного или
нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания
системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать»
при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения
ответа от системы (следствие).

10.

Некоторые техники тест-дизайна
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия
двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех
возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых
данных из полного набора входных данных в системе, которая позволяет
существенно сократить общее количество тест-кейсов. Используется для тестирования,
например, фильтров, сортировок.
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для
фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований,
которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В
таблицах решений представлен набор условий, одновременное выполнение которых приводит к
определенному действию.

11.

Классификация по целям
Функциональное тестирование (functional
testing) рассматривает заранее указанное
поведение и основывается на
анализе спецификации компонента или
системы в целом, т.е. проверяется корректность
работы функциональности приложения.
Нефункциональное тестирование (non-functional
testing) — тестирование атрибутов компонента
или системы, не относящихся к
функциональности.

12.

Классификация по целям
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет,
consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства
использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять
интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для
анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к
конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки,
а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного
обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях
компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности
противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи
с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии
с ее культурными особенностями

13.

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

14.

Классификация по знанию
системы
Тестирование белого ящика (White Box) — метод тестирования ПО,
который предполагает полный доступ к коду проекта, т.е. внутренняя
структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который
предполагает частичный доступ к коду проекта (комбинация White Box и
Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО,
также известный как тестирование, основанное на спецификации или
тестирование поведения — техника тестирования, которая не
предполагает доступа (полного или частичного) к системе, т.е.
основывается на работе исключительно с внешним интерфейсом
тестируемой системы.естирование поведения — техника тестирования,
которая не предполагает доступа (полного или частичного) к системе,
т.е. основывается на работе исключительно с внешним интерфейсом
тестируемой системы.

15.

Классификация по исполнителям
тестирования
Модульное (компонентное) тестирование (Unit Testing)
проводится самими разработчиками, т.к. предполагает полный
доступ к коду, для тестирования какого-либо одного логически
выделенного и изолированного элемента (модуля) системы в
коде, проверяет функциональность и ищет дефекты в частях
приложения, которые доступны и могут быть протестированы поотдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на
проверку корректности взаимодействия нескольких модулей,
объединенных в единое целое, т.е. проверяется взаимодействие
между компонентами системы после проведения компонентного
тестирования.

16.

Классификация по исполнителям
тестирования
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции
собираются воедино и затем тестируются. После чего собирается следующий уровень модулей
для проведения интеграционного тестирования. Данный подход считается полезным, если все
или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает
определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и
постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня
симулируются заглушками с аналогичной функциональностью, затем по мере готовности они
заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули
собираются вместе в виде законченной системы или ее основной части, и затем проводится
интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако
если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно
осложнится, что станет преградой для команды тестирования при достижении основной цели
интеграционного тестирования.

17.

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

18.

Классификация по исполнению
кода
Статическое тестирование — процесс тестирования, который
проводится для верификации практически любого артефакта
разработки. Например, путем анализа кода (code review). Анализ
может производиться как вручную, так и с помощью специальных
инструментальных средств. Целью анализа является раннее
выявление ошибок и потенциальных проблем в продукте. Также к
этому виду относится тестирование требований, спецификаций и
прочей документации.
Динамическое тестирование проводится на работающей
системе, т.е. с осуществлением запуска программного
кода приложения.

19.

Классификация по хронологии
выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation
testing) — тестирование, во время которого исполняются тестовые
сценарии, выявившие ошибки во время последнего запуска, для
подтверждения успешности исправления этих ошибок, т.е. проверяется
исправление багов.
Регрессионное тестирование (regression testing) — это тестирование
после внесения изменений в код приложения (починка дефекта,
слияние кода, миграция на другую операционную систему, базу данных,
веб сервер или сервер приложения), для подтверждения того факта, что
эти изменения не внесли ошибки в областях, которые не подверглись
изменениям, т.е. проверяется то, что исправление багов, а также любые
изменения в коде приложения, не повлияли на другие модули ПО и не
вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы
потребностям, требованиям и бизнес-процессам пользователя.

20.

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