Вы находитесь на странице: 1из 11

Упрощенная классификация тестирования

Тестирование можно классифицировать по очень большому количеству признаков, и


практически в каждой серьёзной книге о тестировании автор показывает свой (безусловно
имеющий право на существование) взгляд на этот вопрос.
Соответствующий материал достаточно объёмен и сложен, а глубокое понимание каждого
пункта в классификации требует определённого опыта, потому мы разделим данную тему на
две: сейчас мы рассмотрим самый простой, минимальный набор информации, необходимый
начинающему тестировщику, а в следующей главе приведём подробную классификацию.
Используйте нижеприведённый список как очень краткую «шпаргалку для запоминания». Итак,
тестирование можно классифицировать (рисунок 1):

Рисунок 1. Упрощенная схема классификации тестирования

 По запуску кода на исполнение:


- Статическое тестирование — без запуска.
- Динамическое тестирование — с запуском.
 По доступу к коду и архитектуре приложения:
- Метод белого ящика — доступ к коду есть.
- Метод чёрного ящика — доступа к коду нет.
- Метод серого ящика — к части кода доступ есть, к части — нет.
 По степени автоматизации:
- Ручное тестирование — тест-кейсы выполняет человек.
- Автоматизированное тестирование — тест-кейсы частично или полностью выполняет
специальное инструментальное средство.
 По уровню детализации приложения (по уровню тестирования):
- Модульное (компонентное) тестирование — проверяются отдельные небольшие части
приложения.
- Интеграционное тестирование — проверяется взаимодействие между несколькими
частями приложения.
- Системное тестирование — приложение проверяется как единое целое.
 По (убыванию) степени важности тестируемых функций (по уровню функционального
тестирования):
- Дымовое тестирование1 - это проверка самой важной, самой ключевой
функциональности, неработоспособность которой делает бессмысленной саму идею
использования приложения.

1
Smoke Test (англ. Smoke testing, дымовое тестирование) в тестировании программного обеспечения означает минимальный
набор тестов на явные ошибки. «Дымовой тест» обычно выполняется самим программистом; не проходившую этот тест
программу не имеет смысла отдавать на более глубокое тестирование. Первое своё применение этот термин получил у
печников, которые, собрав печь, закрывали все заглушки, затапливали её и смотрели, чтобы дым шёл только из положенных
мест.
- Тестирование критического пути — проверка функциональности, используемой
типичными пользователями в типичной повседневной деятельности.
- Расширенное тестирование — проверка всей (остальной) функциональности,
заявленной в требованиях.
 По принципам работы с приложением:
- Позитивное тестирование — все действия с приложением выполняются строго по
инструкции без никаких недопустимых действий, некорректных данных и т.д. Можно
образно сказать, что приложение исследуется в «тепличных условиях».
- Негативное тестирование — в работе с приложением выполняются (некорректные)
операции и используются данные, потенциально приводящие к ошибкам (классика
жанра — деление на ноль).

Подробное описание классифицирующих признаков


Классификация по запуску кода на исполнение
Далеко не всякое тестирование предполагает взаимодействие с работающим приложением.
Потому в рамках данной классификации выделяют:
Статическое тестирование (static testing) — тестирование без запуска кода на исполнение. В
рамках этого подхода тестированию могут подвергаться:
 Документы (требования, тест-кейсы, описания архитектуры приложения, схемы баз
данных и т.д.).
 Графические прототипы (например, эскизы пользовательского интерфейса).
 Код приложения (что часто выполняется самими программистами в рамках аудита кода
(code review), являющегося специфической вариацией взаимного просмотра в
применении к исходному коду). Параметры (настройки) среды исполнения приложения.
 Подготовленные тестовые данные.
Динамическое тестирование (dynamic testing) — тестирование с запуском кода на
исполнение. Запускаться на исполнение может как код всего приложения целиком (системное
тестирование), так и код нескольких взаимосвязанных частей (интеграционное тестирование),
отдельных частей (модульное или компонентное тестирование) и даже отдельные участки
кода. Основная идея этого вида тестирования состоит в том, что проверяется реальное
поведение (части) приложения.

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


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

 Дают гарантию того, что все независимые пути в модуле проверены по крайней мере
один раз.
 Проверяют все логические решения на предмет того, истины они или ложны.
 Выполняют все циклы внутри операционных границ и с использованием граничных
значений.
 Исследуют структуры внутренних данных с целью проверки их достоверности.
Тестирование посредством белого ящика, как правило, включает в себя стратегию модульного
тестирования, при котором тестирование ведется на модульном или функциональном уровне
и работы по тестированию направлены на исследование внутреннего устройства модуля.
Данный тип тестирования называют также модульным тестированием, тестированием
прозрачного ящика (clear box) или прозрачным (translucent) тестированием, поскольку
сотрудники, проводящие тестирование, имеют доступ к программному коду и могут видеть
работу программы изнутри.
На этом уровне тестирования проверяется управляющая логика, проявляющаяся на
модульном уровне. Все пути в данном модуле будут проверены хотя бы один раз, все
логические решения рассмотрены во всевозможных условиях, циклы были выполнены с
использованием верхних и нижних границ и проконтролированы структуры внутренних
данных.

Методы тестирования на основе стратегии белого ящика:


Ввод неверных значений. При вводе неверных значений тестировщик заставляет коды
возврата показывать ошибки и смотрит на реакцию кода. Это хороший способ моделирования
определенных событий, например переполнения диска, нехватки памяти и т.д. Популярным
методом является замена alloc() функцией, которая возвращает значение NULL в 10% случаев
с целью выяснения, сколько сбоев будет в результате. Такой подход еще называют
тестированием ошибочных входных данных. При таком тестировании проверяется обработка
как верных, так и неверных входных данных. Тестировщики могут выбрать значения, которые
проверяют диапазон входных/выходных параметров, а также значения, выходящие за границу
диапазона.
Модульное тестирование. При создании кода каждого модуля программного продукта
проводится модульное тестирование для проверки того, что код работает верно и корректно
реализует архитектуру. При модульном тестировании новый код проверяется на соответствие
подробному описанию архитектуры; обследуются пути в коде, устанавливается, что экраны,
ниспадающие меню и сообщения должным образом отформатированы; проверяются
диапазон и тип вводимых данных, а также то, что каждый блок кода, когда нужно, генерирует
исключения и возвращает ошибки (еггог returns). Тестирование каждого модуля программного
продукта проводится для того, чтобы проверить корректность алгоритмов и логики и то, что
программный модуль удовлетворяет предъявляемым требованиям и обеспечивает
необходимую функциональность. По итогам модульного тестирования фиксируются ошибки,
относящиеся к логике программы, перегрузке и выходу из диапазона, времени работы и утечке
памяти.
Тестирование обработки ошибок. При использовании этого метода признается, что
нереально на практике проверить каждое возможное условие возникновения ошибки. По этой
причине программа обработки ошибок может сгладить последствия при возникновении
неожиданных ошибок. Тестировщик обязан убедиться в том, что приложение должным
образом выдает сообщение об ошибке. Так, приложение, которое сообщает о системной
ошибке, возникшей из-за промежуточного программного обеспечения представляет
небольшую ценность, как для конечного пользователя, так и для тестировщика.
Утечка памяти. При тестировании утечки памяти приложение исследуется с целью
обнаружения ситуаций, при которых приложение не освобождает выделенную память, в
результате чего снижается производительность или возникает тупиковая ситуация. Данная
технология применяется как для тестирования версии приложения, так и для тестирования
готового программного продукта. Возможно применение инструментов тестирования. Они
могут следить за использованием памяти приложения в течение нескольких часов или даже
дней, чтобы проверить, будет ли расти объем используемой памяти. С их помощью можно
также выявить те операторы программы, которые не освобождают выделенную память.
Комплексное тестирование. Целью комплексного тестирования является проверка того, что
каждый модуль программного продукта корректно согласуется с остальными модулями
продукта. При комплексном тестировании может использоваться технология обработки сверху
вниз и снизу-вверх, при которой каждый модуль, являющийся листом в дереве системы,
интегрируется со следующим модулем более низкого или более высокого уровня, пока не
будет создано дерево программного продукта. Эта технология тестирования направлена на
проверку не только тех параметров, которые передаются между двумя компонентами, но и на
проверку глобальных параметров и, в случае объектно-ориентированного приложения, всех
классов верхнего уровня.
Тестирование цепочек. Тестирование цепочек подразумевает проверку группы модулей,
составляющих функцию программного продукта. Эти действия известны еще как модульное
тестирование, с его помощью обеспечивается адекватное тестирование компонентов
системы. Данное тестирование выявляет, достаточно ли надежно работают модули для того,
чтобы образовать единый модуль, и выдает ли модуль программного продукта точные и
согласующиеся результаты.
Исследование покрытия. При выборе инструмента для исследования покрытия важно,
чтобы группа тестирования проанализировала тип покрытия, необходимый для приложения.
Исследование покрытия можно провести с помощью различных технологий. Метод покрытия
операторов часто называют С1, что также означает покрытие узлов. Эти измерения
показывают, был ли проверен каждый исполняемый оператор. Данный метод тестирования
обычно использует программу протоколирования (profiler) производительности.
Покрытие решений. Метод покрытия решений направлен на определение (в процентном
соотношении) всех возможных исходов решений, которые были проверены с помощью
комплекта тестовых процедур. Метод покрытия решений иногда относят к покрытию ветвей и
называют С2. Он требует: чтобы каждая точка входа и выхода в программе была достигнута
хотя бы единожды, чтобы все возможные условия для решений в программе были проверены
не менее одного раза, и чтобы каждое решение в программе хотя бы единожды было
протестировано при использовании всех возможных исходов.
Покрытие условий. Покрытие условий похоже на покрытие решений. Оно направлено на
проверку точности истинных или ложных результатов каждого логического выражения. Этот
метод включает в себя тесты, которые проверяют выражения независимо друг от друга.
Результаты этих проверок аналогичны тем, что получают при применении метода покрытия
решений, за исключением того, что метод покрытия решений более чувствителен к
управляющей логике программы.

Метод черного ящика


Тестирование на основе стратегии черного ящика возможно лишь при наличии
установленных открытых интерфейсов, таких как интерфейс пользователя или программный
интерфейс приложения (API).
Если тестирование на основе стратегии белого ящика исследует внутреннюю работу
программы, то методы тестирования черного ящика сравнивают поведение приложения с
соответствующими требованиями. Кроме того, эти методы обычно направлены на выявление
трех основных видов ошибок: функциональности, поддерживаемой программным
продуктом; производимых вычислений; допустимого диапазона или области действия
значений данных, которые могут быть обработаны программным продуктом. На этом уровне
тестировщики не исследуют внутреннюю работу компонентов программного продукта, тем не
менее они проверяются неявно.
Группа тестирования изучает входные и выходные данные программного продукта. В этом
ракурсе тестирование с помощью методов черного ящика рассматривается как синоним
тестирования на уровне системы, хотя методы черного ящика могут также применяться во
время модульного или компонентного тестирования.
При тестировании методами черного ящика важно участие пользователей, поскольку именно
они лучше всего знают, каких результатов следует ожидать от бизнес-функций. Ключом к
успешному завершению системного тестирования является корректность данных. Поэтому на
фазе создания данных для тестирования крайне важно, чтобы конечные пользователи
предоставили как можно больше входных данных.
Тестирование при помощи методов черного ящика направлено на получение множеств
входных данных, которые наиболее полно проверяют все функциональные требования
системы. Это не альтернатива тестированию по методу белого ящика. Этот тип тестирования
нацелен на поиск ошибок, относящихся к целому ряду категорий, среди них:
 Неверная или пропущенная функциональность
 Ошибки интерфейса
 Проблемы удобства использования
 Методы тестирования на основе автоматизированных инструментов
 Ошибки в структурах данных или ошибки доступа к внешним базам данных
 Проблемы снижения производительности и другие ошибки производительности
 Ошибки загрузки
 Ошибки многопользовательского доступа
 Ошибки инициализации и завершения
 Проблемы сохранения резервных копий и способности к восстановлению работы
 Проблемы безопасности

Методы тестирования на основе стратегии черного ящика


Эквивалентное разбиение. Исчерпывающее тестирование входных данных, как правило,
неосуществимо. Поэтому следует проводить тестирование с использованием подмножества
входных данных.
При тестировании ошибок, связанных с выходом за пределы области допустимых значений,
применяют три основных типа эквивалентных классов: значения внутри границы диапазона,
за границей диапазона и на границе. Оправдывает себя практика создания тестовых
процедур, которые проверяют граничные случаи плюс/минус один во избежание пропуска
ошибок «на единицу больше» или «на единицу меньше». Кроме разработки тестовых
процедур, использующих сильно структурированные классы эквивалентности, группа
тестирования должна провести исследовательское тестирование. Тестовые процедуры, при
выполнении которых выдаются ожидаемые результаты, называются правильными тестами.
Тестовые процедуры, проведение которых должно привести к ошибке, носят название
неправильных тестов.
Анализ граничных значений. Анализ граничных значений можно применить как на
структурном, так и на функциональном уровне тестирования. Границы определяют данные
трех типов: правильные, неправильные и лежащие на границе. Тестирование границ
использует значения, лежащие внутри или на границе (например, крайние точки), и
максимальные/минимальные значения (например, длины полей). При таком исследовании
всегда должны учитываться значения на единицу больше и меньше граничного. При
тестировании за пределами границы используется репрезентативный образец данных,
выходящих за границу, т.е. неверные значения.
Диаграммы причинно-следственных связей. Составление диаграмм причинно-
следственных связей - это метод, дающий четкое представление о логических условиях и
соответствующих действиях. Метод предполагает четыре этапа. Первый этап заключается в
составлении перечня причин (условий ввода) и следствий (действий) для модуля и в
присвоении идентификатора каждому модулю. На втором этапе разрабатывается диаграмма
причинно-следственных связей. На третьем этапе диаграмма преобразуется в таблицу
решений. Четвертый этап включает в себя установление причин и следствий в процессе
чтения спецификации функций. Каждой причине и следствию присваивается собственный
идентификатор. Причины перечисляются в столбике с левой стороны листа бумаги, а
следствия - с правой. Затем причины и следствия соединяются линиями так, чтобы были
отражены имеющиеся между ними соответствия. На диаграмме проставляются булевы
выражения, которые объединяют две или более причин, связанных со следствием. Далее
правила таблицы решений преобразуются в тестовые процедуры.
Системное тестирование. Термин «системное тестирование» часто употребляется как
синоним «тестирования с помощью методов черного ящика», поскольку во время системного
тестирования группа тестирования рассматривает в основном «внешнее поведение»
приложения. Системное тестирование включает в себя несколько подтипов тестирования, в
том числе функциональное, регрессионное, безопасности, перегрузок, производительности,
удобства использования, случайное, целостности данных, преобразования данных,
сохранения резервных копий и способности к восстановлению, готовности к работе, приемо-
сдаточные испытания и альфа/бета тестирование.
Функциональное тестирование. Функциональное тестирование проверяет системное
приложение в отношении функциональных требований с целью обнаружения несоответствия
требованиям конечного пользователя. Для большинства программ тестирования
программного продукта данный метод тестирования является главным. Его основная задача
- оценка того, работает ли приложение в соответствии с предъявляемыми требованиями.
Регрессионное тестирование. Смысл проведения тестирования заключается в обнаружении
дефектов, их документировании и отслеживании вплоть до устранения. Тестировщик должен
быть уверен в том, что меры, принимаемые для устранения найденных ошибок, не породят в
свою очередь новых ошибок в других областях системы. Регрессионное тестирование
позволяет выяснить, не появились ли какие-либо ошибки в результате ликвидации уже
обнаруженных ошибок. Именно для регрессионного тестирования применение инструментов
автоматизированного тестирования дает наибольшую отдачу. Все созданные ранее скрипты
можно использовать снова для подтверждения того, что в результате изменений, внесенных
при устранении ошибки, не появились новые дефекты. Эта цель легко достижима, поскольку
скрипты можно выполнять без ручного вмешательства и использовать столько раз, сколько
необходимо для обнаружения ошибок.
Тестирование безопасности. Тестирование безопасности включает в себя проверку работы
механизмов доступа к системе и к данным. Для этого придумывают тестовые процедуры,
которые пытаются преодолеть защиту системы. Тестировщик проверяет степень
безопасности и ограничения доступа, выявляя таким образом соответствие установленным
требованиям к безопасности и всем применяемым правилам по безопасности системы.
Тестирование перегрузок. При тестировании перегрузок выполняется проверка системы без
учета ограничений архитектуры с целыо выявления технических ограничений системы. Эти
тесты проводятся на пике обработки транзакций и при непрерывной загрузке большого
объема данных. Тестирование перегрузок измеряет пропускную способность системы и ее
эластичность (resiliency) на всех аппаратных платформах. Этот метод подразумевает
одновременное обращение со стороны многих пользователей к определенным функциям
системы, причем некоторые вводят значения, выходящие за пределы нормы. От системы
требуется обработка огромного количества данных или выполнение большого числа
функциональных запросов в течение короткого периода времени.
Тестирование производительности. Тесты производительности проверяют, удовлетворяет
ли системное приложение требованиям по производительности. Применяя тестирование
производительности, можно замерить и составить отчеты по таким показателям, как скорость
передачи входных и выходных данных, общее число действий по вводу и выводу данных,
среднее время, затрачиваемое базой данных на отклик на запрос, и интенсивность
использования центрального процессора. Как правило, для автоматической проверки степени
производительности, проводимой в рамках тестирования производительности, используются
те же инструменты, что и при тестировании перегрузок.
Тестирование удобства использования. Тесты удобства использования направлены на
подтверждение простоты применения системы и того, что пользовательский интерфейс
выглядит привлекательно. Такие тесты учитывают человеческий фактор в работе системы.
Тестировщику нужно оценить приложение с точки зрения конечного пользователя.

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

Методы белого и чёрного ящика не являются конкурирующими или взаимоисключающими -


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

Преимущества и недостатки методов белого и чёрного ящиков


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

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


Ручное тестирование (manual testing) — тестирование, в котором тест-кейсы выполняются
человеком вручную без использования средств автоматизации. Несмотря на то что это звучит
очень просто, от тестировщика в те или иные моменты времени требуются такие качества, как
терпеливость, наблюдательность, креативность, умение ставить нестандартные
эксперименты, а также умение видеть и понимать, что происходит «внутри системы», т.е. как
внешние воздействия на приложение трансформируются в его внутренние процессы.

Автоматизированное тестирование (automated testing) — набор техник, подходов и


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

У автоматизированного тестирования есть много как сильных, так и слабых сторон.

Преимущества и недостатки автоматизированного тестирования


Преимущества Недостатки
 Скорость выполнения тест-кейсов может в  Необходим высококвалифицированный
разы и на порядки превосходить персонал в силу того факта, что
возможности человека. автоматизация — это «проект внутри
 Отсутствие влияния человеческого фактора проекта» (со своими требованиями,
в процессе выполнения тест-кейсов планами, кодом и т.д.)
(усталости, невнимательности и т.д.)  Высокие затраты на сложные средства
 Минимизация затрат при многократном автоматизации, разработку и сопровождение
выполнении тест-кейсов (участие человека кода тест-кейсов.
здесь требуется лишь эпизодически).  Автоматизация требует более тщательного
 Способность средств автоматизации планирования и управления рисками, т.к. в
выполнить тест-кейсы, в принципе противном случае проекту может быть
непосильные для человека в силу своей нанесён серьёзный ущерб.
сложности, скорости или иных факторов.  Средств автоматизации крайне много, что
 Способность средств автоматизации усложняет проблему выбора того или иного
собирать, сохранять, анализировать, средства и может повлечь за собой
агрегировать и представлять в удобной для финансовые затраты (и риски),
восприятие человеком форме колоссальные необходимость обучения персонала (или
объёмы данных. поиска специалистов).
 Способность средств автоматизации  В случае ощутимого изменения требований,
выполнять низкоуровневые действия с смены технологического домена,
приложением, операционной системой, переработки интерфейсов (как
каналами передачи данных и т.д. пользовательских, так и программных)
многие тест-кейсы становятся безнадёжно
устаревшими и требуют создания заново.

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


тестирования)
Модульное (компонентное) тестирование (unit testing, module testing, component testing)
направлено на проверку отдельных небольших частей приложения, которые (как правило)
можно исследовать изолированно от других подобных частей. При выполнении данного
тестирования могут проверяться отдельные функции или методы классов, сами классы,
взаимодействие классов, небольшие библиотеки, отдельные части приложения. Часто данный
вид тестирования реализуется с использованием специальных технологий и
инструментальных средств автоматизации тестирования{71}, значительно упрощающих и
ускоряющих разработку соответствующих тест-кейсов.

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

Интеграционное тестирование (integration testing) направлено на проверку взаимодействия


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

Системное тестирование (system testing) направлено на проверку всего приложения как


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

Для лучшего запоминания степень детализации в модульном, интеграционном и системном


тестировании показана схематично на рисунке 2
Рисунок 2. Схематичное представление классификации тестирования по уровню
детализации приложения

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


функций (по уровню функционального тестирования)
В некоторых источниках эту разновидность классификации также называют «по глубине
тестирования».

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

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


функциональности, используемой типичными пользователями в типичной повседневной
деятельности. Как видно из определения в сноске к англоязычной версии термина, сама идея
позаимствована из управления проектами и трансформирована в контексте тестирования в
следующую: существует большинство пользователей, которые чаще всего используют некое
подмножество функций приложения (см. рисунок 3).
Именно эти функции и нужно проверить, как только мы убедились, что приложение «в принципе
работает» (дымовой тест прошёл успешно). Если по каким-то причинам приложение не
выполняет эти функции или выполняет их некорректно, очень многие пользователи не смогут
достичь множества своих целей. Пороговое значение метрики успешного прохождения «теста
критического пути» уже немного ниже, чем в дымовом тестировании, но всё равно достаточно
высоко (как правило, порядка 70–80–90 % — в зависимости от сути проекта).
Рисунок 3 — Суть тестирования критического пути

Расширенное тестирование (extended test) направлено на исследование всей заявленной в


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

Ещё одним направлением исследования в рамках данного тестирования являются


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

Для лучшего запоминания отразим эту классификацию графически (рисунок 4):

Метрика
тест-кейса

30-50%

70-90%

100%

Рисунок 4 — Классификация тестирования по (убыванию) степени важности тестируемых


функций (по уровню функционального тестирования)

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


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

Негативное тестирование (negative testing) — направлено на исследование работы


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

Оценить