Детерминированное тестирование.

Ручные методы.

· Индивидуальное ручное тестирование;

· Коллективный сквозной просмотр текста;

· Коллективная инспекция текста.

Статические методы.

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

Динамические методы.

Вручную моделируется процесс выполнения программы при заданных исходных данных.

Исходными данными таких проверок являются:

· техническое задание;

· спецификации;

· структурная и функциональная схемы программы;

· схемы отдельных компонентов;

· на более поздних этапах – алгоритмы и тексты программ и тестовые наборы данных.

 

17. Машинные методы тестирования.

Детерминированное тестирование.

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

 

18. Методы структурного тестирования

Детальное изучение текста программы и построение входных тестовых наборов данных (ТНД) осуществляется на основе одного из 4 критериев:

• покрытие операторов

• покрытие узлов ветвлений (покрытие решений)

• покрытие условий

• комбинаторное покрытие условий

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

Покрытие операторов – выбирается такой ТНД, который вызывает выполнение каждого оператора в программе хотя бы один раз.

Покрытие решений - требует создать такой ТНД, в котором в каждом узле ветвления должен быть обеспечен переход по веткам «истина-ложь» хотя бы один раз.

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

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

 

19. Методы функционального тестирования.

Методы «черного ящика»:

• эквивалентного разбиения

• анализа граничных значений

• функциональных диаграмм

1. Метод эквивалентных разбиений:

Два этапа: выделение классов эквивалентности и построение тестов

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

Для нахождения классов эквивалентности используют следующие правила:

• если входное условие описывает область значений, то определяются один правильный и два неправильных КЭ

• если входное условие описывает ситуацию «должно быть», то один правильный и один неправильный КЭ

• если входное условие описывает конечное число конкретных значений и есть основания полагать, что каждое значение программа трактует особо, то определяется правильный КЭ для каждого значения и один неправильный

На основании КЭ строятся тестовые наборы данных (ТНД), причем надо стремиться для правильных КЭ к минимальному числу наборов, т.е. каждый тест должен по возможности покрывать большее число правильных КЭ. Для каждого неправильного КЭ строится хотя бы один ТНД.

2. Метод анализа граничных значений:

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

3. Метод построения функциональных диаграмм:

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

Метод построения функциональных диаграмм предполагает реализацию следующих процедур:

1. В спецификации программы выделяются причины и следствия (причина – отдельное входное условие или КЭ входных условий, следствие – выходное условие или результат преобразования).

2. Каждой причине и следствию присваивается уникальный номер.

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

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

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

6. Столбцы решений преобразуются в тесты

 

20. Тестирование модулей.

Тестированию подвергается:

• Интерфейс модулей

• Внутренние структуры данных

• Независимые пути

• Пути обработки ошибок

• Граничные условия

При тестировании путей выполнения обнаруживаются следующие категории ошибок:

• Ошибочные вычисления

• Некорректные сравнения

• Неправильный поток управления

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

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

Заглушки замещают вызываемые модули.

 

21. Тестирование комплексов программ.

I. Тестирование функций (поиск различий программы и её спецификаций)

II. Тестирование системы (сопоставление результатов с исходными целями)

1) удобства использования

2) на предельных объёмах

3) на предельных нагрузках

4) удобства эксплуатации

5) защиты

6) производительности

7) требований к памяти

8) конфигурации оборудования

9) совместимости или конверсии

10) удобства установки

11) надёжности

12) восстановления

13) удобства обслуживания

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

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

 

22. Отладка программ.

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

Составляющие процесса отладки:

· действия, направленные на выявление ошибок (тестирование);

· диагностика и локализация ошибок (определение характера и местонахождения ошибок);

· внесение исправлений в программу с целью устранения ошибок.

Чтобы понять, где возникла ошибка, приходится:

· узнавать текущие значения переменных;

· выяснять, по какому пути выполнялась программа.

 

23. Документирование ПС.

Документация должна отвечать следующим основным требованиям:

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

• Возможность использования на различных этапах проектирования и эксплуатации ПС;

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

 

24. Состав документации на ПС.

Документацию ПС можно разделить на:

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

• Эксплуатационную документациюпродукта – объекта и результата разработки, создаваемую для конечных пользователей ПС и позволяющую им осваивать и квалифицированно применять эти средства для решения конкретных функциональных задач.

Технологическая документация должна отображать процессы ЖЦ прикладных программ и данных и регламентировать требования к этим документам.

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

• Базовые документы, определяющие цели и методологию применения конкретной версии ЖЦ ПС;

• Ссылочные документы на руководства по организации подобных разработок;

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

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

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

Эксплуатационная документация ПС включает:

• Руководство администраторов и операторов, осуществляющих инсталляцию и непосредственное управление режимами решения функциональных задач;

• Руководство операторов – пользователей, использующих ПС по прямому назначению;

• Документацию сопровождения ПС, включая руководство по сопровождению и модификации программ и информации баз данных;

• Справочные руководства по применению ПС;

• Учебные руководства по освоению ПС и информационной системы.

Исследовательская документация.

• Имеет экспериментальный характер, зависящий от возможных целей исследований.

• Основная ее задача состоит в фиксировании и обобщении характеристик объектов и процессов всего ЖЦ ПС и ИС.

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

 

25. Испытания и сертификация ПС.

Цель испытаний: определение степени соответствия созданного комплекса программ

Виды испытаний:

1. Испытание опытного образца ПС на полное соответствие требованиям ТЗ

2. Испытание рабочей версии ПС, адаптируемое к конкретным условиям применения

3. Испытание версии(модернизированного ПС при сопровождении)

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

1. Утвержденным заказчиком и согласованным с разработчиком ТЗ на ПС

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

3. Программой испытаний по всем требованиям ТЗ

4. Методиками испытаний по каждому разделу требований ТЗ

В программе испытаний должно быть:

• Объект испытаний

• Цели испытаний

• Собственно программа испытаний

• Методика испытаний

Цели сертификации ПС:

Основная – защита интересов пользователей:

• Контроль качества

• Обеспечение высоких потребительских свойств

• Повышение эффективности затрат

Формальная – выдача сертификата

• полнота, точность эталонных данных

• Адекватные показатели качества ПС

• Методологии интерпретации данных

 

26. Методы, технология, средства обеспечения сертификации ПС.

Организационная структура системы сертификации:

• Госстандарт РФ

• Ведомственные органы – те же функции, но в ограниченном объеме и для конкретных классов продукции

• Испытательные лаборатории сертификации (ИЛС)

– Проводят испытания согласно действующим гос. нормативным документам

– Испытывают ПС по поручению органов госнадзора России, заказчиков или разработчиков ПС

– Оформляют в установочном порядке протоколы испытаний

Госстандарт РФ:

• Организует ведение обязательной сертификации продукции по поручению органов законодательной или исполнительной власти

• Организует и финансирует разработку, а также утверждает основополагающие нормативно-технические и методические документы системы сертификации

• Утверждает документы, устанавливающие порядок сертификации конкретных видов продукции

• Проводят аккредитацию ИЛС и выдает аттестат аккредитации

• Признает иностранные сертификаты соответствия

• Регистрирует и аннулирует сертификаты соответствия и лицензии

• Организует периодическую публикацию по сертификации

Исходные данные для сертификационных испытаний:

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

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

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

Решение о выдаче сертификата на ПС основывается на оценке степени его соответствия действующим и/или специально разработанным документам:

• Действующие международные и национальные стандарты на тестирование, испытание, аттестацию программ и б/д

• Международные и гос. стандарты на технологию создания компонент ПС и алгоязыки

• Стандарты на сопровождающую ПС документацию

• Технические условия, описания, спецификации и другие эксплуатационные документы по выбору

Стандарты сертификации:

ISO – 0002 : 1983 – общие термины и определения в области стандартизации и смежных видах деятельности

ISO – 0025 : 1983 – общие требования к оценке технической компетентности ИЛС

ISO – 0038 : 1983 - общие требования к приемке ИЛС

ISO – 0043 : 1983 – организация и проведение проверки на компетентность

ISO – 0045 : 1983 – руководящее положение по представлению результатов испытаний

ISO – 0049 : 1983 – руководящее положение по разработке, руководство по качеству для испытаний лаборатории

ISO – 0054 : 1983 – общие требования к приемке органов аккредитации

ISO – 0055 : 1983 – система аккредитации ИЛС, общие требования к испытательной деятельности

 

27. Сопровождение и конфигурационное управление ПС.

Сопровождение ПС:

Процесс модификации ПС, обусловленный необходимостью устранения выявленных в нем ошибок и/или изменение функциональных возможностей

Конфигурационное управление

Процесс применения административных и технических процедур на всем протяжении жизненного цикла для:

1. Идентификации, определения и базирования единиц ПО в информационных системах

2. Управление модификацией и выпуском версий ПС

3. Фиксирование и сообщение о состоянии версии ПС

4. Для управления и контролирования хранения обращения и поставок ПС

Цель: обеспечить управляемое и контролируемое развитие структуры

 

28. Особенности современных методологий и технологий разработки ПС.

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

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

· обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям;

· гарантия создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;

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

· обеспечение создания информационных систем, отвечающих требованиям открытости, переносимости и масштабируемости;

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

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

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

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

· поддерживать полный жизненный цикл информационной системы;

· обеспечивать гарантированное достижение целей разработки системы с заданным качеством и в установленное время;

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

· технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек);

· обеспечивать минимальное время получения работоспособной системы;

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

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