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