1.    Реалізація системи “Монітор тестування”

 

4.1. Управління користувачами

Розглянемо реалізацію адміністрування користувачів в системі «Монітор Тестувань».

Адміністрування здійснюється користувачем з відповідними правами – Адміністратором користувачів (User Administrator). При вході система перевіряє чи поточний користувач наділений правами адміністрування. Якщо наділений, то в пункті меню Users отримуємо список користувачів, які були створено нами (див. рис. 4.1).

 

Рисунок 4.1

Адміністратор користувачів може виконувати наступні дії:

·        створення одного користувача;

·        створення багатьох користувачів одночасно;

·        зміна персональних даних тих користувачів, що були ним створенні;

·        видалення користувача.

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

Розглянемо детальніше кожну з дій яку може виконувати Адміністратор користувачів.

 

4.1.1. Створення користувачів

В системі «Монітор тестування» передбачені два способи створення користувачів: поодиночне створення та створення багатьох користувачів одночасно. Кожен з варіантів має свої особливості. Так, наприклад, створення одного користувача дає можливість ввести повну інформацію про нього (див. рис. 4.2). Проте цей метод вимагає великих часових затрат, особливо при створенні багатьох користувачів. Важливим пунктом у формі створення користувача є поля Permission. Вони фактично визначають політику безпеки всієї системи, оскільки містять список дій які можуть виконувати користувачі. Наприклад, для створення Адміністратора користувачів слід поставити галочку в клітинці Managing Users, для Адміністратора Тестів – Managing Tests і т.д. Звичайний користувач за замовчуванням наділений тільки правом тестуватися. Слід зазначити, що один і той же користувач може одночасно бути і Адміністратором користувачів, і Менеджером тестів, і при тому звичайним користувачем (щоб можна було перевіряти створені тести). Для цього варто лише поставити галочки навпроти відповідних клітинок.

 

Рисунок 4.2

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

 

Рисунок 4.3

В цій формі потрібно заповнити шаблон за яким будуть створюватись логіни для майбутній користувачів. Наприклад, якщо ми створюємо групу студентів 01і1, логіни яких мають вигляд 01і1**, де ** - порядковий номер студента, то достатньо ввести 01і1 в першому полі рядка Login (друге поле – індекс, що змінюється, третє – частина тексту що дописується до логіна користувача після індексу), а решта цифри допише за нас система. Аналогічно працює рядок з паролем. Рядок Index Range дозволяє задавати межі в яких коливається індекс.

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

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

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

У першому випадку після натиснення клавіші Save на формі редагування користувача запускається відповідна подія, описана у файлі конфігурації struts-config.xml, а конкретно UserEditSubmitAction.do. Дана подія створює новий запис в базі даних з введеними атрибутами. При коректному завершенні, UserEditSubmitAction.do в свою чергу викликає сторінку зі списком користувачами. В разі помилки перенаправляє назад на головну сторінку.

Для кожного користувача встановлюються особливі атрибути, до яких належать:

-         login (логін користувача);

-         password (пароль користувача);

-         status (статус; може приймати два значення: активний чи неактивний);

-         permission (повноваження та привілеї);

-         first name (ім’я).

-         last name (прізвище);

-         initials (ініціали);

-         address (адреса);

-         zipcode;

-         city (місто);

-         home phone;

-         work phone;

-         cel phone;

-         e-mail;

-         fax (факс);

-         sex (стать).

 

У випадку створення багатьох користувачів викликається подія CreateMultipleUsersSubmitAction.do, що генерує вказану кількість об’єктів з вказаним логіном, паролем та групою. Користувач може залогуватись та працювати в системі «Монітор тестування» тільки тоді, коли його атрибут status приймає значення “активний”. Створені користувачі можна прив’язувати до тестів, що дасть їм змогу протестуватись. Слід зауважити, що не можна створювати користувачів з однаковим значенням  атрибуту “login”.

 

4.1.2. Редагування і видалення користувачів

Редагування користувачів здійснюється аналогічно до їх створення. Щоб змінити атрибути користувача необхідно натиснути на кнопці “edit”. Після цього виконається подія UsersEditAction.do яка зчитає з бази атрибути користувача і помістить їх на форму. Тепер їх можна змінювати. Щоб зберегти необхідно натиснути на кнопку “Save”. Викликається подія UserEditSubmitAction.do і зміни вносяться в базу даних.

Для забезпечення стабільної роботи системи користувачі повністю не видаляються з бази даних. Вони просто стають неактивними. Видалити користувача можна натиснувши кнопку “remove”. Далі викличеться подія UsersEditAction.do з параметром  action = remove.

 

 

4.1.3. Ієрархія повноважень

Для забезпечення безпеки роботи з системою було розроблено сукупність класів, які представляють засіб забезпечення безпеки користувача – пул користувачів.

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

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

1.      Показується вікно для вводу логіна користувача та паролю.

2.      При отриманні логіну та паролю система проводить пошук такого користувача (на основі логіну та паролю) в базі користувачів системи.

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

4.      Для збереження інформації про користувача системи використовується принцип збереження активного з’єднання браузера. Програмно це реалізується на основі збереження інформації про користувача і об’єкті HttpServletRequest, пулу активних користувачів системи у об’єкті PageContex.

 

Розглянемо детальніше ієрархію користувачів та їхніх повноважень. На основі аналізу вимог для забезпечення потрібної функціональності було вироблено 7 акторів в роботі системи:

Þ    RootAdmin – користувач системи з найбільшими повноваженнями. В його можливості входить створення превілегійованих користувачів системи: TestAdmin, UserAdmin. Додається можливість зворотного зв’язку з іншими користувачами системи. Залежність з іншими користувачами системи відсутня. Є незалежним актором системи. Існування користувача системи ніким не регламентується і повинно передбачатись ще до початку роботи системи. Передбачається безпосереднє прописування користувача в базі.

Þ    TestAdmin - користувач системи, який є відповідальним за частину проведення тестувань. Він може створити новий тест в системі (додати в систему), редагувати зміст тесту на рівні окремих питань; видалити тест з системи; приєднати особу відповідальну за тестування – TestManager. Також додається можливість зворотного зв’язку з іншими користувачами системи.

Þ    UserAdmin – користувач системи відповідальний за додавання нових, адміністрування існуючих чи видалення з системи існуючих користувачів. Надається можливість по створенню користувачів які створюють тести – TestAdmin, проводять тестування – TestManager, адмініструють користувачів – UserAdmin, та інших. Також додається можливість зворотного зв’язку з іншими користувачами системи. Розглядається два випадки існування: автономне та залежне. У випадку автономного існування користувач повинен бути створений ще до початку роботи системи – безпосереднє прописування користувача в базі. При залежному існуванні користувача створює або RootAdmin  або інший UserAdmin.

Þ    TestManager – особа яка займається проведенням тестувань користувачів системи. В її розпорядженні є перелік доступних їй тестів та користувачів. Має безпосередній доступ до результатів тестування. Додатковою можливістю є попереднє налагодження вимог до тесту – скільки буде запитань у тесті, якої складності, на скільки часу, для яких користувачів зробити цей тест доступним. Також додається можливість зворотного зв’язку з іншими користувачами системи. Має зв’язок з переліком всіх доступних йому тестів та переліком користувачів. Він безпосередньо залежний від UserAdmin-а, який його створив.

Þ    PowerUser – користувач системи, який має особливе право, яке полягає в можливості перегляду статистики свого останнього тестування по всіх доступних йому тестах. Також додається можливість зворотного зв’язку з іншими користувачами системи. Він безпосередньо залежний від UserAdmin-а, який його створив.

Þ    User – користувач системи, який проходить тестування, має доступ до навчально-ознайомчого матеріалу. Також додається можливість зворотного зв’язку з іншими користувачами системи. Він безпосередньо залежний від UserAdmin-а, який його створив.

Þ    Other – користувач, який не зареєстрований в системі. На даний момент для такого типу користувачів не передбачено доступу до системи взагалі. Зв’язок відсутній.

 

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

По вимогах роботи системи було вироблено кілька центральних побажань до присвоєння кількох системних повноважень на одній особі:

1.      RootAdmin. Передбачається виділення виконання цих обов’язків на окремій особі для підвищення рівня безпеки системи. Є центральною і невід’ємною частиною системи.

2.      UserAdmin. Також невід’ємна частина системи, яка створює як окремих користувачів для тестування так і різного роду адміністраторів.

3.      TestAdmin + TestManager. Таке поєднання повноважень на одній особі дозволяє виділити особу яка буде мати можливість контролю структури системних тестів. В таки спосіб досягається гнучке поєднання центральних обов’язків по веденні роботи системи тестування, одночасно не вимагаючи постійного втручання в роботу системи. Передбачається надання таких повноважень для людей які вже досить добре знайомі з проведенням тестувань.

4.      PowerUser + User. Дуже бажаною вимогою до організації користувачів є уникання поєднань таких користувачів з користувачами, повноваження яких описані вище. Проте таке поєднання дає можливість надати користувачам додаткові права по перегляду своєї статистики що є необхідним моментом при використанні тестів з компільованими програмами.

 

В результаті роботи на організацією поєднання повноважень користувачів системи на одній особі було розроблено поняття – пулу активних користувачів системи (див рис. 4.4).

Рисунок 4.4

Пул організовувався на можливості Web-браузерів підтримки сесії користувача з сервером.

 

4.1.4. Процес легування

Розглянемо реалізацію зв’язку структури повноважень з власне роботою системи «Монітор тестування». Основні дії, пов’язані з ініціалізацією користувача (перевірка наявності користувача в базі, завантаження привілеїв, формування користувацького меню тощо) виконуються під час процесу логування. Дані про користувача (логін, пароль, ім’я, прізвище тощо) зберігаються у відповідній таблиці User бази даних системи. Структура таблиці зображена на рис. 4.5.

 

         

                                                               Рисунок 4.5

Отримавши дані з форми, подія LogonAction.do перевіряє наявність даного користувача в базі даних. Якщо такого користувача немає або введено невірний пароль система повертається в початковий стан – сторінку введення даних. Якщо ж процес перевірки повернув задовільний результат, то дані користувача зчитуються і зберігаються як в пулі системи, так і в сесії конкретного користувача. Далі відбувається зчитування відповідних повноважень. Оскільки в системі передбачене поєднання привілеїв різних рівнів, то недоцільним було б збереження в базі всіх можливих варіантів повноважень. Тому запропоновано було бінарну систему визначення привілеїв. Ця система полягає в тому, що користувачу надається числове відображення сукупності повноважень, що є результатом переведення двійкового семизначного числа в десяткову систему числення. Кожен біт цього числа відповідає за певне повноваження. На рис. 4.6 зображено детальну структуру цього числа.

Рисунок 4.6

Дане число формується під час встановлення привілеїв користувачеві як в процесі створення, так і в процесі редагування. За замовчуванням створюється користувач з найменшими привілеями, тобто звичайний User. Відповідно 0-ий біт «числа повноважень» встановлюється в 1, а всі інші в 0. При створенні PowerUser 1-ий біт встановлюється в 1, а всі інші в 0. І так далі. Якщо користувач є одночасно і менеджером тестів і тест-адміністратором, то його повноваження будуть мати вигляд 010100. Оскільки біти відраховуються справа наліво, то це число формується в зворотному до рис. 6.6 порядку. Далі відбувається перетворення в десяткову систему числення і вже в такому вигляді зберігається у відповідному полі permissionId таблиці User.

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

 

 

4.2.  Групи користувачів

 

Адміністрування групами здійснюється користувачем з відповідними правами (User Administrator). Цей користувач отримує список груп, які були ним створені (див. рис. 4.7).

 

Рисунок 4.7

User Administrator може виконувати наступні дії:

·        створення групи користувачів;

·        зміна даних груп, що були ним створені;

·        видалення груп;

·        додавання до групи користувачів;

·        виконувати стандартні дії над користувачами групи.

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

Групи призначені для полегшення роботи TestManager-а. Тепер можна оперувати не окремими користувачами, а їх цілими групами. Наприклад, при підключенні окремої групи до деталізованого тесту до нього автоматично підключаються всі її користувачі.

Є дві групи, які заборонено змінювати (All і Other). В них міститься інформація необхідна для правильної роботи системи. В групі All містяться всі створені користувачі, а в групі Other тільки ті, що не містяться в інших групах.

 

 

4.2.1. Створення груп користувачів

Групи користувачів за допомогою форми створення груп (див. рис. 4.8) записуються в базу даних. Створення груп та запис в базу даних відбувається після натиснення кнопки “Save”. Далі запускається подія згідно опису в файлі конфігурації struts-config.xml, а конкретно GroupEditSubmitAction.do. Дана подія створює новий запис в базі даних з введеними атрибутами. При коректному завершенні GroupEditSubmitAction.do в свою чергу викликає  сторінку з групами. В разі помилки перенаправляє назад на головну сторінку.

 

Рисунок 4.8

Для кожної групи встановлюються особливі атрибути, до яких належать:

-         name (назва групи);

-         description (короткий опис групи);

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

Рисунок 4.9

 

4.2.2. Редагування і видалення груп

Редагування груп здійснюється аналогічно до їх створення. Щоб змінити атрибути групи необхідно натиснути на кнопці “edit”. Після цього виконається подія GroupEditAction.do яка зчитає з бази атрибути групи і помістить їх на форму. Тепер їх можна змінювати. Щоб зберегти необхідно натиснути на кнопку “Save”. Викликається подія GroupEditSubmitAction.do і зміни вносяться в базу даних. Код події GroupEditSubmitAction.do показаний вище.

Для забезпечення стабільної роботи системи користувачі повністю не видаляються з бази даних. Вони просто стають неактивними. Видалити користувача можна натиснувши кнопку “remove”. Далі викличеться подія GroupEditAction.do з параметром  action = remove.

 

 

4.2.3. Додавання до групи  користувачів

Після створення групи до неї необхідно додати користувачів. Щоб додати до групи користувачів необхідно натиснути на кнопці “assign”. Після цього виконається подія GroupEditAction.do яка зчитує з бази користувачів даної групи і поміщає їх на форму. Форма містить два списки користувачів. В одному з них знаходяться користувачі даної групи, а в іншому - всі користувачі, які не містяться у вибраній групі. Тепер можна додавати до групи користувачів я також викидати їх з групи. Щоб зберегти необхідно натиснути на кнопку “Save”. Викликається подія GroupAssignUserSubmitAction.do і підписує (відписує) користувачів до цієї групи.

Рисунок 4.10

4.3. Питання і тести

 

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

Тести, а також запитання до тестів розробляються користувачем з відповідними правами (Test Administrator) та за допомогою форми завантаження тестів записуються в базу даних. Оскільки будь-який тест складається з питань, то розглянемо спочатку процес створення питань, а потім створення самих тестів.

В системі «Монітор тестування» передбачено 6 типів питань: звичайні питання (після тексту питання в кінці знаходиться поле введення відповіді), мультивибірка (користувачеві надається право вибрати декілька правильних варіантів з наданих йому), вибірка (із запропонованих варіантів відповіді лише один правильний), питання з варіантами (суттєво відрізняється від попередніх, оскільки поля введення відповідей розкидані по всьому тексту питання і до кожної відповіді є декілька варіантів правильної; див. рис. 4.11), інформаційне питання (не містить полів відповідей – лише запитання, яке можна використовувати для ознайомлення користувача з деякою інформацією), питання з компіляцією програми (питання містить пояснення щодо програми яку треба написати; відповідь – текст програми, який пізніше буде компілюватися).

 

Рисунок 4.11

 

Створення питань відбувається за допомогою форми, зображеної на рис. 4.11. Адміністратор вводить текст питання, вибирає тип питання, задає складність і власне відповіді (якщо вони потрібні). Є можливість попереднього перегляду питання (клавіша Preview), а також редагування тексту питання в HTML-редакторі, за допомогою якого можна робити таблиці, вставляти рисунки, міняти колір тексту, відступи тощо. Заповнивши всі дані та натиснувши клавішу Save переходимо на сторінку з всіма питання даного тесту.

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

 

<test author="Muzychuk" title="C++" chapter="STL, Algorithms" date="1/10/2005">   <question type="write"> <![CDATA[ Яке середнє арифметичне елементів вектора res після виконання інструкцій функції  F()?   int inc10(int x){ return x+=10;} void F(){       int u[]={10,20,30,40,50};       vector<int> a(u,u+5),res;       transform(a.begin(),a.end(), back_inserter(res), inc10); } ]]> <answer ignoreSpace="true" ignoreCase="false">       <value price="5"><variant><![CDATA[40]]></variant></value> </answer> </question>   <question type="write"> <![CDATA[ Яке середнє арифметичне елементів вектора res після виконання інструкцій функції  F()?   int inc10(int x){ return x+=10;} void F(){       int u[]={10,20,30,40,50};       vector<int> a(u,u+5),res(5);       transform(a.begin(),a.end(), back_inserter(res), inc10); } ]]> <answer ignoreSpace="true" ignoreCase="false">       <value price="5"><variant><![CDATA[40]]></variant></value> </answer> </question>   </test>

 

Як видно, в ньому міститься вся необхідна інформація про тест:

·        назва тесту;

·        тип;

·        автор;

·        питання для тесту;

·        відповіді на питання;

·        кількість балів для кожного питання.

 

4.3.1. Імпортування

Щоб імпортувати тест в самій системі «Монітор Тестувань» просто вказується необхідний файл з питаннями і натискається кнопка “Load”. Далі запускається подія ImportAction.do. Тут відбувається саме зчитування з файлу і запис тесту в базу даних.

 

 

4.3.2. Експортування

            Експортування тесту передбачає створення XML файлу і запис в нього всієї необхідної інформації про тест. За допомогою реалізованих класів бізнес рівня інформація (питання, відповіді та ін.) виймаються з бази даних і поміщаються у файл. Даний файл створюється в каталозі export системи. Далі загружається HTML сторінка, на якій поміщається посилання на цей файл.

 

 

4.3.3. Створення та редагування тестів

Для кожного тесту встановлюються особливі атрибути, до яких належать:

-         test name (назва тесту);

-         description (короткий опис тесту);

-         status (статус; може приймати два значення: активний чи неактивний);

-         questions (запитання);

-         testers (список користувачів, що мають доступ до створених тестів).

Один тест може містити довільну кількість запитань. Створення, редагування та завантаження питань розглядалися вище. До тесту можна «прив’язати» довільну кількість користувачів для надання їм доступу до запитань. Слід зауважити, що не можна створений тест використовувати безпосередньо для тестування. Для цього існують так звані деталізовані тести.

Деталізовані тести – це розширення тестів для подальшого їх використання в процесі тестування. Ці розширення створюються користувачами з відповідними правами (як правило, Test Manager) на основі тестів, до яких їм надано доступ адміністраторами тестів (див. вище). До атрибутів деталізованих тестів належать:

-         detailed test name (назва деталізованого тесту);

-         description (короткий опис);

-         question count (кількість запитань; може бути меншою за кількість запитань відповідного тесту, але не може бути більшою);

-         test time (час, відведений на весь тест);

-         score “Normal” (відсоток правильних відповідей на оцінку «задовільно»);

-         score “Good” (відсоток правильних відповідей на оцінку «добре»);

-         score “Excellent” (відсоток правильних відповідей на оцінку «відмінно»);

-         users (список користувачів, що мають право тестуватися за даним тестом).

Після заповнення атрибутів деталізованого тесту (крім останнього), користувач перенаправляється на сторінку всіх деталізованих тестів, де має можливість приєднати користувачів як до щойно створеного тесту, так і до вже існуючих тестів, що доступні даному тест-менеджеру.

Приєднання користувачів до конкретного тесту відбувається після натиснення “assign”. На рис. 4.12 зображено форму, що відповідає за даний процес.

 

Рисунок 4.12

 

За допомогою JavaScript можна переводити користувачів з лівої панелі в праву, тобто з списку активних користувачів в список користувачів, яким буде доступний конкретний тест. Після внесення змін в списки потрібно натиснути “Save” для того, щоб зберегти їх. Зауважимо, що за таким самим принципом відбувається приєднання менеджерів тестів до конкретних тестів, створених адміністраторами тестів.

 

 

4.4. Процес тестування

В наступних рядках покроково відтворено власне процес самого тестування:

1) користувач реєструється в системі;

2) вибравши пункт меню “Testing”, отримує список деталізованих тестів, до яких йому надано доступ (див. вище);

3) процес тестування розпочинається з натиснення “start” напроти відповідного тесту (зауважимо, що крім початку тестування користувач може відправити повідомлення тому менеджеру тестів, що створив відповідний деталізований тест;

4) в процесі тестування користувач послідовно отримує запитання і відповідає на них;

5) після відповіді на останнє запитання користувачу подається сторінка з результатами його тестування, на якій виведено кількість запитань, кількість правильних відповідей, відсоток правильних відповідей та відповідна оцінка («незадовільно», «задовільно», «добре» чи «відмінно»).

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

 

4.4.1. Контроль часу у звичайних тестах

Для запобігання зловживання користувачами часу для тестування в системі «Монітор Тестувань» введено контроль за часом в процесі тестування. Він базується на тому, що при створенні деталізованого тесту менеджер тестів вводить час, відведений для проведення часу, у відповідному полі форми редагування тестів (див. рис. 4.13).

 

Рисунок 4.13

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

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

Отже, при натисненні кнопки “Save” на формі редагування деталізованих тестів в поле QuestionTime таблиці відповідей в базі даних записується значення, що є цілою частиною від ділення загального часу на кількість запитань.

Далі, при виборі “start” на конкретному тесті, запускається подія згідно опису в файлі конфігурації struts-config.xml, а конкретно startTestingAction.do. Дана подія створює процес тестування, що зберігається в поточній сесії користувача.

При коректному завершенні startTestingAction.do в свою чергу викликає іншу подію testingAction.do з параметром action=start. В разі помилки перенаправляє назад на сторінку зі списком деталізованих тестів. У файлі struts-config.xml це реалізовано наступним чином:

 

<action path="/startTestingAction"        type="edu.lnu.tm.webtier.struts.actions.StartTestingAction">    <forward name="success" path="/testingAction.do?action=start" />    <forward name="testinglist" path="/testingListAction.do" /> </action>

 

Подія testingAction.do, отримавши з бази даних час на запитання генерує конкретну сторінку з тестом і перенаправляє на саму себе, проте вже з атрибутом, що містить поточний номер питання. Цей номер не є ідентифікатором питання в базі даних, а всього лише числом вже заданих питань. У випадку коли питання є останнім викликається ця ж подія, але вже з параметром “finish=true”.

Далі відповідні часові параметри обробляються відповідною jsp-сторінкою testing.jsp. Ця сторінка за допомогою сценаріїв викликає рекурсивну функцію з інтервалом 1 секунду, яка власне і відлічує час під час тестування.

Слід зауважити, що час можна було б відраховувати у сесії користувача, проте такий спосіб має один важливий недолік – якщо в користувача канал з’єднання має низьку пропускну здатність, то час, за який вантажиться сторінка враховувався б в час запитання. При дуже малих швидкостях користувач просто не встигав би відповідати на запитання. Тому час починає відраховуватися на клієнтській стороні тільки після того, як сторінка завантажиться. Передбачена також можливість зупинки часу в той момент, коли користувач натиснув «Далі», оскільки у тому випадку, коли користувач натиснув в останні декілька секунд, а сторінка з наступним питанням ще не встигла завантажитись, сценарій почне завантажувати свою сторінку. В кращому випадку пропаде одне питання, в гіршому – помилка.

 

4.4.2. Тести з поверненням

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

-         за допомогою кнопок з номерами запитань;

-         за допомогою кнопок послідовного переміщення (<<, <, > та >>) на перше запитання, попереднє, наступне та останнє відповідно:

-         для завершення процесу слід натиснути «Finish».

 

Рисунок 4.14

 

Отже, користувач може вільно пересуватися по всіх питаннях тесту, повертатися до того питання, яке пропустив чи на яке уже відповів але прагне змінити свій варіант, тощо. Процес тестування завершиться тільки тоді, коли вийде загальний час або користувач натисне «Finish».

 

 

4.4.3. Інформаційні тести (тести з послідовними питаннями)

            Третім типом тестів є так звані інформаційні тести (тести з послідовними питаннями). Цей тип мало чим відрізняється від тестів з поверненням окрім того, що питання вибираються не випадковим чином, а в строгій послідовності (в порядку їх створення). Необхідність створення такого типу тестів виникла з появою інформаційного типу питань, оскільки інформацію слід подавати у визначеній послідовності, а не випадковим чином. Відсутнє також поле введення відповіді, оскільки немає сенсу відповідати на інформаційне питання (див. рис. 4.15).

 

Рисунок 4.15

 

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

 

 

 

4.5.  Статистика результатів

 

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

 

Рисунок 4.16

Як видно, вказується найнеобхідніша інформація:

·        користувач;

·        назва тесту;

·        результат тестування (в процентах).

 

4.5.1. Деталізована статистика

Щоб отримати повну інформацію необхідно нажати кнопку detail. Тоді появляється додаткова інформація:

·        час початку тестування;

·        час закінчення тестування;

·        кількість питань в тесті;

·        самі питання;

·        їхня складність;

·        відповідь користувача на питання.

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

Рисунок 4.17

 

4.5.2. Пошук статистики

Слід зауважити, що для полегшення перевірки результатів тестування на сторінку завантажується  перелік статистики тільки за поточний день. Це значно зручніше для TestMenedger-а і пришвидшує роботу системи. Щоб переглянути статистику тестування необхідно натиснути кнопку “filter”. Після цього загружається форма, в якій можна вказати критерії пошуку.

Рисунок 4.18

 

Можна задати наступні критерії:

• Star Date, Finish Date (задається період, за який шукати статистику)
• Sort By (критерій, за яким сортувати результат пошуку)
• User (задається конкретний користувач, статистику якого необхідно знайти)

 

Якщо потрібно знайти статистику не для конкретного користувача, а для всіх, тоді в толі “User” вибираємо “All”. Дату пошуку можна задавати вручну, вписуючи її у відповідне поле. Також можна використати спеціальну компоненту під назвою “Calendar”. Вона подає дату у зручнішому вигляді. Для отримання результату пошуку необхідно нажати кнопку “Submit”. В результаті виконається подія FilterStatisticSubmitAction.do в яка зчитає необхідні дані з бази даних і виведе їх список, як це показано на рисунку 4.17. 

4.6.  Зворотній зв’язок

 

Зворотній зв'язок призначений для відправлення і отримання повідомлень користувачами з метою покращення роботи системи (виправлення помилок в тестах, поради, пропозиції, прохання та ін.). Користувачі можуть відправляти повідомлення за таким зв’язком:

·        User Administrator à будь-якому користувачу, якого він створив;

·        Test Admin à Test Manager, на рахунок тесту, від якого був створений деталізований тест;

·        Користувач à Test Admin, на рахунок деталізованого тесту, по якому користувач має право тестуватись;

·        Користувач à користувач (будь-який користувач може відповісти на повідомлення).

Користувач отримує список повідомлень, які він може: а) прочитати; б) відповісти на повідомлення; в) видалити.

 

Рисунок 4.19

Нажавши на кнопку “read” можна прочитати вибране повідомлення. Викликається подія FeedbackAction.do, в якій атрибути повідомлення зчитуються з бази даних і виводяться у поля форми.

Рисунок 4.20

Для кожного повідомлення вказується тема і логін користувача, що відправив це повідомлення.  В події FeedbackAction.do реалізовано весь механізм зворотного зв’язку.