Файл: ОСНОВЫ АЛГОРИТМИЗАЦИИ И ПРОГРАММИРОВАНИЯ (Проверка ПО комплексный метод).pdf

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

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

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

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

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

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

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

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

.

2. Основные подходы тестирования и их ограничения

2.1 Метод Сандвича

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

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

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

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

2.2 Метод «белого ящика»

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

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

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

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

Стратегия Белого ящика включает в себя следующие методы тестирования:

- покрытие операторов (подразумевает выполнение каждого оператора программы, по крайней мере, один раз)

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

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

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

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

2.3 Метод «черного ящика»

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

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

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

- Ошибка интерфейса программы;

- Удобство использования интерфейса;

- Ошибки в функциональности;

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

- Ошибки при загрузке программы;

- Наличие критических ошибок, приводящих к выходу из программы или ее закрытию;

- Качество безопасности программы от взлома;

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

Главными недостатками данного метода можно считать:

- Могут быть протестированный не все входные данные;

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

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

2.4 Метод «серого ящика»

Метод «серого ящика» - тестирование программного обеспечения с частичным знанием его программного кода. ВО время тестирования, не обязателен доступ к изначальному коду программы. Все тесты назначаются и проводятся на основе знания об алгоритме программы и ее поведения.

Существуют следующие виды тестирования по методу «серого ящика»:

- Матричное;

- Регрессивное;

- Шаблонное;

- Ортогональным массивом;

К плюсам данного метода можно отнести;

- Можно использовать наиболее сложные сценарии для тестирования;

- У разработчика есть достаточный временно запас для исправления ошибок;

- Разработчики и татуировщики выполняют работу совместно;

- также включает плюсы «черного» и «белого» ящика;

К недостаткам метода можно отнести:

- Ограниченность анализа как кода, так и интерфейса;

- Тестирование может быть избыточным;

- Большие временные затраты при проверке все возможных вводов и выводов информации;

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

3.1 Статические методы отладки

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

- ручная прогонка программы;

- использование программного анализатора, например, компилятор. При автоматизированном анализе будет попадать в метод «статической отладки», так как проводится без участия ЭВМ.

- массовая или коллективная прогонка программы;

- проверка на технологические ошибки соответствующим специалистом;