
- •Введение
- •1. Обоснование разработки системы
- •1.1 Описание предметной области
- •1.2 Анализ аналогов и прототипов
- •1.3 Подтверждение необходимости и актуальности проектирования
- •1.4 Анализ и выбор средств решения поставленной задачи
- •1.5 Перечень функций разрабатываемой системы
- •2. Разработка проекта системы
- •2.1 Разработка структурной схемы системы
- •2.2 Проектирование баз данных
- •2.3 Разработка и описание рабочих алгоритмов
- •2.4 Требования к системам передачи информации
- •2.5 Описание технологии обработки информации
- •2.6 Разработка интерфейса взаимодействия пользователя с системой
- •3. Реализация проекта системы
- •3.1 Разработка рабочей программы
- •3.2 Реализация графа диалога пользователей
- •3.3 Тестирование программных средств
- •3.4 Оценка надежности
- •3.5 Разработка сопроводительных документов
- •4. Технико-экономическое обоснование разработки
- •5. Рекомендации по безопасности жизнедеятельности и экологии
- •Заключение
- •Список использованных источников
- •Приложение б
- •Приложение в
3.2 Реализация графа диалога пользователей
При работе пользователей с компонентами программного комплекса должны быть выполнены следующие требования: первое – интерфейс модулей должен быть простым и понятным пользователям; второе – пользователи, не имеющие соответствующие права, не должны иметь возможности работать с модулями системы.
Первое требование выполняется при помощи интуитивно понятных элементов управления, системы подсказок и системы помощи при работе с системой. На рисунке 3.4 представлена главная форма модуля тестирования.
Рисунок 3.4 – Главная форма модуля тестирования
Из рисунка видно, что интерфейс прост и понятен. В верхней части окна помещается вопрос. В нижней – варианты ответа, которые вводит пользователь. После ответа на вопрос пользователь переходит к следующему вопросу. Если это разрешено, то возможен переход к предыдущему вопросу.
Кнопки инструментальной панели продублированы пунктами главного меню. Такое построение интерфейса используется мо многих известных приложениях, поэтому работа с модулями программного комплекса не должна вызвать затруднения даже у начинающих пользователей компьютера.
Чтобы предупредить возможные ошибки пользователя, связанные, например, с преждевременным пользователем из сеанса тестирования, реализована система информирования пользователя (рисунок 3.5)
Рисунок 3.5 – Реакция программы на преждевременное завершение работы
Чтобы предотвратить несанкционированный доступ пользователей не имеющих на это право к модулям редактирования тестов и администрирования реализована принудительная аутентификация при входе в приложение.
Рисунок 3.6 – Пример запуска редактора тестов
Интерфейс приложения фактически не скрыт, но загрузка данных в компоненты отображения не производится. Если вход в систему успешный, то все необходимы данные будут загружены в компоненты отображения.
Примеры остальных форм и реакции на действия пользователей представлены в приложении Б.
3.3 Тестирование программных средств
В настоящее время разработано достаточно много разнообразных методов отладки программного обеспечения. Выделим некоторые:
1. Синтаксическая и семантическая отладка.
2. Тестирование программ как "черного" или "белого" ящика.
3. Статическое и динамическое тестирование.
4. Разрушающие и неразрушающие методы.
5. Методологические способы отладки.
6. Другие приемы отладки.
В зависимости от объекта отладки методы и системы отладки можно разделить на две части: синтаксическую и семантическую.
Синтаксическая отладка начинается при первом вводе программы в ЭВМ для трансляции или сразу для выполнения и заканчивается получением текста программы, не содержащего конструкций языка программирования, противоречащих его синтаксису.
Семантическая отладка начинается в тот момент, когда программа стала синтаксически правильной и пригодна для выполнения на ЭВМ. Целью семантической отладки является поиск и корректировка программы таким образом, чтобы она выполняла заданную функцию (преобразование входных данных в выходные) в соответствии с требованиями к программе.
Наиболее распространенным и традиционным методом отладки программ является тестирование программ.
Подходы к решению задачи тестирования в зависимости от того, каким образом они учитывают или рассматривают структуру исследуемой программы, можно разделить на два направления:
1. Тестирование программы как "черного ящика" (при тестировании не учитывается внутренняя структура программы, а принимаются во внимание лишь значения входных и выходных данных);
2. Тестирование программы как "белого ящика" (при тестировании принимается во внимание также и внутренняя структура программы).
При тестировании программ по методу "белого ящика" тестовые данные для программы формируются с учетом ее внутренней структуры. При этом задача тестирования преобразуется в задачу обеспечения полноты проверки внутренней структуры, которая отражает алгоритм функционирования. Внутренняя структура может быть представлена в виде управляющего ориентированного графа, где вершины - это отдельные операторы, а дуги - возможные передачи управления между операторами.
Тогда тестирование может заключаться в проверке всех дуг такого графа, всех выходов из каждой вершины графа, маршрутов обработки инфоpмации внутри программы. При тестировании по этому методу программист располагает информацией о пути прохождения вычислительного процесса по графу и выбирает тесты таким образом, чтобы обеспечить проверку графа по заданному критерию. Также проверяются значения выходных данных, вырабатываемых программой. Поэтому тестирование по методу "белого" ящика в общем случае более глубокое и эффективное, чем по методу "черного" ящика.
Можно указать три вида тестирования, учитывающего внутреннюю структуру программы:
- тестирование путей;
- тестирование ветвей;
- тестирование операторов.
Тестирование путей программы предполагает выполнение всех возможных или подмножеств путей, существующих в программе, по крайней мере один раз. Путь программы определяется значениями входных данных. Каждый путь программы состоит из последовательности линейных участков, на которых расположены только безусловно выполняемые команды; линейные участки связаны командами условного перехода. Если команды условного перехода не коppелиpуют друг с другом по данным, то число различных реализуемых путей программы может достигать числа 2 в степени n, где n - число команд условных переходов, каждая из которых имеет два выхода ("да" и "нет"). Ясно, что даже для небольших программ достичь полного тестирования путей невозможно.
Тестирование ветвей предполагает, по крайней мере, однократное выполнение каждой ветви отлаживаемой программы. Ветвь программы - это последовательность безусловно выполняемых команд, заканчивающихся командой условного перехода (максимальный участок с одним входом и одним выходом). При тестировании ветвей можно достичь полного перекрытия всех ветвей относительно небольшим числом тестов.
Тестирование операторов состоит в выполнении, по крайней мере, один раз каждого оператора программы независимо от пути или ветви программы, на которых он находится. Это наиболее простой из трех перечисленных способов тестирования.
В зависимости от способа получения результатов выполнения программы все подходы к тестированию можно также разделить на два направления.
1. Если программа во время отладки непосредственно не выполняется, то такой подход называется статическим. При этом исследуется текст или код программы с целью выявления конструкций, которые можно интерпретировать как неправильные, для их последующего исправления;
2. Если программа в процессе отладки выполняется, то такой подход называется динамическим. При этом исследуются выходные и промежуточные значения переменных, и если они отличаются от предполагаемых, то делаются необходимые корректировки в программе, и процесс выполнения программы повторяется.
При статическом тестировании проводится достаточно глубокий и полный анализ управляющих и информационных связей программы. Такой анализ основан на исследовании преобразований управления и данных, выполняемых каждым оператором программы, и затем объединении этих преобразований в единую цепочку. В результате формируются единые потоки управления и данных, а сам метод анализа назван потоковым.
Потоки управления и данных представляются в виде управляющего и информационного графов соответственно.
По характеру воздействия на текст программы методы отладки классифицируются как неразрушающие и разрушающие.
неразрушающий метод не предполагает модификации программы во время отладки. Это, как правило, все статические методы и часть динамических. При статических методах отладки нет в принципе необходимости во внесении изменений в отлаживаемую программу, т.к.
всегда можно имитировать такое изменение с помощью других программ, обеспечивающих процесс отладки.
разрушающий метод отладки предполагает модифицирование программы на время отладки. примерами такой модификации могут быть:
- расширение программы макрокоманды отладки;
- добавление в программу отладочных операторов;
- создание контрольных точек;
- включение в текст операторов распечатки промежуточных данных;
- изменение участков программы или отдельных команд.
После завершения процесса отладки такие модифицированные участки программ необходимо восстанавливать. В случае обнаружения новых ошибок необходимо снова модифицировать программу и т.д. Таким образом, разрушающие методы отладки "провоцируют" внесение ошибок в программу в процессе отладки, хотя и позволяют эффективно исследовать программу.
Одной из наиболее распространенных и эффективных дисциплин является разработка программ методом сверху вниз, или нисходящая разработка.
При нисходящей разработке первоначально создаются подпрограммы, находящиеся на верхних "этажах" схемы иерархии (схемы связи) подпрограмм, т.е. те, которые включают в работу весь программный комплекс и осуществляют вызов других подпрограмм.
Существует также разработка программ методом снизу вверх или восходящая разработка, которая предполагает вначале разработку и отладку подпрограмм самых низких уровней, затем более высоких. Однако этот подход имеет более узкую область эффективного применения, чем нисходящая разработка.
Кроме рассмотренных, существуют и другие приемы отладки программ.
Объект испытаний. Объектом испытаний является система удаленного тестирования знаний, применяемая для тестирования пользователей по сети.
Цель испытаний. Целью проведения испытаний является выявление случаев некорректной работы системы и их устранение. Испытания проводятся согласно с ГОСТ 19.301-79 «Программа и методика испытаний».
Требования к программе. Программный комплекс проверки знаний должен выполнять обозначенные в техническом задании функции и не приводить к сбоям в случае ввода пользователем некорректной информации.
Состав и порядок испытаний.
Порядок и результаты испытаний приведены в таблице 3.1.
Таблица 3.1 Состав, порядок и результаты испытаний
№ |
Действие |
Ожидаемый результат |
Действительный результат |
1 |
Ввод неверного пароля |
Отказ в доступе |
Отказ в доступе |
2 |
Попытка входа без пароля |
Отказ в доступе |
Отказ в доступе |
3 |
Ввод неверного логина |
Отказ в доступе |
Отказ в доступе |
4 |
Попытка тестирования пользователем, не имеющим на это прав |
Отказ в доступе |
Отказ в доступе |
5 |
Попытка входа в модуль администрирования или редактор тестов пользователя, не имеющего на это прав |
Отказ в доступе, предложения повторного входа |
Отказ в доступе, закрытие приложения |
6 |
Попытка добавления в БД некорректного файла тестового набора |
Вывод сообщения об ошибке |
Вывод сообщения об ошибке |
Таблица 3.1(продолжение)
№ |
Действие |
Ожидаемый результат |
Действительный результат |
7 |
Удаление пользователя |
Будет удален только пользователь, результаты останутся |
Удалены и пользователь, и результаты |
8 |
Закрытие модуля тестирования во время сеанса |
Вывод предупреждения о незаконченном сеансе |
Вывод предупреждения о незаконченном сеансе |
9 |
Переход пользователя при тестировании к следующему вопросу без ответа на текущий |
Переход к следующему вопросу, занесение в базу ответа как неправильный |
Ошибка доступа к базе данных |
Выявленное в ходе тестирования несоответствие ожидаемого результата и действительного по пунктам 5 и 9 были устранены, ошибки исправлены.
Проведенное тестирование компонентов программного комплекса позволило выявить и исправить существующие ошибки в работе. В конечном итоге получен готовый работоспособный продукт.