Правила составления тестовых заданий

РефератПомощь в написанииУзнать стоимостьмоей работы

Это требование заимствовано у психологов. Действительно, дополнять слово в конце предложения легче, однако это скорее не правило, а пожелание Запуск тестов Запуск двух методов с разными значениями для debitAmount показывает, что тесты корректно обрабатывают оставшиеся варианты. Запуск всех трех тестов позволяет убедиться в том, что все варианты исходного анализе были правильно покрыты тестами… Читать ещё >

Правила составления тестовых заданий (реферат, курсовая, диплом, контрольная)

Тестовые задания должны быть составлены с учетом определенных правил.

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

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

4. При составлении вопросов следует особенно внимательно использовать слова «иногда», «часто», «всегда», «все», «никогда».

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

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

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

7. Неправильные ответы должны быть разумны, умело подобраны, не должно быть явных неточностей, подсказок.
8. Не следует задавать вопросы с подвохом (скорее всего, в заблуждение будут введены наиболее способные или осведомленные обучающиеся, которые знают достаточно для того, чтобы попасться в ловушку, а также это противоречит цели — определение уровня знаний и понимания).
9. Все варианты ответов должны быть грамматически согласованы с основной частью задания; в любом случае следует использовать короткие, простые предложения, без зависимых или независимых оборотов.
10. Как можно реже использовать отрицание в основной части.

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

11. Правильные и неправильные ответы должны быть однозначны по содержанию, структуре и общему количеству слов; применяйте правдоподобные ошибочные варианты, взятые из опыта.
12. Не используйте варианты ответов «ни один из перечисленных» и «все перечисленные».
13. Убедитесь, что различия между вариантами ответов точны.

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

14. Избегайте повторения в вариантах ответов.
15. Используйте ограничения в самом вопросе для того, чтобы снять неопределенность, которая может возникнуть при вводе ответа.
16. Не упрощайте вопросы.
17. Лучше использовать длинный вопрос и короткий ответ. В противоположной ситуации на прочтение ответов уходит больше времени и больше сил тратится на анализ высказываний.
18. Проанализируйте задания с точки зрения возможности неверного ответа наиболее подготовленных испытуемых.
19. Национальные системы ряда стран ставят специфические требования к тестовым заданиям, на которые у нас пока обращается недостаточно внимания. В качестве примера приведем требование инструкции по составлению тестов, предоставленной NEAB (Northen Examinationes and Assesment Board): «Необходимо избегать вопросов, которые в каком-либо виде дают превосходство тестируемому определенного пола. Половой ориентации вопроса необходимо избегать в любом случае. Нельзя считать, что формулировка вопроса в мужском роде подразумевает большую легкость ответа, чем в женском роде. Использование формулы „он/она“ также нежелательно, при формулировании вопросов. Лучше пользоваться неродовыми формулировками». Лучше обращаться к группе, а не к отдельному обучающемуся.

Правила, специфичные для заданий дополнения.

20. Использовать не более двух пропусков подряд (лучше один).

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

21. Дополнять нужно наиболее важное. Правильный ответ должен демонстрировать тот элемент знания, который нужно проверить.
22. Дополнения лучше ставить в конце предложения.

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

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

C#.

throw new ArgumentOutOfRangeException («amount»);

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

Выполнение рефакторинга тестируемого кода Сначала определим две константы для сообщений об ошибках в области видимости класса:

C#.

// class under test.

public const string DebitAmountExceedsBalanceMessage = «Debit amount exceeds balance» ;

public const string DebitAmountLessThanZeroMessage = «Debit amount less than zero» ;

Изменим два условных оператора в методе Debit:

C#.

// method under test.

// …

if (amount > m_balance).

throw new ArgumentOutOfRangeException («amount», amount, DebitAmountExceedsBalanceMessage);

if (amount < 0).

throw new ArgumentOutOfRangeException («amount», amount, DebitAmountLessThanZeroMessage);

// …

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

· Сработает предупреждение, что свойство ActualValue исключения (второй параметр конструктора ArgumentOutOfRangeException) больше начального баланса. В данном случае необходимо сравнить свойство ActualValue исключения со значением переменной beginningBalanceтестового метода, а также проверить, что значение ActualValue больше нуля.
· Сработает предупреждение, что сообщение (третий параметр конструктора) включает указанное DebitAmountExceedsBalanceMessage в классе BankAccount.

Метод StringAssert. Contains платформы модульных тестов Microsoft позволяет проверить второй параметр без вычислений, необходимых в первом случае.

Вторая попытка корректировки Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange будет выглядеть следующим образом:

C#.

[TestMethod].

public void Debit_WhenAmountIsGreaterThanBalance_ShouldThrowArgumentOutOfRange ().

// arrange.

double beginningBalance = 11.99;

double debitAmount = 20.0;

BankAccount account = new BankAccount («Mr. Bryan Walton», beginningBalance);

// act.

try.

account.Debit (debitAmount);

catch (ArgumentOutOfRangeException e).

// assert.

StringAssert.Contains (e.Message, BankAccount. DebitAmountExceedsBalanceMessage);

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

1. При верном обнаружении ошибки в случае, если debitAmount больше баланса, проверка утверждения Contains проходит успешно, исключение игнорируется и тестовый метод завершается успешно. Это соответствует ожидаемому поведению.
2. Если используется debitAmount, то проверка утверждения завершается неудачей, так как возвращается неверное сообщение об ошибке. Проверка утверждения также завершается неудачей, если ввести временное исключение ArgumentOutOfRange на другом шаге в коде тестируемого метода. Это слишком хорошо.
3. Если значение debitAmount допустимо, (т е распределение, но больше нуля, исключение не обработано, поэтому подтверждение никогда не обработано. Тестовый метод проходит успешно. Это неверно, поскольку тестовый метод должен был завершиться ошибкой в том случае, если исключение не создается.

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

Однако повторное тестирование показывает, что тест проходит неуспешно при перехватывании верного исключения. Оператор catch сбрасывает исключение и метод продолжает выполняться, приводя к ошибочному срабатыванию следующего утверждения. Чтобы разрешить эту новую проблему, добавим оператор return после StringAssert. Повторное тестирование подтверждает, что все проблемы были решены. Наша окончательная версия Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange выглядит следующим образом:

C#.