Автор работы: Пользователь скрыл имя, 04 Ноября 2012 в 10:34, дипломная работа
В данной выпускной квалификационной работе изложен процесс разработки и реализации информационной системы, автоматизирующей работу торгового предприятия, осуществляющего закупку, хранение и продажу строительных материалов. Система выполнена по клиент-серверной технологии, следовательно, является многопользовательской, поддерживает сколь угодно обширное территориальное распределение и способна соединить в целое склады, офисы и торговые точки предприятия, значительно повышая эффективность его работы
Главное меню (класс TMainMenu)
Интерфейсный элемент, называемый меню, предусмотрен стандартными соглашениями по требованию к интерфейсам прикладных программ и используется практически во всех Windows – приложениях. В Windows поддерживается два типа меню – строчное и всплывающее. Строчное меню (описываемое компонентом MainMenu) может содержать ряд вложенных меню. Всплывающее меню описывается компонентом PopupMenu. Для создания меню в С++ предусмотрено специальное средство – дизайнер меню.
Кнопка с графикой (класс TBitBtn)
Данный элемент используется для создания кнопок, на которых располагается битовая графика. Изображение на этой кнопке задается свойством Glyph. Основное событие кнопки – OnClick, возникающее при щелчке на ней. Именно в обработчике этого события записываются операторы, которые должны выполняться при щелчке пользователя на кнопке.
Метка с бордюром (класс TStaticText)
Данный компонент подобен компоненту Label, но обеспечивает возможность задания стиля бордюра – BorderStyle.
Кнопка с независимой фиксацией (класс TCheckBox)
Кнопка с независимой
фиксацией позволяет
Выбор из списков (TListBox)
Компонент ListBox отображает списки строк и позволяет пользователю выбрать в них нужную строку. Основное свойство компонента – Items. Заполнить его во время проектирования можно, нажав кнопку с многоточием около этого свойства в окне Инспектора Объектов. Во время выполнения работать с этим свойством можно, пользуясь свойствами и методами класса TStrings – Clear, Add и другими. Этот же класс позволяет поставить в соответствие каждой строке некоторый объект. Тогда выбор пользователем строки в списке можно программно соотносить с этим объектом.
Статический текст (класс TLabel)
С помощью статического интерфейсного элемента создаются заголовки для других интерфейсных элементов, разделители для групп элементов и др. Элемент этого типа обычно используется, когда необходимо отобразить текст, который не может быть отредактирован пользователем, например заголовков компонентов, которые не имеют собственного свойства Caption. Для отображения текста, который можно изменять используются компоненты Edit или Memo.
Строка редактирования (класс TEdit)
Строка редактирования – это прямоугольное окно, в котором возможен ввод и редактирование текста. Поддерживаются операции выделения текста, копирования, удаления, а также возможность ввода нескольких строк текста. Строка редактирования представлена двумя компонентами – Edit для однострочного редактора и Memo – для многострочного.
Многострочное окно редактирования (класс TMemo)
Данный компонент позволяет отображать, вводить и редактировать многострочные тексты. В компоненте Memo формат (шрифт, его атрибуты, выравнивание) одинаков для всего текста и определяется свойством Font.
Таблица строк (класс TStringGrid)
Данный компонент представляет собой таблицу, содержащую строки. Данные таблицы могут быть только для чтения или редактируемыми. Таблица может иметь полосы прокрутки, причем заданное число первых строк и столбцов может быть фиксированным и не прокручиваться. Таким образом, можно задать заголовки столбцов и строк, постоянно присутствующие в окне компонента. Каждой ячейке таблицы может быть поставлен в соответствие некоторый объект.
Навигатор (класс TDBNavigator)
Компонента предназначена для управления набора данных в таблице базы данных. Навигатор содержит набор кнопок, обеспечивающих выполнение различных операций с набором данных путем автоматического вызова соответствующих методов:
Для вывода на печать необходимых отчётов были использованы компоненты FastReport 4.0 одноимённой компании. Fast Reports, Inc — российская компания по разработке программного обеспечения для формирования отчетов. Основана в 1998 году. Потенциальные пользователи: Business Intelligence, администраторы корпоративных сетей, разработчики в средах Embarcadero RAD Studio (ex-Borland): Delphi, C++Builder, FireMonkey; Microsoft Visual Studio, Microsoft Access, Microsoft FoxPro, а также SyBase PowerBuilder, AvERP и др.
Мы не можем протестировать
программу абсолютно во всех аспектах,
поскольку число вариантов рабо
Тестирование часто неправильно воспринимается как процесс подтверждения корректности кода, что можно выразить таким высказыванием: «Протестируй это, чтобы убедиться, что тут все правильно». Иногда, однако, это является целью тестирования, особенно незадолго до отсылки продукта или при регрессионном тестировании (объясняется в следующей главе). Главная цель тестирования далека от подтверждения корректности. Его цель не в том, чтобы показать удовлетворительную работу программы, а в том, чтобы четко определить, в чем работа программы неудовлетворительна!
Время, использованное на тестирование, требует значительных затрат, и мы стараемся получить от этих затрат максимальную прибыль. Для данной тестируемой программы, чем больше дефектов будет найдено на каждый доллар зарплаты, тем выше выигрыш от вложений в тестирование. Следовательно, целью тестирования является обнаружение как можно большего числа дефектов с высоким уровнем важности. Резюмируя сказанное выше, перечислим «золотые правила» тестирования.
*Цель тестирования: максимизировать число и важность обнаруженных дефектов на каждый затраченный доллар.
Поэтому: начинайте тестирование рано.
Ограниченные возможности тестирования: тестирование может установить только присутствие дефектов, и никогда — их отсутствие.
Для установления факта отсутствия дефектов используйте доказательства корректности.
Тестирование оценивается более чем половиной времени, затраченного на проект. Наградой за нахождение дефекта на ранней стадии процесса является по крайней мере десятикратная экономия по сравнению с обнаружением этого же
дефекта на этапе интеграции или, еще хуже, после отправки заказчику. Следовательно, мы должны тестировать рано и часто.
Что касается идеальной гарантии качества в общем, тестирование кода должны проводить люди, не участвовавшие в его разработке. Когда инженер разрабатывает код, он создает для себя представление того, что код должен выполнять. Поэтому в то же время он разрабатывает типичную среду, в которой этот код должен выполняться. Можно смело считать, что код дает немного ошибок в этой конкретной среде. Следовательно, эта среда является основой тестов разработчика. Именно поэтому, когда человек тестирует свой собственный код, он часто прячет каждый дефект, который необходимо найти.
Модульное тестирование является ранним типом тестирования. Следующий уровень состоит из интегрального тестирования. Здесь валидируется общая функциональность каждой стадии конкретной программы. Наконец, система и различные приемосдаточные тесты валидируют финальный продукт, как описано в следующей главе. Уже разработанные варианты использования также берутся в качестве основы для некоторых из этих тестов. Типы тестирования и связь между ними проиллюстрированы на рисунке 4.3.
Рисунок 8.1 – Тестирование: общая картина
Типичный план модульного тестирования, основанный на стандарте IEEE 1008-1987, показан на рисунке 8.2. Далее объясняются шаги процесса модульного тестирования, который представлен на рисунке 8.1.
Входными данными для процесса планирования теста являются требования и детальный проект. Вспомните, что каждое требование соответствует хорошо определенному коду (функции, где возможно). Детальный проект обычно состоит из дополнительных классов и методов. Они также сказываются на качестве программы и должны быть протестированы в том же объеме, что и отдельные требования. Выходными данными процесса планирования теста является модульный план тестирования.
Следующим шагом является получение входных и выходных данных, ассоциирующихся с каждым тестом. Некоторые из этих данных могут быть уже получены из предыдущих тестов (например, предыдущие итерации, предыдущие версии продукта или предыдущие выпуски). Результатом на этом шаге является набор тестов [2], [3].
Наконец, тесты исполняются.
Рисунок 8.2 – План модульного тестирования
Далее приведены этапы, требуемые стандартом IEEE для модульного тестирования (1008-1987). Они расширяют только что описанный план модульного тестирования.
Спланировать общий подход, ресурсы и расписание.
Определить характеристики, которые следует протестировать, исходя из требований.
Обновить общий план.
Разработать набор тестов.
Реализовать обновленный план и проект.
Выполнить тестовые процедуры.
Проверить окончание работы.
Оценить тестирование и модули.
В данном пункте раскрываются основные принципы основных видов тестирования: «черноного ящика», «белого ящика», «серого ящика».
В этом разделе будет дано определение тестирования «черного», «белого» и «серого ящика». В остальной части главы будет описано, как планировать, проектировать и выполнять такие тесты.
Когда мы интересуемся исключительно тем, как программа или ее часть предоставляет соответствующие выходные данные, мы тестируем ее на каждое требование, используя подходящие входные данные. Это называется тестированием «черного ящика», поскольку мы не обращаем внимания на то, что находится внутри «ящика» (программы): «ящик» может быть «черным». Тесты «черного ящика» могут быть эффективны, если мы можем убедиться, что они исчерпывают все комбинации входных данных. Это докажет заказчику, что все требования удовлетворены. Однако никакое тестирование не охватывает всех возможностей [3].
Тестирование «черного ящика» похоже на тестирование моста путем проезда по нему нескольких комбинаций различных транспортных средств. Это неэффективно, поскольку нам нужно проверить и составные части моста, и то, как они объединены в систему. Последнее называется идеей «тестирования белого ящика». Тестирование «черного ящика» и «белого ящика» проиллюстрировано на рисунок 8.3.
Рисунок 8.3 – Тестирование «черного ящика», «серого ящика», «белого ящика»
Целью тестирования «белого ящика» является тестирование наиболее ненадежных путей программы. Для выполнения тестирования «белого ящика» мы сначала разбиваем проект программы на отдельные элементы и ищем пути и другие разбиения для управления и данных. Затем мы проектируем тесты, прослеживающие все или некоторые из этих путей, и проверяем все составные части. Более наглядным названием этих действий было бы «тестирование стеклянного ящика» [2].
Тестирование «серого ящика» рассматривает внутреннюю работу программы или модуля, но только до некоторой степени. Сюда могут быть также отнесены и некоторые аспекты тестирования «черного ящика».
Поскольку у нас нет возможности протестировать все комбинации входных данных, мы ищем представительные варианты тестов. Набор возможных вариантов тестов для трех переменных в финансовой программе — капитал, процентная ставка и оценка инфляции — изображен на рисунке 8.4. Проблема заключается в нахождении наилучшего представления бесконечного множества возможностей наиболее представительным определенным множеством. Разбиение равнозначности — это разбиение входных тестовых данных на подмножества таким образом, чтобы при условии успешного выполнения одного из них остальные элементы подмножества также с большой вероятностью прошли бы тест успешно. Например, при тестировании функции setName(String ) в классе GameCharacter успешное завершение тестового вызова setName( «Harry» ) означает, что у нас, вероятно, не будет проблем при тестировании функции setName() с любой строкой из пяти символов. Более того, мы, вероятно, можем расширить это разбиение равнозначности на «все имена не менее чем с одним и не более чем с maxNumCharsInName() символами».
Информация о работе Информационная система строительной компании