Тестирование и отладка программного обеспечения - Программирование, компьютеры и кибернетика курсовая работа

Главная

Программирование, компьютеры и кибернетика
Тестирование и отладка программного обеспечения

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


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

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

1. Понятия тестирования и отладки программного обеспечения
1.1 Принципы тестирование и отладка программного обеспечения
1.2 Этапы тестирования программного обеспечения
1.3 Цели и задачи тестирования программного обеспечения
1.4 Комплексное тестирование программного обеспечения
1.5 Восходящее и нисходящее тестирование
2. Стратегия тестирования и отладки программного обеспечения
2.4 Метод отладки программного обеспечения
История тестирования программного обеспечения отражает эволюцию разработки самого программного обеспечения. В течение длительного времени разработка программного обеспечения уделяла основное внимание крупномасштабным научным программам, а также программам министерства обороны, связанным с системами корпоративных баз данных, которые проектировались на базе универсальной ЭВМ или миникомпьютера. Тестовые сценарии записывались на бумагу. С их помощью проверялись целевые потоки управления, вычисления сложных алгоритмов и манипулирование данными. Окончательный набор тестовых процедур мог эффективно протестировать всю систему полностью. Тестирование обычно начиналось лишь после завершения плана-графика проекта и выполнялось тем же персоналом.
Появление персональных компьютеров способствовало стандартизации этой отрасли, поскольку приложения стали изначально создаваться для работы с общей операционной системой. Внедрение персональных компьютеров открыло новую эру и привело к быстрому и бурному росту коммерческих разработок. Коммерческие приложения жестко боролись за первенство и выживание. Пользователи компьютеров принимали выжившее программное обеспечение как стандарты defacto. Пакетная обработка заменялась системами, работающими в реальном времени.
Тестирование систем реального времени потребовало другого подхода к проектированию тестирования из-за того, что рабочие потоки могли вызываться в любом порядке. Эта особенность привела к появлению огромного количества процедур тестирования, способных поддержать бесконечное число перестановок и сочетаний.
Причиной многих несчастий разработчиков являются программные ошибки, из-за которых на их многострадальные головы сваливаются и давно просроченные проекты, и бессонные ночи. Ошибки могут сделать жизнь разработчиков действительно несчастной, потому что, достаточно нескольким ошибкам вкрасться в их программы, как заказчики прекращают этими программами пользоваться, а сами они могут потерять работу.
Долгое время ошибки рассматривали как простые неприятности. Ничто не может быть дальше от истины. Всем программистам известны компании, которые закрылись только потому, что выпускали программные продукты, совершенно непригодные к использованию из-за обилия ошибок. В связи со всеобщей компьютеризацией, все шире и шире захватывающей такие важные области, как управление системами жизнеобеспечения, медицинские приборы и сверхдорогую компьютерную аппаратуру, над ошибками больше нельзя просто посмеиваться или рассматривать их как нечто имеющее значение только на этапах разработки.
На отладку в среднем затрачивается около 50% цикла разработки. Если отладка начата вовремя, то ее продолжительность может быть радикально уменьшена, а это означает, что заказчик получит программу значительно быстрее. Нельзя экономить время на рассмотрении требований и проектировании, но можно сделать отладку намного эффективнее. Отладку нужно начинать на стадии разработки требований и продолжать до финальной версии продукта.
1 . Понятия тестирования и отладки программного обеспечения
1.1 Принципы тестирование и отладка программного обеспечения
Тестирование программного обеспечения (software testing)- это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов.
Несмотря на всю простоту этого определения, в нем содержатся пункты, которые требуют дальнейших пояснений. Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование суть плановая, упорядоченная деятельность. Этот момент очень важен, если мы заинтересованы в быстрой разработке, ибо хорошо продуманный, систематический подход быстрее приводит к обнаружению программных ошибок, чем плохо спланированное тестирование, к тому же проводимое в спешке.
Согласно этому определению, тестирование предусматривает "анализ" или "эксплуатацию" программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программного обеспечения, называется статическим тестированием (static testing). Статическое тестирование предусматривает проверку программных кодов, сквозной контроль и проверку программы без запуска па машине, т.е. проверку за столом (desk checks). В отличие от этого, тестовая деятельность, предусматривающая эксплуатацию программного продукта, носит название динамического тестирования (dynamic testing). Статическое и динамическое тестирование дополняют друг друга, и каждый из этих типов тестирования реализует собственный подход к выявлению ошибок.
Последний пункт определения, требующий дополнительных пояснений - это понятие дефекта (bug). Говоря простыми словами, программная ошибка - не что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов. Дефект может возникнуть на стадии кодирования, на стадии формулирования требований или на стадии проектирования, либо же его причина может крыться в некорректной конфигурации или данных. Дефектом может быть также что-то другое, что не соответствует ожиданиям заказчика и что может быть, а может и не быть определено в спецификации программного продукта. Более подробное описание терминологии дефектов приводится во врезке.
Отладка - это процесс выявления источников отказов, т.е. ошибок, и внесение в программу соответствующих исправлений.
1.2 Этапы тестирования программного обеспечения
Первое действие в планировании испытаний предусматривает разработку стратегии тестирования на высоком уровне. В общем случае стратегия тестирования должна определять объемы тестовых работ, типы методик тестирования, которые должны применяться для обнаружения дефектов, процедуры, уведомляющие об обнаружении и устраняющие дефекты, критерии входа и выхода из испытаний, которые управляют различными видами тестирования. Реализуя принцип тесного интегрирования разработки и тестирования с целью оптимизации графика разработки, стратегия тестирования должна отображать различные виды тестовой деятельности на жизненный цикл разработки. При формулировании общей стратегии должно быть предусмотрено как статическое, так и динамическое тестирование.
Если для поддержки различных видов тестовой деятельности используется автоматизация, стратегия автоматизации должна рассматриваться как составная часть общей стратегии тестирования. Автоматизация требует выполнения независимых параллельных работ, которые должны тщательно планироваться и выполняться только в тех случаях, когда это не приводит к снижению эффективности.
Существуют следующие подходы к формулированию стратегии тестирования:
1. Определить объемы тестовых работ путем анализа документов, содержащих требования к программному продукту (технические условия), чтобы выяснить, что нужно тестировать. Рассмотреть виды тестирования, которые не следуют непосредственно из документов с требованиями, такие как тестирование возможности установки и наращивания возможностей программного продукта, удобство и простота обслуживания продукта, а также способности к взаимодействию с другими видами аппаратных средств из среды заказчика.
2. Определить подход к тестированию за счет выбора статических и динамических тестов, связанных с каждой стадией разработки. Здесь потребуется включить описания всех рабочих продуктов, которые должна подготовить тестовая группа.
3. Определить критерии входа и выхода для каждой стадии тестирования, равно как и все точки контроля качества, для чего потребуется участие специалистов по тестированию.
4. Определить стратегию автоматизации в случае, если планируется использование автоматизации какого-либо вида тестовой деятельности. Автоматизация требует проведения независимых параллельных работ, которые должны тщательно планироваться и выполняться только в тех случаях, когда это не приводит к снижению эффективности.
Поскольку подвергнуть тестированию абсолютно все невозможно, важность выбора того, что нужно протестировать, сомнений не вызывает. Если допустить "перебор" в тестировании, т.е., если тестовое покрытие будет избыточным, то для отладки программного продукта потребуется значительное время, что поставит под угрозу срок сдачи проекта. Если тестирование окажется недостаточным (точнее, недостаточным будет тестовое покрытие), то увеличится риск пропуска того или иного дефекта, устранение которого будет стоить очень дорого, особенно после сдачи программного продукта в эксплуатацию. Отыскать нужный баланс между этими двумя крайностями поможет опыт и способ измерения успешности тестирования.
Вот несколько предложений по разработке стратегии тестирования, которые помогут в поиске оптимального тестового покрытия:
Тестировать в первую очередь требования с наивысшим приоритетом.
Тестировать новые функциональные возможности и программный код, который изменялся с целью исправления или совершенствования старых функциональных средств
Использовать разбиение на эквивалентные классы и анализ граничных значений для снижения трудозатрат на тестирование
Тестировать те участки, в которых наиболее вероятно присутствие проблем
Сосредоточить свое внимание на функциях и конфигурациях, с которыми наиболее часто будет иметь дело конечный пользователь.
Второй раздел формулировки стратегии тестирования касается определения похода к тестированию. Построение подхода к тестированию начинается с исследования каждой стадии жизненного цикла разработки с целью отбора тестов статического и динамического тестирования, которые могут быть использованы на соответствующей стадии. При этом не имеет значения, какая модель жизненного цикла разработки используется: каскадная, спиралевидная или модель с итеративными версиями - для отбора эффективных тестов можно исследовать этапы любой перечисленной модели. В качестве примера возьмем каскадную модель и выясним, какие виды тестирования могут для нее использоваться:
Стадии тестирования проектов программ, программных кодов, модульного тестирования и комплексных испытаний
Подход к тестированию должен отражаться в документах, содержащих планы проведения испытаний.
Определение критериев тестирования и точек контроля качества
Существует пять типов критериев, которые могут определяться перед началом системного тестирования:
Критерий входа. Описывает, что нужно сделать перед началом тестирования.
Критерий выхода. Описывает то, что вы считается необходимым для завершения испытаний.
Критерий приостановки/возобновления. Описывает, что произойдет, если по причине из-за дефектов продолжение тестирования окажется невозможным.
Критерий успешного/неудачного прохождения теста. Прогон каждого теста должен давать заранее известные результаты.
Другие критерии, определяемые процессом или стандартами. Если программный продукт должен соответствовать некоторому стандарту или компания предъявляет определенные требования к выполняемому процессу, то, нужно учесть ряд дополнительных критериев.
Определение стратегии автоматизации.
При наличии реальных планов и разумных предположений использование автоматизированных инструментальных средств и автоматизированных тестовых случаев представляет собой прекрасный способ снижения временных затрат на тестирование программного продукта. Любая многократно выполняемая задача является кандидатом на автоматизацию. Однако обычно на автоматизацию задачи уходит намного больше времени, чем на ее выполнение, поэтому для каждой задачи, которая может быть автоматизирована, целесообразно провести тщательный анализ потенциального выигрыша от автоматизации. Выполняя анализ возможных выгод, следует помнить, что для самой автоматизации характерен собственный автономный жизненный цикл.
Эффективная автоматизация требует специальной подготовки персонала, разработки, отладки и верификации, как и любой другой проект разработки программного обеспечения. Бесплановая и плохо выполненная автоматизация означает не только напрасный расход ресурсов, она даже может привести к нарушению графика выполняемых работ, если время будет тратиться на отладку средств автоматизации, а не на тестирование.
1.3 Цели и задачи тестирования программного обеспечения
Повысить вероятность того, что приложение, предназначенное для тестирования, будет работать правильно при любых обстоятельствах.
Повысить вероятность того, что приложение, предназначенное для тестирования, будет соответствовать всем описанным требованиям.
Провести полное тестирование приложения за короткий срок.
Проверить, что система работает в соответствии с определенными временами отклика клиента и сервера.
Проверить, что наиболее критические последовательности действий с системой конечного пользователя выполняются верно.
Проверить работу пользовательских интерфейсов
Проверить, что изменения в базах данных не оказывают неблагоприятного влияния на существующие программные модули.
При проектировании тестов свести к минимуму переработку тестов при возможных изменениях приложения.
Использовать инструменты автоматизированного тестирования там, где это целесообразно.
Проводить тестирование таким образом, чтобы не только обнаруживать, но и предупреждать дефекты.
При проектировании автоматизированных тестов использовать стандарты разработки таким образом, чтобы создать многократно используемые и сопровождаемые скрипты.
1.4 Комплексное тестирование программного обеспечения
Целью комплексного тестирования является проверка того, что каждый модуль программного продукта корректно согласуется с остальными модулями продукта. При комплексном тестировании может использоваться технология обработки сверху вниз и снизу вверх, при которой каждый модуль, являющийся листом в дереве системы, интегрируется со следующим модулем более низкого или более высокого уровня, пока не будет создано дерево программного продукта. Эта технология тестирования направлена на проверку не только тех параметров, которые передаются между двумя компонентами, но и на проверку глобальных параметров и, в случае объектно-ориентированного приложения, всех классов верхнего уровня.
Каждая процедура комплексного тестирования состоит из тестовых скриптов верхнего уровня, которые моделируют выполнение пользователем определенного задания, применяя модульные тесты нижнего уровня с необходимыми параметрами для проверки интерфейса. После принятия решений по поводу всех отчетов о проблемах модульного тестирования модули объединяются инкрементно и тестируются уже совместно на основе управляющей логики. Поскольку модули могут состоять из других модулей, часть работы по комплексному тестированию может быть проведена во время модульного тестирования. В случае если скрипты для модульного тестирования были созданы с помощью инструментов автоматизированного тестирования, их можно объединить и добавить новые скрипты для тестирования межмодульных связей.
Процедуры комплексного тестирования выполняются и должным образом уточняются, отчеты о проблемах документируются и отслеживаются. Отчеты о проблемах, как правило, классифицируют в зависимости от степени их серьезности в диапазоне от 1 до 4 (1 является наиболее, 4 - наименее критическим). После обработки этих отчетов тестировщик проводит регрессионное тестирование для проверки того, что проблемы полностью устранены.
1 . 5 Восходящее и нисходящее тестирование
Восходящее тестирование - это прекрасный способ локализации ошибок. Если ошибка обнаружена при тестировании единственного модуля, то очевидно, что она содержится именно в нем - для поиска ее источника не нужно анализировать код всей системы. А если ошибка проявляется при совместной работе двух предварительно протестированных модулей, значит, дело в их интерфейсе. Еще одним преимуществом восходящего тестирования является то, что выполняющий его программист концентрируется на очень узкой области (единственном модуле, передаче данных между парой модулей и т.п.). Благодаря этому тестирование проводится более тщательно и с большей вероятностью выявляет ошибки.
Главным недостатком восходящего тестирования является необходимое написания специального кода-оболочки, вызывающего тестируемый модуль. Если он, в свою очередь, вызывает другой модуль, для него нужно написать «заглушку». Заглушка - это имитация вызываемой функции, возвращающая те же данные, но ничего больше не делающая.
Понятно, что написание оболочек и заглушек замедляет работу, а для конечного продукта они абсолютно бесполезны. Но написанные однажды, ни элементы могут использоваться повторно при каждом изменении про-флммы. Хороший набор оболочек и заглушек - это очень эффективный инструмент тестирования.
В противоположность восходящему тестированию, стратегия целостного тестирования предполагает, что до полной интеграции системы ее отдельные модули не проходят особо тщательного тестирования.
Преимуществом такой стратегии является то, что нет необходимости в написании дополнительного кода. Поэтому многие руководители выбирают этот способ из соображений экономии времени - они считают, что лучше разработать один обширный набор тестов и с его помощью за один раз проверить всю систему. Но такое представление совершенно ошибочно, и вот почему.
* Очень трудно выявить источник ошибки. Это главная проблема. Поскольку ни один из модулей не проверен как следует, в большинстве из них есть ошибки. Получается, что вопрос не столько в том, в каком модуле произошла обнаруженная ошибка, сколько в том, какая из ошибок во всех вовлеченных в процесс модулях привела к полученному результату. И когда накладываются ошибки нескольких модулей, ситуацию может быть гораздо труднее локализовать и повторить.
Кроме того, ошибка в одном из модулей может блокировать тестирование другого. Как протестировать функцию, если вызывающий ее модуль не работает? Если не написать для этой функции программу-оболочку, придется ждать отладки модуля, а это может затянуться надолго.
* Трудно организовать исправление ошибок. Если программу пишут несколько программистов (а именно так и бывает в больших системах), и при этом неизвестно, в каком модуле ошибка, кто же будет ее искать и исправлять? Один программист будет указывать на другого, тот, выяснив, что его код ни при чем, снова обратится к первому, а в результате будет сильно страдать скорость разработки.
* Процесс тестирования плохо автоматизирован. То, что на первый взгляд кажется преимуществом целостного тестирования - отсутствие необходимости писать оболочки и заглушки, - на самом деле оборачивается его недостатком. В процессе разработки программа ежедневно меняется, и ее приходится тестировать снова и снова. А оболочки и заглушки помогают автоматизировать этот однообразный труд.
Существует и еще один принцип организации тестирования, при котором программа так же, как и при восходящем способе, тестируется не целиком, а по частям. Только направление движения меняется - сначала тестируется самый верхний уровень иерархии модулей, а от него тестировщик постепенно спускается вниз. Такая технология называется нисходящей (top-down). Обе технологии - и нисходящую и восходящую - называют также инкрементальными.
При нисходящем тестировании отпадает необходимость в написании оболочек, но заглушки остаются. По мере тестирования заглушки по очереди заменяются на реальные модули.
Мнения специалистов о том, какая из двух инкрементальных стратегий тестирования более эффективна, сильно расходятся. На практике вопрос выбора стратегии тестирования обычно решается просто: каждый модуль по возможности тестируется сразу после его написания, в результате последовательность тестирования одних частей программы может оказаться восходящей, а других - нисходящей.
2 . Стратегия тестирования и отладки программного обеспечения
Тестирование методом сандвича представляет собой компромисс между восходящим и нисходящим подходами. Здесь делается попытка воспользоваться достоинствами обоих методов, избежав их недостатков. При использовании этого метода одновременно начинают восходящее и нисходящее тестирование, собирая программу как снизу, так и сверху и встречаясь в конце концов где-то в середине. Точка встречи зависит от конкретной тестируемой программы и должна быть заранее определена при изучении ее структуры. Например, если разработчик может представить свою систему в виде уровня прикладных модулей, затем уровня модулей обработки запросов, затем уровня примитивных функций, то он может решить применять нисходящий метод на уровне прикладных модулей (программируя заглушки вместо модулей обработки запросов), а на остальных уровнях применить восходящий метод. Применение метода сандвича - это разумный подход к интеграции больших программ, таких, как операционная система или пакет прикладных программ.
Метод сандвича сохраняет такое достоинство нисходящего и восходящего подходов, как начало интеграции системы на самом раннем этапе. Поскольку вершина программы вступает в строй рано, мы, как в нисходящем методе, уже на раннем этапе получаем работающий каркас программы. Поскольку нижние уровни программы создаются восходящим методом, снимаются те проблемы нисходящего метода, которые были связаны с невозможностью тестировать некоторые условия в глубине программы.
При тестировании методом сандвича возникает та же проблема, что и при нисходящем подходе, хотя здесь она стоит не так остро. Проблема эта в том, что невозможно досконально тестировать отдельные модули. Восходящий этап тестирования по методу сандвича решает эту проблему для модулей нижних уровней, но она может по-прежнему оставаться открытой для нижней половины верхней части программы. В модифицированном методе сандвича нижние уровни также тестируются строго снизу вверх. А модули верхних уровней сначала тестируются изолированно, а затем собираются нисходящим методом. Таким образом, модифицированный метод сандвича также представляет собой компромисс между восходящим и нисходящим подходами.
Термин "белый ящик" означает, что при разработке тестовых случаев тестировщики используют любые доступные сведения о внутренней структуре или коде. Технологии, применяемые во время тестирования "белого ящика", обычно называют технологиями статического тестирования.
Этот метод не ставит цели выявление синтаксических ошибок, так как дефекты такого рода обычно обнаруживает компилятор. Методы белого ящика направлены на локализацию ошибок, которые сложнее выявить, найти и зафиксировать. С их помощью можно обнаружить логические ошибки и проверить степень покрытия тестами.
Тестовые процедуры, связанные с использованием стратегии белого ящика, используют управляющую логику процедур. Они предоставляют ряд услуг, в том числе:
1. Дают гарантию того, что все независимые пути в модуле проверены по крайней мере один раз.
2. Проверяют все логические решения на предмет того, истины они или ложны.
3. Выполняют все циклы внутри операционных границ и с использованием граничных значений.
4. Исследуют структуры внутренних данных с целыо проверки их достоверности.
Тестирование посредством белого ящика, как правило, включает в себя стратегию модульного тестирования, при котором тестирование ведется на модульном или функциональном уровне и работы по тестированию направлены на исследование внутреннего устройства модуля. Данный тип тестирования называют также модульным тестированием, тестированием прозрачного ящика (clear box) или прозрачным (translucent) тестированием, поскольку сотрудники, проводящие тестирование, имеют доступ к программному коду и могут видеть работу программы изнутри. Данный подход к тестированию известен также как структурный подход.
На этом уровне тестирования проверяется управляющая логика, проявляющаяся на модульном уровне. Тестовые драйверы используются для того, чтобы все пути в данном модуле были проверены хотя бы один раз, все логические решения рассмотрены во всевозможных условиях, циклы были выполнены с использованием верхних и нижних границ и роконтролированы структуры внутренних данных.
Методы тестирования на основе стратегии белого ящика:
Ввод неверных значений. При вводе неверных значений тестировщик заставляет коды возврата показывать ошибки и смотрит на реакцию кода. Это хороший способ моделирования определенных событий, например переполнения диска, нехватки памяти и т.д. Популярным методом является замена alloc() функцией, которая возвращает значение NULL в 10% случаев с целью выяснения, сколько сбоев будет в результате. Такой подход еще называют тестированием ошибочных входных данных. При таком тестировании проверяется обработка как верных, так и неверных входных данных. Тестировщики могут выбрать значения, которые проверяют диапазон входных/выходных параметров, а также значения, выходящие за границу диапазона.
Модульное тестирование. При создании кода каждого модуля программного продукта проводится модульное тестирование для проверки того, что код работает верно и корректно реализует архитектуру. При модульном тестировании новый код проверяется на соответствие подробному описанию архитектуры; обследуются пути в коде, устанавливается, что экраны, ниспадающие меню и сообщения должным образом отформатированы; проверяются диапазон и тип вводимых данных, а также то, что каждый блок кода, когда нужно, генерирует исключения и возвращает ошибки (еггог returns). Тестирование каждого модуля программного продукта проводится для того, чтобы проверить корректность алгоритмов и логики и то, что программный модуль удовлетворяет предъявляемым требованиям и обеспечивает необходимую функциональность. По итогам модульного тестирования фиксируются ошибки, относящиеся к логике программы, перегрузке и выходу из диапазона, времени работы и утечке памяти.
Тестирование обработки ошибок. При использовании этого метода признается, что нереально на практике проверить каждое возможное условие возникновения ошибки. По этой причине программа обработки ошибок может сгладить последствия при возникновении неожиданных ошибок. Тестировщик обязан убедиться в том, что приложение должным образом выдает сообщение об ошибке. Так, приложение, которое сообщает о системной ошибке, возникшей из-за промежуточного программного обеспечения представляет небольшую ценность, как для конечного пользователя, так и для тестировщика.
Утечка памяти. При тестировании утечки памяти приложение исследуется с целью обнаружения ситуаций, при которых приложение не освобождает выделенную память, в результате чего снижается производительность или возникает тупиковая ситуация. Данная технология применяется как для тестирования версии приложения, так и для тестирования готового программного продукта. Возможно применение инструментов тестирования. Они могут следить за использованием памяти приложения в течение нескольких часов или даже дней, чтобы проверить, будет ли расти объем используемой памяти. С их помощью можно также выявить те операторы программы, которые не освобождают выделенную память.
Комплексное тестирование. Целью комплексного тестирования является проверка того, что каждый модуль программного продукта корректно согласуется с остальными модулями продукта. При комплексном тестировании может использоваться технология обработки сверху вниз и снизу вверх, при которой каждый модуль, являющийся листом в дереве системы, интегрируется со следующим модулем более низкого или более высокого уровня, пока не будет создано дерево программного продукта. Эта технология тестирования направлена на проверку не только тех параметров, которые передаются между двумя компонентами, но и на проверку глобальных параметров и, в случае объектно-ориентированного приложения, всех классов верхнего уровня.
Тестирование цепочек. Тестирование цепочек подразумевает проверку группы модулей, составляющих функцию программного продукта. Эти действия известны еще как модульное тестирование, с его помощью обеспечивается адекватное тестирование компонентов системы. Данное тестирование выявляет, достаточно ли надежно работают модули для того, чтобы образовать единый модуль, и выдает ли модуль программного продукта точные и согласующиеся результаты.
Исследование покрытия. При выборе инструмента для исследования покрытия важно, чтобы группа тестирования проанализировала тип покрытия, необходимый для приложения. Исследование покрытия можно провести с помощью различных технологий. Метод покрытия операторов часто называют С1, что также означает покрытие узлов. Эти измерения показывают, был ли проверен каждый исполняемый оператор. Данный метод тестирования обычно использует программу протоколирования (profiler) производительности.
Покрытие решений. Метод покрытия решений направлен на определение (в процентном соотношении) всех возможных исходов решений, которые были проверены с помощью комплекта тестовых процедур. Метод покрытия решений иногда относят к покрытию ветвей и называют С2. Он требует: чтобы каждая точка входа и выхода в программе была достигнута хотя бы единожды, чтобы все возможные условия для решений в программе были проверены не менее одного раза и чтобы каждое решение в программе хотя бы единожды было протестировано при использовании всех возможных исходов.
Покрытие условий. Покрытие условий похоже на покрытие решений. Оно направлено на проверку точности истинных или ложных результатов каждого логического выражения. Этот метод включает в себя тесты, которые проверяют выражения независимо друг от друга. Результаты этих проверок аналогичны тем, что получают при применении метода покрытия решений, за исключением того, что метод покрытия решений более чувствителен к управляющей логике программы.
Тестирование на основе стратегии черного ящика возможно лишь при наличии установленных открытых интерфейсов, таких как интерфейс пользователя или программный интерфейс приложения (API). Если тестирование на основе стратегии белого ящика исследует внутреннюю работу программы, то методы тестирования
Тестирование и отладка программного обеспечения курсовая работа. Программирование, компьютеры и кибернетика.
Реферат по теме Беременность: первый период первых срочных родов
Реферат Введение Предприятия
Реферат: Поняття та види угод
Реферат: Компания Borland Software Corporation. Скачать бесплатно и без регистрации
Реферат На Тему Формирование Правильной Осанки
Дипломная работа по теме Политика управления оборотным капиталом (на примере ООО 'Башкирпродторг')
Предпринимательская Деятельность Как Источник Благосостояния Реферат
Курсовая Работа Страховая Компания
Реферат: Основные свойства и материалы упругих элементов. Винтовые пружины
Дипломная работа по теме Психологические и психофизиологические аспекты патогенеза пневмонии у подростков
Артрит Особенности Тренировок Дипломная Работа
Реферат: Articles Of Confederation Essay Research Paper From
Курсовая работа: Предложение на рынке услуг. Лечебно-диагностический центр "Эдельвейс". Скачать бесплатно и без регистрации
Декабрьское Сочинение Темы И Произведения
Сочинение По Русскому Отцы И Дети
Реферат по теме Развитие рекреационного хозяйства Украины на примере Крыма
Реферат: Конституція УРСР 1978 р
Контрольная работа по теме Аварии и катастрофы на транспорте
Дипломная работа по теме СВЧ диагностика газового разряда
Реферат по теме Социально-психологический климат в трудовом коллективе
Проектирование сети сигнализации, работающей по протоколу ОКС № 7 - Коммуникации, связь, цифровые приборы и радиоэлектроника курсовая работа
Сертификация электронного устройства - Коммуникации, связь, цифровые приборы и радиоэлектроника курсовая работа
Україна в 20-х - 30-х роках XX сторіччя - История и исторические личности доклад