Перевод: Анна Радионова

Существует много видов ПО тестов. Практики 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:

1. Не стоит беспокоиться на этот счет . Если BDD процесс поставлен правильно, то каждое отдельное поведение уже полностью покрыто тестовыми сценариями. Каждый сценарий должен покрывать все классы эквивалентности вводимых и выводимых данных. Таким образом, длительные end-to-end сценарии будут являться, в основном, дублированием тестового покрытия. Вместо того, чтобы тратить время на разработку, лучше отказаться от автоматизации длительных end-to-end сценариев, как от тех, которые не представляют большой ценности и уделить больше времени ручному и исследовательскому тестированию .
2. Объединить существующие сценарии в новые . Каждая When-Then пара представляет собой индивидуальное поведение. Шаги из существующих сценариев могут быть переопределены в другие сценарии и для этого потребуется лишь незначительный рефакторинг. Это нарушает хорошие практики Gherkin и может привести к появлению длительных сценариев, но это наиболее практичный способ переиспользовать шаги для обширных end-to-end сценариев. Большинство BDD фреймворков не поддерживают пошаговый порядок, а если поддерживают, то шаги должны быть переписаны, чтобы код работал. (Этот подход является наиболее практичным, но менее традиционным .)
3. Встраивайте проверки в Given и When шаги . Данная стратегия позволяет избежать дуплицирования When-Then пар и убедиться, что проверки производятся. Корректность каждого шага проверяется на протяжении всего процесса с помощью Gherkin текста. Однако, может потребоваться ряд новых шагов.
4. Воспринимайте последовательность поведений как уникальное отдельное поведение . Это наилучший способ обдумывания длительных end-to-end сценариев, т.к. он усиливает поведенческое мышление. Продолжительный сценарий имеет ценность только в том случае, если он расценивается как уникальное поведение. Сценарий должен быть написан с целью подчеркнуть эту уникальность. В противном случае это не тот сценарий, который стоит использовать. Такие сценарии часто являются декларативными и высокоуровневыми.
5. Не используйте BDD фреймворки и пишите тесты исключительно с помощью средств автоматизации . Gherkin предназначен для совместной работы в отношении поведения, в то время как продолжительные end-to-end тесты решают проблемы интенсивности работы QA. Бизнес может предоставить поведенческие спецификации, но никогда не станет писать end-to-end тесты. Переписывание поведенческих спецификаций в длинные end-to-end сценарии может блокировать разработку. Гораздо лучшим решением является сосуществование: приемочные тесты могут быть написаны при помощи Gherkin, а продолжительные end-to-end тесты - средствами программирования. Для автоматизации обоих наборов тестов можно использовать одну и ту же базу кода, у них могут быть единые модули поддержки и даже методы определения шагов.

Выберите подход, наиболее подходящий вашей команде.

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

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

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

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

Блочное (модульное, 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

Понятно, что для проверки подобных спецификаций потребуется движок, который бы считывал спецификации и проверял их соответствие поведению программы. Я такой движок написал и остался доволен данным подходом. Скоро выложу движок в Open Source. (UPD: Выложил)

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

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

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

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

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

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

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

Узнать цену

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

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

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

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

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 может обрабатывать его или нет.

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

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

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

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

РАЗВИТИЕ ТЕСТОВОЙ ТЕХНОЛОГИИ КОНТРОЛЯ УРОВНЯ ОБУЧЕННОСТИ СТУДЕНТОВ.

Белоногова Наталья Николаевна, преподаватель математики ГБОУ СПО МО « Московский областной гуманитарный колледж»

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

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

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

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

Существуют два основных класса тестов: традиционные и нетрадиционные.

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

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

К традиционным тестам относятся тесты гомогенные и гетерогенные .

Гомогенные тесты

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

Легко видеть, что в своей основе определение гомогенного теста совпадает с определением традиционного теста.

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

Гетерогенные тесты

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

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

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

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

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

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

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

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

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

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

Уровень знаний выявляется при анализе ответов каждого ученика на все задания теста. Чем больше правильных ответов, тем выше индивидуальный тестовый балл испытуемых. Один и тот же уровень знаний может быть получен за счет ответов на различные задания.

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

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

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

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

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

К преимуществам тестовой технологии контроля относятся:

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

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

Возможность сочетания ее с другими традиционными формами педагогического контроля.

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

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

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

Возможность проведения традиционного ("бумажного") и компьютеризованного (в локальной сети) тестирования.

Возможность применения современной технологии компьютерно-адаптивного тестирования.

Возможность массового широкомасштабного стандартизованного тестирования путем распечатки и тиражирования параллельных форм (вариантов) теста и доставки его в различные учебные заведения.

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

Единство требований ко всем испытуемым, вне зависимости от их прошлых учебных достижений.

Стандартизованность тестового контроля, возможность разработки единого теста для различных учебных заведений на основе требований ГОС СПО.

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

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

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

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

Высокая критериальная (текущая) валидность итоговых аттестационных тестов.

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

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

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

Возможность учета при тестировании региональных особенностей ГОС СПО.

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

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

СПИСОК ИСПОЛЬЗОВАННЫХИСТОЧНИКОВ

Ж.Н. Зайцева, В.И. Солдатин Информатизация образования: состояние проблемы и перспективы М.; ИЦПКПС, 1998, 38с.

Христовский С.А. Методические основы проектирования электронного учебника, Проектирование образовательных информационных ресурсов, систем и технологий. Сб. докладов и сообщений.- М., ИЦПКПС, 1998, 75с.

Аванесов В.С. "Научные основы тестового контроля знаний". М. Иссл. центр, 1994 .

http://www.usatic.narod.ru

1 ВАЛИДНОСТЬ означает пригодность тестовых результатов для той цели, ради чего проводилось тестирование.