Тестване на случаи на употреба с примери

по: Томас Хамилтън Томас Хамилтън
Hours Обновено

⚡ Умно обобщение

Тестването на случаи на употреба валидира транзакции от край до край, като упражнява взаимодействията между участника и системата. Техниката задвижва системни и тестови случаи на ниво приемане, разкрива пропуски в интеграцията и допълва проверките на ниво модул с реалистични потребителски работни потоци.

  • 🎭 Моделирайте взаимодействията ясно: Означете всеки поток с участник (A) и система (S), за да могат тестерите tracвсяка стъпка от транзакцията.
  • 🛤️ Първо покрийте щастливия път: Валидирайте основния сценарий за успех, след което добавете разширения и пътища за изключения, които отразяват реални потребителски грешки.
  • 🧩 Anchor с условия: Свържете всяка стъпка с ясни предварителни и последващи условия, така че резултатът от теста да е недвусмислен.
  • 🔗 Tracза приемане: Съпоставете случаите на употреба с критериите за приемане, така че заинтересованите страни в бизнеса да могат да одобрят покритието по време на пускането му.
  • 🤖 Използвайте помощ от изкуствен интелект: Преобразувайте потребителски истории на разбираем английски език в чернови на случаи на употреба, ускорявайки тестовия дизайн и намалявайки пропуснатите потоци.
Прочетете повече

Тестване на случаи на използване: Пример

Какво е тестване на случаи на използване?

Тестване на случаи на използване е техника за тестване на софтуер, която идентифицира тестови случаи, обхващащи цяла система, транзакция по транзакция, от началото до края. Тестовите случаи описват взаимодействията между потребителите и софтуерното приложение. Тестването на случаи на употреба разкрива пропуски, които може да не бъдат открити чрез тестване на отделни софтуерни компоненти поотделно.

A използвайте случай В тестването е кратко описание на конкретно използване на софтуера от даден участник или потребител. Случаите на употреба се пишат от потребителските действия и съответните отговори на приложението и се използват широко за извличане на тестови случаи на системно ниво и ниво на приемане.

Ключови компоненти на случай на употреба

Всеки случай на употреба е изграден от един и същ набор от градивни елементи. Познаването на частите предварително улеснява проектирането на покритие, което точно съответства на тестовите случаи:

  • Актьор: потребителят или външната система, която инициира взаимодействие. Представено като „A“ в текстови потоци.
  • Система: тестваният софтуер, който реагира на актьора. Представен като „S“.
  • Предварителни условия: състоянието, в което системата трябва да бъде, преди да може да започне сценарият на употреба.
  • Основен сценарий за успех: последователността от щастлив път на стъпките на актьора и системата.
  • Разширения / алтернативни потоци: клонове, които обработват изключения, неуспешни валидации или алтернативни избори.
  • Пост-условия: състоянието, в което системата остава след края на случая на употреба.

Как да направите тестване на случаи на употреба: Пример

В случай на употреба, актьорът е представен от „A“, а системата от „S“. Примерът по-долу описва функционалността за вход в уеб приложение.

Тестване на случаи на използване: Пример

Основен сценарий за успех Стъпка Descriptйон
A: Актьор S: Система 1 A: Въведете име и парола на агент
2 S: Валидиране на парола
3 S: Разрешаване на достъп до акаунта
Разширения 2a Паролата не е валидна   S: Показване на съобщение и искане за повторен опит (до 4 пъти)
2b Паролата не е валидна 4 пъти   S: Затворете приложението

Горният поток описва един щастлив път и две разширения. Четенето му стъпка по стъпка:

  • Актьорът въвежда имейл и парола като първа стъпка от процеса на влизане от край до край.
  • Системата валидира паролата.
  • Ако паролата е правилна, достъпът е разрешен.
  • Ако паролата е невалидна, системата показва съобщение и подканва за до четири повторни опита.
  • Ако паролата остане невалидна след четири опита, системата блокира по-нататъшни опити (в този пример, като забранява IP адреса).

От този случай на употреба бихте тествали сценария за успех плюс по един случай за всяко разширение. Това води до минимум три тестови случая: валидно влизане, възстановима невалидна парола и заключване след многократни неуспехи.

СВЪРЗАНИ СТАТИИ

Предимства на тестването на случаи на употреба

Тестването на случаи на употреба се вписва естествено между изискванията и тестовите случаи. Ключовите предимства са:

  • Покритие от край до край: тества транзакции между модули, а не изолирани функции.
  • Валидиране, фокусирано върху потребителя: Всеки сценарий отразява как реален участник използва системата.
  • Изчисти tracвъзможност: случаите на употреба се съпоставят директно с критериите за приемане за одобрение от заинтересованите страни.
  • Предотвратяване на дефекти: откроява пропуските в интеграцията на повърхностите преди началото на регресионните цикли.
  • Артефакти за многократна употреба: Същият случай на употреба захранва тестови случаи, обучителни материали и потребителска документация.

Ограничения на тестването на случаи на употреба

Техниката е мощна, но не е изчерпателна. Имайте предвид следните ограничения:

  • Не е заместител на модулното тестване: Повредите на компонентите с ниско ниво все още се нуждаят от целенасочени тестове.
  • Зависи от точните случаи на употреба: Нееднозначните потоци водят до нееднозначни тестове.
  • Ограничено за нефункционално покритие: производителността, сигурността и достъпността се нуждаят от собствени техники.
  • Режийни разходи за поддръжка: Случаите на употреба трябва да се актуализират, когато бизнес правилата се променят.

Въпроси и Отговори

Случаят на употреба описва как един участник и системата взаимодействат, за да постигнат дадена цел. Тестовият случай проверява дали системата действително се държи по този начин. Един случай на употреба обикновено води до множество тестови случаи.

Тестването на случаи на употреба се прилага най-добре на системно ниво и ниво на приемане, след модулни и интеграционни тестове, когато целта е да се валидират пълните работни процеси на потребителите, а не отделни функции.

Актьорът „A“ представлява потребителя или външната система, която инициира взаимодействието. Системата „S“ представлява софтуера, който реагира на тези действия. Нотацията поддържа потоците компактни и четливи.

Разширенията са алтернативни потоци, които обработват изключения или се разклоняват от основния сценарий за успех. Те описват как системата реагира, когато даден участник въведе невалидни данни, изостави стъпка или следва различен път на вземане на решения.

Най-малкото ви е необходим един тестов случай за основния сценарий на успех плюс по един за всяко разширение. Граничните, еквивалентните и отрицателните вариации могат да добавят още, в зависимост от рисковия профил на приложението.

Не. Тестването на случаи на употреба валидира известни работни потоци, докато проучвателното тестване разкрива неизвестни дефекти чрез неподготвено взаимодействие. Двете техники се допълват взаимно и обхващат различни категории риск.

Асистентите с изкуствен интелект преобразуват потребителските истории на разбираем английски език в структурирани случаи на употреба с актьори, сценарии за успех и разширения. Те също така маркират липсващи алтернативни потоци, като сравняват черновата с типичните модели.

Да. Инструментите с изкуствен интелект четат сценарий на употреба и генерират чернови на тестови случаи за основния поток и всяко разширение, заедно с примерни данни. Тестерът все още преглежда резултата, за да потвърди, че бизнес правилата и приоритетите за риск са правилни.

Обобщете тази публикация с: