Сбор информации об ошибках формирование отчетов об ошибках практическая работа

Подборка по базе: практическая работа Расчет больничного листа.docx, курсовая работа Бушуев М.Ю.docx, Практическая Работа 1.docx, Лабораторная работа № 1.pdf, Практическая работа 2- само задание (1).docx, Курсовая работа готовая .docx, Курсовая работа фрезерная.doc, 7 практическая работа задание.docx, Готовая работа).docx, Практическая работа по информатике .pptx

Лабораторная работа № 5. Сбор информации об ошибках

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

Для выполнения лабораторной работы № 5 студент должен изучить приведенный ниже теоретический материал. Отчет сдается в распечатанном и электронном (файл Word) видах.
Понятие отчета об ошибках
Отчёт об ошибке (англ. error report или crash report) – это файл, содержащий техническую информацию об исключительной ситуа- ции (исключении), произошедшей в программе на компьютере пользователя.

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

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

Категории событий могут определяться по отдельным служ- бам или по группам связанных событий. К категориям выбранных событий относятся:

• для всех;

• категории, определенные в соответствии с используемым продуктом, например, Office SharePoint Server 2007 или Microsoft Office Project Server 2007;

• административные функции, такие как «Администрирова- ние», «Резервное копирование и восстановление», и др.

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

События журнала Windows могут иметь следующие уровни:

• не используется;

• error (ошибка);

• warning (предупреждение);

• не удалось выполнить аудит;

• успешное выполнение аудита;

• information (информация).

События журнала трассировки могут иметь следующие уровни:

• не используется;

• unexpected (непредвиденный);

• monitorable (контролируемый);

• high (высокая);

• medium (средняя);

• verbose (подробный).

Структура отчета об ошибке
ID (Идентификатор, Номер). 

Каждой записи в системе учета ошибок присваивается уникальный идентификатор или номер. Как правило, он задается самой системой по определенному шаблону. Это может быть просто числовой номер (1,2,3,…3487), а может быть идентификатор вида ПРОЕКТ-НОМЕР, например, TPO-2367, REG-335 и так далее.

Тип (Трекер). Системы управления задачами, как правило, содержат в себе записи различных типов – задача (Task), улучшение (Feature), баг (Bug), пользовательская история (User Story) и так да- лее. Для каждого типа может быть свой набор полей и свой жизнен- ный цикл.

Заголовок (Тема, Title). Краткое описание проблемы. Оно отображается в списках, результатах поиска, фильтрах и позволяет быстро понять, в чем суть проблемы. Оно не должно быть слишком коротким и общим, но одновременно и не должно быть слишком длинным. Существует мнемоническое правило для грамотного со- ставления описания «Что? Где? Когда?»: описание должно описы- вать, что именно сломалось, где сломалось и при каких условиях. Например, «Не работает поиск» – 

плохое описание ошибки, а «В форме поиска после отправки запроса выдается ошибка

«Internal Error» вместо результатов» – уже лучше.

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

Версия. Версия продукта, в которой ошибка была обнаружена.

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

Приоритет (Priority). Приоритет показывает, с какой срочно- стью должен быть исправлен дефект.

Серьезность (Важность, Severity). Серьезность показывает степень влияния дефекта на систему.

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

Описание. Подробное описание проблемы. Иногда бывает од- но 

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

Шаги для воспроизведения. Не всегда этот пункт выделяется как отдельное поле. Если его нет, то нужно шаги для воспроизведе- ния написать в поле «Описание».

Фактический результат. Должен быть обязательно – нужно указать, что мы получили в результате выполнения указанных шагов.

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

если ожидаемый результат тривиален (сервер отдает ошибку 500, программа аварий- но завершается и т. п.)

Вложения (скриншоты, файлы журнала и пр.). Файлы, ко- торые могут помочь для понимания, воспроизведения, локализации и исправления дефекта.

Контрольные вопросы

1. Какие типы журналов можно просматривать средствами утилиты просмотра событий? Для чего предназначен каждый из них?

2. Какие уровни событий предусмотрены в журнале?

3. Какова структура отчета об ошибках?

4. Что такое отчет об ошибках?

5.
Каковы источники информации для создания отчета об ошибках?

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

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

Пример одной из свободных систем
отслеживания ошибок с веб-интерфейсом.
является Bugzilla (разработка
компании Mozilla). Данная
система очень проста и популярна в
использовании [10].

Подобная
система обеспечивает следующие функции:

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

• система
  уведомления о появлении новых ошибок,
  об изменении статуса известных в системе
  ошибок (как правило, это уведомления
  по электронной почте);

• отчеты
  об актуальных ошибках по компонентам
  системы, по интервалам времени, по
  группам разработчиков и разработчикам;

• информация
  об истории ошибки (в том числе отслеживание
  похожих ошибок, отслеживание повторного
  возникновения ошибки);

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

• интерфейс
  ограниченного доступа к системе bug
  tracking для конечного пользователя
  информационной системы, который
  используется как интерфейс обмена
  информацией между пользователем и
  службой технической поддержки системы.

Существуют основные виды продвижения
ошибки (на англ. «bug») по
системе (на англ. «Defect
flow»)(см. рисунок 6).

Рисунок 6 — Defect
flow

При поступление ошибки в систему, из
любого источника (заказчик, разработчик,
тестировщик), баг принимает статус new
(пер. с англ. «новый»). Затем рассматривается
программистом его описание и: или ошибка
решается (на англ. «resolve»)
или ей ставится статус duplicated
(пер. с англ. «дубль»), что означает, что
данная ошибка уже была и на данном этапе
решается, или же ей ставится статус
invalid (пер. с англ.
«необоснованный»)- неверное описание,
такой ошибки не существует. После всего
этого командой тестировщиков данная
ошибка перепроверяется и закрывается
(на англ. «verify») в случае,
если она больше не повторяется, или
переоткрывается (на англ. «reopen»), если
изменения все равно приводят к ошибке.

В отчете об ошибки необходимо соблюдать
некоторые правила:

1. В отчете должна быть с самого начала
понятна суть ошибки.

2.Должны быть четко понятны шаги
воспроизведения.

3.Должен быть известен альтернативный
правильный вариант поведения.

4. Указана версия и приоритет данной
ошибки.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Практическая работа
№ 5

Тема. Определение количества ошибок в программном продукте и числа
необходимых тестов.

Цель. Изучить процесс и организацию тестирования; критерии качества
тестирования; методы, используемые при тестировании; классификацию и оценку
ошибок.

Оборудование. ПК

Ход работы

1. Ознакомиться с теоретической частью.

2. Выполнить практическое задание.

3. Ответить на контрольные вопросы.

4. Оформить отчет.

Теоретическая часть

Тестирование – процесс
выявления ошибок в программе, а отладка
– процесс их устранения. Более
многословное определение тестирования даёт стандарт IEEE 829-1983 «Standard for Software Test Documentation»: «тестирование – это
процесс анализа ПО, направленный на выявление отличий между его реально
существующими и требуемыми свойствами и на оценку свойств ПО».

Отличие между
реально существующим и требуемым свойствами называется дефектом,
или ошибкой. Среди
программистов распространён термин «bug»
(жучок) – баг. Авторство
терминов «bug» и «debugging»
приписывают то знаменитому
изобретателю Томасу Эдисону, в фонограф которого заползали жучки, то американке
Грейс Хоппер, которая в конце II мировой войны работала с компьютером Mark II и вынуждена была искать и устранять из него жучков,
вызывавших замыкания и другие сбои в работе. Итак,
ошибки есть отклонения объектов (программ, документов) от спецификаций, при
условии, что последние существуют и являются правильными, а также отклонения от
требований «здравого смысла», называемых также общесистемными требованиями (к ним, например, относятся законы математики и логики).

Объектами
тестирования являются: исходные тексты программ; исполняемые модули (программы,
библиотеки); документация. Тестирование документации должно выявить расхождения
между содержанием документов и описанных в них программ.

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

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

Три принципа
тестирования:

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

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

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

Основные проблемы организации
тестирования программы состоят в том, что:

— нередко отсутствует эталон, которому должны соответствовать
результаты тестирования;

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

— отсутствуют практически пригодные формальные
критерии качества тестирования.

Исправление ошибки,
внесенной на стадии анализа требований и обнаруженной на стадии окончательной
проверки, стоит в среднем в 100 раз дороже, чем исправление этой же ошибки на
стадии анализа (по другим источникам – в 500 раз дороже). Для исправления
проблем, выявленных при сопровождении продукта, программисты по статистике тратят
до 60 % времени, пытаясь понять документацию и логику программы.

Тестирование
является весьма затратной деятельностью. Поэтому в большинстве случаев
разработчики заранее формулируют какой-либо критерий качества создаваемых программ
(определяют так называемую планку качества), добиваются выполнения этого
критерия и после этого выпускают продукт на рынок. Такая концепция получила
название Good Enough Quality (достаточно хорошее качество) в противовес
концепции Best Possible Quality (наилучшее качество).

Концепция Good
Enough Quality вовсе не эквивалентна отказу от полноценного тестирования.
Выпуск плохо протестированного продукта из-за недостатка времени – это всегда
плохо. Практика показывает, что пользователи склонны со временем забывать даже значительные
задержки с выпуском продукта, но плохое качество выпущенного продукта
запоминается на всю жизнь.

Критерии качества
тестирования

Критерии качества
тестирования иногда называют критериями
покрытия (test coverage), поскольку они показывают степень охвата,
«покрытия» тех или иных аспектов продукта при тестировании. Критерии покрытия
можно разделить на две группы: критерии покрытия структуры (structural test coverage) и критерии покрытия поведения (behavioral test coverage).

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

Структурные критерии
включают оценки полноты покрытия операторов, маршрутов и данных.

1. Полнота
покрытия операторов. Критерий
достигает 100 %, если при тестировании были выполнены все операторы программы
(хотя бы один раз). Критерий указывает, не остались ли участки кода, в которые
управление не попадало ни разу. Если есть множество не отработавшего кода,
говорить о качественном тестировании не приходится. Существуют продукты,
которые позволяют автоматически зафиксировать и визуально показать отработавшие
операторы, например Rational Pure Coverage.

2. Полнота
покрытия маршрутов. Можно
достигнуть 100 % полноты покрытия операторов, но многие ошибки не будут
выявлены, так как они возникают не на всех маршрутах. Маршрутом, или логическим
путём, называют конкретную последовательность выполнения операторов. За счёт
операторов ветвления и циклов в программе может существовать множество
потенциальных маршрутов. Критерий достигает 100 %, если при тестировании
отработали все возможные маршруты программы (хотя бы один раз). Полнота
покрытия маршрутов – очень сильный критерий, достигнуть его максимума в
большой программе нереально. По ряду оценок, при самом тщательном тестировании
программы достигается примерно 60%-я полнота покрытия маршрутов, а с
использованием специальных средств автоматизации тестирования можно достигнуть
90 %. Установить значение полноты покрытия маршрутов тяжело. Поэтому данный
критерий слабо пригоден на практике.

3. Полнота
покрытия данных. Даже если
добиться 100%-й полноты покрытия маршрутов, – это недостаточно для выполнения
полного тестирования. Исследования показали, что только 35 % ошибок остаются
из-за упущенных маршрутов. Дело в том, что даже на одних и тех же маршрутах
ошибки могут возникнуть или нет, в зависимости от разных входных данных.
Критерий полноты покрытия данных достигает 100 %, если при тестировании были
проверены все возможные входные данные во всех возможных сочетаниях. Это
самый сильный критерий, но практически недостижимый. Даже для единственного
16-разрядного параметра придётся провести 65536 тестов. Два таких параметра
потребуют уже 655362 тестов (все сочетания значений). Однако и 100%-я полнота
покрытия данных не гарантирует выявления всех ошибок, поскольку некоторые
ошибки могут зависеть от состояния среды, в которой работает программа,
например от содержимого оперативной памяти.

Методы,
используемые для тестирования

1. Инспекция кода

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

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

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

2. Многократная
разработка

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

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

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

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

3. Классы
эквивалентности и граничные условия

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

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

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

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

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

Проще всего
выделение классов эквивалентности можно показать на примере численных
параметров. Если параметр должен принимать значения из интервала [0;100], для
него естественным образом выделяются три класса эквивалентности: один класс
допустимых значений [0;100] и два – недопустимых: (–∞;0) и (100;+∞). При
тестировании следует проверить поведение системы при подаче значения из каждого
класса.

Часто классы
эквивалентности приходится формировать для целой совокупности параметров, если
они тесно связаны. Например, подпрограмма должна выполнять поиск подстроки s
в строке S. Очевидно, что классы должны быть сформированы с учётом
наличия/отсутствия s в S. Минимально допустимый набор классов
должен включать классы {s есть в S} и {s нет в S}.

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

В примере с числом в
интервале [0;100] следует протестировать следующие значения: {–0,00001; 0;
0,00001; 99,99999; 100; 100,00001}. В примере с поиском подстроки s в строке
S следует протестировать следующие пограничные условия:

Некоторые виды
тестирования уделяют основное внимание либо типичным, либо маргинальным
объектам или явлениям. Так, например, при исследовании удобства пользовательского
интерфейса логично предполагать поведение наиболее типичного пользователя, а при нагрузочном тестировании для системы целенаправленно
создаются не типичные, а всё более невыносимые условия.

Организация
тестирования

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

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

В команде
тестирования специалистов делят на тест—инженеров и тестеров. Тест—инженер
(test engineer) – наиболее
квалифицированный специалист, который владеет навыками планирования
тестирования, разработки и проведения тестов, а также понимает предметную
область. Тестер (test
technician, test specialist)
– менее квалифицированный
специалист, который главным образом занимается выполнением тестов.

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

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

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

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

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

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

Для того чтобы
максимально сократить время подготовки тестовых данных, желательно принять
следующие меры:

— воспользоваться генератором тестовых данных;

— подготовить тестовые данные силами проектной
группы:

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

— выделить тестовые данные из имеющихся файлов;

— выделить тестовые данные из внешних документов.

Классификация
ошибок

Существует много
классификаций ошибок. Наиболее простой является классификация ошибок по
серьёзности:

— Ошибки с высокой серьёзностью препятствуют решению важных задач. Они проявляются
всегда или с высокой степенью вероятности.

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

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

Очевидно, что
серьёзность ошибок фактически определяет приоритетность их исправления, хотя и
не безусловно.

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

1. Ошибки
анализа. Это самые тяжёлые по
последствиям ошибки. Примеры: не предусмотрена нужная функциональность;
дублирование функций; лишние функции;
неверно оценены требования к
техническим средствам; неверно оценены требования к производительности или
переносимости.

2. Ошибки
проектирования. В рамках
предложенного проекта невозможно достичь требуемой в ТЗ функциональности и
критериев качества. Самые тяжёлые ошибки проектирования – архитектурные.

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

4. Ошибки
программной реализации. Это
самый широкий класс ошибок. Рассмотрим важные виды ошибок программной
реализации:

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

4.2. Ошибки
вычислений. Программа не
учитывает возникновение или накопление ошибок вычислений (погрешности,
округления, переполнения и пр.)

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

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

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

4.4. Ошибки
взаимодействия с устройствами и программами. Программа не учитывает возможность отсутствия,
неисправности или ошибок функционирования используемых устройств (дисков,
принтеров и т. д.) или внешних программ, с которыми устанавливается связь по
специальному или известному протоколу (DDE, OLE, FTP, HTTP и т. д.).

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

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

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

— ошибки доступа, чаше всего выход за границы
массива (по указателю или индексу);

— использование неинициализированных переменных.

Оценки ошибок

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

Фирмой IBM
установлено, что в среднем одна ранее не обнаруженная ошибка появляется в
каждых 100 операторах программы. Большинство ошибок содержится в
сопряжениях модулей и операторах ввода—вывода. Такого рода ошибки
затрагивают обычно сразу несколько модулей. После того как проведено
тестирование отдельно каждого модуля, последние объединяются в систему.
Экспериментально установлено, что в 90
% всех новых модулей и в 15 % старых при этом необходимо вносить изменения. Приблизительно в 15 %
новых модулей и 6 % старых следует внести более 10 изменений.

Если осталось D старых
модулей и сформировано M новых, число необходимых изменений N определяется
эмпирически найденным выражением

Эксперименты
показали, что число ошибок в неоттестированных программах пропорционально E^2/3,
где E – мера Холстеда, характеризующая сложность программы. Коэффициент
пропорциональности равен примерно 1/3200. В программах, прошедших стадии
тестирования и отладки, это отношение сохраняется, но коэффициент пропорциональности
уменьшается.

Различные формулы
оценки количества ошибок не учитывают вероятность внесения k новых
ошибок при исправлении n старых.

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

позволяет установить
среднее количество проверок, необходимых для обнаружения n ошибок. Здесь
β – неизвестное значение, которое может быть определено
экспериментально. Исходя из предыдущей формулы, получаем формулу

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

Если n=10, по
формуле получим, что половина всех ошибок может быть обнаружена в первых 22%
тестовых прогонов, необходимых для обнаружения всех ошибок. Процент прогонов
возрастает до 37, если требуется найти 7 из 10 ошибок, и до 66, если требуется
обнаружить 9 ошибок из 10, то есть третья часть времени затрачивается на
обнаружение одной последней ошибки. Если в программе имеется 100 ошибок, то 90
обнаруживается за первые 44 % тестовых прогонов.

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

Практическая часть

Задание 1.      Перечислите критерии качества тестирования.

Задание 2.      Перечислите методы инспекции кода.

Задание 3.      Перечислите классификацию ошибок,
обнаруживаемых при тестировании программного продукта.

Задание 4. Выполните оценку ошибок программы нахождения среднего
арифметического n чисел.

Задание 5.      Результаты выполнения практического задания
запишите в отчет.

Контрольные вопросы

1.     Что такое тестирование? Что является объектами
тестирования?

2.     Изобразите и опишите информационные потоки при
тестировании.

3.     Опишите виды тестирования.

4.     Поясните понятия  «тест», «тестовые данные», 
«тестовый эксперимент».