Требования к современному диаграммеру

1) Возможность создания иерархически связанных диаграмм, на которых взаимодействуют графические и текстовые объекты.

2) Создание и редактирование объектов в любом месте диаграммы.

3) Создание, перемещение и выравнивание двух объектов, изменение размеров объектов и масштабирование.

4) Сохранение связи между объектами при перемещении и изменении размеров.

5) Автоматический контроль ошибок.

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

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

1) контроль синтаксиса диаграмм и типов их элементов. Такой контроль осуществляется при вводе и редактировании элементов диаграмм.

2) Контроль полноты и состоятельности диаграммы, то есть все элементы диаграммы должны быть идентифицированы и отражены в репазитарии. При анализе репазитария должны выявляться циклические определения, эквивалентные определения и неопределенные объекты.

3) Контроль декомпозиции функций.

4) Сквозной контроль диаграмм на состоятельность по уровням, то есть вертикальное и горизонтальное балансирование диаграмм.

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

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

Вопросы для самоконтроля по теме 5:

1. Перечислите основные особенности методологии RAD

2. Перечислите и опишите фазы жизненного цикла программного обеспечения в соответствии с методологией RAD

3. Перечислите основные принципы методологии RAD

4. Опишите состав и структуру современных case-средств

5. Охарактеризуйте функциональные особенности case-средств.

Тема 6. Структурное тестирование программного обеспечения

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

Тестирование – это процесс выполнения программы с целью обнаружения ошибок.

Шаги процесса задаются тестами. Каждый тест определяет:

1) свой набор исходных данных и условий для запуска программы;

2) набор ожидаемых результатов и работы программы.

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

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

Тестирование обеспечивает:

1) обнаружение ошибок;

2) демонстрацию соответствия функций программы ее назначению;

3) демонстрацию реализации требований характеристикам программы;

4) отображение надежности, как индикатора качества программы.

Тестирование не может показать отсутствие дефектов, оно может показать только присутствие дефектов.

Рисунок 12 – Информационные потоки процесса тестирования

На входе процесса тестирования 3 потока: текст программы, исходные данные, ожидаемые результаты.

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

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

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

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

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

Существуют 2 основных принципа тестирования программ:

1) функциональное тестирование (тестирование черного ящика);

2) структурное тестирование (тестирование белого ящика).

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

Местом приложения тестов черного ящика является интерфейс программного обеспечения.

Рисунок 13 –Схема тестирования черного ящика

Тесты черного ящика демонстрируют:

1) как выполняются функции программ;

2) как принимаются исходные данные;

3) как вырабатываются результаты;

4) как сохраняется целостность внешней информации.

При тестировании черного ящика рассматриваются системные характеристики программ, но игнорируется их внутренняя логическая структура.

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

Необходимо также отметить, что тестирование черного ящика не реагирует на многие особенности программных ошибок.

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

Рисунок 14 –Схема тестирования белого ящика

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

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