Вопрос 4. Основные виды тестирования программного обеспечения.

Вопрос 4. Основные виды тестирования программного обеспечения.

Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на других этапах ЖЦ ПО . На этапе анализа тестирование проводится, например, для получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения. Для успешного проведения этапа тестирования и, как следствие, этапа сопро­вождения необходимо начинать планирование этапа тестирования однов­ре­менно с началом работ по разработке системы. Постепенно план тестирования дорабатывается на разных этапах ЖЦ ПО .

Основные виды тестирования ПО с графическим интерфейсом пользователя: проверка графического интерфейса пользователя; функциональное тестирование; проверка производительности; регрессионное тестирование.

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

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

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

Одним из наиболее развитых средств автоматизированного тестирования является QA (новое название - Quality Works ) фирмы Segue Software (США). QA представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя. Позволяет быстро создавать тесты, эмулирующие работу большого числа пользователей, в целях определения производительности и надежности распределенного приложения. QA позволяет начинать тестирование на любой фазе ЖЦ ПО , планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты. Позволяет безболезненно переносить систему тестирования вместе с тестируемым приложением с одной платформы на другую. Основными компонентами QA являются: QA Partner - среда для разработки, компиляции и выполнения тестов; QA Organizer - модуль для разработки планов тестирования и управления процессом тестирования. Позволяет просматривать результаты тестов и анализировать временные характеристики многотестовых циклов. Для создания и выполнения тестов в процессе работы QA Organizer вызывается QA Partner . Является мощным средством группового тестирования, одним из атрибутов каждого теста является имя его разработчика, что позволяет выполнять тесты, созданные конкретным тестировщиком ; Agent - модуль, поддерживающий работу в сети.

Другим средством для автоматизированного тестирования приложений является средство Rational PerformanceStudio фирмы Rational Software Corporation . С помощью данного средства можно провести все виды функционального и нагрузочного тестирования как крупных, так и средних приложений. Оно измеряет и предсказывает производительность прикладного ПО в архитектуре клиент-сервер и Web-приложений. Причем тестирование производи­тельности дает такие же результаты, как при работе конечного пользователя. Средство Rational TeamTest фирмы Rational Software Corporation производит функциональное и нагрузочное тестирование, поддерживает весь процесс тестирования, включая формулировки требований и необходимых условий.

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

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

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

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

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

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

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

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

Методы выявления ошибок. Программисту надо знать методы уменьшения числа ошибок и методы выявления ошибок. Рассмотрим наиболее эффективные.

а) Метод обзора кода. Это визуальный просмотр текста программы, анализ логики выполнения отдельных операторов . Ц ель обзора - найти как можно больше ошибок в новом коде перед его первой компиляцией . Компилятор не рекомендуется применять даже для выявления синтаксических ошибок, как ни удивительно это покажется большинству программистов. Согласно статистике, компилятор языка Си++ не замечает 9,4% синтаксических ошибок и опечатки. Например, вместо индекса i используется j . И та, и другая переменные описаны в программе, поэтому такая ошибка компилятором не распознается, а на этапе тестирования время на устранение подобных ошибок увеличивается в десятки раз. По данным разных исследований, при обзоре кода одна ошибка выявляется и ликвидируется в среднем каждые 5-20 мин, на этапе тестирования модулей - каждые 15-30 мин и на этапе комплексного тестирования - каждые 8 ч.

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

в) Метод чтения программы. Часто используется опытными программистами для установления правильности системы. Является очень эффективным. При возникновении непонятной ошибки программист анализирует свою программу вместе с коллегами . Даже если коллеги ничего не могут сказать по существу, что вполне понятно, данный метод часто позволяет успешно определить ошибку. Ошибки обнаруживают, когда программист, к которому обратились за помощью, не понимая некоторых фрагментов, просит автора программы дать пояснения. Метод чтения программы зарекомендовал себя как один из самых эффективных в отношении стоимости методов обнаружения ошибок в системе. Для ускорения и повышения эффективности процесса отладки и выявления ошибок программисты используют специализированные средства такие как: DevPartner 64 - предназначен для отладки и выявления ошибок в 64-битных приложениях. Разработчики могут автоматически обнаруживать и диагностировать утечки памяти, переполнение буферов, некорректные вызовы интерфейсов API и другие распространенные ошибки программирования. В состав пакета включена 64-битная версия известного отладчика SoftICE , который предоставляет обзор всех данных и инструкций, используемых в 64-битном варианте операционной системы Windows XP . Новая реализация признанной технологии SoftICE позволяет выявить и проанализировать любые типы ошибок - от неверной ссылки в указателе до несоответствия типов данных. Реализована уникальная возможность переключения между представлениями работы ядра и приложения.