Файл: Отладка и тестирование программ: основные подходы и ограничения (Принципы тестирование и отладка программного обеспечения).pdf

Цели и задачи тестирования программного обеспечения

Цели тестирования (рис. 2):

Рис. 2. Цели тестирования

Увеличение вероятности того, что приложение, предназначенное для тестирования, будет работать корректно при любых обстоятельствах.

Увеличение вероятности того, что приложение, предназначенное для тестирования, будет отвечать всем требованиям, описанным.

Проведение полного тестирования приложения в течение короткого времени.

Убедиться, что система работает в соответствии с определенным временем отклика клиента и сервера.

Убедится в том, что наиболее критическая последовательность действий с системой конечного пользователя выполняется правильно.

Чтобы проверить работу пользовательских интерфейсов

Чтобы убедиться в том, что изменения в базах данных не оказывают никакого отрицательного влияния на существующие программные модули.

При разработке тестов, чтобы свести к минимуму обработку тестовых возможных изменений в приложении.

Использовать средства автоматического тестирования^[14], где это необходимо.

Чтобы таким образом не только обнаруживать, но и предотвращать появление дефектов^[15].

При проектировании автоматизированных тестов использовать стандарты разработки, таким образом, чтобы создать многократно используемые скрипты^[16].

Комплексное тестирование программного обеспечения

Цель комплексного тестирования состоит в проверке каждого модуля программного продукта, правильно согласующегося с другими модулями продукта. Если комплексный тест может использовать технологию обработки сверху вниз и снизу вверх, где каждый модуль представляет собой лист в системе дерева и интегрируется со следующим модулем более низкого или высокого уровня, пока не будет создано дерево программного продукта. Эта технология направлена ​​на тестирование не только параметров, которые передаются между двумя компонентами, но и так же проверяются глобальные параметры в случае объектно-ориентированного приложения всех классов верхнего уровня.

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

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

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

Восходящее тестирование является отличным способом обнаружения ошибок. Если ошибка обнаружена при тестировании единственного модуля, то очевидно, что она содержится в нем, для того чтоб найти источник^[17] не нужно анализировать код всей системы. Но если ошибка появляется в совместной работе двух предварительно протестированных модулей, значит дело в их интерфейсе. Еще одним преимуществом восходящего тестирования^[18] является то, что программист фокусируется на очень узкой области (один модуль, передачи данных между парой модулей и т.д.). В связи с этим, тестирование проводится более тщательно и с большей вероятностью обнаружения ошибок.

Основным недостатком восходящего тестирования требуется написание кода оболочки, который вызывает тестовый модуль. Если он, в свою очередь, вызывает еще один модуль, мы должны написать "заглушку^[19]". Заглушка представляет собой моделирование функции для вызова, который возвращает те же данные, но ничего не делает.

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

В отличие от восходящего тестирования, целостное тестирование предполагает, что до полной интеграции системы отдельные модули не проходят тщательное тестирования.

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

• Очень трудно определить источник ошибки. Это главная проблема. Так как ни один из модулей не проверяется должным образом, большинство из них имеют ошибки. Оказывается, что речь идет не, о том в каком модуле произошла ошибка, а в том какая из ошибок всех привлечённых модулей привела к такому результату. И когда есть ошибки нескольких модулей, ситуацию может быть гораздо сложнее локализовать и повторить.

Кроме того, ошибка в одном модуле может блокировать тестирование другого. Как проверить функцию, если вызывающий её модуль не работает^[20]? Если вы не пишете для этой функции программы - оболочки^[21] придется ждать отладки модуля, и это может занять много времени.

• Трудно обеспечить исправление ошибок^[22], если программу написали несколько программистов (именно это происходит в больших системах), и неизвестно, какой модуль с ошибкой, кто собирается её искать и исправлять? Один программист будет ссылаться на другого и говорить, что его код не причём, тот в свою очередь будет ссылаться на первого и в результате всего этого будет большая потеря времени.

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

Существует еще один принцип тестирования, когда программа таким же образом как и при восходящем способе, тестируется не в целом, а по частям. Только направление движения меняется – сперва тестируется верхний уровень модулей, а оттуда тестировщик постепенно опускается. Эта технология называется нисходящий (сверху вниз). Обе технологии - нисходящая и восходящая - называется также инкрементальными.

При нисходящем тестировании нет необходимости писать оболочки, но заглушки остаются. В процессе тестирования заглушки заменяются реальными модулями^[23].

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

Вывод:

Тестированием программного обеспечения - является процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов.

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

Отладка представляет собой процесс определения источников отказов, т.е. ошибок, и исправления программы соответствующим образом.

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

Подходы к разработке тестирования: а) определение объёма работ на основе анализа документов, б) выбор статических и динамических испытаний, в) определение критериев входа и выхода, г) определение стратегии автоматизации.

Любая задача выполняемая многократно, является кандидатом для автоматизации.

Цели тестирования: а) убедиться, что приложение корректно, отвечает требованиям, б) убедиться, что приложение тестируется быстро, в) убедиться, что приложение соответствует по времени отклику клиента и сервера, г) убедиться, что последовательность действий выполняется правильно, д) проверить работу пользовательских интерфейсов, е) изменения в базах данных не оказывают никакого отрицательного влияния на существующие программные модули, и) свести к минимуму обработку тестовых возможных изменений в приложении, к) использовать средства автоматического тестирования где необходимо, л) обнаруживать и предотвращать появление дефектов, о) создать многократно используемые скрипты.

Цель комплексного тестирования состоит в проверке каждого модуля про-рамного продукта, правильно согласующегося с другими модулями продукта.

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

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

Стратегия тестирования и отладки программного обеспечения

1. Метод Сандвича

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

Метод Сэндвича^[25] сохраняет преимущества восходящего и нисходящего подходов, как начало интеграции системы на ранней стадии. Так как вершина программы вступает в действие мы как в нисходящем методе, на ранней стадии получаем скелет рабочей программы. Поскольку нижние уровни программы создаются в методом возрастания, удаляются проблемы нисходящего подхода, которые были связан с невозможностью проверить определенные условия в глубине программы.

Модифицированный метод^[26] сандвича.

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

2. Метод «белого ящика^[27]»

Термин "белый ящик" означает, что при разработке тестовых примеров тестировщик использует любую доступную информацию о внутренней структуре или коде. Технологии используемые в процессе тестирования белого ящика, как правило, называется статическими технологиями тестирования^[28].

Этот метод не делает никаких попыток выявить синтаксические ошибки, поскольку дефекты такого рода обычно обнаруживаются компилятором. Методы белого ящика направлены ​​на ошибки локализации, которые труднее обнаружить, найти и исправить. Они могут быть использованы для обнаружения логических ошибок и для проверки степени покрытия.

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

Рис. 3. Спектр услуг при тестировании методом белого ящика

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