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