Глава 4. ТЕСТИРОВАНИЕ КАК ЧАСТЬ РАЗРАБОТКИ

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

72 
Тестирование должно предоставить достаточную информацию 
заинтересованным лицам, чтобы принять обоснованные решения о 
передаче программного обеспечения или системы, прошедшей 
тестирование, на следующий шаг разработки или передачи клиентам. 
Бытует мнение, что тестирование состоит только из прогона 
тестов, то есть выполнения самой программы. Но это только часть 
тестирования, и далеко не все, что в него входит.
Активности в тестировании существуют как до, так и после 
выполнения самих тестов. В эти активности входят планирование и 
управление, выбор тестовых условий, разработка и выполнение 
тестовых сценариев, проверка результатов, оценка критериев выхода, 
создание отчетов о процессе тестирования и об испытываемой 
системе и закрытие или завершающие действия после того, как фаза 
тестирования была выполнена. Тестирование также включает 
рецензирование документации (включая исходный код) и проведение 
статического анализа.
И динамическое, и статическое тестирования используются для 
достижения аналогичных целей, предоставляя информацию, которая 
может способствовать улучшению, как испытываемой системы, так и 
процессов разработки и тестирования.
Цели тестирования:
• обнаружение дефектов; 
• повышение уверенности в уровне качества; 
• предоставление информации для принятия решений; 
• предотвращение дефектов. 
Цели процессов и действия, связанные с проектированием 
тестов на раннем этапе жизненного цикла программного обеспечения 
(например, при компонентном, интеграционном и системном 
тестировании), могут помочь предотвратить попадание дефектов в 
код. 
Рецензирование 
документов 
(например, 
требований), 

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

74 
4.2 Принципы тестирования 
Эти принципы тестирования были предложены в последние 40 
лет и являются общим руководством для тестирования в целом.
Принцип 1 – Тестирование демонстрирует наличие дефектов. 
Тестирование может показать, что дефекты присутствуют, но не 
может доказать, что их нет. Тестирование снижает вероятность 
наличия дефектов, находящихся в программном обеспечении, но, 
даже если дефекты не были обнаружены, это не доказывает его 
корректности.
Принцип 2 – Исчерпывающее тестирование недостижимо. 
Полное тестирование с использованием всех комбинаций вводов 
и 
предусловий 
физически 
невыполнимо, 
за 
исключением 
тривиальных случаев. Вместо исчерпывающего тестирования должны 
использоваться анализ рисков и расстановка приоритетов, чтобы 
более точно сфокусировать усилия по тестированию.
Принцип 3 – Раннее тестирование. 
Чтобы найти дефекты как можно раньше, активности по 
тестированию должны быть начаты как можно раньше в жизненном 
цикле разработки программного обеспечения или системы, и должны 
быть сфокусированы на определенных целях.
Принцип 4 – Скопление дефектов. 
Усилия 
тестирования 
должны 
быть 
сосредоточены 
пропорционально ожидаемой, а позже реальной плотности дефектов 
по модулям. Как правило, большая часть дефектов, обнаруженных 
при тестировании или повлекших за собой основное количество сбоев 
системы, содержится в небольшом количестве модулей.
Принцип 5 – Парадокс пестицида. 
Если одни и те же тесты будут прогоняться много раз, в 
конечном счете этот набор тестовых сценариев больше не будет 
находить новых дефектов. Чтобы преодолеть этот “парадокс 

75 
пестицида”, тестовые сценарии должны регулярно рецензироваться и 
корректироваться, новые тесты должны быть разносторонними, 
чтобы охватить все компоненты программного обеспечения, или 
системы, и найти как можно больше дефектов.
Принцип 6 – Тестирование зависит от контекста. 
Тестирование выполняется по-разному в зависимости от 
контекста. Например, программное обеспечение, в котором 
критически важна безопасность, тестируется иначе, чем сайт 
электронной коммерции. 
Принцип 7 – Заблуждение об отсутствии ошибок.
Обнаружение и исправление дефектов не помогут, если 
созданная система не подходит пользователю и не удовлетворяет его 
ожиданиям и потребностям. 
4.3 Основной процесс тестирования 
Активность тестирования, которую легче всего увидеть – это 
выполнение тестов. Но чтобы быть эффективным и рациональным, 
планы тестирования должны включать время, которое будет 
потрачено на планирование тестов, разработку тестовых сценариев, 
подготовку к выполнению и оценку результатов.
Основной процесс тестирования состоит из следующих 
направлений деятельности:
• планирование и управление; 
• анализ и проектирование; 
• внедрение и реализация; 
• оценка критериев выхода и создание отчетов;
• действия по завершению тестов. 
Несмотря на логическую последовательность, действия в 
процессе могут накладываться друг на друга или происходить 

76 
одновременно. Для конкретных системы и проекта обычно требуется 
адаптация этих направлений деятельности.
Планирование и управление тестированием 
Планирование тестирования – это действия, направленные на 
определение целей тестирования и описание задач тестирования для 
достижения этих целей и миссии.
Управление тестированием – это постоянное сопоставление 
текущего положения дел с планом и отчетность о состоянии дел, 
включая отклонения от плана. Это позволяет предпринять меры, 
необходимые для достижения миссии и целей проекта. Чтобы 
обеспечить управление тестированием, активности тестирования 
должны проверяться в течение всего проекта. Планирование 
тестирования учитывает данные, полученные при проверке и 
управлении.
Анализ и проектирование тестов 
Анализ и проектирование тестов - это деятельность, во время 
которой общие цели тестирования материализуются в тестовые 
условия и тестовые сценарии.
Для анализа и проектирования тестов поставлены следующие 
основные задачи:
• Рецензирование базиса тестирования (такого, как требования, 
уровень целостности программного обеспечения 1 (уровень риска), 
отчеты об анализе рисков, архитектура, дизайн, технические 
требования к интерфейсу). 
• Оценка тестируемости базиса тестирования и объектов 
тестирования.
• Идентификация 
и 
расстановка 
приоритетов 
условий 
тестирования, основанных на анализе элементов тестирования, 
спецификации, поведении и структуры программного обеспечения.

77 
• Разработка и расстановка приоритетов тестовых сценариев 
высокого уровня. 
• Выявление необходимых данных для поддержки тестовых 
условий и тестовых сценариев. 
• Проектирование и установка тестового окружения и выявление 
необходимой инфраструктуры и инструментов. 
• Создание двунаправленной трассируемости между тестовым 
базисом и тестовым сценарием. 
Реализация и выполнение тестов 
Реализация и выполнение тестов – это деятельность, где 
процедуры тестирования или автоматизированные сценарии задаются 
последовательностью тестовых сценариев, а также собирается любая 
информация, необходимая для выполнения тестов, разворачивается 
окружающая среда, и запускаются тесты.
Для реализации и выполнения тестов поставлены следующие 
основные задачи:
• Завершение, реализация и расстановка приоритетов тестовых 
сценариев (включая проектирование тестовых данных). 
• Разработка и расстановка приоритетов процедур тестирования, 
создание тестовых данных и, если потребуется, подготовка тестовых 
обвязок и написание автоматизированных сценариев тестирования. 
• Создание тестовых наборов на основе процедур тестирования 
для эффективного выполнения тестов. 
• Проверка правильности настройки тестового окружения. 

Проверка и обновление двунаправленной трассируемости 
между тестовым базисом и тестовым сценарием. 
• Выполнение процедур тестирования либо вручную, либо 
используя инструменты выполнения тестов, согласно заданному 
плану.

78 
• Регистрация результатов выполнения тестов и запись 
наименований 
и 
версий 
объекта 
тестирования, 
тестовых 
инструментов и тестового обеспечения. 
• Сравнение фактических и ожидаемых результатов.
• Отчет о несоответствиях как об инцидентах и их анализ для 
установки причины (например, дефект в коде, в конкретных тестовых 
данных, в тестовом документе, или ошибка выполнения теста). 
• Повторение тестовых действий, результаты которых привели к 
каждому из несоответствий. Например, повторное выполнение теста, 
который ранее не прошел, чтобы подтвердить исправление 
(подтверждающее тестирование), выполнение исправленных тестов 
и/или повторное выполнения тестов с целью убедиться, что дефекты 
не появились в той области программного обеспечения, которая не 
изменялась, или что исправление дефекта не повлекло за собой 
других дефектов (регрессионное тестирование). 
Оценка критериев выхода и отчетность 
Оценка критериев выхода - это деятельность, где выполнение 
тестов оценивается согласно определенным целям. Она должна быть 
выполнена для каждого уровня тестирования (см. раздел 2.2).
Для оценки критериев выхода поставлены следующие основные 
задачи:
• сверка протокола тестирования в сравнении с критериями 
выхода, определенными в плане тестирования; 
• анализ необходимости использования дополнительных тестов 
или изменения критериев выхода; 
• написание 
итогового 
отчета 
о 
тестировании 
для 
заинтересованных лиц.

79 
Действия по завершению тестирования 
Действия по завершению тестирования собирают данные о 
завершенных испытаниях для объединения опыта, тестового 
обеспечения, фактов и цифр. Действия по завершению тестирования 
происходят на тех этапах проекта, когда система программного 
обеспечения выпущена, тестирование завершено (или прервано), этап 
был завершен, или релиз по сопровождению был закончен.
Для действий по завершению тестирования поставлены 
следующие основные задачи:
•
Проверка, что запланированные результаты достигнуты. 
•
Закрытие отчетов об инцидентах или внесение изменений в 
записи по каждому из открытых инцидентов. 
•
Документирование приемки системы. 

Завершение и архивирование тестового обеспечения, тестового 
окружения и инфраструктуры тестирования для последующего 
использования.
•
Передача тестового обеспечения организации сопровождения. 
•
Анализ полученных уроков для определения изменений, 
необходимых для будущих релизов и проектов.
•
Использование собранной информации для повышения 
зрелости процесса тестирования. 
4.4
Уровни тестирования ПО 
Для каждого уровня тестирования может быть определено: 
цели, артефакты процесса разработки, на основании которых будут 
разработаны тестовые сценарии, объекты тестирования, типичные 
дефекты и отказы, которые могут быть найдены во время 
тестирования, требования к тестовой обвязке, инструментарий и 
ответственность участников.

80 
Конфигурационные данные для тестирования системы нужно 
рассматривать во время планирования тестирования, если такие 
данные необходимы.
Компонентное тестирование
Базис тестирования:
• требования к компонентам; 
• детальный дизайн; 
• код. 
Типичные объекты тестирования:
• компоненты; 
• программы; 
• программы конвертации и миграции данных; 
• модули БД. 
Компонентное тестирование (также известное как модульное) 
занимается поиском дефектов и верификацией функционирования 
программных модулей, программ, объектов, классов и т.п., которые 
можно протестировать изолированно. Это может быть сделано 
изолированно от остальной части системы, в зависимости от 
контекста ЖЦ разработки и системы. В процессе могут быть 
использованы заглушки, драйвера и эмуляторы.
Компонентное тестирование может включать как тестирование 
функциональности 
и 
специфичных 
нефункциональных 
характеристик, таких как поведение ресурсов (например, поиск 
утечки памяти) или тестирование надежности, так и структурное 
тестирование (например, покрытие кода). Тестовые сценарии 
разрабатываются на основе артефактов процесса разработки, таких 
как спецификация компонентов, дизайн или модель БД.
Обычно, компонентное тестирование производится с доступом к 
тестируемому коду и с поддержкой рабочего окружения, такого как 
фреймворк модульного тестирования или утилиты отладки. На 
практике 
компонентное 
тестирование 
обычно 
производится 

81 
разработчиками, которые пишут код. Дефекты обычно исправляются 
сразу после того, как становятся известны, без занесения их в базу 
дефектов.
Один из подходов к компонентному тестированию – составить 
автоматизированные тестовые сценарии до кодирования. Это 
называется разработкой, управляемой тестированием. Этот подход 
состоит из множества итераций и основывается на циклах разработки 
тестовых сценариев, написании и интеграции небольшого участка 
кода и выполнении компонентного тестирования, корректируя любые 
проблемы и выполняя тесты, пока не будет получен положительный 
результат. 
Интеграционное тестирование
Базис тестирования:
• проект системы; 
• архитектура; 
• бизнес-процессы; 
• сценарии использования.
Типичные объекты тестирования:
• БД подсистем;
• инфраструктура; 
• интерфейсы. 
Конфигурация системы: 
• Конфигурационные данные. 
Интеграционное тестирование проверяет интерфейсы между 
компонентами, взаимодействие различных частей системы, таких как 
операционная системы, файловая система, аппаратное обеспечение, и 
интерфейсы между системами.
Интеграционное тестирование может состоять из одного или 
более уровней и может быть выполнено на тестовых объектах разного 
размера следующим образом:

82 
1. Компонентное 
интеграционное тестирование проверяет 
взаимодействие между программными компонентами и производится 
после компонентного тестирования.
2. Системное 
интеграционное 
тестирование 
проверяет 
взаимодействие между системами или между аппаратным 
обеспечением и может быть выполнено после системного 
тестирования. В этом случае, разработчики могут управлять только 
одной стороной интерфейса. Однако, это может рассматриваться как 
риск. Бизнес-процессы могут включать последовательность систем; 
могут быть важны кроссплатформенные различия.
Чем больше объем интеграции, тем труднее становится 
изолировать дефекты отдельного компонента или системы, которые 
могут привести к увеличению рисков и требующих дополнительного 
времени для решения проблем.
Стратегии системного интеграционного тестирования могут 
основываться на архитектуре системы (такой как нисходящая или 
восходящая), 
функциональных 
задачах, 
последовательности 
обработки транзакций или других аспектах системы и ее 
компонентов. Для того, чтобы упростить процесс изоляции отказа и 
как можно раньше обнаруживать дефекты, интеграция должна 
проводиться по возрастающей, а не происходить по сценарию 
«большого взрыва».
Тестирование специфичных нефункциональных характеристик 
(например, 
производительности), может быть включено в 
интеграционное тестирование, наравне с функциональным.
На каждой стадии интеграции тестировщики концентрируют все 
внимание именно на интеграции как таковой. Например, если 
интегрируется модуль А с модулем В, они проверяют взаимодействие 
модулей, а не функциональность каждого из них, т.к. она должна 
быть проверена во время компонентного тестирования. Для 

83 
тестирования могут использоваться как функциональный, так и 
структурный подходы.
В идеале, тестировщики должны понимать архитектуру и ее 
влияние на интеграционное планирование. Если интеграционное 
тестирование планируется до разработки компонентов или системы, 
эти компоненты могут разрабатываться в порядке, обеспечивающем 
наиболее эффективное тестирование. 
Системное тестирование
Базис тестирования:
• система и спецификация требований к программному 
обеспечению; 
• сценарии использования;
• функциональная спецификация;
• отчеты об анализе степени риска. 
Типичные объекты тестирования:
• руководство по эксплуатации системы; 
• конфигурация системы.
Конфигурационные данные
Системное тестирование сконцентрировано на поведении 
тестового объекта как целостной системы или продукта. Область 
тестирования должна быть четко определена в главном плане 
тестирования либо плане тестирования для конкретного уровня 
тестирования. 
Во время системного тестирования тестовое окружение должно 
быть как можно ближе к предполагаемому эксплуатационному 
окружению системы для минимизации риска пропуска отказов, 
связанных с эксплуатационным окружением системы.
Системное тестирование может включать тесты, основанные на 
рисках или спецификациях требований, бизнес-процессах, сценариях 
использование системы, или других высокоуровневых текстовых 

84 
описаниях или моделях поведения системы, взаимодействия с ОС и 
системными ресурсами.
Системное тестирование должно заниматься исследованием 
функциональных и нефункциональных требований к системе и 
качеством обрабатываемых данных. Тестировщики также должны 
уметь выполнять свои обязанности в случае неполных или 
недокументированных 
требований. 
Системное 
тестирование 
функциональных требований начинается с тестирования на основе 
спецификаций (тестирования методом черного ящика), для различных 
аспектов системы. Например, таблица решений может быть создана 
на основе бизнес-правил работы системы. Тестирование на основе 
структуры 
(тестирование 
методом 
белого 
ящика) 
может 
использоваться для оценки тщательности тестирования того или 
иного структурного элемента, такого как структура меню или 
навигация веб-страницы. 
Системное тестирование чаще всего выполняет независимая 
тестовая команда.
Приемочное тестирование
Базис тестирования:
• пользовательские требования; 
• системные требования; 
• сценарии использования;
• бизнес процессы;
• отчеты об анализе степени риска.
Типичные объекты тестирования:
• бизнес-процессы на полностью интегрированной системе; 
• процессы эксплуатации и обслуживания;
• процедуры использования;
• форы; 
• отчеты. 
Конфигурационные данные 

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

жүктеу/скачать 2,75 Mb.

Достарыңызбен бөлісу: