Программная инженерия.Часть II. Учебное пособие

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

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

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

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

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

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

II Часть | пособие Учебное

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

Проверка совместимости. Основной целью данного вида тестирования является проверка корректной работы программного продукта в определенном окружении, в качестве которого может выступать, например, аппаратная платформа, сетевые устройства, периферийные устройства (принтеры, CD/DVD приводы, Web-камеры ипр.), операционная система (Windows, Unix, MACOS и т. д.), базы данных (Oracle, MS SQL, MYSQL и т. д.), системное программное обеспечение (Web-сервер, фаервол, антивирус и т. д.), браузеры (Internet Explorer, Firefox, Opera, Chrome, Safariит. д.).

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

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

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

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

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

ня, функций, исполняемых в нескольких модулях, не будут определены. Кроме того, данная технология бесполезна для проведения тестов на производительность. Таким образом, модульное тестирование более эффективно в сочетании с другими методиками тестирования. Необходимо отметить, что для написания тестов может понадобиться написать большее количество кода, чем будет в самой программе. Например, каждое возможное значение логической переменной потребует двух тестов: один на вариант true, другой – на вариант false. В результате на каждую строку исходного кода потребуется 3–5 строк тестового кода.

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

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

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

II Часть | пособие Учебное

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

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

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

17.3. Работа с ошибками

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

Главный компонент такой системы отслеживания ошибок – база данных, содержащая сведения об обнаруженных дефектах.

В общем случае в составе информации об ошибке должно быть:

–номер (идентификатор) дефекта;

–кто сообщил о дефекте;

–дату и время, когда был обнаружен дефект;

–версия продукта, в которой обнаружен дефект;

–оценка степени серьезности (критичность) дефекта и приоритет решения;

–описание шагов для выявления дефекта (воспроизведения неправильного поведения программы);

–кто ответственен за устранение дефекта;

–обсуждение возможных решений и их последствий;

–текущее состояние (статус) дефекта;

–версия продукта, в которой дефект исправлен.

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

Рис. 17.2. Жизненный цикл ошибки

Статус «Новый» определяет, что дефект зарегистрирован тестировщиком.

После назначения ответственного за исправление дефекта ошибка переходит в статус «Назначен».

Статус «Разрешен» определяет тот факт, что дефект переходит обратно в сферу ответственности тестировщика. Переход, как правило, сопровождается резолюцией, например: «Исправлено» (исправления включены в версию такую-то), «Дубль» (повторяет дефект, который уже находится в работе), «Не исправлено» (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и пр.), «У меня все работает» (запрос дополнительной информации об условиях, в которых дефект проявляется).

Далее тестировщик проводит проверку исправлений, в результате, которой дефект либо снова переходит в статус «Назначен» (если он описан как исправленный, но не исправлен), либо в статус «Закрыт».

Статус «Открыт повторно» свидетельствует о том, что дефект вновь найден в другой версии.

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

II Часть | пособие Учебное

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

серьезность проблемы не имеет прямого отношения к сложности устранения ошибки.

17.4. Тестирование с использованием тест-комплектов

Тест-комплект (тест-кейс) является наиболее простым и распространенным вариантом тестирования ПО.

Структура тест-комплекта включает в себя следующие элементы:

–шаги – это инструкция по выполнению теста;

–исполнение шагов – пошаговое выполнение инструкции;

–ожидаемый результат – описание того, что должно случиться после выполнения каждого шага инструкции;

–фактический результат – это то, что реально произошло после выполнения проверяемого шага.

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

17.5. Программные средства для тестирования программного обеспечения

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

1.Свободно распространяемые системы:

– Redmine;

– BUGS – the Bug Genie;

– Bugzilla;

– ETraxis;

– GNATS;

– Mantis bug tracking system;

– Trac;

– EmForge;

– Picket;

– Flyspray;

– DEVPROM;

– YOUTRACK.

2.Системы, требующие оплаты лицензии:

– Atlassian JIRA;

– Bontq;

– PVCS Tracker;