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

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

это проверка, насколько реальное поведение системы или
продукта совпадает с ожидаемым.

Второе определение: это процесс поиска багов.

Ожидаемый результат

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

Фактический результат

поведение системы, наблюдаемое в
процессе работы с системой.

Баг

несоответствие фактического и ожидаемого результатов.

Процесс разработки ПО

это путь от
идеи до поддержки готового
продукта.

Этапы процесса разработки

Идея => Анализ требований => Спецификация и дизайн => Программирование => Тестирование => Внедрение, выпуск, релиз => Сопровождение.

Идея

описание цели.

Спецификация, рабочая концепция (РК), техническое задание
(ТЗ)

описание пути к достижению этой цели.

Разработчик (developer)

переводит вещи,
отраженные в ТЗ, на язык программирования.

Бизнес-логика

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

Юнит-тестирование (unit testing)

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

Тестирование критического пути (critical path test)

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

Функциональность, фича (functionality, feature)

это возможности продукта, предоставляемого пользователю.

Исполнение тестирования

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

Релиз

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

Фиксить (to fix)

исправлять ошибки в коде.

Рабочий процесс (workflow, flow)

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

Семь принципов тестирования

1. Тестирование показывает наличие дефектов;
2. Полное тестирование невозможно;
3. Раннее тестирование;
4. Скопление дефектов;
5. «Парадокс пестицида»;
6. Тестирование зависит от контекста;
7. Заблуждение об отсутствии ошибок.

Тестирование
(др. определение)

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

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

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

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

1. План тестирования;
2. Чек-листы;
3. Тест-кейсы;
4. Наборы тест-кейсов;
5. Отчеты о дефектах;
6. Отчет о результатах тестирования.

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

1. Что надо тестировать;
2. Что будем тестировать;
3. Как будем тестировать;
4. Тестовые окружения, на которых необходимо проверять программный продукт;
5. Когда будете тестировать;
6. Риски и стратегии по их разрешению.

Окружение

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

Версия приложения

«номер партии» программного
продукта, номер релиза.

Что относится к окружению

1. Версия приложения — версия тестируемого продукта;
2. Браузер, в котором тестируется веб-приложение —название и версия (только для веб-приложений);
3. ОС — тип и версия операционной системы;
4. Устройство — тип и модель.

Чек-лист (check-list)

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

Чек-лист представляет собой список, который может быть:

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

Зачем нужен чек-лист?

1. Не забыть требуемые тесты;
2. Для деления задач по уровню квалификации;
3. Для сохранения отчётности и результатов тестирования.

Создание отдельных чек-листов для:

1. различных уровней функционального тестирования;
2. отдельных частей приложения;
3. отдельных требований, групп требований, уровней и типов требований;
4. типичных пользовательских сценариев;
5. частей или функций приложения, наиболее подверженных
рискам.

Логи (logs),
лог-файлы,
журнал

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

Сборка (build)

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

Интерфейс, пользовательский интерфейс, UI

«внешняя»
часть ПО; то, что видит и с чем взаимодействует пользователь.

Фронт-энд

функциональность и пользовательский
интерфейс, работающие на клиентской части приложения
или веб-сайта.

Бэк-энд

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

Степень важности функций приложений

1. Базовые функции, без которых существование приложения теряет смысл;
2. Функции, востребованные типичными пользователями в их повседневной работе;
3. Остальные функции.

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

1. По степени важности тестируемых функций;
2. По цели тестирования;
3. По объекту тестирования;
4. По доступу к коду;
5. По привлечению конечных пользователей;
6. По критерию позитивности сценариев;
7. По степени изолированности тестируемых компонентов;
8. По степени автоматизированности тестирования;
9. По степени подготовки к тестированию;
10. По цели тестирования;
11. По запуску кода на исполнение.

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

1. Дымовое тестирование (smoke testing);
2. Тестирование критического пути (critical path testing);
3. Расширенное тестирование (extended testing);
4. Приемочное тестирование (acceptance testing).

Дымовое тестирование (smoke testing)

(Классификация по степени важности тестируемых функций)

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

Тестирование критического пути
(critical path testing)

(Классификация по степени важности тестируемых функций)

При тестировании критического пути проверяются сценарии типичных пользователей в типичной деятельности

Расширенное тестирование
(extended testing)

(Классификация по степени важности тестируемых функций)

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

Приемочное тестирование
(acceptance testing)

(Классификация по степени важности тестируемых функций)

- Вид тестирования, проводимый на этапе сдачи продукта заказчику;
- Цель – определить готовность продукта перед его выпуском;
- Проверяется только основной функционал на соответствие требованиям;
- Может проводиться самим заказчиком.

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

1. Дымовое тестирование (smoke testing);
2. Тестирование на «вменяемость» (sanity testing);
3. Тестирование новой функции (new feature testing);
4. Повторное тестирование (re-testing);
5. Регрессионное тестирование (regression testing).

Тестирование на «вменяемость»
(sanity testing)

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

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

Тестирование новой функции
(new feature testing)

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

Тестирование новой функциональности, появившейся в конкретном выпуске (release) или сборке (build) программного продукта.

Повторное тестирование
(re-testing)

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

Проводится для подтверждения исправления ошибки и
корректности работы данного функционала

Регрессионное тестирование
(regression testing)

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

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

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

1. Функциональное тестирование;
2. Нефункциональное тестирование (тестирование: интерфейса пользователя, юзабилити, локализации, производительности, безопасности, совместимости).

Функциональное тестирование

(Классификация по объекту тестирования)

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

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

(Классификация по объекту тестирования)

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

Тестирование интерфейса пользователя
(user interface testing, UI)

(Нефункциональное тестирование)

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

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

(Нефункциональное тестирование)

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

Тестирование локализации

(Нефункциональное тестирование)

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

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

(Нефункциональное тестирование)

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

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

(Нефункциональное тестирование)

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

Три важных фактора для тестирования безопасности

(Нефункциональное тестирование)

1. Целостность: ограничение круга пользователей, имеющих доступ к данным;
2. Доступность: ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству;
3. Конфиденциальность: при каких условиях пользователь авторизован получить доступ к данным.

Кросс-
браузерное тестирование

тестирование с разными браузерами.

Кросс-
платформенное тестирование

тестирование с разными ОС.

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

(Нефункциональное тестирование)

Проверка того, как продукт взаимодействует с «Железом» (аппаратным обеспечением, hardware), ПО (браузерами/операционными системами) пользователей, кросс-браузерное и кросс-платформенное тестирование.

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

1. Черный ящик (black box testing);
2. Белый ящик (white box testing);
3. Серый ящик (grey box testing).

Черный ящик
(black box testing)

(Классификация по доступу к коду)

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

Белый ящик
(white box testing)

(Классификация по доступу к коду)

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

Серый ящик
(grey box testing)

(Классификация по доступу к коду)

- Комбинация white box и black box подходов;
- Внутреннее устройство программы известно лишь частично;
- Тестировщик смотрит на объект проверки с позиции черного ящика, но проводит анализ системы с точным расчетом данных, которые ему предварительно известны.

Классификация видов тестирования по привлечению конечных пользователей

1. Альфа-тестирование (alpha testing);
2. Бета-тестирование (beta testing);
3. Гамма-тестирование (gamma testing).

Альфа-тестирование (alpha testing)

(Классификация по привлечению конечных пользователей)

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

Бета-тестирование
(beta testing)

(Классификация по привлечению конечных пользователей)

Использование почти готового продукта с привлечением ограниченного числа внешних пользователей.

Гамма-тестирование (gamma testing)

(Классификация по привлечению конечных пользователей)

Исправление последних дефектов, идеи и улучшения. Часто происходит уже после выпуска.

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

1. Позитивное тестирование (positive testing);
2. Негативное тестирование (negative testing).

Позитивное тестирование (positive testing)

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

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

Негативное тестирование (negative testing)

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

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

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

1. Компонентное (component testing);
2. Интеграционное (integration testing);
3. Системное (system testing).

Компонентное
(component testing)

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

тестирование на уровне логического компонента.

Интеграционное
(integration testing)

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

тестирование на уровне двух или больше компонентов.

Системное
(system testing)

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

проверка всей системы от начала до конца.

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

1. Ручное тестирование (manual testing);
2. Автоматизированное тестирование (automated testing);
3. Смешанное/полуавтоматизированное тестирование.

Ручное тестирование
(manual testing)

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

Исполнение тест-кейсов без помощи каких-либо программ,
автоматизирующих работу.

Автоматизированное тестирование
(automated testing)

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

Инструменты для помощи в черноящичном и сероящичном тестировании.

Смешанное/полуавтоматизированное тестирование

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

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

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

1. Тестирование по тест кейсам (scripted testing);
2. Исследовательское тестирование (exploratory testing);
3. Интуитивное тестирование (ad-hoc testing).

Тестирование по тест кейсам
(scripted testing)

(Классификация по степени подготовки к тестированию)

Создание тест-кейсов для тестирования.

Исследовательское тестирование
(exploratory testing)

(Классификация по степени подготовки к тестированию)

Одновременное изучение программного продукта, проектирование тестов и их выполнение.

Интуитивное тестирование (ad-hoc testing)

(Классификация по степени подготовки к тестированию)

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

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

1. Динамическое (dynamic testing);
2. Статическое (static testing): документы, графические прототипы/эскизы, код приложения, настройки приложения, тестовые данные.

Динамическое
(dynamic testing)

(Классификация по запуску кода на исполнение)

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

Статическое
(static testing)

(Классификация по запуску кода на исполнение)

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

Тест-кейс
(test case)

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

Виды тест-кейсов

1. Высокоуровневый тест-кейс (high level test case);
2. Низкоуровневый тест-кейс (low level test case).

Высокоуровневый тест-кейс
(high level test case)

тест-кейс без конкретных входных данных и ожидаемых результатов.

Низкоуровневый тест-кейс
(low level test case)

тест-кейс с конкретными входными данными и ожидаемыми результатами.

Тестовое покрытие (test coverage)

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

Цель написания тест-кейсов

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

Поля тест-кейса

1. Идентификатор (ID);
2. Приоритет (Priority);
3. Связанная информация (Related task);
4. Название (Summary);
5. Предусловия (Preconditions);
6. Шаги воспроизведения (Steps to reproduce);
7. Ожидаемый результат (Expected Result).

Идентификатор
(ID)

(описание поля
тест-кейса)

Должен быть уникальным (т.е. не повторяться).

Приоритет
(Priority)

(описание поля
тест-кейса)

Пример:
A – высокий
B – средний
C – низкий
D – незначительный

Связанная информация
(Related task)

(описание поля
тест-кейса)

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

Название
(Summary)

(описание поля
тест-кейса)

[Модуль]. [Подмодуль]. Краткое описание

Предусловия
(Preconditions)

(описание поля
тест-кейса)

Приготовления перед выполнением тест-кейса; описание окружения.

Шаги воспроизведения
(Steps to reproduce)

(описание поля
тест-кейса)

Список шагов для выполнения тест-кейса.

Ожидаемый результат
(Expected Result)

(описание поля
тест-кейса)

Может прописываться по конкретным шагам, а может быть общим для всего тест-кейса.

Заглавие (название) должно быть:

(тест-кейсы)

1. Информативным;
2. Хотя бы относительно уникальным (чтобы не путать разные тест-кейсы);
3. Кратким и емким, четко отражающим суть тест-кейса.

Подход к составлению тест кейсов

1. Один тест-кейс – одна проверка:
- Пути пользователя от цели до результата;
- Типа вводимых данных;
2. Разделение позитивных и негативных тестов;
3. Оптимизация = Краткость + Емкость + Понятность.

Набор тест-кейсов (test case suite, test suite, test set)

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

Наборы тест-кейсов

1. Свободный набор;
2.Последовательный набор.

Преимущества свободных наборов

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

Преимущества последовательных наборов

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

Принципы построения наборов тест-кейсов

1. На основе чек-листов;
2. По видам тестирования;
2.1. По принципу проверки самых важных, менее важных и всех остальных функций приложения;
3. На основе разбиения приложения на модули и подмодули;
4. По принципу частоты обнаружения тест-кейсами дефектов в приложении.

Шаги воспроизведения

(тест-кейс)

1. Начинайте с понятного и очевидного места, но не пишите лишних начальных шагов;
2. Если пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить»);
3. Соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т.д.
4. Пишите шаги последовательно, без условных конструкций вида «если… то…»

Ожидаемый результат

(тест-кейс)

1. Описывайте поведение системы так, чтобы исключить субъективное толкование;
2. Пишите ожидаемый результат по всем шагам, если у вас есть хоть малейшие сомнения в том, что результат некоего;
шага будет совершенно тривиальным и очевидным;
3. Пишите кратко, но не в ущерб информативности;
4. Избегайте условных конструкций вида «если… то…».

Свойства качественных
тест-кейсов

1. Правильный технический язык;
2. Соответствие принятым шаблонам оформления;
3. Баланс между специфичностью и общностью;
4. Один тест-кейс – одна проверка;
5. Последовательность в достижении цели;
6. Отсутствие лишних действий.

Почему плоха излишняя специфичность?

(тест-кейс)

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

Почему плоха излишняя общность?

(тест-кейс)

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

Преимущества простых тест-кейсов

1. Их можно быстро прочесть, легко понять и выполнить;
2. Понятны начинающим тестировщикам и новым людям на проекте;
3. Делают наличие ошибки очевидным;
4. Упрощают начальную диагностику ошибки, т.к. сужают круг поиска.

Преимущества сложных
тест-кейсов

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

Как хорошо писать тест-кейсы

1. Разделять систему на составляющие – делать декомпозицию – раскладывать ее на составные части;
2. Собирать и анализировать требования к продукту;
3. Верно расставлять приоритеты;
4. Формулировать свои мысли в понятном для других виде;
5. Знать и применять техники тест-дизайна.

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

1. Что перед вами?
2. Кому и зачем оно нужно (и насколько это важно)?
3. Как оно обычно используется?
4. Как оно может сломаться, т.е. начать работать неверно?

Системы хранения тестов

1. MS Office, Google Docs;
2. Интеллект-карты (mind maps);
3. JIRA (Zephyr);
4. JIRA Cloud;
5. TestLink.

Отчёт о дефекте (defect report, bug report)

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

Для чего нужен отчет о дефекте?

- Предоставить информацию о проблеме
- Приоритизировать проблему
- Содействовать устранению проблемы

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

1. Идентификатор (ID);
2. Краткое описание, заглавие
(summary);
3. Подробное описание
(description);
4. Воспроизводимость;
5. Приоритет;
6. Приложения.

Идентификатор
(ID)

(описание поля
отчета о дефекте)

Должен быть уникальным (т.е. не повторяться)

Краткое описание, заглавие
(summary)

(описание поля
отчета о дефекте)

Что? Где? При каких условиях?

Подробное описание
(description)

(описание поля
отчета о дефекте)

1. Подробное описание проблемы;
2. Подготовительные действия;
3. Шаги воспроизведения;
4. Ожидаемый результат;
5. Фактический результат;
6. Дополнительная информация.

Воспроизводимость

(описание поля
отчета о дефекте)

Удается ли вызвать дефект при каждом
воспроизведении.

Приоритет

(описание поля
отчета о дефекте)

Важность и срочность дефекта

Приложения

(описание поля
отчета о дефекте)

Любые вложения для более наглядного описания:
- Скриншоты;
- Скринкасты;
- Логи.

Важность

(Приоритет)

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

Срочность

(Приоритет)

показывает, как быстро дефект должен быть устранён.

Виды приоритетов

1. Blocker;
2. Critical;
3. Major;
4. Minor;
5. Trivial.

Blocker

(Приоритет)

баг блокирует дальнейшую работу приложения или процесс тестирования.

Critical

(Приоритет)

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

Major

(Приоритет)

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

Minor

(Приоритет)

указывается при незначительном влиянии на эталонное поведение ПО.

Trivial

(Приоритет)

баг не оказывает влияния на функционал и поведение ПО.

При создании отчёта о дефекте рекомендуется следовать
следующему алгоритму:

1. Понять суть проблемы.
2. Сформулировать суть проблемы в виде «что сделали, что получили, что ожидали получить».
3. Заполнить поля отчёта, начиная с подробного описания.
4. После заполнения всех полей внимательно перечитать отчёт, исправив неточности и добавив подробности.
5. Ещё раз перечитать отчёт, т.к. в пункте 4 вы точно что-то упустили.

Типичные ошибки при написании
отчётов о дефектах

1. Ошибки формулировок;
2. Ошибки оформления;
3. Логические ошибки;
4. Проверки.

Цель тест-дизайна

Оптимальное тестовое покрытие тестируемого приложения:
- Минимум тестов;
- Максимум выявленных дефектов.

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

1. Низкоуровневые техники;
2. Техники среднего уровня;
3. Высокоуровневые техники.

Низкоуровневые техники

(Уровни тестов)

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

Техники среднего уровня

(Уровни тестов)

проверка логики работы системы при комбинации данных в элементах системы.

Высокоуровневые техники

(Уровни тестов)

проверка бизнес- процесса системы и логики работы программы.

Виды низкоуровневых техник

(Уровни тестов)

1. Разбиение на классы эквивалентности;
2. Анализ граничных значений;
3. Доменный анализ.

Эквивалентные значения

(Классы эквивалентности)

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

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

наборы значений, внутри которых значения эквивалентны друг другу.

Набор входных данных формирует класс эквивалентности, если предполагаем, что:

1. Они все проверяют одно и то же;
2. Если один набор ловит ошибку, то и остальные, вероятно, тоже ее поймают;
3. Если один набор не ловит ошибку, то и остальные, вероятно, тоже ее не поймают.

Множества значений

(Классы эквивалентности)

1. Линейные;
2. Нелинейные.

Линейные

(Множества значений)

- Представлены на числовой прямой или в виде упорядоченных множеств;
- Можно сравнить друг с другом.

Например: Количество, длина, размер, время, скорость.

Нелинейные

(Множества значений)

Все остальные что не относятся к линейным.

Например: Множество специальных символов, которые можно ввести с клавиатуры.

Разбиение на классы эквивалентности

1. Линейный диапазон;
2. Набор неупорядоченных данных.

Линейный диапазон

(Разбиение на классы эквивалентности)

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

Набор неупорядоченных данных

(Разбиение на классы эквивалентности)

Выделяются как минимум два класса:
- Валидные значения;
- Невалидные значения.

Алгоритм использования техники

(Классы эквивалентности)

1. Определить классы эквивалентности. Это главный шаг техники. От него во многом зависит эффективность её применения.
2. Выбрать одного представителя от каждого класса. На этом шаге из каждого эквивалентного набора тестов мы выбираем одно значение для теста.
3. Выполнить тесты. На этом шаге мы выполняем тесты для каждого класса эквивалентности.

Достоинства и недостатки

(Классы эквивалентности)

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

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

(Низкоуровневые техники)

- Это техника проверки ошибок на границах классов эквивалентности;
- Цель - найти ошибки, связанные с граничными значениями.

C граничными значениями связаны риски:

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

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

Типы границ

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

1. Логическая;
2. Физическая;
3. Технологическая;
4. Произвольная.

Логическая

(Типы границ. Анализ граничных значений)

ограничение, накладываемое логикой.

Например:
- Скидка не может быть больше 100%;
- Длина строки не может быть отрицательной.

Физическая

(Типы границ. Анализ граничных значений)

не может существовать, физически нельзя
преодолеть.

Например:
- Попытка ввести строку отрицательной длины.

Технологическая

(Типы границ. Анализ граничных значений)

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

Например:
- Граница типа переменной в языке программирования

Произвольная

(Типы границ. Анализ граничных значений)

ограничение, накладываемое аналитиком
или разработчиком.

Например:
- Длина поля максимум 250 символов

Алгоритм использования техники

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

1. Выделить классы эквивалентности;
2. Определить граничные значения этих классов;
3. Понять, к какому классу будет относиться каждая граница;
4. Для каждой границы провести 3 теста:
- До границы;
- На границе;
- После границы.

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

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

1. Учитывать тип данных тестируемого объекта;
2. Проверять значения максимально близко к границе;
3. Отдельно проверять нулевое или пустое значение.

Доменный анализ

(Низкоуровневые техники)

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

Доменное тестирование
(domain testing, domain analysis)

(Низкоуровневые техники)

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

Доменный анализ.
Суть техники.

(Низкоуровневые техники)

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

Точки

(Доменный анализ)

1. In (typical) – точки валидного диапазона
2. Out – точки невалидного диапазона
3. On
3.1 Всегда лежит на границе
3.2 Может быть либо In, либо Out
4. Off
4.1 Не лежит на границе, но максимально близка к границе (к On)
4.2 Может быть либо In, либо Out - зависит от «валидности» On
- Если On «валидна» - In, то Off «невалидна» - Out
- Если On «невалидна» - Out, то Off «валидна» - In

Алгоритм использования техники

(Доменный анализ)

1. Выбираем параметры для
тестирования
2. Определяем границы
параметров
3. Определяем специальные точки
для параметров
- On
- Off
- In (typical)
4. Строим тесты

Правила выбора необходимых точек

(Доменный анализ)

- Для каждого условия неравенства (≥, >, ≤ или <) выбрать одну точку On и одну точку Off;
- Для каждого условия равенства (=) выбрать одну точку On и две точки Off - одну левее, чем граничное значение в условии, и одну правее, чем граничное значение в условии;
- Для каждого параметра должна быть выбрана только одна In (typical).

Отчет по результатам тестирования

1. Документ, содержащий информацию о выполненных действиях и результаты этой работы.
2. В общем виде:
- Что тестировали?
- Как тестировали?
- Какие выводы можете сделать?

Виды техник среднего уровня

(Уровни тестов)

К ним относится тестовая комбинаторика которая включает в себя:
- Полный перебор;
- Метод минимальных проверок;
- Атомарные проверки;
- Pairwise.

Полный перебор

(Тестовая комбинаторика)

Количество тестов =
произведению количества
всех значений всех
параметров.

Плюсы, минусы, когда применять.

(Полный перебор. Тестовая комбинаторика)

- Плюс: максимальное покрытие;
- Минус: максимум тестов;
- Когда применяем:
1. Мало значений и параметров;
2. Важный функционал;
3. Автоматизация.

Метод минимальных проверок

(Тестовая комбинаторика)

Количество тестов = максимальному количеству значений у параметра.

Плюсы, минусы, когда применять.

(Метод минимальных проверок. Тестовая комбинаторика)

- Плюс: минимум тестов;
- Минус: минимальное покрытие;
- Когда применяем:
1. Мало времени;
2. Нужна быстрая проверка.

Атомарные проверки

(Тестовая комбинаторика)

Количество тестов =
количеству всех значений
– количество всех
параметров + 1.

Плюсы, минусы, когда применять.

(Атомарные проверки. Тестовая комбинаторика)

- Плюсы: легко локализуемые ошибки;
- Когда применяем:
1. Найти ошибку;
2. Проверить наиболее важный набор значений (первая
строка).

Как можно применять тестовую комбинаторику:

(Виды техник среднего уровня)

1. Техники можно сочетать;
- Проверять, что тест-кейсы не дублируются.
2. Можно убирать те тест-кейсы, которые не имеют смысла;
или невозможно проверить
3. Стараемся разделать позитивные и негативные проверки;
- Позитивные – отдельно;
- Негативные – как дополнение.

Data Driven Testing – тесты, управляемые
данными

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

Pairwise

(Тестовая комбинаторика)

это попарное тестирование. Эта техника поможет сократить количество тестов. Для этого берем пары значений и проверяем все сочетания пар.

Суть техники:

(Pairwise. Тестовая комбинаторика)

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

Алгоритм использования техники

(Pairwise. Тестовая комбинаторика)

1. Определить параметры;
2. Определить их значения;
3. Оптимизировать значения;
4. Описать условия и зависимости;
5. Построить тестовую таблицу.

Инструменты для построения таблиц

(Pairwise. Тестовая комбинаторика)

1. PICT;
2. Allpairs.

Виды высокоуровневых техник

(Уровни тестов)

К ним относится сценарии использования и тестирование состояний и переходов которая включает в себя:
- Диаграммы;
- Таблицы.

Диаграммы состояния и переходов

(Тестирование состояния и переходов. Виды высокоуровневых техник)

Похожи на блок-схемы (flowchart). Имеют ряд обозначений:
- Начальное состояние;
- Состояние;
- Переход;
- Событие;
- Действие;
- Условие;
- Конечное состояние.

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

(Тестирование состояния и переходов)

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

Определение тестов при использовании диаграмм состояний и переходов

(Тестирование состояния и переходов)

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

Таблицы состояний и переходов. Как заполнять.

(Тестирование состояния и переходов)

- Перечислить все возможные состояния;
- Перечислить все комбинации событий/условий;
- Скомбинировать все состояния с каждым событием;
- Занести эти комбинации в первые 2 столбца таблицы;
- Заполнить последние два столбца таблицы действиями и новыми состояниями.
- Пройтись по всем валидным комбинациям!
- В зависимости от системного риска, создать тест-кейсы для некоторых (или всех) недопустимых пар «состояние/событие» для того, чтобы убедиться, что система не реализует неверные пути.

Таблицы состояний и переходов. Преимущества и недостатки.

(Тестирование состояния и переходов)

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

Сценарии использования (use-cases)

(Виды высокоуровневых техник)

это сценарии взаимодействия пользователя и системы.

Алгоритм использования техники

(Сценарии использования. Виды высокоуровневых техник)

1. Найти пользователя и цель;
2. Записать основной сценарий;
3. Продумать альтернативы;
4. Выделить параметры;
5. Собрать всё вместе.

Основное действующее лицо

(Определение. Сценарии использования)

участник (некто или нечто), инициирующее взаимодействие с системой для достижения некоторой цели.

Альтернативные сценарии

(Определение. Сценарии использования)

это отклонения от основного сценария (как позитивные, так и негативные).

Параметры

(Определение. Сценарии использования)

это когда одну операцию можно выполнить разными способами, но сам сценарий от этого не меняется.
Другое определение: это когда В ОДНОМ И ТОМ ЖЕ событии есть
несколько вариаций, как его совершить.

Альтернатива

(Определение. Сценарии использования)

это когда ВМЕСТО исходного события происходит другое.

Таблицы решений

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

Преимущества таблиц решений

- Готовый инструмент;
- Легкое понимание;
- Легко создавать и поддерживать;
- Быстро проверять.

CRUD

C - create, R - read, U - update, D - delete. Подход применяется в тестировании при работе с объектами.

Автоматизация тестирования

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

Преимущества автоматизации

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

Недостатки автоматизации

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

Случаи наибольшей применимости
автоматизации

(Часть 1)

- Регрессионное тестирование;
- Инсталляционное тестирование и настройка тестового окружения;
- Конфигурационное тестирование и тестирование совместимости;

Случаи наибольшей применимости
автоматизации

(Часть 2)

- Использование комбинаторных техник тестирования;
- Тестирование безопасности;
- Тестирование производительности;
- Приемочный тест для крупных систем;
- Приложения (или их части) без графического интерфейса;

Случаи наибольшей применимости
автоматизации

(Часть 3)

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

Случаи наименьшей применимости
автоматизации

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