Основы алгоритмизации и программирования

Содержание:

Введение

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

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

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

1. Основные понятия тестирования и отладки программного обеспечения 

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

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

В различных источниках, тестированию давались разные определения, в том числе:

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

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

Второй тип: динамический – предполагает непосредственный запуск программы, для проведения анализа поведения во время работы. Для выполнения динамического тестирования необходимо, чтобы код был записан, скомпилирован и запущен. Статическое и динамическое тестирование прекрасно дополняют друг друга при выявлении дефектов.

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

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

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

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

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

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

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

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

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

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

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

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

Отдельные модули тестирования можно разделить на следующие пункты:

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

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

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

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

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

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

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

1.3. Определение подхода к тестированию

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

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

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

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

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

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

2. Выбор и обоснование стратегии автоматизации.

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

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

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

2.1. Цели и задачи тестирования программного обеспечения

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

Задачи тестирования:

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

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

2.2. Методологии тестирования ПО

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

Каскадная модель – одна из самых старых моделей, применяемых те только в разработки, но и для тестирования программного обеспечения. Главной особенностью является последовательно в выполнении поставленной задачи. Иными словами, что перейти к следующему шагу до успешного завершения предыдущего не получится. Часто данная модель применяется при реализации небольших проектов, к главным плюсом этой модели можно отнести относительную дешевизну, простоту использования. Но помимо плюсов есть и недостатки, если при тестировании была обнаружена критическая ошибка, то это может повлечь за собой необходимость полностью изменять один из компонентов, что в каскадной модели запрещено. Рис 1.

Рис. 1. Каскадная модель.

V model – как и в случаи с каскадной моделью, методика основана на последовательности выполнения. Однако главным отличием является то, что тестирование идет параллельно со стадией разработки. Согласно этой методике тестирование можно начинать, как только становиться доступно статическое тестирование, что помогает предотвратить появление ошибок на поздней стадии разработки. Рисунок 2, изображенный ниже показывает принцип модели, которые разделены на две части.

Рис 2. V model

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

Рис 3. Инкрементная модель.

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

Рис. 4. Спиральная модель.

2.3. Комплексное тестирование программного обеспечения

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

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

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

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

2.4. Нисходящее и восходящее тестирование

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

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

Рис. 5. Методика нисходящего тестирования.

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

Рис. 5 Методика восходящего тестирования.

К преимуществам можно отнести сохранение и последовательное развитие данных.

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

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

3.1. Метод Сандвича

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

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

Модифицированный метод сандвича.

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

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

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

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

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

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

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

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

Исследуют структуры внутренних данных с целью проверки их достоверности.

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

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

Методы тестирования на основе стратегии белого ящика:

Ввод заведомо неверных значений. При вводе неверного значения специалист заставляет коды возврата показывать дефекты и смотрит на реакцию программного кода. Это простой и хороший способ моделирования определенных событий, которые могут возникнуть в процессе эксплуатации, например, нехватка памяти или переполнение диска. Популярным методом является замена alloc() функцией, которая возвращает значение NULL в 10% случаев с целью выяснения, сколько сбоев будет в результате. Такой подход еще называют тестированием ошибочных входных данных. При данном методе проверяется обработка как верный, так и не верных данных. Тестировщики могут выбрать значения, которые проверяют диапазон входных/выходных параметров, а также значения, выходящие за границу диапазона.

Модульное тестирование. При создании кода каждого модуля программного продукта проводится модульное тестирование для проверки того, что код работает верно и корректно реализует архитектуру. При модульном тестировании новый код проверяется на соответствие подробному описанию архитектуры; обследуются пути в коде, устанавливается, что экраны, ниспадающие меню и сообщения должным образом отформатированы; проверяются диапазон и тип вводимых данных, а также то, что каждый блок кода, когда нужно, генерирует исключения и возвращает ошибки (еггог returns). Данное тестирование программы проводится для того, чтобы проверить корректную работоспособность логики, алгоритмов и то, что модуль удовлетворяет предъявленным требованием, обеспечивая при этом необходимую функциональность. По итогам модульного тестирования фиксируются ошибки, относящиеся к логике программы, перегрузке и выходу из диапазона, времени работы и утечке памяти.

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

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

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

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

Исследование покрытия. При выборе инструмента для исследования покрытия важно, чтобы группа тестирования проанализировала тип покрытия, необходимый для приложения. Исследование покрытия можно провести с помощью различных технологий. Метод покрытия операторов часто называют С1, что также означает покрытие узлов. Эти измерения показывают, был ли проверен каждый исполняемый оператор. Данный метод тестирования обычно использует программу протоколирования (profiler) производительности.

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

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

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

Тестирование на основе стратегии черного ящика возможно лишь при наличии установленных открытых интерфейсов, таких как интерфейс пользователя или программный интерфейс приложения (API). Если тестирование на основе стратегии белого ящика исследует внутреннюю работу программы, то методы тестирования черного ящика сравнивают поведение приложения с соответствующими требованиями. Кроме того, эти методы обычно направлены на выявление трех основных видов ошибок: функциональности, поддерживаемой программным продуктом; производимых вычислений; допустимого диапазона или области действия значений данных, которые могут быть обработаны программным продуктом. На этом уровне тестировщики не исследуют внутреннюю работу компонентов программного продукта, тем не менее они проверяются неявно. Группа тестирования изучает входные и выходные данные программного продукта. В этом ракурсе тестирование с помощью методов черного ящика рассматривается как синоним тестирования на уровне системы, хотя методы черного ящика могут также применяться во время модульного или компонентного тестирования.

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

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

Неверная или пропущенная функциональность

Ошибки интерфейса

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

Методы тестирования на основе Автоматизированные инструменты

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

Проблемы снижения производительности и другие ошибки производительности

Ошибки загрузки

Ошибки многопользовательского доступа

Ошибки инициализации и завершения

Проблемы сохранения резервных копий и способности к восстановлению работы

Проблемы безопасности

Методы тестирования на основе стратегии черного ящика

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

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

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

Диаграммы причинно-следственных связей. Составление диаграмм причинно-следственных связей - это метод, дающий четкое представление о логических условиях и соответствующих действиях. Метод предполагает четыре этапа. Первый этап заключается в составлении перечня причин (условий ввода) и следствий (действий) для модуля и в присвоении идентификатора каждому модулю. На втором этапе разрабатывается диаграмма причинно-следственных связей. На третьем этапе диаграмма преобразуется в таблицу решений. Четвертый этап включает в себя установление причин и следствий в процессе чтения спецификации функций. Каждой причине и следствию присваивается собственный идентификатор. Причины перечисляются в столбике с левой стороны листа бумаги, а следствия - с правой. Затем причины и следствия соединяются линиями так, чтобы были отражены имеющиеся между ними соответствия. На диаграмме проставляются булевы выражения, которые объединяют две или более причин, связанных со следствием. Далее правила таблицы решений преобразуются в тестовые процедуры.

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

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

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

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

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

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

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

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

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

Ручное тестирование;

Прологи;

Снижения;

Обратная трассировка.

Метод ручного тестирования.

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

3.5. Метод пролога.

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

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

3.6. Метод снижения.

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

Метод обратной трассировки.

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

Заключение

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

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

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

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

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

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

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

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

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

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

7. Г. Майерс, Том Баджетт, Кори Сандлер. Искусство тестирования программ, 3-е издание = The Art of Software Testing, 3rd Edition. — М.: «Диалектика», 2012. — 272 с. — ISBN 978-5-8459-1796-6.

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

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

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