Виды программных документов

Документирование программного обеспечения осуществляется в соответствии с Единой системой программной документации (ГОСТ 19.XXX). ГОСТ 19.101-77 содержит виды программных документов для программного обеспечения различных типов. В данном ГОСТе перечислены документы следующих типов:

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

q ведомость держателей подлинников (код вида документа – 05) должна содержать список предприятий, на которых хранятся подлинники программных документов. Необходимость этого документа определяется на этапе разработки и утверждения технического задания только для программного обеспечения со сложной архитектурой;

q текст программы (код вида документа – 12) должен содержать текст программы с необходимыми комментариями. Необходимость этого документа определяется на этапе разработки и утверждения технического задания;

q описание программы (код вида документа – 13) должно содержать сведения о логической структуре и функционировании программы, Необходимость данного документа также определяется на этапе разработки и утверждения технического задания;

q ведомость эксплуатационных документов (код вида документа – 20) должна содержать перечень эксплуатационных документов на программу, к которым относятся документы с кодами: 30, 31, 32, 33, 34, 35, 46. Необходимость этого документа также определяется на этапе разработки и утверждения технического задания;

q формуляр (код вида документа – 30) должен содержать основные характеристики программного обеспечения, комплектность и сведения об эксплуатации программы;

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

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

q руководство программиста (код вида документа – 33) должно содержать сведения для эксплуатации программного обеспечения.

q руководство оператора (код вида документа – 34) содержит сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы;

q описание языка (код вида документа – 35) – описание синтаксиса и семантики языка программы;

q руководство по техническому обслуживанию (код вида документа – 46) содержит сведения для применения программы при обслуживании технических средств.

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

Порядок выполнения работы:

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

2. Отладить программный модуль.

3. Получить результаты работы.

4. Оформить документацию к разработанному программному обеспечению.

5. Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен включать в себя:

1. Интерфейс пользователя.

2. Саму программу.

3. Документацию к программному обеспечению:

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

· текст программы;

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

4. Результаты работы программ.

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

Контрольные вопросы

1. Этап реализации и отладки программного обеспечения.

2. Инструментальные средства разработки.

3. Стихийное программирование.

4. Структурное и модульное программирование.

5. Объектное и компонентное программирование.

6. Документация к программному обеспечению.

Лабораторная работа № 5

Проектирование программной системы при объектном подходе к программированию

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

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

2. Изучить соответствующие разделы в издании [1, 2].

Теория:

Основы UML - проектирования

Важным этапом создания программного обеспечения является проектирование. На этом шаге закладывается архитектура системы.

Одним из способов проектирования является метод CRC-карточек. Этот метод проектирования является составляющей UML-проектирования.

Шаг первый

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

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

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

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

q студент (тестируемый);

q администратор (он же преподаватель, он же составитель тестов).

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

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

Название варианта Цель Действующие лица (актеры) Краткое описание   Тип варианта

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

Подробное описание варианта использования Прохождение теста

Действия исполнителя	Отклик системы
1. Студент вводит свои данные (ФИО, Группа), т.е. регистрируется в системе	2. Система создает на диске файл с результатом тестирования и предлагает выбрать тест.
3. Студент выбирает тест	4. Система запускает тест
5. Студент последовательно отвечает на вопросы	6. Система регистрирует правильные и неправильные ответы
7. Студент завершает тестирование	8. Система подсчитывает процент правильных ответов
9. Студент ожидает результат	10. Система демонстрирует результат и предлагает сохранить его
11. Студент решает, сохранять результат или нет.	12. Если выбрано сохранение, система записывает результат в файл.
13. Студент завершает работу.	14. Система завешает работу.

Шаг второй

Для лучшего понимания структуры программы строится диаграмма вариантов использования, (диаграмма прецедентов):

Пример диаграммы прецедентов системы «Банкомат» изображен на рис. 1.

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

Рис. 1. Диаграмма вариантов использования «Банкомат»

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

Шаг третий

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

Придумать можно много (таймер, счетчик купюр, карточка и т.д.).

Далее оформляются CRC-карты. Это листки бумаги 10x15. Они разделены на 3 части и выглядят следующим образом:

Рис. 2. Оформление CRC-карты

Ниже приведен набор СРС-карт для примера с банкоматом:

 

 

 

Шаг четвертый

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

· диаграммы последовательности событий;

· диаграммы кооперации.

4.1. Диаграмма последовательности событий

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

Для построения диаграммы последовательностей системы необходимо:

q идентифицировать каждое действующее лицо (объект) и изобразить для него линию жизни. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1 на рис. 3). Правее изображается другой объект, который непосредственно взаимодействует с первым и т.д.;

q из описания варианта использования определить множество системных событий и их последовательность;

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

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

4.1.1. Линия жизни объекта

Линия жизни объекта (object lifeline) служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоциированной с единственным объектом. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней (объекты 1 и 2 на рис. 3).

Если объекты разрушаются в какой-то момент для освобождения ресурсов системы, то их линия жизни обрывается в момент уничтожения. Для обозначения такого момента в языке UML используется специальный символ в форме латинской буквы "X" (объект 3 на рис. 3). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.

4.1.2. Фокус управления

Объекты на диаграмме последовательности могут находиться в двух состояниях: активном – непосредственно выполняя какие-либо действия и пассивном – ожидая сообщения от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 3), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности).

4.1.3. Сообщения

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

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

Рис. 3. Графические примитивы диаграммы последовательности

Диаграмма последовательности событий для нашего примера (Система банкомата) приведена на рис. 4.

Рис. 4. Диаграмма последовательности событий

4.2. Диаграмма кооперации (сотрудничества)

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

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

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

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

Решение приведено на рис. 5.

Рис. 5. Пример диаграммы кооперации

Заметим, что на приведенной диаграмме объекты классов «Отдел» и «Сотрудник» реализованы мультиобъектами.

 

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

Порядок выполнения работы:

1. В соответствии с вариантом задания, предложенным преподавателем, определить действующих лиц (акторов) системы.

2. Определить варианты использования системы и описать их в краткой или полной форме.

3. Построить диаграмму вариантов использования системы (использовать MS Office или MS Visio).

4. Определить классы проектируемой системы.

5. Создать CRC-карты для всех классов системы (использовать MS Office или MS Visio).

6. Построить диаграммы взаимодействия (использовать MS Office или MS Visio).

7. Сдать и защитить работу.

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

1. Постановку задачи.

2. Описание действующих лиц и прецедентов системы.

3. Диаграмму прецедентов.

4. CRC-карты.

5. Диаграммы взаимодействия.

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

Контрольные вопросы:

1. Проектирование ПО при объектном подходе.

2. Моделирование предметной области при проектировании ПО.

3. Язык UML. Его назначение, преимущества и недостатки.

4. Варианты использования ПО.

5. Диаграммы в языке UML.

6. Диаграммы прецедентов.

7. Диаграммы взаимодействия.

8. Назначение и использование CRC-карт.

Варианты заданий:

1. Заказ билетов в аэропорту.

2. Электронный магазин.

3. Отправка sms.

4. Система охраны частного дома.

5. Пропускная система.

6. Система безопасности тюрьмы.

7. Система безопасности полета самолета.

8. Компьютерная система тестирования для оценки знаний студентов.

9. Заказ билетов в театральной кассе.

10. Телефонный коммутатор.

11. Система учета успеваемости студентов деканатом.

12. Записная книжка.

13. Пропускная система биоконтроля.

14. Автомат платежной системы.

15. Электронная почта.

Лабораторная работа № 6

Тестирование программ методами «белого ящика»

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

1. Ознакомиться с лекционным материалом по теме "Этапы разработки программного обеспечения. Тестирование и отладка программных продуктов" учебной дисциплины "Технология разработки программного обеспечения".

2. Изучить соответствующие разделы в издании [1, 3].

Теория:

Тестирование программного обеспечения

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

· постановка задачи для теста;

· проектирование теста;

· написание тестов;

· тестирование тестов;

· выполнение тестов;

· изучение результатов тестирования.

Виды тестов

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

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

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

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

Тестирование методом «белого ящика» также не дает стопроцентной гарантии того, что модуль не содержит ошибок. Даже если предположить, что выполнены тесты для всех ветвей алгоритма, нельзя с полной уверенностью утверждать, что программа соответствует ее спецификациям. Например, если требовалось написать программу для вычисления кубического корня, а программа фактически вычисляет корень квадратный, то реализация будет совершенно неправильной, даже если проверить все пути. Вторая проблема – отсутствующие пути. Если программа реализует спецификации не полностью (например, отсутствует такая специализированная функция, как проверка на отрицательное значение входных данных программы вычисления квадратного корня), никакое тестирование существующих путей не выявит такой ошибки. И, наконец, проблема зависимости результатов тестирования от входных данных. Одни данные будут давать правильные результаты, а другие нет. Например, если для определения равенства 3 чисел программируется выражение вида:

IF (A+B+C)/3 = A,

то оно будет верным не для всех значений A, B и С (ошибка возникает в том случае, когда из двух значений В или С одно больше, а другое на столько же меньше А). Если концентрировать внимание только на тестировании путей, нет гарантии, что эта ошибка будет выявлена.

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

Стратегия «белого ящика»

Существуют следующие методы тестирования по принципу «белого ящика»:

q покрытие операторов;

q покрытие решений;

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

q покрытие решений/условий;

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

2.1. Метод покрытия операторов

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

Пример:

   Рис. 1. Пример алгоритма программы

а – правильный; б – с ошибкой

Если для тестирования задать значения переменных А=2, В=0, Х=3, будет реализован путь ace, т.е. каждый оператор программы выполнится один раз (рис. 1, а). Но, если внести в алгоритм ошибки – заменить в первом условии and на or, а во втором X > 1 на X < 1 (рис. 1, б), ни одна ошибка не будет обнаружена (см. табл. 1). Кроме того путь abd вообще не будет охвачен тестом и, если в нем есть ошибка, она также не будет обнаружена. В табл. 1 ожидаемый результат определяется по блок-схеме на рис. 1-а, а фактический по рис. 1-б.

Как видно из этой таблицы, ни одна из внесенных в алгоритм ошибок не будет обнаружена.

Таблица 1

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=3	X=2,5	X=2,5	неуспешно

2.2. Метод покрытия решений (покрытия переходов)

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

Для программы приведенной на рис. 1 покрытие решений может быть выполнено двумя тестами, покрывающими пути {ace, abd}, либо {aсd, abe}. Для этого выберем следующие исходные данные: {A=3, B=0, X=3} – в первом случае и {A=2, B=1, X=1} – во втором. Однако путь, где X не меняется, будет проверен с вероятностью 50%: если во втором условии вместо условия X > 1 записано X < 1, то ошибка не будет обнаружена двумя тестами.

Результаты тестирования приведены в табл. 2.

Таблица 2

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=3, B=0, X=3	X=1	X=1	неуспешно
А=2, В=1, Х=1	Х=2	Х=1,5	успешно

2.3. Метод покрытия условий

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

В рассматриваемом примере имеем четыре условия: {A>1, B=0}, {A=2, X>1}. Следовательно, требуется достаточное число тестов, такое, чтобы реализовать ситуации, где A>1, A£1, B=0 и B¹0 в точке а и A=2, A¹2, X>1 и X£1 в точке b. Тесты, удовлетворяющие критерию покрытия условий и соответствующие им пути:

а) A=2, B=0, X=4           ace

б) A=1, B=1, X=0          abd

Результаты тестирования приведены в табл. 3.

Таблица 3

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=4	X=3	X=3	неуспешно
A=1, B=1, X=0	X=0	X=1	успешно

2.4. Метод покрытия решений/условий

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

Недостатки метода:

q не всегда можно проверить все условия;

q невозможно проверить условия, которые скрыты другими условиями;

q недостаточная чувствительность к ошибкам в логических выражениях.

Так в рассматриваемом примере два теста метода покрытия условий

а) A=2, B=0, X=4           ace

б) A=1, B=1, X=0          abd

отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А>1 будет ложным, транслятор может не проверять условия В=0, поскольку при любом результате условия В=0, результат решения ((А>1)&(В=0)) примет значение ложь. Т.е. в варианте на рис. 1 не все результаты всех условий выполнятся в процессе тестирования.

Рассмотрим реализацию того же примера на рис. 2. Наиболее полное покрытие тестами в этом случае выполняется так, чтобы выполнялись все возможные результаты каждого простого решения. Для этого нужно покрыть пути aceg (тест А=2,В=0,Х=4), acdfh (тест А=3, В=1, Х=0), abfh (тест А=0, В=0, Х=0), abfi (тест А=0, В=0, Х=2)..

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

Рис. 2. Пример алгоритма программы

2.5. Метод комбинаторного покрытия условий

Критерий комбинаторного покрытия условий удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.

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

1. A>1, B=0.

2. A>1, B¹0.

3. A£1, B=0.

4. А£1, B¹0.

5. A=2, X>1.

6. A=2, X£1.

7. А¹2, X>1.

8. А¹2, X£1.

Для того чтобы протестировать эти комбинации, необязательно использовать все 8 тестов. Фактически они могут быть покрыты четырьмя тестами:

q A=2, B=0, X=4 {покрывает 1, 5};

q A=2, B=1, X=1 {покрывает 2, 6};

q A=0,5, B=0, X=2 {покрывает 3, 7};

q A=1, B=0, X=1 {покрывает 4, 8}.

Таблица 4

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=4	X=3	X=3	неуспешно
A=2, B=1, X=1	X=2	X=1,5	успешно
A=0,5 B=0, X=2	X=3	X=4	успешно
A=1, B=0, X=1	X=1	X=1	неуспешно

Порядок выполнения работы:

1. Разработать схему алгоритма в соответствии с вариантом. Обозначить буквами или цифрами ветви алгоритма.

2. Спроектировать тесты по принципу «белого ящика» методами покрытия операторов, решений, условий, решений/условий и комбинаторного покрытия условий. Если разные методы покрываются одним и тем же набором тестов использовать один набор.

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

4. Внести в алгоритм несколько ошибок.

5. Протестировать разработанную Вами программу. Результаты оформить в виде таблиц (см. таблицы 1 - 4).

6. Проверить все виды тестов и сделать выводы об их эффективности.

7. Оформить отчет по лабораторной работе.

8. Сдать и защитить работу.

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

1. Постановку задачи.

2. Блок-схемы программ.

3. Тесты.

4. Таблицы тестирования программы.

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

Контрольные вопросы

1. Этап реализации и тестирования программного продукта.

2. Виды тестирования.

3. Критерии выбора тестов.

4. Свойства тестов.

5. Критерии надежности программ.

6. Оценка надежности программ.

Варианты задания:

Задача 1.

Разработать программу решения уравнения , где a, b, c - любые вещественные числа.

Задача 2.

Разработать программу определения суммарной длины тени, которую отбрасывают на ось ОХ отрезки, параллельные этой оси и заданные координатами x начала и конца отрезка:

Задача 3.

Разработать программу исследования уравнений второго порядка с двумя неизвестными Ax²+2Bxy+Cy2+2Dx+2Ey+F=0. Программа должна определять вид графика: эллипс, парабола, гипербола, две пересекающиеся прямые, две параллельные прямые, две мнимые прямые.

Примечание. Вид прямой втрого порядка определяется по двум дискриминантам

большому: и малому .

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

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

Задача 4.

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

Задача 5.

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

Задача 6.

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

Примечание. Две прямые лежат в одной плоскости, если

, прямые параллельны если ,

где l = x ₂ - x ₁ , m = y ₂ - y ₁ , n = z ₂ - z ₁ (верхний индекс соответствует номеру прямой).

 

Лабораторная работа № 7

Тестирование программ методами «черного ящика»

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

1. Ознакомиться с лекционным материалом по теме "Тестирование программ" учебной дисциплины "Технология разработки программного обеспечения".

2. Изучить соответствующие разделы в литературе [1, 3].

Теория:

Тестирование по принципу «черного ящика»

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

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

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

Правильно выбранный тест подмножества должен обладать следующими свойствами:

1) уменьшать, причем более чем на единицу число других тестов, которые должны быть разработаны для достижения заранее определенной цели «приемлемого» тестирования:

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

Стратегия "черного ящика" включает в себя следующие методы формирования тестовых наборов:

¨ эквивалентное разбиение;

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

¨ анализ причинно-следственных связей;

¨ предположение об ошибке.

Эквивалентное разбиение

Основу метода составляют два положения:

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

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

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

Разработка тестов методом эквивалентного разбиения осуществляется в два этапа:

¨ выделение классов эквивалентности;

¨ построение тестов.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: