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

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

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

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

Таблица 1. Классификация тестовых оболочек

*) Комментарии к отдельным разделам таблицы.

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

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

Использование древовидных структур хранения информации является естественным решением для такого типа данных. Но в этом случае перед программистом встает задача выбора алгоритма хранения древовидной структуры данных в линейной области компьютерной памяти, и чаще всего разработчики выбирают либо древовидную структуру файловой системы, либо упаковывают дерево данных в линейную структуру. Как правило, это обычная таблица, каждый элемент которой имеет ссылку на родительский элемент. Плюсами такого варианта является простота реализации (обычная рекурсия) и низкие затраты памяти на дополнительную информацию, обеспечивающую древовидные связи, а минусом — низкая скорость обработки, так как для того, чтобы восстановить хотя бы одну ветвь такого дерева, надо столько раз просматривать таблицу в поисках всех элементов с одинаковым предком, сколько новых элементов будет найдено. Усовершенствовать этот алгоритм можно, добавив к связям «потомок-> предок» связи типа «предок->потомки», но такой вариант резко увеличивает накладные расходы памяти для хранения данных. Альтернативным вариантом представления древовидных связей в линейной структуре является байтовая последовательность. С ее помощью можно добиться приличной производительности и относительно низких накладных расходов на память, но за счет накладываемых ограничений на максимальное число потомков одной вершины дерева и максимальную глубину вложенности всего дерева. Реализуется такой алгоритм достаточно просто.

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

2.6. Системы, построенные по Интернет-технологии, обладают специфичным и существенным недостатком: при отсутствии у тестируемого быстрого Интернет-канала до сервера, на котором расположена сама Система, тестирование не может происходить в реальном времени и не обеспечивает должного качества проверки знаний. Поэтому очень полезно реализовать возможность представления выбранных тестов в виде автономной подсистемы, которая способна проводить тестирование без связи с Интернетом и основным сервером. Такую подсистему удобно разместить на время тестирования, например, на сервере соответствующего учебного центра, а затем полученные результаты отправить для импортирования в главную Систему.

2.7. и 2.8. Формирование и представление тестовых заданий — одна из главных функций системы тестирования знаний. От качества ее исполнения зависит качество проверки знаний. Как правило, задания формируются в каком-нибудь известном формате (текстовый, RTF, XML, HTML). Это упрощает их дальнейшую визуализацию, но усложняет контроль над правильностью представления данных. Ужесточить этот контроль можно, позволив пользователю — разработчику тестовых заданий представлять только определенные элементы (текст, рисунки, элементы управления и т.п.) и размещать их в заранее заготовленных шаблонах, обеспечивающих не только внешний вид всего задания, но и виды взаимодействия между введенными элементами. Причем конструирование этих шаблонов можно опять же возложить на плечи самих пользователей, выбрав соответствующий формат и используя продукты третьих фирм либо разработав свой и предоставив пользователю соответствующий инструментарий.

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

3.3. и 3.4. Каждый пользователь системы обычно авторизуется с помощью своего пароля, и Система узнает пользователя тогда, когда введенный им пароль совпадает с паролем, хранимым в самой Системе. Если пароль хранится в незашифрованном виде, то он практически незащищен от несанкционированного доступа. Поэтому более правильно хранить пароль в закодированном виде. В качестве кодирования можно применить какой-нибудь алгоритм шифрования, но тогда все равно можно попасть в Систему, узнав ключ шифра. Поэтому более правильным является использование какой-нибудь хэш-функции, не имеющей обратного алгоритма (DES, TripleDES, MD5). В этом случае Система сверяет уже не сам пароль, а закодированный вариант, хранящийся на сервере, и строку, которая получается кодированием только что введенного пользователем пароля. Минусом (а может даже и плюсом) этого метода является невозможность восстановления старого пароля, если пользователь его забыл. Но кто мешает установить новый пароль?

Если система разработана по Интернет-технологии, то каким бы образом не был закодирован пароль, последовательность, передаваемая на сервер, при авторизации достаточно просто «подслушивается», а затем воспроизводится при попытке взлома. Поэтому для обеспечения надежности передаваемых данных можно пользоваться так называемой «challenge» авторизацией. Ее суть заключается в следующем: после поступления запроса от клиента на проведение авторизации, сервер генерирует случайную последовательность и передает ее клиенту, после чего клиент производит кодирование авторизируемых данных и этой последовательности как единого целого и отсылает назад — серверу, который, в свою очередь, сравнивает полученный код с данными, полученными в результате выполнения той же последовательности кодировки. Этот способ хорош тем, что по сети каждый раз передаются новые данные, и их «подслушивание» не дает возможности доступа в Систему.

3.5. После завершения очередного диалога клиент-сервер, Система обычно «забывает» пользователя и при начале новой итерации общения он должен опять идентифицировать себя. Но при использовании Интернет-технологии каждая новая итерация — это загрузка очередной страницы, поэтому проводить каждый раз полную авторизацию неэффективно. Можно рекомендовать использование принципа рабочей сессии пользователя. После первой успешной процедуры авторизации сервер запоминает все его данные (включая те, которые обеспечивают его уникальность: IP адрес, HTTP-USER-AGENT и т.д.), генерирует некоторую случайную последовательность, закрепляет ее за этим пользователем на определенное время и выдает ее в качестве идентификатора. Клиент до конца сеанса использует эту последовательность как свой идентификатор, а сервер, находя ее в своей базе и сравнивая остальные уникальные данные, идентифицирует пользователя.

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

3.7. Реализация Интернет-технологии, как правило, предполагает использование HTTP протокола для передачи данных. По этому протоколу все данные передаются открытым текстом, что дает возможность «подсматривания» за ходом тестирования и подделывания передаваемой информации. Для обеспечения защиты от такого вмешательства можно использовать протокол HTTPS, который подразумевает шифрование передаваемых данных посредством SSL. Но на использование этого протокола накладываются некоторые ограничения. Одним из них, например, является то, что на одном IP-адресе не могут находиться несколько виртуальных Web-серверов, работающих по этому протоколу. Это делает потенциально затрудненным размещение такого сервера на площадях провайдера. Поэтому при разработке можно рассмотреть возможность шифрования данных своими средствами и инкапсулирования этого шифрованного потока в стандарт HTTP. Также возможно делить данные таким образом, что их отдельная часть не представляет из себя никакой ценности, а собранные вместе, они дают полную картину. Одновременно организуются несколько каналов и по каждому из них передается своя часть, после чего все части сливаются воедино на стороне клиента. Эти способы, конечно, не предоставляют реальную защиту, но вполне пригодны для защиты от простейшего просматривания.

4.1.Как правило, разработчики пишут программы, жестко привязываясь к особенностям программных систем, которыми они обладают, и в которых они могут производить тестирование продукта. Например, Web-приложение, написанное для Web-сервера Microsoft IIS и использующее его технологию IS API, уже не будет работать на Unix системе или под управлением другого Web-сервера. Помехой к использованию могут также стать неустановленные библиотеки или иначе сконфигурированные приложения, используемые программой. Поэтому обычно производитель четко указывает, какие требования необходимы для работы его продукта, и в зависимости от того, насколько он универсален, они будут очень жесткими или абсолютно расплывчатыми. Кроме того, практикуется разработка нескольких вариантов программных систем для различных платформ или других условий окружения.

4.2.Использование Интернет-технологии подразумевает жесткое следование определенным стандартам. Неотъемлемыми частями взаимодействия в такой среде являются клиент (браузер) и Web-сервер. Так как клиентов у такой Системы много, а сервер обычно всего один, то при разработке Системы желательно, чтобы на клиентскую часть накладывалось как можно меньше ограничений и каждый пользователь мог иметь тот инструмент, к которому он привык и с которым умеет обращаться, а всю «умную» часть размещать на сервере.

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

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

Как уже говорилось выше, в НГТУ разработана тестирующая система ИнтерТест, ориентированная на использование в сети Интернет. Один из авторов статьи (Л. Г. Макаревич) входит в группу разработчиков этой системы, находящейся в данное время в стадии апробирования и внедрения. Это позволило более четко представить диапазон возможных функций такого рода систем и положить их в основу приведенной выше классификации. Ниже приведена краткая характеристика тестирующей системы ИнтерТест.

Система тестирования ИнтерТест построена по Интернет-технологии и состоит из следующих подсистем: подсистемы администрирования, подсистемы ввода и редактирования вопросов, подсистемы формирования тестов, подсистемы тестирования, подсистемы просмотра и анализа результатов тестирования, подсистемы конвертирования вопросов из программной системы ACT (разработка ВТУ, г. Москва).

Система обеспечивает удаленный доступ, как преподавателей, так и студентов.

Система построена с использованием следующих инструментальных средств: СУБД -MySQL; серверные приложения — php3.14, Web-сервер — IIS4.0 или Apache; клиентское приложение — Internet Explorer 5.0 под Windows NT Workstation или Windows 95 и выше; язык клиентской стороны — JavaScript 1.1; операционная система для сервера -Windows NT 4.0 или Unix.

Система разделяет пользователей на 3 группы: администраторов, преподавателей и студентов. Каждая группа пользователей имеет четкие права по доступу к системе тестирования, т.е. свои привилегии. Администраторы имеют возможность создавать новых пользователей системы, изменять их права, а также удалять их из системы. Каждый пользователь получает статус преподавателя или студента, за каждым пользователем закрепляется уникальное имя и пароль. Таким образом, обеспечивается защита от несанкционированного доступа к данным в базе.

Преподаватели могут:

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

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

Студенты имеют право выполнять тестирование по выбранным тестам, используя один из следующих режимов:

• самотестирование, когда они могут проверять свои ответы или просто просматривать верные;
• мягкое тестирование, когда время ответов не ограничено;
• жесткое тестирование, когда ограничено время тестирования.

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

Администратор при занесении информации о студенте в базу данных может указать права студента на тестирование: студенту может быть разрешен любой режим тестирования или же некоторые из них.

Правила использования тестов. В тесте преподаватель указывает число вопросов по каждой теме, включенной в тест. Каждый вопрос оценивается своим числом баллов, тем самым учитывается сложность вопросов. Вопросы по темам выбираются из базы в случайном порядке. Если число вопросов по теме велико, то они будут выбираться, практически не повторяясь. В тесте также указывается порядок оценки: задается процент правильных ответов, при которых можно ставить различные оценки (5, 4, 3, 2).

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

Все вопросы делятся на группы: открытые, закрытые, соответствия. Открытые вопросы предусматривают четкий ответ, чаще всего в одно-два слова. Ответы вписываются в поле редактирования. Закрытые вопросы предлагают несколько вариантов ответов, и студент выбирает один или несколько из них. Вопросы на соответствие предполагают установление соответствия. Если есть хотя бы одно несоответствие, то ответ считается неверным.

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