ИЗПОЛЗВАНЕ НА СИСТЕМИ ЗА ИЗПИТВАНЕ ВЪВ ВИСШЕ УЧЕБНО ЗАВЕДЕНИЕ

Людмила Ягодинская преди 2 години Прегледи:

3 100 След това оценката, дадена на задачата, се умножава по корекционния коефициент и в края на теста се изчислява съотношението на сбора от получените точки към максимално възможния. Резултатът се определя по 4-точкова система в съответствие със следната таблица. PKF PKF>0,5 Задоволителен 0,84 =>PKF>0,67 Добър PKF>0,84 Отличен Учителят може да променя данните в тази таблица. По-долу са дадени примери за тестови задачи в 7-ми и 1-ви клас. Задача 1* Какво представляват информационните технологии Задача 14 Посочете какви задачи предоставя CIS: 1 счетоводство 2 финансово планиране и финансов анализ 3 управление на договорни отношения 4 разплащания с доставчици и купувачи 5 управление на персонала 6 управление на обществени организации Под текста на задачата е дадена оценка (6) на тестовата задача, автоматично изчислена от системата KOST. Отговорът може да бъде въведен чрез формата за въвеждане, непосредствено под текста на задачата или в първата колона под формата на даден символ, например, "*" (звездичка), маркирайки реда с верния отговор: Режими на тестване Алгоритъмът за работа на системата KOST предвижда три режима на тестване. 1. Подготовка с извеждане на верните отговори. 2. Подготовка без показване на верни отговори. 3. Контрол. В първия режим след отговор на тестова задача се извежда съобщение за верността на отговора: Верен, Неправилен и Непълен отговор, а при неверен или непълен отговор се извежда диалогов прозорец с верния отговор. Този режим се препоръчва като тренировъчен режим за подготовка на ученици със слаба подготовка за изпитване.

5 KOST могат да бъдат инсталирани на всекикомпютър оборудван с MS Excel. 4. Студентите могат да копират COST заедно с тестовите задачи за домашна подготовка за тестване. 5. Системата не изисква интернет или локална мрежа. 6. Системата може да се използва за едновременно изпитване от произволен брой ученици в компютърен клас. Карпушински А.М., Павловская Т.А. РАЗРАБОТВАНЕ НА ТЕСТОВЕ ЗА ПРОГРАМИ С ПОТОК НА КРАВЕНО УПРАВЛЕНИЕ (Санкт Петербургски държавен университет ITMO, Санкт Петербург) Автоматизираното генериране на тестови данни (AGTD) за програми намалява времето за разработване на тестове и осигурява висок процент на покритие на грешките. Обектно-ориентираните езици за програмиране (OOPL) са по-трудни за тестване от процедурните езици, тъй като наследяването, полиморфизмът, обработката на изключения, събитията и други OOPL механизми въвеждат имплицитен поток от контрол, който значително усложнява алгоритмите. Неявният контролен поток може да се разглежда като обмен на съобщения, характеризиращ се с факта, че след като съобщението бъде обработено по време на изпълнение на програмата, контролът винаги се връща на повикващия. Тази статия обсъжда разработването на тестове за обектно-ориентирани програми, съдържащи един от най-често срещаните видове имплицитни контролни потоци, обработващи изключителни ситуации (изключения). Механизмът за обработка на изключения е последователност от хвърляне на изключение и обработката му в същия метод, в който е било хвърлено, или в един от извикващите (обграждащи) методи, разположени по-ниско в стека на извикванията [1]. Съобщението се генерира, ако при хвърляне на изключение контролът се прехвърли към един от извикващите методи. Предлага се тестването на програма, написана на OOLP, да се раздели на две нива: модулно, при което всеки клас се тества отделно (използвайки методиструктурно тестване, приложимо за "процедурни" езици) и интеграция, за която се използва адаптирането на съществуващите AGTD методи. На по-ниско ниво, за тестване на всеки клас, се изгражда контролна графа, избира се критерий за покриване на структурните елементи на програмата (операнди, дъги или пътища) и се разработва алгоритъм за намиране на тестови данни, които удовлетворяват избрания критерий. На ниво интеграция, всяка функция в клас е "черна кутия" и механизмът за съобщения е представен от диаграма на последователност, която е официална програмна спецификация. В този случай се извършва преходът от структурния модел на програмата към нейния поведенчески модел.

---