Процесс выполнения программы с целью обнаружения ошибок это

Тестирование — процесс выполнения программы с целью обнаружения ошибок. Тестирование обеспечивает:

— демонстрацию соответствия функций программы ее назначению;

— демонстрацию реализации требований к характеристикам программы;

— отображение надежности как индикатора качества программы.

На входе процесса тестирования три потока:

— исходные данные для запуска программы;

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

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

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

Поиск и устранение всех ошибок Windows. Как исправить ошибку?

Существуют 2 принципа тестирования программы:

функциональное тестирование (тестирование «черного ящика»);

структурное тестирование (тестирование «белого ящика»).

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

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

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

Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:

некорректных или отсутствующих функций;

ошибок во внешних структурах данных или в доступе к внешней базе данных;

ошибок характеристик (необходимая емкость памяти и т. д.);

ошибок инициализации и завершения.

Подобные категории ошибок способами «белого ящика» не выявляются.

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

Лучший вопрос на собеседовании: Что происходит после ввода адреса в браузер?

На этапе тестирования решают две основные задачи:

Тестирование решения — выполняются планы тестирования, созданные на этапе планирования и расширенные и опробованные на этапе разработки;

Пилотная эксплуатация — развертывание решения в тестовой среде и тестирование с привлечением будущих пользователей и реализацией реальных сценариев использования системы. Эта задача выполняется до начала этапа развёртывания.

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

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

На данной стадии разработки информационной системы необходимо провести следующие типы тестирования:

Базовое тестирование — низкоуровневое техническое тестирование. Проводится самим разработчиком в процессе написания программного кода. Применяется метод «белого ящика», высокий риск ошибок.

Тестирование на пригодность к использованию — высокоуровневое тестирование, выполняется тестировщиком и будущими пользователями продукта. Применяется метод «чёрного ящика».

Альфа- и бета-тестирование — в терминах MSF альфа-код — это в основном все исходные тексты, созданные на этапе разработки модели процессов MSF, а бета-код — код, прошедший тестирование на этапе тестирования. Поэтому на этапе разработки модели процесса MSF тестируется альфа-код, а на этапе тестирования — бета-код.

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

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

Тестирование документации и справочной системы — тестируются все разработанные сопровождающие документы и справочные системы.

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

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

Разработка интерфейса программного продукта

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

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

Стандартный графический интерфейс пользователя должен отвечать ряду требований:

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

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

— удовлетворять правилу » шести» — в одну линейку меню включать не более 6 понятий, каждое из которых содержит не более 6 опций;

— графические объекты сохраняют свое стандартизованное назначение и по возможности местоположение на экране.

Организация технологического процесса решения задачи

Источник: lektsia.com

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

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

Одно из наиболее развитых средств тестирования QA (новое название — Quality Works) [20] представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.

QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.

Основными компонентами QA являются:

• QA Partner — среда для разработки, компиляции и выполнения тестов;
• QA Planner — модуль для разработки планов тестирования и обработки результатов. Для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner;
• Agent — модуль, поддерживающий работу в сети.

Процесс тестирования состоит из следующих этапов:

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

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

Для связывания плана с тестами необходимо создать управляющие предложения (скрипты) на специальном языке 4Test и тесты, которые выполняют требования плана, и связать компоненты любым способом. Для избежания перегруженности тестов используют управление тестовыми данными.

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

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

Комплекс QA занимает на жестком диске не более 21МВ. Поддерживаемые платформы: Windows 3.x, Windows 95, Windows NT, OS/2, Macintosh, VMS, HP-UX, AIX, Solaris.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

V. Тестирование и отладка

Тестирование — процесс выполнения программ с целью обнаружения факта наличия ошибок. Это классическое определение тестирования, принадлежащее Гленфорду Майерсу. Обратим внимание, в определении указан лишь один способ проведения тестирования. Существуют и методы ручного тестирования (например, инспекции и сквозные просмотры программ). Поэтому слова «. процесс выполнения программ. » разумно заменить на «… любая деятельность, выполняемая. ».

Отладка — процесс локализации и устранения ошибок.

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

Тестирование программных продуктов

Существуют две основные стратегии тестирования.

Тестирование программы как черного ящика, при котором программа рассматривается как объект, внутренняя структура которого неизвестна.

Тестирование программы как прозрачного (белого) ящика подразумевает знание исходного кода программы и полный доступ к нему.

Существуют также разновидности тестирования.

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

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

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

Типичные ошибки

Категории наиболее распространенных ошибок программистов.

• Ошибки общего (несинтаксического) характера, остающиеся в программах после выполнения синтаксического контроля.

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

• Ошибки специального вида, особенно трудные для диагностирования.

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

• Тестовые данные

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

• Класс корректных тестовых случаев, отражающих типичную «нормальную» ситуацию.
• Класс тестов, содержащих ненормальную ситуацию, т. е. описывающих ситуацию, которой быть не должно.

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

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

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

• Проблема или ошибка зарегистрирована.
• Выполнен первичный анализ (эксперт подтвердил факт наличия ошибки).
• Понятна причина, вызвавшая ошибку.
• Выполнен окончательный анализ проблемы или ошибки.
• Принято решение о начале работы над исправлением.
• Выполнено исправление ошибки.
• Исправление интегрировано в основное пространство.
• Подтверждено исправление ошибки.

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

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

Источник: studfile.net