Материал: Обеспечения Базовый курс (3е издание) Версия книги 2 от 17. 04. 2023

Классификация по принадлежности к тестированию по методу белого и чёрного ящиков
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 111/301
Тестирование уровня пред- ставления
{83}
Presentation tier testing
Мало
Да
Тестирование уровня бизнес- логики
{83}
Business logic tier testing
Да
Да
Тестирование уровня дан- ных
{83}
Data tier testing
Да
Мало
Альфа-тестирование
{84}
Alpha testing
Мало
Да
Бета-тестирование
{84}
Beta testing
Почти никогда
Да
Гамма-тестирование
{84}
Gamma testing
Почти никогда
Да
Тестирование на основе тест- кейсов
{84}
Scripted testing, Test case based testing
Да
Да
Исследовательское тестиро- вание
{85}
Exploratory testing
Нет
Да
Свободное (интуитивное) те- стирование
{85}
Ad hoc testing
Нет
Да
Функциональное тестирова- ние
{85}
Functional testing
Да
Да
Нефункциональное тестиро- вание
{86}
Non-functional testing
Да
Да
Инсталляционное тестирова- ние
{86}
Installation testing
Изредка
Да
Регрессионное тестирова- ние
{87}
Regression testing
Да
Да
Повторное тестирование
{87}
Re-testing, Confirmation testing
Да
Да
Приёмочное тестирование
{87}
Acceptance testing
Крайне редко
Да
Операционное тестирова- ние
{88}
Operational testing
Крайне редко
Да
Тестирование удобства ис- пользования
{88}
Usability testing
Крайне редко
Да
Тестирование доступности
{88}
Accessibility testing
Крайне редко
Да
Тестирование интерфейса
{88}
Interface testing
Да
Да
Тестирование безопасно- сти
{89}
Security testing
Да
Да
Тестирование интернациона- лизации
{89}
Internationalization testing
Мало
Да
Тестирование локализации
{89}
Localization testing
Мало
Да
Тестирование совместимо- сти
{89}
Compatibility testing
Мало
Да
Конфигурационное тестиро- вание
{89}
Configuration testing
Мало
Да
Кросс-браузерное тестирова- ние
{90}
Cross-browser testing
Мало
Да
Тестирование данных и баз данных
{90}
Data quality testing and Data- base integrity testing
Да
Мало
Тестирование использования ресурсов
{90}
Resource utilization testing
Крайне редко
Да
Сравнительное тестирова- ние
{91}
Comparison testing
Нет
Да

Классификация по принадлежности к тестированию по методу белого и чёрного ящиков
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 112/301
Демонстрационное тестиро- вание
{91}
Qualification testing
Нет
Да
Исчерпывающее тестирова- ние
{91}
Exhaustive testing
Крайне редко
Нет
Тестирование надёжности
{91}
Reliability testing
Крайне редко
Да
Тестирование восстанавли- ваемости
{91}
Recoverability testing
Крайне редко
Да
Тестирование отказоустойчи- вости
{91}
Failover testing
Крайне редко
Да
Тестирование производи- тельности
{91}
Performance testing
Крайне редко
Да
Нагрузочное тестирование
{91}
Load testing, Capacity testing
Крайне редко
Да
Тестирование масштабируе- мости
{92}
Scalability testing
Крайне редко
Да
Объёмное тестирование
{92}
Volume testing
Крайне редко
Да
Стрессовое тестирование
{92}
Stress testing
Крайне редко
Да
Конкурентное тестирова- ние
{92}
Concurrency testing
Крайне редко
Да
Инвазивное тестирование
{93}
Intrusive testing
Да
Да
Неинвазивное тестирова- ние
{93}
Nonintrusive testing
Да
Да
Тестирование под управле- нием данными
{93}
Data-driven testing
Да
Да
Тестирование под управле- нием ключевыми словами
{93}
Keyword-driven testing
Да
Да
Тестирование предугадыва- нием ошибок
{94}
Error guessing
Крайне редко
Да
Эвристическая оценка
{94}
Heuristic evaluation
Нет
Да
Мутационное тестирова- ние
{94}
Mutation testing
Да
Да
Тестирование добавлением ошибок
{94}
Error seeding
Да
Да
Тестирование на основе классов эквивалентности
{94}
Equivalence partitioning
Да
Да
Тестирование на основе гра- ничных условий
{95}
Boundary value analysis
Да
Да
Доменное тестирование
{95}
Domain testing, Domain analy- sis
Да
Да
Попарное тестирование
{95}
Pairwise testing
Да
Да
Тестирование на основе ор- тогональных массивов
{95}
Orthogonal array testing
Да
Да
Тестирование в процессе разработки
{96}
Development testing
Да
Да
Тестирование по потоку управления
{96}
Control flow testing
Да
Нет
Тестирование по потоку дан- ных
{96}
Data flow testing
Да
Нет
Тестирование по диаграмме или таблице состояний
{97}
State transition testing
Изредка
Да

Классификация по принадлежности к тестированию по методу белого и чёрного ящиков
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 113/301
Инспекция (аудит) кода
{97}
Code review, code inspection
Да
Нет
Тестирование на основе вы- ражений
{97}
Statement testing
Да
Нет
Тестирование на основе вет- вей
{97}
Branch testing
Да
Нет
Тестирование на основе условий
{98}
Condition testing
Да
Нет
Тестирование на основе ком- бинаций условий
{98}
Multiple condition testing
Да
Нет
Тестирование на основе от- дельных условий, порождаю- щих ветвление
{98}
(«решаю- щих условий»)
Modified condition decision coverage testing
Да
Нет
Тестирование на основе ре- шений
{98}
Decision testing
Да
Нет
Тестирование на основе пу- тей
{98}
Path testing
Да
Нет
Тестирование по таблице принятия решений
{99}
Decision table testing
Да
Да
Тестирование по моделям поведения приложения
{99}
Model-based testing
Да
Да
Тестирование на основе ва- риантов использования
{99}
Use case testing
Да
Да
Параллельное тестирова- ние
{100}
Parallel testing
Да
Да
Тестирование на основе слу- чайных данных
{100}
Random testing
Да
Да
A/B- тестирование
{100}
A/B testing, Split testing
Нет
Да
Восходящее тестирование
{101}
Bottom-up testing
Да
Да
Нисходящее тестирова- ние
{101}
Top-down testing
Да
Да
Гибридное тестирование
{101}
Hybrid testing
Да
Да
Тестирование на основе де- рева классификаций
{107}
Classification tree method
Да
Да
Тестирование на основе син- таксиса
{107}
Syntax testing
Да
Да
Комбинаторные техники
{107}
(комбинаторное тестирова- ние)
Combinatorial testing
Да
Да
Тестирование всех комбина- ций
{107}
All combinations testing
Да
Нет
Тестирование с выбором зна- чений-представителей
{107}
Each choice testing
Да
Нет
Тестирование с выбором ба- зового набора значений
{107}
Base choice testing
Да
Нет
Тестирование по графу при- чинно-следственных свя- зей
{107}
Cause-effect graphing
Мало
Да

Классификация по принадлежности к тестированию по методу белого и чёрного ящиков
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 114/301
Проверка использования всех объявлений
{108}
All-definitions testing
Да
Нет
Проверка всех вычислений на основе всех объявле- ний
{108}
All-c-uses testing
Да
Нет
Проверка всех ветвлений на основе всех объявлений
{108}
All-p-uses testing
Да
Нет
Проверка всех вычислений и ветвлений на основе всех объявлений
{108}
All-uses testing
Да
Нет
Проверка использования всех объявлений и всех пу- тей без переобъявлений
{108}
(без циклов или с однократ- ными повторениями циклов)
All-du-paths testing
Да
Нет

Чек-листы, тест-кейсы, наборы тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 115/301
2.4.
Чек-листы, тест-кейсы, наборы тест-кейсов
2.4.1.
Чек-лист
Как легко можно понять из предыдущих глав, тестировщику приходится ра- ботать с огромным количеством информации, выбирать из множества вариантов решения задач и изобретать новые. В процессе этой деятельности объективно не- возможно удержать в голове все мысли, а потому продумывание и разработку тест- кейсов рекомендуется выполнять с использованием «чек-листов».
Чек-лист (checklist
282
)
— набор идей [тест-кейсов]. Последнее слово не зря взято в скобки
283
, т.к. в общем случае чек-лист — это просто набор идей: идей по тестированию, идей по разработке, идей по планированию и управлению — любых идей.
Чек-лист чаще всего представляет собой обычный и привычный нам список:
• в котором последовательность пунктов не имеет значения (например, список значений некоего поля);
• в котором последовательность пунктов важна (например, шаги в краткой ин- струкции);
• структурированный (многоуровневый) список, который позволяет отразить иерархию идей.
Важно понять, что нет и не может быть никаких запретов и ограничений при разработке чек-листов — главное, чтобы они помогали в работе. Иногда чек-листы могут даже выражаться графически (например, с использованием ментальных карт
284
или концепт-карт
285
), хотя традиционно их составляют в виде многоуровне- вых списков.
Поскольку в разных проектах встречаются однотипные задачи, хорошо про- думанные и аккуратно оформленные чек-листы могут использоваться повторно, чем достигается экономия сил и времени.
Внимание! Очень частым является вопрос о том, нужно ли в чек-листах писать ожидаемые результаты. В классическом понимании чек-листа – нет (хоть это и не запрещено), т.к. чек-лист – это набор идей, а их детали- зация в виде шагов и ожидаемых результатов будет в тест-кейсах. Но ожи- даемые результаты могут добавляться, например, в следующих случаях:
• в некоем пункте чек-листа рассматривается особое, нетривиальное по- ведение приложения или сложная проверка, результат которой важно отметить уже сейчас, чтобы не забыть;
• в силу сжатых сроков и/или нехватки иных ресурсов тестирование про- водится напрямую по чек-листам без тест-кейсов.
282
Понятие «чек-листа» не завязано на тестировании как таковом — это совершенно универсальная техника, которая может применяться в любой без исключения области жизни. В русском языке вне контекста информационных технологий чаще используется понятное и привычное слово «список» (например, «список покупок», «список дел» и т.д.), но в тестирова- нии прижилась калькированная с английского версия — «чек-лист».
283
Если у вас возник вопрос «почему тут использованы квадратные скобки», ознакомьтесь с синтаксисом «расширенной формы Бэкуса-Наура», который де-факто является стандартом описания выражений в ИТ. См. «Extended Backus–Naur form», Wikipedia. [
https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
]
284
«Mind map», Wikipedia. [
http://en.wikipedia.org/wiki/Mind_map
]
285
«Concept map», Wikipedia. [
http://en.wikipedia.org/wiki/Concept_map
]

Чек-лист
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 116/301
Для того чтобы чек-лист был действительно полезным инструментом, он дол- жен обладать рядом важных свойств.
Логичность. Чек-лист пишется не «просто так», а на основе целей и для того, чтобы помочь в достижении этих целей. К сожалению, одной из самых частых и опасных ошибок при составлении чек-листа является превращение его в свалку мыслей, которые никак не связаны друг с другом.
Последовательность и структурированность. Со структурированностью всё достаточно просто — она достигается за счёт оформления чек-листа в виде многоуровневого списка. Что до последовательности, то даже в том случае, когда пункты чек-листа не описывают цепочку действий, человеку всё равно удобнее вос- принимать информацию в виде неких небольших групп идей, переход между кото- рыми является понятным и очевидным (например, сначала можно прописать идеи простых позитивных тест-кейсов
{82}
, потом идеи простых негативных тест-кейсов, потом постепенно повышать сложность тест-кейсов, но не стоит писать эти идеи вперемешку).
Полнота и неизбыточность. Чек-лист должен представлять собой аккурат- ную «сухую выжимку» идей, в которых нет дублирования (часто появляется из-за разных формулировок одной и той же идеи), и в то же время ничто важное не упу- щено.
Правильно создавать и оформлять чек-листы также помогает восприятие их не только как хранилища наборов идей, но и как «требования для составления тест- кейсов». Эта мысль приводит к пересмотру и переосмыслению свойств качествен- ных требований (см. главу «Свойства качественных требований»
{44}
) в применении к чек-листам.
Задание 2.4.a: перечитайте главу «Свойства качественных требова- ний»
{44}
и подумайте, какие свойства качественных требований можно также считать и свойствами качественных чек-листов.
Итак, рассмотрим процесс создания чек-листа. В главе «Пример анализа и тестирования требований»
{54}
приведён пример итоговой версии требований
{60}
, ко- торый мы и будем использовать.
Поскольку мы не можем сразу «протестировать всё приложение» (это слиш- ком большая задача, чтобы решить её одним махом), нам уже сейчас нужно вы- брать некую логику построения чек-листов — да, их будет несколько (в итоге их можно будет структурированно объединить в один, но это не обязательно).
Типичными вариантами такой логики является создание отдельных чек-ли- стов для:
• типичных пользовательских сценариев
{146}
;
• различных уровней функционального тестирования
{79}
;
• отдельных частей (модулей и подмодулей
{125}
) приложения;
• отдельных требований, групп требований, уровней и типов требований
{39}
;
• частей или функций приложения, наиболее подверженных рискам.
Этот список можно расширять и дополнять, можно комбинировать его пункты, получая, например, чек-листы для проверки наиболее типичных сценариев, затрагивающих некую часть приложения.
Чтобы проиллюстрировать принципы построения чек-листов, мы воспользу- емся логикой разбиения функций приложения по степени их важности на три кате- гории (см. классификацию по убыванию степени важности функций приложения
{79}
):

Чек-лист
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 117/301
• Базовые функции, без которых существование приложения теряет смысл
(т.е. самые важные — то, ради чего приложение вообще создавалось), или нарушение работы которых создаёт объективные серьёзные проблемы для среды исполнения. (См. «Дымовое тестирование»
{79}
).
• Функции, востребованные большинством пользователей в их повседневной работе. (См. «Тестирование критического пути»
{80}
).
• Остальные функции (разнообразные «мелочи», проблемы с которыми не сильно повлияют на ценность приложения для конечного пользователя). (См.
«Расширенное тестирование»
{81}
).