Web-тестирование в дистанционном обучении

Питер Брусиловский и Филипп Миллер, Технологический Университет Д. Карнеги

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

Введение

Контрольное тестирование и устный опрос являются одними из наиболее широко используемых и хорошо разработанных средств проверки знаний в высшем образовании. Классический тест представляет собой последовательность достаточно простых вопросов. На каждый вопрос имеется простой ответ, который может быть формально проверен и оценен как правильный, неправильный или частично правильный (например, неполный). Вопросы обычно классифицируются по типам соответственно типу ожидаемого ответа. Классические типы вопросов делятся на вопросы типа [да/нет], вопросы типа [много вариантов/один ответ] (МВ/ОО), вопросы типа [много вариантов/много ответов] (МВ/МО) и вопросы открытого типа с текстовым или числовым ответом. Более продвинутые типы вопросов включают вопросы на соответствие, вопросы на правильную последовательность, вопросы на указывание (ответ - одна или несколько областей на рисунке), а также графические вопросы (ответ - простой граф). Кроме этого, каждая предметная область может иметь некоторые специфические типы вопросов.

Тестирующие и опрашивающие компоненты были первыми интерактивными компонентами, примененными в Web-основанном обучении (WBE – web-based education), и в настоящее время они являются наиболее разработанными. Существующие WBE системы отличаются по многим аспектам, касающимся выполнения контрольных тестов и опросов. При выборе современной технологии для разработки и выдачи Web-основанных контрольных опросов в Технологическом Университете Д. Карнеги была создана комплексная методика сравнения доступных систем. Данная статья содержит исчерпывающий обзор характеристик, важных при оценке современных технологий Web-тестирования. Наша методика может использоваться специалистами в Web-основанном обучении для понимания и сравнения особенностей тех или иных систем Web-тестирования.

Жизненный цикл и анатомия вопросов

Чтобы сравнить существующие альтернативы, мы проанализировали жизненный цикл вопроса в Web-основанном обучении (см. Таблицу 1). Мы разделили жизненный цикл вопроса в три стадии: подготовка (до активной жизни), выдача (активная жизнь), и оценка (после активной жизни). Каждая из этих стадий далее разделена на меньшие стадии. Для каждой из этих стадий мы исследовали набор возможных технологий поддержки.

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

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

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

Таблица 1. Стадии жизненного цикла тестового вопроса.

Стадия Подготовки

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

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

Хранение вопроса во внутреннем формате обычно означает его хранение в записи базы данных, где различные части вопроса (основа, ответы, и обратная связь) сохранены в различных полях этой записи. Вопрос, как его видит обучаемый, генерируется из внутреннего формата на стадии выдачи. Внутренний формат дает возможность более гибкого манипулирования вопросом: тот же самый вопрос может быть представлен в различных формах (например, открытый тип или множественный выбор) или с помощью различных интерфейсов (например, набором иконок или списком выбора). Порядок альтернатив в вопросах множественного выбора может меняться [Carbone & Schendzielorz 1997]. Это обеспечивает более высокий уровень индивидуализации. Это полезно с педагогической точки зрения и снижает возможность обмана. Существует два основных подхода к созданию вопросов во внутреннем формате: графический пользовательский интерфейс (GUI) и специальный язык разметки вопросов [Brown 1997; Campos Pimentel, dos Santos Junior & Mattos Fortes 1998; Hubler & Assad 1995]. Каждый из этих подходов имеет свои достоинства и недостатки. В настоящее время, подход, основанный на использовании GUI, намного более популярен. Он используется всеми продвинутыми коммерческими WBE-системами, такими как [Blackboard 1998; Question Mark 1998; WBT Systems 1999; WebCT 1999]. Однако, некоторые WBE-системы используют GUI, но не хранят вопросы во внутреннем формате. Вместо этого, такие системы сразу генерируют HTML-вопросы и сохраняют их в статической форме.

Наилучшим выходом для хранилища вопросов является статический тест или опрос, то есть статическая последовательность вопросов. Опрос обычно представляется в форме HTML и создается с помощью авторских средств HTML-уровня. Статические тесты и опросы обычно жестко привязаны к некоторому определенному месту курса. При использовании этой, самой простой, технологии возникает одна проблема; все обучаемые получают одни и те же вопросы в одном и том же месте курса. Другая проблема состоит в том, что каждый вопрос, жестко встроенный в тест не может повторно использоваться. Лучшим вариантом для хранилища вопросов является поддерживаемый вручную фонд вопросов. Фонд может разрабатываться и поддерживаться группой преподавателей. Каждый вопрос в фонде – обычно статический, однако опросы – более гибки. Несложные средства управления фондом позволят преподавателям многократно использовать вопросы; все опросы могут быть собраны и добавлены к содержанию курса, когда это необходимо. Такой подход принято называть гибкостью времени создания. На следующий год тот же самый курс, следующая версия курса, или даже различные разделы в пределах того же самого курса могут включать в себя различные опросы без необходимости разрабатывать эти контрольные опросы с нуля.

Еще лучшим вариантом будет формирование на основе поддерживаемого вручную фонда вопросов базы данных вопросов. База данных добавляет то, что принято называть гибкостью времени выдачи. В отличие от поддерживаемого вручную списка, база данных формально структурирована и доступна системе выдачи вопросов. При наличии базы данных вопросов не только преподаватель может формировать опрос, когда это необходимо, но и сама система может генерировать опрос из набора вопросов. Естественно, вопросы могут быть выбраны случайно и помещены в опрос в случайном порядке [Asymetrix 1998; Brown 1997; Byrnes, Debreceny & Gilmour 1995; Carbone & Schendzielorz 1997; Ni, Zhang & Cooley 1997; Radhakrishnan & Bailey 1997; WBT Systems 1999; WebCT 1999]. В результате, всем обучаемым могут быть предложены индивидуальные опросы (то, чего преподаватель не может обеспечить вручную), что значительно снижает возможность обмана. Обратите внимание, что ведение базы данных вопросов не требует использования коммерческой СУБД. Продвинутые университетские системы, такие как QuestWriter [Bogley et al. 1996] или Carnegie Mellon Online [Rehak 1997] и многие коммерческие системы, такие как TopClass [WBT Systems 1999] или LearningSpace [Lotus 1999] используют готовые базы данных типа ORACLE или Lotus Notes для хранения фондов вопросов во внутреннем формате. Впрочем, имеются также системы, которые успешно имитируют базы данных с файловой системой UNIX, используя специально структурированную систему каталогов и файлов [Byrnes, Debreceny & Gilmour 1995; Gorp & Boysen 1996; Merat и Chung 1997].

Проблема всех систем с автоматической генерацией опросов заключается в том, как обеспечить надлежащий набор вопросов, составляющих опрос. Самый простой способ достижения этого состоит в организации специализированных баз данных вопросов для каждого урока. Этот подход, примененный, например, в WebAssessor [ComputerPREP 1998], уменьшает возможность повторного использования одного и того же вопроса на различных уроках. Многие продвинутые системы подобно TopClass [WBT Systems 1999] могут поддерживать многочисленные фонды вопросов и использовать несколько фондов для генерации каждого опроса. Имея такой уровень поддержки, преподаватель может организовать отдельный фонд для каждой темы или каждой степени сложности вопросов и определять желаемое количество вопросов в сгенерированном опросе, принадлежащих тому или иному фонду.

В настоящее время база данных, хранящая вопросы во внутреннем формате, является активно разрабатываемой технологией хранения. Исследовательские коллективы пытаются развивать ее в трех основных направлениях. Одно направление связано с параметризованными вопросами, используемыми, например, в CAPA [Kashy et al. 1997], EEAP282 [Merat & Chung 1997] или Mallard [Brown 1997; Graham, Swafford & Brown 1997]. Это позволяет создавать неограниченное число тестов из одного того же набора вопросов и фактически исключает возможность обмана [Kashy et al. 1997]. Второе направление исследований связано с развитием метаданных вопроса. Если система знает немного больше относительно вопроса (например, тип, тема, ключевые слова, часть курса, вес или сложность), тогда система может генерировать настроенные и индивидуализированные контрольные опросы по запросу системы или автора. Это означает, что авторы могли бы определить различные параметры опроса, в соответствии с потребностями конкретного обучаемого в конкретной точке курса: общее количество вопросов, относительная доля вопросов определенного типа или по определенной теме, трудность, и т.д., система генерирует настроенный опрос по требованию (который все еще случаен в пределах требований) [Byrnes, Debreceny & Gilmour 1995; Merat & Chung 1997; Rehak 1997; Rios, Pйrez de la Cruz & Conejo 1998]. Такой подход, несомненно, является более мощным, чем простые случайные контрольные опросы. Системы, широко использующие метаданные, действительно больше «знают» о вопросах и их функциональных возможностях. Третье направление исследований – адаптивная выдача вопросов. Такая функциональность основана на оверлейной модели обучаемого, в которой отдельно представлены знания обучаемым различных понятий и разделов курса. Интеллектуальные системы, такие как ELM-ART [Weber & Specht 1997], Medtec [Eliot, Neiman & Lamar 1997], [Lee и Wang 1997], SIETTE [Rios, Pérez de la Cruz & Conejo 1998], Self-Learning Guide [Desmarais 1998] могут генерировать вопросы и тесты, адаптированные к уровню знаний обучаемого, а также снижают число вопросов, требуемых для оценки знаний обучаемых.

Стадия выдачи

Тип интерактивной технологии, используемой для получения ответов обучаемого, является одной из наиболее важных характеристик WBE-систем. Он определяет всю функциональность на стадии выдачи вопросов, а также влияет на стадии создания и оценки вопросов. В настоящее время, различают пять технологий: HTML-ссылки, HTML/CGI-формы, скриптовые языки, внедрение (plag-in) и Java.

HTML-ссылки – самая простая технология взаимодействия, реализующая набор возможных ответов как список HTLM-ссылок. Каждая ссылка связана с определенной страницей обратной связи. При использовании этого подхода возникает две проблемы: сложность создания вопросов (логика вопроса должна быть жестко встроена в гипертекст курса) и поддержка всего двух типов вопросов: [да/нет] и [МВ/ОО]. Эта технология использовалась в основном на заре Web-основанного обучения, когда более продвинутые технологии взаимодействия, такие как CGI, JavaScript или Java еще не были разработаны [Holtz 1995].

Наиболее популярной технологией Web-тестирования, используемой в настоящий момент многочисленными коммерческими и университетскими системами является комбинация HTML-форм и CGI-скриптов. HTML-формы чрезвычайно удобны для представления основных типов вопросов. Вопросы типа [да/нет] и [МВ/ОО] представляются наборами иконок, списками выбора, всплывающими меню. Вопросы [МВ/МО] представляются списками множественного выбора или наборами переключателей. Вопросы открытого типа реализуются в виде полей редактирования. Более продвинутые вопросы, такие как вопросы на соответствие или на правильную последовательность, также могут быть реализованы, при помощи форм. Кроме того, скрытые поля могут использоваться для хранения дополнительной информации о тесте, в которой может нуждаться CGI-скрипт. Значительные преимущества от использования технологии «стороны сервера» (к которой относится и технология «форма/CGI») и схожей с ней технологии «карты стороны серверной» возникают при реализации графических вопросов на указывание. Разработка теста относительно проста и может быть осуществлена с помощью HTML-редактора. Секретная информация, необходимая для вынесения оценки (такая, как параметры вопроса, ответы, обратная связь) может для безопасности храниться на стороне клиента, обеспечивая защиту обучаемых от кражи вопросов (единственной внешней информацией, необходимой хорошо разработанной системе, для оценки теста является идентификатор теста и идентификатор студента). Организация оценки на стороне сервера облегчает реализацию всех функций, необходимых на стадии оценки (таких, как запись результатов, проставление бала, выдача обратной связи). Все эти функции могут выполняться одним и тем же скриптом на стороне сервера. Основная проблема технологии «стороны сервера» – малая выразительная мощность. Эта технология хорошо реализует только основные типы тестов. Более продвинутые и более интерактивные типы тестов (например, тесты, использующие технологию drag-and-drop – перетаскивание объектов) не могут быть реализованы с помощью только технологии «стороны сервера». Создать вопрос с оценкой на стороне сервера довольно непросто потому, что функциональные возможности вопроса распространены между его HTML-представлениям (создаваемым вручную или сгенерированным автоматически) и CGI-скриптом, реализующем оценку. Другая серьезная проблема заключается в том, что вопросы, основанные на CGI, не работают, когда связь пользователя с сервером нарушается или очень замедляется.

Более новая технология для выдачи вопросов и оценки ответов - JavaScript [McKeever, McKeever и Elder 1997]. Интерфейс, обеспечиваемый технологией взаимодействия, основанной на JavaScript, подобен интерфейсу, реализуемому с помощью технологии «форма/CGI». В то же время, функциональность JavaScript поддерживает более продвинутые интерактивные вопросы, например, нахождение релевантного фрагмента в тексте. При использовании «чистой» технологии JavaScript все данные для оценки вопроса и организации обратной связи, а также программа оценки, хранятся как часть вопроса. Это означает, что вопрос, реализованный с помощью JavaScript, может работать в автономном режиме. Это в свою очередь означает, что вопрос самостоятелен: все, необходимое для его представления и оценки находится в одном файле, что является очень привлекательной возможностью для создателей вопросов. Но это также означает, что обучаемые получают доступ к ресурсам вопроса и могут «вскрыть» его. Также, при использовании «чистой» технологии JavaScript, отсутствует возможность регистрации результатов и проставления бала. Все вышеперечисленное показывает, что JavaScript лучше использовать для самооценки, нежели в официальных тестах. По нашему мнению наилучшим выходом для JavaScript будет технология JavaScript/сервер, которая сможет занять достойное место в Web-основанном обучении. Комбинация JavaScript с технологией «стороны сервера» может быть использована для представления большего количества типов вопросов и повышения интерактивности процесса тестирования (Javascript), а также для реализации удобного пользовательского интерфейса, обеспечения оценки и ведения записи (CGI) [ComputerPREP 1998; WebCT 1999].

Более высокий уровень свободы интерфейса может быть достигнут, с помощью технологии внедрения (plug-in)ⁱ. Единственный пример серьезного использования этой технологии в образовании - Shockwave plug-in [Macromedia 1998], который может запускать мультимедиа-презентации, подготовленные с помощью набора авторских средств Macromedia. В настоящее время, технология Shockwave используется в WBE главным образом для передачи анимационных роликов, однако эта технология обладает гораздо более мощными возможностями. В действительности, с помощью средств Macromedia при относительно малых затратах может быть разработано большое количество качественных вопросов, которые могут доставляться обучаемому с использованием технологии Shockwave. Некоторым примером может служить Medtec [Eliot, Neiman & Lamar 1997]. Недостатком этого подхода, как и в случае JavaScript, является то, что регистрация результатов оценки требует постоянного подключения к серверу. До недавнего времени, Shockwave не обеспечивала никакой Internet-функциональности, и ее пользователи должны были применять специальные приемы (например, сохранение результатов во временном файле). Из-за этих проблем некоторые коллективы, начинавшие работать с Shockwave, затем переориентировались на более мощную технологию Java [Eliot, Neiman & Lamar 1997]. Однако, Shockwave все еще может использоваться как платформа для доставки вопросов для самооценки.

На сегодняшний день самый высокий уровень технологии выдачи вопроса обеспечивается Java. Важное преимущество Java состоит в том, что она является полностью законченным языком программирования, разработанным для интеграции с функциональными возможностями браузера и Internet. Java объединяет сетевое преимущество технологии «форма/CGI» и интерактивность Shockwave и JavaScript. Java позволяет разработать любой интерфейс вопроса и в то же время, вопросы, созданные с помощью Java, могут легко взаимодействовать с браузером, также как с любым объектом Internet (сервер или Java-приложение). Примерами систем, которые широко используют Java-основанные вопросы являются FLAX [Routen, Graves & Ryan 1997], NetTest [Ni, Zhang & Cooley 1997], Mallard [Graham & Trick 1997], и Medtec [Eliot, Neiman & Lamar 1997]. Разработать интерфейс вопроса на Java гораздо сложнее, чем с помощью технологией «форма/CGI», поэтому не удивительно, что все перечисленные системы, были разработаны коллективами профессиональных программистов. Однако сложность вряд ли станет препятствием для этой технологии. С помощью Java в настоящее время разработано большое количество типов вопросов, которые не могут быть реализованы с помощью технологии «форма/CGI». К таким вопросам относятся, вопросы множественного указывания, графические вопросы и специализированные типы вопросов. Разработка вопросов на Java может стать доступной для обычных авторов с появлением Java-основанных авторских средств [Ni, Zhang & Cooley 1997; Routen, Graves & Ryan 1997].

Стадия Оценки

Как мы уже говорили, выбор технологии взаимодействия заметно влияет на функциональные возможности стадии оценки. Оценка – это стадия, на которой ответы обучаемых определяются как правильные, неправильные или частично правильные (например, неполные). Обычно, правильные и неправильные ответы готовятся во время создания, так что оценка является или жестко встроенной в вопрос, как это делается в вопросах типа [МВ/ОО], или осуществляется путем простого сравнения (в вопросах открытого типа). Существует несколько случаев, требующих более продвинутой технологии оценки. В некоторых предметных областях может возникнуть ситуация, когда правильные ответы могут не иметь побуквенного соответствия с хранимым правильным ответом. Примеры могут служить: набор неупорядоченных слов, вещественное число, простое алгебраическое выражение [Holtz 1995; Hubler & Assad 1995]. В этой ситуации требуется программа сравнения. Некоторые системы могут применять для этих целей специальные интеллектуальные технологии [Hubler & Assad 1995]. Наконец, в некоторых случаях для оценки ответов необходим «эксперт предметной области», такой как интерпретатор Lisp для программирования на Lisp, как в системе ELM-ART [Brusilovsky, Schwarz & Weber 1996], или компьютерная алгебраическая система для алгебраических предметных областей [Pohjolainen, Multisilta & Antchev 1997]. Первые два варианта оценки очень просты и могут быть реализованы с использованием любой интерфейсной технологией – даже JavaScript, может использоваться, чтобы написать простую программу сравнения. Если же требуются более сложные вычисления (как в случае интеллектуального соответствия ответа), приходится обращаться к полноценному программированию на Java или программе на стороне сервера, использующей CGI-интерфейс. Если для оценки требуется «эксперт предметной области», то единственной альтернативой в настоящее время является запуск «эксперта» на стороне сервера с CGI-шлюзом. Фактически, многие системы типа «эксперт предметной области» (например, компьютерная алгебраическая система Mathematica) имеют CGI-шлюз.

Обычно в функции обратной связи входит: сообщение о том, что ответ правильный, не правильный или частично правильный; выдача правильного ответа, обеспечение индивидуальной обратной связи. Индивидуальная обратная связь может сообщать, что является верным в правильном ответе, что неверно в неправильном и частично неправильном ответе, обеспечивается некоторая мотивационная обратная связь, обеспечивать мотивирующую обратную связь, а также выдавать информацию или ссылки для продолжения обучения. Вся индивидуальная обратная связь обычно создается и хранится вместе с вопросом. Система, включающая определенные понятия или разделы с проставленными весовыми коэффициентами как часть метаданных вопроса, может обеспечивать качественную корректирующую обратную связь без непосредственного создания, так как она «знает», какие знания пропущены, и где их можно найти. Это означает, что мощность обратной связи определяется технологией создания и хранения вопросов. Количество информации, предоставляемое обратной связью, зависит от контекста. При самооценке обучаемый обычно получает всю возможную обратную связь – чем больше, тем лучше. Эта обратная связь – очень важный дидактический ресурс. В случае официального тестирования обучаемому обычно не предоставляется ни правильного варианта ответа, ни, даже, является ли его ответ правильным. Единственной обратной связью по окончании всего теста может быть общее число правильных ответов в тесте [Rehak 1997]. Это значительно снижает возможность обмана, но также и возможность обучаться. Для поддержки процесса обучения, многие существующие WBE-системы делают оценку менее строгой и обеспечивают больше обратной связи, пытаясь бороться с обманами другими средствами. Единственный способ объединить обучение и строгую оценку состоит в использовании более продвинутых технологий, позволяющих получить неограниченное число вопросов: использование параметризованных вопросов [Brown 1997; Hubler & Assad 1995; Kashy et al. 1997; Merat & Chung 1997] и генерация тестов на основе базы знаний [Элиот, Нейман & Ламар 1997; Weber & Specht 1997]. В этой ситуации WBE-система может обеспечить полную обратную связь, препятствуя при этом обману.

Если тест предназначен исключительно для самооценки, то генерация обратной связи должна быть главной обязанностью WBE-системы на послетестовой стадии. Обучаемый – единственный, кому необходимо видеть результаты тестирования. Во контексте оценки, главной обязанностью WBE-системы в процессе тестирования является проставление балов по итогам выполнения обучаемым теста и запись этих данных для будущего использования. Окончательный бал и другие результаты теста важны для преподавателей, администраторов курса и непосредственно обучаемых (многие авторы отмечают, что возможность видеть свои результаты в режиме он-лайн, отмечается большинством обучаемых как положительная особенность WBE-систем). Ранние WBE системы обеспечивали довольно ограниченную поддержку преподавателя на стадии оценки теста. Результаты или посылались преподавателю по электронной почте или регистрировались в специальном файле. В обоих случаях преподавателю приходилось ставить окончательный бал и делать записи лично: обработать результаты теста и поставить окончательный бал, сделать запись о результатах и обеспечить, доступ к ним всем заинтересованным лицам согласно политике университета. Такой вариант просто реализовать, и он не требует от преподавателя изучения новых технологий. Вследствие последней причины возможность использования этой технологии все еще предусматривается в нескольких продвинутых системах [Carbone и Schendzielorz 1997]. Однако, если система которая не обеспечивает никаких других возможностей для ведения записей и проставления оценок, она явно находится ниже современного уровня. На сегодняшний день современная WBE-система должна быть способна оценить результаты теста автоматически и занести их в базу данных. Кроме того, она должна поддерживать несколько уровней ограничения доступа к записям для студентов, преподавателей и администраторов. Ограничения обычно определяются политикой университета. Например, обучаемому могут не разрешить просматривать результаты других обучаемых, или преподавателю могут позволить изменять окончательные балы, проставленные автоматически. Многие системы университетского уровня [Bogley et al. 1996; Brown 1997; Carbone & Schendzielorz 1997; Gorp & Boysen 1996; Hubler & Assad 1995; MacDougall 1997; Ni, Zhang & Cooley 1997; Rehak 1997] и почти все коммерческие системы [Lotus 1999; WBT Systems 1999; WebCT 1999] обеспечивают эти требования в той или иной степени. Менее продвинутые системы обычно хранят результаты в структурированных файлах и обеспечивают ограниченные возможности доступа. Продвинутые системы используют для хранения информации о результатах тестирования технологию баз данных и обеспечивают широкий набор возможностей просмотра оценок обучаемых и другой информации о тестировании, такой как время, затраченное на прохождение теста, количество попыток и т.д. Технология баз данных облегчает генерацию разнообразной статистической информации, на основе результатов большого количества обучаемых во многих тестах курса. В сетевой классной комнате, где общение «обучаемого-со-обучаемым» и «обучаемого-с-преподавателем» ограничено, сравнительная статистика очень важна для преподавателей и обучаемых, она помогает получить «чувство» классной комнаты. Например, сравнивая средний бал класса с личными результатами, обучаемый может определить уровень класса. Сравнивая результаты класса в различных тестах, преподаватель может обнаружить слишком простые, слишком трудные и даже неправильно составленные вопросы.

Список литературы