Опубликовано: 24.09.2026 | Источник: CNews (новости)

Тестирование Android-смартфонов с физической клавиатурой в ВКР: матрица устройств и метрики качества

Kickstarter-кампания Unihertz Titan 2 Elite собрала нужную сумму, и на рынок выходит Android-смартфон за $389 с полноценной QWERTY-клавиатурой и актуальной начинкой. Для выпускника ИТ это не новость «про гаджеты», а готовый повод для дипломной темы: перед вами редкий сценарий ввода, на котором ломается половина стандартных UI-автотестов. Android-приложение, отлично работающее на виртуальной клавиатуре, может давать «фантомные» события, терять фокус и дублировать onKeyDown, как только пользователь нажмёт реальную кнопку. В ВКР такое поведение превращается в проверяемую гипотезу, измеримые метрики и защищаемые выводы. Ниже — как превратить кейс из статьи в рабочую главу диплома, не скатываясь в обзор пресс-релизов.

Основная часть: как кейс Titan 2 Elite превращается в три главы диплома

Поддомен здесь — QA/Автоматизация, роль — QA-лид. Логика простая: физическая клавиатура добавляет в матрицу устройств новый класс ввода, а значит появляются тест-кейсы, которых нет в стандартных чек-листах мобильного тестирования. Ниже три темы ВКР, каждая из которых опирается на конкретный факт из публикации: ценовой сегмент $389 (значит, аудитория широкая — качество критично), физическая QWERTY, современное «железо» и Android как платформа.

Что писать в главе 1: анализ предметной области без «воды»

Первая глава в вашей ВКР — это не пересказ статьи, а разбор проблемы. Опишите класс Android-устройств с аппаратным вводом, приведите пример Titan 2 Elite как свежий (март 2026) кейс, добавьте таблицу сравнения с сенсорными аналогами по параметрам: способ ввода, поддержка клавиатурных сокращений, поведение при блокировке экрана. Сюда же лягут стандарты — ISO/IEC 25010 (раздел usability и functional suitability) и ГОСТ 19.301 для программы испытаний. Именно эти два документа чаще всего требуют на нормоконтроле, и именно на них удобно ссылаться при обосновании метрик.

Что писать в главе 2: проектирование стенда и кода

Вторая глава — самая весомая. Здесь вы описываете архитектуру тестового фреймворка по C4 (контекст и контейнеры), строите UML-диаграмму классов Page Object и приводите листинги. Для темы с клавиатурой нужен минимум один тест, который проверяет аппаратный ввод через ADB и UI Automator, иначе защита «поплывёт» на первом же вопросе комиссии.

# appium_hardware_keyboard_test.py
from appium import webdriver
from appium.options.android import UiAutomator2Options
from appium.webdriver.common.appiumby import AppiumBy

options = UiAutomator2Options()
options.platform_name = "Android"
options.device_name = "Unihertz_Titan_2_Elite"
options.app = "/apk/app-debug.apk"
options.automation_name = "UiAutomator2"

driver = webdriver.Remote("http://127.0.0.1:4723", options=options)

# 1. Стабилизируем фокус на поле ввода
field = driver.find_element(AppiumBy.ID, "com.example.app:id/login_input")
field.click()

# 2. Эмулируем физический ввод ключа через ADB (а не send_keys)
driver.execute_script("mobile: shell", {
    "command": "input",
    "args": ["keyevent", "KEYCODE_A", "--longpress"]
})

# 3. Проверяем: событие не задублировалось
value = field.get_attribute("text")
assert value == "a", f"Ожидали 'a', получили {value!r}"

# 4. Проверяем отсутствие потери фокуса после длинного сценария
assert field.get_attribute("focused") is True
driver.quit()

Совет из практики: отдельно логируйте события через adb shell getevent и сопоставляйте их с onKeyDown/onKeyUp в приложении. Ошибка «дублирование последнего символа» на аппаратных клавиатурах встречается чаще, чем на сенсорных, и в дипломе её полезно вынести в отдельный тест-кейс.

Что писать в главе 3: метрики и их интерпретация

Третья глава без чисел не защищается. Считайте: покрытие автотестами по сценариям ввода, время полного регресса до и после автоматизации, число найденных дефектов на 1000 строк, распределение ошибок ввода по типам клавиш, средний расход заряда на 30 минут набора текста. Опишите диаграмму развёртывания: локальный эмулятор, ферма устройств (Firebase Test Lab), CI-раннер на GitHub Actions или GitLab CI. Интеграцию метрик тестов удобно делать через OpenTelemetry и вывод в Grafana — это уже тренд, который комиссия на технических кафедрах встречает одобрительно.

Чему вы конкретно научитесь на этой теме

• Проектировать матрицу устройств и матрицу тестовых данных под редкий аппаратный ввод.
• Писать автотесты на Appium и UI Automator с эмуляцией low-level событий, а не только send_keys.
• Снимать энергопрофиль через Battery Historian и perfetto, строить регрессионные модели автономности.
• Оформлять программу испытаний по ГОСТ 19.301 и обосновывать атрибуты качества по ISO/IEC 25010.
• Считать эффект автоматизации в часах разработки и дефектах, а не в «удобно/неудобно».

FAQ: что чаще всего спрашивают студенты

Где взять данные, если у меня нет Titan 2 Elite под рукой?

Три пути. Первый — использовать официальный эмулятор Android с флагом hw.keyboard=yes в config.ini AVD: он эмулирует аппаратную клавиатуру. Второй — подключить любую USB/Bluetooth QWERTY-клавиатуру к обычному Android-устройству: для системы это будет тот же класс ввода. Третий — собрать публичный датасет из Kaggle или Zenodo по эргономике ввода и использовать его как baseline для сравнения. В главе 1 обязательно обоснуйте, почему выбранный стенд репрезентативен.

Какой стек выбрать: Appium или Espresso?

Espresso работает внутри приложения и не «увидит» реальное событие клавиатуры так, как его видит система. Appium + UiAutomator2 — предпочтительнее для вашей темы, потому что тест живёт вне процесса и может дергать mobile: shell для проверки событий. Если хотите показать скилл в дипломе — сделайте гибрид: основной сценарий на Appium, а юнит-проверка парсера ввода на Espresso. Двойной стек выглядит убедительно, если вы объясните границы применимости каждого.

Как оформить тест-кейсы для приложения в диплом?

Классический вариант — таблица с полями: ID, название, приоритет, предустановки, шаги, ожидаемый результат, фактический результат. Для аппаратной клавиатуры добавьте колонки «тип ввода» (physical/touch) и «эмулятор/реальное устройство». Тест-кейсы вынесите в приложение к ВКР, в тексте главы оставьте только выборочные примеры. Так вы пройдёте нормоконтроль без претензий.

Как посчитать эффективность автоматизации для защиты?

Формула проста: экономия = (T_manual − T_auto) × N_запусков / месяц, где T_manual — время ручного прогона, T_auto — время автотеста. Не забудьте вычесть стоимость поддержки тестов (обычно 10–20% в месяц от первичной трудоёмкости). Такой расчёт комиссия воспринимает как инженерный, а не маркетинговый.

Чек-лист «Что проверить перед сдачей»

Типичные ошибки студентов

Источник: Китайцы выпустили недорогой смартфон в стиле BlackBerry – с полноценной клавиатурой и современным «железом» (опубликовано 2026-03-25)