Повне керівництво з функціонального тестування з його типами та прикладами

complete functional testing guide with its types

Поглиблений комплексний підручник з функціонального тестування з типами, методами та прикладами:

Що таке функціональне тестування?

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

Це робиться для перевірки всіх функціональних можливостей програми.

СПИСОК підручників, висвітлених у цій серії:

Підручник No1: Що таке функціональне тестування (цей посібник)
Підручник No2: Тестування функціональності Запитання для інтерв’ю
Підручник No3: Найкращі функціональні засоби автоматизації тестування
Підручник No4: Що таке нефункціональне тестування?
Підручник No5: Різниця між одиницею, функціоналом та Інтеграція Тестування
Підручник No6 : Чому тестування функціональності та продуктивності слід проводити одночасно

Інструменти:

Підручник No7: Функціональна автоматизація тестів із Ranorex Studio
Підручник No8: UFT Функціональний інструмент Нові функції
Підручник No9: Крос-браузерна функціональна автоматизація за допомогою інструменту контролю якості Parrot
Підручник No10: Підручник з інструменту з відкритим кодом Jubula для тестування функціональності

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

• Вступ до функціонального тестування
  • Типи функціонального тестування
  • Процес
  • Критерії входу / виходу
    • Критерії вступу:
    • Критерії виходу:
  • Задіяні кроки
  • Підхід
  • Функціональні методи тестування
    • # 1) Тести на основі кінцевого користувача / системи
    • # 2) Тести на еквівалентність
    • # 3) Тести граничних значень
    • # 4) Тести на основі рішень
    • # 5) Тести альтернативних потоків
    • # 6) Спеціальні тести
  • Функціональна автоматизація тестів
  • Переваги
  • Обмеження
  • Висновок
  • Рекомендована література

Вступ до функціонального тестування

Має бути щось, що визначає, що є прийнятною поведінкою, а що ні.

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

Тому тестування функціональності можна проводити через дві популярні техніки :

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

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

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

Типи функціонального тестування

Функціональне тестування має багато категорій, і їх можна використовувати на основі сценарію.

Найвизначніші типи коротко обговорюються нижче:

Одиничне тестування :

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

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

i) Покриття лінії
ii) Покриття кодового шляху
iii) Покриття методу

Перевірка розумності : Тестування, яке проводиться, щоб переконатися, що всі основні та життєво важливі функціональні можливості програми / системи працюють правильно. Зазвичай це робиться після тесту на дим.

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

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

Регресійні тести не повинні бути такими обширними, як фактичні функціональні тести, але вони повинні забезпечувати лише обсяг покриття, щоб засвідчити стабільність функціональності.

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

Тестування бета / юзабіліті : Продукт піддається реальному замовнику на виробництві, як оточення, і вони тестують продукт. З цього випливає комфорт користувача та беруться відгуки. Це схоже на тестування з прийняттям користувачів.

Давайте представимо це на простій блок-схемі:

Тестування функціональної системи:

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

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

=> Різниця між модульним, функціональним та інтеграційним тестуванням

Процес

Цей процес тестування складається з трьох основних етапів:

Підхід, методи та приклади

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

Отже, зображене зображення буде виглядати так, як показано нижче:

Критерії входу / виходу

Критерії вступу:

• Документ специфікації вимог визначено та затверджено.
• Підготовлено тестові кейси.
• Дані тестування створено.
• Середовище для тестування готове, усі необхідні інструменти доступні та готові.
• Повна або часткова заявка розроблена та перевірена модулем та готова до тестування.

Критерії виходу:

• Виконання всіх функціональних тестів завершено.
• Жодних критичних помилок або помилок P1, P2 не відкрито.
• Повідомлені помилки були визнані.

Задіяні кроки

Різні етапи, що беруть участь у цьому тестуванні, зазначені нижче:

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

Підхід

Різні типи сценаріїв можна розглядати та створювати у формі «тестових кейсів». Як люди з контролю якості, ми всі знаємо, як виглядає скелет тестового випадку.

В основному він складається з чотирьох частин:

• Підсумок тесту
• Передумови
• Тестові кроки та
• Очікувані результати.

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

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

Пояснимо це за допомогою приклад.

Приклади використання функціонального тестування:

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

Технічні характеристики наведені нижче:

# 1) Поле ідентифікатора користувача займає мінімум 6 символів, максимум 10 символів, цифри (0-9), літери (a-z, A-z), спеціальні символи (допускається лише підкреслення, крапка, дефіс), і його не можна залишати порожнім. Ідентифікатор користувача повинен починатися з символу чи цифри, а не спеціальних символів.

# два) Поле пароля займає мінімум 6 символів, максимум 8 символів, цифри (0-9), літери (a-z, A-Z), спеціальні символи (усі) і не можуть бути порожніми.

Основний підхід до тестування цього сценарію можна класифікувати на дві широкі категорії:

1. Позитивне тестування і
2. Негативне тестування

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

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

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

Пропоноване читання => Що таке негативне тестування та як писати негативні тестові кейси

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

Функціональні методи тестування

# 1) Тести на основі кінцевого користувача / системи

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

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

як виглядає клавіша wep

Деякі зразки наведені нижче:

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

# 2) Тести на еквівалентність

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

Наприклад , у наведеному вище сценарії поле ідентифікатора користувача може містити максимум 10 символів, тому введення даних> 10 повинно поводитися однаково.

# 3) Тести граничних значень

Граничні тести передбачають обмеження даних для програми та перевіряють її поведінку.

Тому, якщо вхідні дані подаються понад граничні значення, це вважається негативним тестуванням. Отже, мінімум 6 символів для користувача встановлює граничну межу. Тести, написані для ідентифікації користувача<6 characters are boundary analysis tests.

# 4) Тести на основі рішень

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

У наведеному вище сценарії можна негайно отримати наступні тести на основі рішень:

1. Якщо введені неправильні дані, це повинно вказати це користувачеві та перезавантажити сторінку входу.
2. Якщо користувач вводить правильні облікові дані, він повинен перейти до наступного інтерфейсу користувача.
3. Якщо користувач вводить правильні облікові дані, але бажає скасувати вхід, він не повинен переводити користувача до наступного інтерфейсу та перезавантажувати сторінку входу.

# 5) Тести альтернативних потоків

Виконуються альтернативні тести шляху для перевірки всіх можливих способів, що існують, крім основного потоку для виконання функції.

# 6) Спеціальні тести

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

Наприклад , зразком тестового випадку буде:

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

Функціональне проти нефункціонального тестування:

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

=> Точну різницю читайте тут

Функціональна автоматизація тестів

Чи можемо ми автоматизувати функціональні тести?

Завдяки автоматизації можна зменшити ручні зусилля, заощадити час, уникнути ковзання помилок та підвищити ефективність.

Однак неможливо автоматизувати все і все. Це тестування можна автоматизувати, але користувач повинен розробити тестові кейси для автоматизації. Важливо знайти правильні тестові кейси для автоматизації разом із відповідним інструментом.

Автоматизація функціональних випадків може мати недоліки, наприклад, якщо кількість тестових кейсів набагато більше і регресує знову і знову (що потрібно зробити), тоді розробник може зіткнутися з проблемою при здійсненні змін у коді.

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

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

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

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

Міркування щодо автоматизації:

# 1) Виберіть правильний інструмент автоматизації : На ринку доступно кілька інструментів, вибрати інструмент автоматизації - справжнє непросте завдання! Однак ви можете скласти перелік вимог, на основі яких ви можете вибрати, який інструмент автоматизації використовувати.

Деякі основні аспекти, про які слід подумати, включають:

• Виберіть інструмент, який буде простим у користуванні всіма членами команди з контролю якості, якщо вони ще не мають необхідних навичок.
• Інструмент можна використовувати в різних середовищах. Для Приклад : Чи можна сценарії створювати на одній платформі ОС, а працювати на іншій? Вам потрібна автоматизація CLI, автоматизація інтерфейсу користувача, автоматизація мобільних додатків або все інше?
• Інструмент повинен мати усі необхідні вам функції. Для Приклад : Якщо деякі тестери погано володіють мовою сценаріїв, інструмент повинен мати функцію запису та відтворення, а потім підтримувати перетворення записаного сценарію на потрібну мову сценаріїв. Подібним чином, якщо вам також потрібен інструмент для підтримки автоматизованих тестів збірки, конкретної звітності та ведення журналу, то він також повинен це зробити.
• Інструмент повинен мати можливість підтримувати повторне використання тестових випадків у разі зміни інтерфейсу користувача.

Засоби автоматизації : Існує досить багато інструментів, доступних для функціональної автоматизації. Можливо, селен є улюбленим фаворитом, але є й інші інструменти з відкритим кодом, такі як Sahi, Watir, Robotium, AutoIt тощо.

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

Нижче наведено деякі найкращі інструменти функціонального тестування:

• Селен
• QTP
• Джуніт
• Loadrunner
• МИЛО
• TestComplete

=> Ознайомтесь із цим повним списком найкращих функціональних засобів автоматизації

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

Тому ви можете автоматизувати тести, які:

• Потрібно запускати неодноразово.
• Запуск із різними типами даних.
• Деякі тести P1, P2 забирають багато сил та часу.
• Тести, схильні до помилок.
• Набір тестів, які потрібно проводити в різних середовищах, браузерах тощо.

# 3) Виділена команда автоматизації : Це, мабуть, не враховується у більшості організацій, і автоматизація накладається на всіх членів команди з контролю якості.

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

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

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

# 4) Тести, керовані даними: Автоматизовані тестові кейси, що вимагають декількох наборів даних, повинні бути добре написані, щоб їх можна було використовувати повторно. Дані можуть бути записані у такі джерела, як текст або файл властивостей, XML-файли, або прочитані з бази даних.

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

# 5) Зміни інтерфейсу не повинні порушувати тести: Тестові кейси, які ви створюєте за допомогою вибраного інструменту, повинні мати змогу розглядати потенційні зміни інтерфейсу користувача. Наприклад, попередні версії селену використовували розташування для ідентифікації елементів сторінки.

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

Тому важливо заздалегідь зрозуміти недоліки інструменту та скласти тестові кейси таким чином, щоб у разі змін користувальницького інтерфейсу були потрібні лише мінімальні зміни.

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

Переваги

Нижче перераховані різні переваги функціонального тестування:

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

Обмеження

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

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

Недоліки

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

Отже, обидва ці типи тестування необхідні для якісного продукту.

Висновок

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

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

Про автора: Санджай Залавадія - віце-президент з обслуговування клієнтів Зефір , приносить понад 15 років досвіду керівництва в ІТ та службах технічної підтримки.

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

Пропоноване читання => Підручник з тестування функцій

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

• Функціональне тестування проти нефункціонального тестування
• Альфа-тестування та бета-тестування (повний посібник)
• Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
• Різниця між модульним тестуванням, інтеграційним тестуванням та функціональним тестуванням
• Типи тестування програмного забезпечення: різні типи тестування з деталями
• Spock для інтеграції та функціональних випробувань із селеном
• Повне керівництво з тестування перевірки складання (тестування BVT)
• Повний посібник з функціонального тестування для початківців