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

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

Тестировщики описывают баг (ошибку) следующим образом: «Неправильно работает форма такая-то.» А программист отвечает на это: «И что. «.

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

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

Что именно неправильно?

Итак, есть проблема:

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

Также следует, что:

Хочешь ВЫЙТИ ИЗ СИСТЕМЫ ? 12 простых ШАГОВ чтобы выйти из МАТРИЦЫ изменить МИР и улучшить СВОЮ ЖИЗНЬ

• Невозможно организовать систематическую работу по исправлению багов.
• Тратится много лишнего времени сразу нескольких сотрудников (ведь и тестировщик также тратит свое время на объяснения).
• Тестировщик не выполняет свои прямые обязанности (ведь он должен не только обнаружить ошибку, но и описать ее так, чтобы ошибку можно было исправить руководствуясь только ее описанием).

Что самое главное должен указать тестировщик в описании ошибки

• Почему неправильно?
• Что именно неправильно?
• Как правильно?
• Как должно быть?

• Как есть сейчас (в чем состоит ошибка)
• Как должно быть (каким должно быть правильное поведение системы)

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

• Последовательность действий для восстановления ошибки (как проверить, что эта ошибка действительно есть и после исправления проверить, что система работает правильно)
• Профиль клиента (версия операционной системы, версия программы, конфигурация компьютера и т.п.)
• Скриншот экрана с ошибкой
• Дополнительные прилагаемые файлы
• Дополнительная информация

Как убедить тестировщиков описывать ошибки по-новому

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

Топ 10 программ которые нужны на любом компьютере. Лучшие программы для ПК

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

Итоги

• Ввести обязательное описание ошибки, состоящее из двух пунктов:

• Как есть сейчас
• Как должно быть

• Сокращение времени, которое раньше совместно тратили программисты и тестировщики на выяснение сути ошибки, до нуля.
• Как следствие — ускорение всего процесса разработки программы.

Источник: varenich.livejournal.com

Home

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

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

Первым делом желательно успокоиться и не делать резких движений, не нажимать лишних кнопок и т.д. Надо вспомнить последовательность действий, которые были произведены и попытаться воспроизвести ситуацию. Лучше это делать в новом окне браузера (если речь идёт о 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

Источник: www.software-testing.ru

Анализ ошибок приложения при помощи adplus и cdb

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

Примерами таких ситуаций могут быть:

• Доступ к области памяти, помеченной как «недоступная». В данном случае программа не получает необходимые данные и дальнейшие вычисления не имеют смысла.
• Исчерпание памяти. Если в какой-то определенный момент времени система не сможет выделить программе область памяти необходимого размера, то программа не сможет нормально функционировать.
• Целочисленное деление на ноль. Результата у подобной операции быть не может, поэтому дальнейшие вычисления смысла не имеют.
• Ошибка получения данных с внешнего устройства. Если данные не получены, то дальнейшие действия над ним так же бессмысленны.

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

Исключение (исключительная ситуация) — событие, возникающее во время выполнения кода [программы], предписывающее исполнение [специального] кода вне штатного (нормального, текущего) потока управления/исполнения.

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

• Уровня операционной системы : к подобным исключениям относятся исключения, возникающие в коде, который использует структурную обработку исключений (Structured Exception Handling, SEH), то есть встроенный в операционную систему Windows механизм обработки программных и аппаратных исключений. Структурная обработка исключений — механизм, который позволяет приложениям самим получать управление в случае возникновения исключительной ситуации (примеры описаны выше) и обрабатывать их собственными силами, не привлекая операционную систему.
• Уровня языка программирования/фреймворка : к подобным исключениям относятся исключения, возникающие в программах, написанных на каких-либо языках программирования (напр.: C++ либо .NET ). Подобные программы используют собственные механизмы обработки исключений на уровне приложения, однако все они все-равно базируются на системной структурной обработке исключений (SEH).

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

• Аппаратное — специальный тип прерывания процессора, генерируемого в ответ на определенное событие. Относятся: Invalid memory access, Integer devide by zero и прч.
• Программное — явный вызов WinAPI-функции RaiseException кодом приложения или модуля ядра ОС. Относятся: любые виды исключительных состояний, описанные разработчиком ПО.

Обработкой исключений в системе занимается специализированный код ядра системы (размещенный в ntdll.dll ), называемый иначе системным обработчиком исключений или кодом диспетчеризации исключений . Он предоставляет системные механизмы обработки исключений, так называемые «внутренние обработчики исключений». Если программа сама не предоставляет обработчика для какого-либо исключения, то исключение попадает на системный обработчик исключений и, в зависимости от настроек, возможны следующие действия: запуск отладчика для изучения, принудительное закрытие виновного процесса с целью предотвращения дальнейших проблем, создание дампа памяти приложения, создание отчета о сбое и прч. В данной заметке мы будем проводить анализ ошибок приложения пользовательского режима с помощью специализированных средств adplus и cdb.
С точки зрения пользователя ошибка приложения выглядит как информационное окно с сообщением о том, что прекращена работа программы «. «. Вид окна в операционной системе Windows 7 приобрел такой вот незамысловатый вид:

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

Крах приложения — необработанное исключение, то есть ошибка, которая не была обработана самим приложением [с целью восстановить нормальное исполнение программы].

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

Дамп памяти приложения — содержимое всей «рабочей» памяти, занимаемой процессом приложения.

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

Для анализа ошибок приложений Microsoft предоставляет несколько утилит в составе комплекта Debugging Tools for Windows, это:

1. Adplus — утилита, автоматизирующая действия отладчика Microsoft CDB с целью установки точек останова, создания дампов памяти и лог-файлов одного или множества процессов.
2. CDB — упрощенный консольный отладчик пользовательского режима (user-mode).

Microsoft рекомендует использовать ADPlus для анализа следующих видов процессов:

• Процессы, которые перестали отвечать на запросы, «виснут».
• Процессы, которые показывают 100% загрузку процессора на одноядерном процессоре, 50% ЦПУ на двухядерном процессоре, 25% ЦПУ на четырехядерном процессоре, и так далее.
• Процессы, которые неожиданно «падают» или «закрываются».

Microsoft не рекомендует использовать ADPlus в следующих случаях:

• Процессы, которые не запускаются, то есть закрываются прямо на этапе запуска.
• DLL или программы, которые порождают большое количество EH-исключений Microsoft Visual C++.

Настройка среды отладки

1. Установка Debugging Tools for Windows. Как мы уже упоминали, ADPlus содержится в составе комплекта Debugging Tools for Windows. Для установки самой свежей и актуальной для моей системы версии Debugging Tools for Windows, я использую полный комплект Windows SDK (Software Developers Kit). Подробнее о процессе установки можно почитать Установка Debugging Tools for Windows.
2. Создание рабочей директории ADplus. Именно по этому пути у нас будут складываться логи, скрипты и дампы. Создадим рабочую директорию для утилиты adplus.exe. Для этих целей я лично предпочитаю использовать каталог хранения временных файлов, заданный системной переменной %TEMP% . На моей системе он почти всегда имеет имя C:TEMP . Исходя из этого создадим директорию c:tempadplus . Каждый раз при запуске ADPlus, отладочная информация будет складываться в новый уникальный подкаталог и каждый файл, создаваемый в этом подкаталоге будет иметь уникальное имя.

Отладка сбойного приложения

1. Определение имени образа или идентификатора сбойного процесса. В начале, чтобы правильно указать за каким именно процессом будет следить adplus, нам необходимо определить либо имя образа проблемного процесса либо PID. Для этих целей, на вскидку, приходит на ум два способа. Можно использовать Диспетчер задач, предварительно в меню «Вид» — «Выбрать столбцы» — включить чекбокс «ИД процесса (PID)»:

либо использовать консольную команду tasklist без опций:

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