Комп’ютерні тести. Технологія створення тестів для перевірки знань учнів.

Комп’ютерні тести. Технологія створення тестів для перевірки знань учнів.

Актуальність пошуку шляхів удосконалення у сфері технології створення тестових завдань немає потреби обґрунтовувати. Я розгляну кілька технологічних особливостей формування тестових завдань, які, на мій погляд, дозволяють істотно поліпшити якість останніх.

Я вважаю, що використання тестування слід розширити, але звузити коло навчальних завдань, які використовуються під час тестування. Тести слід використовувати лише для формальної перевірки знань і навичок і розглядати їх як обов'язкову програму або кваліфікаційний заїзд у спортивних змаганнях. З метою ж перевірки умінь викладати і осмислено використовувати знання слід використовувати публічний захист різного виду навчальних письмових робіт замість традиційних іспитів. Цілком резонно, що виконання лабораторних робіт слід розбивати на три етапи:

• автоматичне тестування ступеня підготовки до виконання роботи;
• власне виконання роботи;
• перевірку якості одержаних результатів та їх обробки.

Але в будь-якому випадку тестування має передувати захисту. При подібній технології у вчителя з'явиться хоч трохи часу для індивідуальної роботи.

На жаль, на сучасному етапі розвитку з'явилася ціла когорта теоретиків тестування, які в своїй більшості просто компілюють зарубіжний досвід використання тестів, побудований на помилковій концепції плутанини тестів, на визначення здібностей з тестами, на перевірку досягнень у навчанні. В такому короткому повідомленні я не зможу детально зупинитися на всіх помилкових аспектах теорії тестування, тому звертаю увагу читача на розділ «Висновки». Існує досить розроблена класифікація тестових завдань . Однак я хочу подивитися на такі класифікації з боку програміста.

З точки зору програмування раціонально об'єднати в один тип завдання з вибором відповідей незалежно від того, скільки серед запропонованих відповідей правильних: всі, кілька або жодного. Такі завдання слід формулювати у вигляді, який безпосередньо не вказує, скільки запропонованих відповідей вибрати учаснику тестування. У цьому випадку ймовірність несвідомого вгадування буде дорівнювати 1/2m, де m - кількість запропонованих варіантів відповідей. Чим менше ймовірність випадкового вгадування, тим якісніше тестове завдання. На моюдумку завдання, в яких треба вибрати всі або жодний варіант, настільки ж ефективні, як і завдання з вибором однієї або кількох варіантів.

З тієї ж точки зору завдання на встановлення відповідності ізоморфні завданням на встановлення порядку проходження. В останньому випадку для списку з положеннями встановлюється відповідність зі списком порядкових чисел.

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

Завдання відкритого типу з розгорнутою відповіддю слід взагалі виключити з тестів.

Були часи, коли існувала думка, що будь-який школяр, який вміє написати кілька операторів введення-виведення, може створити тестову комп'ютерну програму. Але поступово приходило розуміння, що не все так просто. Відбувся поділ на програмістів, що створюють програмні оболонки і викладачів, підбираючих тестові завдання. В даний час програмісти йдуть назустріч вимогам технології навчання і створюють професійно спрацьовані програмні оболонки для тестування зі стандартним дружнім інтерфейсом. Однак такі оболонки виявляються занадто формальними і відроджується стара ідея на новому рівні. З'являється думка, що учень, який опанував стартовий курс програмування, в тандемі з досвідченим викладачем (скажімо, відмінним фахівцем з матеріалу, але взагалі нетямущим в програмуванні) може створити пристойну тестуючу комп'ютерну програму. В результаті такої співпраці з'являються неймовірні програмні монстри, які, наприклад, викликають штучне зациклення операційної системи (учень вже володіє достатніми знаннями, як це зробити). Але він це робить на вимогу вчителя, який щиро вважає, що саме так треба перешкоджати спробам учасників тестування пройти тест шляхом багаторазового запуску тестуючої програми.

Спосіб створення тестів, коли програмна оболонка створюється програмістом, а тестові завдання вчителем, без алгоритмічних навичок, призводить до тестів низької якості. Зокрема, завдання, які не мають достатнього ступеня варіативності, стимулюють учасника тестування при підготовці шукати і знаходити спрощені алгоритми пошуку відповіді, але такі спрощені алгоритми майже завжди не відповідають дидактичній меті тестового завдання. У разі великого ступеня варіативності стає можливим повною мірою реалізувати ситуацію, при якій учень під час підготовки змушений засвоїти весь навчальний матеріал, передбачений дидактичною метою. Я переконана, що настав час, коли тандем програміст-вчитель повинен придбати нову якість, коли програміст знає навчальний предмет, а викладач розбирається в алгоритмізації. Звичайно, кожен з них щось робить краще, хтось краще розбирається в алгоритмах, а хтось в навчальному предметі, але вони повинні вміти розуміти один одного, як розуміють один одного пілот і штурман в автомобільному ралі.

Наведемо приклад тестового завдання з програмною варіацією.

«У легендарній країні Перепутанії в конституції записані правила переплутування значень очок набраних гравцями в популярній грі "Шахрай". Які значення параметрів a, b i bon з'являться на екрані після виконання останнього оператора наступної програми, яка реалізує конституційний алгоритм Перепутании?

{1} var a,b,bon: integer; // окуляри набрані гравцями і розмір бонусу

{2}

{3} procedure bonusator(x:integer; var y:integer; z:integer); // облік бонусу

{4} begin x:= x+2*z; //нарахування бонусу першому гравцеві

{5} y:= y+3*z; // нарахування другого гравцеві

{6} end;

{7 розрахункова функція головного закону Перепутании}

{8} function plutator(var x:integer; y:integer; z:integer):integer;

{9} begin x:=2*y+3; //обов'язкове переплутування

{10} z:=3*x+2*y; // контрольне переплутування

{11} y:=4*z-5; // довільне переплутування

{12} plutator:=y; // повернення результату переплутування

{13} end;

{14}

{15} begin //початок основної процедури

 Сто шістдесят п'ять

{16} a:=7; b:=5; bon:=3; // стартові значення параметрів задачі

{17} bon:=plutator(a,b,bon);//виконання конституційного алгоритму

{18} bonusator(b,a,bon);// облік бонусу

{19} writeln('a=',a,' b=',' bon=',bon);

{20} end. // кінець програми

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

Дидактична мета цього завдання полягає у перевірці:

• чи розуміє учасник тестування відмінності між значеннями параметрами та змінними параметрами,
• чи має навички їх використання для трактування роботи комп'ютерної програми;
• чи розуміє відмінності у призначенні формальних і фактичних параметрів та порядок проходження останніх впливає на результат;
• чи розуміє, як використовуються глобальні і локальні параметри;
• чи розуміє учасник тестування, як працює оператор присвоювання.

На перший погляд може здатися, що дидактична мета занадто складна. Однак слід зауважити, що редукція зазначеної дидактичної мети, наприклад, на три групи параметрів, як це часто робиться, призведе до втрати перевірки розуміння конструктивної цілісності у використанні параметрів процедур. У навчанні програмування, взагалі кажучи, дуже небезпечно зайве дроблення навчального матеріалу. Так, наприклад, роздільне вивчення різних видів циклу не наближає учнів до вміння вибрати потрібний тип циклу, виходячи з вимог алгоритму, а саме для можливості такого вибору і були розроблені різні типи циклів.

Перша необхідна дія для збільшення варіативності завдання полягає в тому, що потрібно випадковим чином задавати стартові значення параметрів в рядку 16. Якщо забезпечити варіацію вихідних значень параметрів в діапазоні від 0 до 99, то ймовірність примітивного вгадування коливатиметься від однієї тисячної до . Друга дія генератора питання - це варіація числових параметрів в операторах присвоювання у рядках 4, 5, 9, 10 і 11. Наступний крок полягає в тому, що випадковим чином змінюється положення ключового слова var в списку параметрів заголовків в рядках 3 і 8. Далі слід змінювати порядок проходження фактичних параметрів у виклику процедур і функцій рядка 17 і 18. Не слід забувати забезпечити випадковий вибір параметра, який передається в рядку 12. І, нарешті, щоб бути впевненим, що учень при подготовці до тестування не завчить спрощений варіант алгоритму пошуку правильної відповіді, непогано було б забезпечити перетасовку проходження операторів присвоювання в тілі функції, а також міняти місцями рядки 17 і 18 в головній процедурі програми.

Всі перераховані вимоги можуть бути досить просто реалізовані в процедурі генератору варіантів даного завдання. Створення такої процедури потребує значно більше часу, ніж формування всього лише одного варіанту, але зате таке багато варіативне завдання може послужити основою для комп'ютерного тренажера, створення якого, на мій погляд, значно важливіше ніж просто створення тесту.

Висновки:

1. Тести на перевірку досягнень в засвоєнні навчальної програми істотно відрізняються від тестів на визначення здібностей.

2. Всі завдання в тесті на досягнення в навчанні повинні мати однакову вартість в балах. Різна складність завдань, що виявляється при репрезентативному тестуванні, вказує лише на неточності в розподілу ресурсів навчального процесу. Підсумкове тестування не повинно залежати від конкретних методик.

3. Тест, як будь-який прилад вимірювання, має нижню межу чутливості, який визначається ймовірністю довільного вгадування відповіді. Звідси випливає вимога до зниження можливостей знайти відповідь простим вгадуванням. Якщо позбутися від подібних можливостей з якоїсь причини не вдається, то слід набрані таким способом бали віднімати з результату учасника тестування. Наприклад, якщо завдання вартістю в один бал має ймовірність вгадування 0.2, то учасник, правильно вказав відповідь, отримає лише 0.8 бали.

4. Банк тестових завдань повинен бути опублікований до проведення тестування.

5. Щоб уникнути підміни навчального процесу «натаскуванням» на проходження тестів, необхідно забезпечити багатоваріантний характер завдання. Тобто варіантів завдання повинно бути стільки, щоб, як мінімум, покрити всі аспекти дидактичної мети. Варіант завдання повинен генеруватися безпосередньо перед пред'явленням його учаснику тестування. Щоб створити подібний генератор варіантів завдання необхідна тісна взаємодія програміста і дидакта, аж до їх взаємозамінності.

6. Настає нова ера в створенні тестових завдань. Вона висуває нові вимоги до конструкторів комп'ютерних тестів - програміст повинен знати матеріал навчального предмета, а дидакт розбиратися в алгоритмізації.