Как сделать тест c

Обновлено: 03.07.2024

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

Общая теория и соображения по вопросам тестирования

Какие бывают тесты?

Существует несколько разных классификаций тестов. Например такая:

модульные тесты (unit-тесты);
функциональные тесты;
интеграционные тесты;
нагрузочные тесты;
тесты UI.

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

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

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

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

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

Что мы тестируем?

возвращаемое значение;
изменение состояния;
обращение к внешней стороне.

Возвращаемое значение

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

Изменение состояния

Здесь проверяем, что набор манипуляций, который мы сделали с объектом, привел к тому, что его состояние изменилось. Состояние определяется набором внутренних атрибутов (полей). Как правило, к ним мы напрямую доступ не имеем (а если имеем, то тут стоит задуматься, ибо это не очень хорошая практика), поэтому проверять изменение состояния приходится косвенным образом. Например, мы запустили исполнение через метод Run() и проверили, что все запустилось через свойство IsRunned или вызов метода с именем похожим на GetState() .

Обращение к внешней стороне

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

либо мы делаем заключение по объекту, который обращается к внешней стороне, в этом случае она (подмена) называется заглушкой ( stub );
либо мы делаем заключение, анализируя изменения в сущности, к которой обращались, в этом случае подмененная “внешняя сторона” называется подставкой ( mock ).

Если вы пока не знаете, заглушка это или подставка, то называйте ее подделкой ( fake ). Более подробно про это будет рассказано далее.

Структура теста

Довольно часто рекомендуют проектировать тест по следующему паттерну:

Arrange (Подготовка).
Act (Действие).
Assert (Проверка).

Так же можно встретить и такой подход:

Given (Дано).
When (Когда – деятельность, которая тестируется)
Then (Тогда – проверяемые аспекты)

Как именовать тесты?

Если у нас есть проект с именем SimpleProject , то тесты лучше размещать в проекте с именем SimpleProject.Tests .
В проекте SimpleProject есть набор классов, который нужно протестировать. Для этого в SimpleProject.Tests, повторяя ту же иерархию пространств имен, создаем классы с тестами, имена которых выглядят так: ClassNameTests .
Имена тестов можно задавать по следующему шаблону:

UnitOfWork_Scenario_ExpectedBehavior , где

UnitOfWork – имя единицы работы (например, имя метода или тестируемая функциональность).
Scenario – сценарий тестирования.
ExpectedBehavior – ожидаемое поведение.

Здесь есть смешение стилей именования CamelCase и snake_case , но благодаря читаемости, можно считать это допустимым (или нет, зависит от правил, которые у Вас приняты в команде).

Существует такой подход к разработке ПО как TDD ( Test Driven Development ). Суть в том, что мы сначала пишем тесты, потом код. Если вкратце, то работая в рамках данной методологии мы придерживаемся следующего правила: “ Красный – зеленый – рефакторинг ”. Т.е. пишем тест, который будет тестировать будущую функциональность, запускаем его (тест), он, естественно, не проходит (горит красным). Добавляем функциональность в проект, запускаем снова тесты, и делаем это до тех пор, пока тест не будет завершаться успешно, т.е. не станет зеленым. После этого проводим рефакторинг кода и тестов (убираем повторы и т.п.).

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

Как вариант, можно придерживается некоторого компромиссного решения, когда код и тесты пишутся параллельно, чаще код раньше, но очень маленькими порциями. Хотя может это и не совсем верно. Главное, чтобы код оставался тестопригодным.

Тестирование возвращаемого значения и изменения состояния

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

Бывает так, что необходимо проверить сразу несколько случаев, тогда возможны два варианта, в первом: в коде тестового метода создается коллекция с входными и ожидаемыми значениями, после этого в цикле перебираются эти наборы, поставляются в тестируемую единицу и проверяются. Во втором используются специальные атрибуты (например, в NUnit – это TestCase), через который передаются нужные значения в тест. Лучше использовать второй подход, т.к. в этом случае будет создано несколько тестов с разными значениями аргументов. Проблема первого варианта ещё состоит в том, что если в процессе прохождения одного из кейсов возникнет ошибка, то все тесты, после него выполнены не будут. Вариант с TestCase’ами предполагает, что будут выполнены все тесты.

Более подробно о том, как создавать наборы тестов, обращайтесь к документации по framework’у тестирования, который вы используете.

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

Зависимости

Начнем с зависимостей. Редко классы существуют сами по себе и ни от кого не зависят. Эти зависимости объекты классов используют в своей логике, а наша задача протестировать непосредственно саму логику. Как это сделать? Ответ: необходимо разорвать зависимости. По сути, нам нужно сделать так, чтобы используемые сущности можно было подменять в тестах.

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

Это сразу приводит к следующим вопросам: а куда эту реализацию подставлять, и где размещать упомянутые выше зазоры?

Это можно делать через:

конструктор;
свойства;
параметр метода;
фабричный класс;
локальный фабричный метод.

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

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

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

Создадим два сервиса, первый AlarmTemperService – для отслеживания превышений и MinMaxTemperService для определения мин. и макс. значений температуры за заданный интервал. Для представления данных нам понадобится класс Temper , для получения данных из БД – реализация DataMapper’а с интерфейсом ITemperDataMapper.

DataMapper – это шаблон проектирования, который предполагает создание прослойки между объектом и БД. Реализация в коде ITemperDataMapper’а нас, в данном случае, не очень интересует, главное, что мы выделили интерфейс.

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

TemperDataMapper ходит в БД, достает оттуда нужные данные, вытаскивает из них информацию о температуре и возвращает ее нам в виде списка объектов Temper .

Для примера приведем упрощенную реализацию сервиса AlarmTemperService :

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

Для того, чтобы протестировать этот сервис необходимо в тесте как-то подменить TemperDataMapper , чтобы он не работал с реальной БД, а выдавал для нас какие-нибудь демо данные. Сделаем это с использованием указанных выше способов.

Установка зависимости через параметр конструктора

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

Теперь в тесте мы может написать примерно следующее:

Объект, реализующий ITemperDataMapper, мы создаем с помощью фабрики MakeTemperDataMapper(). Таким образом, у нас появилась возможность тестировать функциональность метода IsAlarm, без необходимости организовывать подключение к БД с возможностью самостоятельно определять, какие данные будут переданы при тех или иных значениях параметров start и stop.

Установка зависимости через свойство или метод

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

Реализация установки зависимости через свойства предполагает добавление специального свойства в класс AlarmTemperService:

Если вы выбрали второй вариант, то необходимо реализовать метод для задания ITemperDataMapper’а.

Пример теста с вариантом задания зависимости через свойство.

Установка зависимости через фабричный класс

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

Объект, реализующий интерфейс ITemperDataMapper , создается с помощью метода Create(). Этот метод использует статическую переменную temperDataMapperType хранящую тип, экземпляр которого будет создаваться. При первом обращении к этому классу вызывается статический конструктор, в котором переменной temperDataMapperType присваивается значение – тип, определяющий класс TemperDataMapper – это тот, что работает с реальными данными. Т.е. по умолчанию все будет сделано автоматически, и самостоятельно ничего “подкручивать” не нужно.

Для задания класса, объекты которого будет создавать фабрика используется метод SetTemperDataMapper. Через него передается нужный тип, в самом методе предварительно делается проверка, что этот тип реализует интерфейс ITemperDataMapper.

Модифицируем код конструктора класса AlarmTemperService. Напоминаю, что изменению подлежит самый первый вариант, а не тот, в котором мы уже изменили конструктор или добавили свойство/метод.

Т.е. единственное, что сделали, это заменили вот эту строчку

Для того, чтобы в тесте класс AlarmTemperService использовал подставной DataMapper необходимо предварительно настроить фабрику. Это можно сделать в SetUp. Только не забудьте потом вернуть исходный вариант, если это критично.

Установка зависимости через локальный фабричный метод

Это, наверное, из всех рассматриваемых техник самая “оригинальная”. Идея заключается в том, что в классе AlarmTemperService мы создаем метод, который в дальнейшем переопределим, этот метод возвращает объект, реализующий ITemperDataMapper, который поставляет данные для обработки. Ниже приведена часть класса, с внесенными изменениями (за основу берем первый вариант):

Теперь в тестовом проекте TemperWorker.Tests создадим класс наследник от AlarmTemperService. Добавим туда открытое свойство для установки своей реализации ITemperDataMapper и переопределим GetTemperDataMapper(), так, чтобы он возвращал экземпляр, задаваемый через свойство. Сделаем это. Добавим в проект TemperWorker.Tests класс TestableAlarmTemperService.

Тест использующий TestableAlarmTemperService с поддельным вариантом ITemperDataMapper будет выглядеть так:

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

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

Тестирование обращения к внешней стороне (взаимодействия)

При тестировании взаимодействия, как мы уже сказали, возможны два варианта, того, что мы тестируем: изменения внутри тестируемого объекта либо у того, к кому он обращается.

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

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

Во втором случае, поддельный объект называется подставка (mock). Диаграмма для этого варианта будет такой.

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

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

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

Содержание статьи.

Создание простого теста

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

Как решить эту проблему. Учитель может воспользоваться онлайн конструктором тестов или же попытаться создать тест самостоятельно на основе использования шаблона. Именно второй вариант мы рассмотрим в данной статье.

Мы сформируем простой шаблон, который можно будет потом размножить на несколько файлов и каждый превратить в отдельный тест.

Допустим имеется несложный математический тест, состоящий из нескольких задач по математике:

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

Сначала создадим HTML код задач:

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

Обратите внимание на идентификаторы “z_1”,”z_2” и “z_3”. Если вам нужно добавить задачу 4, то нужно просто скопировать последнюю строку с задачей, заменить условие и в поле идентификатора написать “z_4”.

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

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

pr_otv_zadachi_1 = 55;
pr_otv_zadachi_2 = -9;
pr_otv_zadachi_3 = 85;

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

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

otv_uch_1 = document.getElementById(‘z_1’).value;
otv_uch_2 = document.getElementById(‘z_2’).value;
otv_uch_3 = document.getElementById(‘z_3’).value;

Четвертая задача будет означать новую строку с заменой цифр 3 на 4.

Далее нужно сравнить ответы ученика с правильными ответами. Если ответы будут совпадать, то за каждую задачу теста нужно добавить 1 балл.

ball = 0;
if(otv_uch_1 == pr_otv_zadachi_1) ball +=1;
>
if(otv_uch_2 == pr_otv_zadachi_2) ball +=1;
>
if(otv_uch_3 == pr_otv_zadachi_3) ball +=1;
>

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

Доброго времени суток.

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

Но пробовали ли вы создать тест самостоятельно? Возможно у вас есть свой блог или сайт и вы хотели бы проверить читателей? Или вы хотите проводить анкетирование людей? Или хотите выпустить свой обучающий курс? Еще лет 10-15 назад, чтобы создать простейший тест — пришлось бы потрудиться. Я еще помню времена, когда за зачет по одному из предметов, мне пришлось программировать тест на PHP (эх… было время). Сейчас же, хотел бы с вами поделиться одной программой, которая помогает кардинально решить эту проблему — т.е. создание любого теста превращается в удовольствие.

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

1. Выбор программы для работы

Несмотря на сегодняшнее обилие программ для создания тестов, я рекомендую остановиться на iSpring Suite. Ниже распишу из-за чего и почему.

iSpring Suite 8

Крайне простая и легкая в освоении программа. Например, я свой первый тест в ней сделал за 5 мин. (на основе того, как я его создавал — ниже будет представлена инструкция)! iSpring Suite встраивается в Power Point (эта программа для создания презентаций, есть в каждом пакете Microsoft Office, который установлен на большинстве ПК) .

Еще очень большим достоинством программы является ориентированность на человека, который не знаком с программированием, который никогда ранее не делал ничего подобного. Кроме всего прочего, один раз создав тест, вы можете его экспортировать в разные форматы: HTML, EXE, FLASH (т.е. использовать свой тест для сайта в интернете или для тестирования за компьютером) . Программа платная, но есть демо-версия (многим ее возможностей будет более, чем достаточно :)).

Примечание . Кстати, iSpring Suite кроме тестов, позволяет создавать множество всего интересного, например: создавать курсы, проводить анкетирование, диалоги и т.д. Все это в рамках одной статьи рассмотреть нереально, да и тема этой статьи несколько иная.

2. Как создать тест: начало. Первая страница приветствия.

Далее перед вами откроется окно редактора — оно очень напоминает окно в Microsoft Word или Excel, с которым, я думаю, почти все работали. Здесь можно указать название теста и его описание — т.е. оформить первый лист, который все будут видеть, при запуске теста (см. красные стрелки на скрине ниже).

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

3. Просмотр промежуточных результатов

Я думаю, со мной никто не будет спорить, что первое, что хотелось бы увидеть — это то, как это будет выглядеть в итоговом виде (а то может и не стоит забавляться дальше?!). В этом плане iSpring Suite выше всяких похвал!

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

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

4. Добавление вопросов в тест

Наверное, это самый интересный этап. Должен вам сказать, что всю мощь программы начинаешь чувствовать именно в этом шаге. Ее возможности просто поражают (в хорошем смысле этого слова) :).

Во-первых, есть два типа теста:

ТИПЫ ВОПРОСОВ для тестирования

1) Верно-неверно

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

2) Одиночный выбор

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

Пример: выбор правильного ответа

3) Множественный выбор

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

4) Ввод строки

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

Ввод строки — пример

5) Соответствие

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

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

7) Ввод числа

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

Ввод числа — пример

Этот тип вопросов довольно популярен. Суть его в том, что вы читаете предложение и видите место, в котором не хватает слова. Ваша задача — его туда написать. Иногда, сделать это не просто…

9) Вложенные ответы

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

Вложенные ответы — пример

10) Банк слов

Не очень популярный тип вопросов, однако, имеет место для существования :). Пример использования: вы пишите предложение, пропускаете в нем слова, но слова эти не скрываете — они видны под предложением для тестируемого. Его задача: правильно расположить их в предложении, чтобы получился осмысленный текст.

Банк слов — пример

11) Активная область

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

Активная область — пример

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

И так, как добавить вопрос

Далее обратите внимание на скрин ниже:

Составление вопроса (кликабельно).

Кстати, обратите внимание на то, что к вопросам так же можно добавлять картинки, звуки и видео. Я, например, добавил простую тематическую картинку к вопросу.

Тест — как выглядит вопрос.

5. Экспорт теста в форматы: HTML, EXE, FLASH

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

Если вы хотите использовать тест на компьютерах : т.е. принести тест на флешке (например), скопировать его на компьютер, запустить и посадить тестируемого. В этом случае, лучшим форматов будет EXE файл — т.е. самый обычный файл программы.

Если вы хотите сделать возможность прохождения теста на вашем сайте (по интернету) — то, на мой взгляд, оптимальным форматом будет HTML 5 (или FLASH).

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

Опубликовать тест — выбор формата (кликабельно).

В ажный момент

ИТОГИ

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

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

Кстати, приведу пару скринов самого теста.

ДОПОЛНЕНИЕ

Если вы экспортировали тест в формат HTML — то в папке для сохранения результатов, которую вы выбрали, будет файл index.html и папка data . Это файлы самого теста, чтобы запустить его — просто откройте в браузере файл index.html . Если хотите загрузить тест на сайт — то скопируйте эти файл и папку в одну из папок своего сайта на хостинге (извиняюсь за тавтологию) и дайте ссылку на файл index.html .

Пару слов о РЕЗУЛЬТАТАХ ТЕСТОВ / тестирования

iSpring Suite позволяет не только создавать тесты, но и получать в оперативном порядке результаты проверки тестируемых.

Как можно получать результаты от пройденных тестов:

Отправка по почту : например, ученик прошел тест — а вам потом пришел отчет на почту с его результатами. Удобно!?
Отправка на сервер : этот способ подойдет более продвинутым тесто-создателям. Вы можете получать отчеты о тестах на свой сервер в формате XML;
Отчеты в СДО : можно загрузить тест или опрос в СДО с поддержкой SCORM/AICC/Tin Can API и получать статусы о его прохождении;
Отправка результатов на печать : полученные результаты можно распечатать на принтере.

График прохождения теста

Дополнения по теме статьи — приветствуются. На сим закругляюсь, пойду тестироваться. Удачи!

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

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

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

Madtest

Конструктор для создания квиз-тестов и опросов. Можно создавать тесты как на сайте Meduza.io, больше подойдет для тестирования взрослой аудитории, для медиа и тех, кто размещает тесты и опросы у себя на сайте.

Цена: бесплатный тариф с ограничениями, платный тариф от 1990 рублей в месяц.

Возможности:

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

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

Обзор сервиса Madtest

Каhoot

Возможности:

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

Socrative

Цена: бесплатно, есть Pro версия за 60$ (при покупке 5 и более учителей одной школы скидки)

Возможности:

На заметку:
Сайт и приложение – на английском языке и полностью идентичны друг другу, легко осваиваются без знания языка. Работают только при наличии интернета.

Learningapps

Цена: бесплатно

Возможности:

На заметку:
В интерфейсе сайта 23 языка. Регистрацию проходит и учитель, и все учащиеся. Это нужно для формирования класса и отправки заданий.

Quizizz

Цена: бесплатно

Возможности:

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

Quizlet

Возможности:

!! Будьте внимательны, если не планируете продлить подписку. Деньги снимаются автоматически, если вы не отписались за сутки до окончания ее действия.

Online Test Pad

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

Цена: бесплатный

Возможности:

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

Минусы:

Так как этот сервис пользуется популярностью, он периодически “падает”.
Устаревший дизайн тестов.
Нет возможностей геймификации.

На заметку: больше подходит для тестирования взрослой аудитории и старших школьников.

Вебинар по созданию тестов + обзор сервисов и работа Online Test Pad. Смотрите запись здесь.

Создание тестов в Google Forms

Возможности сервиса:

Бесплатный.
Русифицированный.
Позволяет создавать тесты с разнообразными тестовыми заданиями.
Интегрирован с другими сервисами Google, в том числе успешно можно
использовать с Google Classroom.
Есть возможность отслеживать статистику.
Есть функция “ветвление”.

На наш взгляд: больше подходит для тестирования взрослой аудитории и старших
школьников.

Наш совет: используйте расширения, чтобы улучшить функционал тестов Google. Например: Flubaroo.

Читайте также: