конспект - Лаборатория ITLab - Нижегородский государственный

Нижегородский государственный университет им. Н.И. Лобачевского
Факультет вычислительной математики и кибернетики ННГУ
Компания Интел
Учебно-исследовательская лаборатория
"Математические и программные технологии для современных компьютерных систем
(Информационные технологии)"
Надежность и тестирование программного обеспечения
Нижний Новгород, 2003
Лист регистрации версий документа
Дата
30.04.03
05.05.03
Автор изменения
Чернышова Е.Н.
Чернышова Е.Н.
Номер версии
0
1
Комментарии
Создание
Создание
«Тестирование»
раздела
681450584
28.04.2016, 28 стр.
Название документа
Оглавление
1. НАДЕЖНОСТЬ ПО.................................................................................................... 4
1.1. ПОНЯТИЕ ОШИБКИ ПО ............................................................................................. 4
1.1.1. Возможные определения ошибки в ПО ........................................................ 4
1.1.2. «Окончательное» определение ...................................................................... 5
1.2. ПОНЯТИЕ НАДЕЖНОСТИ ........................................................................................... 5
1.3. МЕТОДЫ ОЦЕНКИ НАДЕЖНОСТИ .............................................................................. 5
1.3.1. Расчет величины риска, вызванного возможностью ошибок в ПО .......... 5
1.3.2. Статистическая надежность ..................................................................... 6
1.3.3. Комбинаторная надежность ........................................................................ 6
1.4. ПРИЧИНЫ ОШИБОК В ПО ......................................................................................... 7
1.5. ИСТОЧНИКИ ОШИБОК В ПО ..................................................................................... 7
1.6. МЕТОДЫ ПРОЕКТИРОВАНИЯ НАДЕЖНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ............ 7
1.6.1. Предупреждение ошибок ............................................................................... 7
1.6.2. Обеспечение устойчивости к ошибкам ........................................................ 8
1.6.3. Обнаружение ошибок ..................................................................................... 9
2. ТЕСТИРОВАНИЕ ПО ............................................................................................. 10
2.1. ПОНЯТИЕ ТЕСТИРОВАНИЯ ...................................................................................... 10
2.2. ПРИНЦИПЫ ТЕСТИРОВАНИЯ ................................................................................... 10
2.3. ПОРЯДОК ПРОЦЕССА ТЕСТИРОВАНИЯ .................................................................... 11
2.4. СТРАТЕГИИ ПРОЕКТИРОВАНИЯ ТЕСТОВ ................................................................. 11
2.4.1. Тестирование программы как «черного ящика» ....................................... 12
2.4.2. Тестирование программы как «белого ящика» ......................................... 15
2.5. ЭТАПЫ ТЕСТИРОВАНИЯ .......................................................................................... 16
2.6. ДВА ПОДХОДА К ТЕСТИРОВАНИЮ МОДУЛЕЙ ......................................................... 17
2.6.1. Восходящее и нисходящее тестирование .................................................. 17
2.7. ALPHA- И BETA- ТЕСТИРОВАНИЕ ............................................................................ 18
2.8. ПРАКТИЧЕСКОЕ ТЕСТИРОВАНИЕ ............................................................................ 19
2.8.1. Процесс разработки ПО .............................................................................. 19
2.8.2. Каскадный процесс тестирования ............................................................. 21
2.8.3. Анализ требований ....................................................................................... 22
2.8.4. Планирование испытаний ............................................................................ 23
2.8.5. Проектирование тестов, реализация и отладка ...................................... 24
2.8.6. Системное тестирование ........................................................................... 25
2.8.7. Приемочные испытания ............................................................................... 25
2.8.8. Сопровождение ............................................................................................. 26
3. ПРИЛОЖЕНИЕ ........................................................................................................ 27
ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ТЕСТИРОВАНИЯ ФИРМЫ RATIONAL SOFTWARE
CORPORATION ....................................................................................................................... 27
Учебно-исследовательская лаборатория "Информационные технологии"
3
Название документа
1. Надежность ПО
1.1. Понятие ошибки ПО
Что такое ошибка в программном обеспечении и что такое надёжность
программного обеспечения? Важно договориться о стандартном определении, чтобы
избежать таких ситуаций, когда пользователь утверждает, что обнаружил в системе
ошибку, а разработчик отвечает: "Нет, система так и была задумана".
Пример: Система раннего обнаружения баллистических снарядов Ballistic Missile
Early Warning System должна наблюдать за объектами, движущимися по направлению к
США, и, если объект не опознан, начать последовательность защитных мероприятий от попыток установить с объектом связь до перехвата и уничтожения. Одна из ранних
версий системы ошибочно принимала поднимающуюся над горизонтом Луну за снаряд,
летящий над Северным полушарием. Является ли это ошибкой? С точки зрения
пользователя (Министерства обороны США) - да. С точки зрения разработчика
системы - возможно, и нет. Разработчик может настаивать на том, что в соответствии
со спецификациями защитные действия должны быть начаты по отношению к любому
движущемуся объекту, появившемуся над горизонтом и не опознанному как мирный
летательный аппарат.
Дело в том, что разные люди по-разному понимают, что такое ошибка в
программном обеспечении.
1.1.1. Возможные определения ошибки в ПО
Рассмотрим возможные определения ошибки в программном обеспечении.
Программное обеспечение содержит ошибку, если:
1. его поведение не соответствует спецификациям.
Недостатки определения: неявно предполагается, что спецификации корректны.
Это если и бывает справедливым, то редко; подготовка спецификаций - один из
основных источников ошибок. Если поведение программного продукта не
соответствует его спецификациям, ошибка, вероятно, имеется. Однако, если система
ведёт себя в соответствии со спецификациями, мы не можем утверждать, что она не
содержит ошибок.
2. его поведение не соответствует спецификациям при использовании в
установленных при разработке пределах.
Это определение ещё хуже первого. Если система случайно используется в
непредусмотренной ситуации, её поведение должно оставаться разумным. Если это не
так, она содержит ошибку. Например, авиационная диспетчерская система, согласно
спецификациям, должна управлять движением до 200 самолётов одновременно. Но
однажды, в районе появился 201 самолёт. Если поведение системы неразумно - скажем,
она забывает об одном из самолётов или выходит из строя, система содержит ошибку,
хотя и используется вне пределов, установленных при проектировании.
3. программное обеспечение ведёт себя не в соответствии с официальной
документацией и поставленными пользователю публикациями.
А если ошибки содержатся и в программе и в публикациях? Или если в
руководстве описана только ожидаемая и планируемая работа с системой. Например,
написано: "Чтобы получить то-то, нажмите один раз то-то". Предположим, что
пользователь случайно два раза нажимает то-то и система выходит из строя, потому что
4
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
её разработчики не предусмотрели такой ситуации. Система, очевидно, содержит
ошибку, но ведёт себя в соответствии с публикациями.
4. система не способна действовать в соответствии с исходным контрактом и
перечнем требований пользователя.
Это утверждение тоже не лишено недостатков, поскольку письменные требования
пользователя редко детализированы настолько, чтобы описывать желаемое поведение
программного обеспечения при всех мыслимых обстоятельствах.
1.1.2. «Окончательное» определение
В программном обеспечении имеется ошибка, если оно не выполняет того, что
пользователю разумно от него ожидать. Отказ программного обеспечения - это
проявление ошибки в нём.
1.2. Понятие надежности
Согласно известному определению, надёжность есть вероятность того, что при
функционировании системы в течение некоторого периода времени не будет
обнаружено ни единой ошибки.
Основной недостаток такого определения - это то, что в нем не учтено различие
между ошибками разных типов. Например, рассмотрим авиационную диспетчерскую
систему с двумя ошибками в программном обеспечении: из-за одной теряется след
самолёта, а другая состоит в том, что в сообщении оператору неправильно печатается
одно слово (например, трансаттлантический вместо трансатлантический).
По своим последствиям эти ошибки далеко не одинаковы, поэтому надёжность должна
быть определена как функция не только частоты ошибок, но и их серьёзности.
Следовательно:
Надёжность программного обеспечения есть вероятность его работы без отказов в
течение определённого периода времени, рассчитанная с учётом стоимости для
пользователя каждого отказа.
Таким образом, надёжность программного обеспечения является функцией
воздействия ошибок на пользователя системы; она не обязательно прямо связана с
оценкой "изнутри" программного обеспечения. Даже крупный просчёт в
проектировании может оказаться не слишком заметным для пользователя. С другой
стороны, как будто бы тривиальная ошибка может иметь катастрофические
последствия. Например, первый запуск космического корабля на Венеру потерпел
неудачу из-за того, что в операторе DO программы на Фортране была пропущена
запятая.
1.3. Методы оценки надежности
Рассмотрим возможные подходы к количественному измерению надежности.
1.3.1.
Расчет
величины
возможностью ошибок в ПО
риска,
вызванного
Во-первых, можно рассчитать величину риска, вызванного возможностью ошибок
в программе. При этом оценивается, к каким последствиям приведет применение ПО,
Учебно-исследовательская лаборатория "Информационные технологии"
5
Название документа
если в нем есть ошибки. Эти последствия могут быть выражены, например, в
экономических показателях. Какие потери мы понесем, если мы будем применять ПО в
соответствии с инструкциями, а в ПО содержатся ошибки? По сути, этот риск
определяется разделами инструкции, устанавливающими использование результатов
программы при данном режиме эксплуатации, и вероятностями ошибок, влияющими на
каждый тип использования. Такой риск может быть основан только на прогнозе
возможных ошибок, что значительно снижает ценность подобного подхода. В то же
время разумно оценить реальные потери за период эксплуатации, вызванные
ошибками. Если определить тенденцию изменения средних реальных потерь за
конкретный период (например, за месяц или год), можно прогнозировать
экономический риск на будущее.
1.3.2. Статистическая надежность
Часто говорят о статистической надежности программы, измеряемой как
дополнительная вероятность обнаружения новой ошибки, не учтенной в предыдущих
коррекциях, при очередном обращении к программе. Простейшей оценкой
статистической надежности является величина
P(n) = 1 - f(n)/n ± e(d,n)
или
P(n) > 1 - f(n)/n - e(d,n)
где п - количество выполненных обращений к программе;
f(n) - число обнаруженных ошибок;
e(d,n) - доверительный интервал хи-квадрат [5] оценки вероятности ошибки f(n)/n
при заданном уровне значимости.
В качестве оценки дисперсии d с гарантией можно пользоваться максимально
возможной дисперсией (= 1/4) двоичной случайной величины (в соответствии с двумя
возможными исходами обращения к кортежу: удача = 0, ошибка = 1).
Это соответствует подходу к программе как к черному ящику, иногда выдающему
ошибки. Недостатком такого подхода является неявно использованная модель "урны с
возвратом шаров", не учитывающая корректировки кортежа после обнаружения каждой
новой ошибки. Ситуация исправляется, если учитывать только новые ошибки, не
компенсируемые ранее сделанными корректировками инструкции.
1.3.3. Комбинаторная надежность
Надо отметить также не вполне конструктивный, но логически безупречный
подход к определению комбинаторной надежности программы, определяемой как
отношение числа вариантов исходных данных, на которых программа срабатывает
верно, к общему числу вариантов исходных данных. В условиях динамической
корректировки кортежа эта надежность постоянно растет. Однако оценить ее можно
только статистически, используя формулы, приведенные выше, для "препарированной"
статистической выборки результатов обращений к программе, из которой выброшены
повторные варианты исходных данных. В общем случае возникает та же трудность с
потерей стационарности процесса при корректировках. Но имеется одна ситуация, где
эта трудность не возникает: статистическая оценка комбинаторной надежности,
полученная на основе многократного тестирования программы, работающей
безошибочно на всей серии тестовых обращений. Это соответствует стадии
тестирования программы в процессе отладки, когда каждая обнаруженная ошибка
исправляется на уровне программы или инструкции, а потом тестирование начинается
заново по полной программе. В этом случае на каждом прогоне тестов корректировок
6
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
не возникает, и процесс возникновения ошибки остается стационарным. Оценка хиквадрат тогда дает Р(n) > 1 - e(1/4,n). Более тонкая оценка может быть основана на
знании внутренней структуры программы.
1.4. Причины ошибок в ПО
Основными причинами ошибок в программном обеспечении являются:
Большая сложность ПО, например, по сравнению с аппаратурой ЭВМ.
 Неправильный перевод информации из одного представления в другое на макрои микроуровнях. На макроуровне, уровне проекта, осуществляется передача и
преобразование различных видов информации между организациями,
подразделениями и конкретными исполнителями на всех этапах жизненного цикла
ПО. На микроуровне, уровне исполнителя, производится преобразование
информации по схеме: получить информацию - запомнить - выбрать из памяти
(вспомнить) - воспроизвести информацию (передать).

1.5. Источники ошибок в ПО
Источниками ошибок (угрозами надежности) в программном обеспечении
являются:
 Внутренние:
ошибки проектирования, ошибки алгоритмизации, ошибки
программирования, недостаточное качество средств защиты, ошибки в
документации.
 Внешние: ошибки пользователей, сбои и отказы аппаратуры ЭВМ, искажение
информации в каналах связи, изменения конфигурации системы.
1.6. Методы проектирования надежного
программного обеспечения
Методы проектирования надежного программного обеспечения можно разбить на
следующие группы:
 Предупреждение ошибок, методы позволяющие минимизировать или исключить
появление ошибки.
 Обнаружение ошибок, методы направленные на разработку дополнительных
функций программного обеспечения, помогающих выявить ошибки.
 Устойчивость к ошибкам, дополнительные функции программного обеспечения,
предназначенные для исправления ошибок и их последствий и обеспечивающие
функционирование системы при наличии ошибок.
1.6.1. Предупреждение ошибок
Методы предупреждения ошибок концентрируются на отдельных этапах процесса
проектирования программного обеспечения и включают в себя:

Методы, позволяющие справиться со сложностью системы.

Методы достижения большей точности при переводе информации.

Методы улучшения обмена информацией.
Учебно-исследовательская лаборатория "Информационные технологии"
7
Название документа
Методы немедленного обнаружения и устранения ошибок на каждом
шаге (этапе) проектирования, не откладывая их на этап тестирования
программы.
Сложность системы является одной из главных причин низкой надежности
программного обеспечения. В общем случае, сложность объекта является функцией
взаимодействия (количества связей) между его компонентами. В борьбе со сложностью
ПО используются две концепции:


Иерархическая структура. Иерархия позволяет разбить систему по
уровням понимания (абстракции, управления). Концепция уровней
позволяет анализировать систему, скрывая несущественные для данного
уровня детали реализации других уровней. Иерархия позволяет
понимать, проектировать и описывать сложные системы.
Независимость. В соответствии с этой концепцией, для минимизации
сложности, необходимо максимально усилить независимость элементов
системы.
Это означает такую декомпозицию системы, чтобы её высокочастотная динамика
была заключена в отдельных компонентах, а межкомпонентные взаимодействия (связи)
описывали только низкочастотную динамику системы. Методы обнаружения ошибок
базируются на введении в программное обеспечение системы различных видов
избыточности:


Временная избыточность. Использование части производительности
ЭВМ для контроля исполнения и восстановления работоспособности ПО
после сбоя.

Информационная
избыточность.
Дублирование
части
данных
информационной системы для обеспечения надёжности и контроля
достоверности данных.

Программная избыточность включает в себя: взаимное недоверие компоненты системы проектируются, исходя из предположения, что
другие компоненты и исходные данные содержат ошибки, и должны
пытаться их обнаружить; немедленное обнаружение и регистрацию
ошибок; выполнение одинаковых функций разными модулями системы
и сопоставление результатов обработки; контроль и восстановление
данных с использованием других видов избыточности.
1.6.2. Обеспечение устойчивости к ошибкам
Методы обеспечения устойчивости к ошибкам направлены на минимизацию
ущерба, вызванного появлением ошибок, и включают в себя:
8

обработку сбоев аппаратуры;

повторное выполнение операций;

динамическое изменение конфигурации;

сокращенное обслуживание в случае отказа отдельных функций
системы;

копирование и восстановление данных;
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа

изоляцию ошибок.
1.6.3. Обнаружение ошибок
Важным этапом жизненного цикла программного обеспечения, определяющим
качество и надёжность системы, является тестирование.
Учебно-исследовательская лаборатория "Информационные технологии"
9
Название документа
2. Тестирование ПО
2.1. Понятие тестирования
Долгое время было принято считать, что целью тестирования является
доказательство отсутствия ошибок в программе. Однако этот тезис не выдерживает
критики, т.к. полный перебор всех возможных вариантов выполнения программы
находится за пределами вычислительных возможностей даже для очень небольших
программ. Поэтому никакое тестирование не может гарантировать отсутствия ошибок.
Афористически это сформулировано в известной "аксиоме Шуры-Буры": "В
каждой программе есть ошибки. Если в программе нет ошибок, то они есть в
алгоритме. Если же ошибок нет ни там, ни там, то такая программа никому не нужна".
Поэтому со временем понимание целей тестирования изменилось. Сегодня
общепринятым определением тестирования считается следующее определение, данное
Гленфордом Майерсом: "Тестирование - это процесс выполнения программ с целью
обнаружения ошибок".
Определение Г. Майерса указывает на объективную трудность тестирования: это
деструктивный (т.е. обратный созидательному) процесс. Поскольку программирование
- процесс конструктивный, ясно, что большинству разработчиков программных средств
сложно “переключиться” при тестировании созданной ими продукции.
Сейчас существует множество методик эффективной проверки программ не только
путем запуска, но и путем чтения, статических проверок и т.п. Поэтому классическое
определение Майерса, приведенное выше, оказывается слишком узким и не
охватывающим всех аспектов современного тестирования. В связи с этим мы будем
пользоваться другим определением тестирования:
Тестирование - это любая деятельность, направленная на обнаружение ошибок в
программном продукте.
2.2. Принципы тестирования
1.
2.
3.
4.
5.
10
У Майерса сформулированы также основные принципы организации тестирования:
необходимой частью каждого теста должно являться описание ожидаемых
результатов работы программы, чтобы можно было быстро выяснить наличие или
отсутствие ошибки в ней;
следует по возможности избегать тестирования программы ее автором, т.к. кроме
уже указанной объективной сложности тестирования для программистов здесь
присутствует и тот фактор, что обнаружение недостатков в своей деятельности
противоречит человеческой психологии (однако отладка программы эффективнее
всего выполняется именно автором программы);
по тем же соображениям организация - разработчик программного обеспечения не
должна “единолично ” его тестировать (должны существовать организации,
специализирующиеся на тестировании программных средств);
должны являться правилом доскональное изучение результатов каждого теста,
чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе;
необходимо тщательно подбирать тест не только для правильных
(предусмотренных) входных данных, но и для неправильных (непредусмотренных);
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
6. при анализе результатов каждого теста необходимо проверять, не делает ли
программа того, что она не должна делать;
7. следует сохранять использованные тесты (для повышения эффективности
повторного тестирования программы после ее модификации или установки у
заказчика);
8) тестирование не должно планироваться исходя из предположения, что в
программе не будут обнаружены ошибки (в частности, следует выделять для
тестирования достаточные временные и материальные ресурсы);
8. следует учитывать так называемый “принцип скопления ошибок”: вероятность
наличия не обнаруженных ошибок в некоторой части программы прямо
пропорциональна числу ошибок, уже обнаруженных в этой части;
9. следует всегда помнить, что тестирование - творческий процесс, а не относиться к
нему как к рутинному занятию.
2.3. Порядок процесса тестирования
Процесс тестирования проходит следующие стадии:
Постановка задачи для теста
 Проектирование тестов
 Написание тестов
 Тестирование тестов
 Выполнение тестов
 Обработка результатов тестирования

2.4. Стратегии проектирования тестов
Успех отладки в значительной степени предопределяет рациональная организация
тестирования. При отладке отыскиваются и устраняются, в основном, те ошибки,
наличие которых в программе устанавливается при тестировании. Как было уже
отмечено, тестирование не может доказать правильность программного средства, в
лучшем случае оно может продемонстрировать наличие в нем ошибки. Другими
словами, нельзя гарантировать, что тестированием программы практически
выполнимым набором тестов можно установить наличие каждой имеющейся в ней
ошибки. Поэтому возникает две задачи. Первая: подготовить такой набор тестов и
применить их к программе, чтобы обнаружить в ней по возможности большее число
ошибок. Однако чем дольше продолжается процесс тестирования (и отладки в целом),
тем большей становится стоимость программного средства. Отсюда вторая задача:
определить момент окончания отладки. Признаком возможности окончания отладки
является полнота охвата пропущенными через программное средство тестами
множества различных ситуаций, возникающих при выполнении, и относительно редкое
проявление ошибок на последнем отрезке процесса тестирования. Для оптимизации
набора тестов, т.е. для подготовки такого набора тестов, который позволял бы при
заданном их числе (или при заданном интервале времени, отведенном на тестирование)
обнаруживать большее число ошибок, необходимо, во-первых, заранее планировать
этот набор и, во-вторых, использовать рациональную стратегию проектирования
тестов. Возможны разные подходы к выработке стратегии проектирования тестов,
которые можно условно графически разместить (см. рис. 1) между следующими двумя
крайними подходами.
Учебно-исследовательская лаборатория "Информационные технологии"
11
Название документа
Рисунок 1. Спектр подходов к проектированию тестов.
Левый крайний подход заключается в том, что тесты проектируются только на
основании изучения спецификаций (принцип черного ящика). Такой подход до сих пор
является самым распространенным в повседневной практике, но у него есть целый ряд
недостатков.
Фактически такой подход требует полного перебора всех наборов входных данных,
так как при использовании в качестве тестов только части этих наборов некоторые
участки программ могут не работать ни на каком тесте и, значит, содержащиеся в них
ошибки не будут проявляться. Однако тестирование программных средств полным
множеством наборов входных данных практически неосуществимо.
Во-вторых, таким способом невозможно найти взаимно уничтожающихся ошибок.
В-третьих, некоторые ошибки возникают достаточно редко (ошибки работы с
памятью), и потому их трудно найти и воспроизвести.
Правый крайний подход заключается в том, что тесты проектируются на
основании изучения текстов программ с целью протестировать все пути выполнения
каждой подпрограммы (принцип белого ящика). Если принять во внимание наличие в
программах циклов с переменным числом повторений, то различных путей выполнения
программ может оказаться также чрезвычайно много, так что их тестирование также
будет практически неосуществимо.
Оптимальная стратегия проектирования тестов расположена внутри интервала
между этими крайними подходами, смещаясь в ту или иную сторону в зависимости от
функций, выполняемых конкретным модулем, комплексом или подсистемой, но ближе
к левому краю (см. рисунок 1).
Она включает проектирование значительной части тестов по спецификациям,
исходя из принципов:
 на каждую используемую функцию или возможность - хотя бы один тест;
 на каждую область и на каждую границу изменения какой-либо входной величины хотя бы один тест;
 на каждый особый случай или на каждую исключительную ситуацию, указанную в
спецификациях, - хотя бы один тест.
Но она требует также проектирования некоторых тестов и по текстам программ,
исходя из принципа (как минимум): каждая команда каждой программы должна
проработать хотя бы на одном тесте.
2.4.1. Тестирование программы как «черного ящика»
Такое тестирование, при котором программа рассматривается как “черный ящик”
(то есть ее текст не используется), называется еще функциональным тестированием.
При этом происходит проверка соответствия поведения программы ее внешней
спецификации.
12
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
2.4.1.1. Метод эквивалентного разбиения
Т.к. нашей целью является построения множества тестов, характеризующегося
наивысшей вероятностью обнаружения большинства ошибок в тестируемой
программе, то тест из этого множества должен:
1) уменьшать (более чем на единицу) число других тестов, которые должны быть
разработаны для достижения заранее поставленной цели “удовлетворительного”
тестирования;
2) покрывать собой значительную часть других возможных тестов.
Другими словами:
1) каждый тест должен заключать в себе проверку наибольшего числа задаваемых
внешней спецификацией входных условий (ограничений на входные данные)
для того, чтобы минимизировать общее число необходимых тестов;
2) необходимо разбить область значений входных данных на конечное число
подобластей (которые будут называться классами эквивалентности), чтобы
можно было полагать каждый тест, являющийся представителем некоторого
класса, эквивалентным любому другому тесту этого класса (т.е.
обнаруживающим одни и те же ошибки). В общем случае использование
термина “класс эквивалентности” является здесь не вполне точным, т.к.
выделенные подобласти могут пересекаться.
Проектирование тестов по методу эквивалентного разбиения проводится в два
этапа:
 выделение по внешним спецификациям классов эквивалентности;
 построение множества тестов.
На первом этапе происходит выбор из спецификации каждого входного условия и
разбиение его на две или более группы, соответствующие так называемым
“правильным” (ПКЭ) и “неправильным” классам эквивалентности (НКЭ), т.е. областям
допустимых для программы и недопустимых значений входных данных.
Этот процесс зависит от вида входного условия.
Если входное условие описывает область (например, х <=0.5) или количество
(например, размер массива А равен 50) допустимых значений входных данных, то
определяются один ПКЭ (х <=0.5 или размер А равен 50) и два НКЭ (х< -0.5; х>0.5 или
размер А меньше 50; размер А больше 50).
Если входное условие описывает дискретное множество допустимых значений
входных данных (например, В может равно -1, 0 или 1), то определяются ПКЭ для
каждого значения из множества (в данном примере 3) и один НКЭ (В<>-1 & В<>0 &
В<>1).
Если входное условие описывает ситуацию “должно быть” (например, N>0), то
определяются один ПКЭ (N>0) и один НКЭ (N<=0).
На втором этапе метода эквивалентного разбиения выделенные классы
эквивалентности используются для построения тестов:
 каждому классу присваивается свой номер;
 проектируются тесты для ПКЭ таким образом, что каждый тест покрывает как
можно больше еще не покрытых ПКЭ, до тех пор, пока все ПКЭ не будут
покрыты;
 проектируются тесты для НКЭ таким образом, что каждый тест покрывает
один и только один НКЭ, до тех пор, пока все НКЭ не будут покрыты.
Нарушение третьего условия приводит к тому, что некоторые тесты с
недопустимыми значениями входных данных проверяют только одну ошибку и
скрывают реакцию программы на другие ошибки.
Учебно-исследовательская лаборатория "Информационные технологии"
13
Название документа
Метод эквивалентного разбиения значительно лучше случайного подбора тестов,
но имеет свои недостатки. Основной из них - пропуск определенных типов
высокоэффективных тестов (т.е. тестов, характеризующихся большой вероятностью
обнаружения ошибок). От этого недостатка во многом свободен метод анализа
граничных условий.
2.4.1.2. Метод анализа граничных условий
Под граничными условиями понимают ситуации, возникающие непосредственно
на границе определенного в спецификации входного или выходного условия, выше или
ниже ее. Метод анализа граничных условий отличается от метода эквивалентного
разбиения следующим:
 выбор любого представителя класса эквивалентности осуществляется таким
образом, чтобы проверить тестом каждую границу этого класса;
 при построении тестов рассматриваются не только входные условия, но и
выходные (т.е. определенные во внешней спецификации ограничения на
значения входных данных).
Общие правила метода анализа граничных условий:
1) построить тесты для границ области допустимых значений входных данных и
тесты с недопустимыми значениями, соответствующими незначительному
выходу за границы этой области (например, для области [-1.0; 1.0] строим тесты
-1.0; 1.0; -1.001; 1.001);
2) построить тесты для минимального и максимального значений входных
условий, определяющих дискретное множество допустимых значений входных
данных, и тесты для значений, больших или меньших этих величин (например,
если входной файл может содержать от 1 до 255 записей, то выбираются тесты
для пустого файла, содержащего 1, 255 и 256 записей);
3) использовать правило 1 для каждого выходного условия (например, программа
вычисляет ежемесячный расход частного лица или небольшого предприятия,
минимум которого 0.00$, а максимум 1165.50$; тогда необходимо построить
тесты, вызывающие отрицательный расход, расходы, равные 0.00$ и 1165.50$, и
расход, больший 1165.50$);
4) использовать правило 2 для каждого выходного условия (например, программа
ищет и отображает на экране дисплея наиболее подходящие, в зависимости от
входного условия, рефераты статей, но не более четырех; тогда необходимо
построить тесты, приводящие к отображению 0, 1, 4 рефератов и попытки
ошибочного отображения 5 рефератов);
5) если входные и выходные данные программы представляют собой
упорядоченное множество (последовательный файл, линейный список, таблицу),
то пре тестировании сосредоточить внимание на первом и последнем элементе
множества;
6) попытаться найти и проверить тестами другие граничные условия.
Важность проверки границ выходных условий объясняется тем, что не всегда
граничным значениям входных данных соответствуют граничные значения
результатов работы программ.
Для иллюстрации необходимости анализа граничных условий приведем
тривиальный пример. Пусть имеется программа, осуществляющая ввод трех чисел,
интерпретирующая их как длины сторон треугольника и выводящая сообщение о типе
треугольника (“разносторонний”, “равнобедренный” или “равносторонний”). Допустим
также, что в программе содержится ошибка: при проверке условия построения
треугольника (сумма длин любых двух сторон должна быть больше третьей)
используется операция отношения >= вместо >. При проектировании тестов по методу
14
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
эквивалентного разбиения будут построены тесты для случаев возможности
построения треугольника (например, 3, 4, 5) и невозможности его построения
(например, 1, 2, 4), т.е. ошибка в программе не будет обнаружена (на входные данные
1, 2, 3 будет выведено сообщение “разносторонний треугольник”). Но подобный тест
будет получен при использовании метода анализа граничных условий.
Анализ граничных условий - один из наиболее полезных методов проектирования
тестов. Но он часто оказывается неэффективным из-за того, что граничные условия
иногда едва уловимы, а их выявление весьма трудно.
2.4.2. Тестирование программы как «белого ящика»
Тестирование, когда программа рассматривается как “белый ящик” (т.е. ее текст
открыт для пользования), называется также структурным. Происходит проверка
логики программы. Полным тестированием в этом случае будет такое, которое
приведет к перебору всех возможных путей на графе передач управления программы
(ее управляющем графе). Даже для средних по сложности программ числом таких
путей может достигать десятков тысяч. Если ограничиться перебором только линейно
независимых путей, то и в этом случае исчерпывающее структурное тестирование
практически невозможно, т. к. неясно, как подбирать тесты, чтобы обеспечить
“покрытие” всех таких путей. Поэтому при структурном тестировании необходимо
использовать другие критерии его полноты, позволяющие достаточно просто
контролировать их выполнение, но не дающие гарантии полной проверки логики
программы.
Но даже если предположить, что удалось достичь полного структурного тестирования
некоторой программы, в ней, тем не менее, могут содержаться ошибки, т.к.
1) программа может не соответствовать своей внешней спецификации, что в
частности, может привести к тому, что в ее управляющем графе окажутся
пропущенными некоторые необходимые пути;
2) не будут обнаружены ошибки, появление которых зависит от обрабатываемых
данных (т.е. на одних исходных данных программа работает правильно, а на
других - с ошибкой).
2.4.2.1. Критерии покрытия логики программы
Как говорилось выше, исчерпывающее структурное тестирование невозможно.
Поэтому необходимо выбрать такие критерии его полноты, которые допускали бы их
простую проверку и облегчали бы целенаправленный подбор тестов.
Наиболее слабым из критериев полноты структурного тестирования является
требование хотя бы однократного выполнения (покрытия) каждого оператора
программы.
Более сильным критерием является так называемый критерий С1: каждая ветвь
алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз. Для
большинства языков программирования покрытие переходов обеспечивает и покрытие
операторов, но, например, для программ на языке ПЛ/1 дополнительно к покрытию
всех ветвей требуется покрытие всех дополнительных точек входа в процедуру
(задаваемых операторами ENTRY) и всех ON - единиц.
Использование критерия покрытия условий может вызвать подбор тестов,
обеспечивающих переход в программе, который пропускается при использовании
критерия С1 (например, в программе на языке Паскаль, использующей конструкцию
цикла WHILE х AND y DO..., применение критерия покрытия условий требует
проверки обоих вариантов выхода из цикла: NOT x и NOT y).
Практически единственным средством, предоставляемым современными системами
Учебно-исследовательская лаборатория "Информационные технологии"
15
Название документа
программирования, является возможность определения частоты выполнения различных
операторов программы (ее профилизации). Но с помощью этого инструмента
поддержки тестирования можно проверить выполнение только слабейшего из
критериев полноты - покрытие всех операторов. Правда, с помощью этого же
инструмента можно проверить и выполнение критерия С1. Но для этого
предварительно текст программы должен быть преобразован таким образом, чтобы все
конструкции условного выбора (IF и CASE или SWITCH) содержали ветви ELSE или
DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма, не выполнявшиеся на
данном тесте, будут “видимы” из таблицы частоты выполнения операторов
преобразованной программы.
Актуальной остается задача создания инструментальных средств, позволяющих:
1) накапливать информации о покрытых и непокрытых ветвях для всех
использованных тестов;
2) выделять разработчику еще не покрытые при тестировании участки программы,
облегчая выбор следующих тестов;
3) поддерживать более мощные критерии полноты структурного тестирования.
2.5. Этапы тестирования
В тестировании многомодульных программных комплексов можно выделить
четыре этапа:
1) тестирование отдельных модулей (т.е. контроль отдельного программного
модуля отдельно от других модулей системы);
2) совместное тестирование модулей (т.е. контроль сопряжений (связей) между
частями системы: модулями, компонентами, подсистемами);
3) тестирование функций программного комплекса (т.е. поиск различий между
разработанной программой и ее внешней спецификацией);
4) тестирование всего комплекса в целом (т.е. поиск несоответствия созданного
программного продукта сформулированным ранее целям проектирования,
отраженным обычно в техническом задании).
Тестирование
отдельных
модулей
Совместное
тестирование
модулей
Тестирование
функций
Комплексное
тестирование
Рисунок 2. Этапы тестирования
16
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
2.6. Два подхода к тестированию модулей
Известны два подхода к совместному тестированию модулей: пошаговое и
монолитное тестирование.
При монолитном тестировании сначала по отдельности тестируются все модули
программного комплекса, а затем все они объединяются в рабочую программу для
комплексного тестирования.
При пошаговом тестировании каждый модуль для своего тестирования
подключается
к
набору
уже
проверенных
модулей.
В первом случае для автономного тестирования каждого модуля требуется модуль драйвер (то есть вспомогательный модуль, имитирующий вызов тестируемого модуля)
и один или несколько модулей - заглушек (то есть вспомогательных модулей,
имитирующих работу модулей, вызываемых из тестируемого). При пошаговом
тестировании модули проверяются не изолированно друг от друга, поэтому требуются
либо только драйверы, либо только заглушки.
При сравнении пошагового и монолитного тестирования можно отметить
следующие преимущества первого подхода:
1) меньшая трудоемкость;
2) более раннее обнаружение ошибок в интерфейсах между модулями (их сборка
начинается раньше, чем при монолитном тестировании);
3) легче отладка, то есть локализация ошибок (они в основном связаны с
последним из подключенных модулей);
4) более совершенны результаты тестирования (более тщательная проверка
совместного использования модулей.
Есть преимущества и у монолитного тестирования:
1) меньше расход машинного времени (хотя из-за большей сложности отладки
может потребоваться дополнительная проверка программы и это
преимущество будет сведено на нет);
2) предоставляется больше возможностей для организации параллельной работы
на начальном этапе тестирования.
В целом более целесообразным является выбор пошагового тестирования.
2.6.1. Восходящее и нисходящее тестирование
При использовании пошагового тестирования возможны две стратегии
подключения модулей: нисходящая и восходящая.
Нисходящее тестирование начинается с главного (или верхнего) модуля
программы, а выбор следующего подключаемого модуля происходит из числа модулей,
вызываемых из уже протестированных. Одна из основных проблем, возникающих при
нисходящем тестировании, - создание заглушек. Это тривиальная задача, т. к., как
правило, недостаточно, чтобы в заглушке выполнялся вывод соответствующего
информационного сообщения и возврат всегда одних и тех же значений выходных
данных.
Другая проблема, которую необходимо решать при нисходящем тестировании, форма представления тестов в программе, так как, как правило, главный модуль
получает входные данные не непосредственно, а через специальные модули ввода,
которые при тестировании в начале заменяются заглушками. Для передачи в главный
модуль разных тестов нужно или иметь несколько разных заглушек, или записать эти
тесты в файл во внешней памяти и с помощью заглушки считывать их.
Поскольку после тестирования главного модуля процесс проверки может
продолжаться по-разному, следует придерживаться следующих правил:
Учебно-исследовательская лаборатория "Информационные технологии"
17
Название документа
а) модули, содержащие операции ввода-вывода, должны подключаться к
тестированию как можно раньше;
б) критические (т.е. наиболее важные) для программы в целом модули также
должны тестироваться в первую очередь.
Достоинства нисходящего тестирования:
1) уже на ранней стадии тестирования есть возможность получить работающий
вариант разрабатываемой программы;
2) быстро могут быть выявлены ошибки, связанные с организацией
взаимодействие с пользователем.
Проблемы, которые могут возникать при нисходящем тестировании:
1) появляется
соблазн
совмещения
нисходящего
проектирования
с
тестированием, что, как правило, неразумно, т.к. проектирование - процесс
итеративный и в нем неизбежен возврат на верхние уровни и исправление
принятых ранее решений, что обесценивает результаты уже проведенного
тестирования;
2) может возникнуть желание перейти к тестированию модуля следующего
уровня до завершения тестирования предыдущего по объективным причинам
(необходимости создания нескольких версий заглушек, использования
модулями верхнего уровня ресурсов модулей нижних уровней).
При восходящем тестировании проверка программы начинается с
терминальных модулей (т.е. тех, которые не вызывают не каких других модулей
программы). Эта стратегия во многом противоположна нисходящему тестированию (в
частности, преимущества становятся недостатками и наоборот).
Нет проблемы выбора следующего подключаемого модуля - учитывается лишь то,
чтобы он вызывал только уже протестированные модули. В отличие от заглушек
драйверы не должны иметь несколько версий, поэтому их разработка в большинстве
случаев проще (кроме того, использование средств автоматизации и отладки облегчает
создание как раз драйверов, а не заглушек).
Другие достоинства восходящего тестирования:
1) поскольку нет промежуточных модулей (тестируемый модуль является для
рабочего варианта программы модулем самого верхнего уровня), нет проблем,
связанных с возможностью или трудностью задания тестов;
2) нет возможности совмещения проектирования с тестированием;
3) нет трудностей, вызывающих желание перейти к тестированию следующего
модуля, не завершив проверки предыдущего.
Основными недостатком восходящего тестирования является то, что проверка всей
структуры разрабатываемого программного комплекса возможна только на
завершающей стадии тестирования.
Хотя однозначного вывода о преимущества той или иной стратегии пошагового
тестирования сделать нельзя (нужно учитывать конкретные характеристики
тестируемой программы), в большинстве случаев более предпочтительным является
восходящее тестирование.
2.7. Alpha- и beta- тестирование
Alpha-тестирование проводится командой разработчиков программного средства
для того, чтобы подтвердить, что данный программный продукт работает. Изначально,
период alpha-тестирования означал первую стадию тестирования в процессе разработки
программы. Эта первая стадия включает тестирование модулей и компонент, а также
тестирование системы в целом.
18
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
Процесс beta-тестирования – вторая стадия тестирования, во время которой
программную систему испытывают пользователи. Чаще всего, это тестирование перед
выпуском релиза. Beta-версии программного обеспечения распространяются для того,
чтобы обеспечить программе тестирование в условиях реального мира и, частично, для
того, чтобы показать возможности программы до выпуска релиза.
2.8. Практическое тестирование
Если бы перед вами была поставлена задача исследовать текущий процесс
разработки программного обеспечения с целью найти способы повышения
эффективности тестирования, то какая часть процесса в первую очередь привлекла бы
ваше внимание? Начнете ли вы эти исследования с анализа того, как планируется
выполнять тестирование? С анализа средств и методов автоматизации разработки
программного обеспечения? Что можно сказать об используемой вами системе
отслеживания дефектов?
Попробуем исследовать каждую фазу процесса разработки программного
обеспечения с позиций специалиста по тестированию.
При этом под статическим тестированием (static testing) будем
понимать тестовую деятельность, связанную с анализом разработки программного
обеспечения. Статическое тестирование предусматривает проверку программных
кодов, сквозной контроль и проверку программы без запуска на машине, т.е. проверку
за столом.
Тестовую деятельность, предусматривающую эксплуатацию программного
продукта будем называть динамическим тестированием (dynamic testing).
2.8.1. Процесс разработки ПО
Тесты - разновидность программ, и для их разработки можно определить
последовательность шагов, аналогичную последовательности шагов разработки
программ вообще.
Разработка программного продукта называется жизненным
циклом
программного продукта (software life cycle). Жизненный цикл
программного продукта может быть описан разными способами.
Одной из первых была использована каскадная (или водопадная) модель
жизненного цикла программного продукта, показанная на рисунке 3. Основное
свойство каскадной модели заключается в том, что каждая стадия или
компонент модели завершается перед началом следующей стадии. Процесс
начиняется с определения требований к системе. В каскадной модели эти
требования выявляются, анализируются и записываются в специальные
документы еще до того, как начнутся работы по проектированию.
Проектирование системы, проектирование программ, кодирование и различные
виды тестирования суть самодостаточные и тщательно документированные
стадии процесса. Следует, однако, заметить, что обычно некоторые стадии выступают под различными именами; например, стадия системного
проектирования часто называется "проектным заданием" иди "эскизным
проектом", в то время на как стадию разработки программы зачастую
ссылаются как на "рабочий план".
Учебно-исследовательская лаборатория "Информационные технологии"
19
Название документа
У каскадной модели имеются свои критики. Один из аргументов, к которым
они прибегают, касается возможности фиксации всех требований на начальной
стадии проекта. Предположим, что вас попросили высказать все свои требования к
новому автомобилю до того, как он будет спроектирован и построен. Как
заказчику, вам будет трудно сформулировать эти требования с той степенью
детализации, которая необходима для проектирования и построения автомобиля "с
нуля". Именно такие запросы предъявляет каскадная модель к заказчику и
программисту-аналитику на начальном этапе каскадного процесса.
Есть мнение, что главным недостатком каскадной модели является то, что она
не трактует программное обеспечение как процесс решения задачи. Каскадная
модель заимствована из области разработки аппаратных средств. Она отображает
конвейерный принцип разработки программного обеспечения, по условиям
которого компонент сначала разрабатывается, а затем многократно тиражируется.
Однако создание программного обеспечения - это, прежде всего, творческий, а отнюдь не производственный процесс. Становление программного обеспечения происходит по спирали по мере того, как растет понимание задачи. В рамках данного
процесса происходят неоднократные продвижения вперед и возвраты обратно, при
этом пробуются различные варианты с целью выбора из них наилучшего. Другими
словами, невозможно построить точную модель процесса разработки
программного продукта в виде некоторого набора автономных стадий, а именно
это и предполагает каскадная модель.
Требования
Проектирование
системы
Проектирование
программ
Тестирование
программных
кодов и модулей
Проверка
взаимодействия и
функционирования
компонентов
системы
Тестирование
системы
Приемочные
испытания
Эксплуатация и
сопровождение
Рисунок 3. Каскадная модель жизненного цикла
20
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
Другие
модели,
в
частности,
спираль,
поэтапная
передача,
эволюционирующая прототипная модель, гораздо лучше отражают итеративный
характер разработки программного обеспечения.
В условиях каскадных моделей разработки, если не предпринять специальных
предосторожностей, все ошибки, допущенные при формулировании требований,
при проектировании системы и при написании программных кодов перетекают в
организацию тестов. В случае применения каскадной модели тестовая группа
может обнаружить массу ошибок перед самым окончанием разработок – ошибок,
возникновение которых прослеживается вплоть до стадий формулирования
требований, проектирования или кодирования программного продукта. Возврат к
началу каскадного процесса разработки сопряжен с существенными трудностями
и большими затратами времени и средств, поскольку все рабочие продукты,
которые якобы уже прошли завершающие стадии, должны подвергнуться
повторной проверке.
Несмотря на все порождаемые проблемы, каскадная модель достойна того,
чтобы ее изучить, поскольку она содержит основные компоненты, необходимые
для разработки программных продуктов. Независимо от используемой модели,
разработка программного обеспечения должна начинаться с понимания того, что
нужно построить, другими словами, с выявления и анализа требований. Процесс
разработки должен включать проектирование, кодирование и тестирование,
невзирая на то, выполняются ли они в виде линейной последовательности, что
характерно для каскадной модели, или в рамках итеративной последовательности,
характерной для моделей эволюционного прототипирования и поэтапной
передачи. Мы используем каскадную модель в качестве контекста для
обсуждения, как добиться улучшения процесса, однако базовые принципы
быстрого тестирования должны применяться независимо от выбранной модели
жизненного цикла.
2.8.2. Каскадный процесс тестирования
В традиционной каскадной модели (см. рисунок 3) роль организации тестов
остается неясной до стадий системного тестирования и приемочных испытаний.
Большая часть видов деятельности, характерных для ранних стадий, таких как
проектирование, кодирование и модульное тестирование, в первую очередь связано
с коллективом разработчиков программного обеспечения. По этой причине имеет
смысл построить соответствующую модель жизненного цикла процесса
тестирования. Из того, что разработка динамических тестов является процессом, во
многом совпадающим с процессом разработки программного обеспечения, следует,
что каскадная модель жизненного цикла динамического тестирования довольно
сильно похожа на модель, которая обсуждалась в предыдущем разделе. Пример
каскадной модели жизненного цикла процесса тестирования приводится на рис. 4.
Обратите внимание на тот факт, что данная модель описывает динамическое
тестирование, однако в ней не отражено статическое тестирование.
Далее рассмотрим каждую стадию каскадного процесса тестирования.
Учебно-исследовательская лаборатория "Информационные технологии"
21
Название документа
Анализ
требований
Планирование
испытаний
Проектирование
тестов
Реализация
тестов
Отладка
тестов
Системное
тестирование
Приемочные
испытания
Эксплуатация и
сопровождение
Рисунок 4. Каскадный процесс тестирования
2.8.3. Анализ требований
На этапе анализа требований цели, которые преследует группа специалистов
по тестированию и коллектив разработчиков, различаются в ряде аспектов. Обоим
коллективам нужны четкие, недвусмысленные спецификации требований, которые
служат входными данными для их работы. Разработчики желают получить полный
набор требований, которыми можно воспользоваться для формулирования
функциональных требований к системе и которые позволили бы проводить работы
по проектированию и кодированию программного продукта. С другой стороны,
тестовой группе нужен набор требований, который позволил бы им составить план
проведения испытаний и выполнить системные и приемочные испытания.
Готовая формальная спецификация требований должна быть подвергнута
статическому тестированию.
Критерии, используемые при тестировании требований:
1. Полнота. Набор требований считается полным, если все его составные части
представлены и каждая такая часть выполнена в полном объеме. При тестировании
набора требований на полноту необходимо обратить особое внимание на следующие
моменты:
• Требования не должны содержать выражений типа "подлежит определению", "и
так далее", "и прочие" и им подобных.
22
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
• Требования не должны ссылаться на несуществующую справочную информацию,
такую как, например, несуществующая спецификация.
• Требование не должно ссылаться на функциональные средства, которые еще не
определены.
2. Однозначность. Каждое требование должно быть точно и ясно сформулировано;
оно должно допускать единственное толкование. Требование должно быть
удобочитаемым и понятным. Если требование отличается особой сложностью, для
облегчения понимания, может быть привлечен вспомогательный материал, такой как,
диаграммы или таблицы. Если для пущей убедительности используются выражения
наподобие "это очевидно" или "само собой разумеется", то вполне возможно, что автор
пытается отвлечь ваше внимание от того или иного двусмысленного утверждения.
3. Непротиворечивость. Требования не должны противоречить друг другу или
действующим стандартам. Если требования конфликтуют друг с другом, то нужно
вводить приоритеты с целью разрешения таких конфликтов. Умение обнаруживать
дефекты, обусловленные противоречиями требований, предполагает хорошее знание
всего документа, содержащего требования, и знакомство с существующими
стандартами или другими внешними техническими условиями.
4. Прослеживаемость. Каждое требование должно иметь уникальный
идентификатор, который позволяет прослеживать его разработку на протяжении всего
жизненного цикла. В рабочих продуктах, которые появляются на более поздних этапах
жизненного цикла, таких как план тестирования, каждая ссылка на свойство системы
должна прослеживаться до определения и спецификации требований.
5. Осуществимость. Каждое требование должно ставить перед системой задачу
обеспечить такие средства, которые целесообразно разрабатывать и поддерживать.
Если заказчик предъявляет к системе нереальные требования в смысле затрат времени
и средств на разработку тех или иных функций либо же требует разработки функций,
которые окажутся ненадежными и опасными в эксплуатации, необходимо определить
риски и принять соответствующие меры. По сути дела, разрабатываемая система
должна быть экономически осуществимой, надежной, удобной в эксплуатации и
сопровождении.
6. Контролепригодность. Мы должны уметь разрабатывать экономически
обоснованные и удобные для использования тесты для каждого требования с целью
продемонстрировать, что тестируемый программный продукт обладает необходимыми
функциональными возможностями, рабочими характеристиками и соответствует
действующим стандартам. Это означает, что каждое требование должно быть
измеряемым или поддаваться количественному определению и что тестирование
должно выполняться в приемлемых условиях.
2.8.4. Планирование испытаний
Под планированием испытаний понимается определение объемов испытаний, подходок, ресурсов и расписания выполнения намеченных действий. Для того чтобы
тестирование было эффективным, необходимо потратить значительные средства и
усилия па планирование, а также быть готовым пересматривать этот план в динамике,
соответственно изменениям и требованиях, расчетах или программных кодах по мере
выявления дефектов. Очень важно, чтобы асе требования подверглись тестированию,
либо лее, если требования выстроены по некоторой системе приоритетов, по крайней
мере, должны быть проверены требования с максимальными приоритетами. Матрица
прослеживаемости требований является полезным инструментальным средством на
Учебно-исследовательская лаборатория "Информационные технологии"
23
Название документа
стадии планирования испытаний, поскольку она может использоваться при расчете
объемов тестирования, необходимого для охвата важнейших, требований.
В идеальном случае планирование испытаний должно принимать в расчет как
статическое, так и динамическое тестирование, но поскольку процесс тестирования,
отраженный на рис. 4, отдает предпочтение динамическому тестированию, временно
оставим статическое тестирование в покое. Действия, выполняемые на стадии
планирования испытаний, представляют собой подготовительные этапы для этапов
системных и приемочных испытаний, которые расположены ближе к концу каскада, и
должны включать:
• Определение того, что подлежит тестированию, и подхода, который при этом
будет использоваться.
• Отображение тестов на требования.
• Определение критериев входа и выхода для каждой стадии процесса тестирования.
• Оценка персонала, необходимого для выполнения тестовых работ, по квалификации и степени занятости.
• Оценка времени, необходимого для выполнения работ по тестированию.
• Планирование основных этапов работ,
• Определение тестовой системы (аппаратных и программных средства), необходимой для проведения тестировании.
• Определение рабочих продуктов для каждой фазы тестирования.
• Оценка рисков, связанных с тестированием, и план по их уменьшению.
Промежуточные результаты или выходы, являющиеся результатами этих действий,
могут быть включены в план проведения испытаний, который, как правило, состоит из
одного или большего числа документов.
2.8.5. Проектирование тестов, реализация и отладка
Динамическое тестирование основано на выполнении заданного набора операций
на конкретном модуле программного продукта и сравнении фактически полученных
результатов с ожидаемыми. Если после прогона получен ожидаемый результат,
считается, что модуль прошел тест. Если зафиксировано аномальное поведение, тест
считается неудачным, однако он может оказаться успешным в смысле обнаружения
дефекта. Заданный набор выполняемых операций образует тестовый случай. Следует
подчеркнуть, что тестовые случаи должны быть спроектированы, закодированы и
отлажены до того, как их можно будет использовать.
Проектирование тестов состоит из двух компонентов: архитектуры тестов и
подробных планов тестов. Архитектура тестов упорядочивает тесты по группам, таким
как функциональные тесты, испытания для определения рабочих характеристик,
проверка безопасности и т.д. Она также описывает структуру и соглашения по именованию хранилища тестов. Подробные планы тестов описывают назначение каждого
теста, технические средства и данные, необходимые для выполнения теста, ожидаемые
результаты каждого теста, а также указывают на требование, на подтверждение
выполнения которого ориентируется данных тест. Между требованиями и планами
тестов должно существовать, по меньшей мере, отношение один к одному.
На основе планов тестов могут быть разработаны подробные методики проверки.
Уровень детализации, необходимый для представления методики проверки в виде
письменного документа, зависит от квалификации и уровня знаний персонала, выполняющего прогон тестов. Следует найти компромисс между временем, необходимым
для написания подробной, последовательной методики, и временем, которое
24
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
заинтересованное лицо тратит на обучение правильному выполнению тестов. Даже
если тест должен быть автоматизирован, в общем случае затраты времени на
заблаговременное подробное описание методики проверки оправдываются, поскольку
перед специалистом по автоматизации ставится четкая и однозначная задача
автоматизации теста.
Как только методика тестирования будет описана, ее потребуется проверить на
каком-либо модуле программного продукта. Поскольку, скорее всего, этот тест будет
проверяться на "изобилующей ошибками" программе, особо внимательно следует
анализировать случаи, когда тест не проходит, что позволит определить, где находится
причина неудачи — в тестируемом коде или в самом тесте.
2.8.6. Системное тестирование
Набор завершенных, отлаженных тестов может использоваться и на следующей
стадии каскадного процесса тестирования, т.е. на этапе системных испытаний.
Системное тестирование проводится для удостоверения того, что программное
обеспечение делает именно то, что от него ожидает пользователь. Существуют два
основных типа системных испытаний: функциональная проверка и испытания для
определения рабочих характеристик.
Функциональная проверка (functional testing) или тестирование программы как
«черного ящика» (см. ранее) не требует от тестировщика знаний принципов работы
программного продукта, в то же время она требует знаний функциональных
требований, предъявляемых к системе. Она использует набор тестов, которые
определяют, выполняет ли система все то, что она должна делать с точки зрения
пользователя.
После
того,
как
тестирование
подтвердило
адекватность
базовой
функциональности системы, задачей тестирования становится проверка, насколько
хорошо система выполняет свои функции. В рамках испытаний для определения
рабочих характеристик (performance testing) выполняются такие проверки, как
тестирование в предельных режимах, нагрузочные испытания, контроль синхронизации
и проверка восстанавливаемости. Испытания на надежность, па эксплуатационную
готовность, проверка приспособленности к техническому обслуживанию также можно
включить в число испытаний для определения рабочих характеристик.
Помимо функциональной проверки и испытаний для определения рабочих характеристик, возможны различные дополнительные проверки, проведение которых может
понадобиться на стадии системных испытаний. В их число могут входить проверка
безопасности, установочная проверка, проверка на совместимость, проверка удобства и
простоты использовании, проверка возможностей наращивания.
2.8.7. Приемочные испытания
По завершении системного тестирования продукт может быть передан
пользователю для проведения приемочных испытаний. Если пользователи принадлежат
той же компании, что и разработчики, такое тестирование обычно называется алъфатестированием (alpha testing). Если пользователями являются заказчики, готовые работать с программным продуктом еще до его официальной готовности, то такое тестирование называется бета-тестированием (beta testing) (см. ранее).
Другой формой приемочных испытаний являются аттестационные
испытания (benchmark test), когда заказчик выполняет заранее определенный
Учебно-исследовательская лаборатория "Информационные технологии"
25
Название документа
набор тестовых случаев, имитирующих типовые условия, в которых система будет
работать после ввода в эксплуатацию. Для аттестационных испытаний могут быть
использованы тестовые случаи, которые разработаны и отлажены вашей тестирующей
организацией и которые в то же время были проверены и одобрены заказчиком. По
завершении контрольных и аттестационных испытаний заказчик должен уведомить вас,
какие требования не удовлетворены, а какие должны быть изменены, чтобы можно
было перейти к заключительным испытаниям.
Заключительным типом приемочных испытаний является установочная
проверка (installation test), по условиям которой завершенная версия
программного продукта устанавливается на площадках заказчика с целью получить от
него подтверждение, что программный продукт соответствует всем требованиям и
заказчик согласен на его поставку.
2.8.8. Сопровождение
Сопровождение программного продукта часто ставит разработчиков и
тестировщиков перед необходимостью решения определенных задач. Сопровождения
для разработчика — это исправление дефектов, которые были обнаружены заказчиком
во время эксплуатации программного продукта, а также расширение функциональных
возможностей продукта, которое призвано удовлетворить возросшие требования заказчика. Что касается организации тестирования, то сопровождение означает проверку
результатов исправления дефектов, тестирование расширенных функциональных
возможностей и выполнение регрессионных тестов (regression tests) на
новых версиях программного продукта. Цель всего этого заключается в получении
подтверждения того, что ранее исправно работавшие функциональные средства не
пострадали от внесения изменений в программный продукт.
26
Учебно-исследовательская лаборатория "Информационные технологии"
Название документа
3. Приложение
Инструментальные средства тестирования
фирмы Rational Software Corporation
Rational Visual Test
Rational Visual Test позволяет осуществить полное тестирование целого комплекса
объектов - от 32-битных программных приложений для Windows и их
составных частей до динамически связанных библиотек, не
зависящих от языка программирования.
Отличительные черты:
Благодаря автоматизации повторяющихся задач в регрессионном
тестировании, приводит к созданию программ более высокого
качества. Использует TestBasic – язык программирования
автоматического тестирования – для создания многоразовых, поддерживаемых и
расширяемых активов тестирования.
Rational Visual PureCoverage
Rational Visual PureCoverage автоматически выявляет те
области исходного кода, которые были пропущены при
тестировании. Это помогает легко и быстро определить
пробелы в тестировании, тщательно, эффективно и
результативно
провести
тестирование
программного
приложения. Отличительные черты:
Анализирует программное приложение в совокупности,
включая его компоненты, как при наличии исходного кода, так
и без него.
Выводит статистику для каждого запуска executable, а также автоматически
объединяет данные по нескольким запускам.
Позволяет контролировать уровень охвата кодовых данных, собираемых каждым
модулем.
Интегрируется с Microsoft Developer Studio '97. Поддерживает программы,
написанные в Visual Basic, Visual C++ и Java.
Rational Purify
Rational Purify, инструментальное средство для проверки
run-time ошибок для разработчиков, создающих программные
приложения и компоненты в языках С/С++, помогает
обеспечить надежность программ.
Отличительные черты:
Проверяя каждый доступ к памяти, осуществляемый
программным приложением, Rational Purify быстро и
автоматически выявляет ошибки run-time и утечки памяти во
всех частях программы, включая компоненты, как при
наличии исходного кода, так и без него.
Следит за ошибками в Windows API calls и методах OLE.
Интегрируется с Microsoft Developer Studio для Visual
Учебно-исследовательская лаборатория "Информационные технологии"
27
Название документа
C++.
В обновленной версии Rational Purify 2000 появились
возможности:
Улучшена поддержка Visual Basic, Visual C++ и Java
Прямая интеграция с PureCoverage
Улучшен модуль поиска ошибок и утечек
Улучшена совместимость с InternetInformationServer
Оптимальная производительность в Windows 2000
дополнительные
Rational Visual Quantify
Rational Visual Quantify - это мощное инструментальное
средство
определения
производительности
для
разработчиков, создающих программные приложения и
компоненты в языках С++, Visual Basic и Java. Оно дает
разработчику возможность с большой точностью увидеть, как
исполняется программа.
Отличительные черты:
Быстро и автоматически определяет узкие места,
устраняя таким образом трудности и неопределенности при
настройке производительности программного приложения.
Предоставляет детальные и повторяемые данные по
производительности.
Интегрировано с Microsoft Developer Studio.
В обновленной версии Rational Quantify 2000 появились дополнительные
возможности:
Улучшена поддержка Visual Basic, Visual C++ и Java
Интеграция с Rational Visual Test и Rational ClearQuest
Поддержка Java 2 JDK
Улучшена совместимость с InternetInformationServer
Оптимальная производительность в Windows 2000
28
Учебно-исследовательская лаборатория "Информационные технологии"