Методика тестирования программных систем.

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

Спираль процесса тестирования

Охарактеризуем каждый шаг процесса тестирования.

1. Тестирование элементов. Цель - индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».

2. Тестирование интеграции. Цель — тестирование сборки модулей в программ­ную систему. В основном применяют способы тестирования «черного ящика».

3. Тестирование правильности. Цель — проверить реализацию в программной си­стеме всех функциональных и поведенческих требований, а также требования эффективности. Используются исключительно способы тестирования «черно­го ящика».

4. Системное тестирование. Цель — проверка правильности объединения и взаи­модействия всех элементов компьютерной системы, реализации всех систем­ных функций.

Тестирование элементов

Объектом тестирования элементов является наименьшая единица проектирова­ния ПС — модуль. Для обнаружения ошибок в рамках модуля тестируются его важнейшие управляющие пути. Относительная сложность тестов и ошибок опре­деляется как результат ограничений области тестирования элементов. Принцип тестирования — «белый ящик», шаг может выполняться для набора модулей па­раллельно.

Тестированию подвергаются:

· интерфейс модуля;

· внутренние структуры данных;

· независимые пути;

· пути обработки ошибок;

· граничные условия.

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

1) неправильный или непонятый приоритет арифметических операций;

2) смешанная форма операций;

3) некорректная инициализация;

4) несогласованность в представлении точности;

5) некорректное символическое представление выражений.

Источниками ошибок сравнения и неправильных потоков управления являются.

1) сравнение различных типов данных;

2) некорректные логические операции и приоритетность;

3) ожидание эквивалентности в условиях, когда ошибки точности делают эквива­лентность невозможной;

4) некорректное сравнение переменных;

5) неправильное прекращение цикла;

6) отказ в выходе при отклонении итерации;

7) неправильное изменение переменных цикла.

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

1) донесение об ошибке невразумительно;

2) текст донесения не соответствует обнаруженной ошибке;

3) вмешательство системных средств регистрации аварии произошло до обработ­ки ошибки в модуле;

4) обработка исключительного условия некорректна;

5) описание ошибки не позволяет определить ее причину.

И, наконец, перейдем к граничному тестированию. Модули часто отказывают на «границах». Это означает, что ошибки часто происходят:

1) при обработке n-го элемента n-элементного массива;

2) при выполнении т-й итерации цикла с т проходами;

3) при появлении минимального (максимального) значения.

Тестовые варианты, ориентированные на данные ситуации, имеют высокую веро­ятность обнаружения ошибок.

Тестирование интеграции

Тестирование интеграции поддерживает сборку цельной программной системы. Цель сборки и тестирования интеграции: взять модули, протестированные как эле­менты, и построить программную структуру, требуемую проектом.

Тесты проводятся для обнаружения ошибок интерфейса. Перечислим некоторые категории ошибок интерфейса:

· потеря данных при прохождении через интерфейс;

· отсутствие в модуле необходимой ссылки;

· неблагоприятное влияние одного модуля на другой;

· подфункции при объединении не образуют требуемую главную функцию;

· отдельные (допустимые) неточности при интеграции выходят за допустимый уровень;

· проблемы при работе с глобальными структурами данных.

Существует два варианта тестирования, поддерживающих процесс интеграции: нисходящее тестирование и восходящее тестирование. Рассмотрим каждый из них.

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

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

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

1. Модули нижнего уровня объединяются в кластеры (группы, блоки), выполня­ющие определенную программную подфункцию.

2. Для координации вводов-выводов тестового варианта пишется драйвер, управ­ляющий тестированием кластеров.

3. Тестируется кластер.

4. Драйверы удаляются, а кластеры объединяются в структуру движением вверх.

Сравнение нисходящего и восходящего тестирования интеграции

Нисходящее тестирование:

1) основной недостаток - необходимость заглушек и связанные с ними трудно­сти тестирования;

2) основное достоинство - возможность раннего тестирования главных управля­ющих функций.

Восходящее тестирование:

1) основной недостаток - система не существует как объект до тех пор, пока не будет добавлен последний модуль;

2) основное достоинство - упрощается разработка тестовых вариантов, отсутствуют заглушки.

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

Тестирование правильности

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

Подтверждение правильности ПС выполняется с помощью тестов «черного ящи­ка», демонстрирующих соответствие требованиям. При обнаружении отклонений от спецификации требований создается список недостатков. Как правило, откло­нения и ошибки, выявленные при подтверждении правильности, требуют измене­ния сроков разработки продукта.

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

1. системную спецификацию;

2. план программного проекта;

3. спецификацию требований к ПС; работающий или бумажный макет;

4. предварительное руководство пользователя;

5. спецификацию проектирования;

6. листинги исходных текстов программ;

7. план и методику тестирования; тестовые варианты и полученные результаты;

8. Руководства по работе и инсталляции;

9. exe-код выполняемой программы;

10. описание базы данных;

11. руководство пользователя по настройке;

12. документы сопровождения; отчеты о проблемах ПС; запросы сопровождения; отчеты о конструкторских изменениях;

13. стандарты и методики конструирования ПС.

Проверка конфигурации гарантирует, что все элементы конфигурации ПС пра­вильно разработаны, учтены и достаточно детализированы для поддержки этапа сопровождения в жизненном цикле ПС.

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

Альфа-тестирование проводится заказчиком в организации разработчика. Разра­ботчик фиксирует все выявленные заказчиком ошибки и проблемы использова­ния.

Бета-тестирование проводится конечным пользователем в организации заказ­чика. Разработчик в этом процессе участия не принимает. Фактически, бета-тестирование - это реальное применение ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сооб­щает о них разработчику. Бета-тестирование проводится в течение фиксированного срока (около года). По результатам выявленных проблем разработчик изменяет ПС и тем самым подготавливает продукт полностью на базе заказ­чика.

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

Системное тестирование подразумевает выход за рамки области действия про­граммного проекта и проводится не только программным разработчиком. Класси­ческая проблема системного тестирования - указание причины. Она возникает, когда разработчик одного системного элемента обвиняет разработчика другого элемента в причине возникновения дефекта. Для защиты от подобного обвинения разработчик программного элемента должен:

1) предусмотреть средства обработки ошибки, которые тестируют все вводы ин­формации от других элементов системы;

2) провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса ПС;

3) записать результаты тестов, чтобы использовать их как доказательство невиновности в случае «указания причины»;

4) принять участие в планировании и проектировании системных тестов, чтобы гарантировать адекватное тестирование ПС.

В конечном счете системные тесты должны проверять, что все системные ты правильно объединены и выполняют назначенные функции. Рассмотри основные типы системных тестов.

Тестирование восстановления

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

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

Тестирование безопасности

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

Тестирование безопасности проверяет фактическую реакцию защитных механиз­мов, встроенных в систему, на проникновение.

В ходе тестирования безопасности испытатель играет роль взломщика. Ему разре­шено все:

· попытки узнать пароль с помощью внешних средств;

· атака системы с помощью специальных утилит, анализирующих защиты;

· подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);

· целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;

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

Конечно, при неограниченном времени и ресурсах хорошее тестирование безопасности взломает любую систему. Задача проектировщика системы — сделать цену проникновения более высокой, чем цена получаемой в результате инфор­мации.

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

На предыдущих шагах тестирования способы «белого» и «черного ящиков» обеспечивали полную оценку нормальных программных функций и качества функционирования. Стрессовые тесты проектируются для навязывания программам ненормальных ситуаций. В сущности, проектировщик стрессового теста спрашивает, как сильно можно расшатать систему, прежде чем она откажет?

Стрессовое тестирование производится при ненормальных запросах на ресурсы системы (по количеству, частоте, размеру-объему).

Примеры:

· генерируется 10 прерываний в секунду (при средней частоте 1, 2 прерывания в
секунду);

· скорость ввода данных увеличивается прямо пропорционально их важности (чтобы определить реакцию входных функций);

· формируются варианты, требующие максимума памяти и других ресурсов;

· генерируются варианты, вызывающие переполнение виртуальной памяти;

· проектируются варианты, вызывающие чрезмерный поиск данных на диске.

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

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

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