49975 (Этапы разработки программ. Тестирование и отладка. Документирование программ), страница 2

Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения (покрытия) каждого оператора программы. Более сильным критерием является так называемый критерий С1: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз.

Использование критерия покрытия условий может вызвать подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С1 (например, в программе на языке Паскаль, использующей конструкцию цикла WHILE х AND y DO... , применение критерия покрытия условий требует проверки обоих вариантов выхода из цикла: NOT x и NOT y). С другой стороны покрытие условий может не обеспечивать покрытия всех переходов.

Например, конструкция IF A AND B THEN... требует по критерию покрытия условий двух тестов (например, A=true, B=false и A=false, B=true), при которых может не выполняться оператор, расположенный в then - ветви оператора if. Практически единственным средством, предоставляемым современными системами программирования, является возможность определения частоты выполнения различных операторов программы. Но с помощью этого инструмента поддержки тестирования можно проверить выполнение только слабейшего из критериев полноты - покрытие всех операторов. Правда, с помощью этого же инструмента можно проверить и выполнение критерия С1. Но для этого предварительно текст программы должен быть преобразован таким образом, чтобы все конструкции условного выбора (IF, CASE или SWITCH) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма, не выполнявшиеся на данном тесте, будут “видимы” из таблицы частоты выполнения операторов преобразованной программы.

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

• накапливать информации о покрытых и непокрытых ветвях для всех использованных тестов;

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

• поддерживать более мощные критерии полноты структурного тестирования.

1.2.3.2 Совместимое тестирование модулей

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

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

• меньшая трудоемкость (при монолитном тестировании требуются 5 драйверов и 5 заглушек; при пошаговом тестировании требуются или только 5 драйверов - если модули подключаются “снизу вверх ”, - или только 5 заглушек - если модули подключаются “сверху вниз”);

• более раннее обнаружение ошибок в интерфейсах между модулями (их сборка начинается раньше, чем при монолитном тестировании);

• легче отладка, то есть локализация ошибок (они в основном связаны с последним из подключенных модулей);

• более совершенные результаты тестирования (более тщательная проверка совместного использования модулей).

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

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

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

1. модули, содержащие операции ввода-вывода, должны подключаться к тестированию как можно раньше;

2. критические (т.е. наиболее важные) для программы в целом модули также должны тестироваться в первую очередь.

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

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

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

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

1.2.3.3 Семантическая отладка

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

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

Существует 3 способа отладки программы:

1. Пошаговая отладка программ с заходом в подпрограммы;

2. Пошаговая отладка программ с выполнением подпрограммы как одного оператора;

3. Выполнение программы до точки остановки.

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

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

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

1.3 Документирование программы

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

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

1.3.1 Пользовательская документация программы

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

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

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

1.3.2 Документация по сопровождению программы

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

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

3. Документация по сопровождению программы можно разбить на две группы:

4. 1. документация, определяющая строение программ и структур данных программы и технологию их разработки;

5. 2. документацию, помогающую вносить изменения в программу.

6. Документация первой группы содержит итоговые документы каждого технологического этапа разработки. Она включает следующие документы:

• Внешнее описание;

• Описание архитектуры программы, включая внешнюю спецификацию;

• Описание модульной системы, включая внешнюю спецификацию каждого включенного модуля;

• Для каждого модуля - его спецификация и описание его строения;

• Тексты модулей на выбранном языке программирования;

1. Документы второй группы содержат:

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

1.4 Запуск готовой программы и анализ полученных результатов

1. После полученного нами файла с *.exe (обычно) разрешением мы можем запустить его и ещё раз проверить (проанализировать) верно, ли работает программа. На этом этапы создания программы закончены.

12