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

Тестирование программного обеспечения. Классификация ошибок. Примеры.

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

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

По времени появления ошибки можно разделить на три вида:

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

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

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

В теоретической информатике программные ошибки классифицируют по степени нарушения логики на:

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

• семантические. Заключаются в нарушении порядка операторов, параметров функций и употреблении выражений. Семантические ошибки также обнаруживаются компилятором.

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

Постановка задачи планирования эксперимента.

Целью планирования эксперимента является создание таких планов покачивания входных переменных, которые обеспечивают более быстрое и точное построение модели объекта.

Выход объекта состоит из неизвестного сигнала (функции от входов) и центрированной помехи ( ).

. (3.1.1)

Функцию часто называют функцией (или поверхностью) отклика, а входные переменные – факторами.

Если мы имеем дело с малоизученным объектом, то вид функции неизвестен и удобным представлением ее является степенной ряд Тейлора в некоторой базовой точке :

(3.1.2)

; ; .

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

Это уравнение называется уравнением регрессии. В нем (в отличие от ряда (3.1.2) исключены зависимые переменные, такие, например, как , ибо = , а коэффициенты 1/2 и др. включены в параметры . Уравнение регрессии отражает среднюю связь выхода объекта со входами. Параметры модели вычисляются обычно по методу наименьших квадратов на основе экспериментов ( ; . ; ), полученных в результате реализации одного из планов, например, ортогональных.

С помощью планирования эксперимента решаются не только задачи построения модели объекта. Примером служит задача о взвешивании тел.

Взвешивание трех тел ( ) можно провести по традиционной схеме, приведенной в табл. 1.

В ней «+» означает, что тело положено на весы, «–» указывает на отсутствие тела на весах.

Вначале проводится «холостое» взвешивание и тем самым определяется «нулевая» точка весов. Затем по очереди взвешивается каждое из тел. Вес каждого тела оценивается по результатам двух опытов:

вес , вес , вес .

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

,

где – дисперсия ошибки взвешивания.

Проведем теперь взвешивание по иной схеме, представленной в табл. 3.1.2.

Вес каждого тела определяется по формулам:

вес , вес , вес .

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

Найдем дисперсию, связанную с ошибкой взвешивания при новой схеме постановки эксперимента:

.

Аналогичным способом находим:

; .

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

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

Дата добавления: 2015-04-18 ; просмотров: 65 ; Нарушение авторских прав

Тестирование

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

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

Уровни тестирования

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

Интеграционное тестирование — это процесс исследования ПО, при котором тестируется интерфейсы между компонентами или подсистемами.

Системное тестирование — это процесс исследования ПО, при котором тестируется интегрированная система на её соответствие требованиям заказчика. Альфа и Бета тестирование относятся к подкатегориям системного тестирования.

Классификация видов тестирования

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

По объекту тестирования

Функциональное тестирование (functional testing) — тестирование ПО, направленное на проверку реализуемости функциональных требований. При функциональном тестировании проверяется способность ПО правильно решать задачи, необходимые пользователям.

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

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

Стресс-тестирование (stress testing) — тестирование ПО, которое оценивает надёжность и устойчивость системы в условиях превышения пределов нормального функционирования. Это проверка программы в таких стрессовых ситуациях как наличие большого объёма входных параметров, нехватка дискового пространства или маломощный процессор.

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

Тестирование стабильности (stability/endurance/soak testing) — тестирование ПО, при котором проверяется работоспособность ПО при длительном тестировании со среднем уровнем нагрузки.

Тестирование безопасности (security testing) — тестирование ПО, которое проверяет фактическую реакцию защитных механизмов, встроенных в систему на проникновение злоумышленников.

Тестирование совместимости (compatibility testing) — тестирование ПО, которое проверяет работоспособность ПО в определенном окружении.

По знанию системы

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

Тестирование белого ящика (white box) — тестирование ПО, при котором тестировщик имеет доступ к исходному коду програмы и может писать код, связанный с библиотеками тестируемого ПО. К тестированию белого ящика относят методики: чтения программ, формальные просмотры программ, инспекции. Этот метод позволяет заглянуть внутрь «чёрного ящика» и сосредоточиться на внутренней информации, которая и определяет поведение программы. Основной трудностью является сложность отслеживания вычислений времени выполнения. При тестировании программы происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей. Даже для средних по сложности программ число таких путей может достигать десятки тысяч.

По времени проведения тестирования

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

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

Регрессионное тестирование (regression testing) — тестирование ПО, при котором проводится проверка ранее найденных ошибок, а также проверка основной функциональности. Проводится, как правило, на каждой новой версии программного продукта. Регрессивное тестирование является наиболее важной фазой тестирования непосредственно перед окончанием работ над продуктом, так как непосредственно перед релизом продукта крайне необходимо проверить не только основную функциональность, но и то, что ни одна из ранее найденных ошибок не повторяется в финальной версии. Являясь неотъемлемой частью функционального тестирования, регрессионное тестирование позволяет гарантировать, что изменения, связанные с устранением дефектов, не оказали негативного воздействия на остальные функциональные области приложения.

Дымовое тестирование (smoke testing) — тестирование ПО, при котором выполняется набор тестов, после которого можно сказать, что программный продукт запускается. Если ошибок при запуске не происходит, то дымовой тест считается пройденным. Если программа не прошла дымовой тест, то её отправляют на доработку. Дело в том, что разработчики пишут отдельные компоненты одного приложения, но когда эти компоненты объединяют, нередко получается так, что совместно они работать не могут, следовательно, нет смысла тестировать продукт в целом.

По степени автоматизации

Ручное тестирование (manual testing) — тестирование при котором не используются программные средства для выполнения тестов и проверки результатов выполнения.

Автоматизированное тестирование (automated testing) — тестирование при котором используются программные средства для выполнения тестов и проверки результатов выполнения. Автоматизированное тестирование, несомненно, приносит пользу и экономит время и ресурсы компании.

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

Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них: HP LoadRunner, HP QuickTest Professional, HP Quality Center, TestComplete.

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

Динамический и статический анализ кода

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

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

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

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

Собеседования

Вы здесь:
1. Главная
2. Статьи про IT
3. Собеседования
4. Подготовка и прохождение собеседования
5. Требования к тестировщику ПО
6. Требования к тестировщику ч.8: дефекты и ошибки ПО

Поиск

Новые материалы

Собеседования

Требования к тестировщику ч.8: дефекты и ошибки ПО

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

1. Что такое дефект и ошибка?

• Дефект (Defect, Bug Report) – это документ, в котором описано неправильное поведение тестируемой системы или ПО. Не нужно путать дефект с ошибкойбагом. В терминологии тестирования ПО ошибка или баг — это непосредственно проблема ПО (например, ошибка в коде), а дефект — это описание данной проблемы.

2. Для чего необходимо описывать дефекты?

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

3. Как формируется дефект и из чего он состоит?

• Для описания дефектов могут использоваться как специализированные программы (Bugzilla, HP ALM, Redmine, JIRA и д.р.), так и обычные офисные приложения типа Excel, Word и даже Notepad. Вне зависимости от средств и систем для описания дефекта самым важным будет наличие основных параметров и полей, таких как (список основных атрибутов дефекта также приведен на схеме Шаблон типового дефекта ):
  • Номер и краткое описание дефекта
  • Версия ПО и название модулякомпонентаприложения
  • Серьезность (Severity) и срочность (Priority) ошибки. На вопросе различия Severity и Priority остановимся немного подробнее, т.к. он очень часто возникает на собеседовании. В этом случае Severity – показывает насколько ошибка критична для работоспособности всей системы (например, Severity=Blocker), а Priority – говорить как быстро ошибку необходимо исправить с точки зрения планов проекта. Тут главное понимать и помнить, что высокая срочность не означает, что ошибка серьезная как и наоборот – серьезность не говорит, что дефект необходимо исправлять в первую очередь. Например, ошибка серьезная и блокирует часть функциональности новой системы, однако в ближайшем релизе мы не планируем выпускать этот функционал. В этом случае более срочным будет исправление ошибок в той части, которая войдет в релиз, пусть даже эти ошибки будут локальными и не такими значительными. Обычно используются следующие варианты серьезности и срочности:
    • Severity = Blocker, Critical, Major, Minor, Trivial
    • Priority = High, Medium, Low
  • Ссылка на требование, нарушение которого описано в дефекте
  • Автор дефекта, тот кто обнаружил и описал ошибку
  • Описание конфигурации и состояния системы, при котором удалось обнаружить ошибку
  • Детальное описание самой ошибки, которое состоит из:
    • Шагов по воспроизведению ошибки
    • Ожидаемого результата (в соответствии с требованиями)
    • Фактического результата, который мы наблюдаем
  • Дополнительным плюсом будут различные логи и скриншоты экрана, которые помогут увидеть, как проявилась ошибка. Любой разработчик точно скажет за это спасибо.

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