Система тестування на основі відносного оцінювання по статистичним вибіркам



Стаття | Article    

Download

Testing system based on relative evaluation of statistical samples

Kovalenko Ihor

Vovchok Eugene

Kyiv, Ukraine

Annotation: The purpose of the article is to review the available ways to solve the problem of assessing the quality of knowledge by testing and to model an architectural solution that combines all the advantages and will not contain the disadvantages of the examined analogues. The optimal solution within the criteria specified in the article is a software product created on the basis of client - server architecture in which the server component is implemented as a single architectural unit, to ensure ease of deployment and reduce the cost of system support.

Keywords: testing systems; establishing the level of knowledge; statistical sample; client-server architecture.

Коваленко Ігор

КПІ ім. Ігоря Сікорського

meelistenso@gmail.com

Вовчок Євген

КПІ ім. Ігоря Сікорського

vovchok.zhenya@gmail.com

Київ, Україна

Анотація: Мета публікації – переглянути наявні способи вирішення завдання по проведенню оцінювання якості знання способом тестування і змоделювати архітектурне рішення, яке поєднує всі переваги, а також не буде містити недоліків оглянутих аналогів. Оптимальним рішенням в межах обумовлених в статті критеріїв є програмний продукт створений на основі клієнт – серверної архітектури в якій серверний компонент реалізовано у вигляді єдиної архітектурної одиниці, для забезпечення простоти розгортання та зниження вартості підтримки системи.

Ключові слова: системи тестування; встановлення рівня знань; статистична вибірка; клієнт–серверна архітектура.

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

Після огляду популярних систем тестування, представлених на веб-порталах, зокрема, мережевої академії Cisco, Canvas, Blackboard Learn, Kahoot!, та на основі досвіду проходження тестів під час навчання, було сформовано перелік основних типів тестів. Для повної реалізації функціональних вимог і конкурентоздатності з переліку було обрано наступні види тестів, які повинні міститися у системі:

  1. Правильно/неправильно – користувач повинен визначити чи правдиве твердження в питанні. Це найпростіший тип питання.

  2. Вибір однієї відповіді – користувачу потрібно вибрати одну правильну відповідь з запропонованих варіантів.

  3. Вибір кількох відповідей – користувач обирає правильні варіанти зі списку. Завдання такого типу складніші чим вибір однієї відповіді, так як кількість правильних відповідей заздалегідь невідома. Правильна відповідь методом випадкового підбору малоймовірна.

  4. Коротка відповідь – користувач повинен ввести правильну відповідь в текстове поле. Для правильної відповіді необхідно добре розбиратись у тематиці поточного питання.

  5. Послідовність – користувач розміщує елементи у правильній послідовності.

  6. Числова відповідь – користувач вводить число у поле для відповіді. Вгадати правильну відповідь малоймовірно.

  7. Відповідність – користувач повинен з’єднати пари слів, фраз, або зображень. Додаткові «зайві» варіанти відповідності можуть ускладнити питання.

При створенні тесту є необхідність виставлення прохідного балу. Крім того, існує проблема встановлення еквівалентності ваги правильних відповідей, оскільки різні питання можуть посилатися на різні об’єми знань, можуть мати неточності, бути складними для розуміння. Універсальний рецепт для фіксованого значення прохідного балу відсутній, тому необхідно зробити його відносним. Як рішення для забезпечення об’єктивності тестування обрано динамічне визначення ваги правильних відповідей відносно загальної статистики відповідей користувачів на питання тесту у межах системи.

Для того, щоб охопити якнайбільшу область знань, але при цьому не виснажувати користувача, понижуючи його продуктивність було вирішено надати можливість встановлення довільної кількості запитань адміністратором системи та встановлено рекомендований обсяг 25-30 питань. При цьому загальний банк питань повинен бути не менше ніж у 3-4 рази більшим, ніж кількість питань у згенерованому адміністратором тесті з метою забезпечення унікальності тестів у різних користувачів і виключення можливості плагіату та розповсюдження набору готових питань-відповідей на тест. Також для виключення можливості користування додатковими матеріалами користувачем необхідно, щоб тест передбачав обмеження по часу, яке встановлюється адміністратором.

На сьогоднішній день існує безліч систем онлайн-тестування.

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

Відповідно до призначення тести поділяються на:

  1. Навчальні – ті, що допомагають закріпити вивчений матеріал. Зазвичай такі тести можна знайти після кожної глави у курсі в якості невеликої практики. Відсутні обмеження по часу, штрафи за неправильні відповіді. На вирішення задач надається кілька спроб. Після кожної помилки відображаються пояснення. Як приклад, тести що стають доступні після завершення вивчення глав у системі мережевої академії Cisco.

  2. Атестаційні – допомагають оцінити знання користувача. В таких тестах присутні обмеження по часу, дається одна спроба на відповідь, відсутні пояснення помилок. Як приклад, Exam.net.

За спеціалізацією, тестові системи поділяються на:

  1. Спеціальні – ті, що призначені для застосування лише у певних сферах. Як приклад, нині популярні системи тестування персоналу SHL, TalentQ, Kenexa, або система тестування інтегрована у платформу Udemy, призначена для оцінки засвоєних навичок після проходження курсу.

  2. Загальні – ті, що мають широке призначення. Різноманітні конструктори тестів та більш загальні системи як Google Forms.

Більшість наявних систем не об’єднують тестування та навчання шляхом встановлення незнання та його ліквідацію за допомогою опису і вказання правильних відповідей шляхом пояснень. Крім того ні одна з них не вирішує проблему еквівалентності ваги правильних відповідей. Також присутня проблема різноманітності форми тестових завдань і сучасності UX [1] частини систем. Як приклад Moodle, мережева академія Cisco мають застарілий дизайн та вузький перелік форм тестових питань.

У результаті огляду прийнято наступні вимоги до проектованого рішення:

  1. Можливість додавання пояснень та посилань до відповідних питанням тем та їх пов’язування.

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

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

  4. Розробка сучасного дизайну.

  5. Широка спеціалізація системи, шляхом налаштувань формату тестів.

Відповідно до сформованих вимог про наявність багатьох користувачів та необхідність централізованого збереження інформації про результати тестів, їх оцінювання, для даного класу підсистем доцільне використання наступних архітектур міжкомпонентної взаємодії: SOA, client-server [2].

КЛІЄНТ-СЕРВЕРНИЙ ПІДХІД

Даний шаблон складається з двох частин: сервера і безлічі клієнтів, рис 1. Серверний компонент надає сервіс клієнтським компонентам. Клієнти запитують сервіс у сервера, а він, у свою чергу, надає їх клієнтам [3].

Рис. 1. Схема комп'ютерної мережі клієнтів, що спілкуються з сервером через мережу Інтернет

Зазвичай використовується для реалізації онлайн додатків (електронна пошта, спільний доступ до документів, банківські послуги, тощо).

Переваги:

  1. Підходить для моделювання набору сервісів, які можуть запитувати клієнти.

Недоліки підходу:

  1. Запити зазвичай виконуються в окремих потоках на сервері.

  2. Взаємодія між процесами підвищує ресурсовитратність, тому що різні клієнти мають різне представлення.

ПІДХІД SOA

Сервісно-орієнтована архітектура (SOA) – спосіб побудови міжкомпонентної взаємодії програмного забезпечення, за якого послуги надаються іншим компонентам компонентами додатків, через протокол зв'язку по мережі [3]. Сервіс SOA - це дискретна одиниця функціональності, до якої можна отримати доступ дистанційно, діяти та оновлюватись незалежно, наприклад, отримання виписки з кредитної картки в Інтернеті.

В межах SOA архітектури виділяють наступні елементи, які відображені на рис. 2.

Рис. 2. Елементи SOA

Сервіс відповідно до визначення SOA, має наступні властивості:

  1. Представлення поведінкової логіки із заданим результатом.

  2. Обмежена відповідальність в межах одного бізнес-завдання.

  3. Це чорна скринька для споживачів, тобто споживач не повинен знати про внутрішню роботу служби.

  4. Можливість об’єднання набору інших сервісів.

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

  1. Неоднорідність і складність рішення.

  2. Величезний набір тестових комбінацій завдяки інтеграції автономних сервісів.

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

  4. Платформа постійно змінюється через наявність нових функцій і послуг.

ТЕХНІЧНЕ РІШЕННЯ

Під час розробки технічного рішення для серверної частини було розглянуто найпопулярніші технології для побудови веб застосунків а саме CGI (C++), ASP.NET CORE (C#) та Spring (Java) [1].

В першу чергу було розглянуто порівняльну характеристику CGI та ASP.NET CORE, а саме швидкість пошуку та видачі даних на порівнюваних платформах. Виходячи з даних графіку представленого на рис. 3, рішення на базі CGI має більшу швидкодію. Проте, на відносно невеликих об’ємах даних розрив у швидкодії скорочується. Крім цього розробка на базі мови C++ є значно витратнішою та займає більше часу, через технічні особливості мови та наявність безпосереднього управління оперативною пам’яттю в межах створюваного процесу [7].

Рис. 3. Порівняння швидкодії реалізацій серверних рішень CGI та ASP.NET CORE

В межах подальшого огляду було проведено порівняння ряду конфігурацій систем ASP.NET CORE та системи на базі Spring [8], результати якого представлено на рис. 4.

Рис. 4. Порівняння швидкодії різних конфігурацій систем на базі ASP.NET CORE та системи на базі Spring

Виходячи з результатів тестів та порівнянь, були зроблені висновки, що для розробки об’ємного проекту найкраще підходить технологія ASP.NET CORE.

Протягом вирішення завдання по збереженню та взаємодії з даними, до порівняння було взято відомі СУБД, а саме: PostgreSQL, MS SQL і IBM db2.

Рис. 5. Порівняння швидкодії реалізацій SQL серверних запитів

На основі даних, представлених на рис. 5, було виявлено перевагу MS SQL у швидкості реалізаціїї серверних запитів порівняно з рештою розглянутих СУБД. Виходячи з обраних технологій, постало питання прийняття рішення по вибору способу взаємодії між сервером і базою даних. Оптимальним вибором для прийнятого стеку технологій є Entity Framework [5] на основі наступних критеріїв:

  1. Наявність підтримки способів генерації бази даних CodeFirst, DataBaseFirst.

  2. Наявність можливості написання запитів засобами мови LINQ та їх подальше виконання всередині бази даних SQL.

  3. Містить генерацію бази даних з відповідно заданої об’єктно-орієнтованої моделі.

  4. Наявність механізму кешування даних.

Під час розробки технічного рішення для клієнтської частини було розглянуто найпопулярніші фреймворки односторінкових веб-додатків, а саме Vue.js, Angular та React.

Розглянувши результати порівняння швидкодії, представлені на рис. 6, було визначено, що всі перелічені фреймворки мають схожу продуктивність під час виконання програми. Виділяється лише швидкість першого завантаження сторінки з використанням Angular. Це пояснюється тим, що даний фреймворк включає в собі ряд бібліотек, призначених для організації коду, взаємодії з зовнішніми джерелами даних, маршрутизаціїї всередині додатку, організації потоків даних. У випадку розробки веб-орієнтованого додатку зі складним інтерфейсом це є значною перевагою, оскільки решта фреймворків потребує власної імплементації даного функціоналу, що у подальшому значно впливає на швидкодію продукту та ускладнює розробку системи.

Виходячи з цього для розробки клієнтської частини було обрано фреймворк Angular.

Рис. 6. Порівняння швидкодії фреймворків Angular, React та Vue.js

Власна реалізація

Під час програмної обробки в межах механізму оцінювання тесту робота якого обмежена специфікою роботи Web API та специфікацією HTTP протоколу виникають наступні технічні проблеми:

1) Перерахунок ваги кожного питання.

2) Оновлення спільних даних конкурентними потоками.

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

$w=\frac{100{{Q}_{m}}}{\sum\limits_{0}^{Q}{{{Q}_{m}}}}\quad$, (1)

де w - це вага за питання, Qm – це кількість не вірних відповідей для одного запитання, Q – це кількість питань в тесті.

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

${{w}_{\min }}=\frac{100}{\sqrt{{{Q}^{3}}}}\quad$, (2)

де ${{w}_{\min }}$ - це мінімальна вага за питання, Q – це кількість питань в одному тесті.

Під час моделювання системи було виявлено наступну технічну проблему, обумовлену можливістю появи конкуруючих потоків, що в свою чергу будуть оновлювати спільні набори даних в один і той самий момент. З метою вирішення технічної проблеми було розроблено наступний механізм, що на основі планувальнику задач реалізує централізоване управління операціями зміни значень з точкою синхронізації, що створюється в межах додаткового джерела даних, на основі записів поточних та запланованих задач. В якості планувальника задач було використано Hangfire [8], як одне з найпопулярніших рішень в межах технології що використовується. Такий підхід забезпечує рішення технічної проблеми конкурентних потоків в межах всієї системи, що в свою чергу надає можливість зміни та збереження статистичних даних консистентно.

ВИСНОВКИ

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

Виходячи з функціональних вимог було обрано, як архітектурне рішення клієнт-серверний додаток. Для реалізації архітектурного рішення та функціональних вимог було проведено огляд технічних засобів, що застосовують для створення даного класу систем і сформовано технічне рішення, яке включає побудову односторінкового додатку на основі фреймворку Angular на боці клієнтської сторони системи та додатку на основі платформи .NET Core та СУБД MS SQL Server з боку серверної частини.

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

ЛІТЕРАТУРА

  1. https://ela.kpi.ua/bitstream/123456789/27860/1/Vovk\_magistr.pdf (дата звернення 12.05.2020).

  2. Леон Шкляр,Річ Розен., книга «Архітектура веб - додатків», рік видання: 2011 року

  3. https://echo.lviv.ua/dev/6455\(дата звернення 11.05.2020).

  4. https://www.ibm.com/developerworks/ru/library/ws\-soa\-term1/index.html\(дата звернення 11.05.2020).

  5. https://habr.com/en/post/262461/ (дата звернення 12.05.2020).

  6. https://www.techempower.com/benchmarks (дата звернення 12.05.2020).

  7. https://docs.microsoft.com/en\-us/ef/ef6/ (дата звернення 12.05.2020).

  8. https://www.hangfire.io/ (дата звернення 12.05.2020).
May 30, 2020