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

Содержание:

Введение

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

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

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

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

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

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

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

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

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

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

Согласно данному определению, тест включает в себя "анализ^[2]" программного продукта. Тестовые мероприятия, связанные с анализом результатов разработки программного обеспечения, называется статическое тестирование. Статическое тестирование включает в себя проверку программных кодов, посредством контроля и проверки программы без запуска на машине. Разница в том, что тестовая деятельность предполагает эксплуатацию программного продукта и называется динамическим тестированием. Статические и динамические тестирования дополняют друг друга, и каждый из этих видов тестирования реализует свой собственный подход к обнаружению ошибок.

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

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

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

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

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

Существуют следующие подходы к разработке стратегии тестирования (рис. 1):

Рис.1. Подходы к разработке тестирования

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

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

3. Определение критериев входа и выхода для каждой стадии тестирования^[7], а также все точки контроля качества, что потребует участия экспертов в тестировании.

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

Определение объема тестовых операций

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

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

Чтобы проверить, первое требование с наивысшим приоритетом.

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

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

Проверка областей, в которых наиболее вероятно наличие проблем.

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

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

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

Этап формулировки требований^[10]

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

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

тестирование системы^[11]

Приемочное тестирование

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

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

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

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

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

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

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

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

Другие критерии определяются процессом или стандартами. Если программный продукт^[12] должен удовлетворять определенным стандартам или компания предъявляет требования, то вам необходимо рассмотреть ряд дополнительных критериев. Наличие реальных планов и разумных предположений с использованием автоматизированных средств тестирования, является отличным способом уменьшить время, затраченное на тестирование программного продукта. Любая задача^[13], выполняемая многократно, является кандидатом для автоматизации. Обычно автоматизация задач занимает гораздо больше времени, чем её выполнение, так что каждая задача, которая может быть автоматизирована, то целесообразно провести тщательный анализ потенциальных выгод от автоматизации. Во время выполнения анализа возможных преимуществ, следует помнить, что для большинства автоматизаций характеризуется своей собственный автономной жизненного цикл. Эффективная автоматизация требует специальной подготовки персонала, разработки, отладки и верификации, а также любой другой разработки программного обеспечения. Незапланированная и плохо выполненная автоматизация не только тратит ресурсы, но также приводит к нарушению графика работ, подлежащих выполнению, время будет потрачено на отладку автоматизации, а не на тестирование.

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

Цели тестирования (рис. 2):

Рис. 2. Цели тестирования

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

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

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

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

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

Чтобы проверить работу пользовательских интерфейсов

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

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

Использовать средства автоматического тестирования^[14], где это необходимо.

Чтобы таким образом не только обнаруживать, но и предотвращать появление дефектов^[15].

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

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

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

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

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

5. Восходящее и нисходящее тестирование

Восходящее тестирование является отличным способом обнаружения ошибок. Если ошибка обнаружена при тестировании единственного модуля, то очевидно, что она содержится в нем, для того чтоб найти источник^[17] не нужно анализировать код всей системы. Но если ошибка появляется в совместной работе двух предварительно протестированных модулей, значит дело в их интерфейсе. Еще одним преимуществом восходящего тестирования^[18] является то, что программист фокусируется на очень узкой области (один модуль, передачи данных между парой модулей и т.д.). В связи с этим, тестирование проводится более тщательно и с большей вероятностью обнаружения ошибок.

Основным недостатком восходящего тестирования требуется написание кода оболочки, который вызывает тестовый модуль. Если он, в свою очередь, вызывает еще один модуль, мы должны написать "заглушку^[19]". Заглушка представляет собой моделирование функции для вызова, который возвращает те же данные, но ничего не делает.

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

В отличие от восходящего тестирования, целостное тестирование предполагает, что до полной интеграции системы отдельные модули не проходят тщательное тестирования.

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

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

Кроме того, ошибка в одном модуле может блокировать тестирование другого. Как проверить функцию, если вызывающий её модуль не работает^[20]? Если вы не пишете для этой функции программы - оболочки^[21] придется ждать отладки модуля, и это может занять много времени.

• Трудно обеспечить исправление ошибок^[22], если программу написали несколько программистов (именно это происходит в больших системах), и неизвестно, какой модуль с ошибкой, кто собирается её искать и исправлять? Один программист будет ссылаться на другого и говорить, что его код не причём, тот в свою очередь будет ссылаться на первого и в результате всего этого будет большая потеря времени.

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

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

При нисходящем тестировании нет необходимости писать оболочки, но заглушки остаются. В процессе тестирования заглушки заменяются реальными модулями^[23].

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

Вывод:

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

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

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

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

Подходы к разработке тестирования: а) определение объёма работ на основе анализа документов, б) выбор статических и динамических испытаний, в) определение критериев входа и выхода, г) определение стратегии автоматизации.

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

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

Цель комплексного тестирования состоит в проверке каждого модуля про-рамного продукта, правильно согласующегося с другими модулями продукта.

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

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

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

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

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

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

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

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

2. Метод «белого ящика^[27]»

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

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

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

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

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

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

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

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

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

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

Методы тестирования на основе белого ящика (рис. 3.)^[30]:

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

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

Модульное тестирование. Если вы пишете код для каждого модуля в исполнении модульного тестирования программного продукта, для того чтобы проверить работу корректности кода и правильность реализуемой архитектуры. Для модульного тестирования^[32], новый код проверяется на предмет соответствия с подробным описанием архитектуры; обследуется путь в коде, определяется, что экраны в раскрывающемся меню и сообщения в надлежащем формате; проверил диапазон и тип входных данных, а также то, что каждый кодовый блок, в случае необходимости, генерирует исключение и возвращает ошибки. Тестирование каждого модуля программного обеспечения осуществляется для того, чтобы проверить правильность алгоритмов и логики, что программный модуль удовлетворяет требованиям и обеспечивает требуемую функциональность. По результатам модульного тестирования, фиксируются ошибки, связанные с логическими программами, перегрузкой и выходом из диапазона, а также утечкой памяти.

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

Утечка памяти^[33]. При проверке утечки памяти, приложение^[34] рассматривается для обнаружения ситуаций, когда приложение не освобождает выделенную память, что приводит к снижению производительности или тупиковой ситуации. Эта технология используется для тестовой версии приложения, а также для тестирования готового программного продукта. Возможно использование инструментов тестирования. Они могут контролировать использование памяти приложения в течение нескольких часов или даже дней, чтобы проверить, будет ли расти память. Они могут быть использованы для идентификации тех операторов программы, которые не освобождают распределенную память.

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

Тестирование цепочек. Тестирование цепочек включает в себя проверку группы модулей, составляющие функционирование программного обеспечения. Эти шаги, известны ещё как модульное тестирование, оно обеспечивает адекватное тестирование компонентов системы. Это тестирование показывает, достаточна ли надежность работы модулей, чтобы сформировать единый модуль, который делает точные и согласующиеся расчёты для программного продукта. При выборе инструмента для исследования покрытия важно, что команда тестирования проанализировала тип покрытия, необходимого для приложения. Изучение покрытия может быть осуществлено с использованием различных технологий. Метод покрытия операторов часто называют С1, что также означает охват узлов. Эти измерения показывают, проверен ли каждый исполняемый оператор^[36]. Такой способ тестирования обычно использует программу протоколирования производительности.

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

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

3. Метод «черного ящика^[37]»

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

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

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

Неправильные или отсутствующие функциональные возможности

Ошибки интерфейса^[39]

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

Методы тестирования на основе автоматизированных инструментов^[40]

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

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

Ошибка^[41] загрузки

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

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

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

Проблемы с безопасностью^[42]

Методы тестирования на основе стратегии чёрного ящика (рис.5).

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

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

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

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

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

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

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

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

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

Тестирование перегрузок. Во время тестирования перегрузок системы определяются технические ограничения системы без учёта архитектуры. Эти испытания проводятся на пике обработки транзакций и при непрерывной загрузке больших объемов данных. Тестирование перегрузок просчитывает пропускную способность системы и ее эластичность на всех аппаратных платформах^[48]. Этот метод предполагает одновременное обращение со стороны многих пользователей к определенным функциям системы, а некоторые вводят значения вне нормального диапазона. Из системы требуется обработка огромных объемов данных или при выполнении большого количества функциональных запросов в течение короткого периода времени.

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

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

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

Отладка программы в любом случае принимает во внимание и логическое решение доступной информации об ошибках. Большинство ошибок могут быть признаны по косвенным признакам путем тщательного анализа кода, результатов тестирования, без получения дополнительной информации. Поэтому используют различные методы (рис. 6)^[51]:

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

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

Пролога;

Снижение;

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

Способ ручного тестирования.

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

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

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

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

Метод снижения^[53].

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

Метод обратной трассировки^[54].

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

Вывод:

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

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

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

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

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

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

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

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

Методы отладки программного обеспечения: ручное тестирование, пролога, снижение, обратная трассировка.

Заключение

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

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

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

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

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

Библиография

Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — 167 с.

Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем -СПб.:Питер, 2004.- 318 с.

Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — 203 с.

Приложение

№ п/п	Понятие	Определение
1	Тестирование программного обеспечения	это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов
2	Отладка	это процесс выявления источников отказов, т.е. ошибок, и внесение в программу соответствующих исправлений
3	Восходящее тестирование	тестирование осуществляется снизу вверх
4	Нисходящее тестирование	тестирование осуществляется сверху вниз
5	Тестирование «белого ящика»	это разработка тестовых случаев где используют любые доступные сведения о внутренней структуре или коде
6	Тестирование «черного ящика»	это разработка тестовых случаев при наличии установленных открытых интерфейсов
7	Метод сандвича	это подход к интеграции больших программ, таких, как операционная система или пакет прикладных программ.
8	Модульное тестирование	процесс, позволяющий проверить на корректность отдельные модули исходного кода программы
9	Тестирование безопасности	это проверка работы механизмов доступа к системе и к данным
10	Тестирование производительности	это проверка, удовлетворяет ли системное приложение требованиям по производительности

1. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.11. ↑

2. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.18. ↑

3. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

4. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.11. ↑

5. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.15. ↑

6. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

7. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

8. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.14. ↑

9. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.18. ↑

10. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

11. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.123. ↑

12. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.20. ↑

13. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

14. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.120. ↑

15. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

16. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.28. ↑

17. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.5. ↑

18. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

19. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.70. ↑

20. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

21. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.28. ↑

22. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.70 ↑

23. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

24. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

25. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.90 ↑

26. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.110. ↑

27. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.18. ↑

28. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

29. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.19. ↑

30. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.18. ↑

31. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

32. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.19. ↑

33. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

34. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.167. ↑

35. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.132. ↑

36. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

37. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.22. ↑

38. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.19. ↑

39. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.65. ↑

40. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

41. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.147. ↑

42. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

43. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.65. ↑

44. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.147. ↑

45. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

46. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.120. ↑

47. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.90. ↑

48. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

49. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.32. ↑

50. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.54. ↑

51. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑

52. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.32. ↑

53. Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — С.54. ↑

54. Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — С.146. ↑

55. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспе-чения и систем -СПб.:Питер, 2004.- С.10-318 . ↑