Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы тестирования и отладки программного обеспечения. Учебник
.pdf
ошибки, выявленные при подтверждении правильности, требуют изменения сроков разработки продукта.
Важным элементом подтверждения правильности является проверка конфигурации ПО. Конфигурацией ПО называют
совокупность всех элементов информации, вырабатываемых
в процессе ее конструирования. Минимальная конфигурация
ПО включает следующие базовые элементы:
1) системная спецификация;
2) план программного проекта;
3) спецификация требований к ПО: работающий или бумаж-
ный макет;
4) предварительное руководство пользователя;
5) спецификация проектирования;
6) листинги исходных текстов программ;
7) план и методика тестирования; тестовые варианты и полу-
ченные результаты;
8) руководства по работе и инсталляции;
9) ехе-код выполняемой программы;
10) описание базы данных;
11) руководство пользователя по настройке;
12) документы сопровождения; отчеты о проблемах ПО; за-
просы сопровождения; отчеты о конструкторских изменениях;
13) стандарты и методики конструирования ПО.
Проверка конфигурации гарантирует, что все элементы конфигурации ПО правильно разработаны, учтены и достаточно детализированы для поддержки этапа сопровождения в ЖЦ ПО.
Разработчик не может предугадать, как заказчик будет реально использовать ПО. Для обнаружения ошибок, которые способен найти только конечный пользователь, используют процесс,
включающий альфа- и бета-тестирование.
Альфа-тестирование проводится заказчиком в организации
разработчика. Разработчик фиксирует все выявленные заказчиком ошибки и проблемы использования.
Бета-тестирование проводится конечным пользователем
в организации заказчика. Разработчик в этом процессе участия
не принимает. Фактически, бета-тестирование – это реальное
применение ПО в среде, которая
Заказчик
сам записывает все обнаруженные проблемы и сообща-
не управляется разработчиком.
51
ет о них разработчику. Бета-тестирование проводится в течение
фиксированного срока (около года). По результатам выявленных проблем разработчик изменяет ПО и тем самым подготавливает продукт полностью на базе заказчика.
3.5. Системное тестирование
Системное тестирование подразумевает выход за рамки области действия программного проекта и проводится не только
программным разработчиком. Классическая проблема системного тестирования – указание причины. Она возникает, когда
разработчик одного системного элемента обвиняет разработчика
другого элемента в причине возникновения дефекта. Для защиты от подобного обвинения разработчик программного элемента
должен:
– предусмотреть средства обработки ошибки, которые тести-
руют все вводы информации от других элементов системы;
– провести тесты, моделирующие неудачные данные или дру-
гие потенциальные ошибки интерфейса ПО;
– записать результаты тестов, чтобы использовать их как до-
казательство невиновности в случае «указания причины»;
– принять участие в планировании и проектировании систем-
ных тестов, чтобы гарантировать адекватное тестирование ПО.
В конечном счете, системные тесты должны проверять, что
все системные элементы правильно объединены и выполняют
назначенные функции.
К системному тестированию относятся следующие виды тестирования ПО:
– тестирование производительности;
– нагрузочное или стрессовое тестирование;
– тестирование конфигурации и совместимости различных
конфигураций;
– тестирование безопасности;
– тестирование надежности и восстановления после сбоев;
– тестирование удобства использования.
Рассмотрим основные типы системных тестов.
Тестирование производительности направлено на определе-
ние того, что система обеспечивает должный уровень производительности при
52
обработке пользовательских запросов. Тестиро-
вание производительности выполняется при различных уровнях
нагрузки на систему, на различных конфигурациях оборудования.
Выделяют три основных фактора, влияющих на производительность системы: 1) число поддерживаемых системой потоков
(например, пользовательских сессий); 2) количество свободных
системных ресурсов; 3) количество свободных аппаратных ресурсов.
Тестирование производительности позволяет выявлять «узкие» места в системе, которые проявляются в условиях повышенной нагрузки или нехватки системных ресурсов. В этом
случае по результатам тестирования проводится доработка системы, изменяются алгоритмы выделения и распределения ресурсов системы.
Все требования, относящиеся к производительности системы,
должны быть четко определены и обязательно включать в себя
числовые оценки параметров производительности. Например,
требование «Система должна иметь приемлемое время отклика
на запрос пользователя» является непригодным для тестирования. Напротив, требование «Время отклика на запрос пользователя не должно превышать 2 секунды» может быть протестировано.
То же самое относится и к результатам тестирования производительности. В отчетах о данных видах тестирования сохраняют такие показатели, как загрузка аппаратного и системного
ПО (число циклов процессора, выделенной памяти, количество
свободных системных ресурсов и т.п.). Также важны скоростные характеристики тестируемой системы (число обработанных
в единицу времени запросов, временные интервалы между началом обработки каждого последующего запроса, равномерность
времени отклика в разные моменты времени и т.п.).
Для проведения
наличие
генератора запросов, который подает на вход системы
тестирования производительности требуется
поток данных, типичных для сеанса работы с ней. Тестовое окружение должно включать в себя кроме программной компоненты
еще и аппаратную, причем на таком тестовом стенде должна существовать возможность моделирования различного уровня доступных ресурсов.
53
Стрессовое тестирование имеет много общего с тестированием производительности, однако его основная задача – не определить производительность системы, а оценить производительность и устойчивость системы в случае, когда для своей работы
она выделяет максимально доступное количество ресурсов либо
когда она работает в условиях их критической нехватки. Основная цель стрессового тестирования – вывести систему из строя,
определить те условия, при которых она не сможет далее нормально функционировать.
В сущности, проектировщик стрессового теста спрашивает,
как сильно можно расшатать систему, прежде чем она откажет?
Стрессовые тесты проектируются для навязывания программам ненормальных ситуаций:
– стрессовое тестирование производится при ненормальных
запросах на ресурсы системы (по количеству, частоте, размеру –
объему). Например, генерируется 10 прерываний в секунду (при
средней частоте 1, 2 прерывания в секунду);
– скорость ввода данных увеличивается прямо пропорцио-
нально их важности (чтобы определить реакцию входных функций);
– формируются варианты, требующие максимума памяти и
других ресурсов;
– генерируются варианты, вызывающие переполнение вирту-
альной памяти;
– проектируются варианты, вызывающие чрезмерный поиск
данных на диске.
По существу, при стрессовом тестировании испытатель пытается разрушить систему. Разновидность стрессового тестирования называется тестированием чувствительности. В некоторых ситуациях (обычно в математических алгоритмах) очень
малый диапазон данных, содержащийся в границах правильных
данных системы, может вызвать ошибочную обработку или резкое понижение производительности.
Тестирование чувствительности обнаруживает комбинации данных, которые могут вызвать нестабильность или неправильность обработки.
Для проведения стрессового тестирования используются
те же самые инструменты, что и для тестирования производительности. Однако, например, генератор нагрузки при стрессо-
54
вом тестировании должен генерировать запросы пользователей
с максимально возможной скоростью либо генерировать данные
запросов таким образом, чтобы они были максимально возможными по объему обработки.
Стрессовое тестирование очень важно при тестировании webсистем и систем с открытым доступом, уровень нагрузки на которые зачастую сложно прогнозировать.
Большинство программных систем (ПС) массового назначения
предназначено для использования на самом разном оборудовании. Несмотря на то, что в настоящее время особенности реализации периферийных устройств скрываются драйверами операционных систем, которые имеют унифицированный с точки зрения
прикладных систем интерфейс, проблемы совместимости (как
программной, так и аппаратной) все равно существуют.
В ходе тестирования конфигурации проверяется корректность работы ПС на всем поддерживаемом аппаратном обеспечении и совместно с другими ПС.
В ходе тестирования конфигурации необходимо также проверять, что система продолжает стабильно работать при горячей замене любого поддерживаемого устройства на аналогичное.
При этом система не должна давать сбоев ни в момент замены
устройства, ни после начала работы с новым устройством. Также
необходимо проверять, что система корректно обрабатывает проблемы, возникающие в оборудовании, как штатные (например,
сигнал конца бумаги в принтере), так и нештатные (сбой по питанию).
На этапе системного тестирования выполняется тестирование
безопасности. Если ПС предназначена для хранения или обра-
ботки данных, содержимое которых представляет собой тайну
определенного рода (личную, коммерческую,
и т.п.),
то к свойствам системы, обеспечивающим сохранение
государственную
этой тайны, будут предъявляться повышенные требования. Эти
требования должны быть проверены при тестировании безопасности системы. В ходе этого тестирования выполняется проверка того, что информация не теряется, не повреждается, ее
невозможно подменить, а также к ней невозможно получить несанкционированный доступ, в том числе с помощью использования уязвимостей в самой ПС.
55
В отечественной практике принято проводить сертификацию
ПС, предназначенных для хранения данных для служебного пользования, секретных, совершенно секретных и совершенно секретных особой важности. Существует ряд отечественных стандартов
Федеральной службы по техническому и экспортному контролю
(ФСТЭК), регламентирующих свойства ПС по обеспечению необходимого уровня безопасности и отсутствию недокументированных
возможностей («закладок»), которые могут быть использованы
злоумышленником для несанкционированного доступа к данным. Кроме того, существует международный стандарт Common
Criteria, также регламентирующий вопросы защиты информации
в ПС.
Несмотря на то что сертификация – процесс, следующий за
верификацией, требования этих стандартов могут быть использованы и при тестировании системы. Так, стандарт ФСТЭК,
традиционно сокращенно называемый РД СВТ, выделяет следующие группы свойств ПС, подлежащие проверке (некоторые
группы свойств укрупнены для сокращения списка):
– разграничение и контроль доступа – предотвращение досту-
па к «чужой» информации;
– очистка и защита памяти – предотвращение доступа к оста-
точной
– информации после удаления объектов из памяти;
– маркировка и защита информации, передаваемой во внеш-
ний мир – сохранение уровня секретности даже вне системы;
– идентификация и аутентификация – предоставление досту-
па только
– санкционированным пользователям и отказ в доступе всем
остальным;
– регистрация (аудит событий) – регистрация в специальном
журнале всех событий системы, связанных с безопасностью для
последующего анализа;
– гарантии
проектирования и архитектуры
– система должна
быть
– спроектирована таким образом, чтобы гарантировать защи-
щенность информации с определенным уровнем уверенности;
– тестирование – все функции по обеспечению безопасности
должны быть протестированы во всех режимах;
56
– целостность и восстановление средств защиты – система
должна иметь средства контроля корректности всех правил разграничения доступа и системы безопасности в целом и средства
их восстановления при сбое;
– документация разработчика, администратора и пользовате-
ля – все средства системы по обеспечению безопасности должны
быть описаны в соответствующих руководствах.
При разработке и верификации ПС, которая будет подвергаться последующей сертификации работы по сертификации
должны включать в себя проверку всех перечисленных свойств.
Тестирование надежности и восстановления после сбоев осуществляется для того, чтобы удостовериться в том, что ПО вос-
станавливает свою функциональность и продолжает корректно
работать после любой проблемы, прервавшей ее работу.
При тестировании восстановления после сбоев имитируются сбои оборудования или окружающего ПО либо сбои ПС, вызванные внешними факторами. При анализе поведения системы
в этом случае необходимо обращать внимание на два фактора –
минимизацию потерь данных в результате сбоя и минимизацию
времени между сбоем и продолжением нормального функционирования системы.
Отдельная группа нефункциональных требований – требования к удобству пользовательского интерфейса системы.
Тестирование удобства использования программы иногда
называют юзабилити – тестированием. Юзабилити – тести-
рование (англ. – Usability testing) – это исследование, выполняемое в целях определения, удобен ли некоторый искусственный объект (такой как web-страница, пользовательский
интерфейс программы или устройство) для его предполагаемого применения.
В результате выполнения всех рассмотренных
тестирования делается
заключение о функциональности и свой-
выше видов
ствах системы, после чего «узкие» места системы дорабатываются до реализации необходимой функциональности или до достижения системой необходимых свойств.
57
Контрольные вопросы
1. Поясните суть методики тестирования программной си-
стемы.
2. Когда и зачем выполняется тестирование элементов? Ка-
кой этап конструирования оно проверяет?
3. Когда и зачем выполняется тестирование интеграции?
Какой этап конструирования оно проверяет?
4. Когда и зачем выполняется тестирование правильности?
Какой этап конструирования оно проверяет?
5. Когда и зачем выполняется системное тестирование? Ка-
кой этап конструирования оно проверяет?
6. Поясните суть тестирования элементов.
7. Перечислите наиболее общие ошибки вычислений.
8. Перечислите источники ошибок сравнения и неправиль-
ных потоков управления.
9. На какие ситуации ориентировано тестирование путей об-
работки ошибок?
10. Что такое драйвер тестирования?
11. Что такое заглушка?
12. Поясните порядок работы драйвера тестирования.
13. В чем цель тестирования интеграции?
14. Какие категории ошибок интерфейса вы знаете?
15. В чем суть нисходящего тестирования интеграции?
16. Поясните шаги процесса нисходящей интеграции.
17. Поясните достоинства и недостатки нисходящей инте-
грации.
18. Какие категории заглушек вы знаете?
19. В чем суть восходящего тестирования интеграции?
20. Поясните шаги процесса восходящей интеграции.
21. Поясните достоинства и недостатки восходящей инте-
грации.
22. Какие категории драйверов вы знаете?
23. Какова комбинированная стратегия интеграции?
24. Каковы признаки критического модуля?
25. В чем суть тестирования правильности?
26. Какие элементы включает минимальная конфигурация
программной системы?
27. Что такое альфа-тестирование?
28. Что такое бета-тестирование?
58
29. В чем суть системного тестирования?
30. В чем суть тестирования восстановления?
31. В чем суть тестирования безопасности?
32. В чем суть стрессового тестирования?
59
4. КРИТЕРИИ ВЫБОРА ТЕСТОВ
4.1. Требования к критерию выбора тестов
Тесты разрабатываются с помощью методов тестирования
«белого ящика», которые называются методами структурного
тестирования, и с помощью методов «черного ящика», которые
называются методами функционального тестирования. При тестировании важно определить, удовлетворяет ли выбранный
метод тестирования критерию полноты тестирования. Когда говорят о полноте тестирования, то это понятие достаточно близко к понятию полноты в музейном смысле или в смысле коллекционирования. Разработчики ПО пытаются собрать некоторую
полную коллекцию тестов, но это не означает, что нужно собрать
все-все тесты. Однако необходимо собрать только тесты для некоторых характерных типовых ситуаций.
Полнота тестирования определяется с использованием количественных показателей, называемых критериями полноты
тестирования. К идеальному критерию предъявляются следующие требования:
– критерий должен быть достаточным, т.е. показывать, когда
некоторое конечное множество тестов достаточно для тестирования данной программы;
– критерий должен быть полным, т.е. в случае ошибки дол-
жен существовать тест из множества тестов, удовлетворяющих
критерию, который раскрывает ошибку;
– критерий должен быть надежным, т.е. любые два множе-
ства тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы;
– критерий должен быть легко проверяемым, например вы-
числяемым на тестах.
Для нетривиальных классов программ в общем случае
не существует полного и надежного критерия, зависящего
от программ или спецификаций. Поэтому вместо идеального
общего критерия используются
риев.
Существуют следующие классы критериев:
1) структурные
туре программы (критерии так называемого белого ящика);
критерии – используют информацию о струк-
реальные частные классы крите-
60
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]