Сравнение нисходящего и восходящего тестирования интеграции
Нисходящее тестирование:
1) основной недостаток— необходимость заглушек и связанные с ними трудности тестирования;
2) основное достоинство — возможность раннего тестирования главных управляющих функций.
Восходящее тестирование:
1) основной недостаток — система не существует как объект до тех пор, пока не будет добавлен последний модуль;
2) основное достоинство — упрощается разработка тестовых вариантов, отсутствуют заглушки.
Возможен комбинированный подход. В нем для верхних уровней иерархии применяют нисходящую стратегию, а для нижних уровней — восходящую стратегию тестирования [3], [13].
При проведении тестирования интеграции очень важно выявить критические модули. Признаки критического модуля:
1) реализует несколько требований к программной системе;
2) имеет высокий уровень управления (находится достаточно высоко в программной структуре);
3) имеет высокую сложность или склонность к ошибкам (как индикатор может использоваться цикломатическая сложность — ее верхний разумный предел составляет 10);
4) имеет определенные требования к производительности обработки.
Критические модули должны тестироваться как можно раньше. Кроме того, к ним должно применяться регрессионное тестирование (повторение уже выполненных тестов в полном или частичном объеме).
Тестирование правильности
После окончания тестирования интеграции программная система собрана в единый корпус, интерфейсные ошибки обнаружены и откорректированы. Теперь начинается последний шаг программного тестирования — тестирование правильности. Цель — подтвердить, что функции, описанные в спецификации требований к ПС, соответствуют ожиданиям заказчика [64], [69].
|
|
|
Подтверждение правильности ПС выполняется с помощью тестов «черного ящика», демонстрирующих соответствие требованиям. При обнаружении отклонений от спецификации требований создается список недостатков. Как правило, отклонения и ошибки, выявленные при подтверждении правильности, требуют изменения сроков разработки продукта.
Важным элементом подтверждения правильности является проверка конфигурации ПС. Конфигурацией ПС называют совокупность всех элементов информации, вырабатываемых в процессе конструирования ПС. Минимальная конфигурация ПС включает следующие базовые элементы:
1) системную спецификация;
2) план программного проекта;
3) спецификацию требований к ПС; работающий или бумажный макет;
4) предварительное руководство пользователя;
5) спецификация проектирования;
6) листинги исходных текстов программ;
7) план и методику тестирования; тестовые варианты и полученные результаты;
|
|
|
8) руководства по работе и инсталляции;
9) ехе-код выполняемой программы;
10) описание базы данных;
11) руководство пользователя по настройке;
12) документы сопровождения; отчеты о проблемах ПС; запросы сопровождения; отчеты о конструкторских изменениях;
13) стандарты и методики конструирования ПС.
Проверка конфигурации гарантирует, что все элементы конфигурации ПС правильно разработаны, учтены и достаточно детализированы для поддержки этапа сопровождения в жизненном цикле ПС.
Разработчик не может предугадать, как заказчик будет реально использовать ПС. Для обнаружения ошибок, которые способен найти только конечный пользователь, используют процесс, включающий альфа- и бета-тестирование.
Альфа-тестирование проводится заказчиком в организации разработчика. Разработчик фиксирует все выявленные заказчиком ошибки и проблемы использования.
Бета-тестирование проводится конечным пользователем в организации заказчика. Разработчик в этом процессе участия не принимает. Фактически, бета-тестирование — это реальное применение ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику. Бета-тестирование проводится в течение фиксированного срока (около года). По результатам выявленных проблем разработчик изменяет ПС и тем самым подготавливает продукт полностью на базе заказчика.
|
|
|
Системное тестирование
Системное тестирование подразумевает выход за рамки области действия программного проекта и проводится не только программным разработчиком. Классическая проблема системного тестирования — указание причины. Она возникает, когда разработчик одного системного элемента обвиняет разработчика другого элемента в причине возникновения дефекта. Для защиты от подобного обвинения разработчик программного элемента должен:
1. предусмотреть средства обработки ошибки, которые тестируют все вводы информации от других элементов системы;
2. провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса ПС;
3. записать результаты тестов, чтобы использовать их как доказательство невиновности в случае «указания причины»;
4. принять участие в планировании и проектировании системных тестов, чтобы гарантировать адекватное тестирование ПС.
В конечном счете системные тесты должны проверять, что все системные элементы правильно объединены и выполняют назначенные функции. Рассмотрим основные типы системных тестов [13], [52].
|
|
|
Тестирование восстановления
Многие компьютерные системы должны восстанавливаться после отказов и возобновлять обработку в пределах заданного времени. В некоторых случаях система должна быть отказоустойчивой, то есть отказы обработки не должны быть причиной прекращения работы системы. В других случаях системный отказ должен быть устранен в пределах заданного кванта времени, иначе заказчику наносится серьезный экономический ущерб.
Тестирование восстановления использует самые разные пути для того, чтобы заставить ПС отказать, и проверяет полноту выполненного восстановления. При автоматическом восстановлении оцениваются правильность повторной инициализации, механизмы копирования контрольных точек, восстановление данных, перезапуск. При ручном восстановлении оценивается, находится ли среднее время восстановления в допустимых пределах.
Тестирование безопасности
Компьютерные системы очень часто являются мишенью незаконного проникновения. Под проникновением понимается широкий диапазон действий: попытки хакеров проникнуть в систему из спортивного интереса, месть рассерженных служащих, взлом мошенниками для незаконной наживы.
Тестирование безопасности проверяет фактическую реакцию защитных механизмов, встроенных в систему, на проникновение.
В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:
· попытки узнать пароль с помощью внешних средств;
· атака системы с помощью специальных утилит, анализирующих защиты;
· подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);
· целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;
· просмотр несекретных данных в надежде найти ключ для входа в систему.
Конечно, при неограниченном времени и ресурсах хорошее тестирование безопасности взломает любую систему. Задача проектировщика системы — сделать цену проникновения более высокой, чем цена получаемой в результате информации.
Стрессовое тестирование
На предыдущих шагах тестирования способы «белого» и «черного ящиков» обеспечивали полную оценку нормальных программных функций и качества функционирования. Стрессовые тесты проектируются для навязывания программам ненормальных ситуаций. В сущности, проектировщик стрессового теста спрашивает, как сильно можно расшатать систему, прежде чем она откажет?
Стрессовое тестирование производится при ненормальных запросах на ресурсы системы (по количеству, частоте, размеру-объему).
Примеры:
· генерируется 10 прерываний в секунду (при средней частоте 1,2 прерывания в секунду);
· скорость ввода данных увеличивается прямо пропорционально их важности (чтобы определить реакцию входных функций);
· формируются варианты, требующие максимума памяти и других ресурсов;
· генерируются варианты, вызывающие переполнение виртуальной памяти;
· проектируются варианты, вызывающие чрезмерный поиск данных на диске.
По существу, испытатель пытается разрушить систему. Разновидность стрессового тестирования называется тестированием чувствительности. В некоторых ситуациях (обычно в математических алгоритмах) очень малый диапазон данных, содержащийся в границах правильных данных системы, может вызвать ошибочную обработку или резкое понижение производительности. Тестирование чувствительности обнаруживает комбинации данных, которые могут вызвать нестабильность или неправильность обработки.
Дата добавления: 2021-03-18; просмотров: 90; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!