Что такое тестирование программного обеспечения и зачем оно нужно

ДОКУМЕНТАЦИЯ

Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.

Основные атрибуты требований:

• Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

• Недвусмысленность — требование должно содержать однозначные формулировки.

• Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию ( а также необходимое в процессе работы оборудование, специальные знания, оценки рисков с вариантами их разрешения). Отвечает на вопросы:

• Что нужно тестировать?

• Как будет тестироваться?

• Когда будет тестироваться?

• Критерии начала тестирования.

• Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для валидации покрытия продукта тестами.

Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Тест-кейс состоит из:

• Названия

• Более подробного описания сути проводимого кейса (для более сложных кейсов)

• Описания окружения

• Указания тестируемого компонента приложения

• Предусловия — PreConditions (не всегда используются) — действий, которые приводят систему к состоянию пригодному для проведения проверки, либо список условий, выполнение которых говорит о том, что система находится в нужном для состоянии основного теста

• Шагов — Steps — cписок действий, переводящих систему из одного состояния в другое, для получения результата

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

• и иногда Постусловия — PostConditions — для перевода системы в первоначальное состояние, как до проведения теста (initial state)

Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего — этоTest script), так и независимыми (Test suite).

Наиболее часто выделяются наборы для:

• Smoke тестирования

• приёмо-сдаточных испытаний.

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

Детализация сводного отчета¶

Флаг можно использовать для отображения «краткой сводной информации по тестированию»
в конце тестового сеанса, что упрощает получение четкой картины всех сбоев, пропусков, xfails и т. д.

По умолчанию для списка сбоев и ошибок используется добавочная комбинация .

Пример:

# content of test_example.py
import pytest


@pytest.fixture
def error_fixture():
    assert 


def test_ok():
    print("ok")


def test_fail():
    assert 


def test_error(error_fixture):
    pass


def test_skip():
    pytest.skip("skipping this test")


def test_xfail():
    pytest.xfail("xfailing this test")


@pytest.mark.xfail(reason="always xfail")
def test_xpass():
    pass

$ pytest -ra
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-5.x.y, py-1.x.y, pluggy-0.x.y
cachedir: $PYTHON_PREFIX/.pytest_cache
rootdir: $REGENDOC_TMPDIR
collected 6 items

test_example.py .FEsxX                                               

================================== ERRORS ==================================
_______________________ ERROR at setup of test_error _______________________

    @pytest.fixture
    def error_fixture():
>       assert 0
E       assert 0

test_example.py:6: AssertionError
================================= FAILURES =================================
________________________________ test_fail _________________________________

    def test_fail():
>       assert 0
E       assert 0

test_example.py:14: AssertionError
========================= short test summary info ==========================
SKIPPED  $REGENDOC_TMPDIR/test_example.py:22: skipping this test
XFAIL test_example.py::test_xfail
  reason: xfailing this test
XPASS test_example.py::test_xpass always xfail
ERROR test_example.py::test_error - assert 0
FAILED test_example.py::test_fail - assert 0
== 1 failed, 1 passed, 1 skipped, 1 xfailed, 1 xpassed, 1 error in 0.12s ===

Параметр принимает ряд символов после себя. Использованный выше символ означает
“все, кроме успешных».

Вот полный список доступных символов, которые можно использовать:

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

Можно использовать более одного символа. Например, для того, чтобы увидеть только
упавшие и пропущенные тесты, можно выполнить:

$ pytest -rfs
=========================== test session starts ============================
platform linux -- Python 3.x.y, pytest-5.x.y, py-1.x.y, pluggy-0.x.y
cachedir: $PYTHON_PREFIX/.pytest_cache
rootdir: $REGENDOC_TMPDIR
collected 6 items

test_example.py .FEsxX                                               

================================== ERRORS ==================================
_______________________ ERROR at setup of test_error _______________________

    @pytest.fixture
    def error_fixture():
>       assert 0
E       assert 0

test_example.py:6: AssertionError
================================= FAILURES =================================
________________________________ test_fail _________________________________

    def test_fail():
>       assert 0
E       assert 0

test_example.py:14: AssertionError
========================= short test summary info ==========================
FAILED test_example.py::test_fail - assert 0
SKIPPED  $REGENDOC_TMPDIR/test_example.py:22: skipping this test
== 1 failed, 1 passed, 1 skipped, 1 xfailed, 1 xpassed, 1 error in 0.12s ===

Использование добавляет в сводный отчет успешные тесты, а добавляет
дополнительный раздел «пройдены” (PASSED) для тестов, которые прошли, но перехватили вывод:

Что мы тестируем?

Мы тестируем:

• возвращаемое значение;
• изменение состояния;
• обращение к внешней стороне.

Возвращаемое значение

Это наиболее простой вид функциональности, который нужно протестировать. По сути, здесь мы тестируем возвращаемое методом (или функцией) значение. В принципе, ничего сложно: создали нужный объект, вызвали требуемый метод на определенном наборе аргументов (или без них), и проверили возвращаемый им результат на предмет его совпадения с некоторым ожидаемым значением.

Изменение состояния

Здесь проверяем, что набор манипуляций, который мы сделали с объектом, привел к тому, что его состояние изменилось. Состояние определяется набором внутренних атрибутов (полей). Как правило, к ним мы напрямую доступ не имеем (а если имеем, то тут стоит задуматься, ибо это не очень хорошая практика), поэтому проверять изменение состояния приходится косвенным образом. Например, мы запустили исполнение через метод Run() и проверили, что все запустилось через свойство IsRunned или вызов метода с именем похожим на GetState().

Обращение к внешней стороне

Это наиболее интересный вид тестирования. Идея в том, что наша сущность может обращаться к внешней стороне, и нам необходимо протестировать, что это взаимодействие было выполнено ожидаемым образом. При этом внешнюю сторону мы никак не контролируем (например, если это какой-то веб-сервис). Тут есть два момента про которые стоит помнить, касающиеся подмены внешней стороны в тесте:

• либо мы делаем заключение по объекту, который обращается к внешней стороне, в этом случае она (подмена) называется заглушкой (stub);
• либо мы делаем заключение, анализируя изменения в сущности, к которой обращались, в этом случае подмененная “внешняя сторона” называется подставкой (mock).

Если вы пока не знаете, заглушка это или подставка, то называйте ее подделкой (fake). Более подробно про это будет рассказано далее.

Цель и значимость тестирования

Тестирование программного обеспечения — это выявление ошибок, дефектов и недочетов в системе, проверка соответствия требованиям.

Также testing — это процесс оценки ПО.

Существует альфа и бета-тестирование. При первой версии продукт жизнеспособен, но в нем все еще есть много недоработок. В бета-версии уже нет критичных багов.

Задача тестировщика — создать план тестирования (test plan) или комплекс мероприятий, чтобы выбрать подход к тестированию, проверить возможные и невозможные сценарии поведения пользователей и убедиться, что программа при любом исходе будет продолжать работать правильно и соответствовать потребностям пользователей. Специалисты проверяют программы на соблюдение условий и параметров с помощью тест-кейсов (test case). Это инструкции для проведения проверок.

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

Если программа сразу и при каждом тесте работает без ошибок, тестирование считается неудачным и не выполняет свою задачу.

Вот несколько основных задач тестирования ПО:

— Обеспечение качества. Тестирование и автотесты помогают выявить и исправить ошибки и проблемы, чтобы продукт был стабильным и надежным в эксплуатации.

— Повышение надежности. Это позволяет обнаружить и устранить ошибки, которые могут привести к неожиданному поведению или ожидаемым сбоям системы. Проверяется производительность и безопасность системы.

— Оптимизация производительности. Тестирование может выявить проблемы, связанные с низкой производительностью, недостаточной масштабируемостью и другими аспектами работы системы. Для этого проводятся проверки реализации тестируемой функции.

— Проверка соответствия требованиям. Это помогает убедиться, что разработчики правильно поняли и реализовали требования клиентов или заказчиков.

— Улучшение пользовательского опыта. Целью тестирования ПО является также улучшение пользовательского опыта. Тестирование помогает проверить удобство использования, интуитивность интерфейса, эффективность взаимодействия и другие аспекты, которые могут повлиять на удовлетворенность пользователя.

Значимость тестирования ПО заключается в следующем:

— Процесс предварительной проверки. Это предотвращает возможные проблемы в работе и сбои, которые могут возникнуть во время использования системы. Если сбой есть, нужно это устранить.

— Улучшение качества ПО. Тестирование помогает предоставить пользователям стабильный и надежный продукт, что способствует удовлетворенности их потребностей. 

— Повышение доверия пользователей. Тест ПО помогает повысить доверие пользователей до выпуска продукта.

В процессе тестирования появляется артефакт.Артефакт — это документ, который помогает наладить коммуникацию между всеми участниками проекта.

На каких этапах жизненного цикла ПО необходим тестировщик?

Если говорить коротко, то на всех.

Сначала, на этапе анализа требований и проектирования, тестировщик тестирует сами требования и участвует в обсуждении концепта решения. Мы добиваемся того, что снимаем фундаментальные ошибки на самом раннем уровне и тем самым удешевляем разработку. Основной инструмент на этом этапе – грамотные вопросы, вкупе со знаниями системы и с общим техническим бэкграундом.

Следующий этап – это непосредственно разработка ПО. Это основной этап работы тестировщика. На этом этапе разрабатываются тестовые сценарии (тест-кейсы), после чего они выполняются и фиксируются дефекты, если они есть

Это этап верификации, который подтверждает, что функционал работает так, как описано в требованиях, и не противоречит здравому смыслу, что тоже важно. Здесь основные инструменты тестировщика – тестовые сценарии и дефекты, с корректными приоритетами.

Далее – этап валидации решения

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

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

Пользовательские метки

Дополнительно к автоматическим меткам есть возможность использовать индивидуальные. Это удобно, если требуется разделить тесты на несколько групп и проводить их запуск отдельно. Чтобы сформировать свою метку, просто укажите её название:

Для запуска теста, помеченного my_mark при вводе в терминал команды pytest —no-summary -m my_mark tests.py, получите на выходе следующее:

Только три файла из пяти запустились с необходимой меткой, а также были зафиксированы три предупреждения. Появилась ошибка от Pytest, указывающая на незарегистрированную метку my_mark в pytest.ini

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

Фикстуры в Pytest

Фикстуры — это функции, которые создают окружение вокруг тестов. Они удобны, когда нужно передать одни и те же входные данные нескольким тестам.

Допустим, у нас есть несколько функций в main.py:

Напишем для каждой из них по тесту в файле tests.py. В качестве тестового массива возьмём список простых чисел от 1 до 50. Создавать его будем с помощью :

Пока во всех тестовых функциях мы используем одну и ту же громоздкую конструкцию, создающую список простых чисел. Вынесем её в отдельную фикстуру. Для этого явно импортируем модуль pytest:

Чтобы объявить функцию фикстурой, используем перед ней декоратор @pytest.fixture():

Теперь передадим эту фикстуру во все тесты, где она нужна. Обращаясь к фикстуре, у неё не нужно писать круглые скобки: как будто это не функция, а переменная.

Сами тесты в итоге получаются такие:

Финализатор

Если хотите, чтобы после запуска теста выполнялся ещё какой-то скрипт, это также можно сделать через фикстуры. Для этого вместо ключевого слова return используйте yield. Код, написанный после yield, и будет выполняться по завершении теста.

Изменим в нашем примере с простыми числами фикстуру get_prime_nums() и добавим в неё финализатор:

При запуске тестов получаем такой результат:

Если тест не был пройден (то есть assert получил False), код из финализатора всё равно выполняется.

Области действия фикстур

У фикстур можно настраивать область действия, в которой они существуют. По умолчанию она равна функции. Это значит, что, когда тестовая функция прекращает свою работу, фикстура финализируется и уничтожается. При следующем вызове фикстура создаётся заново. Это хорошо видно по прошлому примеру с финализатором.

Область действия фикстуры указывается в её декораторе аргументом scope=’область действия’. Всего есть пять уровней:

• ‘function’ — для функции;
• ‘class’ — для класса;
• ‘module’ — для модуля (то есть py-файла);
• ‘package’ — для пакета;
• ‘session’ — для всей сессии тестирования.

Изменим у фикстуры get_prime_nums область действия на module.

Посмотрим, как изменится работа тестов:

В отличие от прошлого примера, фикстура здесь вызывается только один раз — в первой функции, которая её использует. Затем результат работы кэшируется. Финализатор тоже срабатывает только единожды, когда заканчивается файл.

Иерархии фикстур

Одному тесту можно передать сколько угодно фикстур, указывая их через запятую. Их можно передавать и другим фикстурам — тоже в любом количестве.

Например, фикстуру get_prime_nums можно разбить на несколько (хотя в нашем случае в этом нет практического смысла):

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

Примечание

Фикстуры с более широкой областью действия нельзя встраивать с фикстуры меньшего уровня.

Автоиспользование фикстур

Иногда может быть полезным, чтобы фикстура запускалась всегда, даже если функция её не вызывает. Например, когда перед выполнением тестов нужно залогиниться в системе.

В таких случаях можно указать параметр autouse в декораторе: @pytest.fixture(autouse=True).

Основные элементы

Давайте разберем подробнее атрибуты тест-плана: то, без чего не обходится этот документ.

Цели и задачи тестирования

К проведению тестирования относятся как к проекту. Очевидно, что у любого проекта есть цели и задачи.

Цели тестирования — это то, чего вы хотите достичь в результате. Это может включать проверку соответствия ПО заявленным требованиям, поиск и исправление ошибок, обеспечение надежности продукта.

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

Объекты тестирования

Объекты тестирования — это те компоненты или функции, которые нужно протестировать

Важно сосредоточиться на конкретных объектах, чтобы не тратить время на тестирование второстепенных вещей, которые вы попутно сможете заметить в процессе

Что может быть объектом тестирования:

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

Методы тестирования

Есть разные подходы и техники, которые используют для тестирования. Обычно их выбирают после того, как определяют объект, который нужно изучить. 

• Ручное тестирование — выполнение тестов вручную, например, чтобы проверить пользовательский интерфейс.
• Автоматизированное тестирование — использование скриптов и инструментов для автоматического выполнения тестов.
• Функциональное тестирование — проверка того, как программа выполняет заявленный функционал.
• Тестирование производительности — оценка работы системы при различных нагрузках.
• Тестирование безопасности — проверка на уязвимости и угрозы.

Ресурсы и инструменты

Ресурсами может быть персонал, оборудование и различный софт, необходимый для проведения тестирования. Весь набор ресурсов может меняться в зависимости от того, что нужно протестировать.

Среди инструментов тестировщика могут быть:

• Selenium для автоматизации тестирования, 
• Jira для управления проектами и отслеживания ошибок,
• Postman для тестирования API.

Пройти гигиеническое обучение и аттестацию

При дистанционной форме  обучения — заказчик  самостоятельно, используя дома компьютер,    изучает  методический  материал (лекции)  и проходит, не выходя из дома,  на компьютере  тест — контроль на знание санитарных требований (сдает экзамен). При успешном прохождении тест — контроля специалист ФБУЗ оформляет заказчику личную  медицинскую  книжку.

III. Технология поиска необходимых для обучения материалов.

Перечень групп работников, подлежащих гигиеническому обучению и аттестации:

1. Гигиеническое обучение  заведующих и воспитателей детских дошкольных учреждений
2. Гигиеническое обучение  помощников воспитателей детских дошкольных учреждений
3. Гигиеническое обучение начальников, воспитателей, вожатых детских оздоровительных лагерей
4. Гигиеническое обучение технического персонала образовательных учреждений
5. Гигиеническое обучение педагогических работников образовательных учреждений
6. Гигиеническое обучение работников пищеблоков  детских оздоровительных лагерей
7. Гигиеническое обучение работников пищеблоков детских дошкольных учреждений
8. Гигиеническое  обучение инженерно-технических работников работающих с пестицидами и агрохимикатами
9. Гигиеническое обучение рабочих профессий работающих с пестицидами и агрохимикатами
10. Гигиеническое обучение работников кондитерских производств
11. Гигиеническое обучение работников молокоперерабатывающей промышленности
12. Гигиеническое обучение работников мясо- и птицеперерабатывающей промышленности
13. Гигиеническое обучение работников общественного питания
14. Гигиеническое обучение работников продовольственной торговли
15. Гигиеническое обучение работников хлебопекарной и макаронной промышленности
16. Гигиеническое обучение преподавателей ВУЗов
17. Гигиеническое обучение студентов ВУЗов
18. Гигиеническое обучение учащихся и студентов  образовательных учреждений начального проф. образования  и средних специальных учебных заведений
19. Гигиеническое обучение работников парикмахерских
20. Гигиеническое обучение работников фармацевтических  и аптечных учреждений
21. Гигиеническое обучение медицинских работников, кроме младшего мед. персонала
22. Гигиеническое обучение горничных и уборщиц гостиниц и общежитий
23. Гигиеническое обучение младшего медперсонала, организаций, осуществляющих медицинскую деятельность
24. Гигиеническое обучение работников бань и прачечных
25. Гигиеническое обучение работников водопроводно-канализационного хозяйства
26. Гигиеническое обучение работников системы коммунально — бытового обслуживания
27. Гигиеническое обучение работников торговли промышленными товарами
28. Гигиеническое обучение работников плавательных бассейнов
29. Гигиеническое обучение работников рыбообрабатывающих предприятий
30. Гигиеническое обучение работников производств пивоваренной и безалкогольной продукции

Как писать тесты

Для начала нужен код, который мы будем тестировать. Создадим файл main.py и функцию sum2. Она будет принимать на вход два аргумента и возвращать их сумму:

Теперь проверим, корректно ли она работает. Для этого создадим файл tests.py, импортируем в него sum2 и напишем test_sum2:

Чтобы запустить тесты, введём в консоль команду pytest. Альтернативный вариант — использовать интерфейс вашей IDE. Например, PyCharm позволяет запустить файл целиком или тестовую функцию в отдельности.

Получаем вот такой результат:

Теперь изменим наш тест: пусть он ожидает получить не 23, а 0:

Получим сообщение о том, что тест не пройден:

Ограничения нейминга

Чтобы Pytest воспринимал функции тестовыми, файлы и сами тесты должны быть названы определённым образом:

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

Как работает assert

Ключевому слову assert можно передать любое условие. Если оно правдиво (результат True) — тест пройден, если ложно (результат False) — не пройден.

Таким образом можно писать минимальные тесты:

Результат:

Через запятую после условия можно написать отладочное сообщение. Pytest выведет его, если тест провалится:

Результат:

Если в тесте нет assert, он считается пройденным:

Результат:

Примечание

В одном тесте может быть сразу несколько операторов assert, но делать так мы не рекомендуем. Лучше руководствоваться правилом «Один тест — одна сущность, одна функция — один assert».

Запуск тестов

Команда терминала pytest запускает все тесты текущего каталога. Чтобы управлять условиями запуска, укажите после неё путь до файла или даже отдельной функции.

• Команда для запуска файла tests.py: pytest tests.py.
• Команда для запуска функции test_sum2 и только её: pytest tests.py: test_sum2.

Для более гибкого запуска можно дополнительно добавлять флаги. Их список есть в  Pytest.

Что проверяется во время статического тестирования?

Статическое тестирование рассматривает дизайн, код и документы, из которых состоит ваш проект

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

1. Обзор документации

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

Документы по бизнес-требованиям

Тестировщики изучают документ с бизнес-требованиями и убеждаются, что они точно отражают потребности заинтересованных сторон и соответствуют бизнес-целям.

Спецификации требований к программному обеспечению (SRS)

Документ спецификации требований к программному обеспечению (SRS) описывает функции и полезность программного обеспечения. Статическое тестирование проверяет этот документ и убеждается, что он точно описывает функциональность программного обеспечения, включая зависимости и пользовательские интерфейсы.

Проектная документация

Проектная документация также проверяется на предмет соответствия требованиям и спецификациям. Тестировщики проверяют диаграммы унифицированного языка моделирования (UML), потоков данных и архитектурные диаграммы на соответствие требованиям проекта.

Документы по сценариям использования и истории пользователя

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

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

Book ZAPTEST Enterprise Demo

Book ZAPTEST Demo

Тестовые случаи

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

2. Обзор кодов

Далее будет рассмотрен код, используемый в приложении

Вот некоторые из областей, на которые обращают внимание команды тестирования

Синтаксические ошибки

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

Мертвый код

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

Неиспользуемые переменные

Статическое тестирование также позволяет выявить неиспользуемые переменные, которые объявлены, но никогда не выполняются компилятором.

Нарушения стандартов кодирования

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

Недостатки логики

Логические недостатки могут означать, что исходный код работает некорректно, но не дает сбоев. Статические обзоры направлены на выявление и устранение этих проблем до выполнения кода.

Потоки данных

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

Потоки управления

Еще одна изучаемая область – поток управления. Этот обзор изучает порядок выполнения операторов кода и гарантирует, что все действия выполняются в правильном порядке, чтобы программное обеспечение работало так, как задумано.

Применение функций-фикстур

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

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

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

Эта функция должна вывести список строк с полными именами, за которыми следует двоеточие и их заголовок:

Поскольку мы моделируем рабочий процесс разработки, первым делом нужно написать для него тест. Один из способов сделать это:

Делаем шаг вперёд и напишем другую функцию для обработки информации и вывода её в формате значений для использования в электронных таблицах:

Список дел растёт, а благодаря разработке через тестирование вы можете легко планировать задачи наперёд. Новая функция будет похожа на reformat_data():

Оба теста должны снова определить переменную people, а сборка этих строк кода требует времени и дополнительных усилий.

Фикстуры могут помочь при использовании одних и тех же тестовых данных в разных тестах. С их помощью можно поместить одинаковые куски кода в одну функцию и обозначить при помощи ключевого слова @Pytest.fixture, например:

Использовать фикстуру несложно — нужно добавить ссылку на функцию в качестве аргумента. Возвращаемое значение функции-фикстуры может использоваться так:

Теперь тесты намного меньше, но имеют чёткий обратный путь к тестовым данным.