Прибыль:
- Способность создавать модульные, интеграционные и UI-тесты с использованием искусственного интеллекта в соответствии с пирамидой тестирования и охватывать ситуации с ограничениями и ошибками, а также счастливые сценарии.
- Возможность отсеивать пустые/бесполезные тесты и раздутое покрытие, проверяя, что каждый сгенерированный тест действительно подтверждает поведение.
- Обеспечение того, чтобы тест обнаружил ошибку и предотвратил ее исправление, сообщив ИИ, что должен делать код.
Написание кода — это половина дела; Доказать, что код работает правильно, — это вторая половина. Мобильные приложения сталкиваются с сотнями различных устройств, размеров экранов, версий операционных систем и поведения пользователей. Невозможно проверить все это вручную; Вот почему автоматизированное тестирование (код тестирования кода — тестирование, которое выполняется без участия человека) является основой качества мобильных устройств. ИИ невероятно эффективен при написании тестов, потому что написание тестов — это именно та шаблонная работа, которая ему нравится: проверка определенного поведения для конкретных входных данных. В этом модуле мы узнаем, как ускорить модульное тестирование, тестирование интерфейсов и автоматизацию с помощью ИИ, но обеспечить качество теста глазами человека.
Пирамида тестирования: что тестировать и сколько
Здоровая стратегия тестирования напоминает пирамиду. В базу входит большое количество модульных тестов (быстрое тестирование, тестирующее одну функцию или класс изолированно); они быстрые и дешевые. В середине меньше интеграционного тестирования (тестирование того, как несколько частей работают вместе). Вверху — минимальное UI/сквозное тестирование (тестирование осуществляется нажатием на экран, как это делает пользователь); они реалистичны, но медленны и хрупки. ИИ помогает на каждом уровне, но наибольшая ценность заключается в его базе: быстром создании модульных тестов бизнес-логики.
Тип теста
Область применения
скорость
Эффективность ИИ
модульное тестирование
Одна функция/класс
очень быстро
очень высокий
интеграция
прослойка
средний
высокий
Пользовательский интерфейс/сквозной
Весь поток экрана
медленный
Средний (хрупкий)
Совет: приказывая ИИ «создать тесты для этой функции», явно запрашивайте крайние случаи: пустой ввод, ноль, отрицательное число, очень большое значение, сетевая ошибка. ИИ легко создает счастливый путь; Настоящие ошибки прячутся в границах и выскакивают наружу, если вы не хотите, чтобы они были там.
Этапы написания тестов с помощью ИИ
- Определите поведение, которое будет тестироваться. «Эта функция должна передать этот вывод на этот вход».
- Укажите рамки. JUnit + MockK для Android, XCTest для iOS, Espresso (Android) или XCUITest (iOS) для пользовательского интерфейса.
- Спросите о предельных состояниях. Счастливый сценарий + ошибка + точки останова.
- Управляйте фиктивными объектами. Для тестирования эмулируются внешние зависимости, такие как сеть и база данных (макет — контролируемый макет вместо реального сервиса).
- Запустите тест и проверьте. Пройден ли тест, подтверждает ли он что-нибудь действительно значимое?
Пятый шаг имеет решающее значение. ИИ иногда проводит бесполезные тесты, которые «всегда проходят»; например тест, который ничего не проверяет или проверяет собственные фейковые данные. Пройденный тест и ценный тест — это разные вещи.
Внимание: то, что ИИ может производить результаты, не означает, что тест правильный. Иногда ИИ принимает текущее (возможно, ошибочное) поведение кода как «правильное» и соответственно пишет тесты. Такое тестирование скорее исправляет ошибку, чем отлавливает ее. Вы сами определяете, чего ожидает тест; Расскажите ИИ, что он должен делать, а не что делает код.
Мера тестового покрытия и ошибка
Покрытие тестами (какой процент кода выполняется тестами) — полезный, но вводящий в заблуждение показатель. Покрытие 90% означает, что 90% кода выполнено; но не было проверено, что эти линии работают правильно. Тест, который запускает строку и не проверяет результат, расширяет область действия, но не обеспечивает безопасность. Целью являются не высокие цифры, а содержательная проверка. Вы можете быстро масштабироваться с помощью ИИ, но убедитесь, что каждый тест действительно проверяет поведение.
три мини-кейса
Случай 1 — Пограничная ситуация зафиксирована. ИИ попросили провести тесты функции перевода денег в банковском приложении, в частности были добавлены сценарии «отрицательная сумма» и «больше баланса». Проверка выявила, что перевод не был заблокирован с отрицательной суммой; это будет серьезной уязвимостью безопасности в производстве. Закрывается добавлением однострочного элемента управления. Урок: граничные тесты — самые ценные тесты.
Случай 2 — Фейковый тест. Одна команда с облегчением увеличила охват до 85% с помощью 40 модульных тестов, созданных ИИ. Во время проверки было видно, что большинство тестов на самом деле не проверяли никаких выходных данных, они просто вызывали функцию и писали AssertTrue(true). Охват был высоким, но защита была нулевой. Тесты были переработаны и переписаны с учетом реальных проверок. Урок: цифры покрытия могут лгать.
Случай 3. Ускорено тестирование пользовательского интерфейса. Команда электронной коммерции написала сценарий XCUITest для процесса добавления в корзину с помощью ИИ за 20 минут; Если бы оно было написано от руки, это заняло бы полдня. ИИ угадал идентификаторы элементов экрана; Команда сопоставила их с реальным кодом и исправила. Скорость черновика реальна, но проверка идентификатора — это человеческий труд.
Слабая подсказка / Сильная подсказка
Слабая подсказка: «Напишите тест для этой функции».
Мощная подсказка: «Создайте модульные тесты для этой функции Kotlin с помощью JUnit5 + MockK. Функция: денежный перевод (сумма, источник, цель). Тестируемое поведение (что должен делать код): — Действительный перевод должен быть успешным — Отрицательная или нулевая сумма должна быть отклонена — Сумма, превышающая баланс, должна быть отклонена — Сетевая ошибка должна выдавать соответствующее исключение. Каждый тест должен проверять только одну вещь, их имена должны быть описательными, имитировать внешнюю службу. Не пишите пустое утверждение».
Копируемые шаблоны
Шаблон модульного теста: «Создать модульные тесты [JUnit/XCTest] для этой функции для [языка]. Ожидаемое поведение: [что делать]. Включить: счастливый сценарий, нулевой ввод, точки останова, случай ошибки. Пусть каждый тест проверяет отдельное поведение; используйте значимое утверждение; макет. [код]»
Шаблон тестирования пользовательского интерфейса: «Напишите тест пользовательского интерфейса следующего потока с помощью [Espresso/XCUITest]: [пользовательский поток шаг за шагом]. Выберите элементы экрана с идентификатором доступности, используйте идентификатор вместо текста. Добавьте стратегию ожидания. Напомните мне, чтобы я сопоставил идентификаторы элементов с фактическим кодом».
Шаблон аудита тестирования: «Изучите эти тесты: 1) Действительно ли они проверяют выходные данные/поведение или они являются нулевыми? 2) Охватывают ли они предельные случаи? 3) Исправляют ли они ошибки в коде или ожидают правильного поведения? Отмечайте и усиливайте слабые тесты. [тесты]»
Шаблон оптимизации покрытия: «Определите непроверенные части этого класса и предложите значимые тесты. Расставьте приоритеты путей с реальным риском, а не только количества покрытий. [код]»
Распространенные ошибки
- Просто проверяю счастливый сценарий. Ошибки сохраняются в предельных состояниях; Попросите их открыто.
- Принятие пустого/бесполезного теста. Тесты типа AssertTrue(true) расширяют область действия и не обеспечивают никакой защиты.
- ИИ проверяет, что делает код. Тестирование должно ожидать того, что должен делать код; в противном случае это исправляет ошибку.
- Ошибка с номером области действия. 90% охват не означает 90% точность.
- Ссылки на текст при тестировании пользовательского интерфейса. Тест прерывается при изменении текста; Используйте стабильный идентификатор (id).
- Неправильно настроены моки. «Модульный тест», вызывающий реальную службу, будет медленным и нестабильным.
В итоге
Тестирование — основа качества мобильных приложений, и ИИ очень эффективен в этой области, особенно в модульном тестировании. Следуйте пирамиде тестирования: много модулей, средняя интеграция, мало тестирования пользовательского интерфейса. Явно запросите у ИИ счастливый сценарий, а также предельные случаи и пути ошибок. Убедитесь, что каждый сгенерированный тест действительно проверяет поведение; Пустые тесты и завышенное покрытие вводят в заблуждение. Самое главное — сообщайте ИИ, что должен делать код, а не что он делает, чтобы тест обнаружил ошибку, а не исправил ее.
Задача приложения
Запросите тесты у ИИ, используя «Шаблон модульного теста» для функции бизнес-логики (например, расчет скидки или проверка формы) и явно укажите предельные случаи (нулевой, отрицательный, слишком большой). Запустите сгенерированные тесты, а затем проведите аудит тех же тестов с помощью «Шаблона тестового аудита». Найдите хотя бы один слабый тест, укрепите его и проверьте, обнаруживают ли тесты реальную ошибку функции (путем добавления небольшой ошибки).
контрольный список
- [ ] Я выбрал подходящий слой для тестовой пирамиды (приоритетная единица)
- [ ] Я хотел, чтобы помимо счастливого сценария были предельные случаи и ошибки
- [ ] Я проверил, что каждый тест содержит значимое утверждение
- [ ] Я сказал ИИ, что должен делать код, а не что он делает
- [ ] Я сосредоточился на реальных путях риска, а не на количестве страховок.
- [ ] Я использовал стабильный идентификатор в UI-тестах, не привязывался к тексту