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

Содержание:

Введение

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

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

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

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

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

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

1.1 Принципы тестирование и отладка программного обеспечения

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

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

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

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

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

1.2 Этапы тестирования программного обеспечения

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

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

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

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

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

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

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

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

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

Тестировать в первую очередь требования с наивысшим приоритетом.

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

Использовать разбиение на эквивалентные классы и анализ граничных значений для снижения трудозатрат на тестирование

Тестировать те участки, в которых наиболее вероятно присутствие проблем

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

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

- Стадия формулирования требований

- Стадия системного проектирования

- Стадии тестирования проектов программ, программных кодов, модульного тестирования и комплексных испытаний

- Системные испытания

- Приемочные испытания

- Регрессионное тестирование

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

Определение критериев тестирования и точек контроля качества

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

- Критерий входа. Описывает, что нужно сделать перед началом тестирования.

- Критерий выхода. Описывает то, что вы считается необходимым для завершения испытаний.

- Критерий приостановки/возобновления. Описывает, что произойдет, если по причине из-за дефектов продолжение тестирования окажется невозможным.

- Критерий успешного/неудачного прохождения теста. Прогон каждого теста должен давать заранее известные результаты.

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

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

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

1.3 Цели и задачи проверки ПО

Цель проверки ПО:

- Увеличить качество работы ПО в разного рода обстоятельствах.

- Увеличить процент соответствия с предъявляемыми требованиями.

- Полноценная проверка ПО в минимально отведённые сроки.

Задачи проверки ПО:

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

- Система должна правильно выполнять порядок действий даже в наиболее критических последовательностях.

- Работа интерфейсов пользователя должна производиться корректно.

- Любые изменения в базе данных не должны воздействовать на программные модули неблагоприятным образом.

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

- Применять в тестах инструменты автоматизации, где этот метод имеет смысл.

- Проверка программного обеспечения должна обнаруживать и предупреждать недоработки в программе.

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

1.4 Проверка ПО комплексный метод

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

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

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

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

1.5 Проверка ПО восходящим и нисходящим методом

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Матричное;

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

- Шаблонное;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2. Динамические методы отладки

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

К динамическим методам отладки относят:

- тестирование;

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

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

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

Заключение

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

Некоторые методы поиска и устранения ошибок экономически дешевле, другие дороже. Но нельзя зацикливаться только на экономии, к проблемам существования программных ошибок следует подходить комплексно и устранять их. Одними из тех, кто облегчил программирование и сделал более трудном создание ошибок при программировании — это компания Microsoft с языком программирования С#.

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

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

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

Список использованных источников

1. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем [текст] / Б. Бейзер; - Питер, 2004, 320 с. ISBN 5-94723-698-2.

2. Брауде Э.Д. Технология разработки программного обеспечения [текст] / Э.Д. Брауде; - Питер, 2004, 656 с. ISBN 5-94723-663-X.

. Винниченко И.В. Автоматизация процессов тестирования [текст] / И. В. Винниченко; - Питер, 2005, 208 с. ISBN 5-469-00798-7.

. Канер С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений [текст] / С. Канер; - ДиаСофт, 2001, 544 с, ISBN 966-7393-87-9.

. Калбертсон Р. Быстрое тестирование [текст] / Р. Калбертсон, К. Браун, Г. Кобб; - Вильямс, 2002, 384 с. ISBN 5-8459-0336-X.

. Коликова Т.В. Основы тестирования программного обеспечения. Учебное пособие [текст] / Т.В. Коликова, В.П. Котляров; - Интуит, 2006, - 285 с. ISBN 5-85582-186-2.

. Касперски К. Техника отладки программ без исходных текстов [текст] / К. Касперски; - БХВ-Петербург, 2005, 832 с. ISBN 5-94157-229-8.

. Макгрегор Д. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие [текст] / Д. Макгрегор, Д. Сайкс; - ТИД «ДС», 2004, 432 с. ISBN 966-7992-12-8.

. Плаксин М. Тестирование и отладка программ - для профессионалов будущих и настоящих [текст] / М. Пласкин; - Бином. Лаборатория знаний, 2007, - 168 с. ISBN 978-5-94774-458-3.

. Роберт М. Быстрая разработка программ: принципы, примеры, практика [текст] / М. Роберт, Д. Ньюкирк; - Вильямс, 2004, 752 с. ISBN 5-8459-0558-3.

. Фолк Д. Тестирование программного обеспечения [текст] / Д. Фолк, Е. К. Нгуен, С. Канер; - Диасофт, 2003 , 400 с. ISBN 966-7393-87-9.

. Элфрид Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация [текст] / Элфрид Д., Джефф Р., Джон П.;- Лори, 2003, ISBN 5-85582-186-2.