Конспект лекций междисциплинарного курса мдк. 03. 01 Технология разработки программного обеспечения

Контрольные вопросы Что такое CASE-технологии? Что такое RAD-технологии? Охарактеризуйте модель проектируемого ПО при объектном подходе Что такое экстремальное программирование? 4 Тестирование и отладка программ В целом разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведет себя не так, как ожидает пользователь. Дефект – это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя. Общепринятая практика состоит в том, что после завершения продукта и до передачи его заказчику независимой группой тестировщиков проводится тестирование ПО. Эта практика часто выражается в виде отдельной фазы тестирования (в общем цикле разработки ПО), которая часто используется для компенсирования задержек, возникающих на предыдущих стадиях разработки. Другая практика состоит в том, что тестирование начинается вместе с началом проекта и продолжается параллельно созданию продукта до завершения проекта. Второй путь обычно требует больших трудозатрат, но качество тестирования при этом будет выше. Уровни тестирования: модульное тестирование. Тестируется минимально возможный для тестирования компонент, например отдельный класс или функция; интеграционное тестирование. Проверяется, есть ли какие-либо проблемы в интерфейсах и взаимодействии между интегрируемыми компонентами, например, не передастся информация, передается некорректная информация, системное тестирование. Тестируется интегрированная система на ее соответствие исходным требованиям: альфа-тестирование – имитация реальной работы с системой штатными разработчиками либо реальная работа с системой потенциальными пользователями/заказчиком на стороне разработчика. Часто альфа-тестирование применяется для законченного продукта в качестве внутреннего приемочного тестирования. Иногда альфа, тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО; бета-тестирование – в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей. 4.1 Термины и определения Выполнение программы с целью обнаружения ошибок называется тестированием. Виды ошибок и способы их обнаружения приведены в таблице 4.1. Таблица 4.1. Вида программных ошибок и способы их обнаружения Эффективность контроля 1-го вида зависит и от языка, и от компилятора. Контроль 2-го вида осуществляется с помощью исключений – Exceptions и весьма полезен для проверки правдоподобности промежуточных результатов. Тест – это набор контрольных входных данных совместно с ожидаемыми результатами. В число входных данных времязависимых программ входят события и временные параметры. Ключевой вопрос – полнота тестирования: какое количество каких тестов гарантирует, возможно, более полную проверку программы? Исчерпывающая проверка на всем множестве входных данных недостижима. Пример: программа, вычисляющая функцию двух переменных: Y=f(X, Z). Если X,Y,Z— real, то полное число тестов (232)2 = 264 ≈ 1031 Если на каждый тест тратить 1 мс, то 264 мс = 800 млн лет. Следовательно: в любой нетривиальной программе на любой стадии ее готовности содержатся необнаруженные ошибки; тестирование – технико-экономическая проблема, основанная на компромиссе время — полнота. Поэтому нужно стремиться к возможно меньшему количеству хороших тестов с желательными свойствами. Детективность: тест должен с большой вероятностью обнаруживать возможные ошибки Покрывающая способность: один тест должен выявлять как можно больше ошибок. Воспроизводимость: ошибка должна выявляться независимо от изменяющихся условий (например, от временных соотношений) – это труднодостижимо для времяэависимых программ, результаты которых часто не воспроизводи мы. Только на основании выбранного критерия можно определить тот момент времени, когда конечное множество тестов окажется достаточным для проверки программы с некоторой полнотой (степень полноты, впрочем, определяется экспериментально). Используется два вида критериев (таблице. 4.2): функциональные тесты составляются исходя из спецификации программы; структурные тесты составляются исходя из текста программы. Таблица 4.2 – Виды критериев и их функциональность На рисунке 4.1,а видно отличие тестирования команд (достаточен один тест) от C1 (необходимы два теста как минимум). Рисунок 4.1, 6 иллюстрирует различие С1 (достаточно двух тестов, покрывающих пути 1, 4 или 2, 3) от С2 (необходимо четыре теста для всех четырех путей). С2 недостижим в реальных программах из-за их цикличности, поэтому ограничиваются тремя путями для каждого цикла: 0, 1 и N повторений цикла. Рисунок 4.1 – Траектории вычислении при структурном тестировании Остаются проблемы назначения классов входных/выходных данных для функционального тестирования и проектирования тестов для структурного тестирования. Классы, как правило, назначаются исходя из семантики решаемой задачи. Тестирование «белого ящика» и «черного ящика» В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения) фразы тестирование «белого ящика» и тестирование «черного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем. При тестировании «белого ящика» (англ. while-box testing, также говорят — прозрачного ящика) разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные Части системы. Оно обеспечивает то, что компоненты конструкции работоспособны и устойчивы до определенной степени. При тестировании «черного ящика» (англ.black-box testing) тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов с уверенностью в том, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок Если альфа- и бета-тестирование относятся к стадиям до выпуска продукта (а также, неявно, к объему тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели. Бета-тестирование в целом ограничено техникой «черного ящика» (хотя постоянная часть тестировщиков обычно продолжает тестирование «белого ящика» параллельно бета-тестированию). Таким образом, термин бета-тестирование может указывать на состояние программы (ближе к выпуску, чем альфа) или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию «белого ящика», хотя ПО уже «в бете» (стадия), но в этом случае он не является частью бета-тестирования (группы/процесса). Порядок разработки тестов По внешней спецификации разрабатываются тесты: для каждого класса входных данных; для граничных и особых значений входных данных. Контролируется, все ли классы выходных данных при этом проверяются, и добавляются при необходимости нужные тесты. Разрабатываются тесты для тех функций, которые не проверяются в п. 1. По тексту программы проверяется, все ли условные переходы выполнены в каждом направлении (С1). При необходимости добавляются новые тесты. Аналогично проверяется, проходятся ли пути для каждого цикла: без выполнения тела, с однократным и максимальным числом повторений. Готовятся тесты, проверяющие исключительные ситуации, недопустимые входные данные, аварийные ситуации. Функциональное тестирование дополняется здесь структурным. Классы входных/выходных данных должны быть определены в плане тестирования уже во внешней спецификации. Согласно статистике 1-й и 2-й пункты обеспечивают степень охвата С1 в среднем 40—50%. Проверка по С1 (пункт 3) обычно выявляет 90 % всех ошибок, найденных при тестировании. (Все программное обеспечение ВВС США принимается с проверкой по C1.) Систематическое тестирование предполагает также ведение журнала отладки (Bug Book), в котором фиксируется ошибка (описание, дата обнаружения, автор модуля) и в дальнейшем — исправление (дата, автор). Приведем так называемые аксиомы тестирования. Тест должен быть направлен на обнаружение ошибки, а не на подтверждение правильности программы. Автор теста — не автор программы. Тесты разрабатываются одновременно или до разработки программы. Необходимо предсказывать ожидаемые результаты теста до его выполнения и анализировать причины расхождения результатов. Предыдущее тестирование необходимо повторять после каждого внесения исправлений в программу. Следует повторять полное тестирование после внесения изменений в программу или после переноса ее в другую среду. В те программы, в которых обнаружено много ошибок, необходимо дополнить первоначальный набор тестов. 4.2 Автоматизация .тестирования А. Автоматизация прогона тестов актуальна для 5-й и 6-й аксиом Майерса. Пишутся командные файлы для запуска программы с каждым гестом из набора и сравнением реального результата с ожидаемым. Существуют специальные средства (например система MIL-S для PL/1 фирмы IBM). Разрабатывается стандарт IEEE скриптового языка для описания тестовых наборов. Б. Средства автоматизации подготовки тестов и анализа их результатов. Генераторы случайных тестов в заданных областях вход- Отладчики (для локализации ошибок). Анализаторы динамики (profilers). Обычно входят в состав отладчиком; применяются для проверки соответствия тестовых наборов структурным критериям тестирования. Средства автоматической генерации структурных тестов метолом «символического выполнения» Кинга. Модульное тестирование Модульное тестирование – это тестирование программы на уровне отдельно взятых модулей, функций или классов. Цель модульного тестирования заключается в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестировании. Модульное тестирование проводится по принципу «белого ящика», т. е. основывается на знании внутренней структуры программы и часто включает те или иные методы анализа покрытия кода. Модульное тестирование обычно подразумевает создание вокруг каждого модуля определенной среды, включающей заглушки для всех интерфейсов тестируемого модуля. Некоторые из них могут использоваться для подачи входных значении, другие – для анализа результатов, присутствие третьих может быть продиктовано требованиями, накладываемыми компилятором и сборщиком. На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчика ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т. п., обычно пропускаются на уровне модульного тестирования и выявляются па более поздних стадиях тестирования. Именно эффективность обнаружения тех или иных типов дефектов должна определять стратегию модульного тестирования, т. е. расстановку акцентов при определении набора входных значений. У организации, занимающееся разработкой программного обеспечения, как правило, имеется историческая база данных (Repository) разработок, хранящая конкретные сведения о разработке предыдущих проектов: о версиях и сборках кода (build), зафиксированных в процессе разработки продукта, о принятых решениях, допущенных просчетах, ошибках, успехах и т. п. Проведя анализ характеристик прежних проектов, подобных заказанному разработчику, можно предохранить новую разработку от старых ошибок, например, определив типы дефектов, поиск которых наиболее эффективен на различных этапах тестирования. В данном случае анализируется этап модульного тестирования. Если анализ не дал нужной информации, например, в случае проектов, в которых соответствующие данные не собирались, то основным правилом становится поиск локальных дефектов, у которых код, ресурсы и информация, вовлеченные в дефект, характерны именно для данного модуля. В этом случае на модульном уровне ошибки, связанные, например, с неверным порядком или форматом параметров модуля, могут быть пропущены, поскольку они вовлекают информацию, затрагивающую другие модули (а именно, спецификацию интерфейса), л то время как ошибки в алгоритме обработки параметров довольно легко обнаруживаются. Являясь по способу исполнения структурным тестированием иди тестированием «белого ящика», модульное тестирование характеризуется степенью, в которой тесты выполняют или покрывают логику программы (исходный текст). Тесты, связанные со структурным тестированием, строятся по следующим принципам: на основе анализа потока управления. В этом случае элементы, которые должны быть покрыты при прохождении тестов, определяются на основе структурных критериев тестирования С0, C1, C2. К ним относятся вершины, дуги, пути управляющего графа программы (УГП), условия, комбинации условий и т. п. на основе анализа потока данных, когда элементы, которые должны быть покрыты, определяются на основе потока данных, т. е. информационного графа программы. Тестирование на основе потока управления. Особенности использования структурных критериев тестирования С0, C1, C2 были рассмотрены выше. К ним следует добавить критерий покрытия условий, заключающийся в покрытии всех логических (булевых) условий в программе. Критерии покрытия решений (ветвей – С1) и условий не заменяют друг друга, поэтому на практике используется комбинированный критерий покрытия условий/решений, совмещающий требования по покрытию и решений, и условий. К популярным критериям относится критерий покрытия функций программы, согласно которому каждая функция программы должна быть вызвана хотя бы 1 раз, и критерий покрытия вызовов, согласно которому каждый вызов каждой функции в программе должен быть осуществлен хотя бы 1 раз. Критерий покрытия вызовов известен также как критерий покрытия пар вызовов (call pair coverage).

Похожие:

	Конспект лекций междисциплинарного курса мдк. 03. 01 Технология разработки... Исследовать процессы создания новых технологий и определять их основные тенденции целесообразно, сопоставляя эти технологии с уровнем...		Конспект лекций междисциплинарного курса мдк 01. 02 Прикладное программирование ПМ. 01 Разработка программных модулей программного обеспечения для компьютерных систем
	Учебно-методическое пособие "Управление качеством разработки программного... Отображены специфика в подходах к организации, базовым принципам и выполнению тестирования в зависимости от применяемой модели жизненного...		Конспект лекций Ш 39 Метрология, стандартизация, сертификация: Конспект лекций / О. А. Шейфель; Кемеровский технологический институт пищевой промышленности....
	Конспект лекций по курсу “Технология лекаственных форм и галеновых... Конспект лекций по курсу “Технология лекаственных форм и галеновых препаратов” для студентов специальности «Технология фармацевтических...		Конспект лекций для студентов всех форм обучения специальности 080110... Налоги и налогообложение: Конспект лекций / Составитель Н. А. Леончик. – Кемерово, 2006. – 80 с
	Конспект лекций по дисциплине «Научные основы производства продуктов питания» Конспект лекций по дисциплине «Научные основы производства продуктов питания» для студентов кафедры «Технология и организация общественного...		Календарно-тематический план учебной дисциплины преподаватель Алексеев Александр Игоревич Наименование междисциплинарного курса мдк. 01. 01 Электрические машины и аппараты
	Технические средства автоматизации конспект лекций Конспект лекций предназначен для студентов дневной, вечерней, заочной и дистанционной форм обучения по специальности 220301 «Автоматизация...		Конспект лекций мдк 02. 02. Электронные средства и методы геодезических измерений ПМ. 02. Выполнение топографических съемок, графического и цифрового оформления их результатов
	Сборник лекций для студентов медицинского колледжа по пм 04/05/07... Сборник лекций для самоподготовки студентов медицинского колледжа по пм 04/05/07 «Выполнение работ по профессии младшая медицинская...		Конспект лекций Владимир 2010 Министерство образования Российской... Автоматизированные системы бухгалтерского и управленческого учета. Часть 1: Конспект лекций / Владим гос ун-т; Сост.: Д. Н. Васильев...
	Конспект лекций лаконично раскрывает содержание и структуру учебной... Безопасность жизнедеятельности : конспект лекций для студентов очной и заочной форм обучения / сост. В. М. Домашко; Южный федеральный...		Конспект лекций содержание тема Предмет и задачи курса Внутренняя и внешняя среда организации (фирмы) и их взаимосвязь. Мировой рынок и его развитие
	Конспект лекций профессионального модуля пм. 02 Разработка и администрирование баз данных Тема 3 Основы разработки клиент-серверных приложений для работы в компьютерной сети		Конспект лекций для студентов специальности 271200 «Технология продуктов общественного питания» Печатается по решению редакционно-издательского совета Кемеровского технологического института пищевой промышленности