В учебных программах по дисциплине "Обеспечение качества и тестирование программ" есть вопросы "Уровни и циклы тестирования. Задачи тестирования. Уровни тестирования (от Unit testing до Acceptance testing)". В программе обучения базового уровня International Software Testing Qualifications Board "Сертифицированный тестировщик" указано на необходимость понимать и уметь сравнить различные уровни тестирования: типичные объекты тестирования, цели различных видов тестирования (например, функционального или структурного) и работы, связанные с ними, тестировщиков, типы дефектов, которые могут быть найдены.

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

Стандартный глоссарий терминологии по программированию Института инженеров электротехники и электроники, Institute of Electrical and Electronics Engineers Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. 18, 74 страницы:

Component. One of the parts that make up a system. A component may be hardware or software and may be subdivided into other components. Note: The terms “module,” “component,” and “unit” are often used interchangeably or defined to be subelements of one another in different ways depending upon the context. The relationship of these terms is not yet standardized.

Component standard. (IEEE Std 1002-1987193) A standard that describes the characteristics of data or program components.

Component testing. Testing of individual hardware or software components or groups of related components. Syn: module testing. See also: integration testing; interface testing; system testing;unit testing.

Integration. The process of combining software components, hardware components, or both into an overall system.

Integration testing. Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. See also: component testing; interface testing; system testing; unit testing.

System. A collection of components organized to accomplish a specific function or set of functions.

System testing. Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. See also: component testing; integration testing; interface testing; unit testing.

«Основы программной инженерии (по SWEBOK). Программная инженерия. Тестирование программного обеспечения». На базе IEEE Guide to SWEBOK® 2004, Сергей Орлик, 02-03 страницы:

Над чем производятся тесты (The target of the test) Тестирование обычно производится на протяжении всей разработки и сопровождения на разных //уровнях//. Уровень тестирования определяет “над чем” производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий.

Модульное тестирование (Unit testing)

Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.

Интеграционное тестирование (Integration testing)

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

Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” – используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисно-ориентированных архитектурах (SOA).

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

Интеграционное тестирование – постоянно проводимая деятельность, предполагающая работу на достаточно высоком уровне абстракции. Наиболее успешная практика интеграционного тестирования базируется на инкрементальном подходе, позволяющем избежать проблем проведения разовых тестов, связанных с тестированием результатов очередного длительного этапа работ, когда количество выявленных дефектов приводит к серьезной переработке кода (традиционно, негативный опыт выпуска и тестирования только крупных релизов называют “big bang”).

Системное тестирование (System testing)

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

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

«Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах». Роман Савин, Москва, Дело, 2007. 163 страница:

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

1. компонентное тестирование (component testing);
2. интеграционное тестирование (integration testing);
3. системное (или энд-ту-энд) тестирование (system or end-to-end testing).

Сначала краткие и емкие определения, а затем иллюстрации.

Компонентное тестирование (component testing) — это тестирование на уровне логического компонента. И это тестирование самого логического компонента.

Интеграционное тестирование (integration testing) — это тестирование на уровне двух или больше компонентов. И это тестирование взаимодействия этих двух или больше компонентов.

Системное (или энд-ту-энд) тестирование (system or end-to-end testing) — это проверка всей системы от начала до конца.

Теперь иллюстрации кратких и емких определений.

Допустим, программисту поставлена задача написать код, который бы находил полные имена и е-мейлы пользователей, потративших больше 1000 долларов в нашем онлайн-магазине с момента регистрации. Таким пользователям должен быть отправлен е-мейл с подарочным сертификатом, использование которого до 17 ноября включительно предоставит 5%-ю скидку на любую разовую покупку.

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

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

Для начала выделим три компонента, которые мы протестировали бы:

1. Создание файла с полными именами, е-мейлами и номерами сертификатов.
2. Рассылка пользователям е-мейлов.
3. Правильное предоставление скидки вышеуказанным пользователям.

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

Компонент 2. Допустим, код первого компонента, который должен был создать для нас файл, не работает. Мы не отчаиваемся, а просто вручную, не ропща на судьбу, создаем файл установленного формата с взятыми с потолка (1) е-мейлами, (2) полными именами пользователей и (3) номерами подарочных сертификатов. Этот файл мы "скармливаем" программе рассылки е-мейлов и проверяем, что правильные е-мейлы доходят до пользователей из файла (позитивное тестирование).

Компонент 3. Как мы помним, компонент 1 не работает. Что делать? Сертификат — это как некий код, например "UYTU764587657", который нужно ввести во время оплаты, и если сертификат действительный, то итоговая сумма к оплате уменьшается. В данном случае можно попросить программиста, чтобы тот помог сгенерировать легитимные номера сертификатов. Когда номера сертификатов имеются в наличии, можно, например, провеырить, работает ли подарочный сертификат только один раз (позитивное тестирование) или его можно использовать для двух или более транзакций (негативное тестирование, воспроизводящее ошибку пользователя, использующего сертификат более одного раза). Также нужно будет проверить размер скидки (5%) (позитивное тестирование) и действительность сертификата: (1) до 17 ноября (позитивное тестирование), (2) 17 ноября (позитивное тестирование) и (3) после 17 ноября (негативное тестирование, воспроизводящее ошибку пользователя, использующего просроченный сертификат).

Интеграционное тестирование

У нас есть три связи между компонентами: а). между 1-м и 2-м компонентами; б) между 2-м и 3-м компонентами; в) между 1-м и 3-м компонентами.

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

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

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

Значения отделены друг от друга запятой (comma-delimited). Информация о каждом новом пользователе — на новой строчке. Сам файл — простой текстовый файл, который можно открыть программой Notepad.

Образец файла: Ferdinando Magellano, [email protected], QWERT98362 James Cook, [email protected], ASDFG54209 Иван Крузенштерн, [email protected], LKJHG61123

Допустим, программист ошибочно заложил в коде, что значения файла разделяются не запятой (форматом, принимаемым программой рассылки), а точкой с запятой: Ferdinando Magellano; [email protected]; QWERT98362 James Cook; [email protected]; ASDFG54209 Иван Крузенштерн; [email protected]; LKJHG61123

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

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

Это может произойти из-за того, что программа рассылки может быть ошибочно сконфигурирована, чтобы "брать" только 9 первых символов из третьей колонки (колонки с номерами сертификатов), т.е. QWERT98362 будет преподнесена пользователю в укороченном виде (truncated): QWERT9836.

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

в. Здесь может быть ситуация, когда номер сертификата, сгене рированный компонентом 1, не принимается компонентом 3.

Пример такой ситуации Компонент 1 сохранил номер сертификата в базе данных в зашифрованном виде, т.е. в целях безопасности использовался алгоритм, который превратил "LKJHG61123", например, в "&"(&86%(987$!$#". Из-за бага в компоненте 3 последний не дешифровал номер сертификата, ВЗЯТЫЙ из БД, а просто попытался сравнить эту абракадабру из БД и номер сертификата, введенный пользователем, что привело к тому, что номера не сошлись и легитимная скидка не была предоставлена.

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

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

Это тестирование системы (функциональности) от начала до конца (end-to-end), т.е. каждый сценарий будет затрагивать всю цепочку: компонент 1 —> компонент 2 —> компонент 3.

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

«Сертифицированный тестировщик Программа обучения Базового уровня». Версия 2011 (от 13 апреля 2011 года), International Software Testing Qualifications Board, Андрей Конушин (председатель), Александр Александров, Алексей Александров, Татьяна Смехнова, Елена Абрамова. 29-34/101 страница:

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

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

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

Базис тестирования:

1. Требования к компонентам
2. Детальный дизайн
3. Код

Типичные объекты тестирования:

1. Компоненты
2. Программы
3. Программы конвертации и миграции данных
4. Модули БД

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

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

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

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

Интеграционное тестирование

Базис тестирования:

1. Проект системы
2. Архитектура
3. Бизнес-процессы
4. Сценарии использования

Типичные объекты тестирования:

1. База данных подсистем
2. Инфраструктура
3. Интерфейсы

Конфигурация системы

1. Конфигурационные данные

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

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

1. Компонентное интеграционное тестирование проверяет взаимодействие между программными компонентами и производится после компонентного тестирования
2. Системное интеграционное тестирование проверяет взаимодействие между системами или между аппаратным обеспечением и может быть выполнено после системного тестирования. В этом случае, разработчики могут управлять только одной стороной интерфейса. Однако, это может рассматриваться как риск. Бизнес-процессы могут включать последовательность систем; могут быть важны кроссплатформенные различия.

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

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

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

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

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

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

Базис тестирования:

1. Система и спецификация требований к программному обеспечению
2. Сценарии использования
3. Функциональная спецификация
4. Отчеты об анализе степени риска

Типичные объекты тестирования:

1. Руководство по эксплуатации системы
2. Конфигурация системы
3. Конфигурационные данные

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

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

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

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

Приемочное тестирование

Базис тестирования:

1. Пользовательские требования
2. Системные требования
3. Сценарии использования
4. Бизнес процессы
5. Отчеты об анализе степени риска

Типичные объекты тестирования:

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

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

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

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

1. Для коробочного продукта приемочное тестирование можно провести при установке или интеграции
2. Приемочное тестирование удобства использования компонента можно провести во время компонентного тестирования
3. Приемочное тестирование новой функциональности можно проводить до системного тестирования

"Стандартный глоссарий терминов, используемых в тестировании программного обеспечения". Версия 2.3 (от 9 июля 2014 года), International Software Testing Qualifications Board, ред. пер. Александр Александров, 65 страница:

Уровень тестирования (test level): Объединенная и совместно управляемая группа задач тестирования. Уровень тестирования связан с областями ответственности в проекте. Примерами уровней тестирования могут служить компонентное тестирование, интеграционное тестирование, системное тестирование и приёмочное тестирование. [TMap]

Компонентное тестирование (component testing): Тестирование отдельных компонентов программного обеспечения [Согласно IEEE 610].

Интеграционное тестирование (integration testing): Тестирование, выполняемое для обнаружения дефектов в интерфейсах и во взаимодействии между интегрированными компонентами или системами. См. также тестирование интеграции компонентов, системное интеграционное тестирование.

Системное тестирование (system testing): Процесс тестирования системы в целом с целью проверки того, что она соответствует установленным требованиям. [Hetzel]

Cистемное интеграционное тестирование (system integration testing): Тестирование интеграции систем и пакетов программ, тестирование интерфейсов связи с внешними системами (интернет и т.д.).

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

«Краткие основы тестирования программного обеспечения», Артур Коробейник. Киев: Директ-лайн, 2012. 42- страницы:

Модульное

Модульным тестированием (Unit testing) – называется проверка минимально функциональной автономной единицы программы. Чаще всего это проверка функций и процедур внутри кода программы. Такое тестирование чаще всего автоматизируют. Отчеты об ошибках при таком тестировании создаются редко, потому что всё исправляется “на лету”. Для проверки функций кода пишется программа, которая подаёт на вход предопределенные параметры и сравнивает полученный результат на выходе функции с ожидаемым. Например в нашей программе есть функция сложения двух чисел AddN(int a1, int a2). В документе описания архитектуры программы сказано что: 1) она должна возвращать только целые числа и 2) если сумма чисел меньше 0, больше 40 или не целое число, то функция должна вернуть число -1. Как тестировщикам, нам не важно знать как написан код этой функции. Нам нужно проверить только её результаты. Для этого пишем код в котором вызываем эту функцию и сравниваем полученный результат с ожидаемым (пример на языке С):

void Test_AddN()
{
if(AddN(0,0)!=0) printf(“Ошибка! 0+0 не равняется 0 \n”); if(AddN(9,30)!=39) printf(“Ошибка! 9+30 не равняется 39 \n”); if(AddN(30,11)!=-1) printf(“Ошибка! 30+11 не возвращает -1
\n”);
if(AddN(14,-20)!=-1) printf(“Ошибка! 14+(-20) не возвращает
-1 \n”);
if(AddN(15.5,1)!=-1) printf(“Ошибка! Дробный результат не
возвращает -1 \n”); };

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

Компонентное

Компонентное тестирование – это тестирование одного отдельного компонента в программе. Иногда компонентное и модульное тестирование объединяют в один вид, но думаю всё же стоит различать их. Компонентное тестирование подразумевает проверку какой-то логически обобщенной части функционала системы. Например, у вас есть программа для интернет телефонии. Вы можете звонить, отправлять sms, участвовать в видеоконференциях с помощью этой программы. Если вы проверяете только как программа отправляет смс сообщения – это значит вы выполняете компонентное тестирование и проверяете только компоненту работы с sms.

Интеграционное

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

Интеграционное тестирование можно разбить на три вида: нисходящее, восходящее и “Большой Взрыв”. Нисходящее интеграционное тестирование используется для отлова ошибок взаимодействия компонент. Вы ставите сначала все компоненты, а потом начинаете по одной убирать их из системы и проверять её на работоспособность. Если, после того как вы убрали очередной компонент, ошибка исчезла, значит вероятнее всего этот компонент и вызывал ошибку интеграции, следовательно – причину неполадки надо искать в нём. Восходящее тестирование – самое распространенное. Здесь вы постепенно по одному добавляете компоненты в систему и проверяете не появились ли ошибки интеграции. Применяется для постепенного наращивания функционала программы. “Большой Взрыв” – это одновременная установка всех компонентов в систему. Применяется, если есть вероятность что все созданные компоненты сразу будут взаимодействовать нормально. На практике такого не бывает, поэтому после “Большого Взрыва” начинают применять нисходящий подход интеграции компонентов.

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

Системное

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

Как правило это тестирование проводится уже в конце про- цесса разработки, когда работа над программой готова и в скором ожидается её внедрение в реальную рабочую среду. За ним идет уже приемочное (UAT) тестирование заказчиком.

«Как тестируют в Google», Джеймс Уиттакер, Джейсон Арбон, Джефф Каролло. - СПб.: Питер, 2014. - 41/320 страниц:

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

Малые тесты

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

Средние тесты

Средние тесты обычно автоматиизируются. Они покрывают две или больше функции. Тесты фокусируются на том, чтобы проверить взаимодействие между функциями, которые вызывают друг друга или контактируют напрямую. Такие функции мы назовем ближайщиими соседями. Разработчик в тестировании управляет разработкой средних тестов на ранней стадии цикла продукта. Их пишу, исправляют и сопровождают разработчики. Если тест не проходит, разработчик чинит его сам. На более поздней стадии разработки инженеры по тестированию могут выполнять средние тесты вручную (если его трудно или дорого автоматизировать) или автоматически. Средние тесты отвечают на вопрос "Взаимодействуют ли соседние функции друг с другом так, как должны?".

Большие тесты

Большие тесты покрывают не меньше трех (а обычно больше) функций. Это реальные пользовательские сценарии, которые используют реальные источники данных,а их выполнение может занять несколько часов и даже больше. Они затрагивают и интеграцию в целом, но чаще всего большие тесты проверяют, насколько приложение соответствует потребностям пользователей. Все три роли вовлечены в соJeff Carolloздание больших тестов. Их можно проводить разными способами, от автоматизированного до исследовательского ручного тестирования. Большие тесты отвечают на вопрос "Работает ли продукт так, как нужно пользователю, и дает ли желаемый результат?". Сквозные сценарии, которые выполняются на завершенном продукте, относятся к большим тестам.

Эта сборка выдержек должна являться ответом на один из экзаменационных вопросов по учебной дисциплине "Обеспечение качества и тестирование программ" и экзаменационной программы обучения базового уровня International Software Testing Qualifications Board "Сертифицированный тестировщик". Полный перечень вопросов привел в заметке Учебные программы, экзаменационные вопросы и литература по обеспечению качества и тестированию программ.

Заметка от 27.08.2017.