Введение в тестирование программного обеспечения (Ammann & Offutt) упоминает на стр.32 пятиуровневую модель зрелости тестирования:

Уровень 0 Нет разницы между тестированием и отладкой.

Уровень 1 Цель тестирования - показать, что программное обеспечение работает.

Уровень 2 Цель тестирования - показать, что программное обеспечение не работает.

Уровень 3 Цель тестирования - не доказать что-либо конкретное, а снизить риск использования программного обеспечения.

Тестирование уровня 4 - это умственная дисциплина, которая помогает всем ИТ-специалистам разрабатывать более качественное программное обеспечение.

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

Тестирование предназначено для обнаружения дефектов в коде или под другим углом, чтобы доказать на подходящем уровне (он никогда не может быть 100%), что программа делает то, что должна делать. Он может быть ручным или автоматическим, и у него есть много разных видов, таких как юнит, интеграция, система / приемка, стресс, нагрузка, выдержка и т. Д. Тестирование.

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

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

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

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

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

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

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

Там нет ни одного. Если вы делаете это правильно:

Хит их высокий, Хит их низкий :

Регрессионное тестирование и сжатие Saff

Кент Бек, Институт трех рек

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

Тестирование - это привилегия, которой вы наслаждаетесь перед выпуском клиенту.

Ошибки - это кошмар, который вы переживаете после выпуска клиенту.

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

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

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

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

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

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

На уровне 0 тестирование не проводится, потому что команда считает, что в этом нет необходимости.

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

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

На уровне 3 в дополнение ко всему на уровнях 1-2 добавляется нефункциональное тестирование / тестирование на основе некорректности (например, характеристики производительности).

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

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

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

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

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

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

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

Я полностью понимаю очевидную полезность TDD для больших команд и / или систем, которая просто не может позволить себе «глючить». Это также имеет большой смысл для сложных (часто «серверных») систем или если в коде есть высокая доля сложности по сравнению с выводом. Тогда у «тестирования» есть реальная возможность сообщить, когда и почему происходят сбои. Системы, которые выполняют большую сложную работу и / или дают отчетливо измеримые результаты, обычно легко тестируются, поэтому тестирование отличается от отладки. В этих случаях тестирование настоятельно предполагает формализованный метод подтверждения или отклонения соответствия ожиданий и фактического результата. Тестирование происходит постоянно и иногда сообщает нам о необходимости отладки.

Было бы прекрасно, если бы это была вездесущая правда, я бы хотел, чтобы мои циклы разработки были ограничены четко определенным двоичным выходом (красный, зеленый), но ...

В моем случае (что по общему признанию - работа на 98% соло на небольших и средних, недостаточно финансируемых веб-системах, ориентированных на данные корпоративных системах администрирования) я просто не могу понять, как TDD может мне помочь. Вернее, «отладка» и «тестирование» практически одинаковы.

Главным образом, хотя использование термина «тестирование» подразумевает / тесно связано с методологией TDD.

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

Вернее, я категорически не согласен с распространенным предположением, что «тестирование» - это процесс, основанный на формальном коде.

Мое основное возражение (применимо в моем конкретном * контексте *) заключается в том, что ...

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

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

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

Я на 100% согласен с очевидной полезностью в мантре TDD «красный / зеленый / рефактор», но для меня (работа с низким бюджетом, земля соло-разработки RIA) я действительно очень хотел бы, чтобы кто-то показал мне, как я могу возможно , логически и жизненно реально получить какую-либо дополнительную ценность от написания большего ( как и потенциально некорректного тестового кода), чем от реального взаимодействия с полным (и по существу, только) результатом моих усилий, которые по сути связаны с реальным человеческим взаимодействием.

Для меня, когда разработчики говорят о «тестировании», это обычно подразумевает TDD.

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

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

Если цель действительно стоит усилий, а автоматизированное тестирование является эффективным и очень выгодным, а отладка является либо просто результатом этого тестирования, либо плохой заменой автоматического тестирования, то почему второй веб-сайт по посещаемости в мире (Facebook ) так часто пронизаны ослепительно очевидными (для пользователей, но явно не для команды тестирования и кода тестирования) ошибками?

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

Не слишком ли много разработчиков считают, что тестирование - это то, что вы делаете с кодом, а отладка - это то, что вы время от времени делаете в IDE, потому что значок становится красным, и вы не можете понять, почему? Я думаю, что с этими словами связаны неудачные оценочные суждения, которые в целом затеняют практическую реальность того, на чем мы должны сосредоточиться, чтобы сократить разрыв между ожиданиями и результатами.

Просто,

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