Так что же собой представляют автотесты и что это такое?
Автотест (автоматизированное тестирование) – это скрипт, имитирующий поведение пользователя при эксплуатации программного продукта.
Автоматизированное тестирование при должном подходе сильно улучшает процесс разработки и поддержки программных продуктов, однако имеет ряд недостатков и подводных камней.
Цель автотеста – это локализация ошибок в работе программного обеспечения.
Так почему же автотесты зло?
Первый и один из главных недостатков — это дорогая разработка.
Разработка автотестов занимает довольно внушительный промежуток времени, сильно зависящий от сложности и объема функционала. Соответственно, чем проект больше, тем дольше и сложнее будут создаваться автотесты. Плюс ко всему не каждый QA-отдел может позволить себе разработку автотестов, что влечет за собой дополнительную нагрузку на отдел разработки при создании проекта, а это увеличит время разработки самого проекта.
У автотестов медленная обратная связь
Вначале проекта, когда реализуется первый функционал написания автотестов, это будет занимать намного больше времени, чем «ручное тестирование». А уже далее, по мере доработки функционала, написание тестов начинает занимать столько же, либо меньше, чем «ручное тестирование».
ПОЛНЫЙ ТЕСТ ЛЮБОГО МОНИТОРА, ТЕЛЕВИЗОРА НА «ЗАСВЕТЫ и БИТЫЕ ПИКСЕЛИ»/ Monitor, TV Test for Defects!
Немаловажный фактор — это долгий анализ результатов
Все дело в том, что автотесты сами по себе часто сложны в диагностике того, что пошло не так. Также часто случаются ситуации ложных срабатываний и непредсказуемых поведений автотестов при влиянии внешних факторов (изменение разработанного функционала, неполадки в сети, микросбои на сервере и т.д.)
Как сказано ранее, еще одна боль автотестов — выход из строя
Автотесты часто выходят из строя даже после незначительных изменений в программном продукте, поэтому их нужно постоянно дорабатывать.
Поэтому следующий минус автотестов — это их постоянная поддержка
Разработка автотестов требует определенного времени и значительное время будет потрачено для поддержания их в актуальном состоянии. Если не обновлять тесты, то в регрессии, при достаточном их количестве, будет множество «падений» и всё преимущество автотестов сойдёт на нет.
Чаще случается так, что от автотестов ждут завышенные ожидания. И это еще один минус
Автотесты охватывают только то, на что они были запрограммированы. Поэтому тест может пройти успешно, а смежный дефект остаться незамеченным, так как автотест «ловит» другой баг.
Автоматизация не является тестированием, а автотесты – это всего лишь запрограммированные шаги для выполнения какого-либо сценария. Многие, кто впервые сталкивается с автоматизацией, хотят автоматизировать всё и всюду, чтобы избавиться от мануальных тестировщиков. Но такое невозможно, так как в каждом отдельном проекте существуют особенности в тестировании, с которыми автотесты не справятся.
Описание режима автотест телевизоров Rolsen С1420 и С2120
Далее приведено подробное описание процедуры тестирования этих узлов и методики устраниения выявленных неисправностей.
Тест телевизора на плавность движения динамических сцен
Тестирование узлов питания Power
Мироконтроллер в первую очередь N001 контролирует насколько стабильны напряжения 9, 18, 24 и 115 В. Если отклонения отсутствуют то постоянный потенциал на выводе 18 N001 (PROTECT) будет равен +5 В. Если же нет одного из контролируемых напряжений, постоянный потенциал на выводе 18 упадет ниже +3 В, что запустит работу схемы контроля напряжений, которая содержит счетчик суммарной длительности падений потенциала на выводе 18 N001 ниже +3 В. Суммарная длительность падений напряжений высветится в конце строки «POWER». Если время падения потенциала на выводе 18 ниже +3 В на одну секунду, то оно будет равно 16 единицам в числе, показанном в строке «POWER».
Из-за того, что максимум счетчика равен 128, то максимальное время падений напряжения ниже +3 В, которое может зафиксировать этот счетчик не превысит 8 с. Счетчик обнуляется только если сработает защита или произойдет автоматическое выключение телевизора, которое вызываеттся если пропадет одно из контролируемых напряжений на время более8 секунд. Счетчик обнулится и в конце строки зелеными символами высветится «000». Остальные числа в строке «POWER» высветятся красным цветом, и появится сообщение «NG» в конце четвертой строки «AUTO TEST» красного цвета. Изменение цвета символов на зеленый и обнуление счетчика произойдет снова только при срабатывании защиты и поаторном автоматическом выключении телевизора.
Чтобы принудительно обнулить число в строке нужно включить телевизор и замкнуть вывод 18 N001 через резистор номиналом 3 кОм на общий провод на время более 8 с. Спустя это время сработает защита и телевизор автоматически выключится.
После сброса счетчика не забудьте удалить поставленную перемычку. При последующем включении телевизора Rolsen С1420 или С2120 в конце строки «POWER» появится код «000» зеленого цвета. Если строках «BUS» и «SYNC» в этот момент будет установлено сообщение «ОК», то и в четвертой строке также высветится «AUTO TEST: OK».
Тестирование шины данных интерфейса I2C Bus
При корректном прохождении теста узлом шины данных интерфейса I2C Bus в конце строки «BUS» высветится надпись «ОК» зеленого цвета. Если же выявлены какие-либо ошибки, сбои или неисправности, то цвет сообщения будет красным.
Тестирование шины синхронизации итерфейса I2C Sync
При корректном прохождении теста узлом шины синхронизации интерфейса I2C, то в конце строки «SYNC» в режиме автотеста высветится «ОК» зеленого цвета. Если же синхронизация отсутствует, то в этой строке высветится сообщение «NG» красного цвета.
Источник: tvshema.ru
Тестирование приемников цифрового TV: как перенести тестовую модель с TestRail на новый инструмент
Меня зовут Иванов Александр, я тестирую приёмники цифрового телевидения в GS Labs.
В статье расскажу о том, как наша команда набралась смелости и сменила неудобный и дорогой TestRail на новый инструмент управления тестированием. Статья содержит описание этапов переезда тестов и автотестов, настройку нового инструмента, а также непосредственное описание процессов тестирования ТВ-приемников и их программного обеспечения.
Обо мне: за время работы в компании прошёл путь от тестировщика до ведущего инженера по тестированию. Время от времени выступаю с докладами на конференциях для тестировщиков.
GS Labs — разработчик комплексных решений для формирования экосистем создания и доставки цифровых продуктов на основе собственных технологий. Продуктами GS Labs пользуются более 12 млн. абонентов телеком операторов России, СНГ, странах Восточной и Юго-Восточной Азии.
Объект тестирования
Телевидение появилось в начале XX века и с тех пор непрерывно развивается. С переходом от аналогового вещания к цифровому телевидение открыло для себя новые горизонты. Развитие микропроцессорной техники позволило создавать программно-аппаратные решения для приёма и просмотра цифрового ТВ-контента.
По среде передачи контента цифровое ТВ можно условно поделить на:
- Эфирное,
- Кабельное,
- Спутниковое,
- IP-телевидение.
Для приёма, а также для дальнейшего дешифрования контента может использоваться приёмник цифрового телевидения (set-top-box, STB). Для обработки цифрового контента приёмник использует собственное ПО. Сама приставка, а также её ПО являются объектом разработки и тестирования в GS Labs.
Тестирование приставок
Как уже было сказано, современный ТВ приёмник имеет собственное ПО. Главное задачей ПО приёмника является расшифровка контента, передаваемого в зашифрованном виде. Для успешной расшифровки абонент должен приобрести у оператора подписку на соответствующий пакет телеканалов.
Кроме самого контента оператор транслирует рекламу от сторонних клиентов, которая также должна корректно отображаться приёмником. Существует также дополнительная информационная поддержка абонентов, которая время от времени сообщает абонентам о профилактических работах на головной станции, обновлениях приемников и другую информацию в зависимости от нужд оператора.
Как и любое ПО, ПО приёмника тоже необходимо тестировать.
Описание тестового стенда
Для тестирования используется стенд, идентичный тому, что есть у оператора. Тестовые стенды включают головное оборудование, наиболее распространенное в России: Harmonic, Teleste Luminato, WISI, Ericsson, PBI.
Главным элементом стенда является мультиплексор (далее MUX). MUX представляет собой комбинированное цифровое устройство, обеспечивающее поочередную передачу на один выход нескольких входных сигналов. Он нужен для того, чтобы создавать “каналы по своему усмотрению”: добавлять к исходному контенту звуковые дорожки, телетекст, рекламу, а также шифровать средствами системы условного доступа (СУД), которая также заведена на MUX. И сервер СУД, и другие вспомогательные сервера, как правило, представляют из себя виртуальные машины.
Тестовые данные можно условно поделить на:
- конфигурации (live emulation). Является эмуляцией ТВ-трансляции;
- потоки (stream). Записанная ТВ-трансляция.
Тестирование осуществляется как на потоках, так и на конфигурации. Главный плюс конфигурации — всегда имеем дело с последней версией серверов, однако требуется регулярное их обновление. Главный плюс потоков — простота использования, не требуется настройка серверов, всё уже настроено и может быть переиспользовано бесконечное число раз. Однако в этом случае невозможно использовать последнюю версию передающей части.
Приблизительная схема тестового стенда представлена на рисунке 4. При ручном тестировании приёмник подключаем к источнику сигнала (live emulation или stream), изображение передаётся с приёмника на телевизор, например по HDMI-кабелю. С помощью пульта ищем сигнал, переключаем каналы и проверяем функциональность ПО приставки.
Тест-кейс будет зависеть от функциональности, которую тестируем. Разные команды отвечают за разные функции приёмника. Например, если это тестирование СУД, то кейс, проводимый на потоке, будет выглядеть как на таблице ниже.
Автоматизация тестирования
Как и в любом тестировании ПО, у нас тоже стоит задача автоматизации наших тест кейсов.
Большинство плюсов и минусов автоматизации те же, что и для любой автоматизации, будь то клиент-серверные или мобильные приложения.
- скорость
- обеспечение повторяемости
- снижение трудозатрат на тестирование
- стоимость
- эффект “пестицида”
- необходимость регулярной поддержки автотестов
Наши автотесты написаны на Python 3 с использованием библиотеки Behave. Для автоматизированного взаимодействия с приёмником используется API (вместо пульта при ручном тестировании), которое регулярно дорабатывается и улучшается.
Для хранения тестов за всё время было перепробовано много вариантов: Excel, Test Log, TestRail. Наиболее удачной системой на тот момент стал TestRail.
Во время выполнения автотестов, их результаты переносились в TMS через поле autofunction_name, вернее через числовой префикс в начале имени (наследие более старых TMS систем). От использования поля name было решено отказаться, т.к. подразумевалось, что название может меняться.
Итого имеем следующие поля (на примере одного из автотестов):
Как выглядит соответствующий автотест:
Как видно из приведённого в качестве примера теста, он написан с использованием BDD. Каждая из строчек, написанных на “естественном” языке, подразумевает под собой некий код, написанный на языке программирования, а значения, взятые в кавычки, передаются в качестве параметров.
Таким образом, для написания автотестов не требуется знание языков программирования, главное знать тестируемую функциональность. В целом, встречал неоднозначное отношение к использованию BDD: у подхода есть сторонники и противники. Я себя не причисляю ни к тем, ни к другим, однако отмечу, что в нашем случае подход себя оправдал. Ручные тестировщики принимают активное участие в написании автотестов, т.к. тестируемых функций довольно много и команде автоматизации практически невозможно разобраться в нюансах каждой из них.
По окончании тестирования формировался отчёт средствами TMS.
Смена инструмента для тестирования
Сменить привычный TestRail, перейдя на другую систему управления тестированием, нас побудило простое человеческое “дорого”. В связи с этим мы провели обзор существующих на момент 2019 года систем. По совокупности нескольких факторов выбрали новую российскую разработку Test IT. Начав использовать новую TMS мы обнаружили и другие ее преимущества, например, автоматическое формирование отчетов в дашбордах.
В несколько этапов мы выгрузили тесты в *.xml и успешно импортировали в Test IT. И тут возник вопрос, как переносить результаты автотестов — при ручном тестировании подобных вопросов не возникало, скорее, были вопросы, как генерировать отчёт и какие поля включать.
Как выяснилось позже, поле autofunction name, которое мы использовали, не может быть перенесено в Test IT для обозначения результатов, но может использоваться uuid автотеста. Решение нашли: зная uuid автотеста, можно получить его имя и использовать для переноса результатов. Числовой префикс переехал в название тест-кейса. Далее к каждому автоматизированному сценарию был прилинкован автотест с аналогичным названием. В итоге сами автотесты остались без изменений, за исключением вспомогательного модуля по переносу результатов в TMS Test IT.
В итоге имеем поля:
Сегодня все новые кейсы пишутся в самой TMS. Здесь удалось на практике использовать функциональность общих шагов и возможность указать результат каждого из них в тест кейсе. Это позволило ускорить написание кейсов и облегчить работу с ними для новых сотрудников.
Появилась возможность отследить историю прохождения тест-кейсов, на основании этого можно обнаруживать нестабильные автотесты и иметь представление о возможных багах в ПО приёмников цифрового ТВ.
По завершении тестирования генерируется отчёт, автоматически создаваемый в Test IT, фрагмент которого можно увидеть на рис.5.
Заключение
Смена TMS системы всегда требует определённых трудозатрат. Очень важно, чтобы процесс проходил максимально легко и быстро, и не критично сказался на скорости выпуска релизов и качестве продуктов.
Ещё до начала переезда на новую систему команда разработчика провела несколько обучающих презентаций в нашем офисе, на которых мы заранее задали интересующие вопросы. Считаю, что подобные презентации помогли процессу переезда на новую TMS.
Бесспорно, нам самим тоже пришлось разобраться, изучить API, по необходимости писать в поддержку. Главный итог в том, что нам удалось без особых проблем переехать на новую TMS. Что касается улучшения текущих процессов — для понимания этого в полной мере ещё потребуется время. Но уже можно отметить: новый инструмент помогает быстрее и удобнее создавать тест-кейсы и позволяет наглядно отслеживать историю их выполнения.
- Блог компании Test IT
- Тестирование IT-систем
Источник: habr.com