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

Введение

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

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

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

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

В своей курсовой работе, я использовал литературу:

1) Тестирование и отладка программ для профессионалов будущих и настоящих, Автор этой книги Пласкин М.А, выпущена в 2013 году издательством:

БИНОМ. Лаборатория знаний

2) Методы тестирования программного обеспечения, Автор этого учебного пособия И.В Степанченко, выпущена в 2006 году, издательством:

РПК политехник

3) Тестирование программного обеспечения (На русском языке), авторы этой книги Cem Kaner, Jack L. Falk, выпущена в 1999 году, издательством:

ДиаСофт

Цель данной курсовой работы является:

1) Рассказать об основных методах тестирований

2) Рассмотреть тестирование программного обеспечения на основе методов черного и белого ящика

3) Провести анализ ошибок

1. Основные методы тестирования

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

Перед началом тестирования следует установить цели, которые должны быть получены в ходе тестирования. В частности, набор тестов должен быть полон с точки зрения выбранных критериев полноты тестирования. Независимо от применяемых критериев разработка тестов должна вестись систематически, по определенной методике. (М.а, 2013)^[1]

Тесты готовятся заранее, до выхода. Это касается как исходных данных, так и ожидаемых результатов.

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

Необходимость этого подчеркивал логик в работе: «Проблема может быть охарактеризована как факт или группа фактов, которые не имеют приемлемого объяснения, которые кажутся необычными или которые не удается подогнать под наши представления или предположения. Очевидно, что если что-нибудь подвергается сомнению, то об этом должна иметься какая-то предварительная информация. Если нет предположений, то не может быть и неожиданных результатов».^[2]

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

К сожалению, исполнения этого в целом правильного принципа не всегда возможна в силу трех факторов:

1) ресурсы разработки, недостаточны;

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

3) необходим высокий уровень ведения разработки; (И.В, 2006)^[3]

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

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

Программирующая организация не должна сама тестировать разработанные ею программы

Работа программирующей организации или ее руководителя оценивается по их способности производить программы в течение заданного времени и определенной стоимости. Одна из причин такой системы оценок состоит в том, что временные показатели легко измерить, но в то же время чрезвычайно трудно количественно оценить надежность программы. Именно поэтому в процессе тестирования программирующей организации трудно быть объективной, потому что тестирование в соответствии с данным определением может быть рассмотрено как средство уменьшения вероятности соответствия программы заданным временным параметрам. Как и ранее, из сказанного не следует, что программирующая организация не может найти свои ошибки; тестирование в определенной степени может пройти успешно. Мы утверждаем здесь лишь то, что экономически более целесообразно выполнение тестирования каким-либо объективным, независимым подразделением. В некоторых организациях подобная практика существует, но только на этапах комплексной отладки. Подобный способ тестирования чрезвычайно сложно реализовать из-за организационных трудностей. (И.В, 2006)^[5]

Необходимо полностью изучать результаты каждого теста.

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

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

Необходимо проверить программу на побочные эффекты.

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

Недопустимо ради упрощения тестирования изменять программу.

Тестировать вы будете уже другую программу.

После изменений в программе необходимо повторное тестирование.

Чтобы исправить ошибку, мы вносим изменения в программу. Нельзя гарантировать, что, исправив одну ошибку, мы не внесем другую. Вероятность внесения новой ошибки при исправлении старой оценивается в 20–50%. Для особо сложных систем эта вероятность может быть значительно выше. (М.а, 2013)^[6]

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

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

Для тестирования большого программного обеспечения требуется большой творческий потенциал по сравнению с её проектированием, так как, нельзя дать гарантию, что построенный текст сможет обнаруживать все ошибки. (И.В, 2006)^[7]

Разработка тестов

Характеристики хорошего теста:^[8]

1. Вероятность обнаружение тестом ошибок
2. Набор тестов не должен быть избыточным
3. Тест должен быть лучшим в категории
4. Тест не должен быть сильно простым или сложным

(Cem Kaner, 1999)

Минимально грубое тестирование^[9] – это критерий покрытия решений, условий по проверке циклов

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

(М.а, 2013)

Проектирование теста включается в этапы:^[10]

1. Понять цель теста
2. Входные значения
3. Предполагаемые выходные значения
4. Выполнить тест и записать результат
5. Анализировать результат

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

Четвертый этап является механическим, тут не нужно думать, только аккуратно фиксировать данные.

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

При подготовке тестирования модулей, нужно еще раз просмотреть психологические и экономические принципы. (И.В, 2006)

Обоснованная вероятность выявления ошибок - цель этого тестирования является, выявление ошибок.

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

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

Не слишком сложный и не слишком простой – если объединить два теста, можно сэкономить время, но не переусердствуйте – огромный и сложный тест трудно понять. Кроме трудоемкости у сложных тестов есть свои недостатки. После первого недопустимого значения работоспособность программы выйти из-под контроля.^[11] (Cem Kaner, 1999)

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

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

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

Следует помнить, что задача тестирования заключается не в показе правильно работы программы, а в выявление ошибок. (И.В, 2006)^[12]

Безмашинное тестирование^[13] – для начинающих программистов тестирование подразумевает непременный прогон программы на компьютере.

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

1. Сухая прокрутка

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

Program p;

Var k, n: integer;

Sum: integer;

Begin

Writeln (‘Я считаю сумму квадратов чисел от 1 до 5’);

N: = 5;

Sum: = 0;

For k: = 1 to n do

Sum: = sum + k*k;

Writeln (‘Сумма квадратов чисел от 1 до ‘, n,’=’, sum)

End. {P}

Трассировочная таблица выглядит так:^[14] (М.а, 2013)

2) Символическая прокрутка – в этом варианте не нужно подставлять значения переменных. Вместо этого нужно много анализировать ход программы.

Как переменная получит получит значение, надо убедиться, что значение подходит по смыслу переменной, надо удостоверится, что в программе отражены все возможные случаи.^[15]

3) Работа с коллегой – когда рассуждение идет с самим собой о программе, многие из них остаются не сформулированными. Когда идет разговор с человеком, вам уже необходимо явно формулировать все допущения. И скорее всего в процессе формулировки, вы сами найдете упущения.

4) Передача своей программы коллеге для изучения – возможно, что при изучении собственной программы, вы видите не то, что программа делает, а то что вам бы хотелось видеть. Есть шанс, что коллега увидит в тексте программы, то, что могли упустить и вы. (М.а, 2013)

5) Искусственное внесение ошибок в программу – мощный прием, с психологической точки зрения. После внесения в программу искусственных ошибок, этот психологический стопор снимается.

Некорректное поведение программы проявляется с достаточной очевидностью^[16] - тут есть над чем подумать, неверные выходные данные на экране или бумаги, тестировщик может пропустить.

1) Разрабатывая тест, нужно подробно описать выходные данные и реакцию программы.

2) Нужно постараться выполнять тесты так, чтобы объём выходных данных был минимален.

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