Файл: Отладка и тестирование программ: основные подходы и ограничения (Основные методы тестирования).pdf

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

Во-вторых, нужно пытаться разбить область программы на число классов эквивалента так, чтобы каждый тест был эквивалентен любому другому тесту этого класса. ^[27] (И.В, 2006)

Как и все программные обеспечения, тестирование начинается со стадии планирования, обдумываются стратегии, серии тестов и распределение между сотрудниками задачи. Планирование начинается сразу, после того как проектировщики выдают программные требования. ^[28]

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

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

Когда программное обеспечение готово и протестировано, он должен пройти еще ряд последних тестов.

Потом продукт сверяется с опубликованными документациями и системами требования – эти процедуры носят название аттестация тестирования.

Бета-тестирование – подтверждение, что программа достаточно стабильна. На этом этапе с программой начинают работать её потенциальные пользователи.

И пользователи понимают, что в бета-тестирование еще могу быть серьёзные ошибки. (Cem Kaner, 1999).

Тестирование области допустимых значений – область допустимых значений, представляет просто перечисление, нужно обязательно проверить, что

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

1. Нормальный условия (Средний класс)
2. Граничные (Экстремальные) условия
3. Исключительные (Выход за границу класса)^[29] (М.а, 2013)

Тестирование целостности готового продукта и тестирование копий^[30]

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

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

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

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

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

Тестирование программы лучше поручить одному человеку, а не команде.

Для программы средней сложности уйдет около двух недель. (Cem Kaner, 1999)

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

Тестирование “Стеклянного(белого) ящика”

Эта технология называется “тестирование стеклянного ящики” или ее еще могут называть “Тестирование белого ящика”.^[31]

Тестирование “Черного ящика” программу рассматривали как, тестирование объекта у которого внутренняя структура неизвестна. При тестировании “Стеклянного ящика’ ситуация другая. Программист уже разрабатывает тесты на основе исходного кода, к которому у него есть доступ, в результате он имеет преимущества:

1. Направленность тестирования – программист может частями тестировать программу.
2. Полный охват кода – программист всегда определяет какие фрагменты работают в тексте.
3. Управление потоком – программист всегда знает, какая задача должна быть следующей и как она должна работать.
4. Отслеживание целостности данных – программисту всегда известно, какая часть должна изменять элемент данных.
5. Внутренние граничные точки – в исходном коде видны граничные точки, которые скрыты от взгляда
6. Тестирование выбранным алгоритмом – программисту нужно точно знать, какие алгоритмы используются, и обратиться к специальной литературе.

Тестирование ‘Стеклянного ящика” – это часть в процессе программирования. Программисты тестируют каждый модуль после его написания. (Cem Kaner, 1999)

В этом случае тестирующий получает тестовые данные путем анализа логики программы. Незнающему может показаться, что можно построить набор тестов, в котором каждый оператор исполняется хотя бы один раз; нетрудно показать, что это неверно. Подразумевается, что программа проверена полностью, с помощью тестирований можно осуществить выполнение этой программы по всем возможным путям ее потока передач управления^[32]. (И.В, 2006)

Структурное тестирование против функционального.^[33]

Структурное тестирование – это один из видов тестирования “стеклянного ящика”. Главная идея этого тестирования является правильным выбором тестирования программного пути.

Функциональное тестирование – это один из видов тестирования “Черного ящика”. Каждая функция тестируется вводом её входных данных и анализа выходных.

Тестирование частей против тестирования целого.

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

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

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

Самым главным недостатком восходящего тестирования является необходимость написания кода оболочки

Стратегия целостного тестирования – преимуществом этой стратегией является то, что для неё нет необходимости писать дополнительный код. Многие руководители выбирают именно эту стратегию, но это не всегда верно, так как:

1. Очень трудно найти источник ошибки
2. Трудно организовать исправление ошибки (Cem Kaner, 1999)

В заключение можно отметить, что, исчерпывающее входное тестирование предпочтительнее исчерпывающего тестирования путей, ни то, ни другое не могут стать полезными стратегиями, потому что они невозможны. Поэтому реальным путем, который позволит создать хорошую, но, конечно, не абсолютную стратегию, является совмещение тестирования программы черного и белого ящиков.^[34] (И.В, 2006) Вывод: При написании программного обеспечения, программист должен не раз приходить к схемам ящиков.

Типы ошибок

Ошибка – это расхождение между вычислениями, наблюдаемыми и истинным, заданным или теоретически правильным значением.^[35]

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

1. Структурные ошибки
2. Ошибки компиляции
3. Ошибки периода выполнения

Структурные ошибки – данный тип ошибок определяется при наборе программы или ее компиляции.

Ошибки компиляции – возникают из-за ошибки кода. (И.В, 2006)

Функциональность – функциональные недостатки бывают, когда программа не делает что должна.

Обработка ошибок – это очень важная часть программы в них тоже очень часто попадаются ошибки.

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

Ошибки вычисления – самая основная ошибка, это ошибки округления. После промежуточных вычислений может оказаться, что 2+2=1. Даже если в этих этапах не было ошибок. (Cem Kaner, 1999)^[36]

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

Можно прийти к заключению, что все типы ошибок по первой классификации

При тестировании, приходится иметь дело с ошибками периода выполнения. (И.В, 2006)

Ошибки управлением потока^[37] – такие ошибки пропустить сложно, в самом плохом случае в работе произойдет сбой, а если ошибка менее серьёзна, то забредет не туда.

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

Перегрузки – Программа может не справляться с напряжением. Программного обеспечение может не выдерживать долгого использования. У каждой программы свои пределы. (Cem Kaner, 1999)

Программные ошибки классифицируют по нарушению логики на:^[38]

1. Синтаксические
2. Семантические
3. Прагматические

Синтаксические ошибки – заключаются в правописание или пунктуации. В качестве примеров синтаксических ошибок можно назвать:

1. Пропуск знака пунктуации
2. Несогласованность скобок
3. Пропуск скобок
4. Неверное написание слов
5. Отсутствие написание массива

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

Прагматические ошибки – заключаются в нарушении логике алгоритма, смысла.

Некоторые из ошибок объединяются в группы, которые могу тоже служить в классификации:

1. Ошибка адресации – неправильная адресация данных
2. Ошибка ввода и вывода – возникает в процессе обмена данных
3. Ошибка вычисления
4. Ошибка интерфейса – несовпадение фактических и формальных параметров
5. Ошибка обращения к данным – возникает при обращении к данным
6. Ошибка описании данных –ошибка описания данных (И.В, 2006)

Анализ ошибок и их место проявления

На каком этапе работы может быть ошибка: ^[39]

1. При постановке задачи
2. При проектировании программы
3. При написании текста

Результаты анализа ошибок полезно заносить в отчет отладки. (М.а, 2013)

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

Если тестируемый программный продукт состоит из нескольких программ, то следует обязательно указать в какой из программ обнаружена та или иная ошибка.^[40] (Cem Kaner, 1999)

Первичное выявление ошибок^[41]

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

Следует заметить, что из-за методов ручного тестирования таких как: математическое доказательство правильности программ. Первая реакция – это скептицизм, ощущение того, что обычные методы не могут быть полезными. Но использование этих методов показало, что они не уводят в сторону.

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

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

Можно прийти к выводу, что ручное тестирование, нужно проводить начальном этапе. (И.В, 2006)

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

Подробное описание проблемы и как её воспроизвести.

Следует подробно написать в чем состоит проблема. Описать все шаги, подробности и сообщение об ошибке. Составляя данное описание, программист часто не понимает, при каких обстоятельствах проявляется ошибка. Если не удается воспроизвести ошибку, но точно зная, что она была, нужно составить подробный отчет. Программист сможет найти ошибку по отчету, через программный код.^[42]