100 р бонус за первый заказ

Выберите тип работы Дипломная работа Курсовая работа Реферат Магистерская диссертация Отчёт по практике Статья Доклад Рецензия Контрольная работа Монография Решение задач Бизнес-план Ответы на вопросы Творческая работа Эссе Чертёж Сочинения Перевод Презентации Набор текста Другое Повышение уникальности текста Кандидатская диссертация Лабораторная работа Помощь on-line

Узнать цену

В статье третьей (УШ № 32) говорилось о традиционных тестах. Там же приводились определения гомогенных и гетерогенных тестов. В сегодняшней статье - материал о нетрадиционных тестах, к которым можно отнести тесты интегративные, адаптивные, многоступенчатые и так называемые критериально-ориентированные тесты.

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

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

Методика создания интегративных тестов сходна с методикой создания традиционных тестов, за исключением работы по определению содержания заданий. Для отбора содержания интегративных тестов использование экспертных методов является обязательным. Это связано с тем, что только эксперты могут определить адекватность содержания заданий целям теста. Но, прежде всего, самим экспертам важно будет определиться с целями образования и изучения тех или иных образовательных программ, а затем и договориться между собой по принципиальным вопросам, оставив для экспертизы лишь вариации в понимании степени значимости отдельных элементов в общей структуре подготовленности. Согласованный, по принципиальным вопросам, отобранный состав экспертов в зарубежной литературе нередко панелью. Или учитывая различия в смысле последнего слова, в русском языке, такой состав можно назвать представительной экспертной группой. Группа подбирается так, чтобы адекватно представлять подход, используемый при создании соответствующего теста.

Лекция является второй из трех рассматривающих уровни процесса верификации. Тема данной лекции - процесс интеграционного тестирования, его задачи и цели. Рассматриваются организационные аспекты интеграционного тестирования - структурная и временная классификации методов интеграционного тестирования, планирование интеграционного тестирования. Цель данной лекции: дать представление о процессе интеграционного тестирования, его технической и организационной составляющих

Задачи и цели интеграционного тестирования

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

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

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

Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения

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

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

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

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

• Блочное (Unit testing) - тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) - тестирование группы взаимодействующих модулей.
• Системное (System Testing) - тестирование системы в целом.

Блочное тестирование

Не всякий класс легко покрыть unit тестами. При проектировании нужно учитывать возможность тестируемости и зависимости класса делать явными. Чтобы гарантировать тестируемость можно применять TDD методологию , которая предписывает сначала писать тест, а потом код реализации тестируемого метода. Тогда архитектура получается тестируемой. Распутывание зависимостей можно осуществить с помощью Dependency Injection . Тогда каждой зависимости явно сопоставляется интерфейс и явно определяется как инжектируется зависимость - в конструктор, в свойство или в метод.

Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks . Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемое поведение.

По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears , в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.

Интеграционное тестирование

Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент - это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.

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

Хорошая статья по интеграционному тестированию мне попалась лишь однажды - Scenario Driven Tests . Прочтя ее и книгу Ayende по DSL DSLs in Boo, Domain-Specific Languages in .NET у меня появилась идея как все-таки устроить интеграционное тестирование.

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

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

Системное тестирование

Первый подход - это использовать вариацию MVC паттерна - Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.

Второй подход - использовать специальные инструменты для записи действий пользователя. То есть в итоге запускается сама программа, но щелканье по кнопкам осуществляется автоматически. Для.NET примером такого инструмента является White библиотека . Поддерживаются WinForms, WPF и еще несколько GUI платформ. Правило такое - на каждый use case пишется по скрипту, который описывает действия пользователя. Если все use case покрыты и тесты проходят, то можно сдавать систему заказчику. Акт сдачи-приемки должен подписать.

12 ответов

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

Функциональное тестирование - это когда вы тестируете систему в соответствии с функциональными требованиями продукта. Управление продуктами/проектами обычно записывает эти данные, и QA формализует процесс того, что пользователь должен видеть и испытывать, и каков конечный результат этих процессов. В зависимости от продукта это может быть автоматизировано или нет.

Функциональное тестирование: Да, мы тестируем продукт или программное обеспечение в целом функционально независимо от того, работает ли он функционально или нет (кнопки тестирования, ссылки и т.д.)

Например: Страница входа

вы указываете имя пользователя и пароль, вы проверяете, ведет ли он вас на домашнюю страницу или нет.

Тестирование интеграции: Да, вы тестируете только интегрированное программное обеспечение, но вы проверяете, где происходит поток данных, и происходят ли какие-либо изменения в базе данных.

Например: Отправка электронной почты

Вы отправляете кому-то одно сообщение, есть поток данных, а также изменение в базе данных (отправленная таблица увеличивает значение на 1)

Надеюсь, это помогло вам.

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

Единичное тестирование легко определить. Он тестирует CUT (Code Under Test ) и ничего больше. (Ну, как можно меньше.) Это значит, что это издевательства, подделки и светильники.

На другом конце спектра есть то, что многие люди называют тестированием системной интеграции. Это тестирование как можно больше, но все еще ищет ошибки в вашем собственном CUT.

Но как насчет обширного пространства между?

• Например, что, если вы проверите немного больше, чем CUT? Что делать, если вы включили функцию Фибоначчи вместо использования приспособления, которое вы ввели? Я бы назвал это функциональное тестирование, но мир не согласен со мной.
• Что делать, если вы включили time() или rand() ? Или что, если вы вызываете http://google.com ? Я бы назвал это тестирование системы, но опять же, я один.

Почему это имеет значение? Потому что системные тесты ненадежны. Они необходимы, но иногда они могут потерпеть неудачу по причинам, не зависящим от вас. С другой стороны, функциональные тесты всегда должны проходить, а не случайным образом; если они бывают быстрыми, их можно также использовать с самого начала, чтобы использовать Test-Driven Development без написания слишком большого количества тестов для вашей внутренней реализации. Другими словами, я думаю, что модульные тесты могут быть более сложными, чем они того стоят, и у меня хорошая компания .

Я поставил тесты на 3 оси, со всеми их нулями при модульном тестировании:

• Функциональное тестирование: использование реального кода глубже и глубже в вашем стеке вызовов.
• Интеграция-тестирование: выше и выше ваш стек вызовов; другими словами, тестирование вашего CUT путем запуска кода, который будет использовать его.
• Системное тестирование: все больше и больше неповторимых операций (планировщик O/S, часы, сеть и т.д.).

Тест может легко быть все 3 в разной степени.

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

Тестирование интеграции: процесс, в котором проверяется поток данных между двумя модулями.

Интеграционное тестирование. Тестирование интеграции - это не что иное, как тестирование различных модулей. Вы должны проверить взаимосвязь между модулями. Например, вы открываете facebook, после чего вы видите страницу входа в систему после ввода идентификатора входа и пароля, вы можете видеть домашнюю страницу facebook, поэтому страница входа - это один модуль, а домашняя страница - это еще один модуль. вы должны проверять только связь между ними, когда вы вошли в систему, тогда только домашняя страница должна быть открыта, а не поле сообщения или что-то еще. Существует два основных типа интеграционного тестирования: подход TOP-DOWN и подход BOTTOM UP.

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

В тесте функционального тестирования основное внимание уделяется функциональности и вспомогательной функциональности приложения. Функциональность приложения должна работать правильно или нет.

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

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

Функциональное тестирование: - Тестирование в основном разделено на две категории: 1.Функциональное тестирование 2. Нефункциональное тестирование ** Функциональное тестирование: - Проверить, работает ли программное обеспечение в соответствии с требованиями пользователя или нет. ** Нефункциональное тестирование: - Чтобы проверить, соответствует ли программное обеспечение критериям качества, таким как стресс-тест, тест безопасности и т.д.

Обычно Клиент предоставляет требования только для функционального теста и для не-функционального теста, требования не должны упоминаться, но приложение обязательно выполняет эти действия.

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

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

Когда дело доходит до интеграционного тестирования, это взаимодействие между модулями. Если модуль отправляет вход, модуль B может обрабатывать его или нет.

Тестирование интеграции

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

Функциональное тестирование

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

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

1. Интегративные тесты

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

Методика создания интегративных тестов сходна с методикой создания традиционных тестов, за исключением работы по определению содержания заданий. Для отбора содержания интегративных тестов использование экспертных методов является обязательным. Это связано с тем, что только эксперты могут определить адекватность содержания заданий целям теста. Но, прежде всего, самим экспертам важно будет определиться с целями образования и изучения тех или иных образовательных программ, а затем и договориться между собой по принципиальным вопросам, оставив для экспертизы лишь вариации в понимании степени значимости отдельных элементов в общей структуре подготовленности. Согласованный, по принципиальным вопросам, отобранный состав экспертов в зарубежной литературе нередко панелью. Или учитывая различия в смысле последнего слова, в русском языке, такой состав можно назвать представительной экспертной группой. Группа подбирается так, чтобы адекватно представлять подход, используемый при создании соответствующего теста.

2. Адаптивные тесты

Использование заданий, соответствующих уровню подготовленности, существенно повышает точность измерений и минимизирует время индивидуального тестирования до, примерно, 5 - 10 минут Адаптивное тестирование позволяет обеспечить компьютерную выдачу заданий на оптимальном, примерно 50%-ом уровне вероятности правильного ответа, для каждого ученика.

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

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

Истоки адаптивного подхода можно проследить с момента возникновения педагогических трудов Коменского, Песталоцци и Дистервега, которых объединяют идеи природосообразности и гуманности обучения. В центре их педагогических систем был Ученик. Например, в малоизвестной у нас работе А. Дистервега (2) «Дидактические правила» (Киев, 1870 г.) можно прочитать такие слова: «Преподавай сообразно природе… Учи без пробелов… Начинай преподавание с того, на чем остановился ученик… Прежде чем приступить к преподаванию, нужно исследовать точку исхода… Без знания того, на чем остановился ученик, невозможно порядочно обучить его». Недостаточная информированность о реальном уровне знаний учащихся и естественные различия в их способностях усвоить предлагаемые знания стали главной причиной появления адаптивных систем, основанных на принципе индивидуализации обучения. Этот принцип трудно реализуем в традиционной, классно-урочной форме.

До появления первых компьютеров наиболее известной системой, близкой к адаптивному обучению, была так называемая «Система полного усвоения знаний». О ней уже писалось в УШ № 26/99.

3. Так называемые «критериально-ориентированные тесты»

Если главной задачей является стремление выяснить, - какие элементы содержания учебной дисциплины усвоены тем или иным испытуемым, то это случай предметно - педагогического подхода к интерпретации результатов тестирования. При этом определяется - что из генеральной совокупности заданий (по англ. Domain) испытуемый знает и что не знает. Интерпретация результатов ведется педагогами, на языке учебной дисциплины.

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

Споры ведутся вокруг двух главных вопросов:

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

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

Второй вид тестов связан с ориентацией на такие конкретные цели и задачи, как, например, проверка уровня усвоения сравнительно короткого перечня требуемых знаний, умений и навыков, выступающих в качестве заданного стандарта или критерия усвоения. Например, для аттестации выпускников образовательных учреждений важно иметь такие задания, которые позволяют делать вывод о минимально допустимой компетентности выпускников. За рубежом их так и называют: Minimum Competency Tests. При проверке минимально допустимого уровня знаний содержание заданий носит принципиально облегченный характер. Поскольку такие задания должны выполнять все выпускники, допущенные учебным заведением к аттестации, здесь невозможно трудно говорить о тестах, как методе объективного и эффективного измерения испытуемых с разным уровнем подготовленности, в строгом смысле понятия «тест». Этот подход выработан для органов управления образованием, стоящих перед необходимостью в короткое время проверить состояние образования в большом количестве учебных заведений, и не позволять последним опускаться ниже предельно допустимого уровня требований.

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

При критериально-ориентированной интерпретации требуется несколько меньшее число заданий, посредством которых определяется - что испытуемый знает, и что не знает из заданного стандарта. Иначе говоря, здесь ответы оцениваются относительно не всей области (Domain) требуемых знаний, а только из области, ограниченной конкретным стандартом или уровнем (критерием) знаний. Как и случае с Domain Referenced Testing, интерпретация результатов ведется на языке учебной дисциплины, но уже преимущественно работниками органов управления образованием и теми педагогами, на мнения которых управленцы опираются при аттестации.

По мнению автора, используемые при этом «тесты» не соответствуют подлинно тестовым требованиям, предъявляемым к традиционным и адаптивным тестам. При критериально-ориентированной интерпретации для диагностики заранее заданного уровня подготовленности используются, по существу, не тесты, в традиционном понимании этого метода, а совокупности заданий в тестовой и в иной другой форме, не более того. Слово одно, но смысл другой. «Тесты» с критериально-ориентированной интерпретацией нередко противопоставляются тестам с так называемой нормативно-ориентированной интерпретацией результатов. На самом деле, последние - это традиционные тесты, некоторые из которых имеют параллельные варианты.

Литература

1. Rasch, G. Probabilistic Models for Some Intelligence and Attainment Tests. With a Foreword and Afteword by B.D. Wright. The Univ. of Chicago Press. Chicago & London, 1980. 199 рр. Для более точного восприятия смысла понятия «логит» может быть полезными некоторые формализмы. По существу, Г.Раш ввел две меры: «логит уровня знаний» и «логит уровня трудности задания». Первую он определил как натуральный логарифм отношения доли правильных ответов испытуемого, на все задания теста, к доле неправильных ответов, а вторую - как натуральный логарифм другого отношения - доли неправильный ответов на задание теста к доле правильных ответов на тоже задание, по множеству испытуемых.
2. Дистервег А.«Дидактические правила» (Киев, 1870 г.)
3. См., например, статью: Аванесов В.С. «Образовательные стандарты нуждаются в изменении». УШ, № 46, декабрь 1998г.
4. Нlively W.(Ed). Domain Referenced Testing. Educational Technology Publications. Englewood Cliffs, N-J, 1974.
5. Berk R.A. (Ed). A Guide to Criterion - Referenced Test Construction. The John Hopkins Univ. Press, Baltimore, 1984.