Автоматизация расчёта ожидаемой прибыли средствами VBA

Cells(5, 2).Value = " "

Cells(5, 3).Value = " "

Cells(1, 2).Value = " "

Cells(3, 3).Value = 0

Cells(3, 4).Value = 0

sss = Cells(3, 2).Value - Cells(3, 1).Value

    If sss >= 0 Then

    Cells(4, 1).Value = "Экономическая деятельность при данных параметрах убыточна"

    Cells(5, 2).Value = "убыток за 1 месяц="

    Cells(5, 3).Value = sss * (-1)

    End If

     If sss < 0 Then

    izd = Cells(3, 3).Value

    n = 0

    k = 0

    sss = Abs(sss)

    Do While izd >= 0 'Or (n < 60)

      izd = izd - sss

      k = k + 1

    Loop

Cells(3, 4).Value = sss

Cells(1, 2).Value = k

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

Также были созданы макросы для запуска и очистки таблиц и вынесены на панель быстрого доступа рис. 3.

- кнопка отвечающая за очистку таблиц расходов и доходов 

- кнопка отвечающая за вызов формы «Источники дохода»

- кнопка отвечающая за вызов формы «Расходы»

 

 

Рис.3. Панель быстрого доступа.

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

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

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

 

2.2. Выбор стратегии тестирования  и разработка тестов

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

Стратегия тестирования отвечает на вопросы [13]:

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

Тестирование  программного обеспечения (ПО) - это  процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом [11].

Для оптимизации набора тестов, т.е. для  подготовки такого набора тестов, который позволял бы при заданном их числе (или при заданном интервале времени, отведенном на тестирование) обнаруживать большее число ошибок в ПО, необходимо, во-первых, заранее планировать этот набор и, во-вторых, использовать рациональную стратегию планирования  тестов. Проектирование тестов можно начинать сразу же после завершения этапа внешнего описания ПО. Возможны разные подходы к выработке стратегии проектирования тестов, которые можно условно графически разместить между следующими двумя крайними подходами  (Рис. 4) [16].

                                

   

 

    Рис. 4. Спектр подходов к проектированию тестов.

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

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

Рассмотрим  подробнее методики тестирования «чёрный  ящик» и метод тестирования «белый ящик».

Метод тестирования «чёрный ящик». Долгое время основным способом тестирования было тестирование методом «черного ящика» - программе подавались некоторые данные на вход и проверялись результаты, в надежде найти несоответствия. При этом, как именно работает программа, считается несущественным. Отметим, что даже при таком подходе необходимо иметь спецификацию программы для того, чтобы было с чем сравнивать результаты [2].

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

Метод тестирования «белый ящик». Метод тестирования, которые изучают не только внешнее  поведение программы, но и ее внутреннее устройство (исходные тексты). Такие методики обобщенно называют тестированием «белого ящика». Назовем некоторых представителей этого класса методик: чтение программ, формальные просмотры программ, инспекции и т.п. Основной трудностью подобных методов является сложность отслеживания вычислений времени выполнения [13].

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

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

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

Теперь  проведём тестирование созданного нами программного продукта. Для тестирования приложения была выбрана комбинация методик «черного ящика» и «белого ящика». Ниже в таблице 1 сведены примеры тестов готового программного приложения «АС для расчёта ожидаемой прибыли»:

Критерии  тестирования.

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

2. Поиск  не рациональных методов вычисления, переменных объявленных, но неиспользованных в ходе работы процедур.

3. Проверка  соответствия введённых данных  на формы и отображения этих  данных  в ячейках таблиц, проверка  обмена данными между листами MS Excel.

4. Тестирования  арифметических и логических  вычислений в АС, тестирования проводилось путём подстановки данных, с которыми результат работы приложения заранее известен (т.е. просчитан).

5. Тестирования интерфейса АС.

Результаты прохождения критерия тестирования.

(+) -  тест пройден с положительным результатом.

(-) -  тест пройден с отрицательным результатом.

(0) - для данной процедуры  / объекта тест не предусмотрен.

 

Таблица 1

Тестирования «АС для  расчёта ожидаемой прибыли»
	Workbook «Доход_Расход. Xlsm»		UserForm1 «Расходы»			UserForm2 «Расходы»
№  кри-я. Тес-ния.	Workbook_Open	Worksheet_Activate «срок_окупаемости»	CommandButton1_Click «Добавить»	CommandButton2_Click «Очистить таблицу»	UserForm_Activate	CommandButton1_Click «Добавить»	CommandButton2_Click «Очистить таблицу»	UserForm_Activate
1.	+	+	+	+	+	+	+	+
2.	+	+	+	+	+	+	+	+
3.	+	+	+	+	+	+	+	+
4.	0	+	+	+	+	+	+	+
5.	0	0	+	+	0	+	+	0

 

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

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

 

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

Документация продукции (или, иными словами, эксплуатационная документация) фактически представляет собой часть этой продукции, поскольку без нее целевое применение последней невозможно или сильно затруднено. Стандартизация эксплуатационной документации позволяет не описывать в договоре или в техническом задании подробные требования к эксплуатационной документации, а сослаться на соответствующие стандарты или их разделы. Требования к составу и содержанию эксплуатационной документации на программу приведены в ГОСТах серии 19. Требования к составу и содержанию эксплуатационной документации на автоматизированную систему приведены в ГОСТах серии 34.

Руководство пользователя, руководство по эксплуатации, руководство  оператора – документ, назначение которого, предоставить людям помощь в использовании некоторой системы. Документ входит в состав технической документации на систему [13].

Структура и содержание документов руководство оператора, руководство программиста, руководство системного программиста регламентированы в ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 [22].

Структура и содержание документа «Руководство пользователя автоматизированной системы» регламентированы подразделом 3.4 документа РД 50-34.698-90 [19].

Руководства пользователя содержит следующие разделы:

1. Введение.

2. Назначение и условия применения.

3. Подготовка к работе.

4. Описание операций.

5. Аварийные ситуации.

6. Рекомендации по освоению.

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

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

Назначение  и условия применения. Автоматизированная система для расчёта ожидаемой прибыли  позволяет создать полноценные  базы  источников дохода и расхода, проанализировав базы, делает автоматические вычисления по расчёту ожидаемой прибыли, валовой прибыли, чистой прибыли, объёма капитала для закупки и срока окупаемости вложены инвестиций. Стоит отметить, что расчёты выполняются в двух временных диапазонах: за 1 месяц, а второй будет вводить сам пользователь приложения.