Дорогой читатель, это мой первый туториал и если я что-то упустил или не объяснил, хотя стоило бы, напиши пожалуйста комментарий и я обновлю статью.
TL;DR
Весь код для микросервисов и e2e теста тут
Рекомендую быстро пробежаться по коду перед прочтением статьи т к в самой статье я объясню только неочевидные моменты реализации e2e тестирования.
В этой статье мы поделились опытом, полученным за время нашего участия в тестнетах и дропах (это и Aptos, и Arbitrum, и другие) разобрали, что такое ретродропы, как в них можно поучаствовать, почему проектам выгодно раздавать токены ранним пользователям (в этом контексте коснулись регуляции криптовалют) и немного углубились в тонкости - в то, каким образом можно увеличить свой шанс на получение хорошего дропа. Материал вышел немаленький, поэтому ниже содержание с якорными ссылками. Приятного прочтения!
Начало здесь.
Русский свет
https://rs24.ru/customer_person_register
1) Форма регистрации.
Нет возможности просмотра введённого пароля.
а) Отсутствие возможности просмотра введенного пароля может привести к ошибкам при наборе и повторному вводу пароля, что может вызвать раздражение и затраты времени.
Что хорошо:
Есть кнопка повтора заказа.
1. Кнопка повтора упрощает процесс оформления заказа для пользователя, поскольку все данные, введенные при предыдущем оформлении заказа, будут автоматически заполнены. Таким образом, не нужно тратить время на повторное ввод данных.
2. Кнопка повтора помогает ускорить процесс обработки заказа со стороны компании. Это связано с тем, что повторный заказ содержит все необходимые данные, что упрощает его обработку компанией.
Собственно говоря, в интернете присутствуют чек‑листы для тестирования личного кабинета, но мы(почему «мы»? я, ж один) здесь постараемся подойти к проблеме более комплексно. Посмотрим что получится.
Сразу без долгих подготовок определимся для чего нужОн этот самый личный кабинет(сокращенно ЛК).
Личный кабинет — это организация какого‑либо процесса компании, который раньше был настроен в офлайне. Но из‑за оптимизации ресурсов и автоматизации рутины компания перевела его в онлайн.
Зачем сайту личный кабинет клиента
Личный кабинет пользователя на сайте решает три важных задачи.
Всё началось с того, что перед нами поставили задачу покрыть тестами наши сервисы для микросервисной платформы TOT Pyramid, которую мы развиваем последние два года. Мы были вправе выбрать стек технологий самостоятельно. Данные тесты должны запускаться в CI каждый раз при создании мердж-реквеста и проверять, что изменения ничего не сломали. Выбор пал на Rest-assured, тем более хотелось писать тесты на модном, молодёжном Kotlin.
В данной статье хочу поделиться опытом написания автотестов на Rest-assured + Kotlin. Статья не претендует на Rocket Science - в ней я приведу простые примеры и основные принципы тестирования API, которые применяются у нас в TOT Systems.
Поэтому, если вы ищете инструмент для покрытия API автотестами и при этом хотите писать на Kotlin, то эта статья для вас.
Внедрение автоматизированных тестов, которые тестируют всё приложение, является сложной задачей. От выбора уровней для проверки (API, UI или оба) до управления тестовыми данными и подбора подходящей библиотеки для работы. Основываясь на своем опыте, я подготовил руководство по внедрению автоматизации в ваш проект.
Кажется, что принципы гибких подходов давно стали нашей действительностью. Мы признаем их значимость и стремимся сократить потери ресурсов на всех этапах. Однако на практике, даже в такой казалось бы прогрессивной отрасли как ИТ, многое устроено по старинке. Расскажу историю, как я увидела проблему в своей компании, и как мы ее устранили с помощью принципа «Три Амиго».
Привет, уважаемые Хабровчане. Я — Алена Зорина, профдеформированный тестировщик и руководитель отдела обеспечения качества SSP. Предлагаю обсудить инструменты, которые помогают выстроить адекватную коммуникацию в команде, и при чем здесь тестировщики.
Добро пожаловать, новички в тестировании! Вы, вероятно, только начали свой путь в этом увлекательном мире, но не беспокойтесь, мы здесь, чтобы помочь вам разобраться в различных типах тестирования, которые используются в современной практике. Независимо от того, какой уровень опыта вы имеете в тестировании, этот материал будет полезным для вас, чтобы расширить свои знания и умения.
Типы тестирования
Существует множество различных типов тестирования, каждый из которых имеет свои особенности и преимущества. Рассмотрим некоторые из наиболее распространенных типов тестирования.
Мы переходим к технической части статей про тестирование на проникновение. И начнем как всегда с внешнего пути – с эксплуатации веб уязвимостей. И начнем мы с SQL – инъекций.
SQL-инъекция (SQLi) - это уязвимость веб-безопасности, которая позволяет злоумышленнику вмешиваться в запросы, которые приложение делает к своей базе данных. Как правило, это позволяет просматривать данные, которые он обычно не может получить. Это могут быть других пользователей, или любые другие данные, доступ к которым имеет само приложение. Во многих случаях злоумышленник может изменять или удалять эти данные, вызывая постоянные изменения в содержимом или поведении приложения.
Это мой первый пост, прошу сильно не пинать. Для начала немного расскажу, кто такой тестировщик. Это специалист, который отлавливает ошибки на всех этапах разработки проекта. Работа рутинная, но ответственная. Получают тестировщики на 20-30% меньше, чем программисты: от 30 000 руб. и выше, всё зависит от опыта.
Становление тестировщиком – самый простой путь старта в IT, есть куда расти (тест-менеджмент, веб-дизайн, чистая разработка).
Эту информацию я почерпнул из открытых источников и подумал, что вот, я не умею программировать, а получать астрономическую зарплату работать в IT – хочется. Думал, что начну с ручного тестирования, устроюсь на работу – а дальше, как пойдёт.
Но на практике оказалось не всё так просто. Кругом полно таких же людей, который думают точно также же, и такие специалисты маловостребованы. Для чего вообще берут на работу стажёров? Работодатель ожидает, что в ближайшем будущем навыки стажёра охрененно вырастут и он будет приносить огромную пользу фирме с дальнейшим повышением зарплаты (но не всегда таким, какую ожидает стажёр). Поэтому чаще всего стажёры, получив опыт, либо настаивают на значительном повышении з/п или уходят к конкурентам.
Несмотря на грустные мысли, я поставил цель – изучить навыки тестирования на Python хотя бы на уровне продвинутого стажёра.
Ближайшая конференция Heisenbug будет больше обычного: целых четыре дня (два онлайновых и два в Москве с возможностью удалённого подключения). А значит, и докладов тоже будет много. И сейчас, когда программа готова, пришло время показать Хабру их описания.
Как водится на Heisenbug, освещены будут очень разные стороны тестирования, от мобильного до нагрузочного: можно в оглавлении этого поста найти интересующий блок и перейти сразу к нему.
И ещё, как водится на Heisenbug, вместо «болтологии» — техническая конкретика. Как тестировать Flutter-приложения? Как ускорить прогон тестов в многомодульном проекте Maven? Даже хайповый ChatGPT тут будет не в очередных абстрактных рассуждениях «уволят ли нас всех через пять лет», а в конкретном «сравним на практике ChatGPT со статическим анализатором кода».
Парадигма качества представляет собой общую философию и подход к качеству в определенной области или отрасли. Она включает в себя убеждения, ценности и практики, связанные с обеспечением качества; и формируется под влиянием контекста, в котором она действует.
Всем привет! Меня зовут Алена и QA engineer :)
В этой статье хотела бы поделиться опытом автоматизации REST API с помощью таких инструментов как Postman, Newman и Jenkins.
Postman — популярный клиент API, который позволяет тестировать, делиться, создавать, сотрудничать и документировать процесс разработки API внутри команды. Немаловажной функцией Postman является возможность писать и выполнять тесты на основе JavaScript для API. Postman предлагает встроенные инструменты для интеграции API для некоторых инструментов непрерывной интеграции (CI), например Jenkins.
Как можно оценить качество работы SAST-инструмента? Ответ простой: посмотреть на количество false positive и false negative срабатываний на заранее подготовленном уязвимом приложении.
Мы выложили в открытый доступ на GitHub новую версию IAMeter — уязвимого приложения, созданного специально для оценки эффективности SAST-анализаторов. Просканировав его анализатором PT Application Inspector, мы убедились, что SAST вполне может быть как точным, так и полным одновременно, — нашлись все настоящие уязвимости, но не было срабатываний на заведомо ложных.
Предлагаем и вам проверить свой анализатор в «боевых» условиях — сканируйте проект IAMeter и пишите о полученных результатах в комментариях или в наш Telegram-чат.
Представьте, что вы из большой компании впервые пришли на проект единственным тестировщиком и чувствуете себя совершенно беспомощным. В этой статье хочу затронуть некоторые неочевидные нюансы организации тестирования в небольшой команде.
Всем привет! С вами снова я, Иван Шевелёв, QA Lead в компании Denti.AI. Сегодня хотел обсудить наболевшую тему — лучший стек для автоматизации тестирования.
У каждого фреймворка есть большое комьюнити, чатики, каналы, форумы и даже бизнес‑завтраки! Если зайти на страничку любого фреймворка, то каждый из них — топ-1 в мире автоматизации тестирования. Но так ли это?
Привет, Хабр! Меня зовут Ира, я SRE в команде Samokat.tech. В этом посте хочу поделиться подходом в тестировании, которым мы пользуемся сами. Если вам при подготовке тестов часто приходится писать похожие друг на друга как две капли воды заглушки (или, как их ещё называют, «моки»), а затем заботиться о том, чтобы их развернуть, то вам может понравиться наше решение. Освободившись от части рутинных забот, вы можете уделить больше времени чему-то более важному.
Разношёрстные и хаотично развёрнутые в окружении заглушки – дорогие и неэффективные. В каждой отдельной заглушке разбирается в лучшем случае только одна команда, чаще только один человек. Со временем при накоплении критической массы они становятся фактически неподдерживаемыми.
Такие заглушки редко переиспользуются и что важнее, никто ими не делится, так как они либо тривиальны, либо написаны не самым лучшим способом (могут оказаться слишком сложными или неоптимальными).
Сложно представить тестировщика в роли доброго самаритянина, раздающего коллегам свои заглушки. Его к этому вряд ли что-то мотивирует, да и работы у него всегда прилично. Некогда отвлекаться! Так, давайте разгрузим немного нашего трудягу.
Если вы хотите добиться успеха в быстро изменяющемся мире современных технологий, то необходимо постоянно повышать узнаваемость своего бизнеса. Целевая аудитория в наше время в равной мере пользуется как веб-приложениями, так и мобильными устройствами, а потому вопрос предоставления высококачественных программных продуктов для обеих групп пользователей является жизненно важным для любой компании.
Для создания безупречных программных приложений требуется хорошо спланированный процесс тестирования мобильных и веб-приложений. С изменением мышления клиентов и их переходом к использованию мобильных приложений возрастает и роль мобильного тестирования. Решающим элементом такого процесса является круглосуточный доступ к лаборатории тестирования. Тестировщики, обладающие постоянным доступом к облачным сервисам, могут использовать набор портативных и мобильных устройств для повышения эффективности, масштабирования и общего улучшения процесса тестирования. В то же время при всей схожести процесса сохраняется различие между тестированием мобильных и веб-приложений.
В процессе автоматизации часто появляются интересные задачи, к которым, на первый взгляд, абсолютно непонятно как подступиться. Об одной из таких задач сегодня и пойдёт речь.
Статья об автоматизации тестирования веб-приложения в связке с telegram ботом с использованием Telethon и очереди сообщений.
