Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное

учреждение высшего образования
ПЕТРОЗАВОДСКИЙ ГОСУДАРСТВЕННЫЙ
УНИВЕРСИТЕТ

К. А. Кулаков, В. М. Димитров

Основы тестирования
программного обеспечения

Учебное электронное пособие для обучающихся

Института математики и информационных технологий

Петрозаводск
Издательство ПетрГУ
2018
УДК 004
ББК 32.973.2
K90 Издается по решению редакционно-издательского совета
Петрозаводского государственного университета
Издается в рамках реализации проекта моделирования
практикоориентированных образовательных программ
бакалавриата по направлению «Программная инженерия»
Р е ц е н з е н т ы:
канд. техн. наук. А. В. Сысун; канд. техн. наук. И. М. Шабалина
Кулаков, Кирилл Александрович.
K90 Основы тестирования программного обеспечения [Электронный ре-
сурс]: учебное электронное пособие для для обучающихся Института
математики и информационных технологий / К. А. Кулаков, В. М.
Димитров; М-во образования и науки Рос. Федерации, Федер. гос.
бюджет. образоват. учреждение высш. образования Петрозавод. гос.
ун-т. — Петрозаводск : Издательство ПетрГУ, 2018. — Систем. тре-
бования : PC, MAC с процессором Intel 1.3 ГГц и выше ; Windows,
MAC OSX ; 256 Мб ; видеосистема : разрашение экрана 800x600 и
выше ; графический ускоритель (опционально) ; мышь или другое
аналогичное устройство. — Загл. с этикетки диска.
ISBN 978-5-8021-3222-7
В учебном пособии содержатся теоретические и практические
сведения по планированию, организации, проведению и поддержке
одного из основополагающих этапов разработки программного обес-
печения — тестирования. Рассматриваются обоснование и необходи-
мость тестирования, роль тестирования на различных этапах жиз-
ненного цикла проекта, виды тестирования, управление ошибками.
Пособие предназначено для обучающихся Института математи-
ки и информационных технологий направлений подготовки «При-
кладная математика и информатика», «Информационные системы
и технологии» и «Программная инженерия».
УДК 004
ББК 32.973.2

© Кулаков К. А., Димитров В. М., 2018

ISBN 978-5-8021-3222-7 ©Петрозаводский государственный
университет, 2018
Содержание
Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

§ 1. Тестирование на этапах жизненного цикла проекта 7

1.1. Планирование и анализ требований . . . . . . . . . . . 7
1.2. Проектирование . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Кодирование и написание документации . . . . . . . . 10
1.4. Тестирование . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5. Сопровождение . . . . . . . . . . . . . . . . . . . . . . . 13

§ 2. Проектирование и разработка тестов . . . . . . . . . . 14

2.1. Характеристики хорошего теста . . . . . . . . . . . . . 14
2.2. V-модель разработки ПО . . . . . . . . . . . . . . . . . 15
2.3. Позитивные и негативные тесты . . . . . . . . . . . . . 16
2.4. Методы разработки тестов . . . . . . . . . . . . . . . . 17
2.5. Модульное тестирование . . . . . . . . . . . . . . . . . . 21
2.6. Интеграционное тестирование . . . . . . . . . . . . . . 23
2.7. Системное тестирование . . . . . . . . . . . . . . . . . . 26
2.8. Пользовательское тестирование . . . . . . . . . . . . . 26
2.9. Принципы тестирования . . . . . . . . . . . . . . . . . . 27

§ 3. Структура документации тестирования . . . . . . . . 30

3.1. План тестирования . . . . . . . . . . . . . . . . . . . . . 30
3.2. Тестовый отчет . . . . . . . . . . . . . . . . . . . . . . . 34
3.3. Матрица соответствия требований . . . . . . . . . . . . 34
3.4. Лист проверки . . . . . . . . . . . . . . . . . . . . . . . 35

§ 4. Отчет об ошибке . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1. Структура отчета об ошибке . . . . . . . . . . . . . . . 37
4.2. Анализ воспроизводимости . . . . . . . . . . . . . . . . 38
4.3. Жизненный цикл отчета . . . . . . . . . . . . . . . . . 38
4.4. Системы отслеживания ошибок . . . . . . . . . . . . . 39

§ 5. Статическое тестирование . . . . . . . . . . . . . . . . . 41
5.1. Рецензирование . . . . . . . . . . . . . . . . . . . . . . . 41
5.2. Статический анализ кода . . . . . . . . . . . . . . . . . 44
5.3. Метрики кода . . . . . . . . . . . . . . . . . . . . . . . . 45

3
4

§ 6. Динамическое тестирование . . . . . . . . . . . . . . . . 47

§ 7. Разработка через тестирование . . . . . . . . . . . . . . 52

Приложение. Пример практического задания . . . . . . . 54

Список литературы . . . . . . . . . . . . . . . . . . . . . . . . 56
Введение 5

Введение
В проектах по разработке программного обеспечения (ПО) по-
мимо основной задачи по реализации заявленной функциональности
существует не менее важная задача по обеспечению качества ПО.
Качество ПО (Software quality) — это совокупность характеристик
программного обеспечения, относящихся к его способности удовлетво-
рять установленные и предполагаемые потребности. Каждый участ-
ник проекта может иметь собственное представление о критериях ка-
чества и оценке степени присутствия критериев качества в ПО. Таким
образом, возникает задача определения круга заинтересованных лиц,
согласования набора критериев качества и нахождения оптимального
баланса критериев качества, обеспечивающего качественное ПО.
Одним из устоявшихся способов контроля качества является те-
стирование. Тестирование ПО (Software testing) — проверка соот-
ветствия между реальным и ожидаемым поведением программы, осу-
ществляемая на конечном наборе тестов, выбранном определенным
образом. Тестирование включает следующие этапы:
1) планирование работ (Test Management);
2) проектирование тестов путем ручной разработки или автомати-
ческой генерации (Test Design);
3) выполнение тестирования с получением результатов (Test
Execution);
4) анализ полученных результатов выполнения с целью оценки ка-
чества ПО (Test Analysis).
В связи с этим возникают следующие проблемы.
“Что тестировать?” Как правило, программный продукт пред-
ставляет собой результат длительной работы команды разработчиков.
В результате запуск ПО приводит к взаимодействию множества ком-
понент, что влечет за собой трудности с локализацией выявленных
ошибок.
“Как тестировать?” В силу большого числа комбинаций вход-
ных значений и путей выполнения необходимо найти такое множество
тестов, при котором тестирование будет максимально полным.
“Как оценить результат?” Так как код и тест являются ре-
зультатом деятельности человека, в них могут содержаться ошибки.
6 Введение

Таким образом, результат теста может сообщить нам, что ошибка при-
сутствует в коде, тесте или в коде и тесте одновременно. Кроме этого,
объект тестирования может выдавать большой объем выходных дан-
ных, требующий значительных усилий для анализа.
Пособие предназначено для студентов направлений 01.03.02 “При-
кладная математика и информатика”, 09.03.02 “Информационные си-
стемы и технологии” и 09.03.04 “Программная инженерия”. Освоение
материала, представленного в пособии, позволит приобрести навыки
по планированию тестирования, проектированию, реализации и за-
пуску тестовых наборов, анализу полученных результатов.
Тестирование на этапах жизненного цикла проекта 7

§ 1. Тестирование на этапах жизненного

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

1.1. Планирование и анализ требований

На этапе планирования выполняется организация работы, согла-
сование тематики проекта с заказчиком, выработка идей проекта,
8 Тестирование на этапах жизненного цикла проекта

сбор и анализ требований, определение функциональных характери-

стик продукта. Результатом этапа являются план реализации проекта
и техническое задание.
В ходе планирования и анализа требований “тестируются” идеи.
На данном этапе к анализу могут быть привлечены специалисты и ру-
ководители разных направлений, в том числе отдела маркетинга, от-
дела разработки и др. Специалисты по тестированию в этой работе
практически никогда не участвуют.
Специалисты по тестированию знакомятся с проектными доку-
ментами и собирают различного рода информацию, которая может
оказать помощь в оценке результатов этапа и дальнейшем планирова-
нии тестирования. Для сбора информации используются следующие
способы:
• сравнительный анализ: выполняется сравнение целей и за-
дач проекта с аналогичными или похожими проектами для уста-
новления взаимосвязей и выявления потенциальных проблем;
• дискуссионные группы: выполняется анализ и обсуждение
предлагаемых идей с целью уточнения и детализации;
• обследование объекта: выполняется изучение бизнес-
процессов с целью выявления скрытой информации.
Логическим завершением каждой из этой процедур является пере-
смотр существующих планов.
В ходе анализа требований группа тестирования должна достичь
следующих целей.
• Адекватность требований. В ходе анализа требований мо-
жет выясниться, что заказчик хочет получить совершенно дру-
гой продукт. Группа тестирования должна удостовериться, что
заявленные требования соответствуют ожиданиям заказчика.
• Полнота требований. Выяснение дополнительной информа-
ции у заказчика на последующих этапах проекта может приве-
сти к дополнительным задержкам. Кроме этого, не выясненные
детали могут привести к кардинальному усложнению проекта.
• Совместимость требований. Функции разрабатываемого
программного обеспечения могут оказаться несовместимыми по
Тестирование на этапах жизненного цикла проекта 9

логическим (противоречивость функций) или психологическим

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

1.2. Проектирование
В ходе проектирования командой разработчиков создается набор
моделей — представлений будущей программной системы. К ключе-
вым моделям можно отнести следующие:
• внешний дизайн (представление системы с точки зрения конеч-
ного пользователя);
• проектирование программной архитектуры (декомпозиция, под-
системы, модули, интерфейсы);
• проектирование организации данных (потоки данных, преобра-
зования, представления);
• описания алгоритмов (параметры, действия, результат);
• прототипы.
Группа проектирования более активно участвует в проекте и за-
нимается проверкой проектных идей. Как правило, анализ и обсуж-
дение проектных решений выполняется на совещаниях аналитиков.
В результате формируются новые проектные решения или модифи-
цируются текущие.
10 Тестирование на этапах жизненного цикла проекта

• Эффективность проекта. Насколько проект отвечает задаче

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

1.3. Кодирование и написание документации

В ходе выполнения этапа разработчики создают код и программ-
ную документацию. Задачей группы тестирования является разработ-
ка тестов. Тесты создаются на основе внутренней структуры кода или
алгоритма (белый ящик, White box testing) или функциональности
объекта тестирования (черный ящик, Black box testing). Разработка
тестов белым ящиком позволяет:
• проверить логику работы кода;
• выполнить полный охват кода;
• проверить потоки данных;
• отследить целостность данных;
• проверить внутренние граничные точки.
Разработка тестов черным ящиком позволяет:
• проверить работу сложных объектов;
• проверить работу на некорректных данных;
• тестировать с точки зрения пользователя;
Тестирование на этапах жизненного цикла проекта 11

• создавать тесты параллельно с кодом.

По аналогии с проектированием тестирование большого сложного
объекта (целостное) принесет меньше информации, чем тестирование
составляющих объект модулей (модульное) и их взаимосвязей (ин-
теграционное). С другой стороны, модульное тестирование требует
дополнительных затрат на создание условий запуска и имитацию дея-
тельности смежных модулей. Однако затраты на создание окружения
тестируемого модуля, как правило, однократные, а окружение может
быть использовано как для автоматизации тестирования, так и при
сопровождении проекта, например, при демонстрации работы компо-
нент.
Таким образом, задача группы тестирования заключается в опре-
делении объектов тестирования, их взаимосвязей, подготовке окру-
жения и набора тестов.
Для оценки результатов работы группы тестирования используют
метрики покрытия (Coverage criteria) или полноты. Метрики по-
крытия позволяют оценить охват объекта тестирования тестами и вы-
явить слабые места, где покрытие тестами минимально. Для оценки
покрытия можно воспользоваться следующими метриками.
• Критерий охвата функций (Function coverage) — каждая функ-
ция вызывается хотя бы раз.
• Критерий охвата строк (Statement coverage) — самый слабый,
каждая строка должна выполниться.
• Критерий охвата ветвлений (Decision / Branch coverage) — более
основательный, каждое ветвление проверяется по всем направ-
лениям.
• Критерий охвата условий (Condition coverage) — более стро-
гий, проверка всех составляющих логического условия (каж-
дое атомарное булево выражение приняло значения и «истина»,
и «ложь»).
• Критерий охвата параметров (Parameter Value coverage) — про-
верка всех значений параметров метода.
• Критерий охвата путей (Path coverage) — все возможные пути
в коде были пройдены.
12 Тестирование на этапах жизненного цикла проекта

• Критерий охвата циклов (Loop coverage) — все циклы исполня-

лись 0, 1, . . . , N раз.

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

наличия не исправленных ошибок в момент завершения этапа фор-

мируется итоговый список.

1.5. Сопровождение
На сопровождение программного обеспечения может тратится до
2/3 части от его общей стоимости. Эту сумму можно поделить при-
мерно так [3]:
• 20% правка ошибок;
• 4% изменения, связанные с повышением производительности;
• 25% внесение изменений в продукт в связи с изменением аппа-
ратного обеспечения и программной среды;
• 6% исправление документации;
• 42% доработка продукта (новый функционал);
• 3% другое.
Задачами группы тестирования на этапе сопровождения являют-
ся отслеживание появления новых ошибок и их локализация, а так-
же поддержка в актуальном состоянии системы тестирования. В ходе
дальнейших изменений и усовершенствований, как правило, проект
проходит стадию быстрой разработки.
14 Проектирование и разработка тестов

§ 2. Проектирование и разработка тестов

2.1. Характеристики хорошего теста
Выявление программных ошибок является сложной задачей. Про-
граммная ошибка (Software error) может не приводить к наблюда-
емому сбою, а, например, порождать другую программную ошиб-
ку или переводить процесс работы в некорректное состояние. Сбой
(Software failure) порождается наличием одного или нескольких де-
фектов (Software defect) — недостатков в компоненте или системе.
Для выявления программных ошибок используются тестовые случаи
или тесты.
Тестовым случаем (Test Case) называют документ, который
описывает конкретные шаги, условия и параметры, необходимые для
анализа реализации тестируемой функции. Каждый тест содержит
три базовые части.
• Предусловия (PreConditions) — шаги, которые переводят систе-
му в состояние, пригодном для проведения проверки.

• Описание теста (Description) — шаги, которые переводят си-

стему из состояния в состояние. На основании полученного ре-
зультата делается вывод о соответствии реализации заявленным
требованиям.

• Постусловия (PostConditions) — шаги, которые переводят систе-

му в изначальное положение.
Проверка результата работы объекта тестирования выполняется
на основе определения корректного состояния или эталонной моде-
ли результата. Эталонная модель определяется используемыми стан-
дартами, спецификациями или ожиданиями пользователя. Эталонная
модель может быть представлена множеством различных способов:
• неформальное представление того, «как ПО должно работать»;

• формальная техническая спецификация;

• набор тестовых примеров;

• корректные результаты работы программы;

Проектирование и разработка тестов 15

• другая (априори корректная) реализация той же исходной спе-

цификации.
Для проявления некорректных состояний необходимо создавать
тесты, обладающие следующими характеристиками:
• достижение (Reachibility) — тест должен выполнить место в ис-
ходном коде, где присутствует программная ошибка;

• повреждение (Corruption) — при выполнении ошибки состояние

программы должно испортиться с появлением сбоя;

• распространение (Propagation) — сбой должен распространить-

ся дальше и вызвать неудачу в работе ПО.
Проектирование и создание тестов, которые соответствуют опре-
деленным ранее критериям качества и целям тестирования, называ-
ется Тест дизайном (Test Design). В ходе тест дизайна необходимо
ответить на следующие вопросы:
• “Что тестировать?”

• “Как тестировать?”

2.2. V-модель разработки ПО

Разработка тестов неразрывно связана с этапами создания про-
граммного продукта. Используемый в классической модели жизнен-
ного цикла принцип увеличения детализации проекта находит свое
применение и в разработке тестов. На рисунке 1 представлена V-
модель разработки ПО.
Каждый этап разработки ПО сопровождается соответствующими
этапами разработки тестов и выполнением тестирования. В ходе сбо-
ра и анализа требований формируются аттестационные и системные
тесты, которые используются в ходе приемочного и системного тести-
рования. Проект архитектуры позволяет определить механизмы вза-
имодействия между модулями, что приводит нас к созданию интегра-
ционных тестов и затем к интеграционному тестированию. Проекти-
рование модулей сопровождается модульными тестами и модульным
тестированием.
16 Проектирование и разработка тестов

Рис. 1. V-модель разработки ПО

Написание кода ПО приводит нас к последовательному усложне-

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

2.3. Позитивные и негативные тесты

В ходе разработки тестов формируются наборы, содержащие по-
зитивные и негативные тесты. Позитивные тесты (Positive test) про-
веряют наличие требуемых действий в тестируемом объекте и их ра-
ботоспособность. Негативные тесты (Negative test) проверяют дей-
ствия тестируемого объекта в случае некорректного начала (напри-
мер, неправильные входные данные или неправильная последователь-
ность вызовов).
Позитивные тесты обладают следующими характеристиками:
• тесты, предназначенные для проверки, что программа выпол-
няет свое основное предназначение;
• тесты на основании «правильных» входных данных;
Проектирование и разработка тестов 17

• тестирование с целью проверки соответствий требованиям.

Для создания позитивных тестов необходимо определить допустимые
значения входных параметров, требуемую функциональность и ожи-
даемый эталонный результат.
Основная задача негативных тестов заключается в определении
и минимизации деструктивных воздействий в случае некорректной
работы компонент ПО или его окружения. Негативные тесты облада-
ют следующими характеристиками:
• тесты для проверки устойчивости ПО к негативным входным
данным;
• тесты на проверку устойчивости ПО к ошибкам пользователя;
• тесты на то, что у программы нет неожиданных побочных эф-
фектов;
• тестирование с целью «сломаем это!».

2.4. Методы разработки тестов

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

Таблица 1. Отличия черного и белого ящиков.

Критерий Черный Ящик Белый Ящик

Основной уровень Приемочное тести- Модульное тести-
применимости рование рование
Ответственный Независимый Разработчик
тестировщик
Знание программи- Не обязательно Необходимо
рования
Знание реализации Не обязательно Необходимо
Знание сценариев Необходимо Не обязательно
использования
Основа тестовых Спецификации Код
сценариев

реализации модуля, тестировщик создает тестовые сценарии пользо-

вательского уровня, которые покрывают потенциально проблемную
область. Серый ящик особенно удобен для проверки интерфейсов вза-
имодействия объектов (интеграционное тестирование).
Главной проблемой тестирования является определение того, до-
статочно ли текущего количества тестов для вывода о правильности
реализации системы, а также нахождения такого множества тестов,
которые обладают таким свойством.
Для решения этой проблемы используют следующие методики:
• эквивалентное разделение (Equivalence Partitioning);
• анализ граничных значений (Boundary Value Analysis);
• причина / следствие (Cause/Effect);
• предугадывание ошибки (Error Guessing);
• исчерпывающее тестирование (Exhaustive Testing);
Число возможных комбинаций входных параметров может быть
очень большим. Также число возможных путей следования внутри
тестируемого объекта может быть очень большим. В силу ограни-
ченности временных ресурсов, выделенных на проект в целом и этап
Проектирование и разработка тестов 19

тестирования в частности, выполнение полного тестирования невоз-

можно. В таких случаях тесты объединяют в группы при выполнении
следующих условий:
• тесты, которые предназначены для тестирования одной и той
же ошибки;
• при выявлении ошибки в одном из тестов другие тесты, вероят-
нее всего, тоже это сделают;
• при отсутствии ошибки в одном из тестов в других тестах, ве-
роятнее всего, она также будет отсутствовать;
Тесты, объединенные в группу, называются эквивалентными, а са-
ма группа — классом эквивалентности. Для проведения тестиро-
вания достаточно выбрать по одному представителю из классов экви-
валентности.
Изменение поведения тестируемого объекта происходит при до-
стижении внешних или внутренних граничных значений. Гранич-
ные значения принадлежат одному или нескольким классам эквива-
лентности или образуют собственный класс эквивалентности. В связи
с этим тесты с участием граничных значений являются наилучшими
кандидатами.
В ряде случаев необходимо проверить реализованные причинно-
следственные связи, например, условия (причин) для получения от-
вета от ПО (следствие). Использование этой методики построения те-
стов позволяет проверить работу ПО в динамике (потоки данных,
передача управления и т. д.).
Использование накопленного опыта в области разработки и те-
стирования ПО позволяет проектировщику тестов предугадать места
появления ошибок. Например, в поле ввода номера пользователь мо-
жет попытаться ввести отрицательное значение, ноль или текстовую
фразу.
Исчерпывающее тестирование — это крайний случай. В пределах
этой методики проверяются все возможные комбинации входных зна-
чений. На практике применение исчерпывающего тестирования невоз-
можно в силу того, что количество входных значений бесконечно.
Для примера, рассмотрим функцию двух вещественных перемен-
ных, допустимые значения которых лежат в области [0, a] и [0, b]. Пол-
ное тестирование функции невозможно в силу бесконечного числа воз-
20 Проектирование и разработка тестов

можных комбинаций значений переменных, однако можно разделить

комбинации на следующие группы в соответствии с рисунком 2.

Рис. 2. Пример разбиения на классы эквивалентности

1) Значения переменных внутри области допустимых значений.

Такая комбинация подойдет для проверки работоспособности
исследуемой функции. Такие тесты называются общими.
2) Одно значение или оба превышают верхнюю границу области
допустимых значений. Эта группа тестов подходит для провер-
ки реакции функции на некорректные входные данные. Такие
тесты называются негативными.
3) Одно значение находится на верхней границе, а другое — внутри
области допустимых значений. Такие тесты называются крае-
выми.
4) Одно значение находится на нижней границе, а другое — внутри
области допустимых значений. Группы 3 и 4 можно объединить,
если поведение функции одинаково.
5) Оба значения находятся на верхней или нижней границе од-
новременно. В первом случае мы проверяем работу функции
на максимальных значениях входных параметров, а во втором
случае — на минимальных. Такие тесты называются специаль-
ными.
Проектирование и разработка тестов 21

6) Одно значение меньше нижней границы, а второе внутри обла-

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

7) Оба значения меньше нижней границы области допустимых

значений. Группы 6 и 7 можно объединить, если поведение
функции одинаково.

Таким образом, для исследуемой функции достаточно 7 тестов,

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

• Одни и те же значения входных данных.

• Выполняются одинаковые функции программы.

• Одни и те же значения выходных данных.

• Блок обработки ошибок программы вызывается всеми тестами.

• Блок обработки ошибок программы не вызывается ни одним

тестом.

2.5. Модульное тестирование

Модульное (блочное) тестирование нацелено на независимую про-
верку работы компонент (модулей, блоков, объектов, классов, функ-
ций и т. д.) ПО. Тестирование модулей выполняется изолированно, без
интеграции с другими модулями ПО. В связи с этим для выполнения
тестирования требуется реализовывать и/или подключать заглушки,
эмуляторы и другие вспомогательные инструменты, заменяющие пол-
ностью или частично реальные компоненты ПО.
Разработка тестов основывается на внутренней структуре модуля
(белый ящик). Задачами модульного тестирования являются поиск
22 Проектирование и разработка тестов

дефектов, связанных с алгоритмическими ошибками, ошибками ко-

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

Рис. 3. Схема организации запуска модульного теста

Анализ результата работы модуля и сравнение с эталоном выполня-

ется с помощью специального модуля (оракула). Оракул позволяет
Проектирование и разработка тестов 23

выявить требуемые элементы из множества результирующей инфор-

мации, выполнить сравнение с эталонным результатом и сделать вы-
вод о получении или отсутствии дефекта.

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

Интеграционное тестирование (Integration testing) направлено
на проверку взаимодействия между частями (модулями) приложения.
На этапе интеграционного тестирования выполняется поиск ошибок,
связанных с трактовкой данных, реализацией интерфейса взаимодей-
ствия и совместимостью компонент приложения. Как правило, для
интеграционного тестирования применяется метод серого ящика: из-
вестны все характеристики взаимосвязей между модулями, но модули
закрыты для анализа.
В ходе интеграционного тестирования выполняется объединение
модулей в блоки. Существуют два основных подхода к проведению
интеграции:
• восходящая интеграция (Bottom Up Integration);
• нисходящая интеграция (Top Down Integration).
Восходящая интеграция предполагает объединение модулей низ-
кого уровня в группы, группы с группами или модулями и с получе-
нием в итоге целого приложения в соответствии с рисунком 4. Нис-
ходящая интеграция предполагает последовательное присоединение
модулей к группе, содержащей управляющий модуль в соответствии
с рисунком 5. Преимущества и недостатки представленных подходов
отражены в таблице 2.
В ряде случаев предпочтительным является использование сме-
шанной интеграции (Mixed Integration), когда модули собираются
в блоки (восходящая интеграция), а блоки присоединяются к управ-
ляющему модулю (нисходящая интеграция). Смешанная интеграция
позволяет минимизировать недостатки традиционных подходов.
Также существует подход «Большого взрыва» («Big Bang»
Integration), который подразумевает сбор всех модулей в одну систему
и проведение интеграционного тестирования. Данный подход может
сохранить время, однако может привести к одномоментному появле-
нию большого количества ошибок.
24 Проектирование и разработка тестов

Рис. 4. Схема восходящей интеграции

Рис. 5. Схема нисходящей интеграции

Проектирование и разработка тестов 25

Таблица 2. Сравнение способов интеграции

Восходящее Нисходящее
Преимущества • Возможность ранней • Возможность ранней
проверки корректно- проверки корректно-
сти низкоуровневого сти высокоуровневого
поведения поведения
• Не требуется написа- • Модули могут добав-
ние заглушек ляться по одному,
независимо друг от
• Просто определить
друга
требования ко входа-
м/выходам модулей • Не требуется раз-
работка множества
драйверов
• Можно разрабаты-
вать систему как
в глубину, так и в
ширину

Недостатки • Отложенная проверка • Отложенная провер-

высокоуровневого по- ка низкоуровневого
ведения поведения
• Требуется разработка • Требуется разработка
драйверов «заглушек»
• При замене драйвера • Крайне сложно
на модуль высоко- корректно сформу-
го уровня может лировать требования
произойти «мини- ко входам/выходам
Большой Взрыв» частичной системы
числа найденных
ошибок
26 Проектирование и разработка тестов

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

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

2.8. Пользовательское тестирование

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

аудио-видео фиксация действий и комментариев пользователя с по-

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

• определение цели тестирования;

• формулировка задания и инструкции для пользователей;

• определение перечня респондентов;

• проведение тестирования;

• оценка результатов.

2.9. Принципы тестирования

Разработка правильных и эффективных тестов – достаточно
непростое занятие. Принципы тестирования, представленные ниже,
были разработаны в последние 40 лет и являются общим руковод-
ством для тестирования в целом [7].
1. Тестирование может найти ошибки (Testing shows
presence of defects).
Тестирование может найти ошибки в ПО, но не доказать их от-
сутствие. Однако важно находить варианты тестов, которые будут
выявлять как можно больше ошибок. Это позволит снизить вероят-
ность появления ошибок в ПО. Ни в коем случае нельзя утвержать,
что ПО не содержит ошибок даже если тестирование не выявило их.
2. Полное тестирование невозможно (Exhaustive testing is
impossible).
28 Проектирование и разработка тестов

Нет возможности провести полное тестирование, включающее

весь возможный ввод пользователя и состояния системы. Но необ-
ходимо правильно расставлять приоритеты и анализировать риски.
Это может позволить более эффективно обеспечить качество ПО.
3. Раннее тестирование (Early testing).
Тестирование необходимо начинать как можно раньше. На разных
этапах жизненого цикла разработки ПО оно должно преследовать
определенные цели.
4. Скопление дефектов (Early testing).
Разные модули системы могут содержать разное количество де-
фектов, то есть плотность скопления дефектов в разных элемен-
тах программы может отличаться. Усилия по тестированию должны
распределяться пропорционально фактической плотности дефектов.
В основном, большую часть критических дефектов находят в ограни-
ченном количестве модулей. Это проявление принципа Парето: 80%
дефектов содержатся в 20% модулей.
5. Парадокс пестицида (Pesticide paradox).
Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем,
что они находят все меньше новых ошибок. Поскольку ПО эволюци-
онирует, многие из ранее найденных дефектов исправляют и старые
тест-кейсы больше не срабатывают.
Чтобы преодолеть этот парадокс, необходимо периодически вно-
сить изменения в используемые наборы тестов, рецензировать и кор-
ректировать их с тем, чтобы они отвечали новому состоянию ПО
и позволяли находить как можно большее количество дефектов.
6. Тестирование зависит от контекста (Testing is context
dependent).
Выбор методологии, техники и типа тестирования будет напря-
мую зависеть от природы самого ПО. Например, ПО для медицинских
нужд требует гораздо более строгой и тщательной проверки, чем, на-
пример, сайт магазина. Из тех же соображений, сайт с большой посе-
щаемостью должен пройти через серьезное тестирование производи-
тельности, чтобы показать возможность работы в условиях высокой
нагрузки.
7. Заблуждение об отсутствии ошибок (Absence–of–errors
fallacy).
Тот факт, что тестирование не обнаружило дефектов, еще не зна-
чит, что ПО готово к публикации. Нахождение и исправление дефек-
Проектирование и разработка тестов 29

тов будут не важны, если ПО окажется неудобным в использовании,

и не будет удовлетворять ожиданиям и потребностям пользователя.
30 Структура документации тестирования

§ 3. Структура документации тестирова-

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

Рис. 6. Структура документации тестирования

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

План тестирования (Test plan) — это основной документ этапа
тестирования, который описывает работы по тестированию, начиная
с описания объекта, стратегии, расписания, критериев начала и окон-
чания тестирования, до необходимого в процессе работы оборудова-
ния, специальных знаний, а также оценки рисков с вариантами их
разрешения.
Основные вопросы, которые план тестирования должен раскрыть:
• Что необходимо тестировать: включает в себя абсолютно все
аспекты ПО, которые могут быть протестированы.
• Что будет тестироваться: подмножество пунктов из первого во-
проса, которые будут протестированы. Из первого вопроса ис-
Структура документации тестирования 31

ключаются аспекты, исходя из анализа сроков, бюджета, прио-

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

– списки отчетов и экранных форм;

– списки входных и выходных переменных;
– списки возможностей и функций;
– списки сообщений об ошибках;
– список файлов программы.

• Тестовую стратегию, включающую:

– Анализ функций и подсистем с целью определения наибо-

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

• Расписание тестовых циклов.

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

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

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

• Тестирование работы на конкретной платформе.

В реальных разработках используются и комбинируются различ-

ные типы тестов для обеспечения спланированного качества продук-
та.

3.2. Тестовый отчет

В результате тестирования (после каждого этапа тестирования)
формируется документ, который называется тестовым отчетом. Он
должен содержать:

• Что было запланировано для тестирования и что удалось про-

тестировать.

• Время тестирования.

• Выполненные тесты и результат их выполнения.

• Найденные ошибки и повторно найденные ошибки.

• Найденные отклонения от разработки программного обеспече-

ния.

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

3.3. Матрица соответствия требований

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

3.4. Лист проверки

Лист проверки (чек-лист, check list) — это документ, описываю-
щий что должно быть протестировано. Лист проверки может быть
абсолютно разного уровня детализации. На сколько детальным будет
чек-лист, зависит от требований к отчетности, уровня знания продук-
та сотрудниками и сложности продукта. Как правило, лист проверки
содержит только действия (шаги), без ожидаемого результата. Лист
проверки менее формализован, чем тестовый сценарий. Его уместно
использовать тогда, когда тестовые сценарии будут избыточны. Лист
проверки обычно используется в гибких подходах в тестировании.
36 Отчет об ошибке

§ 4. Отчет об ошибке
Ошибкой ПО считают либо расхождение между программой и ее
спецификацией в том случае, когда спецификация существует и она
правильная, либо когда программа не делает того, чего пользователь
от нее вполне обоснованно ожидает.
Все ошибки можно разделить по следующим категориям:
• Ошибки пользовательского интерфейса:
– Отсутствие или неправильная работа ожидаемой функ-
ции.
– Взаимодействие программы с пользователем. Например,
возможность ввести неправильный тип данных там, где
есть такие ограничения.
– Организация программы (легко ли найти нужную функ-
цию).
– Низкая производительность ПО.
– Выходные данные (правильно ли формируются отчеты).
• Недостаточно качественная обработка ошибок.
• Ошибки, связанные с обработкой граничных условий.
• Ошибки вычислений и алгоритмов.
• Ошибки управления потоком (последовательность действий).
• Ошибки передачи или интерпретации данных (взаимодействие
с другим ПО).
• Ошибки, связанные с пиковыми нагрузками на ПО.
• Ошибки, возникающие на специфичном аппаратном обеспече-
нии.
• Ошибки в описании ПО (его документации), обычно возникают
при переработки функционала ПО.
• Ошибки тестирования.
Цель создания отчета об ошибке заключается в том, чтобы ее
исправить. Создание отчета необходимо для всех участвующих лиц
в разработке ПО — от заказчика до разработчика. Кроме того, это
помогает осуществлять анализ разработки ПО во времени.
Отчет об ошибке 37

4.1. Структура отчета об ошибке

Отчет об ошибке может включать в себя следующие разделы:

• программа или модуль (указывается при наличии нескольких

компонент ПО (например, серверная или клиентская части) или
реализаций ПО под несколько платформ);

• версия программы или модуля;

• тип отчета (может включать в себя ошибку или запрос на до-

бавление новой функциональности);

• важность отчета (варианты значения: критический, высокий,

средний, низкий);

• описание;

• повторяемость;

• последовательность шагов для воспроизведения ошибки;

• предлагаемое исправление;

• автор отчета;

• ответственный за исправление;

• комментарии пользователей ПО;

• текущее состояние отчета (варианты значения: открытый, за-

крытый);

• приоритет отчета (отмечается руководителем разработки ПО в

отличие от важности, которую указывает автор отчета);

• срок выполнения работ (указывается руководителем разработ-

ки ПО).

Составление подробных отчетов и сбор полной информации об

ошибках является очень важным элементом тестирования.
38 Отчет об ошибке

4.2. Анализ воспроизводимости

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

• максимально подробно записать последовательность действий,

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

4.3. Жизненный цикл отчета

Этапы жизненного цикла отчета об ошибке:
• неподтвержденная (unconfirmed). После публикации отчет об
ошибке попадает на первичное рассмотрение, в результате кото-
рого ответственные лица решают допустить ли этот отчет к ана-
лизу или отправить на доработку, например из-за отсутствия
некоторых данных;
• новая (new). Руководители проекта или ответственные лица
анализируют ошибку и либо назначают ответственного за ее
исправление, либо переводят ее в один из статусов: повторная
(duplicate), отклонена (rejected), не ошибка (not a bug), после
чего закрывают ее;
• назначен ответственный (assigned). Ошибка ждет начала рабо-
ты над ней;
• открытая (open). Этот статус ошибки означает, что ответствен-
ный за исправление начал работу над ней;
Отчет об ошибке 39

• исправленная (fixed). Ошибка исправлена и требует повторного

тестирования;
• проверена (verified). Исправления протестированы и могу быть
опубликованы. Если в результате тестирования были выявлены
другие ошибки, связанные с исправлениями, или ошибка была
воспроизведена, то ошибка возвращается в статус «открытая»;
• опубликована (published). Версия ПО с исправленной ошибкой
опубликована;
• закрыта (closed). Ошибка закрыта;
На рисунке 7 представлен жизненный цикл отчета об ошибке.

Рис. 7. Жизненный цикл отчета об ошибке

4.4. Системы отслеживания ошибок

Как видно из вышеприведенного списка разделов отчета об ошиб-
ке, его составление является достаточно трудоемкой задачей. Еще бо-
40 Отчет об ошибке

лее трудоемкой задачей является ведение таких отчетов и поддержка

их актуального состояния. Упростить эти задачи для разработчиков
ПО призваны системы отслеживания ошибок. Они позволяют:
• автоматизировать часть работ (например, заполнение некото-
рых полей отчета, возможность создания списков программ,
версий ПО и др., возможность создания специализированных
наборов важности, текущего состояния, приоритетов и др.);
• организовать взаимодействие между пользователями, заказчи-
ком и командой разработчиков;
• оценивать производительность работ и выполнения сроков по
устранению ошибок;
• оценивать состояние проекта;
• интегрироваться с системами контроля версий кода для указа-
ний мест кода, проводящих к ошибке или решающих ее;
• составлять различного рода статистические отчеты;
• использовать расширенный набор возможностей (оповещения
по электронной почте или СМС, возможность управления про-
ектами, настройка прав доступа, поддержка добавления фай-
лов, поддержка комментариев, распределение работ, ведение
подзадач и др.).
Системы отслеживания ошибок являются полезными не только
для программистов. Отчеты о «работе над ошибками» могут исполь-
зовать менеджеры проекта. Для управляющих процессом разработки
программного обеспечения такие отчеты позволяют судить о произ-
водительности программистов, при работе по улучшению работы ПО.
Приведем несколько примеров систем отслеживания ошибок:
• Bugzilla ([Link]
• Redmine ([Link]
• Trac ([Link]
• Atlassian JIRA ([Link]
При выборе системы отслеживания ошибок также учитывают сле-
дующие факторы: лицензия, стоимости, язык интерфейса, наличие
базы знаний ошибок, набор функциональности и др.
Статическое тестирование 41

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

• сбор и анализ требований — анализ требований, в том числе

проверка на адекватность, полноту и совместимость;

• проектирование — анализ проектной документации, моделей

проекта, псевдокода;

• реализация — анализ кода и реализации;

• тестирование — анализ тестов и результатов;

• сопровождение — анализ использования ПО.

5.1. Рецензирование
Основным инструментом статического тестирования является ре-
цензирование. Рецензирование (Review) — оценка состояния объек-
та анализа с целью установления расхождений с запланированными
результатами и для выдвижения предложений по совершенствованию.
Рецензирование может быть как формальным (по заранее определен-
ной процедуре с составлением отчетности), так и неформальным (на-
пример, обзор).
Выделяют следующие типы рецензирования:
• Неформальное рецензирование (Informal review, ad-hoc review)
— анализ артефакта командой из двух и более человек без ис-
пользования формальных процедур и строгой отчетности.
42 Статическое тестирование

• Инспектирование (Inspection) — тип равноправного анализа, ос-

нованный на визуальной проверке артефактов для поиска де-
фектов. Например, нарушение стандартов разработки и несоот-
ветствие документации более высокого уровня. Наиболее фор-
мальная методика рецензирования и поэтому всегда основыва-
ется на документированной процедуре.
• Разбор (Walkthrough) — проводимое автором рецензирование
для сбора информации и обеспечения одинакового понимания
содержания артефакта. Относится к неформальному типу ре-
цензирования.
• Технический анализ (Technical review) — обсуждение, имею-
щее целью выработать единый подход к техническому процессу,
и проводимое равноправными участниками. Технический ана-
лиз может проводиться как формально, так и неформально.
Цель технического анализа — оценка технических решений и
правильности их применения, а также обеспечение согласован-
ности применения технических решений.
• Экспертная оценка (Peer review) — рецензирование разрабаты-
ваемого программного продукта с привлечением сторонних экс-
пертов как внутри компании-разработчика, так и за ее предела-
ми. Цель экспертной оценки заключается в нахождении дефек-
тов и внесении улучшений.
Формальное рецензирование артефакта проекта выполняется по
следующему плану:
• планирование процесса рецензирования;
• запуск процесса (опциональный шаг);
• выполнение анализа артефакта;
• обсуждения рецензентов и выработка результатов;
• обработка результатов разработчиком артефакта;
• формирование итогового результата.
В ходе планирования процесса рецензирования определяется ав-
тор артефакта и модератор процесса. Модератор ответственен за
Статическое тестирование 43

организацию процесса рецензирования (сроки, команда участников-

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

• собрание ограничивается двумя часами, при необходимости пе-

реносится на следующий день;

• модератор имеет право отменить или прекратить собрание, если

один или несколько рецензентов не появились или недостаточно
подготовлены;

• артефакт, предоставленный на рецензирование, является пред-

метом обсуждения, а не его разработчик;

• модератор не должен быть оппонентом;

• каждый рецензент должен иметь возможность высказать свои

замечания и вопросы;

• в конце встречи все участники собрания должны подписать ито-

говый протокол.

Разработчик артефакта анализирует итоговые списки и принима-

ет решение по каждому элементу: подтверждает, уточняет/коммен-
тирует или отклоняет результат. Мнение рецензентов и разработчика
фиксируется в итоговом результате рецензирования.
44 Статическое тестирование

5.2. Статический анализ кода

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

• Формирование рекомендаций по оформлению кода в соответ-

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

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

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

• Относительно низкая стоимость анализа.

• Раннее выявление дефектов кода.

• Полное покрытие кода.

Статическое тестирование 45

• Независимость от используемого компилятора и среды выпол-

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

5.3. Метрики кода

Метрика кода ПО — численное значение некоторого свойства кода.
Метрики кода позволяют оценить качество кода и принять решения
о необходимости улучшений. Существует большое количество разно-
образных метрик, которые можно подсчитать, используя те ли иные
инструменты.
• Количественные метрики. Данный класс метрик позволяет оце-
нить объем кода, соотношение компонент кода и, в результа-
те, сложность понимания кода. К данному классу метрик отно-
сятся количество строк кода, комментариев, метрики Холстеда
и Джилба.
• Метрики сложности потока управления программы. Данный
класс метрик оценивает управляющий граф программы[6]. При-
мерами метрик являются цикломатическая сложность програм-
мы (цикломатическое число Мак-Кейба) и их модификации
(метрики Майерса, Хансена и Пивоварского).
• Метрики сложности потока данных. Данный класс метрик оце-
нивает конфигурацию, размещение и использование данных в
программе. Примерами метрик являются метрика обращения
к глобальным переменным, метрика спена и метрика Чепина.
• Метрики сложности потока управления и данных программы.
Данный класс метрик устанавливает сложность структуры про-
граммы как на основе количественных подсчетов, так и на ос-
нове анализа управляющих структур. Примерами метрик явля-
ются M-мера и метрика Мак-Клура.
• Объектно-ориентированные метрики. Данный класс метрик
специализирован на оценке использования методов объектно-
46 Статическое тестирование

ориентированного программирования. Примерами метрик яв-

ляются наборы метрик Мартина и набор метрик Чидамбера
и Кемерера.
• Метрики надежности. Метрики оценивают уровень дефектов
кода. Примерами метрик являются количество структурных из-
менений и количество ошибок. Для больших проектов обычно
рассматривают усредненные по количеству строк кода показа-
тели.
• Гибридные метрики. Метрики данного класса основываются на
более простых метриках и представляют собой их взвешенную
сумму. Примерами метрик являются метрика Кокола и метрика
Зольновского, Симмонса, Тейера.
При использовании метрик следует учитывать, что метрики не
могут служить абсолютным правилом: результаты измерений долж-
ны быть интерпретированы с учетом контекста. Кроме этого, значе-
ния метрик могут быть искажены из-за целенаправленной оптимиза-
ции работы программиста. Например, если в компании — разработчи-
ке труд программиста оценивается на основе количества написанных
строк кода, то программисты будут стремиться писать как можно
больше строк и не будут использовать способы упрощения кода, со-
кращающие количество строк.
Динамическое тестирование 47

§ 6. Динамическое тестирование
Динамическое тестирование производится путем запуска ПО
и проверки его функционала. Проверка осуществляется с помощью
ручного или автоматического выполнения заранее подготовленного
набора тестов.
Можно выделить следующие виды динамического тестирования:
• функциональное тестирование (Functional testing);

• тестирование безопасности (Security and Access Control Testing);

• тестирование взаимодействия (Interoperability Testing);

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

– нагрузочное тестирование (Performance and Load Testing);

– стрессовое тестирование (Stress Testing);
– тестирование стабильности или надежности (Stability /
Reliability Testing);
– объемное тестирование (Volume Testing);

• тестирование установки (Installation testing);

• тестирование удобства пользования (Usability Testing);

• тестирование на отказ и восстановление (Failover and Recovery

Testing);

• конфигурационное тестирование (Configuration Testing);

• дымовое тестирование (Smoke Testing);

• регрессионное тестирование (Regression Testing);

• повторное тестирование (Re-testing);

• тестирование сборки (Build Verification Test);

• санитарное тестирование или проверка согласованности/ис-

правности (Sanity Testing).
48 Динамическое тестирование

В ходе функционального тестирования проверяется соответствие

работы приложения ожиданиям пользователя. Проверка выполняет-
ся на основе предъявляемых к приложению функциональных требо-
ваний и ограничений.
В рамках тестирования безопасности выполняется комплекс про-
верок безопасности системы, а также анализ рисков, связанных с обес-
печением всесторонней защиты приложения от несанкционированно-
го доступа к защищаемым данным или от внесения изменений для
нарушения работы приложения или повреждения данных. В отече-
ственной практике для подтверждения безопасной работы приложе-
ния принято проводить сертификацию ПО, работающего с данны-
ми для служебного пользования, секретными, совершенно секрет-
ными и совершенно секретными особой важности. Существует ряд
отечественных стандартов Федеральной службы по техническому и
экспортному контролю (ФСТЭК), регламентирующих свойства про-
граммных систем по обеспечению необходимого уровня безопасности1
и по отсутствию недокументированных возможностей2 , которые мо-
гут быть использованы злоумышленником для несанкционированного
доступа к данным. Кроме того, существует международный стандарт
Common Criteria3 , также регламентирующий вопросы защиты инфор-
мации в программных системах [4].
Тестирование взаимодействия (Interoperability Testing) относится
к категории функционального тестирования и проверяет способность
приложения взаимодействовать с одним и более компонентами или си-
стемами. Тестирование взаимодействия включает в себя тестирование
совместимости (Compatibility testing) и интеграционное тестирование.
Тестирование производительности проверяет выполнение обра-
1
Гостехкомиссия России. Руководящий документ. Средства вычисли-
тельной техники. Защита от несанкционированного доступа к информации.
Показатели защищенности от несанкционированного доступа к информа-
ции. М.: Гостехкомиссия РФ, 1992.
2
Гостехкомиссия России. Руководящий документ. Защита от несанкци-
онированного доступа к информации. Часть 1. Программное обеспечение
средств защиты информации. Классификация по уровню контроля отсут-
ствия недекларированных возможностей. М.: Гостехкомиссия РФ, 1999.
3
ISO/IEC 15408. Information technology — Security techniques
— Evaluation criteria for IT security. International Organization for
Standardization. 50 p. (part 1), 248 p. (part 2), 168 p. (part 3).
Динамическое тестирование 49

ботки пользовательских запросов в условиях нагрузки на ПО и

при различных конфигурациях оборудования. Нагрузочное тестиро-
вание позволяет выявить узкие места системы, проявляющиеся в ходе
нехватки системных ресурсов. Для выполнения тестирования необхо-
димо иметь четко определенные требования с числовыми оценками
параметров производительности.
Целью стрессового тестирования является оценка устойчивости
ПО в условиях критической нагрузки. Выполнение стрессового тести-
рования аналогично нагрузочному тестированию. Задачей объемно-
го тестирования является получение оценки производительности при
увеличении объемов данных в используемой базе данных. Задачей
тестирования стабильности (надежности) является проверка работо-
способности ПО при длительном (многочасовом, многодневном) те-
стировании со средним уровнем нагрузки.
Тестирование установки направлено на проверку успешной ин-
сталляции и настройки, а также обновления или удаления ПО.
Тестирование удобства пользования направлено на установление
степени удобства использования, обучаемости, понятности и привле-
кательности ПО пользователям в контексте заданных условий. Сюда
также входит.
• Тестирование пользовательского интерфейса (UI testing) — это
вид исследования, выполняемого с целью определения, удобен
ли некоторый искусственный объект (такой как веб-страница,
пользовательский интерфейс или устройство) для его предпо-
лагаемого применения.
• Тестирование обучаемости (User eXperience testing, UX) — ощу-
щение, испытываемое пользователем во время использования
цифрового продукта, его способность к освоению, запоминанию
и пониманию работы ПО.
Тестирование на отказ и восстановление (Failover and Recovery
Testing) проверяет ПО с точки зрения способности противостоять
внутренним и внешним негативным факторам и успешно восстанав-
ливаться после возможных сбоев, возникших в связи с ошибками про-
граммного обеспечения, отказами оборудования или проблемами свя-
зи (например, отказ сети). Целью данного вида тестирования является
проверка систем восстановления (или дублирующих основной функ-
50 Динамическое тестирование

ционал систем), которые, в случае возникновения сбоев, обеспечат

сохранность и целостность данных тестируемого продукта.
В ходе тестирования конфигурации проверяется работа прило-
жения на различных комбинациях оборудования, внешних устройств
и сторонних систем. Тестирование конфигурации предназначено для
поиска и выявления проблем совместимости и реакции на штатные и
нештатные ситуации.
Дымовое (Smoke) тестирование рассматривается как короткий
цикл тестов, выполняемый для подтверждения того, что после сборки
кода (нового или исправленного) устанавливаемое приложение, стар-
тует и выполняет основные функции. Как правило, в рамках дымо-
вого тестирования выполняется поиск явных ошибок.
Регрессионное тестирование — это вид тестирования направлен-
ный на проверку изменений, сделанных в ПО или окружающей среде
(например, исправление дефекта, слияние кода, миграция на другую
операционную систему, базу данных, сервер), для подтверждения то-
го факта, что существующая ранее функциональность работает как
и прежде. Регрессионными могут быть как функциональные, так и
нефункциональные тесты.
Повторное тестирование заключается в повторном выполнении те-
стовых сценариев, выявивших ошибки во время последнего запуска,
для подтверждения успешности исправления этих ошибок. В отличии
от регрессионного тестирования повторное тестирование не проверяет
появление новых ошибок, полученных в результате внесения измене-
ний, а подтверждает устранение ранее выявленных ошибок.
Тестирование сборки (Build Verification Test) — тестирование, ана-
логичное дымовому, направленное на определение соответствия, вы-
пущенной версии, критериям качества для начала тестирования. Те-
стирование сборки может иметь достаточно большую глубину, в за-
висимости от требований к качеству выпущенной версии.
Санитарное тестирование является подмножеством регрессионно-
го тестирования и нацелено на доказательство того, что конкретная
функция работает согласно заявленным в спецификации требовани-
ям. Используется для определения работоспособности определенной
части приложения после изменений произведенных в ней или окру-
жающей среде. Обычно выполняется вручную.
Несмотря на преимущества, динамическое тестирование имеет ряд
недостатков:
Динамическое тестирование 51

• выполнение динамического тестирования требует больших вре-

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

§ 7. Разработка через тестирование

Одним из перспективных направлений обеспечения качества яв-
ляется применение метода разработки через тестирование (test-driven
development, TDD). Разработка через тестирование — метод со-
здания ПО с использованием короткого цикла разработки:
• написание теста, проверяющего будущее изменение;
• написание кода, удовлетворяющего тесту;
• рефакторинг кода в соответствии с принятыми стандартами.
Основным отличием данного метода является фокусирование разра-
ботчиков на требованиях, т. к. покрывающие требования тесты созда-
ются до написания кода.
В ходе разработки теста для предстоящего изменения рассматри-
ваются возможные сценарии использования и пользовательские исто-
рии. Новые требования могут затрагивать существующие тесты и по-
влечь их изменение. По завершении разработки и модификации те-
стов производится их запуск с целью проверки, что новые тесты не
проходят.
В ходе написания кода выполняется минимально необходимая мо-
дификация кода ПО с целью прохождения тестов. При этом напи-
санный код может содержать погрешности, которые будут устранены
впоследствии. По завершении кодирования выполняется повторный
запуск тестов с целью проверки прохождения всех тестов.
На заключительном шаге выполняется рефакторинг кода. Ре-
факторинг — процесс изменения внутренней структуры кода без из-
менения внешнего поведения для облегчения понимания его работы,
устранения дублирования и облегчения последующих изменений. По
завершении рефакторинга выполняется повторный запуск тестов с це-
лью проверки прохождения всех тестов.
Метод разработки через тестирование обладает следующими пре-
имуществами.
• Наличие большого количества тестов. Каждая модификация
ПО предполагает создание одного или нескольких тестов. По-
следние могут быть использованы в ходе автоматического те-
стирования.
Приложение. Пример практического задания 53

• Создание кода, более приспособленного для тестирования. Ис-

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

• Уменьшение времени отладки. Использование тестов позволя-

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

• Безопасный рефакторинг кода. Тесты позволяют отслеживать

корректность изменений кода в ходе рефакторинга.

Метод разработки через тестирование не лишен следующих недо-

статков.

• Существуют задачи, которые невозможно решить только с по-

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

• Разработка через тестирование ориентирована на проверку

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

• Использование тестов ведет к увеличению накладных расходов

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

• Тесты сами могут содержать ошибки, например, вследствие

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

• Использование разработки через тестирование может создать

ложное ощущение надежности, приводящее к меньшему коли-
честву действий по контролю качества.
54 Приложение. Пример практического задания

Приложение. Пример практического зада-

ния
Задание
• Выбор и согласование объекта тестирования
• Разработка плана тестирования.
• Тестирование (инспекция) проектной документации и кода.
• Реализация модульных тестов, запуск.
• Реализация интеграционных тестов, запуск.
• Реализация системных тестов, запуск.
• Анализ результатов тестирования и подготовка отчета.

Структура отчета о выполнении тестирования

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

– Описание структуры объекта тестирования и связей внут-

ри объекта тестирования (архитектура). Для каждого
структурного элемента указать отношение к тестирова-
нию.
– Описание стратегии блочного тестирования (метод про-
ведения, используемые окружение и инструменты, способ
оценки результатов).
– Описание стратегии интеграционного тестирования (схема
интеграции, последовательность шагов интеграции с ука-
занием на каждом шаге способа интеграции, метод про-
ведения, используемые окружение и инструменты, способ
оценки результатов).
Приложение. Пример практического задания 55

– Описание стратегии аттестационного тестирования (метод

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

Список литературы
[1] IEEE Standard for Software Unit Testing, in ANSI/IEEE Std 1008-
1987, 1986.
[2] IEEE Standard for Software Test Documentation, in IEEE Std 829-
1998, 1998. — с. 1-64.
[3] Тестирование программного обеспечения. Фундаментальные
концепции менеджмента бизнес–приложений: Пер. с англ./Сэм
Канер, Джек Фолк, Енг Кек Нгуен. — Киев: Издательство «Диа-
Софт», 2001. — 544 с.
[4] Верификация программного обеспечения : курс лекций / С.В.
Синицын, Н. Ю. Налютин. — Москва: Интуит НОУ, 2016. — 446
с.
[5] Макконнелл С. Совершенный код. Мастер-класс — Пер. с ан-
гл. — Москва: Издательско-торговый дом «Русская редакция»;
Санкте-Петербург: Питер, 2005. — 896 с. ISBN 5-7502-0064-7.
[6] T. J. McCabe. «A complexity measure» IEEE Transactions on
Software Engineering 1976 vol. SE-2, № 4 pp. 308—320.
[7] ISTQB Exam Certification [Link]
com/
 Учебное электронное издание

Кулаков Кирилл Александрович

Димитров Вячеслав Михайлович

Основы тестирования программного обеспечения

Учебное электронное пособие для обучающихся
Института математики и информационных технологий

Электронная версия и оформление обложки В. М. Димитрова

Ответственный за выпуск O. В. Обарчук

Подписано к изготовлению 25.12.17. Тираж 100 экз.

1 CD-R. 1,5 Мб. Изд. №217

Федеральное государственное бюджетное образовательное

учреждение высшего образования
ПЕТРОЗАВОДСКИЙ ГОСУДАРСТВЕННЫЙ
УНИВЕРСИТЕТ
185910, г. Петрозаводск, пр. Ленина, 33
[Link]
Тел. (8142) 71-10-01

Изготовлено в Издательстве ПетрГУ

185910, г. Петрозаводск, пр. Ленина, 33
URL: [Link]/UNIPRESS/[Link]
Тел./факс (8142) 78-15-40
nvpahomova@[Link]