Тестирование для интернета вещей: раскладываем по полочкам
Привет, Хабр! Меня зовут Катя Муличева, я тестировщица в СИБУР Диджитал. За 4 года в профессии я успела попробовать различные виды тестирования и в этом материале хочу описать свой опыт тестирования систем с использованием датчиков интернета вещей.
Когда я впервые с ними столкнулась, я понятия не имела, с чего начать, — незнакомо было примерно всё. Поэтому в материале тема объясняется «на пальцах», ровно так, как я и хотела бы её получить в начале своего пути. Надеюсь, он окажется для вас полезным!
В первой части очень кратко разберёмся с теорией, а во второй посмотрим, что с ней происходит на практике.
Часть 1. Теоретическая
Определяем предметную область
Рассматривать мы будем системы (программы, приложения, сайты), которые в качестве источника данных используют сообщения от устройств — например, датчиков температуры или камер наблюдения. Простой пример — система «умного дома» с приложением, в котором можно отслеживать, где включены лампочки или кондей. Это приложение запускается, допустим, в браузере или на смартфоне, и получает/отправляет данные на другие устройства.
Гротескная архитектура системы и датчиков
Окей, есть система, есть датчики. Есть два варианта их обмена данными: напрямую, как bluetooth‑наушники, или через посредника. Второй вариант раскроем подробнее.
Наша система запускается где‑то в одном месте — на одном сервере, на чьем‑то телефоне, а датчики совсем не обязательно располагаются рядом. Они могут быть и в разных комнатах, и в разных зданиях, а напрямую соединять их проводами, мягко говоря, не очень удобно. А ещё для безопасной передачи данных может понадобиться шифрование перед отправкой. Поэтому для датчиков и системы нужен посредник. Схема простая: датчики закидывают свои данные в посредника, посредник пасует их приложению. Или в обратном порядке. Посредником может быть и обычный Wi‑Fi роутер, и базовая станция с протоколом LoRa — зависит от вашего продукта.
Анатомия датчика
Датчики бывают разные (да неужели), но есть у них и общие по предназначению элементы. Разберем три самых важных для тестировщиков элемента по функциям:
Фиксация параметра. То есть, это может быть датчик дыма, температуры или давления, камера или тепловизор.
«Мозг» датчика, содержащий его прошивку, — грубо говоря, инструкции и правила, которым датчик подчиняется. Например, сколько раз и за какой период времени он должен проводить измерения, как часто он должен отправлять информацию посреднику и т. д.
Питание. Да, я про батарейку.
С теорией разделались быстро, как и обещали. Переходим к более практической части.
Часть 2. Тестирование на практике
Но сперва дисклеймер: тестировщик системы с датчиками тестирует в первую очередь не сами датчики, а работу системы с ними. Звучит как волчья цитата, но проговорить всё же стоит.
Чем больше окружение тестировщика похоже на окружение прода, тем больше вероятность отловить проблемы заранее. В нашем случае, помимо окружения для запуска системы (версии ПО, модели телефонов, браузеры), нам понадобится ещё и заняться датчиками, а групп тестирования с датчиками у нас три.
1. Настоящие датчики — так мы проверяем, как работает система с реальными данными, применяются ли настройки и команды, которые мы будем отправлять;
2. Эмуляторы датчиков — программы, имитирующие получение данных с датчика. Так мы проверяем, как система работает с получаемыми данными, что очень удобно использовать для проверки отдельных функций или сервисов системы, потому что конкретные данные можно задавать самим.
3. Никаких датчиков! Так мы проверяем функциональность системы самой по себе. Например, для кейсов, когда пользователь только установил систему и настраивает её под себя.
Датчик в процессе тестирования, так сказать
Какие датчики покупать
Вряд ли ваша система будет использовать только датчики одного типа и от одного производителя. Поэтому и покупать, скорее всего, придётся не один датчик. Но какие брать?
Здесь мы можем воспользоваться опытом тестировщиков приложений для смартфонов, им тоже приходится закупать целый парк устройств. В выборе они ориентируются на своих пользователей, изучают, кто чем пользуется, и стараются покупать телефоны, которые покроют наибольший процент пользователей.
Если бюджет в вашей компании не очень строго ограничен, то чем разнообразнее выборка, тем лучше, — например, несколько датчиков температуры от разных производителей, или одинаковые датчики, но с разной версией прошивки. Это поможет в локализации потенциальных проблем (проще говоря, существует ли проблема только с одним производителем или только с одной версией прошивки).
Ещё было бы здорово закупиться датчиками для принципиально новых функций. Например, если раньше у вас в системе никогда не было функциональности для датчика температуры, то лучше проверять новую функциональность на настоящем датчике температуры, чем на эмуляторе. Это уменьшает риски конфуза на проде.
Но разумеется, в реальности у нас почти никогда не может быть полного парка устройств, и нужно быть готовыми, что у реальных пользователей будут возникать специфичные проблемы с редкими устройствами. Для уменьшения рисков в таких случаях стоит использовать бета‑тесты — проще говоря, отдавать новую версию системы не всем пользователям, а небольшой части, и только убедившись, что у них не возникло проблем, лить новую версию на всех пользователей.
А что, собственно, проверяем
Примерный и далеко не полный список:
Добавление и удаление датчика в вашу систему;
Корректность данных, получаемых с датчика;
Настройки, которые мы можем применить к датчику, параметры для генерации событий или сообщения при достижении этих параметров;
Соответствие пакетов от датчика заданному расписанию;
Поведение системы, если датчик присылает пакеты с ошибками.
Поведение, связанное с батареей датчика. Например, есть ли уведомления о приближении заряда к нулю или об отсутствии питания, достоверно ли показывается текущий процент заряда;
Возможность бесконечного цикла в переданных датчику командах.
Но список может довольно сильно варьироваться в зависимости от продукта, поэтому вам, как тестировщику, желательно погрузиться во все его особенности и нюансы.
Отдельно отмечу, что у самого датчика также могут быть дефекты. Например, неправильная прошивка, из‑за которой он передает завышенные/заниженные показатели, или непредвиденное изменение парсинга, или проблема с получением сигнала. Но такие проблемы нужно отдавать на разбор производителям датчиков или сообщать клиенту, что проблема не в ПО и для устранения необходимы другие действия.
Регрессионное тестирование
Для проведения регресса лучше использовать все виды датчиков, что у вас есть. Общие вещи, конечно, можно проверять и на одном датчике. Например, скачивание отчёта, потому что он формируется из таблицы с расшифрованными числами от датчика, на формирование которых тип датчика не особо влияет. Но вот добавление датчика в систему стоит проверять отдельно для каждого устройства, потому что у них могут быть отдельные парсеры сообщений и особенные команды.
Автотесты
Автоматизировать проверки можно даже с реальными датчиками! Даже если кажется, что это не так. Например, когда для добавления датчиков в систему нужно удерживать на них кнопку 5 секунд, или когда датчик реагирует на движение. Здесь удобно использовать эмуляторы, симулирующие поведение датчика, — например, присылающие сгенерированные пакеты раз в 5 минут. Или обращаться напрямую к API с необходимыми параметрами в запросе.
А вот наш датчик в естественной среде обитания
Эпилог
С базой справились! Надеюсь, стало понятнее, что будет ждать вас в тестировании системы с датчиками, а пугающая неизвестность осталась в прошлом. Если хотите больше таких материалов — мне будет приятно увидеть ваши лайки и комментарии:)
Спасибо и до новых встреч!
Habrahabr.ru прочитано 2637 раз
