Файл: Отладка и тестирование программ: основные подходы и ограничения (1. Понятия тестирования и отладки программного обеспечения).pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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