Автоматизированная система мониторинга зависимости заказов сезонных продуктов от климатических условий

• проверки того, что требования к проекту являются соответствующими требованиям ПО;

• автономное тестирование;

• системное тестирование;

• приёмочное тестирование;

• ревизии.

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

Сквозной контроль.

Эффективный  прием  оценки детальных внешних спецификаций – подготовить тесты и затем воспользоваться детальными внешними спецификациями для имитации поведения программы АСМЗЗСПКУ. Этот процесс часто называют сквозным контролем [10]  или прослеживанием.

Для проверки отдельных внешних функций должны быть выполнены следующие действия. Кто-то (не автор спецификаций) должен сначала построить “тесты на бумаге” для этой функции, т.е. список конкретных входных данных (допустимых и недопустимых). Вместе с автором спецификаций затем имитируют ввод этих данных в cистему, используя спецификации как описание поведения системы. Если оказывается, что спецификации описывают выходные данные или преобразование для какого-то набора входных данных недостаточно полно и правильно, это означает, что обнаружена ошибка.

Важно отметить, что цель всякого такого сеанса сквозного  контроля – обнаружить ошибки, но не исправлять их сразу.

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

В результате проведения теста было зафиксировано, что загруженные данные обрабатываются программой  согласно  предполагаемому результату, время обработки запроса пользователя отвечает указанному в ТЗ (не более 3 секунд при минимальной конфигурации, процессор Intel 586). При попытке осуществить некорректную операцию над данными не всегда выдаются сообщения об ошибках, либо не указано какие действия необходимо предпринять для правильной работы системы.

Для осуществления проверки требований к АСМЗЗСПКУ и требований пользователя на полноту (поиск всех пропущенных требований), т.е. удовлетворения всех требований пользователя в программном продукте,  и отсутствия неоднозначности применяется матрица трассировки.

Соответствие требований проверялось на ранних стадиях ЖЦ программного продукта. Используя матрицу  трассировки было установлено полное соответствие между требованиями пользователя и требованиями к ПО, неоднозначности  в требованиях обнаружены не были.  (см. ТЗ “Матрица трассировки”).

Цель теста внешней  функции – найти расхождения  между программой и её внешними спецификациями. Необходимым условием успешного  тестирования функций является наличие  чётких и точных внешних спецификаций. Если внешние спецификации неполны или неоднозначны, результаты тестирования не могут не быть такими же.

Внешние спецификации обычно разбиваются на отдельные внешние  функции (например, по типу входных  сообщений или команд пользователя), и после тщательного изучения каждой функции строятся тесты. Тесты должны строиться для всех входных условий и вариантов, а также на границах всех областей допустимых значений на входе и области изменения на выходе. Тесты должны также проверять поведение программы у функциональных границ и в случаях и в случаях ввода недопустимых или непредусмотренных данных.  Рассмотрим методологию проектирования тестов, основанную на функциональных диаграммах (cause-effect graphing).

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

Метод функциональных диаграмм [11], предлагает способ перевода спецификаций, написанных на естественном языке, на язык формальный. Это способствует проектированию высокорезультативных тестов, не страдающих избыточностью, и обнаруживающих случаи неполноты и неоднозначности во входных спецификациях. Метод предполагает анализ семантического содержания внешних спецификаций и перевод их на язык логических отношений между входными данными (ситуациями) и выходными данными и преобразованиями (эффектами), представленных в виде логической диаграммы (“и- или”-графа), называемой функциональной диаграммой.

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

Последовательность применения метода:

• Первый шаг: разбить внешние спецификации на отдельные функции, комбинаторные свойства которых и должны тестироваться;

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

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

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

 

Тестирование модуля.

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

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

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

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

• Был проверен текст программы на её чувствительность к отдельным особым значениям входных данных и были добавлены соответствующие тесты.

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

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

 

Комплексное тестирование – процесс поисков несоответствия системы ее исходным целям [11]. Это наиболее творческий из всех видов тестирования. Оно состоит из следующих шагов:

• Тестирование стрессов. Распространенный недостаток больших систем в том, что они функционируют как будто бы нормально при слабой или умеренной нагрузке, но выходят из строя при большой нагрузке и в стрессовых ситуациях реальной среды. Тестирование стрессов представляет попытки подвергнуть систему крайнему “давлению”.

Для проведения тестов осуществлялось одновременная работа нескольких экземпляров АСМЗЗСПКУ (20 экземпляров). В результате теста не было зафиксировано никаких отклонений в работе программы, но было отмечено определенное замедление работы АСМЗЗСПКУ.

• Тестирование объёма. В то время как при тестировании стрессов делается попытка подвергнуть систему серьёзным нагрузкам в короткий интервал времени, тестирование объема представляет собой попытку предъявить системе большие объёмы данных  (максимальный объм базы данных, 2 Мб) в течение более длительного времени.

Для проведения тестов использовались таблицы БД как можно больших размеров, использовались граничные значения числовых форматов. В результате теста также не было зафиксировано отклонений в работе программы, обработка запросов пользователя по АСМЗЗСПКУ осуществлялась с незначительным замедлением.

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

При работе с разными  типами накопителей данных (НГМД, НЖМД)  не было обнаружено ошибок, за исключением малой информативности ошибок возникающих при некорректной работе с НГМД.

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

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

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

Для проведения данного  теста были использованы персональные компьютеры различной конфигурации (ЭВМ на базе Intel 486, Pentium 100, Cyrix 350). В  результате проведения теста  была зафиксирована корректная  работы системы, но необходимо отметить, что работа на ПК на базе Intel 486 не рекомендуется, хотя и возможно таблиц предельно малых размеров.

На основание проведения вышеперечисленных тестов  можно  заключить, что созданная система корректно выполняет все функции, указанные в ТЗ.

 

 

 

 

 

 2.6  Руководство пользователя

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

 

 

Рис 2.13 Окно ввода пароля и выбора отдела

В программе используются следующие пароли по умолчанию:

Название	Пароль
ГЛАВНЫЙ СКЛАД	1
Центральный склад	2
Северный склад	3
Южный склад	4

 

При необходимости можно  изменить пароли по умолчанию выбором  пункта меню «Окна\Отделы»

В случае, если проверка пароля прошла успешно, то пользователь допускается к работе с автоматизированной системой мониторинга зависимости заказов сезонных продуктов от климатических условий (далее АСМСК), соответственно открывается гласное око программы (рис. 2.14)

 

Рис 2.14 Главное меню АСМ «Зависимости заказов сезонных продуктов от климатических условий»

    Работа с заказчиками (то есть покупателями товаров)  состоит в добавлении нового заказчика, удалении заказчика, редактировании атрибутов заказчика: код заказчика (для каждого заказчика код уникален), название заказчика,  телефон и факс заказчика,  e-mail и WWW, а также примечания.   Добавление заказчика производится следующим образом: пользователь выбирает пункт меню «Окна\Заказчики» и заполняет атрибуты заказчика (рис. 2.15).

Рис. 2.15 Окно для редактирования информации о заказчиках

Довольно часто возникает  необходимость работать с данными о товарах, заказчиках (покупателях), продажах и заявках на покупку в табличном режиме. Доступ к редактированию в табличном режиме осуществляется с помощью пункта «Окна \ В виде таблицы» главного меню программы (рис 2.16).

Рис. 2.16 Редактирование данных о товарах в табличном режиме.

Для редактирования таблицы  “Товары” нужно выбрать запись для редактирования, нажать клавишу Enter и изменить необходимую информацию. Измененные атрибуты товара автоматически изменяются в других таблицах.

          Окно “товары” представляет собой список товаров, которые проданы (или запланированы к продаже) заказчикам. Атрибуты этой таблицы следующие: уникальный код товара, цена, единица измерения, отдел (магазин) , примечания.

      Добавление  новой записи в таблицу осуществляется путем ввода информации о товаре в строки таблицы товары. Редактирование – нажатием соответствующей клавиши  на панели инструментов и изменении информации.

 

     Работа с продажами и заявками на покупку осуществляется в двум окнах : «Продажа» и  «Заявки на покупку».