Документирование и анализ ошибок

Автор: Ольга Рябова

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

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

Первым делом желательно успокоиться и не делать резких движений, не нажимать лишних кнопок и т.д. Надо вспомнить последовательность действий, которые были произведены и попытаться воспроизвести ситуацию. Лучше это делать в новом окне браузера (если речь идёт о web-приложении). Ну и записывать вводимые данные/команды, какие кнопки нажимались, в какие меню производился переход, какая реакция системы на эти действия, какое сообщение об ошибке выводится.

Теперь надо записать свои действия. Записывать надо коротко, но ясно и понятно. Найти золотую середину. Если написать мемуары, то программист их не будет читать или подумает, что ошибка очень трудная и отложит на потом, а сверхкороткий отчёт никто не поймёт. Как следствие исправление ошибки (бага) повиснет в воздухе или отправят обратно вам с пометкой «не воспроизводится» или попросят уточнений, тем самым потратив попросту и Ваше и своё время. Также не стоит в один отчёт вписывать более одной ошибки. Мотив всё тот же.

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

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

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

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

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

Описание ошибки

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

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

Приоритет (насколько серьёзная ошибка и какой скорости выполнения требует. Быстро надо исправить или можно подождать)

Назначить (кто будет заниматься ошибкой)

Класс (это какой вид ошибки- серьёзная, незначительная, опечатка…)

Заголовок ошибки

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

Описание проблемы

Описывать проблему лучше с помощью «стрелочек». С помощью них из текста отчёта выкидывается много ненужных слов, которые мешают понимать суть дела.

Пример: Открыл www.aaa.ru —> ввел в поле bbb слово ccc —>нажал кнопку ddd —> система выдала ошибку: ddd

Пример из жизни

Заголовок: Проблема с меню «забыли пароль»

Описание проблемы: Зайти на страницу авторизации —> нажать кнопку «Забыли пароль?» —> в поле «Лицевой счёт» вписать 2389 —> в поле «e-mail» вписать
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
—> система пишет: «Ошибка отправки сообщения. (#1)»

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

Приложения (Attachments)

Чтобы отчёт сделать более подробным и наглядным можно и нужно прибегнуть к использованию:

• ссылок
• скриншотов
• видео записи

Ссылка

Ну тут всё понятно. Выскочила ошибка — берётся ссылка на эту страницу и вставляется отчёт. Желательно ещё и со скриншотом. (при условии, что тестируется веб-приложение — прим. редактора)

Скриншоты

Очень полезная вещь для визуализации проблемы. Делаете скриншот проблемной зоны. (Самое простое — это на клавиатуре найти кнопку Print Screen, нажать её потом в открыть программку Paint (если мы находимся в операционной системе семейства Windows — прим. редактора), которая автоматически устанавливается в Windows и в ней нажать Ctrl-V, потом вырезать ненужное, сохранить (лучше в формате JPG))

Хотя, есть и более профессиональные программки, которые более приспособлены к такого рода действиям и имеют много очень полезных функций, например SnagIt, HyperSnap, HardCopy, RoboScreenCapture, FullShot 9, HyperSnap-DX 5, TNT 2. Скриншот нужно прикрепить к отчёту об ошибке.

Видео ролики

Если ошибку тяжело описать, то это самый подходящий метод. Программы: SnagIt, CamStudio

Лекция №
10

Тестирование и отладка программ

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

Дейкстра:
«Никакое тестирование не может
подтвердить правильность программы: в
лучшем случае, оно может показать только
ее ошибочность».

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

Виды
программных ошибок Способы
их обнаружения

1.
Синтаксические Статический контроль
и диагностика компилятором и
компоновщиком

2.
Ошибки выполнения, выявляемые
Динамический контроль:

автоматически:

а)
переполнение, потеря порядка, … —
аппаратурой процессора (Вопрос
1)

б)
несоответствие типов —
run-time
системы программирования

в)
зацикливание — операционной
системой – по превы-

шению лимита времени задачи

3.
Программа не соответствует специ-
Целенаправленное тестирование

фикации

4.
Спецификация не соответствует
Испытания, бета-тестирование

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

Глубина
контроля 1-го вида зависит и от языка, и
от компилятора. Строгая типизация весьма
полезна: DO
3 I
= 1.3
– “точка стоимостью 800 млн $” (вместо
запятой) – ошибка в Фортран-программе
бортового вычислителя ракеты к Венере
[1]. Вопрос 2.

Набор
ошибок 2-го вида может быть расширен
программистом: контроль можно
программировать с помощью утверждений
(asserts)
проверок, вставляемых в код. Это полезно
для проверки правдоподобности
промежуточных результатов вычислений
и допустимости значений фактических
параметров подпрограмм.

Собственно
процесс тестирования направлен на
выявление ошибок 3 и 4 видов. Большинство
программистов сами исправляют 99% своих
текущих ошибок. Однако порядка одной
ошибки на 100 строк кода обычно еще
остается, когда программист сдает работу
тестеру, утверждая, что ошибок в ней нет
[2].

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

Ключевой
вопрос – полнота
тестирования:
какое
количество
каких тестов
гарантирует возможно более полную
проверку программы ? Исчерпывающая
проверка на всем множестве входных
данных недостижима. Пример: программа,
вычисляющая функцию двух переменных:
Y
= f
(X,
Z).
Если X,
Y,
Z
– real,
то полное число тестов (2³²)²
= 2⁶⁴ ≈
10³¹.
Если на каждый тест тратить 1 мс, то 10³¹
мс = 800 млн
лет (отсюда видно, что ошибка FDIV
Pentium’а
вполне простительна). Все траектории
выполнения кода также невозможно
воспроизвести. В [1] приведена программа
из двадцати строк кода (цикл и несколько
операторов IF),
у которой 10¹⁷
возможных
путей выполнения.

Следовательно:

• В
  любой нетривиальной программе на любой
  стадии ее готовности содержатся
  необнаруженные ошибки

• Продолжительность
  тестирования – технико-экономическая
  проблема: компромисс между временем и
  полнотой. Поэтому нужно возможно
  меньшее количество хороших
  тестов с
  желательными свойствами:

• Детективность:
  тест должен
  с большой вероятностью обнаруживать
  возможные ошибки.

• Покрывающая
  способность: один
  тест должен выявлять как можно больше
  ошибок.

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

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

Два
вида критериев:

• Функциональные
  – если тесты
  составляются исходя из спецификации
  программы (тестирование черного ящика).
  Проверяется правильность выполнения
  программой всех ее заданных функций.
  Именно этим критериям в основном и
  следуют при независимом тестировании.

• Структурные
  – если тесты
  составляются исходя из текста программы
  (тестирование прозрачного ящика).
  Проверяется правильность работы при
  прохождении всех участков кода. Эту
  работу программисты выполняют постоянно
  в ходе разработки.

Вид
критерия Что должно
обеспечивать множество тестов

А.
Функциональные

1.
Тестирование классов вх. данных !
Содержать представителей всех вх или
вых

2.
Тестирование классов вых. данных !
классов и точки на границах классов

3.
Тестирование функций Каждая функция
внешнего интерфейса должна
быть проверена >= 1раза

Б.
Структурные

1. Тестирование
   команд Каждая команда (оператор)
   д.б. выполнена

>=
1раза

1. Критерий
   С1 – тестир. ветвей Каждая ветвь
   д.б. выполнена >= 1раза

2. Критерий
   С2 – тестир. путей Каждый путь в
   графе программы д.б.

выполнен >=
1раза (Вопрос
3)

На
рис 10-1 а) видно отличие тестирования
команд (достаточен один тест) от С1
(необходимы два теста как минимум). Рис
10-1 б) иллюстрирует отличие С1 (достаточно
двух тестов, покрывающих пути 1, 4 или 2,
3) от С2 (необходимо 4 теста для всех
четырех путей). С2 в принципе недостижим
в реальных программах из-за их цикличности,
поэтому ограничиваются тремя путями
для каждого цикла: 0, 1 и N
повторений цикла.

Идея
назначения классов эквивалентности
вх/вых данных для функционального
тестирования основана на разумном
предположении, что программа на всем
классе ведет себя так же, как на его
одном представителе. Классы назначаются
исходя из семантики решаемой задачи. В
таблице 1 дан пример тестирования классов
выходных
данных:
минимальный набор тестов для программы
нахождения вещественных корней
квадратного уравнения ax²
+ bx
+ c
= 0 (Грюнбергер, 1968).

Рис.10-1.
Траектории вычислений при структурном
тестировании

Таблица
1

	a	b	c	Ожидаемый результат	Что проверяется
1	2	-5	2	x1=2, x2=0.5	Случай вещественных корней
2	3	2	5	Сообщение	Случай комплексных корней
3	3	-12	0	x1=4, x2=0	Нулевой корень
4	0	0	10	Сообщение	Неразрешимое уравнение
5	0	0	0	Сообщение	Неразрешимое уравнение
6	0	5	17	Сообщение	Не квадратное уравнение (деление на 0)
7	9	0	0	x1=x2=0	Корень из 0

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

Пример,
где назначаются классы входных
данных – на
рис. 10-2. Здесь классы- точечные множества;
внутри области А они отмечены штриховкой;
символом * отмечены представители
классов — тестовые значения. На рис. 10-2
предложен минимальный набор из 18 тестов
– по одному для каждого класса и границы
–

стороны
многоугольника, ограничивающего область
А. В состав тестового набора следует
включать значения, непосредственно
примыкающие к граничным. Например, если
допустимые входные значения – целые
от 1 до 99, то для тестирования допусти-мых
данных можно выбрать 1 и 99, а для
недопустимых – 0 и 100. Если программа
получает 8 входных данных, то нужно
предусмотреть 3 теста: ввод 8, 7 и 9 данных.

Запись
классов эквивалентности входных данных
в текстовой форме является частным
случаем плана
тестирования,
пример которого приведен на рис. 10-3.
Заметим, что классы эквивалентности
могут пересекаться, как в этом примере
(классы 1.2.4.1 и 1.2.4.3) – это приводит к
некоторой избыточности, но не страшно.
Задание 4.

Рис
10-2. Классы входных данных для тестирования

1.
Ввод числа

1.1
Допустимые варианты

1.1.1
Числа от 0 до 99

1.2
Недопустимые варианты

1. 0

2. >
   99

3. Отрицательные
   числа

4. Буквы
   и другие нечисловые символы

   1. Буквы

   2. Символы
      с ASCII-кодами,
      меньшими кода 0

   3. Символы
      с ASCII-кодами,
      большими кода 9

2.
Ввод первой буквы имени

2.1
Допустимые варианты

2.1.1
Первый символ является заглавной буквой

<и
т.д.>

Рис
10-3. Классы входных данных: фрагмент
плана тестирования

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

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

Соседние файлы в предмете Информатика

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

Презентация по 4 и 5 главам книги Канера «Тестирование программного обеспечения» Сидорина Анастасия, 332 группа математикомеханического факультета СПб. ГУ

Глава 4 Программные ошибки.

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

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

Качество(продолжение) Еще одной составляющей качества является надежность программного продукта. Она тем выше, чем реже в нем происходят сбои. Также качество нельзя назвать высоким, если программа не выполняет то, что пользователь считает важным. Итак, качество программы определяется: 1. возможностями, благодаря которым она понравится пользователю; 2. недостатками, которые вынуждают пользователя приобрести другую программу. Главное, что тестировщик может сделать для улучшения качества программы, — это выявить ее недостатки, сбои в её работе и явные ошибки.

Программные ошибки Определения: Расхождение между программой и ее спецификацией является ошибкой тогда, и только тогда, когда спецификация существует и она правильна. Если программа не делает того, чего пользователь от нее вполне обоснованно ожидает, значит, налицо программная ошибка (Майерс). Не существует ни абсолютного определения ошибок, ни точного критерия наличия их в программе. Можно лишь сказать, насколько программа не справляется со своей задачей, — это исключительно субъективная характеристика (Бейзер).

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

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

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

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

Категории программных ошибок(продолжение) Ситуация гонок. 1. Предположим, в системе ожидаются два события, А и Б. Первым может произойти любое из них. 2. Если первым произойдет событие А, выполнение программы продолжится, а если первым наступит событие Б, то в работе программы произойдет сбой. 3. Программист полагал, что первым всегда должно быть событие А, и не ожидал, что Б может выиграть гонки. Такие ошибки наиболее типичны для систем, где параллельно выполняются взаимодействующие процессы и потоки, а также для многопользовательских систем реального времени.

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

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

Глава 5 Документирование и анализ ошибок.

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

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

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

Структура отчета о проблеме (продолжение) Тип отчета. Ошибка кодирования. Программа ведет себя не так, как должна по мнению тестировщика. Пример: 2 + 2 = 3. Ошибка проектирования. Программа соответствует проектной документации, но в определенном вопросе тестировщик с ней не согласен. Предложение. Описывается идея, реализация которой, по мнению тестировщика, может улучшить программу. Расхождение с документацией. Программа ведет себя не так, как описано в руководстве или интерактивной справке. Взаимодействие с аппаратурой. Эта проблема связана с неудачным взаимодействием программы и аппаратного обеспечения. Вопрос. Программа делает что-то, чего тестировщик не ожидает или не понимает.

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

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

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

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

Структура отчета о проблеме (продолжение) Состояние. В поле Состояние только что написанного отчета записывается Открыто. После исправления ошибки, значение этого поля изменяется на Закрыто. Приоритет. Ошибки исправляются в порядке их приоритета. (1) Исправить немедленно — ошибка задерживает работу других сотрудников. (2) Исправить как можно быстрее. (3) Исправить в текущей версии (альфа, бета и т. д. ). (4) Исправить до выхода окончательной версии. (5) Исправить, если возможно. (6) Не обязательно — сделайте, как посчитаете нужным. Графу Приоритет имеет право заполнять только руководитель проекта, а графу Степень важности — только составитель отчета или руководитель группы тестирования.

Структура отчета о проблеме (продолжение) Резолюция и Исправленная версия. 1. В графе Резолюция определяется текущее состояние вопроса или принятое по нему решение. 2. Если в ответ на данный отчет в программу были внесены изменения, в графе Исправленная версия программист указывает номер исправленной версии программы. Варианты резолюции: (1) рассматривается. (2) исправлено. (3) не воспроизводится. (4) отложено. (5) соответствует проекту. (6) отозвано составителем. (7) нужна дополнительная информация. (8) не согласен с предложением. (9) дубликат.

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

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

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

Каким должен быть отчет о проблеме (продолжение) Разборчивость. Рукописный отчет должен быть разборчивым. Если отчет вводится в компьютер, это все равно нужно сделать аккуратно. Беспристрастность. Ни в коем случае нельзя допускать оценок работы программиста. Для решения вопроса начальство может установить цензуру.

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

Анализ воспроизводимой ошибки (продолжение) Наиболее серьезные последствия проблемы. Чтобы привлечь к проблеме внимание, нужно представить ее более серьезной. Сбой программы — это: • ее переход в непредусмотренное программистом состояние; • передача управления блоку обработки ошибки.

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

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

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

Методика анализа воспроизводимой ошибки (продолжение) • Мигание и обновление экрана. Если экран неожиданно мигнул, то возможно он был обновлен подпрограммой обработки ошибок. Это может быть первое, что она сделает, а остальные ее действия могут проявиться позднее или не проявиться вовсе. • Перемещение курсора. Это может быть сделано процедурой обработки ошибок, а может быть и результатом сбоя в работе самой программы. • Несколько курсоров. • Повторяющиеся или пропущенные символы. • Горящий индикатор активности устройства, которое не должно участвовать в работе. Программист записал данные не по тому адресу, и вместо определенного места памяти они попали на диск.

Методика анализа воспроизводимой ошибки (продолжение) Отслеживание действий программы. 1. Можно воспользоваться отладчиком исходного кода: какой процесс в данный момент активен, какой объем памяти компьютер использует, насколько заполнен стек и т. д. 2. Распечатка экранов программы и изменений в файлах данных. 3. Если содержимое экрана очень быстро меняется, можно попробовать поработать на менее скоростном компьютере или эксплуатировать программу в многопользовательской среде с повышенной нагрузкой.

Методика анализа воспроизводимой ошибки (продолжение) Выявив критический шаг, тщательно протестируйте его последствия. 1. Если пользователь выполняет шаги А, Б, В, а на шаге В что-то происходит не так, то ошибка на шаге Б. 2. Поменяйте последовательность действий, посмотрите, как поведет себя программа, если после шага Б выполнить не В, а Г. Возможно, обнаружится более серьезная проблема, чем та, которую вы встретили вначале. Поищите дальнейшие ошибки. За найденной ошибкой возможно последуют другие, и информация об этих последствиях первой ошибки может помочь программисту в ее поиске и исправлении.

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

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

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

Направления поиска источника ошибки (продолжение) Ошибка пользователя: вы сделали вовсе не то, что думаете. Тестировщик может ошибиться; например, если исчезли нужные данные, это может означать, что вы их случайно удалили. Но предполагать собственную ошибку следует в последнюю очередь. Ошибка с разрушительными последствиями. Бывает, что последствия ошибки настолько разрушительны, что ее невозможно сразу повторить, т. е. чтобы приступить к воспроизведению ошибки, придется сначала восстановить работоспособность системы. Никогда не работайте с исходными данными — только с копиями!

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

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

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

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

---

Подборка по базе: Word мәтіндік редакторында практикалық жұмыстар жасау.doc, 5-11-2 Планируем работу в графическом редакторе.ppt, Практические работы в графическом редакторе Paint.docx, Вопрос 1 Что такое текстовый редактор.docx, Таблица в текстовом редакторе.pptx, Задание. Использованию возможностей графического редактора Paint, Национальный научный центр особо опасных инфекции.pptx, Раздел 2. Таблицы и графические объекты в текстовых редакторах.d, План урока информатикик создание и редактор текста.doc, Инструменты 3D — редактора.docx

---

Ошибки, связанные с обработкой граничных условий
Простейшими граничными условиями являются числовые (такие, как в примере из первой главы). Но существует и много других граничных си­
туаций. Любой аспект работы программы, к которому применимы понятия больше или меньше, раньше или позже, первый или последний, короче или длиннее, обязательно должен быть проверен на границах диапазона. Внутри диапазонов программа обычно работает прекрасно, а вот на их границах порой случаются самые неожиданные отклонения.
Ошибки вычислений
Программирование даже самых простых арифметических операций всегда чревато ошибками. Нечего и говорить о сложных формулах и расче­
тах. Одними из самых распространенных среди математических ошибок являются ошибки округления. После нескольких промежуточных вычисле­
ний может оказаться, что 2 + 2 = -1, даже если на промежуточных этапах не было логических ошибок.

Скачать материал

Скачать материал

Описание презентации по отдельным слайдам:

• 

  1 слайд

  Сержантов Антон,
  Ведущий программист,
  JaNet systems LLC
  Москва, 2010 г.
  Тестирования программного обеспечения

• 

  2 слайд

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

  Программные ошибки, документирование и анализ

  Разновидности тестирования и их роль в процессе разработки ПО

  Тест-план. Для чего нужен тест-план, какие тесты должен включать?

  Анализ ПО. Приоритеты тестирования.

• 

  3 слайд

  Что такое тестирование?
  Основные понятия
  Заблуждения при тестировании:
  Нельзя полностью протестировать продукт
  Невозможно проверить реакцию программы на каждую комбинацию входных данных
  Невозможно проверить все способы редактирования данных
  Невозможно проверить реакцию программы на ввод данных в каждый момент ее работы (окружение)
  Невозможно проверить каждую возможность выполнения команд программы
  Невозможно выявить все ошибки проектирования
  Тестирование – проверка правильности программы?
  Невозможно проверить, что программа работает правильно

• 

  4 слайд

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

• 

  5 слайд

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

• 

  6 слайд

  Программные ошибки, документирование и анализ
  Категории программных ошибок:
  Ошибки пользовательского интерфейса
  Ошибки функционала
  Взаимодействие программы с пользователем
  Организация программы
  Пропущенные команды
  Производительность
  Выходные данные
  Обработка ошибок
  Алгоритмический ошибки (вычисления, потоки, гонки, перегрузки)
  Контроль версий
  Документация

• 

  7 слайд

  Программные ошибки, документирование и анализ

• 

  8 слайд

  Программные ошибки, документирование и анализ
  Каким должен быть отчет об ошибке:
  Простота
  Понятность
  Воспроизводимость
  Беспристрастность

• 

  9 слайд

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

• 

  10 слайд

  Разновидности тестирования и их роль в процессе разработки ПО
  Этапы разработки ПО:
  Планирование
  Анализ требований (3%)
  Спецификация (3%)
  Проектирование (5%)
  Кодирование и написание документации (7%)
  Тестирование и исправление ошибок (15%)
  Поддержка и сопровождение (67%)
  Чем раньше найти и исправить ошибку, тем дешевле это обойдется!

• 

  11 слайд

  Разновидности тестирования и их роль в процессе разработки ПО
  Тестирование на этапе планирования:
  Что тестируется:
  Идеи
  Кто тестирует:
  Отдел маркетинга
  Руководители проекта
  Аналитики
  Архитекторы
  Специалисты по анализу человеческого фактора

• 

  12 слайд

  Разновидности тестирования и их роль в процессе разработки ПО
  Тестирование на этапе планирования:
  Основные вопросы:
  Адекватны ли требования?
  Полны ли они?
  Совместимы ли требования между собой?
  Выполнимы ли?
  Разумны ли они?
  Сравнительный анализ существующих продуктов
  Дискуссионные группы

• 

  13 слайд

  Разновидности тестирования и их роль в процессе разработки ПО
  Тестирование на этапе проектирования:
  Что тестируется:
  Идеи, более формализованы
  Проектная документация
  Кто тестирует:
  Аналитики
  Архитекторы (в основном решение проблем)

• 

  14 слайд

  Разновидности тестирования и их роль в процессе разработки ПО
  Тестирование на этапе проектирования:
  Основные вопросы:
  Действительно ли проект хорош?
  Соответствует ли проект требованиям?
  Полон ли проект?
  Достаточно ли он реалистичен?
  Хорошо ли описана (продумана, спроектирована) в проекте подсистема обработки ошибок?!
  Совещание аналитиков:
  Обзорное совещание
  Инспекционное совещание
  Рецензионное совещание

• 

  15 слайд

  Разновидности тестирования и их роль в процессе разработки ПО
  Разновидности тестирования:
  Тестирование «Стеклянного ящика»:
  Преимущества:
  Направленность тестирования
  Полный охват кода
  Управление потоком
  Отслеживание целостности данных
  Структурное тестирование:
  Тестирование программных путей, критерии охвата
  Модульное тестирование, нисходящее и восходящее тестирование
  Статическое тестирование и динамическое
  Псевдоотладка и мутационное тестирование
  Анализ производительности
  Регрессионное тестирование

• 

  16 слайд

  Разновидности тестирования и их роль в процессе разработки ПО
  Разновидности тестирования:
  Тестирование «Черного ящика»:
  Приемочное тестирование
  Функциональное тестирование:
  Сверка со спецификацией
  Граничные условия
  Производительность
  Переходы между режимами
  Эксплуатация в реальном режиме
  Нагрузочное тестирование (максимальной объем входных данных, многозадачность, многопользовательский режим)
  Обработка ошибок
  Защита
  Совместимость и преобразование форматов
  Эффектные тесты

• 

  17 слайд

  Разновидности тестирования и их роль в процессе разработки ПО
  Разновидности тестирования:
  Тестирование «Черного ящика»:
  Системное тестирование:
  Аппаратные конфигурации
  Тип ОС
  Формат дисков
  Клавиатура
  Установка
  Интерфейс
  Установка и обслуживание

• 

  18 слайд

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

• 

  19 слайд

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

• 

  20 слайд

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

• 

  21 слайд

  ООО «ДжаНет системс», ИНН 7709715178
  101000, Москва, Петроверигский пер., д. 6-8-10, стр. 8
  Тел.: +7 (495) 625-84-00, info@janetsys.com
  www.janetsys.com

Найдите материал к любому уроку, указав свой предмет (категорию), класс, учебник и тему:

6 275 780 материалов в базе

• Выберите категорию:

• Выберите учебник и тему

• Выберите класс:

• Тип материала:

  • Все материалы

  • Статьи

  • Научные работы

  • Видеоуроки

  • Презентации

  • Конспекты

  • Тесты

  • Рабочие программы

  • Другие методич. материалы

Найти материалы

Вам будут интересны эти курсы:

• Курс повышения квалификации «Методика написания учебной и научно-исследовательской работы в школе (доклад, реферат, эссе, статья) в процессе реализации метапредметных задач ФГОС ОО»

• Курс повышения квалификации «Организация научно-исследовательской работы студентов в соответствии с требованиями ФГОС»

• Курс повышения квалификации «Основы управления проектами в условиях реализации ФГОС»

• Курс повышения квалификации «Экономика предприятия: оценка эффективности деятельности»

• Курс профессиональной переподготовки «Организация логистической деятельности на транспорте»

• Курс повышения квалификации «Разработка бизнес-плана и анализ инвестиционных проектов»

• Курс профессиональной переподготовки «Организация менеджмента в туризме»

• Курс повышения квалификации «Организация маркетинга в туризме»

• Курс повышения квалификации «Источники финансов»

• Курс профессиональной переподготовки «Разработка эффективной стратегии развития современного вуза»

• Курс профессиональной переподготовки «Гражданско-правовые дисциплины: теория и методика преподавания в образовательной организации»