По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет, мы давно хотели рассказать о том, что из себя представляет одна из широко распространённых CRM систем, а именно – про Амо. AmoCRM – система управления бизнесом, в которой хранятся карточки существующих и потенциальных клиентов, воронки продаж и информация о сделках. CRM интегрируется с чатами на сайтах, мессенджерами, социальными сетями и почтой, что позволяет автоматизировать сбор заявок от клиентов и работу с ними. AmoCRM так же генерирует понятные и детальные отчеты по статусам сделок, количеству клиентов и финансовым показателям. В статье мы рассмотрим процесс изначальной регистрации и разберем каждый из модулей этой CRM системы.
/p>
Установка AmoCRM
Для того, чтобы начать пользоваться AmoCRM достаточно зарегистрироваться на официальном сайте. Новая компания получает 14 дней бесплатного использования полного функционала системы. После регистрации необходимо настроить систему, это делается довольно просто. Необходимо просто заполнить поля формы, которая появляется сразу после первого входа в систему.
Саму систему не нужно отдельно устанавливать, она работает как веб-приложение. Так же Amo представлена в виде приложений для Android и iOS. Для планшетов разработчики рекомендуют использовать веб-версию.
Личный кабинет
После окончания регистрации открывается доступ к функциям CRM. На левой панели отображаются инструменты, необходимые для работы, а на главном экране отображается аналитика процессов.
Сделки
Вкладка «Сделки» открывает инструментарий воронки продаж. Она отображает шаги, которые проходит клиент прежде чем совершить целевое действие. По умолчанию в AmoCRM это следующие этапы:
Первичный контакт;
Переговоры;
Принятие решения;
Согласование договора;
При необходимости их можно кастомизировать или создать с нуля. В Amo можно создать до 10 воронок продаж в одном аккаунте, которые будут включать в себя до 100 различных шагов. Настраивается воронка с помощью Настроить>Этапы продаж.Шаги можно выделять цветом для удобства построения сценариев и группировки шагов. Например, зеленый для действий «попадания в воронку», красный для неуспешного статуса.
Задачи
Задачи помогают распределить задания между сотрудниками. Существует два типа встроенных задач: встреча и связаться с клиентом, кроме того можно создать уникальную задачу выбрав иконку, её цвет и название события.
Задаче обязательно должен быть присвоен исполнитель и дедлайн.
Списки
Один из основных компонентов, с которым работают менеджеры по продажам, это вкладка Списки. Она представляет собой базу данных клиентов, контактировавших с компанией так или иначе. Контакты могут быть привязаны к одной и более сделкам в воронке продаж или вообще не участвовать ни в одной. К одному контакту может быть подключено несколько менеджеров с одним ответственным, который регулирует права доступа к информации и действиям. Поля, необходимые для заполнения, могут настраиваться администратором CRM в зависимости от внутренних правил компании и приоритета в данных.
Телефония и почта
Расширить возможности коммуникации с клиентами из CRM можно с помощью интеграций с социальными сетями, мессенджерами, а также электронной почтой и телефонией. Amo предлагает множество вариантов подключения к виртуальным АТС различных компаний буквально в несколько кликов. После интеграции совершать звонки можно прямо из карточки контакта или из сделки. С помощью API CRM можно подключить к любой другой АТС, которая не представлена в списке.
Если у клиента нет опыта интеграции CRM с телефонией, AMO предлагает воспользоваться демо образом виджета, благодаря которому можно исследовать все тонкости работы со звонками внутри системы.
Как и телефонию к системе можно привязать почту и общаться с клиентами напрямую из CRM. История переписки сохраняется в карточке клиента, даже если письмо было отправлено с помощью почтового агента, а не системы.
Аналитика
Amo включает в себя мощные инструменты по созданию графиков и анализу эффективности отдела продаж, так же можно отслеживать различные зависимости и брать данные для разработки маркетинговых компаний.
Пользователю предлагаются следующие отчеты:
Анализ продаж;
Сводный отчет;
Отчет по сотрудникам;
Список событий;
Звонки;
Цели;
Одним из интересных и новых инструментов является последний пункт. Он позволяет отслеживать уровень выполнения KPI в любое время, устанавливать новые показатели и анализировать, как с ними справляются сотрудники.
Данные можно просматривать за 1 день, неделю, месяц и год.
API
Amo CRM предлагает специальный кабинет разработчика, в котором хранится вся необходимая информация для интеграции системы практически с любым другим сторонним сервисом. CRM можно не только просто настроить, но и наделить её абсолютно новыми функциям. Развернутое описание API можно найти на официальном сайте во вкладке для разработчиков.
Кроме того, в настройки уже входят десятки различных виджетов для подключения телефонии, чатов, социальных сетей, рекламной аналитики и др. Систему можно настроить, не прибегая к услугам программистов.
Заключение
На этом все, спасибо за внимание. Если вам интересны какие-то тонкости по работе и настройке AmoCRM – пишите в комментариях, будем рады пополнить нашу базу статей новым интересным и полезным материалом!
Существует большое количество методов аутентификации клиентов беспроводных сетей при подключении. Эти методы появлялись по мере развития различных беспроводных технологий и беспроводного оборудования. Они развивались по мере выявления слабых мест в системе безопасности. В этой статье рассматриваются наиболее распространенные методы проверки подлинности.
Открытая аутентификация
Стандарт 802.11 предлагал только два варианта аутентификации клиента: open authentication и WEP.
Open authentication-предполагает открытый доступ к WLAN. Единственное требование состоит в том, чтобы клиент, прежде чем использовать 802.11, должен отправить запрос аутентификации для дальнейшего подключения к AP (точке доступа). Более никаких других учетных данных не требуется.
В каких случаях используется open authentication? На первый взгляд это не безопасно, но это не так. Любой клиент поддерживающий стандарт 802.11 без проблем может аутентифицироваться для доступа к сети. В этом, собственно, и заключается идея open authentication-проверить, что клиент является допустимым устройством стандарта 802.11, аутентифицируя беспроводное оборудование и протокол. Аутентификация личности пользователя проводится другими средствами безопасности.
Вы, вероятно, встречали WLAN с open authentication, когда посещали общественные места. В таких сетях в основном аутентификация осуществляется через веб-интерфейс. Клиент подключается к сети сразу же, но предварительно должен открыть веб-браузер, чтобы прочитать и принять условия использования и ввести основные учетные данные. С этого момента для клиента открывается доступ к сети. Большинство клиентских операционных систем выдают предупреждение о том, что ваши данные, передаваемые по сети, не будут защищены.
WEP
Как вы понимаете, open authentication не шифрует передаваемые данные от клиента к точке доступа. В стандарте 802.11 определен Wired Equivalent Privacy (WEP). Это попытка приблизить беспроводную связь к проводному соединению.
Для кодирования данных WEP использует алгоритм шифрования RC4. Данный алгоритм шифрует данные у отправителя и расшифровывает их у получателя. Алгоритм использует строку битов в качестве ключа, обычно называемого WEP- ключом. Один кадр данных-один уникальный ключ шифрования. Расшифровка данных осуществляется только при наличии ключа и у отправителя, и у получателя.
WEP- это метод безопасности с общим ключом. Один и тот же ключ должен быть как у отправителя, так и получателя. Этот ключ размещается на устройствах заранее.
WEP-ключ также может использоваться в качестве дополнительного метода аутентификации, а также инструмента шифрования. Если клиент отправляет неправильный ключ WEP, он не подключится к точке доступа. Точка доступа проверяет знание клиентом ключа WEP, посылая ему случайную фразу вызова. Клиент шифрует фразу вызова с помощью WEP и возвращает результат точке доступа (АР). АР сравнивает шифрование клиента со своим собственным, чтобы убедиться в идентичности двух ключей WEP.
Длина WEP - ключей могут быть длиной 40 или 104 бита, представленные в шестнадцатеричной форме из 10 или 26 цифр. Как правило, более длинные ключи предлагают более уникальные биты для алгоритма, что приводит к более надежному шифрованию. Это утверждение не относится к WEP. Так как WEP был определен в стандарте 802.11 в 1999 году, и соответственно сетевые беспроводные адаптеры производились с использованием шифрования, специфичного для WEP. В 2001 году были выявлены слабые места WEP, и началась работа по поиску более совершенных методов защиты беспроводной связи. К 2004 году поправка 802.11i была ратифицирована, и WEP официально устарел. Шифрование WEP и аутентификация с общим ключом WEP являются слабыми методами защиты WLAN.
802.1x/EAP
При наличии только open authentication и WEP, доступных в стандарте 802.11, требовался более безопасный метод аутентификации. Аутентификация клиента обычно включает в себя отправку запроса, получение ответа, а затем решение о предоставлении доступа. Помимо этого, возможен обмен ключами сессии или ключами шифрования в дополнение к другим параметрам, необходимым для клиентского доступа. Каждый метод аутентификации может иметь уникальные требования как уникальный способ передачи информации между клиентом и точкой доступа.
Вместо того чтобы встроить дополнительные методы аутентификации в стандарт 802.11, была выбрана более гибкая и масштабируемая структура аутентификации-разработан расширяемый протокол аутентификации (EAP). Как следует из его названия, EAP является расширяемым и не состоит из какого-либо одного метода аутентификации. Вместо этого EAP определяет набор общих функций, которые применяют фактические методы аутентификации, используемые для аутентификации пользователей.
EAP имеет еще одно интересное качество: он интегрируется со стандартом управления доступом на основе портов стандарта IEEE 802.1X. Когда порт стандарта 802.1X включен, он ограничивает доступ к сетевому носителю до тех пор, пока клиент не аутентифицируется. Это означает, что беспроводной клиент способен связываться с точкой доступа, но не сможет передавать данные в другую часть сети, пока он успешно не аутентифицируется.
Open authentication и WEP аутентификация беспроводных клиентов выполняется локально на точке доступа. В стандарте 802.1 x принцип аутентификации меняется. Клиент использует открытую аутентификацию для связи с точкой доступа, а затем фактический процесс аутентификации клиента происходит на выделенном сервере аутентификации. На рисунке 1 показана трехсторонняя схема стандарта 802.1x, состоящая из следующих объектов:
Клиент: клиентское устройство, запрашивающее доступ
Аутентификатор: сетевое устройство, обеспечивающее доступ к сети (обычно это контроллер беспроводной локальной сети [WLC])
Сервер аутентификации (AS): устройство, принимающее учетные данные пользователя или клиента и разрешающее или запрещающее доступ к сети на основе пользовательской базы данных и политик (обычно сервер RADIUS)
На рисунке клиент подключен к точке доступа через беспроводное соединение. AP представляет собой Аутентификатор. Первичное подключение происходит по стандарту open authentication 802.11. Точка доступа подключена к WLC, который, в свою очередь, подключен к серверу аутентификации (AS). Все в комплексе представляет собой аутентификацию на основе EAP.
Контроллер беспроводной локальной сети является посредником в процессе аутентификации клиента, контролируя доступ пользователей с помощью стандарта 802.1x, взаимодействуя с сервером аутентификации с помощью платформы EAP.
Далее рассмотрим некоторые вариации протокола защиты EAP
LEAP
Первые попытки устранить слабые места в протоколе WEP компания Cisco разработала собственный метод беспроводной аутентификации под названием Lightweight EAP (LEAP). Для проверки подлинности клиент должен предоставить учетные данные пользователя и пароля.
Сервер проверки подлинности и клиент обмениваются челендж сообщениями, которые затем шифруются и возвращаются. Это обеспечивает взаимную аутентификацию. Аутентификация между клиентом и AS осуществляется только при успешной расшифровке челендж сообщений.
На тот момент активно использовалось оборудование, работавшее с WEP- протоколом. Разработчики протокола LEAP пытались устранить слабые места WEP применением динамических, часто меняющихся ключей WEP. Тем не менее, метод, используемый для шифрования челендж сообщений, оказался уязвимым. Это послужило поводом признать протокол LEAP устаревшим. Существуют организации, которые все еще используют данный протокол. Не рекомендуется подключаться к таким сетям.
EAP-FAST
EAP-FAST (Flexible Authentication by Secure Tunneling) безопасный метод, разработанный компанией Cisco. Учетные данные для проверки подлинности защищаются путем передачи зашифрованных учетных данных доступа (PAC) между AS и клиентом. PAC- это форма общего секрета, который генерируется AS и используется для взаимной аутентификации. EAP-FAST- это метод состоящий из трех последовательных фаз:
Фаза 0: PAC создается или подготавливается и устанавливается на клиенте.
Фаза 1: после того, как клиент и AS аутентифицировали друг друга обсуждают туннель безопасности транспортного уровня (TLS).
Фаза 2: конечный пользователь может быть аутентифицирован через туннель TLS для дополнительной безопасности.
Обратите внимание, что в EAP-FAST происходят два отдельных процесса аутентификации-один между AS и клиентом, а другой с конечным пользователем. Они происходят вложенным образом, как внешняя аутентификация (вне туннеля TLS) и внутренняя аутентификация (внутри туннеля TLS).
Данный метод, основанный на EAP, требует наличие сервера RADIUS. Данный сервер RADIUS должен работать как сервер EAP-FAST, чтобы генерировать пакеты, по одному на пользователя.
PEAP
Аналогично EAP-FAST, защищенный метод EAP (PEAP) использует внутреннюю и внешнюю аутентификацию, однако AS предоставляет цифровой сертификат для аутентификации себя с клиентом во внешней аутентификации. Если претендент удовлетворен идентификацией AS, то они строят туннель TLS, который будет использоваться для внутренней аутентификации клиента и обмена ключами шифрования.
Цифровой сертификат AS состоит из данных в стандартном формате, идентифицирующих владельца и "подписанных" или подтвержденных третьей стороной. Третья сторона известна как центр сертификации (CA) и известна и доверяет как AS, так и заявителям. Претендент также должен обладать сертификатом CA только для того, чтобы он мог проверить тот, который он получает от AS. Сертификат также используется для передачи открытого ключа на видном месте, который может быть использован для расшифровки сообщений из AS.
Обратите внимание, что только AS имеет сертификат для PEAP. Это означает, что клиент может легко подтвердить подлинность AS. Клиент не имеет или не использует свой собственный сертификат, поэтому он должен быть аутентифицирован в туннеле TLS с помощью одного из следующих двух методов:
MSCHAPv2;
GTC (универсальная маркерная карта): аппаратное устройство, которое генерирует одноразовые пароли для пользователя или вручную сгенерированный пароль;
EAP-TLS
PEAP использует цифровой сертификат на AS в качестве надежного метода для аутентификации сервера RADIUS. Получить и установить сертификат на одном сервере несложно, но клиентам остается идентифицировать себя другими способами. Безопасность транспортного уровня EAP (EAP-TLS) усиливает защиту, требуя сертификаты на AS и на каждом клиентском устройстве.
С помощью EAP-TLS AS и клиент обмениваются сертификатами и могут аутентифицировать друг друга. После этого строится туннель TLS, чтобы можно было безопасно обмениваться материалами ключа шифрования.
EAP-TLS считается наиболее безопасным методом беспроводной аутентификации, однако при его реализации возникают сложности. Наряду с AS, каждый беспроводной клиент должен получить и установить сертификат. Установка сертификатов вручную на сотни или тысячи клиентов может оказаться непрактичной. Вместо этого вам нужно будет внедрить инфраструктуру открытых ключей (PKI), которая могла бы безопасно и эффективно предоставлять сертификаты и отзывать их, когда клиент или пользователь больше не будет иметь доступа к сети. Это обычно включает в себя создание собственного центра сертификации или построение доверительных отношений со сторонним центром сертификации, который может предоставлять сертификаты вашим клиентам.
С помощью этого руководства вы научитесь писать модульные тесты для функций Python. Но для чего вообще нужно уделять такое внимание модульным тестам?
Что ж, когда вы работаете над большими проектами, вам часто приходится обновлять какие-то модули и выполнять перепроектирование кода по мере необходимости. Однако такие изменения могут негативно влиять на другие модули, в которых используется этот обновленный модуль. В некоторых случаях это может нарушить существующую функциональность программы.
Как разработчик, вы обязаны протестировать свой программный код с целью убедиться, что все модули в приложении работают должным образом. Модульные тесты позволяют проверять, корректно ли работают маленькие блоки программного кода, и исправлять несоответствия, которые возникают в результате обновлений и перепроектирования.
Это руководство поможет вам научиться обращаться с модульными тестами в Python. Здесь вы узнаете, как использовать встроенный в Python модуль
unittest
для настройки и запуска модульных тестов, а также для написания тестовых примеров для проверки функций Python. Также вы узнаете, как тестировать функции, которые вызывают исключения.
Давайте начнем!
Тестирование в Python – первый этап
Мы начнем с того, что определим функцию Python и напишем модульный тест, чтобы проверить, работает ли она должным образом. Для того, чтобы перейти к настройке модульных тестов, рассмотрим простую функцию
is_prime()
, которая принимает на вход число и проверяет его на простоту.
import math
def is_prime(num):
'''Check if num is prime or not.'''
for i in range(2,int(math.sqrt(num))+1):
if num%i==0:
return False
return True
Давайте запустим Python REPL, вызовем функцию
is_prime()
, передав ей аргументы, и проверим результаты.
>>> from prime_number import is_prime
>>> is_prime(3)
True
>>> is_prime(5)
True
>>> is_prime(12)
False
>>> is_prime(8)
False
>>> assert is_prime(7) == True
Для того, чтобы убедиться, что
is_prime(),
возвращает ожидаемое логическое значение, вы также можете использовать конструкцию
assert
(см. выше). Если значение, которое вернула функция, отличается от ожидаемого логического значения, то возникнет ошибка
AssertionError
.
Такое ручное тестирование будет не самым эффективным вариантом, если вы захотите проверить свою функцию на гораздо большем количестве аргументов. У вас есть возможность настроить автоматическое тестирование, которое будет запускать функцию и проверять выходные данные на соответствие тестовым примерам, которые были определены в тестовом наборе.
Как работать с модулем Python
unittest
В Python втроен модуль
unittest
, с помощью которого можно настраивать автоматические тесты для функций и классов в вашем приложении. Общая процедура для настройки модульных тестов в Python выглядит следующим образом:
# .py
import unittest
from import
# all entries within <> are placeholders
class TestClass(unittest.TestCase):
def test_(self):
# check function_to_test
def test_(self):
# check function_to_test
:
:
:
def test_(self):
# check function_to_test
Фрагмент кода
.py
, который приведен выше, выполняет следующее:
Импортирует встроенный в Python модуль
unittest
.
Импортирует функцию Python
, которую необходимо протестировать, из модуля
, в котором она определена.
Создает тестовый класс (
TestClass
), который наследуется от класса
unittest.TestCase
.
Все тесты, которые должны быть запущены, должны быть определены в качестве методов внутри тестового класса.
?
Примечание
: для того, чтобы
unittest
определял эти методы как тесты и запускал их, названия этих методов должны начинаться с
test_
.
Класс
TestCase
из модуля
unittest
предоставляет полезные методы с утверждениями для проверки того факта, что тестируемая функция возвращает ожидаемые значения.
Ниже перечислены самые распространенные методы с утверждениями, и некоторые из них мы будем использовать в этом руководстве.
Метод
Описание
assertEqual(expected_value,actual_value)
Утверждает, что
expected_value == actual_value
assertTrue(result)
Утверждает, что
bool(result)
это
True
assertFalse(result)
Утверждает, что
bool(result)
это
False
assertRaises(exception, function, *args, **kwargs)
Утверждает, что
function(*args, **kwargs)
вызывает
exception
Для того, чтобы запустить эти тесты, мы должны запустить
unittest
в качестве основного модуля с помощью следующей команды:
$ python -m unittest .py
Для запуска
unittest
в качестве основного модуля мы можем добавить условие
if __name__=='__main__'
.
if __name__=='__main__':
unittest.main()
Добавив if, у нас появится возможность запускать тесты, просто запуская модуль Python, который содержит эти тесты.
$ python .py
Как определять тестовые примеры для функций Python
В этом разделе мы напишем модульные тесты для функции
is_prime()
с помощью уже изученного синтаксиса.
Для того, чтобы протестировать функцию
is_prime()
, которая возвращает логическое значение, мы можем воспользоваться методами
assertTrue()
и
assertFalse()
. Мы определяем четыре метода тестирования в классе
TestPrime
, который наследуется от
unittest.TestCase
.
import unittest
# import the is_prime function
from prime_number import is_prime
class TestPrime(unittest.TestCase):
def test_two(self):
self.assertTrue(is_prime(2))
def test_five(self):
self.assertTrue(is_prime(5))
def test_nine(self):
self.assertFalse(is_prime(9))
def test_eleven(self):
self.assertTrue(is_prime(11))
if __name__=='__main__':
unittest.main()
$ python test_prime.py
Ниже вывод в виде точки ( . ) говорит нам об успешно выполненном тестировании.
Output
....
----------------------------------------------------------------------
Ran 4 tests in 0.001s
OK
В приведенном выше коде есть четыре метода тестирования. Каждый из этих методов проверяет какие-то определенные входные данные. Вместо этого вы можете определить один метод тестирования, который проверял бы результат для всех четырех входных данных.
import unittest
from prime_number import is_prime
class TestPrime(unittest.TestCase):
def test_prime_not_prime(self):
self.assertTrue(is_prime(2))
self.assertTrue(is_prime(5))
self.assertFalse(is_prime(9))
self.assertTrue(is_prime(11))
После того, как мы запустили модуль
test_prime,
мы видим, что успешно было выполнено только одно тестирование. Если какой-либо из методов с утверждением выдает
AssertionError
, то это значит, что тест завершился неудачно.
$ python test_prime.py
Output
.
----------------------------------------------------------------------
Ran 1 test in 0.001s
OK
Как писать модульные тесты для проверки на исключения
В предыдущем разделе мы протестировали функцию
is_prime()
, передавая в качестве входных данных как простые, так и непростые числа. Если более конкретно, то все входные данные были положительными числами.
Мы еще не установили тот факт, что аргументы в вызове функции
is_prime()
должны быть целыми положительными числами. Вы можете использовать подсказки при вводе кода для того, чтобы обеспечить соблюдение типов или выкидывать исключения для недопустимых входных данных.
При тестировании функции
is_prime()
мы не учли следующее:
Если аргумент будет числом с плавающей точкой, то функция
is_prime()
также будет работать и возвращать значение
True
или
False
, что является ошибочным.
Если аргумент будет совершенно другого типа (например, строкой «five» вместо числа 5), то функция выдаст ошибку
TypeError
.
Если аргумент будет отрицательным числом, то функция
math.sqrt()
выдаст ошибку
ValueError
, поскольку квадраты всех действительных чисел (положительных, отрицательных или нуля) всегда неотрицательны.
Давайте проверим то, что мы рассмотрели выше, запустив несколько циклов Python REPL.
>>> from prime_number import is_prime
>>> is_prime('five')
Traceback (most recent call last):
File "", line 1, in
File "/home/bala/unit-test-1/prime_number.py", line 5, in is_prime
for i in range(2,int(math.sqrt(num))+1):
TypeError: must be real number, not str
>>> is_prime(-10)
Traceback (most recent call last):
File "", line 1, in
File "/home/bala/unit-test-1/prime_number.py", line 5, in is_prime
for i in range(2,int(math.sqrt(num))+1):
ValueError: math domain error
>>> is_prime(2.5)
True
Как вызвать исключения для недопустимых входных данных
Для того, чтобы устранить все недочеты, которые мы обсудили выше, мы проверим значение
num
, которое используется в вызове функции, и выбросим исключение, если это будет нужно.
Проверяем, является ли
num
целым числом. Если является, то переходим к следующей проверке. В противном случае выбрасываем исключение
TypeError
.
Проверяем, является ли
num
отрицательным целым числом. Если является, то выбрасываем исключение
ValueError
.
Переопределяем функцию, чтобы она также проверяла значение и выбрасывала по мере необходимости исключения. И получаем:
import math
def is_prime(num):
'''Check if num is prime or not.'''
# raise TypeError for invalid input type
if type(num) != int:
raise TypeError('num is of invalid type')
# raise ValueError for invalid input value
if num < 0:
raise ValueError('Check the value of num; is num a non-negative integer?')
# for valid input, proceed to check if num is prime
for i in range(2,int(math.sqrt(num))+1):
if num%i==0:
return False
return True
Теперь, когда мы изменили функцию так, чтобы мы могли выбрасывать исключения
ValueError
и
TypeError
для недопустимых входных данных, следующий шаг - проверка того, выпадает ли исключение.
Как пользовать методом
assertRaises()
для проверки наличия исключений
Давайте добавим в определение
TestPrime
методы для проверки того, выпадают ли исключения.
Мы определим методы
test_typeerror_1()
и
test_typeerror_2()
для проверки исключения
TypeError
, и метод
test_valueerror()
для проверки исключения
ValueError
.
?
Для вызова метода
assertRaises()
мы можем использовать следующий общий синтаксис:
def test_exception(self):
self.assertRaises(exception-name,function-name,args)
Мы также можем применить и другой синтаксис, используя менеджер контекста (в этом примере мы будем использовать именно его):
def test_exception(self):
with self.assertRaises(exception-name):
function-name(args)
Добавив эти методы тестирования, получим:
import unittest
from prime_number import is_prime
class TestPrime(unittest.TestCase):
def test_prime_not_prime(self):
self.assertTrue(is_prime(2))
self.assertTrue(is_prime(5))
self.assertFalse(is_prime(9))
self.assertTrue(is_prime(11))
def test_typeerror_1(self):
with self.assertRaises(TypeError):
is_prime(6.5)
def test_typeerror_2(self):
with self.assertRaises(TypeError):
is_prime('five')
def test_valueerror(self):
with self.assertRaises(ValueError):
is_prime(-4)
if __name__=='__main__':
unittest.main()
Давайте запустим модуль
test_prime
и посмотрим на результат:
$ python test_prime.py
Output
....
----------------------------------------------------------------------
Ran 4 tests in 0.002s
OK
Во всех примерах, которые мы успели написать до этого момента, все тесты выполнялись успешно. Давайте изменим один из методов, допустим,
test_typeerror_2()
:
def test_typeerror_2(self):
with self.assertRaises(TypeError):
is_prime(5)
Мы вызываем функцию
is_prime()
и передаем ей в качестве аргумента число 5. В данном случае 5 является допустимым вводом, для которого функция возвращает
True
. Поэтому функция не вызывает исключение
TypeError
. А когда мы снова запустим тесты, то увидим, что один тест завершился неудачно.
$ python test_prime.py
Output
..F.
======================================================================
FAIL: test_typeerror_2 (__main__.TestPrime)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_prime.py", line 17, in test_typeerror_2
is_prime(5)
AssertionError: TypeError not raised
----------------------------------------------------------------------
Ran 4 tests in 0.003s
FAILED (failures=1)
Заключение
Благодарю, что дочитали до конца!
?
Надеюсь, что это руководство помогло вам понять азы модульного тестирования в Python.
Вы научились настраивать тестирования, которые позволяют проверять, работает ли функция должным образом или выкидывает исключение – и все это с помощью встроенного в Python модуля
unittest
.