Предугадывание ошибки error guessing eg - Не ошибается лишь тот, кто ничего не делает!

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

Время на прочтение
13 мин

Количество просмотров 179K

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

ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
выполнением тестирования (Test Execution)
анализом результатов (Test Analysis)

Основные цели тестирования

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

Верификация (verification)	Валидация (validation)
Соответствие продукта требованиям (спецификации)	Соответствие продукта потребностям пользователей

Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

Следует уметь различать, что:

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

Жизненный цикл бага

Атрибуты дефекта

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

Градация Серьезности дефекта

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

Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

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

Пример таблицы принятия решений

ВИДЫ ТЕСТИРОВАНИЯ

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

Классификация по целям

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

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

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

Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.

Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.

Классификация по позитивности сценария

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

Классификация по знанию системы

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

Классификация по исполнителям тестирования

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

Классификация по уровню тестирования

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

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

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

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

Классификация по исполнению кода

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

Классификация по хронологии выполнения

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

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

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

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Тестовые сценарии	Функциональное требование 1	Функциональное требование 2	Функциональное требование 3	…
test case 1	+	+
test case 2		+	+
test case 3	+	+	+
…				+

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

Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

Предусловия (PreConditions) используются, если предварительно систему нужно приводить к состоянию пригодному для проведения проверки; т.е. указываются либо действия, с помощью которых система оказывается в нужном состоянии, либо список условий, выполнение которых говорит о том, что система находится в нужном состоянии для основного теста.
Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.
Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.
иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)

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

Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

Шапка	Название/тема: Краткое описание (Summary) некорректного поведения, составляется по схеме WWW, т.е. ЧТО ГДЕ КОГДА (при каких условиях)
Назначен на (Assigned To) сотрудника, который будет с ним разбираться
Статус (Status) бага в соответствии с workflow
Компонент приложения (Component): название тестируемой функции или ее части
Информация по сборке, на которой была найдена ошибка: Номер версии (Version), название ветки
Информация об окружении (Environment): ОС + версия, модель девайса (для мобильных устройств) и т.д.
Серьезность (Severity)
Приоритет (Priority)
Описание	Подробное описание (Description): указывается по необходимости; как правило, сюда вносятся предусловия (PreConditions) или другая дополнительная полезная информация, например, если для воспроизведения бага нужны специальные знания/данные/инструменты
Шаги воспроизведения (Steps to Reproduce), по которым воспроизводится ситуация, приведшая к ошибке
Фактический Результат (Result), полученный после прохождения шагов воспроизведения, часто может быть = теме/краткому описанию (Summary) + расшифровка чего-либо (например, ошибки по коду), если нужно
Ожидаемый результат (Expected Result): который правильный, т.е. описание того, как именно должна работать система в соответствии с требованиями
Прикрепленные файлы	*Вложения* (Attachment): файлы с логами, скриншот или видео каст либо их комбинация для прояснения причины ошибки

Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется

Источник

Предугадывание ошибки (Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? «, и так далее. Это и есть предугадывание ошибки.

Источник

Раздел: Тестирование > Техники тест дизайна

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

Предлагаю вам ознакомиться с кратким описанием наиболее распространенных техник тест дизайна:

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

Наверх

1. Тестирование ПО Лекция 5. Методики тестирования

ШТАНЮК А.А., 2019

2. Позитивные и негативные тесты

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

3. «Черный ящик»

ВХОД
ВЫХОД

4. «Черный ящик»

• Не знаем/Игнорируем устройство тестируемого объекта
• Можем управлять входными параметрами
• Среда, в которой проводим эксперименты, может считаться входным
параметром
• Можем измерять выходные параметры

5. Шаги

1.
2.
3.
4.
5.
Изучение спецификаций и требований
Выбор входных значений
Определение ожидаемых выходных
значений
Исполнение тестов
Сравнение полученных результатов с
ожидаемыми

6. Стратегии

Число тестов определяется числом входов и диапазоном входных данных
Перебор всех вариантов (по диапазону), как правило, невозможен!
Стратегии уменьшения числа тестов:
1. Классы эквивалентности
2. Граничные условия

7. Классы эквивалентности

Если от двух тестов ожидается одинаковый результат – они эквивалентны
Группа тестов представляет класс эквивалентности если:
• Все тесты предназначены для выявление одной и той же ошибки
• Если один тест выявит ошибку, то и остальные это сделают
• Если один из тестов не выявит ошибку, то и остальные этого не сделают
Дополнительные практические критерии:
Тесты включают значения одних и тех же входных данных
Для проведения теста выполняются одни и те же операции программы
В результате тестов формируются значения одних и тех же выходных данных
Ни один из тестов не вызывает выполнения конкретного блока обработки
ошибок либо выполнение этого блока вызывается всеми тестами

8. Классы эквивалентности

Программа классификации треугольников
Классы эквивалентности по корректным входным данным:
• Равнобедренные треугольники
• Равносторонние треугольники
• Прямоугольные треугольники
• Просто треугольники
Классы эквивалентности по некорректным входным данным:
• Отрезки не образуют треугольник
• Числа больше sizeof(int)
• Строка, содержащая буквы

9. Классы эквивалентности

Программа, говорящая дату следующего дня
Классы эквивалентности по корректным входным данным:
День от 1 до 27
Последний день месяца
Последний день года
28 февраля високосного года
Классы эквивалентности по некорректным входным данным:
Месяц > 12
День > 31
Неверная строка

10. Классы эквивалентности

Построение классов эквивалентности – субъективный процесс
Общие рекомендации:
• Не забывайте о классах некорректных данных
• Формируйте классы в виде таблицы или плана
• Определите диапазоны числовых значений входных данных
• Проанализируйте варианты выбора из списков и меню
• Поищите переменные значения которых должны быть равными
• Поищите классы значений, зависящих от времени
• Выявите группы переменных, совместно участвующих в конкретных вычислениях
• Посмотрите на какие действия программа отвечает эквивалентными событиями
• Продумайте варианты среды тестирования

11. Граничное тестирование

Тестирование значений лежащих на границе классов эквивалентности,
т.к. там выше вероятность возникновения ошибки
int safe_add( int a, int b )
{
int c = a + b ;
if ( a >= 0 && b >= 0 && c < 0 )
{
fprintf ( stderr, «Overflow!n»);
}
if ( a < 0 && b < 0 && c >= 0 )
{
fprintf ( stderr, «Underflow!n»);
}
return c;
}

12. Граничное тестирование

• Определяем границу класса эквивалентности
• Проверяем значения, лежащие ровно на границе
• Проверяем значения лежащие максимально близко к границе с обоих
сторон
Пример:
При покупке более 100 единиц товара дается скидка 5%. Нужно
проверить:
• 100
• 99
• 101

13. Преимущества и недостатки «ЧЯ»

Преимущества:
• Тестирование с точки зрения пользователя
• Не требует специальных знаний (например конкретного языка
программирования)
• Позволяет найти проблемы в спецификациях
• Можно создавать тесты параллельно с кодом
• Тестировщик может быть отделен от разработчиков

14. Преимущества и недостатки «ЧЯ»

Недостатки:
Эффективность зависит от выбора конкретных тестовых
значений
Необходимость наличия четких и полных спецификаций
Невозможность сконцентрироваться на особо сложных
частях кода
Трудность локализации причины дефекта
Возможность не протестировать часть кода

15. «Белый ящик»

• Используем знание об устройстве тестируемого объекта
• В случае ПО – имеем полный доступ к тестируемому коду
Стадии применения:
• Unit-тестирование
• Интеграционное тестирование

16. Шаги

Представляем программу в виде графа

17. Шаги

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

18. Метрики

Покрытие кода (code coverage) – мера измерения оттестированости
имеющегося программного кода
Microsoft Visual Studio 2010(C++, C#)
DevPartner (C#, Java)
Codecov из Intel Compiler (C, C++, Fortran)
Jtest (Java)
Devel::Cover (Perl)
PHPUnit (PHP)
Coverage (Python)
CoverMe (Ruby)

19. Преимущества и недостатки

Преимущества:
• Позволяет найти «скрытые» в коде дефекты
• Позитивные побочные эффекты (например, обучение команды)
• Нахождение проблем производительности
• Более надежное разбиение на классы эквивалентности
• Как правило, ускорение цикла нахождение-исправление
Недостатки:
• Не найдем пропущенное в коде
• Дорого

20. Сравнение «ящиков»

Критерий
Черный Ящик
Белый Ящик
Основной уровень
применимости
Приемочное
тестирование
Юниттестирование
Ответственный
Независимый
тестировщик
Разработчик
Знание
программирования
Не обязательно
Необходимо
Знание
реализации
Не обязательно
Необходимо
Знание сценариев
использования
Необходимо
Не обязательно
Основа тестовых
сценариев
Спецификации
Код

21. «Серый» ящик

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

22. Выбор входных значений

Бессистемный выбор входных значений не позволит найти большое
количество дефектов. Необходимо использование методов для выбора
набора входных значений.
Основные методы выбора входных значений:
• Перебор всех возможных значений
• Случайные входные данные
• Предугадывание ошибки
• Построение графов «причина-следствие»
• Использование классов эквивалентности
• Исследование граничных значений

23. Метод перебора

Перебираем все возможные значения входных параметров
Последовательный перебор всех возможных комбинаций входных
значений
Попарный перебор. Перебираем комбинации пары 2х входных
параметров. Работаем в предположении что параметры попарно
зависимы. На практике находит ~80% функциональных дефектов
низкого уровня

24. Случайные входные данные

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

25. Предугадывание

Составление тестовых сценариев на основании опыта предыдущего тестирования
Используйте знания о известных проблемных местах вашего продукта
Знайте распространенные ошибки программирования и пишите тесты для их
поиска
◦ Некорректная работа с памятью: переполнение, чтение за пределами, утечки памяти
◦ Отсутствие обработки некорректных входных данных
◦ Ошибки работы с типами данных: переполнение, приведение, приближение
◦ Ошибки многопоточности: deadlock, data race
◦ Отсутствие инициализации/сброса переменных
◦ Недостаток привилегий, недоступность ресурсов
◦ ….

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

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

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

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

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

“Aвтоматический” вариант применяется
на кафедре “ВТ и САПР” в СибАДИ . По подробней
об этом будет сказано дальше.

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

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

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

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

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

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

Вопросы и задачи заносятся в банк, как правило, вместе
с несколькими
(обычно 5-10) вариантами ответов. Эти вaрианты
сообщаются студенту одновременно с формулировкой
задания, и он должен выбрать из них верный.
Возможно, что полным правильным ответом
является набор некоторого количества
приведенных вариантов.

Банк ответов. Содержит
прaвильные ответы к каждому заданию, компьютер
сверяет данный студентом ответ с содержанием
банка.

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

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

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

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

Блок формирования оценок.
Осуществляет сравнение ответа студента
с содержанием банка ответов,
и в соответствии с выбранным
режимом оценивания, фиксирует оценку
ответа в баллах.

Протоколы, статистика. Записывает
в память компьютера фамилию студента,
дату экзамена, распределение набранных
баллов.

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

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

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

Раньше при старой
системе проведения экзамена по курсу
“Информатика” требовалось довольно
много времени для опроса всех студентов. В настоящее время
теоретической частью экзамена является
тестирование. Для охвата всей темы в тесте
предлагается 30-40 вопросов. По окончании
проведения контроля оценку ставит сама
машина.

Метод компьютерного тестирования вот
уже несколько лет применяется в курсе
“Теории вероятности и математической
статистики”. На практическом занятии
после обсуждения определений, формул
и типовых задач студенты начинают самостоятельную
работу с тестами.
Тестирование рассчитано на 40 минут. При
такой организации работы преподаватель
выступает в роли консультанта, имеет
возможность обсудить практически с каждым
наиболее трудные моменты и ошибки. За
отведенное время студент успевает разобрать
10-15 задач вместо обычных 3-4.

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

Задания предлагаются, как
правило, с ответами в “закрытой
форме”, когда нужно выбрать один
из нескольких предложенных ответов
или в “открытой форме”, когда
нужно вставить пропущенное слово. В этом случае, когда ответ однозначен,
он оценивается по двухбалльной системе
— 1 или 0, если задание имеет несколько
правильных ответов, возможны три оценки
-0, 0.5 и 1.
Введение в тест заданий с многовариантными
ответами развивает у студента потребность
в поиске разных путей решения задачи,
что необходимо для достижения основной
цели обучения в вузе — умения самостоятельно
выбирать способ выполнения поставленной
задачи.

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

По мнению исследователей
такой методики раздел курса считается
проработанным, если выполнено 70% заданий.

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

2. Традиционные
формы педагогического контроля

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

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

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

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

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

Перечисленные методы диагностирования
успеваемости учащихся имеют определенные
недостатки. Рaссмотрим некоторые из них .
Могут возникать трудности, связанные
с особенностями преподавательской работы:
— довольно часто проявляются несовпадение
требований разных преподавателей, отличия
в их уровне строгости при оценке одного
и того же ответа;
— различие в профессиональной квалификации;
— при организации текущих проверок знaний
большого числа студентов, когда оценивание
проводится, главным образом, лишь по формальным
критериям, наблюдается загруженность
преподавателя рутинной мало творческой
работой, связанной с большим объемом
информaции, которую требуется подготовить,
обрaботать и проанализировать за относительно
короткий промежуток времени;
— возможная небеспристрастность преподавателя
(по психологическим и иным причинам) к
оценке ответов некоторых студентов;
— иногда оценки, выставляемые студентам,
оказываются недостоверными из-за опасения
преподавателя, что они будут использованы
для оценивания работы самого преподaвaтеля.
Трудности, связанные со спецификой традиционной
формы проверки знаний.
Такие, как отсутствие четко сформулированных
стандартов знаний и конкретно очерченных
объемов умений, достаточных для каждой
положительной оценки
(часто преподаватель мучается с вопросом:
«Какую оценку поставить — «неуд»
или все же можно оценить как «удовлетворительно»?”).
Трудности, связанные со студентами: использование
шпаргалок, списывание,
«взаимопомощь» на экзамене, что искажает
достоверность оценки знаний студентов
и мешает преподавателю объективно взглянуть
на качество своей педагогической работы.
Отсутствие объективных критериев оценки
и эффективных механизмов сравнения результатов
обучения по данной дисциплине (специальности)
в различных
ВУЗах, что особенно актуально для выработки
верной стратегии подготовки кадров. Принятая,
преимущественно, методика приема экзаменов
по 3-4 вопросам в билете не позволяет оценить
полноту освоения материала и провоцирует
списывание.

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

3. Формирование
оценочной шкалы тестового контроля

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

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

В существующих системах
тестирования предполагается, что преподаватель-
экзaменатор зaранее выбирает определенную
шкaлу оценок, т.е. устанавливает, например,
что, если испытуемый набирает от 31 до
50 баллов, то он получает оценку “отлично”,
от 25 до 30 баллов -”хорошо”, от 20 до 24 —
“удовлетворительно”, менее 20 — “неудовлетворительно”.

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

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

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

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

Методы тестирования ПО МЕТОДЫ ПОИСКА ОШИБОК

Содержание лекции Определимся, кто несет ответственность за качество системы Изучим методы поиска ошибок Задания

Качество vs ответственность От кого зависит качество системы? Кто несет ответственность за качество системы?

Классификация по знанию внутренней системы

Разработка через тестирование

Преимущества 1. Возможность убедиться, что приложение пригодно для тестирования 2. Автоматизированные тесты покрывают все пути исполнения 3. Разработчик продумывает детали интерфейса до реализации 4. Тесты заставляют делать свой код более приспособленным для тестирования 5. Модульное тестирование способствует формированию четких и небольших интерфейсов 6. Несмотря на то, что при разработке через тестирование требуется написать большее количество кода, общее время, затраченное на разработку, обычно оказывается меньше 7. Тесты защищают от ошибок. Поэтому время, затрачиваемое на отладку, снижается многократно 8. Устранение дефектов на более раннем этапе разработки, препятствует появлению хронических и дорогостоящих ошибок, приводящих к длительной и утомительной отладке в дальнейшем 9. Тесты позволяют производить рефакторинг кода без риска его испортить. При внесении изменений в хорошо протестированный код риск появления новых ошибок значительно ниже 10. Уверенность в том, что изменения не нарушит существующую функциональность, придает уверенность разработчикам и увеличивает эффективность их работы 11. Разработка через тестирование способствует более модульному, гибкому и расширяемому коду. 12. Тесты могут использоваться в качестве документации. Хороший код расскажет о том, как он работает, лучше любой документации.

Слабые места 1. 2. 3. 4. 5. 6. 7. Существуют задачи, которые невозможно решить Прохождение функциональных тестов Поддержка от руководства Модульные тесты обычно пишутся теми же, кто пишет тестируемый код Ложное ощущение надежности Тесты сами по себе являются источником накладных расходов Сложно определить покрытие тестами: неудачные архитектура, дизайн или стратегия тестирования приводят к большому количеству непройденных тестов, важно их все исправить в индивидуальном порядке. Простое удаление, отключение или поспешное изменение их может привести к необнаруживаемым пробелам в покрытии тестами.

Разработка тестов МЕТОДЫ ПОИСКА ОШИБОК

Где искать тесты? ● Тщательное изучение и анализ требований (описания функции, модуля, спецификации, и т. д. ). ● Декомпозиция требованийфункций. ● Выявление всех условий, входных и выходных данных (что) ● Анализ поведения (как) ● Использование различных техник для выделения определенных тестов ● Использование накопленных знаний о выполненных проектах (оттестированных продуктах) ● Интуиция ● Анализпросмотр выявленных тестов и добавление новых

Проблемы, которые придется решить ● ● ● Искать все ошибки или грубейшие? Если не все, то как установить порог допустимости ошибки? Когда завершать тестирование? Что делать, если сроки поджимают и/или нет ресурсов на дальнейшее тестирование? Где остановиться в документировании тестов? Изменять тест или следовать первоначальной инструкции?

Классы эквивалентности (partitioning, equivalent analysis) ● Анализируем входные и выходные данные: ○ правильные классы эквивалентности (корректные входные данные) ○ неправильные классы эквивалентности (ошибочные входные данные)

Лучшие представители ● Какие значения тестировать внутри класса эквивалентности? ● Используем предположения: ○ Множество возможных значений непрерывно ○ Значения могут быть спроецированы на числовую ось, мы всегда можем определить, что из двух значений одно больше, а другое меньше или они одинаковы

Разберем пример Программа: INPUT

Выводы: Типы ошибок: ● Программа не принимает числовые значения как факт ○ ● Написали

Анализ граничных значений (Boundary Value Testing) ● Идентифицировать граничные значения для каждого входного значения (класса эквивалентности) ○ на границе ○ значение, меньшее граничного ( «у границы» ’below point’) ○ значение, большее граничного ( «за границей» ’above point’) Примеры: ➢ Область корректных значений: [-1. 0, 1. 0] -> тесты для -1. 0, -1. 001, 1. 001 ➢ Максимальная длина слова – 5 символов — > тесты для 4, 5, 6 ➢ Область выходных значений: минимум расхода 0. 00, максимум 2000 -> подбираем входные данные для того, чтобы получить на выходе 0. 00, 2000. 01, -0. 01

В задаче: INPUT

Граничные значения Для точки: Z -> Z-1, Z, Z+1 Для отрезка: [x, y] -> x-1, x, y, y+1 А для такого интервала значений: (х, у) ?

Выбор значений ● ● Значение в пределах класса является лучшим представителем Граничные значения часто будут лучшими представителями Могут быть лучшие представители, которые не будут граничными значениями Могут быть выделены лучшие представители в классах, значения которых не будут очевидно сравнимы (больше-меньше)

Как тестируем? ● Классы эквивалентности: некорректные значения ○ Тестировать одно некорректное значение за раз для того, чтобы проверить, что система идентифицирует его корректно. ● Классы эквивалентности: корректные значения ○ Как ?

Стратегии работы с новым кодом ТАБЛИЦЫ РЕШЕНИЙ (DECISION TABLE TESTING)

Этапы построения таблицы 1. 2. 3. 4. 5. Определить/записать все условия Посчитать количество возможных комбинаций условий Запомнить комбинации Записать действия Убрать лишние комбинации (схлопывание таблицы)

Пример: светофор (SQA DAYS 14 — ЕЛЕНА СТАШЕНКО)

Автомобиль находится перед светофором, определить его дальнейшие действия Условия: ØГорит ли красный? Y N ØГорит ли желтый? Y N ØГорит ли зеленый? Y N Количество комбинаций: Ø 2*2*2 = 8

1. Определить список возможных условий и их значения

2. Определить список всех возможных действий (ожидаемых результатов для условий)

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

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

Дополнительные условия

Убрать лишние комбинации

Стратегии работы с новым кодом ФУНКЦИОНАЛЬНЫЕ ДИАГРАММЫ (CAUSE-EFFECT GRAPHING)

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

Алгоритм действий 1. Разбить внешние спецификации на отдельные функции, которые будут тестироваться (декомпозиция функциональных требований) 2. Идентифицировать явные и неявные причины (условия на входе) и присвоить каждой из них уникальный номер 3. Идентифицировать явные и неявные эффекты (действия на выходе) и присвоить каждому из них уникальный номер 4. Перевести семантику спецификации в граф «причина-следствие» (Boolean cause-effect graphing) 5. Добавить информацию о невозможных комбинациях причинэффектов 6. Построить таблицу решений (бинарные значения) 7. Записать тест кейс для каждого столбца

Пример Requirements for Calculating Car Insurance Premiums: For females less than 65 years of age, the premium is $500 For males less than 25 years of age, the premium is $3000 For males between 25 and 64 years of age, the premium is $1000 For anyone 65 years of age or more, the premium is $1500

Причины (Causes) – входные условия 1. Пол: мужской 2. Пол: женский 3. Возраст: =25 and = 65

Следствия (Effects) – выходные результаты 100. Премия = $1000 101. Премия = $3000 102. Премия = $1500 103. Премия = $500

Причина: 1. Пол: мужской and 3. Возраст:

Причина: 1. Пол: мужской and 4. Возраст: >=25 and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500

Причина: 2. Пол: женский and 3. Возраст: =25 and

Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500

Преобразование в таблицу решений Test Cases 1 (мужской) 2 (женский) 3 (= 25 and = 65) 1 1 0 0 2 1 0 0 1 0 3 1 0 0 0 1 4 0 1 0 0 1 5 0 1 1 0 0 6 0 1 0 100 (1000$) 101 (3000$) 102 (1500$) 103 (500$) 0 1 0 0 0 0 0 1

Особенности применения ф. диаграмм 1. Требуется трансляция спецификации в булевскую логическую сеть 2. Обнаружение неполноты и неоднозначности в исходных спецификациях 3. Применение функциональных диаграмм не обеспечивает построение всех полезных тестов, которые могут быть определены: a. Как пример: метод неадекватно исследует граничные условия 4. Лучше отделять анализ граничных значений от метода функциональных диаграмм (иначе граф существенно усложняется) 5. Наиболее трудным при реализации метода является преобразование диаграммы в таблицу решений

Стратегии работы с новым кодом ДРУГИЕ МЕТОДЫ

Метод предположение об ошибке (Error guessing) ● Этот метод в значительной степени является интуитивным ● Тест инженер использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку ● Перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка написать тесты

Requirements-Driven Testing Проверяем каждое требованиезапрос, которое описано или озвучено анализ требований: выявление неоднозначностей, неточностей, пропущенной информации и т. п. (можно использовать функциональные диаграмма) Отслеживаем все требования и их покрытие тестами ● список требований с идентификаторами и соответствующих тестов (Requirements Tracing Matrix) Для каждого требования должны быть разработаны тесты ●

Задания 1. Классы эквивалентности 2. Граничные значения 3. Таблица решений 4. Функциональные диаграммы

1. Выполнить разбиение на классы эквивалентности 1. 1 Password – длина не меньше 8 символов, максимум 16. Может состоять из латинских букв и цифр, а также могут быть использованы символы только из списка «!» , «_» , «? » , «#» . При этом пароль должен обязательно содержать, как минимум, одну заглавную букву и одну цифру. 1. 2 Значение для ‘Product ID’ должно содержать 5 символов, первые два из них должны быть обозначениями из списка допустимых значений (A 1 or A 2 or B 1 or B 2), остальные три — уникальным числовым значением.

Определить граничные значения 2. 1 Корректные значения X — целые значения от -2 до 10 2. 2 Максимальное длина вводимого значения равна 20 символам

3. Составить таблицу решений 3. 1 Страховая компания предоставляет страховку клиентам, достигшим 18 -ти летнего возраста. Если стаж водителя составляет от 2 -х до 6 -ти лет, предоставляется скидка 20%. Если стаж водителя более шести лет, скидка 30% 3. 2 Любому посетителю салона красоты «Жасмин» может быть присвоена одна из категорий: «Клиент» , «Клиент категории А» , «Клиент категории Б» , «Клиент категории С» в зависимости от количества посещение салона. Категория «Клиент» присваивается посетителю, на счету которого 3 посещения и более. Категория «Клиент категории А» присваивается посетителю, на счету которого 10 посещений и более. Категория «Клиент категории Б» присваивается посетителю, на счету которого 20 посещений и более. Категория «Клиент категории С» присваивается посетителю, на счету которого 30 посещений и более.

3. Составить таблицу решений 3. 2 Система скидок магазина Скидки предоставляются покупателям, которые приобрели накопительную карту магазина. Изначально карта имеет тип “Standard” c нулевым балансом. При покупке товара и предъявлении карты при оплате, сумма покупок зачисляется на баланс карты. Величина скидки зависит от общей суммы покупок на карте покупателя и от типа карты. Для карты тип “Standard” скидки составляют: ● 5%, если общая сумма покупок на карте от 20000 руб до 40000 руб включительно, ● 10%, если сумма на карте больше, чем 40000 руб. Магазин меняет карту типа “Standard” на карту типа “Silver Card”, если накопительная сумма покупателя на карте типа “Standard” становится равной или больше 50000 руб. Для карты тип “Silver Card” скидки составляют: ● 10%, если сумма на карте от 50000 руб до 70000 руб включительно, ● 20%, если сумма на карте больше, чем 70000 руб. Магазин меняет карту типа “Silver Card” на карту типа “Gold Card”, если накопительная сумма покупателя на карте типа “Silver Card” становится равной или больше 100000 руб. Для карты типа “Gold Card” скидки составляют: ● 20%, если сумма на карте от 100000 руб до 150000 руб включительно, ● 30%, если сумма на карте больше, чем 150000 руб. Магазин меняет карту типа “Gold Card” на карту типа “VIP Card”, если накопительная сумма покупателя на карте типа “Gold Card” становится равной или больше 200000 руб. Для карты типа “VIP Card” скидки составляют: 30%, если сумма на карте больше, чем 200000 руб

4. Применить метод функциональных диаграмм 4. 1 Для банкомата банка «ТТТ» реализовано ПО, которое автоматизирует такие функции как выдача денег, выдча справки о балансе (доступные средства на карте), выдача распечатки с 10 ю последними операциями по карте, оплата услуг по мобильной связи Проанализирйте спецификацию для функции «Обработка запроса на снятие суммы с карты» и примените метод функциональных диаграмм для создания тест кейсов. Разработать и описать тест-кейсы в матрице (xls-file). ● Спецификация для функции «Обработка запроса на снятие суммы с карты» : Если карта типа «кредитная» (K) или «дебетовая» (D), то банкомат выдает деньги клиенту при условии, что запрашиваемая сумма (X) не превышает сумму доступных средств на карте клиента (S). Если карта типа «кредитная» , то банкомат выдает деньги и в случае, если запрашиваемая сумма превышает сумму доступных средств на карте, но не выходит за рамки допустимого превышения кредита (L). В случае, если карта не является «кредитной» или «дебетовой» или же запрашиваемая сумма превышает сумму доступных средств на карте для дебетовой карты или же запрашиваемая сумма превышает сумму доступных средств на карте и выходит за рамки допустимого превышения кредита для кредитовой карты, тогда выдается сообщение о том, что деньги не могут быть выданы и деньги не выдаются.

Метод предугадывания ошибок тестирование

Источник

Эквивалентное разделение
Анализ граничных значений
Переход состояний
Попарное тестирование
Предугадывание ошибок

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

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

Что такое тест-дизайн?

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

Зачем нужен тест-дизайн?

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

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

Итоги

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

При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.

Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши».

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

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

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

Динамическое тестирование требует проверять ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы:

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

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

1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски.

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

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

3. Анализ результатов и составление отчетов.

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

Техники тест-дизайна на примерах

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

Эквивалентное разбиение

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

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

У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.

QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.

Граничные значения

Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.

Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д.

Таблица принятия решений

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

Какие возможны сценарии:
1. Правильный логин и правильный пароль.
2. Правильный логин, неправильный пароль.
3. Неправильный логин, правильный пароль.
4. Неправильный логин, неправильный пароль.

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

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.

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

Пример таблицы принятия решений

Попарное тестирование

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

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

Pairwise testing: пример

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

№	Браузер	Операционная система	Язык
1	Opera	Windows	RU
2	Google Chrome	Linux	RU
3	Opera	Linux	EN
4	Google Chrome	Windows	EN

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

Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel.

Пример содержимого файла для программы PICT:

Браузер: Chrome, Opera
ОС: Windows, Linux
Язык: RU, ENG

Пример попарного тестирования

Причина и следствие

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

Примерный алгоритм использования техники:

1. Выделяем причины и следствия в спецификациях.
2. Связываем причины и следствия.
3. Учитываем «невозможные» сочетания причин и следствий.
4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.
5. Расставляем приоритеты.

Эта техника помогает:

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

Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.

Предугадывание ошибок

Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.

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

Что произойдет, если не ввести код?
Что произойдет, если не ввести спецсимволы?
Что произойдет, если ввести не цифры, а другие символы?
Что произойдет, если ввести не четыре цифры, а другое количество?

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

1. Эта проверка эффективна в качестве дополнения к другим техникам.
2. Выявляет тестовые случаи, которые “никогда не должны случиться”.

Недостатки:
1. Техника в значительной степени основана на интуиции.
2. Необходим опыт в тестировании подобных систем.
3. Малое покрытие тестами.

Итоги

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

Понравилась статья?

Подпишитесь на рассылку SimbirSoft! Пришлём письма о лайфхаках в разработке, поделимся опытом управления командами и компанией, а также расскажем о новых ивентах SimbirSoft.

ОСНОВНЫЕ ТЕРМИНЫ

планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
выполнением тестирования (Test Execution)
анализом результатов (Test Analysis)

Основные цели тестирования

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

Верификация (verification)	Валидация (validation)
Соответствие продукта требованиям (спецификации)	Соответствие продукта потребностям пользователей

Следует уметь различать, что:

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

Жизненный цикл бага

Атрибуты дефекта

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

Градация Серьезности дефекта

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

Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

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

Пример таблицы принятия решений

ВИДЫ ТЕСТИРОВАНИЯ

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

Классификация по целям

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

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

Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.

Классификация по позитивности сценария

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

Классификация по знанию системы

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

Классификация по исполнителям тестирования

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

Классификация по уровню тестирования

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

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

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

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

Классификация по исполнению кода

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

Классификация по хронологии выполнения

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

ДОКУМЕНТАЦИЯ

Основные атрибуты требований:

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

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Тестовые сценарии	Функциональное требование 1	Функциональное требование 2	Функциональное требование 3	…
test case 1	+	+
test case 2		+	+
test case 3	+	+	+
…				+

Атрибуты тест кейса:

Предусловия (PreConditions) используются, если предварительно систему нужно приводить к состоянию пригодному для проведения проверки; т.е. указываются либо действия, с помощью которых система оказывается в нужном состоянии, либо список условий, выполнение которых говорит о том, что система находится в нужном состоянии для основного теста.
Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.
Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.
иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)

Шапка	Название/тема: Краткое описание (Summary) некорректного поведения, составляется по схеме WWW, т.е. ЧТО ГДЕ КОГДА (при каких условиях)
Назначен на (Assigned To) сотрудника, который будет с ним разбираться
Статус (Status) бага в соответствии с workflow
Компонент приложения (Component): название тестируемой функции или ее части
Информация по сборке, на которой была найдена ошибка: Номер версии (Version), название ветки
Информация об окружении (Environment): ОС + версия, модель девайса (для мобильных устройств) и т.д.
Серьезность (Severity)
Приоритет (Priority)
Описание	Подробное описание (Description): указывается по необходимости; как правило, сюда вносятся предусловия (PreConditions) или другая дополнительная полезная информация, например, если для воспроизведения бага нужны специальные знания/данные/инструменты
Шаги воспроизведения (Steps to Reproduce), по которым воспроизводится ситуация, приведшая к ошибке
Фактический Результат (Result), полученный после прохождения шагов воспроизведения, часто может быть = теме/краткому описанию (Summary) + расшифровка чего-либо (например, ошибки по коду), если нужно
Ожидаемый результат (Expected Result): который правильный, т.е. описание того, как именно должна работать система в соответствии с требованиями
Прикрепленные файлы	*Вложения* (Attachment): файлы с логами, скриншот или видео каст либо их комбинация для прояснения причины ошибки

Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется

Источник

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

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

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.

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

Зачем тестировать ПО

Цели тестирования:

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

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

Этапы:

Анализ продукта
Работа с требованиями
Разработка стратегии тестирования
и планирование процедур контроля качества
Создание тестовой документации
Тестирование прототипа
Основное тестирование
Стабилизация
Эксплуатация

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

По целям:

Безопасности
Функциональное
Нефункциональное
- UI
- Совместимости
- Производительности
  - Нагрузочное
  - Стабильности
  - Стресс

По знанию системы:

Белый ящик
Серый ящик
Чёрный ящик

По хронологии выполнения:

Входное (Smoke/intake)
Повторное
Регрессионное

По степени автомтизации

По исполнению кода

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

Модульное/Компонентное (unit/component testing)* — тестирование наименьших элементов ПО, которые могут быть протестированы по-отдельности (модули, объекты, классы, функции).
Задача модульного тестирования — выявление локализованных в модуле ошибок реализации алгоритмов, а также определение степени готовности системы к переходу на следующий уровень разработки и тестирования.
Интеграционное (integration testing) — тестирование части системы, состоящей из двух и более модулей.
Задача интеграционного тестирования — поиск дефектов, связанных с ошибками реализации и интерпретации интерфейсного взаимодействия между модулями, а также ошибок взаимодействия с другими частями системы (ОС, оборудованием).
Системное (system testing) — процесс тестирования системы в целом с целью проверки того, что она соответствует установленным требованиям.
Задача системного тестирования — выявление дефектов, связанных с общей работой системы, таких как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство в применении и т.д.
Приёмочное (acceptance testing) — формальный процесс тестирования, который проверяет соответствие системы потребностям, требованиям и бизнес процессам пользователя, и проводится для вынесения решения заказчиком (внутренним или внешним) или другим уполномоченным лицом принимается приложение или нет.

Техники тест-дизайна

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

Что такое Regression и Confirmation тестирование, какая между ними разница

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

Регрессионное тестирование (regression testing) — тестирование уже протестированной программы после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде ПО или его окружения.

Частота регрессионного тестирования

Стоит делать по возможности и в зависимости от частоты вмешательства в релизы.

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

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

Configuration Testing

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

Exploratory Testing

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

Black/Grey/White Box Testing

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

Performance Testing

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

Smoke и Sanity тестирование и какая между ними разница

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

Дымовое/входное тестировние (smoke/intake test) — специальный тест (короткий цикл тестов) для принятия решения, готов ли компонент или система для дальнейшего детального тестирования. Выполняется для подтверждения того, что после сборки кода (нового или исправленного) приложение, стартует и выполняет основные функции.

Traceability Matrix

Матрица соответствия требований (traceability matrix) — двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).
В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

End-to-End тест

End-to-End тесты — такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы.
Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими — зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

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

Тестирование безопасноcти/защищённости (security testing) – тестирование ПО с целью определить его защищённость.
Основные понятия, которые должны быть охвачены тестированием: конфиденциальность, целостность и сохранность данных, аутентификация, авторизация и невозможность отказа от авторства.

Испытание на основе рисков

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

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

Динамическое тестирование (dynamic testing) — тестирование, проводимое во время выполнения ПО, компонента или системы.

«Парадокс пестицида»

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

Основные фазы STLC? Дайте определение Entry и Exit Criteria.

Жизненный цикл тестирования ПО(STLC) определяет, какие действия выполнять при тестировании и когда их выполнять.

Фазы:

Анализ требований
Планирование тестирования
Дизайн теста
Настройка тестовой среды
Выполнение теста
Завершение теста

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

Критерии выхода (Exit Criteria) — определяют элементы, которые должны быть выполнены до завершения тестирования.

Что такое Bug, Error, Failure, Fault

Bug (defect/fault) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Атрибуты баг-репорта? Какие основные поля для заполнения

Баг Репорт (Bug Report) — документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Атрибуты:

Короткое описание (Summary/Title) — выжимка информации явно указывающая на причину и тип проблемы.
Номер версии (Version) — версия на которой была найдена ошибка
Серьезность (Severity):
- S1 Блокирующий (Blocker)
- S2 Критический (Critical)
- S3 Значительный (Major)
- S4 Незначительный (Minor)
- S5 Тривиальный (Trivial)
Приоритет (Priority):
- P1 Высокий (High)
- P2 Средний (Medium)
- P3 Низкий (Low)
Статус (Status) — текущий статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)
Окружение (Environment) — ОС / Браузер + версия и т.п. Информация об окружении, на котором был найден баг.
Шаги воспроизведения (Steps to Reproduce) — действия, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Actual Result) — результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) — ожидаемый правильный результат

Разница между приоритетом и серьезностью

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

Приоритет (Priority) — атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Больше инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект

Обычно Severity выставляется тестировщиком, а Priority — менеджером, тимлидом или заказчиком.

Приведите примеры серьезного, но не приоритетного бага.

На Андроиде 4.4 приложение при первом запуске падает. В последующие запуски работает нормально. Т.к. пользователей с этой версией ОС у нас около 0,5%, то приоретет можно поставить низкий или вообще проигнорировать.

В чем разница между валидацией и верификацией

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

Зачем нужна тестовая документация? Какие её виды

https://habr.com/ru/company/otus/blog/588923/

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

Виды:

План тестирования (test plan)
Чеклист (checklist)
Тестовый сценарий (Test Case)
Баг-репорт (Bug Report)
Отчёт о тестировании (Test Report)
Инструкция (Manual)

Тест-план? Какие элементы у него есть

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

В стандарте IEEE 829 перечислены пункты, из которых может/должен состоять тест-план:

Test plan identifier
Introduction
Test items
Features to be tested
Features not to be tested
Approach
Item pass/fail criteria
Suspension criteria and resumption requirements
Test deliverables
Testing tasks
Environmental needs
Responsibilities
Staffing and training needs
Schedule
Risks and contingencies
Approvals

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

Должен отвечать на вопросы:

Что надо тестировать?
Что будете тестировать?
Как будете тестировать?
Когда будете тестировать?
Критерии начала тестирования.
Критерии окончания тестирования.

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

Разница между чеклистом и тест-кейсами

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

Тестовый кейс/сценарий (Test Case) — артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Должен иметь 3 части:

PreConditions — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions — список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

Тест кейсы разделяют на позитивные и негативные:

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

AQA (Automation QA)

Программирование

Что такое ООП? Назовите его принципы с примерами

Объектно-ориентированное программирование (ООП) — подход, при котором вся программа рассматривается как набор взаимодействующих друг с другом объектов. При этом нам важно знать их характеристики.

Основные понятия ООП:

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

Объект (экземпляр) – отдельный представитель класса, имеющий конкретное состояние и поведение, полностью определяемое классом.
Говоря простым языком, объект имеет конкретные значения атрибутов и методы, работающие с этими значениями на основе правил, заданных в классе.

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

Абстрагирование – способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.

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

Полиморфизм – свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

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

SHORT VERSION

Базовые принципы ООП:

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

Используйте следующее вместе с наследованием:

Делегация — перепоручение задачи от внешнего объекта внутреннему
Композиция — включение объектом-контейнером объекта-содержимого и управление его поведением; последний не может существовать вне первого
Агрегация — включение объектом-контейнером ссылки на объект-содержимое; при уничтожении первого последний продолжает существование

Интерфейс? Абстрактный класс? Чем они отличаются

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

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

Что такое SOLID? Приведите примеры

SOLID — 5 правил разработки ПО задающие принципы, которым стоит следовать, когда пишешь программы, чтобы их проще было масштабировать и поддерживать.

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

O — Open-Closed (Принцип открытости/закрытости)
Сущности программы должны быть открыты для расширения, но закрыты для изменения.

L — Liskov Substitution (Принцип подстановки Барбары Лисков)
Должна быть возможность вместо базового типа подставить любой его подтип.

I — Interface Segregation (Принцип разделения интерфейсов)
Клиенты не должны вынужденно зависеть от методов, которыми не пользуются.

D — Dependency Inversion (Принцип инверсии зависимостей)
Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Что такое DRY, KISS, YAGNI

DRY (Don’t Repeat Yourself — Не повторяйся)
Избегайте повторного написания кода, вынося в абстракции часто используемые задачи и данные. Каждая часть вашего кода или информации должна находиться в единственном числе в единственном доступном месте. Это один из принципов читаемого кода.

KISS (Keep It Simple, Stupid/Keep It Simple and Straightforward — Будь проще)
Не придумывайте к задаче более сложного решения, чем ей требуется. Простота кода – превыше всего, потому что простой код – наиболее понятный.

YAGNI (You Aren’t Gonna Need It — Вам это не понадобится)
Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны.

Какие паттерны GOF вам известны? Приведите примеры их использования.

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

Строитель (Builder) — разделяет создание сложного объекта и инициализацию его состояния так, что одинаковый процесс построения может создать объекты с разным состоянием.
Пример: избавление от лишних опций конструктора (Lombok и создание экземпляров класса), StringBuilder

Итератор (Iterator) — предоставляет способ последовательного доступа к элементам множества независимо от его внутреннего устройства.
Пример: foreach

Одиночка (Singleton) — гарантирует, что класс имеет только один экземпляр и предоставляет глобальную току доступа к нему.
Пример: общий доступ к базе данных из разных частей программы, selenium driver

Фабричный метод (Factory Method) — определяет интерфейс для создания объекта, но позволяет подклассам решать, какой класс инстанцировать. Позволяет делегировать создание объекта подклассам.

Абстрактная фабрика (Abstarct Factory) — предоставляет интерфейс для создания групп связанных или зависимых объектов, не указывая их конкретный класс.

PageObject и PageFactory

Page Object — паттерн при котором для каждой страницы тестируемого приложения создаётся отдельный объект, методы которого инкапсулируют логику работы с отдельными элементами. Позволяет уменьшить количество кода и упростить его поддержку.
Page Factory — реализация паттерна Factory для создания экземпляров страниц встроенная в Selenium.

Какая иерархия Collections

Интерфейсы:

Collection
List
Set
Map
Sorted Set
Sorted Map
Queue

Классы:

Lists:
- ArrayList
- LinkedList
- Vector(deprecated)
Sets
- HashSet
- LinkedHashSet
- TreeSet
Maps
- HashMap
- TreeMap
- HashTable (deprecated)
- LinkedHashMap
Queue
Priority Queue

Разница между Thread class и Runnable interface

Многопоточность программы в Java организуется с помощью интерфейса Runnable и класса Thread, который наследуется от Runnable. Первый способ более гибкий, второй – проще.
Когда пользовательский класс должен наследоваться от другого класса (не Thread), приходится использовать наследование от интерфейса Runnable, т.к. в Java нет множественного наследования классов.

Разница между String, Stringbuffer и Stringbuilder

String
Строки в Java иммутабельны (не могут быть изменены). При изменении объекта String в Java каждый раз создается совершенно новый объект.
При использовании оператора new для создания в памяти кучи каждый раз будет создаваться новый объект String. При использовании литерала объекта («some string»), если такой объект уже существует в куче, новый объект не появится, а ссылочная переменная будет указывать на существующий объект.

StringBuilder
Класс StringBuilder представляет собой альтернативу классу String, поскольку создает мутабельный (изменяемый) набор символов.
Класс StringBuilder не обеспечивает синхронизацию: экземпляры класса StringBuilder не могут совместно использоваться несколькими потоками. Для операций со строками в среде, не являющейся многопоточной, стоит использовать StringBuilder, потому что он быстрее, чем StringBuffer.

StringBuffer
Класс StringBuffer также создает изменяемый строковый объект и содержит те же методы, что и StringBuilder.
Разница между ними в том, что класс StringBuffer — потокобезопасный и синхронизированный: экземпляры класса StringBuffer могут совместно использоваться несколькими потоками. Для операций со строками в многопоточных средах стоит использовать StringBuffer.

Разница между final, finally и finalize

final – модификатор, который применяется к переменным, полям, методам и классам. Переменная или поле становится неизменяемым и требует инициализации. Финальный метод нельзя переопределить в наследниках. Финальный класс не может иметь наследников вообще.

finally – часть языковой конструкции try-catch-finally.

finalize — метод класса Object. Сборщик мусора вызывает его для объектов, на которые больше нет ссылок и которые помечены для сбора мусора. Deprecated с Java 9.

Selenium

Что такое Selenium и зачем его используют

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

Selenium IDE — плагин для браузера Firefoх для записи действий пользователя.
Selenium RC — устаревшая библиотека для управления браузерами.
Selenium WebDriver — современная библиотека для управления браузерами.
Selenium Server — сервер для управления браузером удаленно по сети.
Selenium Grid — кластер Selenium-серверов для управления браузерами на разных компьютерах в сети.

Что такое Selenium Grid

Selenium Grid — кластер, состоящий из нескольких Selenium-серверов. Предназначен для организации распределённой сети, позволяющей параллельно запускать много браузеров на большом количестве машин. Имеется выделенный сервер, который носит название «хаб» или «коммутатор», а остальные сервера называются «ноды» или «узлы».

Драйвер браузера

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

Какие виды локаторов страницы существуют? Каковы их преимущества и недостатки

id=<element_id> — соответствует элементу, у которого атрибут id равен значению element_id. Cледует отметить, что данный вид локаторов является одним из самых быстрых в нахождении и одним из самых уникальных.

name=<element_name> — соответствует элементу, у которого атрибут name равен значению element_name. Эффективно применяется при работе с полями ввода формы (кнопки, текстовые поля, выпадающие списки). Данный тип локаторов тоже является достаточно быстрым в нахождении, но менее уникальным, так как на странице может быть несколько форм, у которых могут быть элементы с одинаковым именем.

dom=<dom_object> — данный тип локатора позволяет обращаться к элементу так же, как и в DHTML используя DOM-структуру. Данный тип локатора используется нечасто, так как обычно находятся более удобные аналоги, но тем не менее данная возможность есть.

link=<link_text> — специально для ссылок используется отдельно зарезервированный тип локаторов, который находит нужную ссылку по ее тексту. Это сделано отчасти потому, что ссылки как правило не имеют таких атрибутов как ID или name. Также у ссылки есть фиксированная часть и есть часть, которая может варьироваться. В этом случае мы можем использовать wildcards, в частности ‘*’.

xpath=<xpath_locator> — наиболее универсальный тип локаторов. HTML представляет собой различное сочетание тегов, которые выстраиваются в определенную иерархию, наподобие структуры каталогов в файловой системе. Задача XPath — отразить подобный путь к нужному элементу, с учетом иерархии. У XPath есть много удобств, но есть и основной недостаток — низкая скорость нахождения объекта. В таких случаях рекомендуется воспользоваться CSS-локаторами, но в некоторых случаях от XPath уйти не получится.

css=<css_path> — данный тип локаторов основан на описаниях таблиц стилей (CSS). В отличие от локаторов по ID, по имени или по тексту ссылки, данный тип локаторов может учитывать иерархию объектов, а также значения атрибутов, что делает его ближайшим аналогом XPath. А в силу того, что объект находится по данному локатору быстрее, чем XPath, рекомендуется прибегать к помощи CSS вместо XPath.

Selenium Waits? Какие есть и чем отличаются

Implicit Wait (неявное ожидание) — пожалуй, самый популярный способ ожидания в Selenium благодаря своей легкости в использовании. Использование:

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

Explicit wait (явное ожидание) — чаще используется для ожидания определенного условия, которое должно быть выполнено прежде, чем тест пойдет дальше. Стоит помнить следующие вещи:

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

Какие exceptions может бросить Selenium? Что они означают и как их обрабатывать

ElementClickInterceptedException — команда [Клик] не могла быть выполнена должным образом, так как элемент, получающий команду каким-то образом скрыт (например, перекрыт другим элементом).

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

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

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

WebDriverException — возникает из-за несовместимости Selenium WebDriver и целевого веб-браузера.

Исключения в Selenium обрабатываются посредством использования try-catch блока

Для чего используют JavascriptExecutor? Приведите примеры.

JavascriptExecutor — это интерфейс Selenium, который позволяет выполнить JavaScript код. Например, ввести текст, сделать щёлчок по элементу и т.п.

Способы click и send keys Selenium

Через методы Селениума или через использование JavaScriptExecutor.

Как вы запускаете параллельное выполнение тестов? Что такое ThreadLocal

maven-surefire-plugin -> thread-count

Параллелизация сьютов между агентами на CI сервере

jUnit5
-Djunit.jupiter.execution.parallel.enabled=true
-Djunit.jupiter.execution.parallel.mode.default=concurrent

TestNG
TestNG(xmlSuite.setParallel(XmlSuite.ParallelMode.CLASSES))
TestNG(xmlSuite.setThreadCount(<n>) + xmlSuite.setDataProviderThreadCount(<m>))

java.lang.ThreadLocal — класс используется для хранения переменных, которые должны быть доступны для всего потока. Фактически это нечто вроде ещё одной области видимости переменных. Класс ThreadLocal имеет методы get и set, которые позволяют получить текущее значение и установить новое значение.
Обычно экземпляры ThreadLocal объявляются как приватные статические переменные в классе. Каждый поток получает из метода get своё значение и устанавливает через set тоже своё значение, изолированное от других потоков.

Разница между Action и Actions

Action — интерфейс, который представляет одно действие пользователя. Содержит один из наиболее широко используемых методов perform().

Actions — класс ориентированный на пользователя API для эмуляции сложных пользовательских действий. Класс Actions реализует паттерн Builder, который может создавать CompositeAction, содержащий все действия, указанные вызовами метода.

Как написать метод isElementPresent

public boolean isElementPresent(By by) {
    return driver.findElement(by).isDisplayed();
    }

Как вычитать данные из динамической веб-таблицы

Необходимо сначала определить количество колонок и столбцов в данный момент с помощью xPath и тэгов <td>, <tr>, а затем обращаться к определённой ячейке или итеративно получить данные из всех ячеек.

Можете ли вы назвать 10 интерфейсов в Selenium

WebDriver
Options
Capabilities
Timeouts
JavascriptExecutor
Action
LocalStorage
Logs
WrapsDriver
WrapsElement

Я не вижу практического применения в заучивании названий интерфейсов.

2 способа, позволяющих автоматизировать капчу

Боты с поддержкой оптического распознавания символов (OCR) — в этом подходе КАПЧА решается автоматически с помощью бота.
Услуги по решению капчи реальными людьми — в сервисе есть сотрудники, которые постоянно доступны онлайн для решения капчи. Когда вы отправляете свою КАПЧУ, компания пересылает ее работникам, которые ее решают, и отправляет обратно решения.

Типы команд Selenium

Действия – функциональное действие над тестируемым веб-приложением в браузере. Например, заполнение полей, нажатие на кнопку и т.п.
Проверки – выполнение проверок на тестируемой странице. Например, проверка того, что определенное поле формы имеет указанное значение, или проверка заголовка окна.
Ожидания – организация того как, сколько и какого события будет дожидаться Selenium (ожидания загрузки страницы, ajax и т.д.).

Как найти поврежденные ссылки в Selenium WebDriver

Собрать все ссылки на веб-странице на основе тега <a>.
Отправить HTTP-запрос для первой ссылки.
Получить HTTP-код ответа и узнать, является ли ссылка действительной или нет.
Повторить это для всех захваченных ссылок.

TestNG/JUnit

Для чего нужны TestNG/JUnit

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

Какие аннотации используются в TestNG/JUnit

TestNG:

@BeforeSuite / @AfterSuite
@BeforeTest / @AfterTest
@BeforeClass / @AfterClass
@BeforeGroups / @AfterGroups
@BeforeMethod / @AfterMethod
@Test
@DataProvider
@Factory
@Parameters
@Listener

jUnit 5:

@BeforeAll / @AfterAll
@BeforeEach / @AfterEach
@Test
@Disable
@Nested
@Tag
@TestFactory
@Suite / @SelectClasses / @SelectPackages / @IncludePackages / @ExcludePackages
@IncludeClassNamePatterns / @ExcludeClassNamePatterns / @IncludeTags / @ExcludeTags

Какие assertions есть в TestNG/JUnit

TestNG:

assertEquals() / assertNotEquals()
assertTrue() / assertFalse()
assertNull() / assertNotNull()
assertSame() / assertNotSame()
assertEqualsNoOrder()
fail()

jUnit 5:

assertTrue() / assertFalse()
assertEquals() / assertNotEquals()
assertArrayEquals()
assertIterableEquals()
assertLinesMatch()
assertNull() / assertNotNull()
assertSame() / assertNotSame()
assertTimeout() / assertTimeoutPreemptively()
assertThrows()
fail()

Как выполнять тесты параллельно TestNG/JUnit

Перевести драйвер браузера на ThreadLocal!

TestNG

TestNG (xmlSuite.setParallel(XmlSuite.ParallelMode.CLASSES))
TestNG (xmlSuite.setThreadCount(<n>) + xmlSuite.setDataProviderThreadCount(<m>))

jUnit 5

-Djunit.jupiter.execution.parallel.enabled=true
-Djunit.jupiter.execution.parallel.mode.default=concurrent

Git

Для чего используют системы контроля версий

Система контроля версий (Version Control System/VCS) — позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
VCS позволяет изменять одни и те же файлы нескольким разработчикам одновременно. При этом все варианты изменений сохраняются отдельно, и можно сделать разные варианты одного и того же файла с учетом разных правок от разных людей. Если же несколько изменений затрагивают один и тот же фрагмент документа, то система предложит выбрать нужный вариант.

Что такое Git? Каков принцип его работы

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

Что такое commits, branches в Git

Коммит (commit) — снимок изменений в репозитории.
Бранч (branch) — ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект.

Для чего нужны GitHub, GitLab и другие, базирующиеся на Git, вебхостинги проектов

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

CI

Что такое CI/CD/CD

Непрерывная интеграция (Continuous Integration/CI) — методология разработки и набор практик, при которых в код вносятся небольшие изменения с частыми коммитами. Поскольку большинство современных приложений разрабатываются с использованием различных платформ и инструментов, то появляется необходимость в механизме интеграции и тестировании вносимых изменений.
Цель CI — обеспечить последовательный и автоматизированный способ сборки, упаковки и тестирования приложений.

Непрерывная поставка (Continuous Delivery/CD) — основывается на автоматизации сборки и тестирования, которую вводит непрерывная интеграция. Она предполагает перевод ручных шагов, необходимых для выпуска сборки приложения в продакшн, на автоматизированный процесс.

Непрерывное развёртывание (Continuous Deployment/CD) — после автоматизации релиза остаётся один ручной этап: одобрение и запуск развёртывания в продакшен. Практика непрерывного развёртывания упраздняет это, не требуя непосредственного утверждения со стороны разработчика. Все изменения развёртываются автоматически.

Последовательность выполнения CI/CD процесса на проекте

Написание кода
Сборка
Тестирование
Релиз
Развертывание
Поддержка и мониторинг
Планирование

Как автоматическое тестирование интегрируется в CI

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

Какие инструменты для генерации репорта после выполнения автоматических тестов вы знаете

Allure, Serenity

Какую информацию должен содержать отчет о выполнении автоматических тестов

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

Технические пользователи — Test-manager. Для них приоритетно понимание хода тестирования, какие возникают проблемы, как они решаются, построение самого процесса тестирования, описание применяемых методов и технологий.
Product Manager, они же Менеджеры продукта. Их фокус сконцентрирован на сроках выполнения, выжимках из результатов тестирования без излишних технических подробностей и на общей статистике (цифровые и сравнительные метрики).
Бизнес-пользователи. Обычно это и есть те люди, которые принимают решения по завершению тестирования. Они же определяют качество проделанной работы. Для них, в первую очередь, важен конечный результат в максимально кратком и ясном формате (данет), наглядное представление информации (графики, диаграммы), экспертное мнение о возможности выпуска продукта в промышленную среду и т. п., без углубления в детали.

WEB

Клиент-серверная архитектура

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

Что может выступать в роли клиента

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

Что такое REST, SOAP? В чем разница

SOAP и REST — это два стиля API, которые подходят к вопросу передачи данных с разных точек зрения.

SOAP (Simple Object Access Protocol) — это стандартизированный протокол, который отправляет сообщения с использованием других протоколов, таких как HTTP и SMTP. Спецификации SOAP являются официальными веб-стандартами, которые поддерживаются и разрабатываются Консорциумом World Wide Web (W3C).

REST (Representational State Transfer) — это не протокол, в отличие от SOAP, а архитектурный стиль. Архитектура REST устанавливает набор рекомендаций, которым необходимо следовать, если вы хотите построить веб-службу RESTful, например, сервисы без сохранения промежуточного состояния или использование HTTP-кодов состояния.

Какие протоколы передачи данных знаете

IP (Internet Protocol) — протокол передачи, который первым объединил отдельные компьютеры в единую сеть. Один из самых простых. Он является ненадёжным, т.е. не подтверждает доставку пакетов получателю и не контролирует целостность данных. По протоколу IP передача данных осуществляется без установки соединения.

TCP/IP (Transmission Control Protocol/Internet Protocol) — стек протоколов TCP и IP. Первый обеспечивает и контролирует надёжную передачу данных и следит за её целостностью. Второй же отвечает за маршрутизацию для отправки данных.

UDP (User Datagram Protocol) — протокол, обеспечивающий передачу данных без предварительного создания соединения. Этот протокол является ненадёжным. В нём пакеты могут не только не дойти, но и прийти не по порядку или вовсе продублироваться. Основное его преимущество заключается в скорости доставки данных. Именно поэтому чувствительные к сетевым задержкам приложения часто используют этот тип передачи данных.

FTP (File Transfer Protocol) — протокол передачи файлов. Использовали ещё в 1971 году — задолго до появления протокола IP. На текущий момент этим протоколом пользуются при удалённом доступе к хостингам. FTP является надёжным протоколом, поэтому гарантирует передачу данных. Работает по принципу клиент-серверной архитектуры. Пользователь проходит аутентификацию (хотя может подключаться и анонимно) и получает доступ к файловой системе сервера.

HTTP (HyperText Transfer Protocol) — изначально протокол передачи HTML-документов. Сейчас же он используется для передачи произвольных данных в интернете. Он является протоколом клиент-серверного взаимодействия без сохранения промежуточного состояния. В роли клиента чаще всего выступает веб-браузер, хотя может быть и, например, поисковый робот. Для обмена информацией протокол HTTP в большинстве случаев использует TCP/IP. HTTP имеет расширение HTTPS (HTTP over TLS), которое поддерживает шифрование.

SSH (Secure Shell) — протокол удалённого управления ОС с использованием TCP. В SSH шифруется весь трафик, с возможностью выбора алгоритма шифрования. В основном это нужно для передачи паролей и другой важной информации. Также SSH позволяет обрабатывать любые другие протоколы передачи. Это значит, что кроме удалённого управления компьютером, через протокол можно пропускать любые файлы или даже аудио/видео поток. SSH часто применяется при работе с хостингами.

Какие способы взаимодействия с API существуют? В чем разница между ними

SOAP (Simple Object Access Protocol) — Простой Протокол Доступа к Объектам. Клиент и сервер обмениваются сообщениями посредством XML. Это менее гибкий API, который был более популярен в прошлом.
RPC (Remote Procedure Call) — Удалённый Вызов Процедур. Клиент выполняет функцию (или процедуру) на сервере, и сервер отправляет результат обратно клиенту.
Websocket – современная разработка web API, которая использует объекты JSON для передачи данных. WebSocket поддерживает двустороннюю связь между клиентскими приложениями и сервером. Сервер может отправлять сообщения обратного вызова подключенным клиентам, что делает его более эффективным, чем REST.
REST — на сегодняшний день это самые популярные и гибкие API-интерфейсы в Интернете. Клиент отправляет запросы на сервер в виде данных. Сервер использует этот клиентский ввод для запуска внутренних функций и возвращает выходные данные обратно клиенту.

Как можно протестировать API, что там нужно проверять

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

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

Проверка спецификации:

эндпоинты правильно именованы
ресурсы и их типы правильно отражают объектную модель
нет отсутствующей или дублирующей функциональности
отношения между ресурсами правильно отражаются в API

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

Корректность кода состояния HTTP (создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т.д.)
Полезная нагрузка ответа (правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы)
Заголовки ответа (заголовки HTTP-сервера влияют как на безопасность, так и на производительность)
Правильность состояния приложения (применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить)
Базовая работоспособность (если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден)

Форматы передачи данных

JSON (JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript, но при этом независим от JS.
XML (eXtensible Markup Language/расширяемый язык разметки) — используется для хранения и передачи данных. формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому часто используется для передачи данных по API. Единственно возможный формат входных и выходных данных в SOAP.
CSV (Comma-Separated Values/значения, разделенные запятыми) – текстовый формат, предназначенный для представления табличных данных с фиксированным количеством столбцов. Каждая строка файла — это одна строка таблицы.
YAML (YAML Ain’t markup language/YAML не язык разметки; ранее Yet Another Markup Language) — язык для сериализации данных, который позволяет хранить сложноорганизованные данные в компактном и читаемом формате. Похож на XML и JSON, но использует более минималистичный синтаксис при сохранении аналогичных возможностей.

Отличия между XML и JSON

XML — язык разметки.

JSON — формат для обмена данными, обычно реализуемый, как массив данных.

Ключевые различия:

Объект JSON имеет тип, тогда как объекты XML не содержат типов
В JSON проще получить объект нежели в XML (данные XML должны быть проанализированы)
Читабельность JSON файла выше по сравнению с XML
JSON не обеспечивает поддержку пространства имен, в то время как XML обеспечивает
JSON не имеет возможностей отображения, тогда как XML имеет такую возможность
JSON менее защищен, тогда как XML более безопасен по сравнению с JSON
JSON поддерживает только кодировку UTF-8, тогда как XML поддерживает различные кодировки

Как происходит шифрование

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

Ассиметричное — используются два ключа: открытый/публичный и закрытый/приватный. Преимущество ассиметричного шифрования в том, что один из ключей всегда остается на устройстве и не передается.
Схема передачи данных между двумя субъектами (А и Б) выглядит следующим образом:

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

Какие бывают виды БД

https://proglib.io/p/11-tipov-sovremennyh-baz-dannyh-kratkie-opisaniya-shemy-i-primery-bd-2020-01-07

Простейшие типы БД

Текстовые файлы, csv-файлы
Иерархические (файловые системы, DNS, LDAP)
Сетевые (IDMS)

Реляционные БД (MySQL, PostgreSQL..)
NoSQL БД

«Ключ-значение» (Redis, memcached)
Документные (MongoDB, RethinkDB)
Графовые (Neo4j, Dgraph)
Колоночные (Cassandra, HBase)
БД временных рядов (OpenTSDB, TimescaleDB)

Комбинированные типы БД

NewSQL (MemSQL, VoltDB, CockroachDB)
Многомодельные (OrientDB, Couchbase)

Охарактеризуйте каждый класс HTTP status code (1хх; 2xx; 3xx; 4xx; 5xx).

1xx: Informational (информационные)
2xx: Success (успешно)
3xx: Redirection (перенаправление)
4xx: Client Error (ошибка клиента)
5xx: Server Error (ошибка сервера)

Расшифровка CRUD

CRUD — акроним, обозначающий четыре базовые функции, используемые при работе с постоянными хранилищами данных: создание (create), чтение (read), модификация (update), удаление (delete).

Какие есть HTTP-методы

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

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

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

PUT — Загружает содержимое запроса на указанный в запросе URI. Если по заданному URI ресурса нет, то сервер создает его, возвращая статус 201 (Created).

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

DELETE — Удаляет указанный ресурс.

OPTIONS — Используется для описания параметров коммуникации между клиентом и сервером.

CONNECT — Преобразует соединение запроса в прозрачный TCP/IP-туннель.

Отличия GET от POST

Разница между методами PUT, POST, PATCH

POST — создание новой сущности. Может создавать коллекцию сущностей.
PUT — создание новой или полное обновление существующей сущности. Может работать только с одой сущностью.
PATCH — частичное обновление существующей сущности.

Какие знаете Web elements

Кнопки, лейблы, поля ввода, выпадающие списки, чекбоксы, радиобатоны, фреймы

Для чего необходимы инструменты разработчика в браузере (Chrome DevTools) и как они помогают в тестировании

Переопределение геолокации и подмена User-Agent
Определение JS пути к строке
Изменение HTML-кода и стилей CSS у элементов
Тестирование производительности и неиспользуемых CSS и Javascript в вёрстке
Debug JavaScript
Имитация медленного сетевого соединения
Мониторинг сетевых запросов
Информация о cookies во вкладке applications

Что такое кэш

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

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

Что такое сессия

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

Зачем нужны cookies

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

iFrame и как с ним работать в Selenium

Фрейм (Frame/iFrame) — самостоятельный документ, который отображается в отдельном окне браузера и представляет собой полностью законченную HTML-страницу. Простыми словами, фрейм — разделитель браузерных окон на отдельные области.

Способы переключаться на iframe:

По индексу driver.switchTo().frame(i);
По имени или идентификатору driver.switchTo().frame("a077aa5e");
По веб-элементу
driver.switchTo().frame(driver.findElement(By.cssSelector("#modal>iframe"));

Что такое HTML/CSS/JavaScript

HTML (HyperText Markup Language/язык гипертекстовой разметки) — стандартизированный язык разметки документов для просмотра веб-страниц в браузере.

CSS (Cascading Style Sheets/каскадные таблицы стилей) — формальный язык описания внешнего вида документа (веб-страницы), написанного с использованием языка разметки (чаще всего HTML или XHTML). Также может применяться к любым XML-документам, например, к SVG или XUL.

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

Какую структуру имеет веб-страница

Заголовок: <header>
Навигационное меню: <nav>.
Основное содержимое: <main>, с различными подразделами содержимого, представленными элементами <article>, <section> и <div>.
Боковая панель: <aside>, обычно располагается внутри <main>.
Нижний колонтитул: <footer>.

Зачем чистить кэш

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

Что такое AJAX

AJAX (Asynchronous JavaScript and XML/асинхронный JavaScript и XML) — технология описывающая как можно получать данные с сервера в фоновом режиме и использовать их для обновления страницы (без перезагрузки). Основная цель AJAX – это сделать сайты и веб-приложения более удобными, быстрыми и отзывчивыми.
Асинхронный потому, что действие выполняется в фоне (не в основном потоке), таким образом, что оно не мешает пользователю взаимодействовать со страницей.
JavaScript отвечает за создание и настройку запроса, отправку его на сервер, получение ответа и его разбор, обновление страницы.

Преимущества использования AJAX:

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

Mobile

Какие мобильные платформы существуют

Android
iOS

Какие версии Android и iOS используются на рынке (минимальные и максимальные)

Взят min в 1%

Android: 4.4 — 13

iOS: 12 — 15

Типы мобильных приложений

Игры для смартфона
Промо-приложения
Контентные сервисы
Социальные сети

Что такое ADB

ADB (Android Debug Bridge) — клиент-серверное приложение, которое предоставляет доступ к работающему эмулятору или устройству. С его помощью можно копировать файлы, устанавливать скомпилированные программные пакеты и запускать консольные команды.
Состоит из трёх компонентов:

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

Как снять логи с Android/IOS

Android:

Подсоедините ваше устройство
Подтвердите, что согласны подключить устройство к компьютеру (на устройстве)
Откройте командную строку Windows
adb devices
adb -s <device ID> logcat -> log.log
Воспроизведите проблему
Остановите процесс подключения (ctrl+c) или просто отсоедините устройство
В папке, из которой вы запустили командную строку, вы найдете файл log.log.

iOS (нужен MAC):

Запустите Xcode.
Подсоедините ваше устройство.
Нажмите на вкладку Window — выберите в выпадающем списке «Устройства».
Выберите ваше устройство.
Воспроизведите проблему.
Выберите log файл нажатием клавиш cmd+A
Сохраните файл.

Что такое Appium

Appium — бесплатный кроссплатформенный инструмент с открытым исходным кодом, который помогает автоматизировать приложения как для Android, так и для iOS. Appium придерживается того же подхода, что и Selenium WebDriver, который получает HTTP-запросы в формате JSON от клиентов и преобразует их в зависимости от платформы, на которой он работает.

Требования для Android:

Java (version >= 7)
Android SDK API (version >= 17)
Android Virtual Device (AVD) / real device
Intel Hardware Accelerated Execution Manager

Требования для iOS:

Mac OS X (version >= 10.7)
Xcode (version >= 5.1)
Java (version >= 7)
Homebrew
NodeJS
npm

Как запускать тесты Android без Appium

Espresso — официальный фреймворк для UI-тестирования, но тесты с его использованием работают по модели белого ящика (white-box). Espresso поддерживает Android API с 10 версии.
UiAutomator — официальный фреймворк для тестирования. Как GUI-драйвер он служит для поиска элементов интерфейса на экране девайса и эмуляции различных действий: кликов, тачей, свайпов, ввода текста, проверок на видимость. Позволяет писать тесты по модели черного ящика (black-box). Он живет в собственном процессе и работает без доступа к исходному коду приложения. Тест с его использованием может взаимодействовать практически с любыми приложениями, в том числе системными.
Robolectric — позволяет писать особые unit-тесты на основе JUnit с использованием Android API. Мокирует часть Android SDK, предоставляя пользователю так называемые shadow-объекты. Robolectric берет на себя такие задачи, как inflate view, загрузка ресурсов, и множество других, которые имеют нативную С-реализацию на Android-девайсах. Поэтому Robolectric позволяет писать тесты, имеющие зависимости на Android, но запускать их не на эмуляторе или реальном девайсе, а на десктопной JVM. Это существенно ускоряет процесс сборки, запуска и выполнения тестов.
Robotium
Selendroid

Источник

Тестовое
Покрытие (Test Coverage)

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

Если
рассматривать тестирование как «проверку
соответствия между реальным и ожидаемым
поведением программы, осуществляемая
на конечном наборе тестов», то именно
этот конечный набор тестов и будет
определять тестовое покрытие:

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

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

Существует
2 широко применяемых подхода к оценке
и измерению тестового покрытия:

Покрытие
требований (Requirements Coverage)
— оценка покрытия тестами функциональных
и нефункциональных требований к продукту
путем построения матриц трассировки
(traceability matrix).
Покрытие
кода (Code Coverage)
— оценка покрытия исполняемого кода
тестами, путем отслеживания непроверенных
в процессе тестирования частей
программного обеспечения.

Различия:
Метод
покрытия требований сосредоточен на
проверке соответствия набора проводимых
тестов требованиям к продукту, в то
время как анализ покрытия кода — на
полноте проверки тестами, разработанной
части продукта (исходного кода).

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

Покрытие
требований (Requirements Coverage)

Расчет
тестового покрытия относительно
требований проводится по формуле:

Tcov
= (Lcov/Ltotal) * 100%

где:
Tcov
— тестовое покрытие
Lcov
— количество требований, проверяемых
тест кейсами
Ltotal
— общее количество требований

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

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

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

Покрытие
кода (Code Coverage)

Расчет
тестового покрытия относительно
исполняемого кода программного
обеспечения проводится по формуле:

Tcov
= (Ltc/Lcode) * 100%

где:
Tcov
— тестовое покрытие
Ltc
— кол-ва строк кода, покрытых тестами
Lcode
— общее кол-во строк кода.

В
настоящее время существует инструментарий
(например: Clover),
позволяющий проанализировать в какие
строки были вхождения во время проведения
тестирования, благодаря чему можно
значительно увеличить покрытие, добавив
новые тесты для конкретных случаев, а
также избавиться от дублирующих тестов.
Проведение такого анализа кода и
последующая оптимизация покрытия
достаточно легко реализуется в рамках
тестирования белого ящика (white-box testing)
при модульном, интеграционном и системном
тестировании; при тестировании же
черного ящика (black-box testing) задача становится
довольно дорогостоящей, так как требует
много времени и ресурсов на установку,
конфигурацию и анализ результатов
работы, как со стороны тестировщиков,
так и разработчиков.

Техники
тест
дизайна
(Test Design Technics)

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

Предлагаем
вам ознакомиться с кратким описанием
наиболее распространенных техник тест
дизайна:

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

Практическое
применение техник тест дизайна при
разработке тест кейсов

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

Эквивалентное
Разделение (Equivalence Partitioning),
далее в тексте — EP
Анализ
Граничных Значений (Boundary Value Analysis),
далее в тексте — BVA
Предугадывание
ошибки (Error Guessing),
далее в тексте — EG
Причина
/ Следствие (Cause/Effect),
далее в тексте — CE

План
разработки тест кейсов
предлагается следующий:

Анализ
требований.
Определение
набора тестовых данных на основании
EP,
BVA,
EG.
Разработка
шаблона теста на основании CE.
Написание
тест кейсов на основании первоначальных
требований, тестовых данных и шагов
теста.

Далее
на примере, рассмотрим предложенный
подход.

Пример:

Протестировать
функциональность формы приема заявок,
требования к которой предоставлены в
следующей таблице:

Элемент	Тип элемента	Требования
Тип обращения	combobox	Набор данных: Консультация Проведение тестирования Размещение рекламы Ошибка на сайте * — на процесс выполнения операции приема заявок не влияет.
Контактное лицо	editbox	1. Обязательное для заполнения 2. Максимально 25 символов 3. Использование цифр и спец символов не допускается
Контактный телефон	editbox	Обязательное для заполнения Допустимые символы «+» и цифры «+» можно использовать только в начале номера Допустимые форматы: начинается с плюса — 11-15 цифр +31612361264 +375291438884 без плюса — 5-10 цифр, например: 0613261264 2925167
Сообщение	text area	1. Обязательное для заполнения 2. Максимальная длина 1024 символа
Отправить	button	Состояние: 1. По умолчанию — не активна (Disabled) 2. После заполнения обязательных полей становится активна (Enabled) Действия после нажатия 1. Если введенные данные корректны — отправка сообщения 2. Если введенные данные НЕ корректны — валидационное сообщение

Вариант
использования (иногда
его может и не быть):

Читаем,
анализируем требования и выделяем для
себя следующие нюансы:

какие
из полей обязательные для заполнения?
имеют
ли поля ограничения по длине или по
размерности (границы)?
какие
из полей имеют специальные форматы?

2.Определение набора тестовых данных

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

в
зависимости от того обязательное поле
или нет, определим какие поля необходимо
проверить на пустое значение, так как
оно может вызывать ошибку (В результирующей
таблице оранжевый
цвет)
т.к.
исчерпывающее тестирование не
представляется возможным из-за
огромного числа всевозможных комбинаций
значений,
в первую очередь необходимо определить
минимальный
набор данных.
Это можно сделать используя такие
техники,
как EP
и BVA.
(В результирующей таблице голубой
цвет)
На
форме присутствует поле, имеющее
составной тип (цифры используются
совместно с символами), обладает
специальным форматом данных и поэтому
выделение тестовых данных для него —
это достаточно трудоемкая задача. В
пределах данной статьи ограничимся
только простой проверкой форматов и
основных требований описанных в форме
приема заявок.
По
завершению генерации данных используя
стандартные техники, можно добавить
некоторое количество значений на
основании личного опыта (техника
EG)
— это будет использование спец. символов,
очень длинных строк, разных форматов
данных, регистров в строках (Upper, Lowwer,
Mixed cases), отрицательные и нулевые значения,
кейворды Null — NaN — Infinity и т.д. Сюда можно
включить все, что вы полагаете может
вывести приложение из строя (В
результирующей таблице фиолетовый
цвет)

Примечание:

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

2.1 Выбор тестовых данных для каждого отдельно взятого поля

Поле
Тип
обращения.
Так как все данные входят в 1 класс
эквивалентности, то есть не изменяют
сам процесс выполнения приема заявки,
берем любою (1-ю) позицию в листе с
ожидаемым пезультатом ОК. Но т.к.
реализовано поле как лист, имеет также
смысл рассмотреть и граничные условия
(техника BVA), т.е. берем первый и последний
элементы. Итого: 1-я и последняя позиции
в листе. Ожидаемый результат при
использовании — ОК.
Поле
Контактное
лицо.
Это обязательное поле размером от 1 до
25 символов (включая границы). Проверка
на обязательность добавляет к тестовым
данным пустое значение. Проведем анализ
граничных условий (BVA), получим набор:
0, 1, 2, 24, 25 и 26 символов. Пустое значение
(0 символов) уже было добавлено при
анализе обязательности поля для ввода,
поэтому при BVA мы не будем добавлять
его еще раз. (если его добавить второй
раз, произойдет дублирование тестовых
данных, которое не приведет к нахождению
новых дефектов, а значит повторное
добавление в домен не имеет смысла). В
связи с тем, что значения 2 и 24 символа
являются, с нашей точки зрения,
некритичными, их можно не добавлять. В
итоге получаем, что минимальный набор
данных для тестирования поля — это
строки 1 и 25 — ОК, и 0 (пустое значение),
26 символов — NOK.
поле
Контактный
телефон
состоит из нескольких частей: код
страны, код оператора, номер телефон
(который может быть составной и
разделенный дефисами). Для определения
правильного набора тестовых данных
необходимо рассматривать каждую
составную часть по-отдельности. Применяя
BVA и EP, получим:
- для
  номеров с плюсом
  По
  BVA получим номера с 10, 11, 12 и 14, 15, 16
  цифрами, где 10 и 16 — NOK, а 11, 12, 14, 15 —
  OK
  Рассматривая полученные данные с
  позиции EP выделим, что 11, 12, 14, 15 входят
  в один класс эквивалентности. Поэтому
  при тестировании мы можем использовать
  любое из них, но так как 11 и 15 — это
  границы интервала, то на наш взгляд их
  пропускать нельзя. Следовательно мы
  можем уменьшить набор значений до
  двух, исключив 12 и 14, а оставив 11 и 15 для
  проверки граничных условий.
  Итого
  имеем:
  11 и 15 цифр — OK, (+12345678901,
  +123456789012345)
  10 и 16 цифр — NOK; (+1234567890,
  +1234567890123456)
- для
  номеров без плюса:
  По
  BVA получим номера с 4, 5, 6 и 9, 10, 11
  цифрами.
  Действуя аналогично примеру
  для номеров телефонов с плюсом, исключим
  значения 6 и 9, оставив 5 и 10.
  Итого
  имеем:
  5 и 10 цифр — OK, (12345, 1234567890)
  4 и
  11 цифр — NOK; (1234, 12345678901)
поле
Сообщение.
подбор данных проводим по аналогии с
полем Контактное лицо. На выходе получаем
значения: строки 1 и 1024 — ОК, и 1025 символов
— NOK.

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

Поле	OK/NOK	Значение	Комментарий
Тип обращения	OK	Консультация	первый в списке
Ошибка на сайте	последний в списке
NOK
Контактное лицо	OK	йцукенгшщзйцукенгшщзйцуке	25 символов нижний регистр
a	1 символ
ЙЦУКЕНГШЩЗФЫВАПРОЛДЖЯЧСМИ	25 символов ВЕРХНИЙ регистр
ЙЦУКЕНГШЩЗфывапролджЯЧСМИ	25 символов СМеШаННыЙ регистр
NOK		пустое значение
йцукенгшщзйцукенгшщзйцукей	длина больше максимальной(26 символов
@#$%^&;.?,>\|/№»!()_{}[<~	спец. символы (ASCII)
1234567890123456789012345	только цифры
adsadasdasdas dasdasd asasdsads(…)sas	очень длинная строка (~1Mb)
Контактный телефон	OK	+12345678901	с плюсом — минимальная длина
+123456789012345	с плюсом — максимальная длина
12345	без плюса — минимальная длина
1234567890	без плюса — максимальная длина
NOK		пустое значение
+1234567890	с плюсом — < минимальной длины
+1234567890123456	с плюсом — > максимальной длины
1234	без плюса — < минимальной длины
12345678901	без плюса — > максимальной длины
+YYYXXXyyyxxzz	с плюсом — буквы вместо цифр
yyyxxxxzz	без плюса — буквы вместо цифр
+###-$$$-%^-&^-&!	спец. символы (ASCII)
1232312323123213231232(…)99	очень длинная строка (~1Mb)
Сообщение	OK	йццуйцуйц(…)йцу	максимальная длина (1024 символа)
NOK		пустое значение
йццуйцуйц(…)йцуц	длина больше максимальной (1025 символов)
adsadasdasdas dasdasd asasdsads(…)sas	очень длинная строка (~1Mb)
@##$$$%^&^&	только спец. символы (ASCII)

Соседние файлы в папке 03.11.13_1

Источник

		Пароль верный	Пароль неверный
Состояние 1	Клик на «Войти»	Состояние 5	Состояние 2
Состояние 2	1-я попытка	Состояние 5	Состояние 3
Состояние 3	2-я попытка	Состояние 5	Состояние 4
Состояние 4	3-я попытка	Состояние 5	Состояние 6
Состояние 5	Вход в систему
Состояние 6	Блокировка

Заказ	Размер	Город	Количество	Доставка	Время
Яблочный пирог	Маленький	Нью-Йорк	1	Адресная	Немедленно
Чизкейк	Средний	Лос-Анджелес	2	Самовывоз	К указанному времени
	Большой	Чикаго	3

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

ОСНОВНЫЕ ТЕРМИНЫ

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

ВИДЫ ТЕСТИРОВАНИЯ

ДОКУМЕНТАЦИЯ

1. Тестирование ПО Лекция 5. Методики тестирования

2. Позитивные и негативные тесты

3. «Черный ящик»

4. «Черный ящик»

5. Шаги

6. Стратегии

7. Классы эквивалентности

8. Классы эквивалентности

9. Классы эквивалентности

10. Классы эквивалентности

11. Граничное тестирование

12. Граничное тестирование

13. Преимущества и недостатки «ЧЯ»

14. Преимущества и недостатки «ЧЯ»

15. «Белый ящик»

16. Шаги

17. Шаги

18. Метрики

19. Преимущества и недостатки

20. Сравнение «ящиков»

21. «Серый» ящик

22. Выбор входных значений

23. Метод перебора

24. Случайные входные данные

25. Предугадывание

Что такое тест-дизайн?

Зачем нужен тест-дизайн?

Популярные техники тест-дизайна

Эквивалентное разделение

Пример эквивалентного разделения

Анализ граничных значений

Пример анализа граничных значений

Переход состояний

Пример диаграммы перехода состояний

Попарное тестирование

Пример попарного тестирования

Предугадывание ошибок

Пример предугадывания ошибок

Итоги

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

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

Техники тест-дизайна на примерах

Эквивалентное разбиение

Граничные значения

Таблица принятия решений

Попарное тестирование

Причина и следствие

Предугадывание ошибок

Итоги

ОСНОВНЫЕ ТЕРМИНЫ

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

ВИДЫ ТЕСТИРОВАНИЯ

ДОКУМЕНТАЦИЯ

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

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

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

Зачем тестировать ПО

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

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

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

Техники тест-дизайна

Что такое Regression и Confirmation тестирование, какая между ними разница

Частота регрессионного тестирования

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

Configuration Testing

Exploratory Testing

Black/Grey/White Box Testing

Performance Testing

Smoke и Sanity тестирование и какая между ними разница

Traceability Matrix

End-to-End тест

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

Испытание на основе рисков

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

«Парадокс пестицида»

Что такое Selenium и зачем его используют