Работа с заказами
Для работы с заказами предлагается две закладки:
- Заказ;
- Все заказы.
В закладку “заказ” включены таблица “заказ” с атрибутами: номер
заказа, номер договора, номер счета, получено, оплачено, и поле для определения задолженности предприятия по оплате выполненных поставок. Пользователю предоставляется возможность добавления, редактирования и удаления записей. Все операции с записями осуществляются для определенного договора, указанного в закладке ассортимент договора. Все атрибуты таблицы обязательны к заполнению. Заполнение полей таблицы оплачено и получено можно осуществлять с выпадающего списка с двумя строками (да, нет).
В случае если долг по оплате поставок отсутствует, то поле “долг” принимает значение “нет”.
Закладка “все заказы” представляет собой таблицу с перечнем всех заказов сделанных по всем заключенным договорам. Что-либо в ней изменять пользователь не имеет возможности.
Печать.
Закладка “печать” используется для печати бланков договоров, заявок, заказов. Для выбора документа, который необходимо напечатать следует выбрать соответствующий флажок.
5. Испытания программного продукта.
Надежность программного обеспечения (ПО) есть вероятность его работы без отказов в течении определенного периода времени, рассчитанная с учетом стоимости для пользователя каждого отказа [9] . Надежность программного обеспечения как определяющий элемент его качества закладывается на этапе разработки и проектирования, реализуется на этапе реализации ПО [11]. Выбор критериев, которыми должна определятся надежность ПО, отыскание оптимальной по отношению к этим критериям его структуры, выбор режима работы ПО – вот далеко не полный перечень тех проблем, которые должны быть решены на этапе создания и реализации ПО до его эксплуатации. Поэтому для обеспечения надежности ПО зачастую используют такие термины, как доказательство, тестирование, отладка, контроль и испытание, которые часто используются как синонимы, поэтому приведём эти определения:
¨ Тестирование (testing) - процесс выполнения программы или части программы, с намерением или целью найти ошибки;
¨ Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы.
¨ Контроль (verification) - попытка найти ошибки в тестовой, или моделируемой среде;
¨ Испытание (validation) - попытка найти ошибки, выполняя программу в заданной реальной среде;
¨ Аттестация (certification) - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом;
¨ Отладка (debugging) не является разновидностью тестирования. Хотя “отладка” и “тестирование” часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование – деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки.
Испытания программного продукта производятся с использованием следующей справочной литературы:
1. ГОСТ Р28195-89 Оценка качества программных средств.
2. ISO/IEC 9126 : 1991 Information Technology Software Product Quality Characteristics.
3. Стандарты разработки ПО ESA PSS-05-0-1991.
5.2. Краткий обзор верификации .
Верификация обозначает:
¨ действие по проверке, инспекции, тестированию, контролю процессов, определённых требованиями ANSI –78
¨ процесс определения: удовлетворяет ли продукт данной фазе ЖЦ ПО требованиям, сформулированным на протяжение предыдущих фаз;
¨ формальное доказательство корректности программы.
¨ верификация необходима для обеспечения качественных характеристик продукта.
Ряд определений, приведённый ниже, охватывает вторую сторону тестирования: типы ошибок, которые предполагается обнаружить, и стандарты, с которыми сопоставляются тестируемые программы.
¨ Тестирование модуля или автономное тестирование – контроль отдельного программного модуля, обычно в изолированной среде (т.е. изолированно от всех остальных модулей). Тестирование модуля иногда также включает математическое доказательство.
¨ Тестирование сопряжений – контроль сопряжений между частями системы (модулями, компонентами подсистемами).
¨ Комплексное тестирование – контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.
¨ Тестирование приемлемости – проверка соответствия программы требованиям пользователя.
Верификацию, тестирование и испытания разрабатываемой системы будем производить в соответствии со стандартами ES-PSS-05.
Процесс верификации включает в себя:
¨ технические проверки, сквозные контроли и инспекции ПО;
¨ проверки того, что требования к ПО соответствуют требованиям заказчика;
¨ проверки того, что требования к проекту являются соответствующими требованиям ПО;
¨ автономное тестирование;
¨ системное тестирование;
¨ приёмочное тестирование;
¨ ревизии.
Исходя из выше изложенного, были проведены тестовые испытания программного продукта.
Эффективный прием оценки детальных внешних спецификаций – подготовить тесты и затем воспользоваться детальными внешними спецификациями для имитации поведения системы. Этот процесс часто называют сквозным контролем [10] или прослеживанием.
Для проверки отдельных внешних функций должны быть выполнены следующие действия. Кто-то (не автор спецификаций) должен сначала построить “тесты на бумаге” для этой функции, т.е. список конкретных входных данных (допустимых и недопустимых). Вместе с автором спецификаций затем имитируют ввод этих данных в cистему, используя спецификации как описание поведения системы. Если оказывается, что спецификации описывают выходные данные или преобразование для какого-то набора входных данных недостаточно полно и правильно, это означает, что обнаружена ошибка.
Важно отметить, что цель всякого такого сеанса сквозного контроля – обнаружить ошибки, но не исправлять их сразу.
Используя данный прием тестирования, были протестированы запросы осуществляемые к базе данных (БД) созданной системы. Для этого на вход подавались различные запросы к БД (См. приложение B).
В результате проведения теста было зафиксировано, что корректные запросы обрабатываются БД согласно предполагаемому результату, время обработки запроса отвечает указанному в ТЗ (не более 3 секунд при минимальной конфигурации, процессор Intel 586). При попытке осуществить некорректный запрос к БД не всегда выдаются сообщения об ошибках, либо не указано какие действия необходимо предпринять для правильной работы системы.
5.3.2. Трассировка требований к ПО и требований пользователя.
Для осуществления проверки требований к ПО и требований пользователя на полноту (поиск всех пропущенных требований), т.е. удовлетворения всех требований пользователя в программном продукте, и отсутствия неоднозначности применяется матрица трассировки.
Соответствие требований проверялось на ранних стадиях ЖЦ программного продукта. Используя матрицу трассировки было установлено полное соответствие между требованиями пользователя и требованиями к ПО, неоднозначности в требованиях обнаружены не были. (см. ТЗ “Матрица трассировки”).
5.3.3. Тестирование внешних функций.
Цель теста внешней функции – найти расхождения между программой и её внешними спецификациями. Необходимым условием успешного тестирования функций является наличие чётких и точных внешних спецификаций. Если внешние спецификации неполны или неоднозначны, результаты тестирования не могут не быть такими же.
Внешние спецификации обычно разбиваются на отдельные внешние функции (например, по типу входных сообщений или команд пользователя), и после тщательного изучения каждой функции строятся тесты. Тесты должны строиться для всех входных условий и вариантов, а также на границах всех областей допустимых значений на входе и области изменения на выходе. Тесты должны также проверять поведение программы у функциональных границ и в случаях и в случаях ввода недопустимых или непредусмотренных данных. Рассмотрим методологию проектирования тестов, основанную на функциональных диаграммах (cause-effect graphing).
Тестирование функций – процесс контроля, поскольку оно обычно выполняется в моделируемой среде (в противоположность обстановке реальной). Другими словами, тестирование функций обычно выполняется для компонент системы прежде, чем она будет собрана воедино. Например, могут быть недоступны определённые устройства ввода-вывода, вследствие чего потребуется написать специальные программы для имитации их работы, могут отсутствовать или быть неполными отдельные компоненты программного обеспечения, что также потребует имитации или применения вспомогательных программ.
Метод функциональных диаграм [11], предлагает способ перевода спецификаций, написанных на естественном языке, на язык формальный. Это способствует проектированию высокорезультативных тестов, не страдающих избыточностью, и обнаруживающих случаи неполноты и неоднозначности во входных спецификациях. Метод предполагает анализ семантического содержания внешних спецификаций и перевод их на язык логических отношений между входными данными (ситуациями) и выходными данными и преобразованиями (эффектами), представленных в виде логической диаграммы (“и- или”-графа), называемой функциональной диаграммой.