Повний навчальний посібник із використання кейсів та тестування кейсів

use case use case testing complete tutorial

Для початку давайте розберемося 'Що таке варіант використання?' а пізніше ми обговоримо 'Що таке тестування використання?' .

Приклад використання - це інструмент для визначення необхідної взаємодії користувача. Якщо ви намагаєтеся створити нову програму або внести зміни до існуючої програми, проводиться кілька обговорень. Одне з найважливіших обговорень, яке ви повинні провести, - це те, як ви будете представляти вимогу до програмного рішення.

Бізнес-експерти та розробники повинні мати взаєморозуміння щодо вимог, оскільки це дуже важко досягти. Будь-який стандартний метод структурування спілкування між ними справді буде благом. Це, в свою чергу, зменшить недоліки спілкування, і ось місце, де вживається сценарій використання.

Цей навчальний посібник дасть вам чітке уявлення про концепцію випадку використання та тестування, охоплюючи тим самим різні аспекти, що стосуються цього, практичними прикладами для легкого розуміння будь-кого, хто абсолютно новий у цій концепції.

Що ви дізнаєтесь:

• Приклад використання
• Хто використовує документи 'Case Case'?
• Види випадків використання
  • # 1) Сонячний день Використовуйте кейси
  • # 2) Випадок використання дощового дня
• Елементи у випадках використання
• Представництво
• Як написати варіант використання?
• Діаграма випадків використання
• Дії користувача
• Що таке тестування використання?
  • Деякі факти
  • Як створити шаблон тесту?
• Висновок
• Рекомендована література

Приклад використання

Приклад використання відіграє значну роль на різних фазах життєвого циклу розробки програмного забезпечення. Приклад використання залежить від 'Дій користувача' та 'Відповіді системи' на дії користувача.

Це документація „Дій”, виконаних Актором / Користувачем, та відповідна „Поведінка” Системи Користувачеві „Дій”. Використовуйте кейси може або не може призвести до досягнення цілі «Актором / Користувачем» щодо взаємодії з системою.

У випадку використання ми опишемо 'Як система реагуватиме на певний сценарій?' . Це «орієнтоване на користувача», а не «орієнтоване на систему».

Це «орієнтоване на користувача»: Ми вкажемо „які дії робить користувач?“ Та „Що актори бачать у системі?“.

Він не є «орієнтованим на систему»: Ми не будемо вказувати „Який вхід надається системі?“ Та „Який вхідний результат виробляє система?“.

Команді розробників потрібно написати «Використовувати справи», оскільки фаза розробки дуже залежить від них.

Використання сценаристів, членів команди та Клієнтів сприятимуть створенню цих справ. Для їх створення нам потрібно зібрати команду розробників, і команда повинна добре знати концепції проекту.

Після реалізації справи документ перевіряється, і поведінка Системи перевіряється відповідно. У випадку, якщо велика літера „А” позначає „Актор”, буква „S” позначає „Система”.

Хто використовує документи 'Case Case'?

Ця документація дає повний огляд різних способів взаємодії користувача з системою для досягнення мети. Поліпшення документації може набагато простіше визначити вимоги до програмної системи.

Цією документацією можуть користуватися розробники програмного забезпечення, тестувальники програмного забезпечення, а також зацікавлені сторони.

Використання документів:

• Розробники використовують документи для впровадження коду та його проектування.
• Тестери використовують їх для створення тестові кейси .
• Зацікавлені сторони бізнесу використовують документ для розуміння вимог до програмного забезпечення.

Види випадків використання

Є 2 типи.

Вони є:

• Сонячний день
• Дощовий день

# 1) Сонячний день Використовуйте кейси

Це первинні випадки, які найімовірніше трапляються, коли все вдається добре. Їм надається пріоритет, ніж іншим справам. Після завершення справ ми передаємо його команді проекту на перевірку та гарантуємо, що ми охопили всі необхідні справи.

Як переглянути файли XML в

# 2) Випадок використання дощового дня

Їх можна визначити як перелік крайових випадків. Пріоритет таких випадків буде після «випадків використання сонячних променів». Ми можемо звернутися за допомогою до зацікавлених сторін та менеджерів продуктів, щоб розставити пріоритети у справах.

Елементи у випадках використання

Нижче наведено різні елементи:

1) Короткий опис : Короткий опис, що пояснює випадок.

2) Актор : Користувачі, які беруть участь у дії у випадках використання.

3) Передумова : Умови, які необхідно виконати до початку розгляду справи.

4) Основні Потік : «Основний потік» або «Основний сценарій» - це звичайний робочий процес у системі. Це потік транзакцій, здійснених Акторами для досягнення своїх цілей. Коли актори взаємодіють із системою, оскільки це звичайний робочий процес, помилок не буде, і Актори отримають очікуваний результат.

5) Альтернативні потік : Окрім звичайного робочого процесу, система може також мати 'альтернативний робочий процес'. Це менш поширена взаємодія користувача із системою.

6) Виняток потік : Потік, який заважає користувачеві досягти мети.

7) Опублікувати Умови : Умови, які необхідно перевірити після завершення справи.

Представництво

Справа часто представлена ​​у вигляді простого тексту або схеми. Через простоту схеми використання, будь-яка організація вважає її необов’язковою

Приклад використання:

Тут я розтлумачу приклад „Логіну” до „Системи управління школою”.

Бали, на які слід звернути увагу

• Поширені помилки, які учасники роблять із використанням кейсів, полягають у тому, що вони містять занадто багато подробиць про конкретний випадок або взагалі не мають достатньої кількості деталей.
• Це текстові моделі, якщо потрібно, ми можемо додати візуальну схему до неї, а може і не.
• Визначте застосовну передумову.
• Напишіть кроки процесу у правильному порядку.
• Вкажіть вимогу до якості процесу.

Як написати варіант використання?

Наведені нижче пункти допоможуть вам написати наступне:

=> Коли ми намагаємося написати справу, перше питання, яке повинно виникнути, - „Що є основним використанням для клієнта?“ Це питання змусить вас писати свої справи з точки зору Користувача.

=> Ми повинні отримати шаблон для них.

=> Він повинен бути продуктивним, простим і сильним. Вагомий випадок використання може вразити аудиторію, навіть якщо вона має незначні помилки.

=> Ми повинні його пронумерувати.

=> Ми повинні написати крок процесу в його порядку.

=> Дайте власне ім’я Сценаріям, іменування повинно здійснюватися відповідно до мети.

=> Це ітераційний процес, що означає, що коли ви пишете їх вперше, це не буде ідеально.

=> Визначте дійових осіб у системі. Ви можете знайти купу акторів у системі.

Приклад ,якщо ви розглядаєте сайт електронної комерції, такий як Amazon, там ми можемо знайти таких гравців, як покупці, продавці, оптові дилери, аудитори, постачальники, дистриб'ютори, обслуговування клієнтів тощо.

Спочатку давайте розглянемо перших акторів. У нас може бути більше одного актора, що має однакову поведінку.

Наприклад , обидва Покупець / Продавець можуть «Створити рахунок». Так само як 'Покупець, так і Продавець' можуть 'Шукати товар'. Отже, це повторювана поведінка, і їх потрібно усунути. Окрім використання дублікатів справ, ми повинні мати і більш загальні випадки. Отже, нам потрібно узагальнити випадки, щоб уникнути дублювання.

=> Ми повинні визначити застосовну передумову.

Діаграма випадків використання

Діаграма використання - це графічне зображення дій користувача в системі. Він справді є чудовим інструментом у цьому контексті, якщо діаграма містить багато дійових осіб, це дуже легко зрозуміти. Якщо це діаграма високого рівня, вона не буде містити багато деталей. Він демонструє складні ідеї досить елементарно.

Малюнок No: UC 01

Як показано в Малюнок No: UC 01 він представляє схему, де Прямокутник представляє „Систему”, овал - „Приклад використання”, Стрілка - „Відносини”, а Людина - „Користувач / Актор”. Він показує систему / додаток, потім показує організацію / людей, які з нею взаємодіють, та основний потік 'Що робить система?'

Рис. No: UC 02

Рис. No: UC 03 - Використовуйте схему випадків для входу

Це діаграма випадків використання випадку «Вхід». Тут у нас є не один актор, вони всі розміщені поза системою. Учні, вчителі та батьки вважаються головними дійовими особами. Ось чому всі вони розміщені на лівій стороні прямокутника.

Адміністратор та Персонал вважаються другорядними акторами, тому ми розміщуємо їх праворуч від прямокутника. Актори можуть входити в систему, тому ми з'єднуємо акторів і справу для входу за допомогою роз'єму.

Інші функції, які можна знайти в системі, - це Скинути пароль та Забули пароль. Усі вони пов’язані з випадком входу, тому ми підключаємо їх до роз’єму.

Дії користувача

Це дії, які виконує користувач у системі.

Наприклад: Пошук на сайті, додавання елемента до вибраного, спроба зв’язку тощо.

Примітка:

• Система це «все, що ви розробляєте». Це може бути веб-сайт, додаток або будь-який інший компонент програмного забезпечення. Як правило, він представлений прямокутником. Він містить випадки використання. Користувачі розміщуються поза «прямокутником».
• Використовуйте кейси зазвичай представлені овальними фігурами, що визначають дії всередині нього.
• Актори / Користувачі це люди, які користуються системою. Але іноді це можуть бути інші системи, людина чи будь-яка інша організація.

Що таке тестування використання?

Він підпадає під функціональну техніку тестування Black Box. Оскільки це тестування чорної скриньки, перевірка кодів не проводиться. Декілька цікавих фактів про це коротко описані в цьому розділі.

Це гарантує, чи використовуваний користувачем шлях працює належним чином чи ні. Це гарантує, що користувач може успішно виконати завдання.

Деякі факти

• Не тестування проводиться для визначення якості програмного забезпечення.
• Навіть якщо це тип наскрізного тестування, це не забезпечить повного охоплення користувацької програми.
• На підставі результатів тестування, відомих з тестування Case Use, ми не можемо прийняти рішення про розгортання виробничого середовища.
• Він виявить дефекти інтеграційного тестування.

Приклад тестування прикладу використання:

Розглянемо сценарій, коли користувач купує товар із Інтернет-магазину. Користувач спершу увійде в систему та розпочне пошук. Користувач вибере один або кілька предметів, показаних у результатах пошуку, і додасть їх у кошик.

Після всього цього він перевірить. Отже, це Приклад логічно пов’язаної серії кроків, які користувач виконає в системі для виконання завдання.

У цьому тестуванні перевіряється потік транзакцій у всій системі від кінця до кінця. Випадки використання - це, як правило, шлях, який користувачі найімовірніше використовуватимуть для досягнення конкретного завдання.

Отже, це полегшує пошук випадків використання дефектів, оскільки він включає шлях, з яким користувачі частіше стикаються, коли користувач використовує програму вперше.

Крок 1: Першим кроком є ​​перегляд документів про використання.

Нам потрібно переглянути та переконатися, що функціональні вимоги повні та правильні.

Крок 2: Потрібно переконатися, що випадки використання атомні.

Наприклад: Розглянемо „Систему управління школою, яка має багато функціональних можливостей, таких як„ Вхід ”,„ Показати дані про учнів ”,„ Показати позначки ”,„ Показати відвідувачів ”,„ Контактний персонал ”,„ Подати комісію ”тощо. Наразі ми намагаємось підготуйте Служби використання для функціональності «Вхід».

Потрібно переконатись, що жоден звичайний робочий процес не повинен поєднуватися з будь-якою іншою функціональністю. Воно повинно бути повністю пов’язане лише з функцією «Увійти».

Крок 3: Нам потрібно перевірити нормальний робочий процес у системі.

Перевіривши робочий процес, ми повинні переконатися, що він завершений. Спираючись на знання системи або навіть домену, ми можемо з’ясувати відсутні етапи в робочому процесі.

Крок 4: Переконайтеся, що альтернативний робочий процес у системі завершено.

Крок 5: Ми повинні переконатися, що кожен крок у випадку використання перевіряється.

Кожен крок, описаний у тестуванні на використання, перевіряється.

Наприклад, деякі транзакції з кредитними картками в системі не перевіряються з міркувань безпеки.

Крок 6: Як тільки ми оживимо ці випадки, ми зможемо написати тестові приклади.

Ми повинні писати тестові кейси для кожного нормального та альтернативного потоку.

Наприклад , Розглянемо випадок «Показати оцінки учнів» у системі управління школою.

Назва використання: Показати студентські оцінки

Актори: Студенти, викладачі, батьки

Попередній стан:

1) Система повинна бути підключена до мережі.

два) Актори повинні мати «посвідчення студента».

Приклад використання для «Показувати знаки студентів»:

Відповідний тестовий випадок для справи «Показати оцінки студентів»:

Зверніть увагу, що наведена тут таблиця Test Case містить лише основну інформацію. „Як створити шаблон тестового кейсу“ докладно пояснено нижче.

У таблиці відображається «Тестовий приклад», який відповідає випадку «Показати оцінку студента», як показано вище.

Найкращий спосіб написати тестові кейси - це спочатку написати тестові кейси для «Основного сценарію», а потім написати їх для «Альтернативних кроків». « Кроки у тестових справах отримується з документів про використання. Найперший Крок у справі «Показати студентську оцінку» «Ввести ім’я студента» стане першим Крок у 'Тестовому випадку'.

Користувач / Актор повинен мати можливість увійти до нього. Це стає Очікуваний результат .

Ми можемо звернутися за допомогою до такої техніки проектування тестів, як „ аналіз граничного значення ' , 'Розділення еквівалентності' під час підготовки тестових кейсів. Техніка проектування тестів допоможе зменшити кількість тестів і тим самим скоротити час, необхідний для тестування.

Як створити шаблон тесту?

Коли ми готуємо тестові кейси, ми повинні думати і діяти як кінцевий користувач, тобто поставити себе на місце кінцевого користувача.

На ринку є кілька інструментів, які допоможуть у цьому контексті. ' TestLodge ’- один із них, але це не безкоштовний інструмент. Нам потрібно його придбати.

Нам потрібен шаблон для документування тестового кейсу. Давайте розглянемо загальноприйнятий сценарій, «вхід у систему FLIPKART», який ми всі знайомі. Електронну таблицю Google можна використовувати для створення таблиці тестових кейсів та обміну нею з членами команди. Поки що я використовую документ Excel.

Ось приклад

=> СКАЧАТИ цей шаблон таблиці тестових кейсів тут

Перш за все, назвіть аркуш тесту відповідним іменем. Ми пишемо тестові кейси для певного модуля проекту. Отже, нам потрібно додати 'Назва проекту' та ‘Модуль проекту ’Стовпці в таблиці тестових кейсів Документ повинен містити прізвище творця тестових кейсів.

Тому додайте 'Створено' і «Дата створення» колонки. Документ повинен переглянути хтось (керівник групи, керівник проекту тощо), тому додайте «Переглянуто» стовпець і «Переглянута дата» .

Наступна колонка є „Тестовий сценарій“ , тут ми навели Приклад сценарію тестування ‘Підтвердити вхід на Facebook’ . Додайте стовпці «Ідентифікатор сценарію тесту» і «Опис тестового кейсу» .

Для кожного тестового сценарію ми напишемо ‘Тестові кейси ’. Отже, додайте стовпці «Ідентифікатор тестового кейсу» і ‘Опис тестового кейсу ’. Для кожного тестового сценарію буде „Стан повідомлення“ і «Попереднє стан» . Додайте стовпці „Попередній стан” та „Попередній стан”.

Ще одна важлива графа - «Тестові дані» . Він міститиме дані, які ми використовуємо для тестування. Тестовий сценарій повинен передбачати очікуваний результат та фактичний результат. Додайте стовпець 'Очікуваний результат' та 'Фактичний результат'. 'Статус' показує результат виконання тестового сценарію. Це може бути або передача / невдача.

Тестери виконуватимуть тестові кейси. Нам потрібно включити це як «Виконав» і «Дата виконання» . Ми додамо 'Команди', якщо такі є.

Висновок

Сподіваюся, ви б чітко уявили про випадки використання та тестування випадків використання.

Написання цих справ - це ітераційний процес. Для написання цих випадків вам потрібно лише трохи практики та гарне знання системи.

У двох словах, ми можемо використовувати програму «Використовувати тестування кейсів» у додатку, щоб знайти відсутні посилання, неповні вимоги тощо. Їх пошук та модифікація системи досягнуть ефективності та точності системи.

Чи маєте ви попередній досвід використання прикладів використання та тестування? Не соромтеся поділитися з нами у розділі коментарів нижче.

Рекомендована література

• Функціональне тестування проти нефункціонального тестування
• Поглиблені підручники Eclipse для початківців
• Альфа-тестування та бета-тестування (повний посібник)
• Підручник з тестування DevOps: Як DevOps вплине на тестування якості?
• Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
• Підручник з тестування зручності використання: Повний посібник із початку роботи
• Підручник з тестування графічного інтерфейсу: Повна інструкція з тестування інтерфейсу користувача (UI)
• Підручник з деструктивного контролю та неруйнівного контролю