Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
isxodniki.docx
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
1.04 Mб
Скачать

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 были устранены, ошибки исправлены.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]