67
На главной форме приложения (рисунок №9) находятся компоненты, описанные в
таблице №13.
Таблица №13
Компоненты формы модуля Tasks
Название
Тип
Описание
DBGrid1
TDBGrid
Табличный визуальный компонент для
вывода содержимого таблицы tasks из базы
данных.
TasksDS
TDataSource
Невизуальный компонент для передачи
данных из таблицы tasks к визуальным
компонентам.
DBNavigator1
TDBNavigator
Визуальный компонент, предназначенный
для добавления, изменения, удаления
информации из таблицы, а так же для
навигации по таблице tasks.
TasksQuery
TZQuery
Невизуальный компонент для выполнения
запросов к таблице tasks.
9 Модуль Clients.
Модуль Clients предназначен для считывания информации о клиентах из
базы данных, вывода на экран содержимого базы данных и редактирования
информации в базе данных.
Входными данными для модуля являются:
действия пользователя с использованием интерфейса формы;
содержимое таблицы clients в базе данных.
Исходный текст модуля приведен в приложении.
После отображения на экран формы модуля Clients, считываются и
выводятся на экран данные из базы данных о клиентах предприятия и ожидаются
действия пользователя.
В зависимости от команды пользователя происходит:
68
сохранение информации о новом клиенте;
изменение информации в базе данных об уже существующем
клиенте;
удаление из базы данных информации об уже существующем
клиенте;
изменение настроек отображения списка существующих клиентов
предприятия (отображение всех клиентов или только юридических лиц или
только физических лиц);
закрытие формы модуля Clients.
Операции добавления, изменения, удаления информации из таблицы, а так
же навигация по таблице происходит при помощи кнопок визуального
компонента класса TDBNavigator, представленного на форме модуля.
Отображение всех клиентов предприятия происходит при выборе пункта
«Все» меню «Фильтр».
Отображение только клиентов частных лиц происходит при выборе пункта
«Частные лица» меню «Фильтр».
Отображение только клиентов юридических лиц происходит при выборе
пункта «Юридические лица» меню «Фильтр».
Закрытие формы модуля происходит по нажатию на кнопку «X» в правом
верхнем углу формы модуля.
Выходными данными работы модуля в зависимости от команды
пользователя являются:
сохраненная в базу данных информация о новом клиенте;
измененная информация в базе данных об уже существующем
клиенте;
удаленная из базы данных информация об уже существующем
клиенте.
Форма модуля представлена на рисунке №10.
69
Рисунок №10.Форма модуля Clients
На главной форме приложения (рис. №10) находятся компоненты, описанные в
таблице №14.
Таблица №14
Компоненты формы модуля Clients
Название
Тип
Описание
DBGrid1
TDBGrid
Табличный визуальный компонент для
вывода содержимого таблицы clients из базы
данных.
ClientsDataSource
TDataSource
Невизуальный компонент для передачи
данных из таблицы clients к визуальным
компонентам.
DBNavigator1
TDBNavigator
Визуальный компонент, предназначенный
для добавления, изменения, удаления
информации из таблицы, а так же для
навигации по таблице clients.
ClientsQuery
TZQuery
Невизуальный компонент для выполнения
запросов к таблице clients.
N1
Пункт меню «Фильтр».
N2
Пункт меню «Все».
70
Название
Тип
Описание
N3
TMenuItem
Пункт меню «Частные лица».
N4
Пункт меню «Юридические лица».
События, обрабатываемые формой, представлены в таблице №15.
Таблица №15
События, обрабатываемые формой
Название
Назначение
procedure TClientsForm.N2Click(Sender: TObject);
Выбор пункта
меню «Все».
procedure TClientsForm.N3Click(Sender: TObject);
Выбор пункта
меню «Частные
лица».
procedure TClientsForm.N4Click(Sender: TObject);
Выбор пункта
меню
«Юридические
лица».
procedure
TClientsForm.ClientsQueryclient_is_organizationGetText(Send
er: TField; var Text: string; DisplayText: Boolean);
Событие получения
текста из поля
client_is_organizatio
n таблицы clients.
procedure
TClientsForm.ClientsQueryclient_is_organizationSetText(Sende
r: TField; const Text: string);
Событие отправки
текста в поле
client_is_organizatio
n таблицы clients.
10 Модуль NewContract.
Модуль NewContract предназначен для организации интерфейса для
добавления в базу данных информации о новом заключенном договоре.
Входными данными для модуля являются:
действия пользователя с использованием интерфейса формы;
71
содержимое таблицы clients в базе данных;
содержимое таблицы managers в базе данных.
Исходный текст модуля приведен в приложении на стр. .
После отображения на экран формы модуля NewContract, считываются и
выводятся на экран данные из базы данных о клиентах предприятия и
работающих на предприятии менеджерах и ожидаются действия пользователя.
В зависимости от команды пользователя происходит:
сохранение информации о новом заключенном договоре в базу
данных;
отмена изменений и отказ от их внесения в базу данных;
закрытие формы модуля NewContract.
Сохранение информации о новом заключенном договоре в базу данных
происходит при нажатии на кнопку «Добавить» на форме модуля.
Отмена изменений и отказ от их внесения в базу данных происходит при
нажатии на кнопку «Отмена» на форме модуля.
Закрытие формы модуля происходит по нажатию на кнопку «X» в правом
верхнем углу формы модуля или же при сохранении или отказе от сохранения
данных в базе данных.
Выходными данными работы модуля в зависимости от команды
пользователя являются:
сохраненная в базу данных информация о новом заключенном
договоре;
информация в базе данных, оставленная без изменений.
Форма модуля представлена на рис. №11.
72
Рисунок №11. Форма модуля NewContract
На форме модуля (рис. 11) находятся компоненты, описанные в таблице
№16.
Таблица №16
Компоненты формы модуля AddItemToOrder
Название
Тип
Описание
Button1
TButton
Кнопка «Добавить»
Button2
Кнопка «Отмена»
ComboBox1
TComboBox
Визуальный компонент для отображения
выпадающего списка клиентов.
ComboBox2
Визуальный компонент для отображения
выпадающего списка менеджеров.
ComboBox3
Визуальный компонент для хранения
скрытого списка идентификаторов клиентов.
ComboBox4
Визуальный компонент для хранения
скрытого списка идентификаторов
менеджеров.
Memo1
TMemo
Визуальный компонент для ввода описания
нового заключаемого договора.
Label1
TLabel
Надпись «Клиент»
Label2
Надпись «Менеджер»
73
События, обрабатываемые формой, представлены в таблице №17.
Таблица №17
События, обрабатываемые формой
Название
Назначение
procedure
TNewContractForm.FormShow(Sender:
TObject);
Событие отображения формы
модуля.
procedure
TNewContractForm.Button1Click(Sender:
TObject);
Нажатие на кнопку «Добавить».
procedure
TNewContractForm.Button2Click(Sender:
TObject);
Нажатие на кнопку «Отменить».
2.4 Контрольный пример реализации проекта и его описание
Тестировать программные приложения становится все труднее, поскольку
продолжает расти их техническая и функциональная сложность. К сожалению,
технология большинства процессов тестирования не успевает за новыми типами
приложений. Возникающее несоответствие подвергает риску качество программ и
бюджет проекта - процесс тестирования требует пересмотра.
Для большинства проектов этот процесс включает тестирование кода
приложения с ожидаемыми результатами. Затем разработчики «фиксируют»
приложение до тех пор, пока оно не обеспечит нужный результат. Либо
происходит корректировка ожидаемого результата, если возникла ошибка. Такой
подход фокусируется на коде приложения и его поведении на множестве
тестовых условий. Оказывается, что тщательное тестирование приложения
требует большого числа тестовых условий. При таком подходе к тестированию
предполагается, что качество приложения является функцией от количества
тестов - чем больше тестов, тем лучше качество.
74
· Неэффективность существующих технологий тестирования.
Традиционный подход был тщательно разработан для пакетных и
символьно-ориентированных диалоговых Кобол-приложений, но сегодня системы
радикально изменились: произошел переход от монолитных программ к
фрагментированным модулям на С, С++ и/или Java. Данный тип разработки
увеличивает число компонентов приложения и сложность их взаимодействия, что
снижает эффективность тестирования, основанного на коде.
Современные приложения имеют больше возможностей благодаря
взаимодействию многих модулей. Число тестовых условий, необходимых для
обращения к приложениям этого типа, может превысить бюджет и требования
плана. Это происходит из-за неэффективности процесса тестирования,
сосредоточенного на исследовании кода законченного приложения. Только
организации, способные выдержать такие затраты и гибкий временной график,
могут и дальше увеличивать продолжительность тестирования и отношение
времени тестирования ко времени разработки.
Как уже отмечалось, традиционные технологии тестирования
ориентированы на код законченного приложения (т.е. приложение может
тестироваться только после того, как оно собрано). Этот подход оказывается
неэффективным с точки зрения как качества выполняемой работы, так и бюджета.
Годы исследований показали - устранение ошибок при завершении процесса
разработки обходится дороже и требует больше времени, чем их исправление на
более ранних стадиях (анализ, проектирование и т.д.) [1]. Риск сбоя программного
обеспечения в результате этих изменений также увеличивается на завершающих
стадиях разработки приложения. Одновременно с увеличением цены и риска
уменьшаются возможности разработчика по внесению изменений. Очевидно, что
ошибки следует находить и исправлять как можно раньше.
Идея поиска ошибок в момент, когда закончено кодирование приложения,
предполагает размещение момента обнаружения ошибки непосредственно в
процесс разработки, где, опять-таки, цена и риск высоки, а вносить изменения уже
сложно. Несоответствие между стадией обнаружения, временем и ценой
исправления этих ошибок делает существующие процессы тестирования все
менее эффективными для современных приложений.
75
Традиционный подход приводит к выделению половины (а иногда и более)
бюджетных средств исключительно на тестирование [2]. Недостаток ресурсов и
плана существующих технологий тестирования может сталкиваться с
сокращением бюджета и срока разработки, заставляя в худшем случае вообще
отказываться от тестирования. Эта ситуация достаточно опасна, если учесть
возрастающую роль программного обеспечения в современном бизнесе.
Разработчикам нужен новый подход к тестированию, который отвечал бы
требованиям сложных приложений и предполагал исправление ошибок как можно
раньше. Это дает импульс к преобразованию процесса тестирования: от
тестирования по завершении кода, к тестированию на протяжении всего процесса
разработки.
· Новый подход к процессу тестирования.
Тестирование должно помочь находить и исправлять ошибки на самой
ранней возможной стадии. Пересмотр процесса тестирования включает
определение концептуальной структуры, организующей различные технологии
тестирования. Среда для этого процесса построена на концепции «стадийной
локализации» (stage containment), то есть обнаружении и исправлении ошибок на
той стадии, где они и появились.
Пересмотр процесса тестирования включает сопоставление стадии
обнаружения ошибки со стадией, на которой ошибка в системе впервые возникла.
В результате мероприятия поиска ошибок сдвигаются на ранние стадии процесса
разработки, когда вносить изменения проще и дешевле.
Тестирование по принципу «черного ящика»
Известны: функции программы.
Исследуется: работа каждой функции на всей области определения.
Основное место приложения тестов «черного ящика» - интерфейс ПО.
Эти тесты демонстрируют:
· Как выполняются функции программы.
· Как принимаются исходные данные.
· Как вырабатываются результаты.
· Как сохраняется целостность внешней информации.
76
При тестировании «черного ящика» рассматриваются системные
характеристики программ, игнорируется их внутренняя логическая структура.
Исчерпывающее тестирования, как правило, невозможно. Например, если в
программе 10 входных величин и каждая принимает по 10 значений, то
потребуется 1010 тестовых вариантов. Тестирование «черного ящика» не
реагирует на многие особенности программных ошибок.
Тестирование «черного ящика» (функциональное тестирование) позволяет
получить комбинации входных данных, обеспечивающих полную проверку всех
функциональных требований к программе. Программное изделие здесь
рассматривается как «черный ящик», чье поведение можно определить только
исследованием его входов и соответствующих выходов.
Во многих случаях определение таких тестовых вариантов основывается на
предыдущем опыте инженеров тестирования. Они используют свое знание и
понимание области определения для идентификации тестовых вариантов, которые
эффективно обнаруживают дефекты. Тем не менее систематический подход к
выполнению тестовых данных может использоваться как полезное дополнение к
эвристическому знанию.
Тестирование «черного ящика» обеспечивает поиск следующих категорий
ошибок:
· Некорректных или отсутствующих функций;
· Ошибок интерфейса;
· Ошибок во внешних структурах данных или в доступе к внешней базе
данных;
· Ошибок характеристик (необходимая емкость памяти и т.д.);
· Ошибок инициализации и завершения.
Одним из способов проверки программ является тестирование с
управлением по данным или по принципу «черного ящика». Под «чёрным
ящиком» понимается объект исследования, внутреннее устройство которого
неизвестно. Тестирование по принципу «черного ящика» - это тип тестирования, в
котором функциональные возможности программного обеспечения тестируются
без каких-либо ссылок на внутренний дизайн, код или алгоритм, используемый в
программе.