Основы тестирования программного обеспечения [Кирилл Алек­сандрович Кулаков] (pdf) читать онлайн

Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное
учреждение высшего образования
ПЕТРОЗАВОДСКИЙ ГОСУДАРСТВЕННЫЙ
УНИВЕРСИТЕТ

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

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

Петрозаводск
Издательство ПетрГУ
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
ISBN 978-5-8021-3222-7

© Кулаков К. А., Димитров В. М., 2018
©Петрозаводский государственный
университет, 2018

Содержание
Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

§ 1. Тестирование на этапах жизненного цикла проекта
1.1. Планирование и анализ требований . . . . . . . . . . .
1.2. Проектирование . . . . . . . . . . . . . . . . . . . . . . .
1.3. Кодирование и написание документации . . . . . . . .
1.4. Тестирование . . . . . . . . . . . . . . . . . . . . . . . .
1.5. Сопровождение . . . . . . . . . . . . . . . . . . . . . . .

7
7
9
10
12
13

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

14
14
15
16
17
21
23
26
26
27

§ 3. Структура документации тестирования
3.1. План тестирования . . . . . . . . . . . . .
3.2. Тестовый отчет . . . . . . . . . . . . . . .
3.3. Матрица соответствия требований . . . .
3.4. Лист проверки . . . . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

30
30
34
34
35

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

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

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

3

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

36
37
38
38
39

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

41
41
44
45

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 “Программная инженерия”. Освоение
материала, представленного в пособии, позволит приобрести навыки
по планированию тестирования, проектированию, реализации и запуску тестовых наборов, анализу полученных результатов.

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

§ 1.

7

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

Рассмотрим классический жизненный цикл проекта:
• Планирование и анализ требований.
• Проектирование. Создание моделей и представлений проекта:
дизайн интерфейса, архитектура, структуры данных, алгоритмов и т. д.
• Кодирование и написание документации.
• Тестирование и исправление недостатков.
• Сопровождение (после выпуска) и усовершенствование.
На каждом этапе жизненного цикла должны выполняться верификация и валидация проекта. Верификация (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, трассируемость требования в тестах) — это двумерная таблица, содержащая
соответствие функциональных требований ПО и подготовленных тестовых сценариев. В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении
— отметка, означающая, что требование текущей колонки покрыто
тестовым сценарием текущей строки. Матрица соответствия требований используется руководителями тестирования ПО для валидации
покрытия продукта тестами и является неотъемлемой частью тестплана.

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

3.4.

35

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

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

Отчет об ошибке

36

§ 4.

Отчет об ошибке

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

Отчет об ошибке

4.1.

37

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

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

Отчет об ошибке

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 (https://www.bugzilla.org/),
• Redmine (https://www.redmine.org/),
• Trac (https://trac.edgewall.org/),
• Atlassian JIRA (https://ru.atlassian.com/software/jira).
При выборе системы отслеживания ошибок также учитывают следующие факторы: лицензия, стоимости, язык интерфейса, наличие
базы знаний ошибок, набор функциональности и др.

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

§ 5.

41

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

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

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

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

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

Динамическое тестирование

§ 6.

47

Динамическое тестирование

Динамическое тестирование производится путем запуска ПО
и проверки его функционала. Проверка осуществляется с помощью
ручного или автоматического выполнения заранее подготовленного
набора тестов.
Можно выделить следующие виды динамического тестирования:
• функциональное тестирование (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 10081987, 1986.
[2] IEEE Standard for Software Test Documentation, in IEEE Std 8291998, 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 http://istqbexamcertification.
com/

Учебное электронное издание

Кулаков Кирилл Александрович
Димитров Вячеслав Михайлович

Основы тестирования программного обеспечения
Учебное электронное пособие для обучающихся
Института математики и информационных технологий
Электронная версия и оформление обложки В. М. Димитрова
Ответственный за выпуск O. В. Обарчук

Подписано к изготовлению 25.12.17. Тираж 100 экз.
1 CD-R. 1,5 Мб. Изд. №217
Федеральное государственное бюджетное образовательное
учреждение высшего образования
ПЕТРОЗАВОДСКИЙ ГОСУДАРСТВЕННЫЙ
УНИВЕРСИТЕТ
185910, г. Петрозаводск, пр. Ленина, 33
https://petrsu.ru
Тел. (8142) 71-10-01
Изготовлено в Издательстве ПетрГУ
185910, г. Петрозаводск, пр. Ленина, 33
URL: press.petrsu.ru/UNIPRESS/UNIPRESS.html
Тел./факс (8142) 78-15-40
nvpahomova@yandex.ru