Дымовые тесты 1с что это

Запускаем дымовые тесты с помощью Vanessa-Automation

Используется сторонняя регистрация. После клика вы будете перенаправлены на другой сайт, не пугайтесь.

Онлайн-встреча объединит разработчиков 1С: обсудим автоматизированное тестирование и запуск дымовых тестов с помощью фреймворка Vanessa-Automation. Организатор митапа — IT-компания Lad.

Спикером выступит разработчик 1С Виталий Онянов (Омск), cтаж работы в IT— более 15 лет, в сфере разработки 1С — с 2010 года: работа на стороне заказчика, в консалтинговых компаниях, техническая поддержка.
Текущая специализация — продуктовая разработка. Виталий — популяризатор 1С: автор YouTube-канала, собственного сайта https://tavalik.ru/ и статей на Infostart, спикер профессиональных конференций.

Программа
Дымовые тесты — это первый поверхностный этап проверки на очевидные ошибки, минимальный набор тестов. Спикер расскажет о возможностях и принципах работы инструмента Vanessa-Automation в части дымового тестирования. Продемонстрирует:

• как с нуля развернуть и настроить фреймворк Vanessa-Automation;
• как запустить дымовые тесты для небольшой бесплатной конфигурации «Управляемое приложение».

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

До встречи на митапе! Не упустите возможность перенять практический опыт и прокачать профессиональные навыки!

Smoke-тестирование

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

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

Профессия / 16 месяцев
Тестировщик-автоматизатор

Лучший выбор для быстрого старта в IT

Как проводится дымовое тестирование

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

Планирование. Smoke-тест планируется, как правило, в начале проекта командой quality assurance (QA) инженеров в сотрудничестве с менеджером проекта, программистами, заказчиками и пользователями. Типичное планирование выглядит следующим образом:

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

Выполнение. Это непосредственно этап самого тестирования. В ходе него проверяемая сборка подвергается испытанию в рамках предварительно разработанных тест-кейсов:

• в продукт водятся определенные на этапе планирования исходные данные;
• полученные выходные данные фиксируются для дальнейшей оценки.

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

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

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

• регистрация пользователя;
• авторизация в системе;
• личная страница пользователя;
• редактирование личных данных.

Станьте тестировщиком – это лучший выбор для быстрого старта в IT

Для проверки этого функционала тестировщик в ходе дымового тестирования должен провести основные пользовательские сценарии:

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

Что проверяется с помощью дымовых тестов

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

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

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

Читайте также Как выбрать IT-специальность в новых реалиях?

Чек-лист для Smoke-тестирования:

Этот чек-лист является базовым руководством для smoke-тестирования и может быть дополнен в зависимости от особенностей вашего проекта.

1. Запуск приложения:
   • Приложение успешно запускается без ошибок.
   • Отсутствуют критические ошибки на этапе запуска.
2. Основные функции:
   • Главные функции приложения (например, вход в систему, создание нового пользователя) работают корректно.
   • Основной пользовательский интерфейс открывается и отображается без существенных дефектов.
3. Навигация:
   • Навигация между разделами приложения происходит без проблем.
   • Отсутствуют сломанные ссылки или переходы.
4. Ввод данных:
   • Ввод данных (текст, числа и т.д.) в поля происходит без ошибок.
   • Поля ввода ограничивают ввод некорректных данных.
5. Отображение данных:
   • Данные корректно отображаются на экране (текст, изображения и т.д.).
   • Отсутствуют аномалии в структуре или визуальном отображении.
6. Ошибки и уведомления:
   • Проверка наличия понятных и информативных сообщений об ошибках.
   • Проверка наличия уведомлений о действиях пользователя (успешные операции, предупреждения).
7. Кросс-браузерное тестирование:
   • Приложение работает корректно на основных браузерах (Chrome, Firefox, Safari, Edge и т.д.).
8. Респонсивный дизайн:
   • Приложение адекватно отображается на различных устройствах (мобильные телефоны, планшеты, настольные компьютеры).
9. Базовая безопасность:
   • Проверка наличия базовых мер безопасности (например, валидация данных на сервере, защита от SQL-инъекций).
10. Интеграции:
    • Проверка корректной работы с внешними системами или API, если они используются.
11. Тестовые данные:
    • Проверка наличия тестовых данных или демонстрационных аккаунтов для удобства тестирования.
12. Восстановление после сбоев:
    • Проверка, что приложение может восстановиться после временных сбоев (например, если интернет-соединение было потеряно).
13. Документация:
    • Обновленная документация, описывающая, какие тесты и функциональности должны быть протестированы в рамках smoke-тестирования.
14. Производительность:
    • Общая производительность приложения на базовом уровне.
15. Обратная связь:
    • Проверка наличия механизмов для предоставления обратной связи о найденных ошибках.

Когда проводится smoke-тестирование

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

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

Преимущества дымового тестирования

• Экономия времени и ресурсов. Smoke-тесты сравнительно простые и не требуют значительных затрат на свое проведение, могут осуществляться самими разработчиками или ограниченной командой QA-инженеров. В то же время они могут показать, что текущая сборка не выполняет даже основных своих задач и потому проводить более глубокое и затратное тестирование просто не имеет смысла до тех пор, пока главный функционал продукта не будет стабильно работать.
• Автоматизация. Дымовые тесты обычно стандартные и повторяющиеся для каждой сборки одного и того же продукта или различных однотипных проектов. Соответственно, для ускорения и упрощения тестирование можно автоматизировать. Однако автоматизация самого теста зачастую может быть труднее его «ручного» проведения, поэтому ее нужно осуществлять соразмерно сложности проекта.
• Стабильность сборки. В случае, когда сборки выпускаются часто, регулярное проведение smoke-тестов придает разработчику и другим задействованным в разработке продукта сторонам уверенность, что он будет работать стабильно по крайней мере в отношении основных функций. Соответственно, на каких-то этапах можно опустить затратную глубокую проверку — например, если текущий билд отличается от предыдущего незначительными изменениями.
• Обнаружение проблем на ранних этапах. Особенно это преимущество проявляется в непрерывной интеграции, когда продукт проходит быструю и частую смену итераций. Потенциально такая скорость может привести к накоплению большого количества ошибок в финальной версии. Внедрение smoke-тестов в рамках каждого цикла позволяет этого избежать.

Недостатки дымового тестирования

• Ограниченность. Smoke-тесты покрывают только основные функции приложения. Соответственно, их проведение не гарантирует, что продукт будет работать абсолютно без ошибок, в том числе критических.
• Стереотипность. Повторяющиеся и стандартизированные smoke-тесты упрощают их проведение и автоматизацию. Однако в процессе работы приложения могут возникнуть непредвиденные новые ошибки, тестовые сценарии для которых не были заранее предусмотрены.

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

Тестировщик-автоматизатор

Как ворваться в IT, даже если вы не умеете программировать? Стать тестировщиком. Для старта достаточно базовых знаний ПК. А начать работать можно уже через 4 месяца обучения.

Дымовые тесты 1с что это

Запускаем дымовые тесты с помощью Vanessa-Automation

Онлайн-митап для разработчиков 1С: расскажем и покажем, как проводить дымовые тесты небольших конфигураций с помощью фреймворка Vanessa-Automation

ИТ и интернет 16+

В ноябре митап для 1С-комьюнити объединит разработчиков 1С: обсудим автоматизированное тестирование с помощью фреймворка Vanessa-Automation.

Д ымовые тесты — это первый поверхностный этап проверки на очевидные ошибки, минимальный набор тестов. Спикер расскажет о возможностях и принципах работы инструмента Vanessa-Automation в части дымового тестирования.

• как «с нуля» развернуть и настроить фреймворк Vanessa-Automation;
• как запустить дымовые тесты для небольшой бесплатной конфигурации «Управляемое приложение».

А также поделится собственным опытом тестирования для «больших» типовых конфигураций.

Спикер: Виталий Онянов, разработчик 1С, г. Омск.

• Стаж работы в IT более 15 лет.
• В сфере разработки 1С с 2010 года: работа на стороне заказчика, в консалтинговых компаниях, техническая поддержка, текущая специализация — продуктовая разработка.
• Популяризатор 1С: автор YouTube-канала , собственного сайта https://tavalik.ru/ , а также статей на Infostart , спикер профессиональных конференций.

Не упустите возможность приобщиться к практическому опыту эксперта и прокачать профессиональные навыки!

VanessaADD. Дымовые тесты для 1С и вывод результата в отчет Allure. Проверяем доработки в расширение

Проверяем доработки в расширение c помощью VanessaADD. Настраиваем, запускаем дымовые тесты и анализируем в отчете Allure.

Доработаны инструменты для VanessaADD для управления дымовыми тестами. Точечная настройка дымовых тестов. Возможность отобрать объекты для проверки, которые доработаны в расширениях. Сокращаем время тестирования доработок за счет точечной настройки дымовых тестов.

***В видео сокращено время тестирования для комфортного просмотра.

Комментарии

• Дата
• Дата
• Рейтинг всех уровней
• Рейтинг 1-го уровня
• Древо развёрнутое
• Древо свернутое

Свернуть все
1. artbear 1444 27.08.21 11:49 Сейчас в теме

вопрос — сделаешь ПР с доработками в основной репозиторий Ванесса-АДД?

Прямая ссылка:

BB-код для форумов и блогов:

HTML-код:

Платформа 1С:Предприятие 8 развивалась с начала двухтысячных, постепенно расширяя свое влияние на мобильный мир, веб-технологии и облачные сервисы. Расскажем об эволюции платформы и приложений экосистемы 1С:Предприятие. Доклад в виде статьи: https://infostart.ru/1c/articles/2018812/

Существует множество языков программирования и каждый имеет свои особенности по работе с типами данных. Слабые, явные, динамические и другие. Но кто же здесь 1С и почему с приходом «строгой» типизации EDT 1С-программистам стоит задуматься над изменением своих привычек. Кому полезно: Программистам, которые хотят облегчить процесс разработки и обезопасить свой код. Всем другим, кто хочет краем глаза окунуться в альтернативный мир типизированного 1С. (Всё будет понятно) Вы узнаете: На какой стороне Силы находится 1С и почему это хорошо/плохо (нужное подчеркнуть). Как EDT пытается изменить 1С, сохранив её «особый путь». Тайные знания ордена желтокнижников под кодовым названием ИТС. Как EDT гадает на кофейной гуще и как ей помочь этого не делать. P.S.: Речь не только про ЕДТ, но и про сами стандарты разработки 1С =)

Зачастую при разработке продуктов 1С пренебрегают UI и UX-дизайном. Это приводит к неочевидным интерфейсам, к недовольству пользователей, высокой нагрузке на техническую поддержку и даже саботажу внедрения и применения. О том, на что влияет продуманный дизайн, и какие мелочи в дизайне стоит учесть, расскажем в докладе. Доклад в виде статьи: https://infostart.ru/1c/articles/2015102/

По запросу «Система взаимодействия 1С» выходит очень мало толковой информации о способах применения механизма. Еще меньше информации о неинтерактивном варианте работы системы. Расскажем о четырех проектах, в основе которых лежит Система взаимодействия: двусторонняя связь скайпа с 1С, два кейса для интеграции с Asterisk и использование системы взаимодействия для обслуживания клиентов. Доклад в виде статьи: https://infostart.ru/1c/articles/2014266/

Библиотека стандартных подсистем. Ред. 3.1.9.238. Подсистема «Загрузка данных из файла». Обзор, режим прикладной загрузки, пример использования

Используя некоторые приемы, инструменты и «лайфхаки», можно сделать работу разработчика 1С проще, удобнее, а главное – эффективнее. О том, какие именно «мелочи» могут сделать жизнь разработчика 1С проще, на конференции Infostart Event 2022 Saint Petersburg рассказал Виталий Онянов. Доклад в виде статьи: https://infostart.ru/1c/articles/2007370/

Многие, кто пытался разобраться с производительностью 1С, сталкивались со сложностями. Нет общепринятых алгоритмов, большинство утилит пишутся «под себя» или не выходят за пределы компании, а существующие официальные инструменты тяжелы для освоения. О том, как расследование проблем производительности 1С привело к созданию собственного коммерческого продукта, пойдет речь в докладе. Доклад в виде статьи: https://infostart.ru/1c/articles/2004817/ Приобрести Алькир на Инфостарте: https://infostart.ru/soft1c/1807939/

DaJet Flow: проектирование конвейеров. На примере учебного проекта dajet-flow-tutorial, исходный код которого опубликован на GitHub, мы научимся проектировать конвейеры потоковой обработки данных DaJet Flow. Разберём исходный код учебного проекта и узнаем какие виды блоков конвейера мы можем самостоятельно создавать: — простые, — условные, — итеративные, — транзакционные, — асинхронные. Научимся синхронизировать работу блоков конвейера между собой в транзакционных и асинхронных сценариях обработки данных.

1. Описание контекста выполнения и общей архитектуры DaJet Flow. 2. Внедрение зависимостей (программных сервисов) в плагины DaJet Flow. 3. Взаимодействие плагинов между собой через контексты пайплайна, менеджера пайплайнов и глобальный контекст сервера.

Видео-урок о подсистеме настроек платформы DaJet и разработке пользовательских настроек для плагинов DaJet Flow в Visual Studio 2022 на C#.