Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

1.Слишком большое количество всех возможных комбинаций входных данных.96 Следует проверить:

−Все допустимые входные значения.

−Все недопустимые входные значения.

−Все способы редактирования входных данных.

−Реакцию программы на ввод в каждый момент еѐ работы. Например, по-

пробовать ввести данные, когда программа их совсем не ждѐт, пока она обрабатывает предыдущие данные, выводит результат или сообщение.

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

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

Физически невозможно проверить все пути выполнения программы. Для серь-

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

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

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

Всех ошибок всѐ равно не найти. Для чего же тестируют программы?

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

Если тест позволил выявить проблему, значит, он успешный. Главные ответы тестирования:

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

2.Показать полноту документации к системе.

3.Показать точность полученных результатов.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 97

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

5.5.6.1. Тестирование на этапе определения требований

Проверяется:

−адекватность (действительно такой продукт нужно создавать);

−полнота (не упущены жизненно-необходимые функции, или наоборот можно ослабить какие-либо требования);

−совместимость (логическая несовместимость требований означает противоречивость, психологическая – концептуальные разногласия);

−выполнимость (может быть, необходимо более быстрое аппаратное обеспечение, больший объѐм памяти, более высокая пропускная способность, большее разрешение и т.п.);

−правильная расстановка приоритетов (абсолютная безупречность, требовательность к ресурсам, готовность конкурировать с другими ПС).

5.5.6.2. Тестирование на этапе анализа

Проверяется:

− соответствие модели анализа требованиям; − соответствие спецификаций требованиям (по функциям и по данным);

− простота, гибкость и функциональность пользовательского интерфейса.

5.5.6.3. Тестирование на этапе проектирования

Проверяется:

−добротность проекта (будет ли на его основе создан эффективный, компактный, лѐгкий в сопровождении программный продукт);

−полнота (описаны ли все взаимосвязи между подсистемами и данными);

−реалистичность (сможет ли продукт работать быстро, достаточны ли аппаратные и программные ресурсы, удачно ли выбраны инструментальные средства разработчиков);

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

5.5.6.4. Тестирование на этапе реализации

Технология тестирования этапа кодирования называется тестированием стеклянно-

го ящика (glass box).

Различают структурное и функциональное тестирование:

1.Структурное тестирование (тестирование белого ящика – white box) предполагает знание исходного кода и полный доступ к нему. Как правило, тестирует программист, а само тестирование является неотъемлемой частью процесса программирования. При этом учитываются следующие аспекты:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

− полный охват кода (когда и какие фрагменты кода работают в конкретный момент времени);

− управление потоком (какая функция и когда должна выполняться в программе, какова последовательность выполнения функций);

− отслеживание целостности данных (какая часть программы меняет данные и каким образом);

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

2. Функциональное тестирование (тестирование чѐрного ящика – black box) предполагает, что внутренняя структура программы неизвестна. Тестер ищет интересные с его точки зрения входные данные и условия, которые могут привести к нестандартным результатам. Программа исследуется извне, то есть с точки зрения пользователя. Именно этому типу тестирования посвящается бОльшая часть времени. Оно позволяет выявить проблемы и критические точки, которые были упущены программистом.

5.5.6.5. Тестирование на этапе тестирования

Этот этап жизненного цикла связан с проверкой качества всего проекта в соответствии со спецификацией качества. Для этого существует специальный тип тестирования, который принято называть регрессионным тестированием.

У термина регрессионное тестирование два значения, объединѐнных общей идеей повторного использования разработанных тестов:

1.Тест обнаружил ошибку, и программист еѐ исправил. Снова проводится тот же тест, чтобы убедиться, что ошибки больше нет.

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

В первом значении этого термина регрессионное тестирование используется на этапе реализации проекта.

5.5.6.6. Тестирование на этапе опытной эксплуатации

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

5.5.6.7. Тестирование на этапе окончательной приѐмки и сертификации

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 99

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

Международные стандарты – ISO 12207, ISO 9001. Отечественные стандарты:

ГОСТ 19.201-78. Техническое задание. ГОСТ 19.202-78. Спецификация.

ГОСТ 19.301-79. Программа и методика испытаний. ГОСТ 19.503-79. Руководство системного программиста. ГОСТ 19.504-79. Руководство программиста.

ГОСТ 28195-89. Оценка качества программных средств. Общие положения.

РД 50-34.698-90 – Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов.

5.5.6.8. Тестирование на этапе сопровождения

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

Если этап сопровождения предполагает перенос ПС с одной аппаратной или программной платформы на другую, то проводится адаптационное тестирование.

Адаптационное тестирование включает в себя:

−регрессионные тесты;

−тестирование клавиатуры (если она специфическая, то в работе с ней могут быть отклонения от стандарта), терминала (отображение графики, проблемы со шрифтами, цветом), дисков (правильность работы с файлами, так как ѐмкость и формат дисков могут отличаться);

−тестирование обработки ошибок операционной системой (как ПС защищает себя от ошибок и странностей операционной системы);

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

−проверку совместимости (если на исходном компьютере продукт совместим с программой Икс, то при переносе на новый компьютер он также должен быть совместим с ней);

−тестирование пользовательского интерфейса (в различных графических средах (Windows, Mac, Motif) действуют различные соглашения о пользовательском интерфейсе);

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

−проверку номера версии и идентификация системы (номер версии везде из-100 менѐн; правильность идентификации аппаратуры и операционной системы);

−другие изменения (спросить у программиста, что он изменил в программе для адаптации, и тщательно протестировать все изменения).

6.ДОКУМЕНТАЦИЯ ПРОЦЕССА РАЗРАБОТКИ

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

При разработке ПС создаѐтся большой объѐм разнообразной документации. Она необходима:

−как средство управления разработкой;

−как средство передачи информации между разработчиками;

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

Примерный состав сопровождающей проект документации, рекомендованный стандартом ISO 12207, показан на рис. 6-1.

Рис. 6-1. Состав

документации

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011