ВНИМАНИЕ!!! Attention! Achtung! Attenzione! Увага! Это даже не черновик, а франкенштейн из обрывков. Выкладываю его сюда просто чтобы обозначить, что когда-нибудь я начну работу над этим разделом (не ближайший год точно), а также для того, чтобы желающие могли это начать уже сейчас. Может быть кто-то просто найдет в этом хаосе что-то полезное.
- Обнаружение дефектов как можно раньше. До того как увидит пользователь, до того как выложить на сервер, до того как отдать на тестирование, до того как закоммитить.
- Локализация проблемы. Тест затрагивает лишь часть кода.
- Ускорение разработки. Исполнение теста происходит гораздо быстрее ручной проверки.
- Актуальная документация. Тест представляет из себя простой и гарантированно актуальный пример использования.
Пирамида автоматизации Майка Кона отлично иллюстрирует более эффективный подход. Ширина каждого уровня пирамиды показывает, сколько тестов должно быть на каждом уровне по сравнению с другими.
На нижнем уровне пирамиды находятся компонентные, или юнит-тесты. Они должны составлять большинство ваших тестов. Например, чтобы протестировать класс, который вычисляет проценты с суммы, создается юнит-тест, передающий процентную ставку x и баланс y. Ожидаемый результат: корректное вычисление суммы процентов с нужной точностью.
Средний уровень занимают тесты, которые верифицируют бизнес-поведение (но не через GUI!). Такие тесты иногда называют API тестами. Если вы используете методологию «разработки через поведение» (BDD, behavior-driven development), ваши автоматические тесты будут относиться к этому уровню. Вам может понадобиться довольно большое количество тестов этого уровня, но всё равно их должно быть меньше, чем юнит-тестов. Такие тесты могут затрагивать несколько компонентов одновременно и проверять поведение продукта с точки зрения бизнеса. Пример: после вычисления процента по депозиту нужная сумма добавляется к балансу.
Верхний уровень пирамиды — автоматические тесты, которые непосредственно затрагивают пользовательский интерфейс. Их должно быть намного меньше, чем остальных. Пример такого теста: после начисления процента в банковской выписке отображается правильная, новая сумма.
И, «вишенка на тортике» — ручные тесты. Некоторые виды тестирования не могут быть автоматизированы, допустим, исследовательское тестирование или тестирование юзабилити, но в идеале стоит стремиться минимизировать объем мануальных тестов.
Еще несколько важных принципов, связанных с пирамидой автоматизации:
Избегайте дублирования тестов на разных уровнях. Нет смысла повторять одни и те же тесты на разных уровнях. Например, если граничные значения были проверены на уровне юнит-тестов, не стоит повторять их на уровне GUI — таким образом мы вряд ли получим новую информацию.
В целом, там, где это возможно, стоит стремиться к сдвигу тестов на более низкий уровень. Допустим, проверить вычисление процентов с отрицательной суммы наверняка возможно на «среднем уровне» или даже на уровне юнит-тестов, так зачем делать это на уровне пользовательского интерфейса? Автоматизировать тесты на более низком уровне эффективнее, это позволяет раньше обнаруживать дефекты, экономит время и деньги.
Автоматизированное тестирование программного обеспечения (Software Automation Testing) — это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования.
Специалист по автоматизированному тестированию программного обеспечения (Software Automation Tester) — это технический специалист (тестировщик или разработчик программного обеспечения), обеспечивающий создание, отладку и поддержку работоспособного состояния тест скриптов, тестовых наборов и инструментов для автоматизированного тестирования.
Инструмент для автоматизированного тестирования (Automation Test Tool) — это программное обеспечение, посредством которого специалист по автоматизированному тестированию осуществляет создание, отладку, выполнение и анализ результатов прогона тест скриптов.
Тест Скрипт (Test Script) — это набор инструкций, для автоматической проверки определенной части программного обеспечения.
Тестовый набор (Test Suite) — это комбинация тест скриптов, для проверки определенной части программного обеспечения, объединенной общей функциональностью или целями, преследуемыми запуском данного набора.
Тесты для запуска (Test Run) — это комбинация тест скриптов или тестовых наборов для последующего совместного запуска (последовательного или параллельного, в зависимости от преследуемых целей и возможностей инструмента для автоматизированного тестирования).
Спрашивая: «Что автоматизировать?», необходимо сначала ответить на вопрос: «Целесообразна ли автоматизация тестирования в условиях проекта». Если ответ «ДА», то необходимо, исходя из требований к объекту тестирования, создать план, по которому будут разрабатываться автоматизированные тесты. Создавая подобный документ, вы должны четко представлять, «что автоматизировать?«, «как автоматизировать?« и «чем автоматизировать?«. Не будем вдаваться в подробности, как и чем тестировать ту или иную функцию, просто перечислим места, где, на наш взгляд, нужно применять автоматизацию:- Труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД)
- Часто используемая функциональность, риски от ошибок в которой достаточно высоки. Автоматизировав проверку критической функциональности, можно гарантировать быстрое нахождение ошибок, а значит и быстрое их решение.
- Рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей. Автоматизировать заполнение полей различными данными и их проверку после сохранения)
- Валидационные сообщения (Автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации)
- Длинные end-to-end сценарии
- Проверка данных, требующих точных математических расчетов
- Проверка правильности поиска данных
Для более эффективного использования автоматизации тестирования лучше разработать отдельные тест кейсы проверяющие:
- Базовые операции создания/чтения/изменения/удаления сущностей (так называемые CRUD операции — Create / Read / Update / Delete).
- Типовые сценарии использования приложения, либо отдельные действия.
- Интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную.
Это и есть та функциональность, от автоматизации тестирования которой, можно получить наибольшую отдачу.
Выбор инструмента зачастую зависит от объекта тестирования и требований к тестовым сценариям, т.к. инструменты тестирования не могут поддерживать абсолютно все технологии, используемые при разработке приложений. То есть, выбор инструмента сводится к банальному методу проб и ошибок. В итоге, нередко мы выбираем несколько инструментов для тестирования функций приложения. Например, GUI мы проверяем посредством Mercury WinRunner, бэкенд процессы — используя «java based test tools» или другие инструменты. Основные аспекты выбора инструмента автоматизации тестирования рассмотрены в разделе «Как автоматизировать?«.Рассмотрим инструменты для автоматизированного функционального тестирования от разных производителей:
| Компания | Инструмент |
| Hewlett-Packard (Mercury Interactive) | QuickTest Professional, WinRunner |
| IBM Rational | Rational Robot, Rational Functional Tester |
| Borland (Segue) | SilkTest |
| AutomatedQA Corp | TestComplete |
| Microsoft | Microsoft VS 2005 |
| SeleniumHQ | Selenium |
| Инструмент | Описание |
| Selenium | Selenium is a set of different software tools each with a different approach to supporting test automation of web applications across many platforms. |
| Watij | Watij (pronounced wattage) stands for Web Application Testing in Java. Watij is a pure Java API created to allow for the automation of web applications. Based on the simplicity of Watir and enhanced by the power of Java, Watij automates functional testing of web applications through a real browser. Currently Watij supports automating Internet Explorer on Windows only. Future plans are in place to support others like Mozilla. |
| HtmlUnit | HtmlUnit is a «browser for Java programs». It models HTML documents and provides an API that allows you to invoke pages, fill out forms, click links, etc... just like you do in your «normal» browser. It has fairly good JavaScript support (which is constantly improving) and is able to work even with quite complex AJAX libraries, simulating either Firefox or Internet Explorer depending on the configuration you want to use. It is typically used for testing purposes or to retrieve information from web sites. HtmlUnit is not a generic unit testing framework. It is specifically a way to simulate a browser for testing purposes and is intended to be used within another testing framework such as JUnit or TestNG |
| HttpUnit | Written in Java, HttpUnit emulates the relevant portions of browser behavior, including form submission, JavaScript, basic http authentication, cookies and automatic page redirection, and allows Java test code to examine returned pages either as text, an XML DOM, or containers of forms, tables, and links. When combined with a framework such as JUnit, it is fairly easy to write tests that very quickly verify the functioning of a web site. |
| Jamaleon | Jameleon is an automated testing framework that can be easily used by technical and non-technical users alike. One of the main concepts behind Jameleon is to create a group of keywords or tags that represent different screens of an application. All of the logic required to automate each particular screen can be defined in Java and mapped to these keywords. The keywords can then be organized with different data sets to form test scripts without requiring an in-depth knowledge of how the application works. The test scripts are then used to automate testing and to generate manual test case documentation. |
| Junit | JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. |
| Abbot | Abbot is a simple framework for unit and functional testing of Java GUIs. Facilitates generating user actions and examining component state. Supports recording and playback on any Java application. |
| Marathon | With Marathon you capture user interactions on the applications and also insert assertions to verify that correct processing is taking place. The generated raw script can be re-factored to modules for efficient reuse and maintainability. Replay the scripts either manually or integrate Marathon into your build process for automatic execution of the test suites. |
| Hewlett-Packard (Mercury Interactive) | HP Performance Center (включает HP LoadRunner) |
| IBM Rational | Rational Performance Tester |
| Borland (Segue) | Silk Performer |
| SmartBear | LoadComplete Web Load Testing |
| Neotys | NeoLoad |
- Jmeter - an Apache Jakarta project that can be used as a load testing tool for analyzing and measuring the performance of a variety of services
- Grinder - a load testing framework that makes it easy to run a distributed test using many load injector machines. Test scripts are written in Jython, and HTTP scripts can be recorded easily from a browser session.
Во-вторых, нужно обратить внимание на то сколько времени требуется на поддержку скриптов написанных с помощью выбранного инструмента. Для этого запишите простой скрипт который выбирает пункт меню, а потом представьте, что изменился пункт меню который необходимо выбрать. Если для восстановления работоспособности сценария вам придется перезаписать скрипт целиком, то инструмент не оптимален, так как реальные сценарии гораздо сложнее. Лучше всего тот инструмент, который позволяет вам вынести название кнопки в переменную в начале скрипта и быстро заменить ее значение. В идеале – описать меню как класс.
И последний момент на который нужно обратить внимание – насколько удобен инструмент для написания новых скриптов. Сколько требуется на это времени, насколько можно структурировать код (поддержка ООП), насколько код читаем, насколько удобна среда разработки для рефакторинга (переработки кода) и т.п.
Лучше всего для принятия правильного решения об автоматизации отвечать на вопросы «Зачем? Что? Как?» именно в таком порядке. Это поможет избежать впустую потраченных времени нервов и финансов. С другой стороны вы сможете получить надежность, скорость и качество!!!
Фикстуры - это по сути тестовые данные. Они нужны для unit-тестирования. Это могут быть как данные в базе, так и обычные файлы (обычно 2 варианта, до и после обработки так скажем). Каждый раз когда запускаются тесты, эти данные используются для установления начального состояния системы, что бы тесты всегда выполнялись предсказуемо.
Сеанс-это один вызов pytest, включая все тесты, выполняемые в нескольких каталогах.
Проект содержит два типа файлов init.py: найденные в каталоге src/ и те, которые находятся в tests/. Файл src/tasks/init.py сообщает Python, что каталог является пакетом. Он также выступает в качестве основного интерфейса для пакета, когда кто-то использует import tasks. Он содержит код для импорта определенных функций из api.py, так что cli.py и наши тестовые файлы могут обращаться к функциям пакета, например tasks.add(), вместо того, чтобы выполнять task.api.add (). Файлы tests/func/init.py и tests/unit/init.py пусты. Они указывают pytest подняться вверх на один каталог, чтобы найти корень тестового каталога и pytest.ini-файл.
Файл pytest.ini не является обязательным. Он содержит общую конфигурацию pytest для всего проекта. В вашем проекте должно быть не более одного из них. Он может содержать директивы, которые изменяют поведение pytest, например, настрйки списка параметров, которые всегда будут использоваться
Файл conftest.py также является необязательным. Он считается pytest как «local plugin» и может содержать hook functions и fixtures. Hook functions являются способом вставки кода в часть процесса выполнения pytest для изменения работы pytest. Fixtures — это setup и teardown функции, которые выполняются до и после тестовых функций и могут использоваться для представления ресурсов и данных, используемых тестами.
Использование usefixtures почти то же самое, что указание имени фикстуры в списке параметров метода теста. Единственное отличие состоит в том, что тест может использовать возвращаемое значение фикстуры, только если оно указано в списке параметров. Тест, использующий фикстуру из-за использования usefixtures, не может использовать возвращаемое значение фикстуры.
С параметризованными функциями вы можете запускать эту функцию несколько раз. Но с параметризованными фикстурами каждая тестовая функция, использующая эту фикстуру, будет вызываться несколько раз.
- pytest.ini: Это основной файл конфигурации Pytest, который позволяет вам изменить поведение по умолчанию. Поскольку вы можете внести довольно много изменений в конфигурацию, большая часть этой главы посвящена настройкам, которые вы можете сделать в pytest.ini.
- conftest.py: Это локальный плагин, позволяющий подключать хук-функции и фикстуры для каталога, в котором существует файл conftest.py, и всех его подкаталогов. Файл conftest.py описан в главе 5 «Плагины» на стр. 95.
- __init__.py: При помещении в каждый test-подкаталог этот файл позволяет вам иметь идентичные имена test-файлов в нескольких каталогах test. Мы рассмотрим пример того, что пойдет не так без файлов __init__.py в тестовых каталогах в статье «Избегание коллизий имен файлов» на стр. 120.
После чего выполните в терминале команду:
pip freeze > requirements.txt
Эта команда сохранит все версии пакетов в специальный файл requirements.txt.
Как их оттуда достать? Попробуйте создать новое виртуальное окружение (если нужно, вернитесь в модуль 1 за инструкциями) и активировать. После чего выполните команду:
pip install -r requirements.txt
В свежем окружении все пакеты установлены одной командой!
СЕЛЕКТОРЫ:
https://www.youtube.com/watch?v=_TNh2ydpoOw
Точный
Уникальный
Простой+понятный
Устойчивые к изменениям
Используйте комбинации, отрицания, не искать по тексту, чайлдам
https://github.com/JakUi/stepik-auto-tests-course/blob/master/%D0%A4%D0%B8%D0%BA%D1%81%D1%82%D1%83%D1%80%D1%8B%20%D0%B8%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D1%8B.txt
https://habr.com/ru/company/yandex/blog/242795/
PyTest плагины
https://plugincompat.herokuapp.com/
PyTest документация фул
https://docs.pytest.org/en/latest/contents.html
Всё про всё выше
https://stepik.org/lesson/237258/step/1?unit=209646
Полезные фреймворки
https://stepik.org/lesson/239062/step/1?unit=211485
Всё по xpath https://stepik.org/lesson/102555/step/10?unit=196193
CSS-селекторы:
https://developer.mozilla.org/ru/docs/Web/CSS/CSS_%D0%A1%D0%B5%D0%BB%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D1%8B
https://www.w3schools.com/cssref/css_selectors.asp
Селениум
https://habr.com/ru/post/250975/
https://selenium-python.readthedocs.io/locating-elements.html#locating-hyperlinks-by-link-text
html атрибуты
https://www.w3schools.com/tags/ref_attributes.asp
Чего еще можно ждать, пока не кликнет
https://selenium-python.readthedocs.io/api.html#module-selenium.webdriver.support.expected_conditions
Общее полезные ресурсы
https://stepik.org/lesson/171979/step/1?unit=146657
Всё про QA
https://dou.ua/lenta/articles/qa-engineer-position/
https://dou.ua/lenta/articles/qa-automation-engineer-position/
Всё про GIT
https://stepik.org/lesson/187065/step/12?unit=161976
- Git и GitHub — системы управления исходным кодом;
- Jenkins — сервер автоматизации для создания конвейеров CI/CD;
- Docker — ПО для автоматизации деплоя и управления приложениями в средах с поддержкой контейнеризации;
- Kubernetes — открытая система оркестрации контейнеров;
- Chef, Puppet и Ansible — средства для автоматического конфигурирования и развертывания;
- Selenium — решение для автоматизации тестирования;
- Prometheus и Nagios — программы для мониторинга серверов;
- Grafana — решение для сбора и анализа метрик.
https://habr.com/ru/company/vdsina/blog/494762/ 50 инструментов для удаленки
- Asana — для управления проектами. Настроена интеграция с Jenkins.
- Google Meet — для проведения видеовстреч.
- Slack — для коммуникаций и различных оповещений, включая нотификации из Jenkins.
- Atlassian Confluence — для документирования и групповой работы.
Доверие – короткие атомарные тесты, моки
Контроль – grafana
Первый уровень — это выбрать на чём писать, это Java, .NET, JS? Я больше с Java работала, про неё и буду говорить. Собственно, на чём построить проект — Java. Собрать его можно с помощью Maven или Gradle. Сейчас у Maven прикольные в YAML формате описания pom-ника есть, с ним удобно работать.
Дальше, выбрать чем эти тесты запускать — это JUnit или TestNG какие-нибудь. Я с JUnit 5 в последнее время работаю.
Потом выбрать уровень взаимодействия с элементами. Это Selenium, либо обёртка над ним какая-нибудь, например, Selenide. С ним можно скоратить время на написание тестов.
Дальше нужно проверять результаты тестов. Здесь очень большой выбор инструментов. Можно из JUnit 5 использовать те же самые Assertions, они сейчас в нём довольно удобно сделаны. Либо библиотека Hamcrest, мне она очень нравится. Либо AssertJ тоже удобная вещь. Когда для запуска тестов выбираете этот раннер, то нужно подумать о параллельности запуска тестов, как её будет лучше организовать. В JUnit 5 это удобно, там аннотация просто делается.
Потом уже само написание тестов, это может быть какая-нибудь BDD обёртка, тот же Cucumber. Если выбираете JUnit, то к нему ещё дополнительные вещи потребуются.
Плюс инфраструктура. Я в последнее время с Selenoid работала, мне с ним удобнее всего было.
Ещё отчёты.
— Ну отчёты это, конечно, Allure?
Аня: Ну или ReportPortal. Я могу объяснить, когда лучше Allure, когда лучше ReportPortal. Allure хорошо, когда маленький проект, тогда он идеально вообще заходит. Если это какой-нибудь большой проект, где 100500 тысяч тестов или это энтерпрайзное решение, или есть понимание, что тестов должно быть очень много и они должны все в какой-нибудь отчёт складываться, то тогда хорош ReportPortal, там удобнее обрабатывать результаты именно большого количества тестов. Когда тестов немного, тогда Allure удобнее.
Есть тот самый Selenium обычный старый, Selenium или Selenium Grid, или Selenium Server — это приложение, написанное на Java, которое самое старое и самое простое с точки зрения фич. Года три назад от Selenium стандартного, от Selenium Grid отпочковался проект Zalenium. Он уже умеет запускать браузеры в Docker-контейнерах. Этот проект реализует полностью весь стандарт, поддерживает возможность видеозаписи, возможность хранения логов, имеет интерфейс лучше, чем у стандартного Selenium.
Мы же сделали с нуля проект под названием Selenoid. Это тоже совершенно независимая реализация Selenium-протокола. Она написана на Go, не требуется установки Java, ничего не нужно, просто в бинарнике запускается и нужен Docker.
Кроме опенсорса мы делаем реализацию для Kubernetes, это Moon. Это тоже совершенно независимая реализация, которая нужна, если у вас есть Kubernetes. Мы делали упор на то, чтобы развернуть инфраструктуру было просто легко с помощью пары команд. Людям это нравится, что ты две команды ввел и у тебя уже всё работает.
Ещё для Selenium есть всякие онлайн-платформы, если не хочется самому Selenium разворачивать. Можно пойти в облачные сервисы Они достаточно дорогие, но тем не менее они есть, пользуются довольно большой популярностью.
Аня: У меня был опыт с SauceLabs, там тоже довольно удобно всё. Просто указываешь в каком браузере запустить, они даже мобильное тестирование поддерживают. И запускаешь. Но они дорого стоят.
— Как, с точки зрения кроссбраузерности и мобилок, работает Selenium, и есть ли какие-то проблемы с инфраструктурой с этим? Я знаю, что некоторые тестируют определенные браузеры на мобилках. К счастью, не тестировал это руками в Selenium, не знаю, насколько это сложно всё настраивать.
Ваня: Это геморно и достаточно дорого. Цель — протестировать, что если мы откроем на каком-то телефоне наше приложение, в каком-нибудь мобильном Chrome, у нас всё работает точно так же. Естественно, мы хотим, как и в случае настольных браузеров, делать это кодом.
Первоначальная простая идея состоит в том, чтобы накупить телефонов разных моделей, положить их на стол. Есть готовые инструменты, например, Appium, которые реализуют стандарт Selenium. Это тоже реализация Selenium-расширения, которая позволяет работать как раз с мобильными. Изначально это делалось как раз под ферму реальных телефонов и планшетов. Проблема в том, что просто опыт эксплуатации таких ферм телефонов показывает, что это очень дорого. Это постоянно ломается, нужно эти телефоны заменять, у них распухают батарейки, это требует довольно специальных систем, которые заряжают эти телефоны, туда нужно ставить обновления, следить, чтобы там ничего не разломалось.
Сейчас всё потихонечку двигается в сторону того, чтобы запускать это всё в эмуляторах. Существуют специальные программы — эмуляторы, которые показывают на экране обычного компьютера или сервера ровно то же самое, что видит пользователь на своём телефоне или планшете. Существуют эмуляторы для Android и для iOS. Проблема заключается в том, что, с точки зрения Android, это виртуалки, такие эмуляторы нельзя запустить на абы каком железе. Если вы хотите Android эмуляторы, вам нужно брать железные сервера, это дорого.
Если вы хотите тестировать на эмуляторах под iOS, вам нужно брать эппловское железо, то есть MacMini, MacPro, MacBook или что-то подобное, это тоже дорого. Это связано с лицензионными ограничениями компании Apple. Поэтому тестирования на мобильных в принципе возможно, понятно как делать инфраструктуру. Даже в Docker можно запускать Android, но это достаточно дорого. Если люди хотят такое делать, им нужно сильно подумать. Основная задача тестирования на мобильных — найти баги, которые воспроизводятся только на мобильных. Существуют разные способы сделать это дешевле. Есть возможность запускать настольные браузеры вроде Chrome, в котором подсовывается юзер-агент, подсовывается нужное разрешение экрана. Решение о том, нужно ли тестировать на настоящих эмуляторах, на телефонах, нужно принимать исходя из того, можете ли вы отловить баги только на эмуляторе или на телефоне. — Кстати, есть разные инструменты вроде Puppeteer, Playwright, которые позволяют достаточно точно эмулировать и делать кроссбраузерное тестирование в т.ч. в мобильных браузерах. Может на них уже давно все пересели или пересаживаются?
Ваня: Фронтендеры, больше никто не пересел.
Аня: Это клёвые штуки, но у них есть ограничения в плане кроссбраузерности. У Cypress для Firefox вроде выйдет обновление скоро. Ты можешь очень круто быстро писать тесты, всё удобно, но ты ограничен только Chromium-ом.
Ваня: Начнем с Cypress. В 2004-2005 году Selenium работал следующим образом.
Запускался браузер, в него загружалось специальное расширение, в которое запихивались команды по автоматизации браузера. Через 15 лет появились ребята, которые посмотрели на это. От этого подхода в Selenium отказались, потому что не всё можно делать при помощи расширения. Поскольку Javascript, то выполнять можно не всё в браузере, нельзя обращаться к файлам на файловой системе. В Selenium перешли на нативный подход, стали писать отдельные бинари, отдельно стоящие от браузера. Прошло 15 лет. Ребята на JavaScript сделали похожим образом инструмент.
Puppeteer ровно то же самое. Puppeteer это Google Chrome, Chromium, в котором реализован специальный протокол для работы с этой отладочной панели. В Chrome есть отладочная панель, чтобы там можно было сообщения в консоли смотреть, сетевые запросы и так далее.
— Developer tools очень крутая, конечно.
Ваня: Да-да, для разработчика удобная. Как выяснилось, эта штука взаимодействует с браузером по специальному протоколу. Основная идея заключается в том, чтобы в этот протокол не руками мышкой кликать, а чтобы можно было точно так же, как в Selenium, команды слать кодом. Ребята просто написали Javascript-библиотеку, которая реализует протокол.
Аня: Эти инструменты, мне кажется, могут хорошо подходить для компонентного тестирования, которое бы сами фронтендеры и покрывали. Я знаю такие кейсы применения, они прямо очень хорошо заходили.
Популярные системы управления тестированием
Зачем она нужна? Решить задачу создания единой системы для работы со всей документацией проекта можно несколькими способами:
- Самый дешёвый способ — не заморачиваться и выбрать Google Docs для матрицы трассируемости, а дефекты вести в open-source баг-трекере.
- Другой способ — использовать одну из популярных TMS'ок, интегрированную с баг-трекером компании.
- Next-level способ — выбрать Test Management System, исходя из специфики проектов, объемов задач, типов документации и используемых видов тестирования.
- Test Link
- Test IT
- Zephyr
- qTest
- PractiTest
- TestLodge
- TestRail
- Qase
- Tematoo
- Test Collab
- HP ALM
- Testuff
- XQual
Для отслеживания прогресса проекта доступны отчёты и диаграммы, а дополнительные функции включают тэгирование ключевыми словами, указание требований и журнал событий. Код проекта часто обновляется и дополняется.
Возможности:
- Управление требованиями
- Спецификация — определение тест кейсов путём группировки в разные наборы тестов
- Назначение выполнения тест сьютов на уровне сборки
- Централизованное управление пользователями и ролями
- Кастомизация настраиваемых пользователем полей
2. Test IT
Test IT — TMS, которую создают тестировщики для тестировщиков. Этот инструмент отличает продуманный и понятный интерфейс. Внутри системы можно создавать проекты и вести для каждого структурированную библиотеку тестовых случаев и чек-листов, часто повторяющиеся операции выделяются в общие шаги. Инструмент гибкий — в каждом проекте создаются дополнительные пользовательские атрибуты, распределяются роли и права, что упрощает настройку TMS под процессы вашей компании. Test IT помогает руководителям групп тестирования равномерно распределять нагрузку между тестировщиками и контролировать исполнение работ с помощью пользовательских запросов и отчётов.
Разработчики приложения уделяют большое внимание автоматизированному тестированию, каждый тестовый случай в библиотеке тестов можно интегрировать с автотестами по API. Правильно настроенная интеграция с автотестами позволяет следить за прогонами и их результатами прямо из TMS в режиме реального времени. Вы сможете видеть какие автоматические тесты в процессе выполнения, анализировать их результаты и просматривать исходный код прямо из Test IT.
Приложение активно развивается, в ближайшем будущем заявлено много полезных фич.
Возможности:
- Управление тест-планами, тест-кейсами и чек-листами
- Общие шаги для повторяющихся действий
- Автоматическое распределение тестов на QA инженеров
- Интеграция автоматических тестов с помощью API
- Аналитика как по автоматическим, так и по ручным тестам
- Ролевая модель и персонализация
- Геймификация
- Двусторонняя интеграция с JIRA
- Импорт из других систем управления тестированием
Zephyr — это плагин для всем известной JIRA, который интегрирует тестирование в проектный цикл, позволяя вам отслеживать качество программного обеспечения и принимать решения в стиле go / no-go. Тест кейсы могут создаваться, выполняться и трекаться так же, как и любые другие задачи в JIRA. Для более оптимальной фиксации процесса тестирования есть интеграция с инструментами управления качеством, автоматизации, непрерывной интеграции и аналитики. Кроме того, у продукта быстро отвечающая тех поддержка.
Возможности:
- Ссылка на user stories, задачи, требования, дефекты
- Конфигурации деплоя: в облаке, на сервере, в дата-центре
- Расширенная информация на дашбордах аналитики и DevOps
- Интеграция с JIRA, Confluence, Selenium, Jenkins и Bamboo
4. qTest
Инструмент полезный не только тестировщикам, но и всей команде. Интерфейс qTest нативно понятен, мануалы просты в освоении. Это позволяет быстро и эффективно создавать, организовывать и управлять тест кейсами.
Разработчики нескромно заявляют, что их инструмент управления тестами №1 Согласно анализу рынка, qTest является одним из самых быстрорастущих решений для управления тестированием среди команд Agile Development.
Возможности:
- Планирование тестов
- Создание и управление требованиями
- Интуитивный drag-n-drop интерфейс
- Комплексная матрица трассируемости
- Наглядные отчёты с подробными графиками
- Интеграция со сторонними инструментами баг-трекинга
- Детальный контроль доступа пользователей
- Облачный инструмент интеграции с JIRA
5. PractiTest
PractiTest — это комплексное средство управления тестами. Оно обеспечивает полную наглядность процесса тестирования и более глубокое понимание результатов тестирования. Этот инструмент поможет организовать тест сьюты в соответствии с вашими циклами и спринтами. Тестовые наборы можно формировать по различным критериям, таким как компоненты, версии или типы. Тул заточен на Agile тестирование, регрессионное тестирование, тестирование микросервисов и DevOps.
А в тех поддержке работают обученные QA сотрудники, которые могут быстро понять вашу проблему.
Возможности:
- Лёгкое добавление тестов новых фич в регрессионное тестирование
- Группировка тестов на основе микросервисов, которые они охватывают, даже кросс-сервисные
- Различное отображение информации для разных групп пользователей
- Дашборды в реальном времени показывают состояние тестов, прогонов на этапах разработки и при деплое на продакшн
- Интеграция с JIRA, Redmine, Jenkins, GitLab и Slack
6. TestLodge В нём есть самый необходимый минимум, который требуется для управления тестированием: тест планы, требования, тест кейсы и сьюты, и тестовые прогоны. Тул можно интегрировать с существующими баг-трекерами, что позволяет автоматически создавать отчёты о дефектах и заводить задачи.
Возможности:
- Базовый набор создания, редактирования тест плана и тест сьютов
- Нативный интерфейс
- Интеграция с JIRA, Redmine, Trello, Asana, GitHub и YouTrack
7. TestRail
Это программное обеспечение удобно как для команд QA, так и для разработки. План тестирования можно выстроить как по сценарию гибкой методологии, так и для более традиционного подхода. Инструмент позволяет получить представление о ходе тестирования в реальном времени.
Возможности:
- Отслеживание состояния и результатов отдельного теста
- Сравнение результатов нескольких тестов, конфигураций и этапов
- Отслеживание рабочей нагрузки команды для корректировки задач и ресурсов
- Развёрнутые отчёты и метрики
- Широкие возможности настройки, облачные или локальные варианты установки
- Интеграция с JIRA, Redmine, YouTrack, GitHub, Jenkins, Selenium и Visual Studio
- Удобный REST API
8. Qase
Qase это недавно появившийся продукт, который можно нормально использовать в работе. Облачная TMS, которая поможет вашей команде повысить производительность и организовать удобный флоу тестирования программного обеспечения.
Возможности:
- Тестовый репозиторий: выстраивание тестов в логические группы
- Составление шагов для кейсов, установка приоритета и серьёзности
- Запуск тестовых прогоны с трекингом времени по каждому тест кейсу
- Хранение документации по проекту
- Автоматическое заведение дефектов в интегрированные трекеры
- Интеграция с JIRA, Redmine, YouTrack и Slack
- Объединение результатов автотестов с REST API
9. Tematoo
Эта облачная TMS от TestLink не так разрекламирована, но не уступает по своей функциональности более дорогим аналогам. Инструмент предоставляет лаконичную инфраструктуру, позволяя быстро приступить к тестированию продукта. А бесплатный план поддержки небольших команд позволяет проводить пилотные реализации проекта бесплатно. Tematoo может быть интегрирован со многими баг-трекерами, даже облачными.
Возможности:
- Формирование тест сьютов по билдам и типам
- Описание тест кейса по шагам, с возможностью прикрепить скриншот
- Статус отдельных тестов, наборов и общий статус сборки
- Аналитические отчёты и общий метрики по тест плану
- Для платного плана: свой баг-трекер
10. Test Collab
Это сервис с полезным набором функций, который необходим для быстрого старта использования инструмента. Плюс, немного приятных бонусов: удобный интерфейс, кастомизация фильтров и полей, time-трекер для каждого члена команды, и внутрисистемное общение.
Test Collab можно настроить в облаке или в вашей инфраструктуре, тут всё достаточно гибко.
Возможности:
- Группировка тест кейсов по этапам или билдам
- Управление требованиями
- Переиспользование тестов
- Настройка спринтов
- Отчёты по результатам тестов
- Комментирование тест кейсов
- Интеграция с JIRA, Redmine, Bugzilla, Asana, Trello, YouTrack, GitHub
11. HP ALM
HP ALM — долгожитель среди систем управления жизненным циклом продукта, и его тестировании в том числе. Инструмент позволяет осуществлять планирование, создание, тестирование и контроль на всех этапах разработки. Сложен в первоначальном освоении, но незаменим для компании крупной руки, где особое внимание уделяется деталям производства. Именно потому что продукт уже обкатан, в интернете есть большое множество мануалов и видеогайдов по настройке и использованию.
Возможности:
- Общий доступ к библиотекам требований и ресурсов
- Подробные сведения о коде, тестировании, управлении рисками и их оценке, а также о соответствии требованиям
- Быстрый доступ к показателям, например к данным о неустранённых дефектах
- Быстрая настройка лабораторной среды для устранения ошибок конфигурации в средах Agile
- Создание требований и отслеживание их выполнения на всех этапах жизненного цикла приложения
- Аналитика на любой вкус и цвет: гибко настраиваемые отчёты
- Интеграция с 50+ инструментами
12. Testuff
Testuff — это мощная веб-платформа управления тестированием, которая позволяет легко проектировать, выполнять и управлять неограниченным количеством тестов. Тул можно настроить под любой формат тестирования: от популярной гибкой методологии и TDD, до White-Box или Black-Box; Top-Down или Bottom-Up.
Здесь есть и оптимизированная очередь управления задачами для каждого тестировщика с применением тайм-менеджмента. И организация тестов по проектам, веткам кода и типичным тестовым наборам. Помимо бонуса экспорта в HTML/Excel, есть маленькие плюшки в виде встроенного тула создания скриншотов и видео с отображением указателя и нажимаемых клавиш.
Возможности:
- Два доступных клиента — Web и Desktop
- Планирование цикла тестирования с использованием нескольких тестовых окружений
- Разграничение по ролям пользователей
- Встроенный захват экрана в виде скриншота или видео
- Подключение результатов автоматизированных тестов по API
- Интеграция с JIRA, Trello, Redmine, Bugzilla, YouTrack, Selenium, GitHub, Visual Studio
13. XQual
XStudio от XQual осчастливит продвинутого тестировщика, который хочет подвергнуть свой продукт максимальному количеству испытаний. С помощью этого инструмента можно управлять не только своими релизами, требованиями, рисками, спецификациями, тестами, кампаниями и багами. Он может быть интегрирован со всеми платформами непрерывной интеграции и может выполнять любой вид тестирования.
Возможности:
- Расширенная настройка шагов тест кейса
- Переиспользование тестов
- Матрица трассируемости
- Настройка тестовой лаборатории: hardware, software, тестовое окружение
- Продвинутое логирование действий (даже удалённых тестов)
- Настраиваемая аналитика
- Встроенный захват экрана
- Интеграция с JIRA, Redmine, MySQL, Oracle, Apache, Skype
- Интеграция с 5 различными интерфейсами для ручного тестирования
- Интеграция с почти 70 тулами автоматизации: Selenium, QTP / UFT, JMeter, Ranorex, TestComplete, JUnit, NUnit, TestPartner, Sahi, NeoLoad, QF-Test, RobotFramework, Sikuli, SoapUi, Squish, TestNg, TestOptimal и многие другие
Charles — инструмент для мониторинга HTTP/HTTPS трафика. Программа работает как прокси-сервер между мобильным приложением (в нашем случае) и сервером этого приложения. Charles записывает и сохраняет все запросы, которые проходят через подключенный к нему телефон и позволяет их редактировать.
Чтобы редактировать выдачу сервера и воспроизводить сложные тестовые сценарии в QA Redmadrobot, мы используем Charles.
Charles является незаменимым инструментом в арсенале QA-инженеров Redmadrobot. С его помощью можно создавать любые необходимые тестовые данные, как реальные, так и невозможные (если верить API-спецификациям). Такие возможности расширяют границы тестирования черного ящика и позволяют наблюдать все основные взаимодействия вашего МП и его серверов. Тестирование на таком уровне позволяет находить более сложные дефекты и значительно повышает общее качество приложения.
https://habr.com/ru/company/redmadrobot/blog/269109/
Софт такого рода — отличная вещь для дебага веб-запросов. Но Charles — не мой выбор. Мне больше понравился бесплатный аналог Fiddler.
Работал с ним хоть и не очень долго, но в нем есть все что нужно — есть те же фильтры, можно подменять ответы, поддерживает HTTPS, может перехватить запрос и ответить на него, не обращаясь к реальному серверу. На Linux работает под Mono, но с периодическими вылетами и мелкими глюками.
Redis (от англ. remote dictionary server) — резидентная система управления базами данных класса NoSQL с открытым исходным кодом, работающая со структурами данных типа «ключ — значение». Используется как для баз данных, так и для реализации кэшей, брокеров сообщений[en].
Ориентирована на достижение максимальной производительности на атомарных операциях (заявляется о приблизительно 100 тыс. SET- и GET-запросов в секунду на Linux-сервере начального уровня[5]). Написана на Си, интерфейсы доступа созданы для большинства основных языков программирования.
RabbitMQ — диспетчер обмена сообщениями между приложениями
Zabbix — свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования, написанная Вадимом Зубовичем (динозавр).
Для хранения данных используется MySQL, PostgreSQL, SQLite или Oracle Database, веб-интерфейс написан на PHP. Поддерживает несколько видов мониторинга:
- Simple checks — может проверять доступность и реакцию стандартных сервисов, таких как SMTP или HTTP, без установки какого-либо программного обеспечения на наблюдаемом хосте.
- Zabbix agent — может быть установлен на UNIX-подобных или Windows-хостах для получения данных о нагрузке процессора, использования сети, дисковом пространстве и так далее.
- External check — выполнение внешних программ, также поддерживается мониторинг через SNMP.
И так, встречайте: Zabbix. Система состоит из нескольких частей, и при большой нагрузке и наблюдении за очень большим количеством хостов позволяет разнести эти части на несколько раздельных машин.
Zabbix состоит из
- собственно сервера мониторинга, который выполняет периодическое получение данных, обработку, анализ и запуск скриптов оповещения
- базы данных (MySQL, PostgreSQL, SQLite или Oracle)
- веб-интерфейса на PHP
- агента — демона, который запускается на отслеживаемых объектах и предоставляет данные серверу. Агент опционален, мониторинг можно производить не только с помощью него, но и по SNMP (версий 1, 2, 3), запуском внешних скриптов, выдающих данные, и несколько видов предопределенных встроенных проверок, таких как ping, запрос по http, ssh, ftp и другим протоколам, а так же замер времени ответа этих сервисов.
Redmine [ɹɛdˈmɑɪn] — открытое серверное веб-приложение для управления проектами и задачами (в том числе для отслеживания ошибок).
Confluence — тиражируемая вики-система для внутреннего использования организациями с целью создания единой базы знаний. Написана на Java. Разрабатывается Atlassian.
Selenoid – это сервер, запускающий изолированные браузеры в Docker контейнерах.
Преимущества использования Selenoid:
- Единая среда для параллельного запуска автотестов
- Изолированное окружение: каждый браузер запускается в отдельном контейнере, что позволяет полностью изолировать окружение нашего браузера
- Масштабируемость: окружение никак не влияет на качественное и непрерывное проведение тестов
- Потребление и утилизация ресурсов: Selenoid позволяет поддерживать высокую нагрузку без дополнительных ресурсозатрат; кроме того, он утилизирует все неактивные контейнеры после завершения самой его сессии, тем самым постоянно поддерживая нужно количество свободной памяти
- Установка: не занимает много времени и осуществляется, по сути, при помощи одной команды
- Одновременная поддержка нескольких версий одного браузера: данная опция доступна только у Selenoid, для этого необходимо создать несколько контейнеров с необходимыми браузерами
- Фокус: операционная система работает таким образом, что в фокусе может быть только одно окно. При запуске нескольких браузеров на одной машине, окна могут начать конкурировать за фокус. У Selenoid такой проблемы нет, поскольку каждый тест запускается в отдельном контейнере
- Пользовательский интерфейс и логи: Selenoid позволяет быстро получить доступ к имеющимся журналам. Помимо этого есть возможность интеграции с ELK стэком для более быстрого сбора и анализа текущих файлов.
- Хранение данных в оперативной памяти: в Selenoid все временные памяти хранятся в Tmpfs – временном файловом хранилище, которое позволяет хранить файлы в оперативной памяти. Доступ к ОЗУ, как известно, осуществляется намного быстрее, чем к файловой системе жесткого диска.
- Selenoid позволяет использовать различное разрешение экрана: мы самостоятельно можем настраивать подходящее разрешение экрана для запущенного контейнера. Сделать это можно посредством выставления необходимых параметров в настройках компонента Browser Capabilities.
- Видеозапись тестов: активация записи в Selenoid на примере браузера Google Chrome происходит за счет выставления параметра true в соответствующую настройку компонента Browser Capabilities:
ChromeOptions options = new ChromeOptions(); options.setCapability(«enableVideo»,true);
- Автоматическое решение большинства проблем с Ajax, ожиданиями и таймаутами
- Управление жизнедеятельностью браузера
- Автоматическое создание скриншотов
Selenide — достаточно популярный инструмент, для которого есть много готовых решений. Часть возможностей Selenide доступна и у аналогов — Atlas, Selenium, HTMLElements и т.п. Но каждый из них по-своему нам не подходил.
Selenium лежит в основе Selenide. Но для наших целей он слишком низкоуровневый. Нет смысла изобретать велосипед, когда есть готовое решение.
Atlas появился совсем недавно. Он достаточно сырой и не имеет поддержки Groovy. HtmlElements всем хорош, но устарел и не поддерживается. Есть еще JDI, но в нем возникли проблемы с многопоточностью.
Serenity, ранее использовавшийся на проекте, был слишком громоздким. В нем все настолько взаимосвязано, что для добавления какого-то нового обработчика или перехватчика событий приходилось переписывать десяток классов (и это не каждый раз приводило к успеху). Плюс к Serenity не получалось подключить Allure — фактический отраслевой и внутрикорпоративный стандарт для генерации тестовых отчетов.
В Selenide с точки зрения автоматизатора все гораздо проще. Например, нет необходимости отдельно описывать шаги — привязываться к методам и т.п. Поскольку у него есть поддержка Allure из коробки, в тестовый отчет автоматически попадают все действия по работе с веб-элементами.
Разумеется, у Selenide есть поддержка PageFactory, Page Object и PageElement. Это делает код более читаемым. Плюс предусмотрены внутренние ожидания того момента, когда элемент появится, — нет необходимости явно прописывать, что нужно остановить тест на несколько секунд, прежде чем идти дальше (предельное время ожидания устанавливается в конфигах). Отдельно существуют и явные ожидания — можно на каждом тестовом шаге явно переопределить таймаут для нужных элементов.
Удобно, что у Selenide есть целый набор всевозможных готовых методов.
Чем можно заменить Selenium Grid? Достойным вариантом является Selenoid – инструмент, с помощью которого можно быстрее и проще запускать браузеры в Docker-контейнерах. Процесс отличается от аналогичного в Selenium.
Для каждого запроса нового браузера Selenoid запускает новый контейнер и останавливает его после закрытия сессии.
В каждом контейнере находится определенная версия браузера, нужная версия веб-драйвера или Selenium-сервера и все необходимые зависимости (например, графические библиотеки). При этом благодаря изоляции процессов, можно запускать любое количество разных версий браузеров одновременно.
- Изолированное окружение
При использовании Selenium Grid существует вероятность, что настройки браузера могут быть изменены.
- Масштабируемость
В Selenoid окружение никак не влияет на качественное и непрерывное проведение тестов.
- Потребление и утилизация ресурсов
Selenoid позволяет поддерживать высокую нагрузку без дополнительных ресурсозатрат.
В среднем при десяти запущенных сессиях Selenium Server на Java потребляет 500 МБ оперативной памяти, в то время как Selenoid – всего 50–60 МБ.
Кроме того, Selenoid утилизирует все неактивные контейнеры после завершения сессии, тем самым постоянно поддерживая нужное количество свободной памяти.
- Selenoid гораздо проще и быстрее устанавливается, чем Selenium Server.
- С ним удобнее управлять браузерами.
- На порядок более легкое масштабирование количества параллельных автотестов.
- Имеет очень удобный UI и логирование.
- Имеет дополнительные фишки, например, очереди. Если у вас на хост пришло слишком много автотестов одновременно, и хост не может их переработать, то Selenoid ставит их в очередь. И будет их пропускать по очереди, как только какие-то тесты уже завершатся.
- Мы можем изменять конфигурации Selenoid на «горячую». Нам не нужно для этого останавливать хосты с Selenoid, мы просто правим JSON и там специальной командой Selenoid перезапускается, и не прерывая активных сессий он уже готов поставлять по запросу новые необходимые браузеры.
- По умолчанию используются образы разработчиков Selenoid, но вы можете использовать готовые образы. Есть официальные образы от Selenium с браузерами. Или вы можете создать свой образ, если по политике безопасности вам не разрешают лезть в общедоступные репозитории. Внутри образа у вас должен быть браузер с WebDriver. Должен быть установлен X-сервер, чтобы браузер при запуске думал, что он запущен на реальном экране.
- Поддержка централизованного логирования. Selenoid позволяет не просто смотреть отдельные логи браузера. У него есть специальный адрес в строке. Если туда обращаться, то он возвращает JSON с подобной статистикой того, что сейчас происходит на хосте. Это очень удобно применять для живого анализа того, что происходит. Можно подключить graphite, Grafana. И очень легко получать статистику, и выводить на больших экранах, и показывать текущую ситуацию. Например, отслеживать перезагрузку какого-нибудь хоста или какие-то аномалии.
- И очень удобная штука – это задание разрешения экрана прямо через код автотестов, т. е. не разрешение самого браузера, с каким он отроется, а именно экрана, чтобы тестировать в том числе мобильные устройства. А именно, когда вы делаете узкий экран, эмулируете экран мобильника, тоже можно запускать и дополнительно проверять тесты.
- И новая фича появилась недавно, буквально неделю назад. Это встроенная видеозапись тестов, т. е. подгружается специальный контейнер по умолчанию, который по VNC, если вы включили capability специальный, он в одно место складывает видеозапись прохождения автотестов. Но нужно понимать, что это очень грузит хост и нужно использовать только в режимах отладки, потому что по умолчанию Selenoid запускается без поддержки VNC и поддержки видеозаписи, чтобы максимально утилизировать доступные ресурсы для более стабильного запуска автотестов и прохождения.
- Я пришел к тому, что если у вас больше 5 автоматизаторов, то надо внедрять Selenoid. Это реально вам поможет, тем более, что порог входа очень маленький. И ничего не мешает это сделать. И даже если вы один работаете, то большое количество запусков параллельных тестов позволяет вам в тестировании внедрить параметризацию. Например, раньше вы не могли себе позволить использовать случайные значения для автотестов или граничные значения проверять. А теперь, если у вас большое количество одновременных сессий, вы можете очень легко параметризацию проверять.
- Очень просто мигрировать. Он виден как обычный Selenium Hub. И ничего не нужно менять в коде. Если вам нужны дополнительные возможности, то вы просто capabilities добавляете.
- Экономит время, ресурсы и нервы. Это очень важно. У нас работа вредная, а молоко не дают.
- Бесплатный + низкая стоимость владения. Т. е. он требует мало ресурсов на обслуживание. А почему бесплатный? Потому что ребята его сделали сначала для Яндекса, но потом поняли, что инструмент получился хороший и в то же время им ресурсов не хватает для его тестирования, потому что появляются новые браузеры, новые веб-драйверы. И на этом стыке появляются какие-то баги, которые даже в масштабах Яндекса трудно заметить.
- Они выложили все это в открытый доступ, чтобы увеличить аудиторию, которая растет с каждым днем. Например, Саймон рассказывал про zalenium вчера, т. е. это Selenium в Docker. У него в репозитории в Docker 150 000 скачиваний. А у Selenoid уже 300 000 скачиваний. Можно сказать, что реальных внедрений уже где-то 1 000. И это действительно так, у них есть Telegram-канал свой. И я заметил, что в последние несколько месяцев там все больше коллег из Индии появляется, которые очень активно используют Selenoid в реальном применении. И ребята уже столкнулись с тем, что появляются не совсем адекватные запросы. Но они стараются продукт делать простым и мощным. Неадекватные запросы не реализуются, чтобы стабильность была в первую очередь.
https://www.youtube.com/watch?v=vaEHDkDcPTo&list=LLlZaXx9Cfc-at7iDWEn8_RQ&index=83&t=0s
https://www.youtube.com/watch?v=hGmJMeE_ok0&list=LLlZaXx9Cfc-at7iDWEn8_RQ&index=89&t=0s
Simplify API development for users, teams, and enterprises with the Swagger open source and professional toolset. Find out how Swagger can help you design and document your APIs at scale. Swagger UI — один из самых популярных инструментов для создания интерактивной документации. Swagger UI создает интерактивную консоль API для экспериментов с запросами в реальном времени.
Newman is a command-line collection runner for Postman. It allows you to effortlessly run and test a Postman collection directly from the command-line. It is built with extensibility in mind so that you can easily integrate it with your continuous integration servers and build systems. Newman — это сборщик команд в командной строке для Postman. Это позволяет вам легко запускать и тестировать коллекцию Postman непосредственно из командной строки. Он построен с учетом расширяемости, поэтому вы можете легко интегрировать его с вашими серверами непрерывной интеграции и системами сборки.
Стэк ELK (Elasticsearch+Logstash+Kibana)
Как правило Kibana используется для мониторинга и анализа ИТ-инфраструктуры в составе Elastic Stack (ранее ELK Stack), в который помимо нее входят Elasticsearch и Logstash. Logstash отвечает за логирование и поставляет входящий поток данных в Elasticsearch для хранения, классификации и поиска. Kibana, в свою очередь, получает доступ к данным Elasticsearch для их визуализации в различных визуальных форматах, например – в виде информационных панелей (dashboards) с различными видами диаграмм.
Clumsy целенаправленно ухудшает условия, в которых работает Ваше сетевое соединение в Windows
JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures.
Burp Suite – это платформа для проведения аудита безопасности веб-приложений. Содержит инструменты для составления карты веб-приложения, поиска файлов и папок, модификации запросов, фаззинга, подбора паролей и многое другое. Также существует магазин дополнений BApp store, содержащий дополнительные расширения, увеличивающие функционал приложения.
Burp Suite — это интегрированная платформа, предназначенная для проведения аудита веб-приложения, как в ручном, так и в автоматических режимах. Содержит интуитивно понятный интерфейс со специально спроектированными табами, позволяющими улучшить и ускорить процесс атаки. Сам инструмент представляет из себя проксирующий механизм, перехватывающий и обрабатывающий все поступающие от браузера запросы. Имеется возможность установки сертификата burp для анализа https соединений.
Если посмотреть статистику и репорты bug-bounty программ — практически везде на скриншотах можно встретить использование этого инструмента. На ряду с OWASP ZAP это самый популярный набор утилит для тестирования веб-приложений.
- Full support for MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB, Informix, MariaDB, MemSQL, TiDB, CockroachDB, HSQLDB, H2, MonetDB, Apache Derby, Amazon Redshift, Vertica, Mckoi, Presto, Altibase, MimerSQL, CrateDB, Greenplum, Drizzle, Apache Ignite, Cubrid, InterSystems Cache, IRIS, eXtremeDB and FrontBase database management systems.
- Full support for six SQL injection techniques: boolean-based blind, time-based blind, error-based, UNION query-based, stacked queries and out-of-band.
- Support to directly connect to the database without passing via a SQL injection, by providing DBMS credentials, IP address, port and database name.
- Support to enumerate users, password hashes, privileges, roles, databases, tables and columns.
- Automatic recognition of password hash formats and support for cracking them using a dictionary-based attack.
- Support to dump database tables entirely, a range of entries or specific columns as per user's choice. The user can also choose to dump only a range of characters from each column's entry.
- Support to search for specific database names, specific tables across all databases or specific columns across all databases' tables. This is useful, for instance, to identify tables containing custom application credentials where relevant columns' names contain string like name and pass.
- Support to download and upload any file from the database server underlying file system when the database software is MySQL, PostgreSQL or Microsoft SQL Server.
- Support to execute arbitrary commands and retrieve their standard output on the database server underlying operating system when the database software is MySQL, PostgreSQL or Microsoft SQL Server.
- Support to establish an out-of-band stateful TCP connection between the attacker machine and the database server underlying operating system. This channel can be an interactive command prompt, a Meterpreter session or a graphical user interface (VNC) session as per user's choice.
- Support for database process' user privilege escalation via Metasploit's Meterpreter getsystem command.
- Man-in-the-middle Proxy
- Traditional and AJAX spiders
- Automated scanner
- Passive scanner
- Forced browsing
- Fuzzer
- Участки кода, исполнение которых трудно визуализировать и получить осязаемую информацию о протекающих процессах (back-end процессы, занесение в базу данных, занесение логов в файл).
- Функциональность продукта, которая будет использоваться наиболее часто и возникновение ошибок которой связано с достаточно высоким риском. Автоматизированное тестирование узловых моментов функциональности потребует меньше времени для поиска ошибок. И соответственно, сократит время на их устранение.
- Типовые часто выполняемые операции, которые обычно связаны с обработкой данных. Например – формы, в которых количество заполняемых граф и полей довольно значительное. Цель – автоматизировать занесение требуемых данных в нужное поле и проверить правильность выполнения задачи после сохранения результата.
- Сообщения об ошибках. Требуется автоматизация разнесения некорректных данных по соответствующим полям и тестирование корректности проверки правильности данных и сообщений об ошибках.
- Комплексная проверка поведения всей системы, как целостного объекта (end-to-end testing).
- Проверка числовых массивов, нужных для достоверных математических операций.
- Тестирование корректности отображаемых результатов поиска в ответ на запрос по нужным данным.
- Предложенный список только ориентировочный. Всё зависит от предъявляемых к проверяемой системе требований, возможностей, которые позволяет реализовать выбранный для автоматического тестирования инструмент.
- Create/Read/Update/Delete операции. Простейший пример – работа с пользователем. Ввод, просмотр и коррекция данных о нём, удаление введённой информации.
- Типовые последовательности при эксплуатации приложения. В качестве примера может выступить работа с почтовым менеджером: авторизация, просмотр писем, пролистывание имеющихся, создание новых и их отправка, выход. Это и есть end-to-end последовательность, тестирующая полный объём выполняемых действий и манипуляций. Достоинство таких сценариев в том, что по окончании теста, система возвращается в исходное состояние (или где-то около него), значит, уменьшается влияние на результаты иных тестов.
- Другие случаи, когда ручное тестирование не подходить по ряду причин. Примером может служить проверка структуры создаваемых системой файлов.