Разработчик
Мы тестируем медицинское оборудование, поэтому знаем, какие требования закон предъявляет к процессу тестирования. Каждый протокол теста — это документ, который контролирующий орган может проверить.
Здесь упор делается на тщательно выверенные формулировки. Кроме того, отчет должен быть оформлен надлежащим образом.
В процессе тестирования пользовательского интерфейса мы распознаем его на скриншотах тестируемого устройства.
Говоря о распознавании, часто имеют ввиду нейросети и другие алгоритмы машинного обучения. Однако, применительно к нашей задаче машинное обучение имеет недостатки. Поэтому мы с его помощью решаем лишь некоторые части задачи распознавания GUI. В остальном, мы разбираем изображение по правилам, написанным вручную.
Squish - это платный инструмент для автоматического тестирования пользовательского интерфейса. Есть Squish для QT, Squish для Windows, для веба, для Java и iOS.
Во всех случаях тестовые сценарии - это скрипты на питоне или других скриптовых языках.
Рассмотрим следующие моменты при работе со Squish для QT на питоне:
• Настройка и запуск без Squish IDE.
• Real name, symbolic name и явные имена.
• Прокси-объекты и их сравнение.
• Suid на тестируемом приложении.
• Тестирование рендеринга с помощью скриншотов.
• Неудобство API Squish и работа без него: симуляция ввода, элементы списков и таблиц.
• Добавление методов в метаобъект для вызова через Squish.
В комментарии к моей предыдущей статье, «Какие задачи не решаются bat-файлами?», предположили, что на bat-файлах не получится написать Doom. Насчет Дума я пока не уверен, а вот тетрис у меня получился.
Бат-файлы ведут свою историю со времен MS-DOS. Новые фичи добавлялись с сохранением обратной совместимости. Из-за этого многое в языке bat-файлов, как мы увидим далее, нелогично и неудобно.
Вместе с тем, в bat-файле можно использовать переменные, условия, циклы и подпрограммы. При помощи некоторых костылей можно передавать данные на вход команд и разбирать их вывод. Проще говоря, можно программировать.
В этой статье мы постараемся дать обзор основных элементов языка командного интерпретатора Windows, с помощью которых можно реализовать любой алгоритм.
В проектах, связанных с разработкой микросервисной архитектуры, CI/CD переходит из разряда приятной возможности в категорию острой необходимости. Автоматическое тестирование является неотъемлемой частью непрерывной интеграции, грамотный подход к которой способен подарить команде множество приятных вечеров с семьёй и друзьями. В противном же случае, проект рискует быть никогда не завершенным.
Можно покрыть весь код микросервиса юнит-тестами с мок-объектами, но это лишь частично решает задачу и оставляет множество вопросов и сложностей, особенно при тестировании работы с данными. Как всегда, наиболее острые – тестирование консистентности данных в реляционной БД, тестирование работы с облачными сервисами и неверные предположения при написании мок-объектов.
Все это и немного больше решается тестированием целого микросервиса в Docker-контейнере. Несомненным преимуществом для обеспечения валидности тестов является то, что тестам подвергаются те же самые Docker-образы, что идут в продакшен.
Автоматизация такого подхода представляет ряд проблем, решение которых будет описано чуть ниже:
Это статья по мотивам моего выступления на SECR 2019. Так что для тех, кому лень читать, вот запись выступления.
