Elettracompany.com

Компьютерный справочник
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Классификация ошибок возникающих при тестировании по

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

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

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

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

В соответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 9.1):

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

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

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

Рис. 9.1. Классификация ошибок по этапу обработки программы

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

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

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

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

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

• появление сообщения об ошибке, обнаруженной операционной системой,

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

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

• неверное определение исходных данных,

• накопление погрешностей результатов вычислений.

Неверное определение исходных данных происходит, если возникают любые ошибки при выполнении операций ввода-вывода.

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

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

• ошибки межмодульного интерфейса,

• другие ошибки кодирования.

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

9.2. Методы отладки программного обеспечения

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

Метод ручного тестирования.

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

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

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

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

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

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

Метод обратного прослеживания.

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

9.3. Методы и средства получения дополнительной информации

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

• интегрированные средства отладки,

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

Данный метод не очень эффективен и в настоящее время практически не используется.

Интегрированные средства отладки.

Большинство современных сред программирования (Delphi, Builder C++, Visual Studio и т. д.) включают средства отладки, которые обеспечивают максимально эффективную отладку. Они позволяют:

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

• предусматривать точки останова,

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

Отладка с использованием независимых отладчиков.

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

9.4. Общая методика отладки программного обеспечения

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

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

Если ошибка не найдена или система просто «зависла», переходят ко второму этапу.

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

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

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

4 этап исправление ошибки — внесение соответствующих изменений во все операторы, совместное выполнение которых привело к ошибке.

5 этап повторное тестирование — повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

Указать этапы тестирования и типы ошибок.

Приведите тесты для задачи:

Ввести элементы двумерного массива MAS(2,2) и, если выше главной диагонали хотя бы один элемент >10, просчитать количество всех элементов матрицы, в противном случае вывести сообщение «Условие не выполнено».

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

Все ошибки в разработке программ делятся на следующие

Ошибка (error) – состояние программы, при котором выдается неправильные результаты, причиной которых являются изъяны в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, а следовательно и к неверному решению.

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

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

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

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

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

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

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

Читать еще:  Подключаемый модуль java

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

3. Этапы тестирования ПО.

• модульное тестирование – тестируется минимально возможный для тестиро-вания компонент, например, отдельный класс или функция;

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

• системное тестирование – тестируется интегрированная система на соответствие исходным требованиям:

o альфа-тестирование – имитация реальной работы с системой разработчи-ками либо реальная работа с системой потенциальными пользователями-заказчиками на стороне разработчика.

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

Дать понятие класса.

Описать классы, использующиеся для моделирования ПО.

Разработать графическое представление изображения классов для моделирования программного обеспечения:

а) управляющий класс;

В) граничный класс.

Структура и поведение одинаковых объектов описывается в общем для них классе.

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

· класс-сущность – пассивный класс, информация о котором должна храниться постоянно. Как правило, этот класс соответствует отдельной таблице БД. В этом случае его атрибуты являются полями этой таблицы, а операции — присоединенными или хранимыми процедурами (рис. 1, б).

· граничный класс располагается на границе системы с внешней средой. К этому типу относят как классы, реализующие пользовательские интерфейсы, так и классы, обеспечивающие интерфейс с аппаратными средствами или программными системами (рис. 1, в).

11. Отладка программного обеспечения. Классификация ошибок, методы отладки программного обеспечения: ручного тестирования, индукции, дедукции, обратного прослеживания.

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

• специфики управления используемыми техническими средствами,

• среды и языка программирования,

• природы и специфики различных ошибок,

• методик отладки и соответствующих программных средств.

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

В целом сложность отладки обусловлена следующими причинами:

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

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

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

• отсутствуют четко сформулированные методики отладки.

В соответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1): синтаксические ошибки — ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы; ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;

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

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

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

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых */ Ошибки компоновки. Ошибки компоновки, как следует из названия, связаны с проблемами,

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

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

• появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль», нарушении адресации и т. п.;

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

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

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

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

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

• неверное определение исходных данных,

• накопление погрешностей результатов вычислений (рис. 10.2).

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

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

К последней группе относят:

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

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

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

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

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

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

опосредованного проявления ошибок;

возможности взаимовлияния ошибок;

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

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

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

написания отдельных частей программы разными программистами.

Методы отладки программного обеспечения

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

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

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

Читать еще:  Java возведение в степень int

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

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

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

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

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

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

Форум тестировщиков

Стандартная классификация ошибок внутри ко.

Олешка 02 окт 2003

Case 08 окт 2003

Олешка 08 окт 2003

Олешка 08 окт 2003

Case 08 окт 2003

По поводу авторских прав — можно вывесить сам док (не анонсируя его через сервер), только для работы в форуме, то есть в форуме просто дадим ссылку на документ.

По поводу предопределённого заранее типа ошибок, говорить не могу — ибо не знаю такого метода 🙂

Olga 08 окт 2003

Case 08 окт 2003

Олешка 08 окт 2003

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

Наверное, имеет смысл взглянуть на список групп ошибок Канера:

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

SNord 08 окт 2003

Олешка 08 окт 2003

Olga 08 окт 2003

Guriy 08 окт 2003

У нас такая группа есть. Другое дело, что она не является обязательной для заполнения.

NOT NULL в базе поставить на поле 😉

Guriy 08 окт 2003

Не использую, потому как не злан что такая спецификация есть.
Можно ссылки в студию или документ в почту (выложу в раздел Портфель).

У него есть поля на форме Change Request
«Component» и «Category»

В компонент — что именно падает «Main Menu — System — File — Open File Dialog»
В категорию — категорию(:)) ошибки «Design»

И потом манагер проекта захотел посмотреть по каким-то параметрам количество багов — выборку по базе 🙂 а-ля

У нас вообще тулзня заполняет эти поля

Case 10 окт 2003

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

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

Guriy 10 окт 2003

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

Тестировщикам зато нет 🙁

Сидит вот у меня девочка, ее от слова «сиквэл» в дрожь бросает. Как ей объяснить что вот эта ошибка произошла на бизнес-уровне, а вот эта, хоть и похожая, на уровне клиента. А вот эта вот, ну просто идентичная с предыдущей, — вообще не наша и желающие могут написать претензии в Майкрософт.

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

Тут именно указывается компонент. А на каком уровне сломалось, это уже девелопер пусть смотрит — у нас задачи другие. Нам под отладчиком тестировать некузяво .

sua 10 окт 2003

Мы в свое время долго бились над классификацие багов у нас в компании и в конце концов пришли к определенному решению. Оно доморощенное, т.к. на тот момент мы были не знакомы с первоисточниками, но и на данный момент нас вполне удовлетворяет
У нас баги делаться по Projects (или Module в другой интерпретации), по Components (область функциональной области)

А еще одна проблема для нас была расстановки проиритетов. Мы также придумали собственную систему:
1- Crash — функция вызывает падеж программы или порчу данных
2 — Blocking point — функция отрабатывает, но результат ноль
3 — Incorrect — функция работает, что-то делает, но неправильно, т.е. результат не совпадает с ожидаемым
4 — Cosmetic — GUI (очепятки, размещение эл-ов ит.д.) и мелкие недочеты функционирования
5 — Requests — предложения по улучшению
6 — specifications — ошибки спецификации
Интересно a как это реализовано у коллег?

Case 10 окт 2003

Сидит вот у меня девочка, ее от слова «сиквэл» в дрожь бросает.

Это её персональная проблема и к вопросу организации процесса отношения не имеет.

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

Это ей обьяснять и не надо 🙂 На это есть вы. У меня когда сотрудники не сообразят куда закинуть (бизнесс уровень, дата) — просто кидают на меня. Когда я не знаю, кто именно сейчас ведёт этот кусок функционала из девелоперов — просто кидаю на ведущего разработчика.

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

Опять не правда ваша — проект большой, но опять таки к предмету темы дела не имеет.
Да какая мне разница сколько в нём файлов исходников? 🙂

У системы есть N модулей. Каждому модулю в разделе риквестов по две папки для начала:
— ЮзерИнтерфейс — сюда и дизайн и юзабилити, и неспецификацию по тем же полям ввода, табордерам, шорткатам и пр
— БизнесЛогика (вылеты, спецификация, логика, предложения и тыды)

А на каком уровне сломалось, это уже девелопер пусть смотрит

Бедные девелоперы — как же вы им риквесты, то биш запросы на изменение то ставите? 🙂

— у нас задачи другие.

Девушек успокаивать, которые в дрожи бьются? 😉

Guriy, без обид, просто призываю более предметно и обоснованно.

Mike 10 окт 2003

Там где я работал тестером, была следующая классификация (по памяти, мож что и путаю):

Note :
Enhancement
Feature request
Bug:
Crash
Exception occured (не приводящие к слёту программы)
Data error
I/O error
Incorrect result
Interface error (ошибки пользовательского интерфейса)
Spelling error

Кроме этого поля (Category), у каждого дефекта было поле Importance

Case 10 окт 2003

А еще одна проблема для нас была расстановки проиритетов. Мы также придумали собственную систему:
1- Crash — функция вызывает падеж программы или порчу данных
2 — Blocking point — функция отрабатывает, но результат ноль
3 — Incorrect — функция работает, что-то делает, но неправильно, т.е. результат не совпадает с ожидаемым
4 — Cosmetic — GUI (очепятки, размещение эл-ов ит.д.) и мелкие недочеты функционирования
5 — Requests — предложения по улучшению
6 — specifications — ошибки спецификации

Очень продумано.
Во многом зависит от системы которую вы тестируете, но чувствую, что проработано. А потом вы это используете как предлагалось выше? То есть строите разные выборки, чтобы погсомтреть что-то? И если не секрент что именно? Или при планировании применяете? Приоритеты ж ведь.

Интересно a как это реализовано у коллег?

У нас сейчас тип бага это просто указание разработчику что именно вылетело — если угодно просто более формальное описание проблемы. Потом я для себя реальной пользы не вижу. Считать сколько было замечаний по дизайну, а сколько по функционалу мне не очень интересно. Мы стараемся всё таки работать на результат (на продукт), а не на цифры отчётов.

SALar 15 окт 2003

Несколько обьемно, но пока удобно.
————
Полное описание ошибки.

Описание
1) ID
2) Заголовок
3) Описание и воспроизведение (можно разбить на две части)
4) Аттач

Управленческие признаки:
1) Приоритет исправления. 4 градации
2) Важность. 4 градации + предложение
3) Номер версии. Крупная версионность, такая как «Альфа», «Вета», .
4) Владелец.
5) Состояние ошибки. Из Rational Rose.

Аналитические признаки:
1) Часть программы. Обычно 5-15.
2) Тип ошибки. Можно брать из Канера.

Достаточно стандартная ситуация:
Необходимо стабилизировать альфа версию для отправки клиенту. Часть ошибок переносится на бету, недочеты по производительности и авторизации не исправлять.
Запрос программиста к базе:
Часть программы: журнал операций (удобней править один пакет подряд)
Состояние: «назначена» или «в работе»
Тип: «функционал», «дизайн» (остальное не важно СЕЙЧАС)
Версия: «Альфа».
Вывести в порядке важности.

Другой запрос:
Срочно исправить ошибки с высоким приритетом (данные ошибки блокируют работу остальных участников команды)

1. Critical (критическая) — с этой ошибкой приложение не может выполнять своих базовых функций
2. Major (важная) — выпадает важная функциональность
3. Average (средняя) — система ведет себя нестабильно и непредсказуемо
4. Minor () — функция реализована неудобно
5. Enhancement () — нужно добавить в спецификацию

Читать еще:  Java util zip

Другой вариант оценки:
1. End User не может выполнять свою работу без внесение изменений в код
2. End User не может выполнять свою работу без консультации с фирмой разработчиком и / или выполнения нетривиальных действий (ручная инициализация базы, …).
3. End User может выполнять свою работу, но это неудобно
4. Мелкие недочеты, такие как, некорректные сообщения системы, отсутствие обозначения полей, обязательных к заполнению, ошибки в падежах, …

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

1. Исправить немедленно.
Данная ошибка блокирует дальнейшую работу остальных участников проекта либо это требование заказчика.
2. По окончании текущей работы
3. Решать в рабочем порядке.
Порядок продолжения разработки и / или внесения изменений планируется разработчиком, исходя из общего плана.
4. Устранить при возможности.
Данная ошибка может быть исправлена при наличии ресурсов или малой ресурсоемкости.

Изначально тестер назначает приоритеты исходя из соответствия важности и критичности для проведения тестов. В дальнейшем менеджер проекта может изменять приоритеты.

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

Классификация ошибок возникающих при тестировании по

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

В краткой классификации выделяются следующие ошибки.

— Ошибки пользовательского интерфейса.

— Ошибки управления потоком.

— Ошибки передачи или интерпретации данных.

— Ошибка выявлена и забыта.

1. Ошибки пользовательского интерфейса.

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

2. Ошибки вычислений.

Выделяют следующие причины возникновения таких ошибок:

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

— неправильно выполняются арифметические операции (как правило — это ошибки кодирования);

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

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

3. Ошибки управления потоком.

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

— очевидно неверное поведение программы;

— переход по GOTO;

— логика, основанная на определении вызывающей подпрограммы;

— использование таблиц переходов;

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

4. Ошибки обработки или интерпретации данных.

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

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

— проблемы с обменом сообщений (сюда включены несколько видов ошибок: отправка сообщения не тому процессу или не в тот порт, ошибка распознавания полученного сообщения, недостающие или несинхронизированные сообщения, сообщение передано только N процессам из N+1, порча данных, хранящихся на внешнем устройстве, потеря изменений, не сохранены введенные данные, объем данных слишком велик для процесса-получателя, неудачная попытка отмены записи данных).

5. Повышенные нагрузки.

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

В этом разделе хотелось бы обратить внимание на следующее:

1) Часть ошибок из этого раздела могут проявляться и при не очень высоких нагрузках, но, возможно, они будут проявляться реже и через более длительные интервалы времени;

2) Многие ошибки из 2-х предыдущих разделов уже в своей формулировке носят вероятностный характер, поэтому следует предположить возможность использования вероятностных моделей и методов для их выявления.

6. Контроль версий и идентификаторов.

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

7. Ошибки тестирования.

Являются ошибками сотрудников группы тестирования, а не программы. Выделяются подпункты:

— пропущенные ошибки в программе;

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

— пропуск ошибок на экране;

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

8. Ошибка выявлена и забыта.

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

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

Основные пути борьбы с ошибками

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

· сужение пространства перебора (упрощение создаваемых систем),

· обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),

· обеспечение однозначности интерпретации представления информации,

· контроль правильности перевода (включая и контроль однозначности интерпретации).

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector
×
×