Разработка програмного обеспечения автоматизированного рабочего места калькулятора

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

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

     Структурный метод (метод белого или стеклянного  ящика)

     Тестирование  методом "Белого ящика" (white box) предполагает обработку тестируемой программы  как "прозрачного объекта" в  отличие от метода "Черного ящика" данный метод основан на использовании  определенных знаний программного кода, необходимых для контроля корректности данных на выходе. Тест является правильным только в том случае, когда специалист, тестирующий программное обеспечение (ПО), знает, что конкретно должна делать программа. К методам "белого ящика" относятся методы покрытия операторов, покрытия решений, покрытия условий и метод комбинаторного покрытия условий. Все эти методы базируются на том, что при выполнении тестов должны выполняться те или  иные конструкции в тексте программы. Тестирование методом "белого ящика" не обрабатывает случайные ошибки, но наряду с этим весь видимый код  должен быть удобочитаемым. Основной трудностью подобных методов является сложность  отслеживания вычислений времени выполнения. 

     Поведенческий метод "Черного ящика"

     Тестирование  методом "Черного ящика" (black box) предполагает обработку системы  как "непрозрачного объекта". Основная цель – выяснение ситуаций, в  которых поведение программы  не соответствует ее спецификации. Тестовые данные генерируются на основе функциональной спецификации программы, они имеют граничные значения. Поэтому для тестирования функций  программы (в случае слишком большого числа вариантов тестов) достаточно протестировать граничные значения и некоторые случайные промежуточные  значения входных данных. Таким образом, знание внутренней структуры в явном  виде не используется. Тестирование этим методом обычно подразумевает проверку функциональных возможностей. Классические примеры – это эквивалентное  разбиение и тестирование областей (domain testing). При тестировании программного обеспечения методом "Черного ящика" специалист по тестированию ПО знает только набор вводимых параметров и ожидаемые на выходе результаты, каким образом программа достигает этих результатов, ему не известно. Он также никогда не проверяет программный код и не нуждается в дополнительном знании программы, кроме ее технического описания. К методам “черного ящика” относятся метод эквивалентных разбиений, анализ граничных условий, метод функциональных диаграмм.

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

     Основным  же преимуществом тестирования по методу "чёрного ящика" является его  объективность. Т.е. потенциальные ошибки, которые могут быть выявлены методом  «белого ящика» требуют практического  подтверждения, что они действительно  являются ошибками и что существует путь реализовать эти ошибки (т.е. ошибка не отсекается на каком-либо другом уровне проверок), что зачастую проще  выполняется именно функциональными  методами, как и в случае метода "чёрного ящика". 
 
 

     Метод регрессивного тестирования

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

     Регрессионное тестирование имеет большое значение потому, что внесенные в программу  коды изменений и исправлений  ошибок, как правило, более подвержены ошибкам, чем исходные коды программы. Например, в книге приведены результаты исследований, проведенных в одной  крупной компании, занимающейся сопровождением программ. В результате этих исследований выяснилось, что даже однострочное изменение программы с вероятностью 55% сохраняло ошибку или вносило  новую. 

     Метод "Серого ящика"

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

     Метод опытной эксплуатации

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

     Тестирование  эргономичности

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

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

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

 

     

     ГЛАВА II. ПРАКТИЧЕСКАЯ ЧАСТЬ РАБОТЫ 

     Весь  процесс разработки программы «АРМ калькулятора» включает в себя пять основных фаз проектирования: анализ требований, проектирование, разработка функций приложения, тестирование и  методы тестирования, ввод системы  в эксплуатацию.

     2.1. Концептуальная фаза

 
     

1. На первом этапе  была поставлена главная цель выполнения выпускной квалификационной работы – создание работоспособного программного продукта, из чего следовала формулировка задач: определить программное обеспечение, написать программный код, написать пояснительную записку.
2. Были изучены рекомендации руководителя проекта: в программе необходимо было реализовать полный набор функций.
3. Определение затраченных ресурсов.
4. Сравнительная оценка альтернатив выполнения работы.

     Программа калькулятора, должна обладать следующими функциями:

• Б.Д. с группой ингредиентов
• Калькуляционная карта
• Редактирование и добавление ингредиентов
• Вывод меню на печать
• Простой и понятный интерфейс
• Работа с Б.Д.
• Оптимизация программы калькулятора
• Использование минимальных требований компьютера.

 

     2.2 Моделирование. 

     Реализация  основных функций.

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

     На  изображении мы видим, что программа  имеет такие функции как:

• Добавить блюдо
• Удалить блюдо
• Выход на все блюда
• Калькуляционную карту
• Панель для редактирования ингредиентов блюда
• Главное меню.

     Компонент TMainMenu

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

     1) помещение TMainMenu на форму, 

     2) вызов Дизайнера Меню через  свойство Items в Инспекторе Объектов

     3) определение пунктов меню в  Дизайнере Меню.

     Этот  компонент доступен из модуля MENUS, и  находится на странице Палитры компонентов Standard

     Этот  компонент представляет главное  меню формы и наследует все  методы и свойства TMenu. Особенность  его в том, что в нем реализован сложный механизм объединения меню. Это необходимо по следующим причинам:

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

      Также был использован компонент AlphaControls7, который предает программе  дружественный интерфейс, и предоставляет  возможность менять оформление программы. Он дает возможность устанавливать  дополнительные кнопки со специальными расширениями.  А помощью панели внизу таблицы можно редактировать БД. Добавлять записи, удалять, перемещать и так далее.  
 

     

     Так же были использованы компоненты ADOConnection, ADOTable, ADOQery и DataSource. Эти компоненты позволяют работать через программу с Б.Д.. Вообще компоненты ADO (Active Data Objects) - это высокоуровневый компонент технологии доступа к данным от Microsoft. (т.н. MDAC - Microsoft Data Access Components) Другие компоненты - это старый добрый ODBC и новый низкоуровневый интерфейс OLE DB.

     Данными для ADO могут быть как привычные  таблицы Access или серверные базы MS SQL или Oracle, так и несколько экзотичные Microsoft Active Directory Service, XML-файлы и т.п.