Определение структуры теста. Разработка спецификации теста

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

Пусть задан следующий фрагмент набора требований для модели обмена транзакциями:

  1. Функция DoTransaction должна принимать адрес и данные в соответствии с параметрами, создавать в очереди новый элемент, заполнять его адресную часть и часть полей данных переданной информацией и инициировать транзакцию
  2. Функция DoAddressTenure должна принимать адрес в соответствии с параметрами, создавать в очереди новый элемент и заполнять его адресную часть
  3. Функция DoDataTenure должна принимать данные в соответствии с параметрами, находить в очереди первый элемент с частично незаполненными полями данных, дополнять его переданной информацией и инициировать транзакцию

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

  1. Вызвать DoTransaction с адресом и данными. Проверить появление в очереди еще одного элемента. Проверить появление на шине транзакции с правильными адресом и данными.
  2. Вызвать DoAddressTenure с адресом. Проверить появление в очереди еще одного элемента. Проверить отсутствие новой транзакции на шине.
  3. Вызвать DoDataTenure с данными. Проверить заполнение полей данных. Проверить появление на шине транзакции с правильными адресом и данными

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

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

  1. Определяется модель использования, включающая операционное окружение продукта и "актеров". Актером может быть пользователь, другой продукт, аппаратная часть и тому подобное, то есть все, с чем продукт обменивается информацией. Разделение на окружение и актеров условно и служит для описания оптимальных способов использования продукта.
  2. Разрабатываются сценарии использования продукта. Описание сценария в зависимости от продукта и выбранного подхода может быть строго определенным, параметризованным или разрешать некоторую степень неопределенности. Например, описание сценария на языке MSC допускает задание параметризованных сценариев с возможностью переупорядочивания событий.
  3. Разрабатывается набор тестов, покрывающих заданные сценарии. С учетом степени неопределенности, заложенной в сценарии, каждый тест может покрывать один сценарий, несколько сценариев, или, наоборот, часть сценария.

Использование сценариев не требует наличия полной формальной спецификации требований, но зато может потребовать больше времени на разработку и анализ.

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

Пример использования спецификации требований для разработки тестов.

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

  1. Сценарий: пользователь имеет две независимые нити управления, одна из которых отвечает за генерацию полных транзакций посредством DoTransaction , а другая – за сбор транзакций из адресной части и части данных, когда эта информация приходит из разных источников. Таким образом, вторая нитка использует вызовы к DoAddressTenure и DoDataTenure .
  2. Описание тестов: Вызвать DoAddressTenure c адресом А1 , вызвать DoTransaction с адресом А2 и данными D2 , вызвать DoDataTenure с данными D1 . Проверить последовательное появление на шине двух транзакций: {А1, D1} и {А2, D2}

При выполнении этого теста было, в частности, обнаружено, что функция DoTransaction была реализована через вызовы к DoAddressTenure и DoDataTenure , что приводило к появлению на шине транзакций вида {А1, D2} и {А2, D1} . Подобный дефект может быть обнаружен с большим трудом, если разрабатывать тесты, основываясь только на спецификации требований.

Ручная разработка тестов

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

Генерация тестов

В настоящее время некоторые языки спецификаций, используемые для описания алгоритмов тестирования, могут быть использованы для генерации тестового кода. Рассмотрим генерацию кода из языка MSC. Тест, описанный выше, формализован на языке MSC (Рис. 9.3). Здесь каждая стрелка с пометкой DoTransaction , DoAddressTenure или DoDataTenure представлет собой вызов соответствующей функции продукта с передачей параметров. Стрелка checkTr соответствует проверке прохождения по шине транзакции с соответствующими параметрами. Каждая из стрелок диаграммы генератором тестов преобразуется в исполнимый код, при этом стрелкам, представляющим собой вызовы функций может соответствовать достаточно простой и маленький участок кода, вызывающий соответствующую функцию и проверяющий ее выходное значение на наличие ошибок.


Рис. 9.3.

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

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

Планирование содержания теста

Конкретизированные цели обучения

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

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

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

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

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

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



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

Примечание. Рассмотреть примеры спецификаций по конкретным дисциплинам: истории, математике, информатике и др.

Спецификация теста Е.Ю. Карданова, 04.10. 2012 Спецификация теста Документ, в котором содержится информация о целях, задачах, плане и структуре педагогического теста, а также основные требования к правилам проведения педагогического тестирования, обработке результатов и их интерпретации. На данном этапе разрабатывается первая версия. По итогам дальнейшей работы над тестом спецификация может меняться. Окончательный вариант спецификации предоставляется любым пользователям теста и является необходимой частью пакета тестовых документов, наряду с самим тестом. Спецификация теста Цель создания теста. Обоснование выбора подхода к его созданию. Описание возможных сфер применения. Перечень документов, используемых при планировании содержания теста (образовательный стандарт, программа). Основные учебники и учебные пособия, которые могут быть использованы при подготовке к тестированию. Перечень элементов содержания и компетенций, проверяемых в ходе тестирования (в частности, кодификатор элементов содержания теста и компетентностная карта дисциплины). Перечень требований к уровню подготовки обучающихся, проверяемых в ходе тестирования. Описание общей структуры теста, перечень субтестов (если они есть) с указанием подходов к их разработке. Описание теста: общее количество заданий, тип заданий с указанием процентного содержания или количества заданий каждой формы, описанием каждой формы. Рекомендуемая автором стратегия расположения заданий в тесте, т.е. композиция теста. Распределение заданий теста по разделам содержания и видам деятельности (содержательнодеятельностная матрица). Рекомендуемое время выполнения теста, в том числе и на каждый субтест, среднее время выполнения каждого задания с учетом специфики формы. Рекомендации автора по оцениванию заданий (дихотомическая или политомическая оценка) и теста в целом. План теста по отдельным заданиям (обобщенный план теста). Кодификатор элементов содержания учебной дисциплины Перечень элементов содержания дисциплины, в котором каждому элементу содержания присвоен собственный код При составлении кодификатора все содержание дисциплины выражается в виде перечня логически завершенных содержательных модулей – разделов, подразделов, тем, подтем, отдельных элементов содержания учебной дисциплины Элемент содержания учебной дисциплины – это логически завершенная минимальная часть учебной дисциплины, определенная нормативными документами (образовательным стандартом, программами). Фрагмент кодификатора КИМ ЕГЭ по истории (цитируется с официального сайта ФИПИ: http://www.fipi.ru/view/sections/93/docs/58.html) Код раздела Код контролируемого элемента История России с древности до конца XVI в. 1 1.1 1.1.1 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.3 Элементы содержания, проверяемые заданиями КИМ Восточные славяне в VI-VIII вв. Расселение, занятия, быт, верования восточных славян. Славяне и их соседи Древнерусское государство (IX- первая половина XII в.) Формирование древнерусского государства. Новгород и Киев. Версии происхождения государства на Руси Население сел и городов. Развитие ремесла и торговли. «Русская правда» Князья Древней Руси. Князь и дружина Крещение Руси. Распространение христианства Культура и быт Древней Руси Русь в ХII-ХVвв. ……………………………………………………….. Компетентностная карта дисциплины методический документ, содержащий информацию о компетентностных результатах образования, зафиксированных в образовательном стандарте по данному направлению подготовки, и формируемых средствами данной дисциплины, а также об уровне и методах их формирования в рамках данной дисциплины. Компетентностная карта дисциплины № 1 2. . Компетенции Код Степень Дескрипторы по формирования – основные (формулировка ОрОС компетенции признаки из освоения образовательного (РБ, СД, МЦ) (показатели стандарта) достижения результата) Формы Методы оценки и методы уровня формировани сформирован я и развития ности компетенции компетенции * * Системные компетенции 1.1 1.2… 2.1 2.2… Инструментальные компетенции Социально-личностные компетенции Содержательно-деятельностная матрица Включает примерную раскладку процентного соотношения содержания разделов дисциплины и определение необходимого количества тестовых заданий различного уровня трудности, исходя из важности раздела и числа часов, отведенных на его изучение в программе. Работа по отбору содержания теста и определению для каждого элемента содержания уровня его усвоения была проведена на первых этапах работы над содержанием теста, поэтому на данном этапе все эти данные суммируются и оформляются в виде одной таблицы. Содержательно-деятельностная матрица теста (пример) Проверяемые знания и виды деятельности 1 раздел 20% Разделы содержания 2 раздел 3 раздел 30% 40% 4 раздел 10% Всего заданий Знание понятий, определений, терминов (10%) Знание законов и формул (30%) Применение формул и законов (30%) Нахождение сходств и различий (20%) 1 1 3 1 6 4 5 7 2 18 4 5 7 2 18 2 4 5 1 12 Умение интерпретировать материал на графиках и схемах (10%) Всего 1 3 2 0 6 12 18 24 6 60 Обобщенный план теста Таблица, в которой каждое тестовое задание соотносится с определенным элементом содержания учебной дисциплины и оцениваемым уровнем компетенции обучающегося. Указывается форма и вид тестового задания План теста по отдельным заданиям (Обобщенный план теста) № задания Раздел (элемент) содержания учебной дисциплины Проверяемая компетенция (код согласно компетентностной карте дисциплины) Степень формирования компетенции Тип Время задания выполнения (мин.) Максимальный балл за выполнение задания

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

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

Форма - способ существования и выражения содержания, главной функцией которой является донесение до тестируемого содержания задания как можно понятнее, нагляднее.

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

Для такого задания характерны:

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

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

Закрытая форма

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

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

В закрытой форме ответы не могут быть все верными или все неверными.

Примеры:

Новая страница 1

Открытая форма

Имеет вид неполного утверждения, в котором отсутствует один или несколько ключевых элементов (число, буква, слово). Ответ формулируется самим тестируемым.

Примеры:

Новая страница 1

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

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

Примеры:

Новая страница 1

1) Соответствие между авторами и их произведениями 2) Соответствие между авторами и их произведениями
У. Эко Имя Розы Б. Акунин Алмазная колесница
Ф. Ницше Так говорил Заратустра Любовник смерти
Ф. Достоевский Идиот Ошо Близость
Сознание Осознание
Война и мир Ф. Ницше Так говорил Заратустра
Отверженные

Обратим внимание, что в данном примере задание 1 является заданием на соответствие «один к одному» с двумя альтернативными элементами («Сознание», «Война и мир»), а задание 2 - «соответствие один ко многим» с одним альтернативным элементом - «Отверженные».

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

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

Например, при конструировании «опросника супружеского статуса» Дж. Руст и С. Голомбок (Rust, Golombok, 1988) основывались на опросе экспертов, в качестве которых выступали семейные терапевты и консультанты, а также на данных, полученных от клиентов этих специалистов. Экспертов просили назвать те области взаимоотношений между мужчиной и женщиной, которые они полагали наиболее важными для гармоничного брака. Информация от клиентов позволила обнаружить те проблемные зоны семейной жизни, в которые супруги хотели бы внести изменения. На этой основе были выделены такие содержательные области, как «совместные интересы и степень зависимости – независимости», «вербальная и невербальная коммуникации», «доверие и уважение» и др. Ясное понимание цели будущего теста, естественно, облегчает построение перечня того, что предстоит измерять. При спецификации манифестаций важно обеспечить выделение различных форм их реализации. Так, при конструировании вышеупомянутого опросника «установки и чувства, проявляющиеся в отношениях» рассматривались как манифестации «вербальных и невербальных коммуникаций» между супругами.

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


При разработке опросников обычно считают, что решетка размером от 16 до 25 ячеек (например, 4x4,4x5, 5x4 или 5x5) считается идеальной для той длины теста, который вполне реально сконструировать, предъявить и обработать.

Далее необходимо определить, сколько заданий, например вопросов, должно быть создано для каждой из ячеек. При решении этой задачи следует руководствоваться тем, насколько важным представляется исследователю измерение одного из параметров сравнительно с другим или другими. В решетке, приведенной в табл. 3.2 (Rust, Golombok, 1989), допускается, что содержательным областям, обозначенным как Аи В, следует приписать 40 %-ный вес, а С и D – 10 %-ный. В то же время каждой манифестации А, В, C и D приписывается 25 %-ный вес. Необходимо обратить внимание на то, что в целом процентный вес всех содержательных областей (по горизонтали) и всех манифестаций (по вертикали) должен составлять 100 %. Такое расположение процентных весов подскажет, какую часть от всех заданий следует создать для каждой ячейки. Следующий шаг состоит в том, чтобы решить, какое количество заданий должно быть включено в тест. При этом необходимо учитывать такие факторы, как размер решетки и время, предполагаемое для выполнения заданий. Хорошо известно, что в определении количества заданий перед исследователем возникает дилемма: обеспечение, с одной стороны, надежности теста, что требует увеличения заданий, а с другой – минимизация количества заданий для обеспечения эффективной работы испытуемого с ними, подразумевающей прежде всего поддержание концентрации внимания в ходе обследования. Так, для достижения удовлетворительной надежности опросника требуется не менее 20 заданий, выполнение которых обычно занимает не более 10 минут. Наконец, важную роль в определении количества заданий теста играют особенности того контингента, который предполагается обследовать. Обычно при проводимом разработчиками пилотажном исследовании количество заданий предварительного варианта теста должно быть по крайней мере на 50 % больше числа тех, которые будут включены в окончательную версию.

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

2024 litera-globus.ru. literaglobus - Образовательный портал.