Как написать программу проверки

• Начало
• » Python для новичков
• » Как написать программу проверки-знаний?

#1 Окт. 21, 2017 21:27:09

Как написать программу проверки-знаний?

Привет товарищи! стоит задача проверить знания своих студентов, так как я немного знаком с python думал использовать его. Хотелось бы чтобы программа спокойно запускалась под винду без дополнительных установок библиотек(в школе везде винда).

#2 Окт. 21, 2017 23:01:59

Как написать программу проверки-знаний?

эээ а с такой постановкой “задачи” от нас вы чего ожидаете? Если ищите ответа, то да, такое возможно.

_________________________________________________________________________________
полезный блог о python john16blog.blogspot.com

#3 Окт. 21, 2017 23:58:57

Как написать программу проверки-знаний?

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

#4 Окт. 22, 2017 00:04:24

Как написать программу проверки-знаний?

С дураками и сектантами не спорю, истину не ищу.
Ели кому-то правда не нравится, то заранее извиняюсь.

#5 Окт. 22, 2017 00:40:17

Как написать программу проверки-знаний?

а можно сделать тесты на Tkinter? ну и хотелось бы чтобы ученики не смогли добраться до ответов(шифровка)

#6 Окт. 22, 2017 06:33:59

Как написать программу проверки-знаний?

Goyt можно, но внешний вид там прямо скажем не есть гут и документация так себе.
если схема — вопрос + варианты ответа,
то я бы сделал на PyQt + база данных либо с шифрованием, либо на удаленном сервере
или на JS веб-интерфейс. в 90 такую работу делал на Роботроне в dbase2, было две программы — редактор вопросов/ответов и собственно проверка знаний.
может вам сюда?

Отредактировано vic57 (Окт. 22, 2017 07:07:22)

#7 Окт. 22, 2017 07:16:47

Как написать программу проверки-знаний?

с учениками я работаю немного(техподдержка комп класса в школе) и остановился на варианте загрузочный LiveCD/LiveUSB шифрованный — если сопрут то прочитать не смогут все равно

#8 Окт. 22, 2017 11:39:12

Как написать программу проверки-знаний?

vic57
Goyt можно, но внешний вид там прямо скажем не есть гут и документация так себе. если схема — вопрос + варианты ответа, то я бы сделал на PyQt + база данных либо с шифрованием, либо на удаленном сервере или на JS веб-интерфейс. в 90 такую работу делал на Роботроне в dbase2, было две программы — редактор вопросов/ответов и собственно проверка знаний. может вам сюда?

Проверка GPTchat на присутствие ИИ. Сможет ли он написать программу которая работает?

Остались исходники?) Чтобы допилить под себя. Вариант с pyqt хороший, но придется курить маны

#9 Окт. 22, 2017 11:40:50

Как написать программу проверки-знаний?

Я изучил программу, я работаю из под Линукс и не понимаю что мешает другому человеку скачать редактор и открыть тесты(я имею ввиду, программа не имеет защиты типа логин пароль)

#10 Окт. 22, 2017 11:59:44

Как написать программу проверки-знаний?

а может клиент/серверный подход здесь будет лучше? Наверняка в комп. классе есть ПК преподавателя или тп.

_________________________________________________________________________________
полезный блог о python john16blog.blogspot.com

Источник: python.su

Тестирование в Python [unittest]. Часть 2. TestCase

Продолжаем изучать unittest – framework для тестирования в Python. В этой статье сосредоточимся на общем обзоре основных структурных элементов unittest (test case, test suite, test runner), рассмотрим способы запуска тестов и подробно остановимся на классе TestCase.

1. Основные структурные элементы unittest.
2. Запуск тестов из командной строки и с использованием графического приложения.
3. Работа с TestCase.

Основные структурные элементы unittest

unittest – это framework для тестирования в Python, который позволяет разрабатывать автономные тесты, собирать тесты в коллекции, обеспечивает независимость тестов от framework’а отчетов и т.д. Основными структурными элемента каркаса unittest являются:

Test fixture

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

Test case

Test case – это элементарная единица тестирования, в рамках которой проверяется работа компонента тестируемой программы (метод, класс, поведение и т.п.). Для реализации этой сущности используется класс TestCase.

Test suite

Test suite – это коллекция тестов, которая может в себя включать как отдельные test case’ы так и целые коллекции (т.е. можно создавать коллекции коллекций). Коллекции используются с целью объединения тестов для совместного запуска.

Test runner

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

Вся работа по написанию тестов заключается в том, что мы разрабатываем отдельные тесты в рамках test case’ов, собираем их в модули и запускаем, если нужно объединить несколько test case’ов, для их совместного запуска, они помещаются в test suite’ы, которые помимо test case’ов могут содержать другие test suite’ы.

Запуск тестов из командной строки и с использованием графического приложения

Запуск тестов можно сделать как из командной строки, так и с помощью графического интерфейса пользователя (GUI), рассмотрим каждый из этих способов более подробно. В качестве примера приложения, будет выступать utest_calc.py из предыдущей статьи.

Интерфейс командной строки (CLI)

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

Запуск всех тестов в модуле utest_calc.py.

> python -m unittest test_calc.py

Запуск тестов из класса CalcTest.

> python -m unittest utest_calc.CalcTest

Запуск теста test_sub().

> python -m unittest utest_calc.CalcTest.test_sub

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

> python -m unittest -v utest_calc.py

Если осуществить запуск без указания модуля с тестами, будет запущен Test Discovery.

> python -m unittest

Более подробно о Test Discovery будет рассказано в одной из следующих частей. С правку по ключам запуска можно получить из документации.

Графический интерфейс пользователя (GUI)

Для запуска и анализа результатов работы тестов можно использовать GUI. Списко инструментов доступен здесь , но он далеко не полный. Для пример рассмотрим работу с Cricket . Для установки Cricket можно воспользоваться менеджером pip:

> pip install cricket

После этого на ваш компьютер будет установлен cricket-unittest.

Для запуска тестов в данном приложении, перейдите в каталог с вашим тестирующим кодом и в командной строке запустите cricket-unittest, для этого просто наберите это название и нажмите Enter.

> cricket-unittest

Приложение, при запуске, автоматически загрузит тесты.

Для запуска тестов нажмите “Run all”. Как видно, все тесты завершились удачно – они окрасились в зеленый цвет.

Работа с TestCase

Как уже было сказано – основным строительным элементом при написании тестов с использованием unittest является TestCase. Он представляет собой класс, который должен являться базовым для всех остальных классов, методы которых будут тестировать те или иные автономные единицы исходной программы.

Приведем еще раз класс CalcTest из предыдущего урока:

import unittest import calc class CalcTests(unittest.TestCase): def test_add(self): self.assertEqual(calc.add(1, 2), 3) def test_sub(self): self.assertEqual(calc.sub(4, 2), 2) def test_mul(self): self.assertEqual(calc.mul(2, 5), 10) def test_div(self): self.assertEqual(calc.div(8, 4), 2) if __name__ == ‘__main__’: unittest.main()

Для того, чтобы была возможность использовать компоненты unittest (в том числе и TestCase), в самом начале программы нужно импортировать модуль unittest стандартным образом.

При выборе имени класса наследника от TestCase можете руководствоваться следующим правилом: [ИмяТестируемойСущности]Tests. [ИмяТестируемойСущности] – это некоторая логическая единица, тесты для которой нужно написать. В нашем случае – это калькулятор, поэтому мы выбрали имя CalcTests. Если бы у нашего калькулятора был большой набор поддерживаемых функций, то тестирование простых функций (сложение, вычитание, умножение и деление) можно было бы вынести в отдельный класс и назвать его например так: CalcSimpleActionsTests. При написании программ на Python старайтесь придерживаться PEP 8 — Style Guide for Python Code – это рекомендации по стилевому оформлению кода.

Для того, чтобы метод класса выполнялся как тест, необходимо, чтобы он начинался со слова test. Несмотря на то, что методы framework’а unittest написаны не в соответствии с PEP 8 (ввиду того, что идейно он наследник xUnit), мы все же рекомендуем следовать правилам стиля для Python везде, где это возможно. Поэтому имена тестов будем начинать с префикса test_. Далее, под словом тест будем понимать метод класса-наследника от TestCase, который начинается с префикса test_.

Все методы класса TestCase можно разделить на три группы:

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

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

Методы, используемые при запуске тестов.

К этим методам относятся:

Метод вызывается перед запуском теста. Как правило, используется для подготовки окружения для теста.

tearDown()

Метод вызывается после завершения работы теста. Используется для “приборки” за тестом.

Заметим, что методы setUp() и tearDown() вызываются для всех тестов в рамках класса, в котором они переопределены. По умолчанию, эти методы ничего не делают. Если их добавить в utest_calc.py, то перед [после] тестов test_add(), test_sub(), test_mul(), test_div() будут выполнены setUp() [tearDown()].

setUpClass()

tearDownClass()

skipTest(reason)

Как написать программу проверки

Автоматизация тестирования REST API на сегодняшний день является актуальной темой в интеграционном тестировании. В этой статье мы поговорим о программе Postman, применяемой для тестирования REST API, рассмотрим несколько интересных методов написания автотестов и на примере реального проекта API «Яндекс.Словарь» разберем несколько тестов.

Нам понадобится

Для того, чтобы начать тестировать «Яндекс.Словарь», нам понадобится:

• Знание основ программирования. Достаточно владеть такими понятиями, как:

Для чего-то более сложного и интересного, уже необходимо знать про

• Понимание REST API. Об этом хорошо рассказал в своей статье Андрей Шальнев.
• Postman – программа, в которой будут создаваться автотесты.
• Документация. Документация – это своего рода инструкция, из которой узнаем, какие функции необходимо протестировать.
• Ключ для «Яндекс.Словарь». Специальный ключ для использования «Яндекс.Словарь» можно получить быстро и бесплатно в сервисе.

Планирование в тестировании

Прежде чем начать писать код, мы должны ответить на следующие вопросы: «какие методы будем тестировать», «как будем тестировать» и «какие трудности могут возникнуть».

Какие методы будем тестировать? На этот вопрос нам поможет ответить документация. В документации «Яндекс.Словарь» описаны два метода (getLangs и lookup) и несколько параметров к каждому из методов.

Как будем тестировать? Для того, чтобы выбрать технику тестирования, необходимо проанализировать параметры метода API. Значения параметров бывают разными, это может быть число, слово, элемент из списка значений и другие типы данных.

К каждому параметру нужен свой подход: например, если параметр – это число с допустимым максимальным значением, то что произойдет при отправке в запросе числа, превышающего это значение? Если API работает правильно, то в ответе мы увидим ошибку с этим параметром; отсутствие ошибки будет означать, что API работает неправильно. Для написания тестов значений параметров можно использовать различные техники тест-дизайна (например, классы эквивалентности, граничные значения и техники парного тестирования).

Какие трудности могут возникнуть? Нельзя недооценивать скорый дедлайн, проблемы сервера с API, проблемы с интернетом и внезапное изменение API. Недостаток опыта тестирования и знаний JavaScript приведет к увеличению времени на написание автотестов. Таким образом, закладывая время на разработку тестов, старайтесь все это учесть для точной оценки сроков и качественного тестирования.

Хорошая структура – быстрый анализ ошибок

Пишите свои тесты осмысленно. Представляйте, что написание кода – это создание баг-репорта. Хороший код отличает структура, оптимальность и читаемость.

Читаемость кода достигается несколькими путями. Упомянем лишь часть из них:

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

Оптимальность кода достигается тщательным продумыванием каждой строчки и отсечением всего лишнего; при этом алгоритм должен выполняться за минимальное число шагов.

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

Метод вложенных условий

Суть этого метода в следующем: все проверки, которые можно было написать на вкладке «Tests», вы пишите во вложенных условиях if-else. Этот метод мне нравится тем, что «если что-то сейчас не работает, то дальше проверять не имеет смысла». Это значит, что вы экономите время выполнения проверки метода API, а при правильном заполнении ассоциативного массива tests[] можете сразу понять, что именно сломалось.

Представьте гирлянду с последовательно соединенными лампочками: если одна лампочка перегорает, то не работает вся цепь. Здесь принцип такой же, только лампочки горят до первой поломанной. Не делайте из условий if «параллельные лампочки» – вам сложно будет разобраться, где именно появится ошибка.

Приведу пример плохого написания кода (не используются остановки выполнения автотеста):

Для того, чтобы этот метод работал правильно, вы должны расставить приоритет своим тестам, выяснить последовательность их выполнения и определиться с тем, что имеет смысл проверять даже если что-то сломалось (а также и то, что проверять не нужно).

Например, самый высокий приоритет будет иметь код статуса. Если вы ожидали код 200, а пришло что-то другое (4хх или 5хх), то проверку можно не продолжать – выводим сообщение об ошибке «код ответа не 200». Далее имеет смысл проверить, заполнен ли хоть чем-то ответ: если ответ пуст – выводим ошибку.

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

Реализация метода «вложенных условий» выглядит так:

Метод assert’ов

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

Assert – это принудительный вызов ошибки, исключения, остановки работы программы; при этом может передаваться пользовательский текст ошибки. В программировании assert используется по такому алгоритму: если произошла ошибка, то вызвать исключение с описанием этой ошибки.

В JavaScript это можно реализовать при помощи следующего алгоритма:

• в условие if записываем логическое выражение, истинное при неверных данных;
• в if записываем ассоциативный массив tests[] с ключом-описанием ошибки и значением false;
• после tests[] в условии if вызываем return, который принудительно остановит дальнейшее тестирование.

Не забывайте про приоритет тестов для их логически правильного выстраивания. В данном методе тесты слабо зависят друг от друга, т.е. вы можете сначала проверить, пустое ли тело ответа, затем – какое вернулось значение у параметра «часть речи», а потом – код 200. При первой найденной ошибке метод завершает свою работу и отправляет эту ошибку на вкладку Tests.

Код автотеста с методом assert’ов будет выглядеть так:

Для того, чтобы узнать, какие проверки были отработаны верно, после каждого if необходимо дописать else c tests[«ключ»] = true.

Какой метод лучше?

Оба метода хороши по-своему.

Плюсом метода вложенных условий является возможность вывода нескольких ошибок одновременно. Использование ассоциативного массива и отсутствие принудительных остановок return позволяет полностью проверить ответ и остановить проверки только на определенных уровнях вложенности. В итоге вместо одной ошибки можно получить три на вкладке Tests. Также этот метод помогает понять, какие параметры зависят друг от друга в ответе, – следовательно, вы лучше понимаете и разбираетесь в API, которое тестируете.

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

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

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

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

В итоге оба метода свелись к выбору между «читаемостью кода», «легкостью и скоростью реализации автотеста» и «количеству найденных ошибок при одном запуске теста». Если вы хотите быстро писать автотесты, но при этом готовы исправлять ошибки по мере их обнаружения, то используйте метод assert’ов. Если у вас есть время на продумывание структуры проверок, выявление зависимостей параметров в ответе, и вы хотите получить все ошибки сразу – используйте метод вложенных условий.

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

Практика написания тестов методом вложенных условий

Настало время приступить к написанию автотестов! Давайте попробуем сделать что-то посложнее, применив метод вложенных условий.

Для тестирования метода lookup отправим параметры lang = «ru-ru» и text = «лягушка» и проведем тесты на код 200, на непустое тело ответа и на то, что «лягушка» – имя существительное.

В данном примере получилось три условия if-else, которые вложены по приоритету. Это не все проверки, которыми можно покрыть данный метод, дальнейшее усложнение зависит от знаний и желаемого качества тестового покрытия.
Для тех, кто не знает разницу между «==» и «===», полезно прочитать это и вот это.

Первая сложная строка в примере – var responseBodyJSON = JSON.parse(responseBody). Дело в том, что ответы от сервера приходят в формате JSON. JSON – это объект, и если вы имеете представление о классах и объектах, то сразу поймете, о чем идет речь.

Если же предмет разговора вам непонятен, то его можно объяснить с помощью примера: у вас есть большой платяной шкаф, а внутри него – выдвижные ящики, дверки, вешалки и платья. Ящики, дверки, вешалки – это функции шкафа, а платья – параметры; все в целом – это объект. В Postman responseBody – это не JSON (объект), а строка, но преобразовать в JSON (объект) можно как раз функцией JSON.parse().

Вторая сложная строка – var strfromJSON = responseBodyJSON.def[0].pos, это обращение к нужному параметру в объекте JSON. Например, если в нашем шкафу есть 5 выдвижных ящиков, а нужная вещь находится во втором ящике, то доступ к этой вещи будет выглядеть следующим образом: «шкаф -> выдвижные ящики -> первый выдвижной ящик -> вещь». В документации к «Яндекс.Словарь» можно прочитать о параметрах ответа JSON. Def – массив словарных статей (соответственно, def[0] – первая словарная статья). Pos – часть речи.
Для более наглядной иллюстрации работы метода вложенных условий я покажу его реализацию на практике, представив два примера: когда «все работает», и когда сервер прислал пустое «тело ответа».

По клику на картинку откроется полная версия.
Все, что следует после FAIL, не проверяется и не выводится; тестирование останавливается.

В данной статье я рассказала о тестировании API «Яндекс.Словарь» при помощи Postman, JavaScript, GET запроса и JSON объекта, а также объяснила, как можно облегчить себе жизнь после FAIL при помощи метода вложенных условий или метода assert’ов.
Применяйте все это на практике и получайте хорошие результаты!

Источник: quality-lab.ru