Из институтского курса по технологиям программирования я вынес следующую классификацию видов тестирования (критерий - степень изолированности кода). Тестирование бывает:
- Блочное (Unit testing) - тестирование одного модуля в изоляции.
- Интеграционное (Integration Testing) - тестирование группы взаимодействующих модулей.
- Системное (System Testing) - тестирование системы в целом.
Блочное тестирование
Блочное (модульное, unit 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 у меня появилась идея как все-таки устроить интеграционное тестирование.
Идея простая. У нас есть входные данные, и мы знаем как программа должна отработать на них. Запишем эти знания в текстовый файл. Это будет спецификация к тестовым данным, в которой записано, какие результаты ожидаются от программы. Тестирование же будет определять соответствие спецификации и того, что действительно находит программа.
| Проиллюстрирую на примере. Программа конвертирует один формат документа в другой. Конвертирование хитрое и с кучей математических расчетов. Заказчик передал набор типичных документов, которые ему требуется конвертировать. Для каждого такого документа мы напишем спецификацию, где запишем всякие промежуточные результаты, до которых дойдет наша программа при конвертировании. 1) Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами: $SectionNames = Введение, Текст статьи, Заключение, Литература 2) Другой пример. При конвертировании нужно разбивать геометрические фигуры на примитивы. Разбиение считается удачным, если в сумме все примитивы полностью покрывают оригинальную фигуру. Из присланных документов выберем различные фигуры и для них напишем свои спецификации. Факт покрываемости фигуры примитивами можно отразить так: $IsCoverable = true |
Данный вид тестирования является интеграционным, так как при проверке вызывается код взаимодействия нескольких классов. Причем важен только результат взаимодействия, а не детали и порядок вызовов. Поэтому на тесты не влияет рефакторинг кода. Не происходит избыточного или недостаточного тестирования - тестируются только те взаимодействия, которые встречаются при обработке реальных данных. Сами тесты легко поддерживать, так как спецификация хорошо читается и ее просто изменять в соответствии с новыми требованиями.
Системное тестирование
Системное - это тестирование программы в целом. Для небольших проектов это, как правило, ручное тестирование - запустил, пощелкал, убедился, что (не) работает. Можно автоматизировать. К автоматизации есть два подхода.Первый подход - это использовать вариацию 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 может обрабатывать его или нет.
Тестирование интеграции
Можно видеть, как разные модули системы работают вместе. Мы в основном ссылаемся на интегрированную функциональность различных модулей, а не на разные компоненты системы. Для эффективной работы любой системы или программного продукта каждый компонент должен синхронизироваться друг с другом. В большинстве случаев инструмент, который мы использовали для тестирования интеграции, будет выбран, который мы использовали для модульного тестирования. Он используется в сложных ситуациях, когда модульное тестирование оказывается недостаточным для тестирования системы.
Функциональное тестирование
Его можно определить как тестирование отдельных функциональных возможностей модулей. Это относится к тестированию программного продукта на индивидуальном уровне, чтобы проверить его функциональность. Для проверки программного обеспечения для ожидаемых и неожиданных результатов разработаны тестовые примеры. Этот тип тестирования выполняется больше с точки зрения пользователя. То есть, он учитывает ожидание пользователя для ввода типа. Он также называется тестированием черного ящика, а также тестом с закрытым ящиком
Перевод:
Анна Радионова
Существует много видов ПО тестов. Практики BDD можно применять в любых аспектах тестирования, но BDD фреймворки используются далеко не во всех типах тестов. Поведенческие сценарии, по сути, являются функциональными тестами - они проверяют, что тестируемый продукт работает корректно. Для тестирования производительности могут использоваться инструменты, в то время как BDD фреймворки не предназначены для этих целей. Задача данной статьи, в основном, состоит в описании роли BDD автоматизации в Пирамиде Тестирования. Прочитайте статью BDD 101: Manual Testing для того, чтобы понимать как BDD применяется при ручном тестировании. (Всю информацию по BDD можно найти на странице Automation Panda BDD page)
Пирамида Тестирования
Тем не менее, BDD практики могут применяться для юнит-тестов. Каждый юнит-тест должен быть направлен на основную составляющую: один вызов, единичная вариация, определенная комбинация ввода; на поведение .В дальнейшем при разработке спецификация поведения фичи четко отделяет юнит тесты от тестов более высокого уровня. Разработчик функционала также ответственен за написание юнит-тестов, в то время как за интеграционные и end-to-end тесты несет ответственность другой инженер. Спецификация поведения является, своего рода, джентльменским соглашением о том, что юнит-тесты будут являться отдельной сущностью.
Интеграционное и End-to-End тестирование
Тестовые BDD фреймворки наиболее ярко проявляют себя на интеграционных и end-to-end уровнях тестирования .
Поведенческие спецификации однозначно и лаконично описывают, на что именно ориентирован тест-кейс. Шаги могут быть написаны на интеграционном или end-to-end уровне. Тесты сервиса могут быть написаны с помощью поведенческих спецификаций, как, например в Karate . End-to-end тесты фактически представляют собой многошаговые интеграционные тесты. Обратите внимание на следующий пример, который, на первый взгляд, кажется базовой моделью взаимодействия с пользователем, но, по сути, является объемным end-to-end тестом:
Given
a user is logged into the social media site
When
the user writes a new post
Then
the user"s home feed displays the new post
And
the all friends" home feeds display the new post
Простая публикация в социальной сети включает процессы взаимодействия с интерфейсом, вызовы сервисов бекенда и внесение изменений в базу данных в режиме реального времени. Описан полный путь прохождения в системе. Автоматизированные шаги могут покрывать эти уровни явно или неявно, но они совершенно точно покрыты тестом.
Длительные End-to-End тесты
Термины часто понимаются разными людьми по-разному. Когда люди говорят “end-to-end тесты,” они подразумевают продолжительные последовательные тесты: тесты, которые покрывают различное поведение продукта одно за другим . Это утверждение заставляет содрогнуться приверженцев BDD, т.к это противоречит основному правилу BDD: один сценарий, одно поведение. Конечно, с помощью BDD фреймворков можно составлять длительные end-to-end тесты, но нужно хорошо подумать, стоит ли это делать и как именно.
Существует пять основных принципов написания длительных end-to-end сценариев в BDD:
- Не стоит беспокоиться на этот счет . Если BDD процесс поставлен правильно, то каждое отдельное поведение уже полностью покрыто тестовыми сценариями. Каждый сценарий должен покрывать все классы эквивалентности вводимых и выводимых данных. Таким образом, длительные end-to-end сценарии будут являться, в основном, дублированием тестового покрытия. Вместо того, чтобы тратить время на разработку, лучше отказаться от автоматизации длительных end-to-end сценариев, как от тех, которые не представляют большой ценности и уделить больше времени ручному и исследовательскому тестированию .
- Объединить существующие сценарии в новые . Каждая When-Then пара представляет собой индивидуальное поведение. Шаги из существующих сценариев могут быть переопределены в другие сценарии и для этого потребуется лишь незначительный рефакторинг. Это нарушает хорошие практики Gherkin и может привести к появлению длительных сценариев, но это наиболее практичный способ переиспользовать шаги для обширных end-to-end сценариев. Большинство BDD фреймворков не поддерживают пошаговый порядок, а если поддерживают, то шаги должны быть переписаны, чтобы код работал. (Этот подход является наиболее практичным, но менее традиционным .)
- Встраивайте проверки в Given и When шаги . Данная стратегия позволяет избежать дуплицирования When-Then пар и убедиться, что проверки производятся. Корректность каждого шага проверяется на протяжении всего процесса с помощью Gherkin текста. Однако, может потребоваться ряд новых шагов.
- Воспринимайте последовательность поведений как уникальное отдельное поведение . Это наилучший способ обдумывания длительных end-to-end сценариев, т.к. он усиливает поведенческое мышление. Продолжительный сценарий имеет ценность только в том случае, если он расценивается как уникальное поведение. Сценарий должен быть написан с целью подчеркнуть эту уникальность. В противном случае это не тот сценарий, который стоит использовать. Такие сценарии часто являются декларативными и высокоуровневыми.
- Не используйте BDD фреймворки и пишите тесты исключительно с помощью средств автоматизации . Gherkin предназначен для совместной работы в отношении поведения, в то время как продолжительные end-to-end тесты решают проблемы интенсивности работы QA. Бизнес может предоставить поведенческие спецификации, но никогда не станет писать end-to-end тесты. Переписывание поведенческих спецификаций в длинные end-to-end сценарии может блокировать разработку. Гораздо лучшим решением является сосуществование: приемочные тесты могут быть написаны при помощи Gherkin, а продолжительные end-to-end тесты - средствами программирования. Для автоматизации обоих наборов тестов можно использовать одну и ту же базу кода, у них могут быть единые модули поддержки и даже методы определения шагов.
Выберите подход, наиболее подходящий вашей команде.
Классы и виды тестов.
Существуют два основных класса тестов: традиционные и нетрадиционные .
Тест обладает составом , целостностью и структурой . Он состоит из:
- заданий;
- правил их применения;
- оценок за выполнение каждого задания;
- рекомендаций по интерпретации тестовых результатов.
Целостность теста означает взаимосвязь заданий, их принадлежность общему измеряемому фактору. Каждое задание теста выполняет отведенную ему роль и потому ни одно из них не может быть изъято из теста без потери качества измерения.
Структуру теста образует способ связи заданий между собой. В основном, это так называемая факторная структура , в которой каждое задание связано с другими через общее содержание и общую вариацию тестовых результатов.
Традиционный тест представляет собой единство, по меньшей мере, трех систем:
- содержательной системы знаний, описываемой языком проверяемой учебной дисциплины;
- формальной системы заданий возрастающей трудности;
- статистических характеристик заданий и результатов испытуемых.
Традиционный педагогический тест нужно рассматривать в двух существенных смыслах: как метод педагогического измерения и как результат применения теста .
тест - это система заданий, образующих наилучшую методическую целостность . Целостность теста - это устойчивое взаимодействие заданий, образующих тест как развивающуюся систему.
Гомогенные тесты
К традиционным тестам относятся тесты гомогенные и гетерогенные .
Гомогенный тест представляет собой систему заданий возрастающей трудности, специфической формы и определенного содержания - система, создаваемая с целью объективного, качественного, и эффективного метода оценки структуры и измерения уровня подготовленности учащихся по одной учебной дисциплине .
Гомогенные тесты распространены больше других. В педагогике они создаются для контроля знаний по одной учебной дисциплине или по одному разделу такой, например, объемной учебной дисциплины, как физика. В гомогенном педагогическом тесте не допускается использование заданий, выявляющих другие свойства. Наличие последних нарушает требование дисциплинарной чистоты педагогического теста. Ведь каждый тест измеряет что-то заранее определенное.
Гетерогенные тесты
Гетерогенный тест представляет собой систему заданий возрастающей трудности, специфической формы и определенного содержания - система, создаваемая с целью объективного, качественного, и эффективного метода оценки структуры и измерения уровня подготовленности учащихся по нескольким учебным дисциплинам .
Нередко в такие тесты включаются и психологические задания для оценки уровня интеллектуального развития.
Обычно гетерогенные тесты используются для комплексной оценки выпускника школ, оценки личности при приеме на работу и для отбора наиболее подготовленных абитуриентов при приеме в вузы. Поскольку каждый гетерогенный тест состоит из гомогенных тестов, интерпретация результатов тестирования ведется по ответам на задания каждого теста (здесь они называются шкалами) и кроме того, посредством различных методов агрегирования баллов делаются попытки дать общую оценку подготовленности испытуемого.
Интерпретация результатов тестирования ведется преимущественно на языке тестологии, с опорой на среднюю арифметическую, моду или медиану и на так называемые процентильные нормы, показывающие - сколько процентов испытуемых имеют тестовый результат хуже, чем у любого взятого для анализа испытуемого с его тестовым баллом. Такая интерпретация называется нормативно-ориентированной .
Интегративные тесты
Интегративным можно назвать тест, состоящий из системы заданий, отвечающих требованиям интегративного содержания, тестовой формы, возрастающей трудности заданий, нацеленных на обобщенную итоговую диагностику подготовленности выпускника образовательного учреждения .
Диагностика проводится посредством предъявления таких заданий, правильные ответы на которые требуют интегрированных (обобщенных, явно взаимосвязанных) знаний в области двух и большего числа учебных дисциплин. Создание таких тестов дается только тем преподавателям, которые владеют знаниями ряда учебных дисциплин, понимают важную роль межпредметных связей в обучении, способны создавать задания, правильные ответы на которые требуют от учащихся знаний различных дисциплин и умений применять такие знания.
Интегративному тестированию предшествует организация интегративного обучения . К сожалению, существующая сейчас классно-урочная форма проведения занятия, в сочетании с чрезмерным дроблением учебных дисциплин, вместе с традицией преподавания отдельных дисциплин (а не обобщенных курсов), еще долго будут тормозить внедрение интегративного подхода в процессы обучения и контроля подготовленности.
Преимущество интегративных тестов перед гетерогенными заключается в большей содержательной информативности каждого задания и в меньшем числе самих заданий.
Адаптивные тесты
Целесообразность адаптивного контроля вытекает из необходимости рационализации традиционного тестирования.
Каждый учитель понимает, что хорошо подготовленному ученику нет необходимости давать легкие и очень легкие задания, потому что слишком высока вероятность правильного решения. К тому же легкие материалы не обладают заметным развивающим потенциалом. Симметрично, из-за высокой вероятности неправильного решения нет смысла давать трудные задания слабому ученику. Известно, что трудные и очень трудные задания снижают учебную мотивацию многих учащихся.
Самая главная характеристика заданий адаптивного теста - это уровень их трудности, полученный опытным путем, что означает: прежде чем попасть в банк, каждое задание проходит эмпирическую апробацию на достаточно большом числе типичных учащихся интересующего контингента. Слова "интересующего контингента" призвано представлять здесь смысл известного в науке более строгого понятия "генеральная совокупность".
Тестирование обладает следующими преимуществами перед другими методами педагогического контроля:
· повышение скорости проверки качества усвоения знаний и умений учащимися;
· осуществление хотя и поверхностного, но полного охвата всего учебного материала;
· снижение воздействия негативного влияния на результаты тестирования таких факторов как настроение, уровень квалификации и др. характеристики конкретного учителя, т.е. минимизация субъективного фактора при оценивании ответов;
· высокая объективность и, как следствие, большее позитивное стимулирующее воздействие на познавательную деятельность учащегося;
· ориентированность на современные технические средства, на использование в среде компьютерных обучающих и контролирующих систем;
· возможность математико-статистической обработки результатов контроля, и как следствие, повышение объективности педагогического контроля;
· осуществление принципа индивидуализации и дифференциации обучения благодаря использованию адаптивных тестов;
· возможность увеличить частоту и регулярность контроля за счет уменьшения времени выполнения заданий и автоматизации проверки;
· облегчение процесса интеграции системы образования страны в европейскую.
Тесты можно классифицировать по следующим основаниям:
1. Предметная область применения тестов
: монопредметные, полипредметные, интегративные.
Интегративным
можно назвать тест, состоящий из таких заданий, правильные ответы на которые требуют интегрированных (взаимосвязанных, обобщенных) знаний двух или большего числа учебных дисциплин. Использование таких тестов в школе, как контролирующих, так и обучающих, - отличное средство реализации межпредметных связей в обучении.
2. Общая ориентация замысла построения теста
: нормативно-ориентированные или критериально-ориентированные (предметно-ориентированные).
При нормативно-ориентированном
подходе разрабатываются тесты для сравнения испытуемых по уровню учебных достижений.
Главным отличительным признаком предметно-ориентированного
тестирования является интерпретация выполнения теста с точки зрения его смыслового содержания. Упор делается на строго определенную содержательную область (что тестируемые могут и что знают), а не на то, как они выглядят на фоне других.
3.Дидактико-психологическая ориентация теста: тест достижений для контроля знаний теории; тест достижений для контроля умений и навыков различной степени сложности по данному предмету, тест обучаемости (диагностики реальных учебных возможностей по данному кругу предметных или цикловых знаний – математической, лингвистической и т.п.).
4.Ориентация на определенный этап контроля : тесты предварительного контроля, тесты текущего контроля, тесты итогового контроля.
5. Доминирующая деятельность испытуемого при выполнении тестов – устные, письменные, компьютерные.
6. Количество объектов контроля : тесты, имеющие один объект контроля (например, количество выполняемых на должном уровне операций) или несколько (качество, количество, скорость, строгую последовательность, осознанность тех же операций).
7. Степень гомогенности тестовых заданий : тесты с однородными или разнородными формами построения заданий.
8. Скоростной фактор : скоростные (с обязательным фиксированием времени выполнения) и нескоростные.
9. Форма организации тестирования : массовые, индивидуальные, групповые .
Отдельно выделяют так называемые адаптивные тесты, основанные на принципе индивидуализации обучения. Каждый учитель понимает, что хорошему ученику нет смысла давать легкие и очень легкие задания, так же как нет смысла давать трудные задания слабому ученику. В теории педагогических измерений была найдена мера трудности заданий и мера уровня знаний, сопоставимые в одной шкале. После появления компьютеров эта мера легла в основу методики адаптивного контроля знаний, где трудность и число предъявляемых заданий регулируются в зависимости от ответов учеников.