Розбиття еквівалентності в тестуванні програмного забезпечення – це техніка тестування “чорного ящика “, яка допомагає створювати ефективні тестові кейси без шкоди для тестового покриття.
У цій статті ми розглянемо, що таке розбиття класів еквівалентності, чому воно корисне, а також вивчимо деякі процеси та підходи, які можна використовувати для розкриття переваг цієї техніки.
Що таке розбиття класів еквівалентності
у тестуванні програмного забезпечення?
Будь-яке програмне забезпечення має певні вхідні умови. У контексті тестування програмного забезпечення ці вхідні умови описують значення або дані, які тестувальник повинен використовувати для перевірки якості та функціональності програмного забезпечення. Ці дані можуть бути як простим клацанням миші, так і текстом і цифрами.
Еквівалентне розбиття в тестуванні програмного забезпечення досліджує різні вхідні дані, необхідні для використання програмного забезпечення, і групує їх у класи еквівалентності, тобто набори вхідних даних, які будуть мати еквівалентний вплив на поведінку програмного забезпечення.
Якщо ви знаєте, як поводитиметься кожна група вхідних даних, вам не потрібно тестувати кожного представника групи. Таким чином, розбиття на класи еквівалентності є чудовим способом допомогти тестувальникам зменшити частоту надлишкових тестів. У світі гіперконкурентної розробки програмного забезпечення з дедалі жорсткішими дедлайнами, економія часу та зусиль у життєвому циклі тестування програмного забезпечення (ЖЦПЗ) має вирішальне значення.
Нарешті, варто зазначити, що тестування еквівалентності – це метод тестування “чорної скриньки”. Коротше кажучи, це означає, що тестувальникам не потрібно знати про внутрішній код або внутрішню роботу програми. Тести базуються на входах, виходах і зовнішній поведінці. Таким чином, ці тести зосереджені на поведінці користувача під час використання програми.
1. Поділ еквівалентності тестування програмного забезпечення в двох словах
Розбиття еквівалентності розділяє вхідні дані для тестування програмного забезпечення на два табори: допустимі та недопустимі вхідні дані. Значення у кожному розділі мають спричиняти однакову поведінку програми. Наприклад:
- Якщо умова для одного значення в розділі A є істинною, то й інші значення в розділі A також повинні бути істинними.
- Аналогічно, якщо умови одного значення в частині A є хибними, інші значення в частині A також повинні бути хибними.
У контексті тестування кожен розділ повинен бути покритий принаймні один раз. Логічно це означає, що якщо один вхід у розділі А вийде з ладу, то всі інші входи також вийдуть з ладу. Цей процес має заощадити час, оскільки замість того, щоб тестувати кожен вхід, який знаходиться в розділі А, тестувальники можуть протестувати лише один і екстраполювати результат на основі їхніх спільних ознак.
2. Чому тестування класів еквівалентності в тестуванні програмного забезпечення є важливим
Перш ніж перейти до безпосередніх переваг тестування класів еквівалентності в тестуванні програмного забезпечення, ми повинні визначити, чому цей підхід є важливим.
Всі тестувальники розуміють, що тестування програмного забезпечення вимагає компромісів. Час і бюджети обмежені, а це означає, що тестувальники повинні максимально ефективно використовувати свої ресурси. Розбиття еквівалентності тестування програмного забезпечення допомагає командам знайти баланс між ефективністю та надійністю при тестуванні, зменшуючи кількість вхідних даних.
Переваги розбиття за еквівалентністю
у тестуванні програмного забезпечення
Команди тестувальників віддають перевагу еквівалентному поділу в тестуванні програмного забезпечення з різних причин. Ось деякі з найбільш переконливих.
1. Ефективність
Великою перевагою тестування еквівалентності розділів є його ефективність. Коли тестувальники використовують розбиття еквівалентності, вони можуть зменшити кількість необхідних тестових кейсів без шкоди для тестового покриття. Вибравши вхідні дані з кожного класу еквівалентності, тестувальники можуть бути впевнені, що вони розуміють, як працює їхнє програмне забезпечення з різними вхідними даними.
2. Простота
Ще однією великою перевагою розділення еквівалентності при тестуванні програмного забезпечення є простота. Розбиття різноманітного набору вхідних даних на достовірні та недостовірні означає, що планування тестів значно спрощується. Тестування кожного входу окремо вимагає багато документації та координації. Скорочення до одного репрезентативного прикладу спрощує процес тестування.
Розширене покриття
Використання класів еквівалентності в тестуванні також дозволяє ефективніше використовувати час тестування. Зменшення кількості вхідних даних у класах означає, що ви можете ретельніше протестувати кожен клас. Такий комплексний підхід був би відверто неможливим, якби ви тестували кожен вхід окремо. Розбиття на частини за еквівалентністю дозволяє командам ретельно перевіряти достовірні та недостовірні дані, граничні випадки, граничні значення тощо.
3. Можливість багаторазового використання
Початковий час, який ви інвестуєте у створення кожного класу еквівалентності при тестуванні програмного забезпечення, окупиться згодом, якщо ви будете використовувати ці класи для майбутніх вхідних тестів. Хоча не всі розділи будуть актуальними для майбутніх тестів, ті, що будуть, заощадять вам багато часу в майбутніх проектах або навіть в ситуаціях регресійного тестування.
Недоліки розбиття за еквівалентністю
у тестуванні програмного забезпечення
Хоча розбиття на розділи еквівалентності пропонує деякі основні переваги, воно не є ідеальним рішенням для кожного сценарію. Розглянемо деякі з його обмежень.
1. Порядок введення
У певних ситуаціях порядок введення даних є важливою частиною тестування функціональності програми. Це не те, що ви дійсно можете скоротити за допомогою розбиття на розділи за еквівалентністю. Тестувальники повинні пам’ятати про такі ситуації і використовувати альтернативні методи для забезпечення хорошого покриття.
2. Складні вхідні залежності
Складне програмне забезпечення зі складними вхідними залежностями є ще однією сферою, де виявляються обмеження еквівалентного розбиття. Наприклад, програмне забезпечення, яке виводить розрахунки на основі різних вхідних даних. У цьому сценарії тестувальники повинні використовувати різні методи, щоб зменшити комбінаторний вибух і підвищити ймовірність ізолювання дефектів.
Альтернативні підходи, що доповнюють
обмеження перевірки еквівалентності
Хоча тестування на еквівалентність розділів підходить для багатьох тестових сценаріїв, дуже складне програмне забезпечення зі складними залежностями між вхідними значеннями може вимагати додаткових додаткових підходів.
Коли справа доходить до написання тестових кейсів для складного програмного забезпечення, використання комбінації цих підходів є гарною ідеєю.
1. Парне тестування
Парне тестування – це техніка тестування програмного забезпечення, яка перевіряє всі можливі комбінації кожної пари вхідних параметрів. Такий підхід гарантує, що кожна пара параметрів тестується разом принаймні один раз.
2. Тестування таблиці рішень
Таблиця рішень допомагає тестувальникам методично відобразити різні комбінації вхідних даних. Це хороший спосіб забезпечити систематичне покриття за наявності складних залежностей.
3. Тестування державного переходу
Цей тип тестування вимірює, як програмне забезпечення переходить між різними станами у відповідь на різні комбінації вхідних даних.
4. Тестування на основі моделей
Цей підхід вимагає створення моделі, заснованої на внутрішній логіці програмного забезпечення, і використання інструменту автоматизації для створення тестових кейсів на основі цієї моделі. Цей метод добре справляється зі складністю та забезпечує адекватне покриття.
Приклади тестування розбиття класів еквівалентності
Найкращий спосіб зрозуміти розбиття еквівалентності – це подивитися, як і де ви можете використовувати клас еквівалентності в тестуванні програмного забезпечення. Ось кілька прикладів, які допоможуть вам краще уявити цю концепцію.
1. Приклад тестування розбиття класів еквівалентності #1
Онлайн-форма замовлення є хорошим прикладом класу еквівалентності в тестуванні програмного забезпечення.
Припустимо, ви створюєте додаток для інтернет-магазину стаціонарного обладнання. Існує типовий бланк замовлення на заставу паперу формату А4. Ось як ви можете використовувати класи еквівалентності для тестування цієї форми.
Класи еквівалентності:
Кількість паперу формату А4 знаходиться в певному діапазоні, наприклад, від 1 до 100. Отже, три класи:
- 1 до 100
- Числа менше 1
- Числа понад 100.
Тестові кейси:
Необхідно виконати три тестові кейси з наступними очікуваними результатами
- Будь-яке число від 1 до 100 = Замовлення оброблено
- Числа менше 1 = повідомлення про помилку
- Числа більше 100 = повідомлення про помилку
2. Приклад тестування еквівалентності розбиття #2
Клас еквівалентності в тестуванні програмного забезпечення може мати справу не лише з числами. У цьому прикладі ми розглянемо, як можна використовувати той самий принцип для перевірки порталу для завантаження файлів. Припустимо, вам потрібно протестувати сайт, який вимагає від користувачів завантажувати документи, що посвідчують особу, але ви можете приймати лише певні формати.
Класи еквівалентності:
- Підтримуються документи у форматі PDF та JPEG.
- Непідтримувані документи – це всі інші формати документів
- Документ відсутній
Тестові кейси:
- Перевірте, завантаживши PDF або JPEG = успішне завантаження
- Тест із завантаженням непідтримуваного формату = повідомлення про помилку
- Тест без завантаження файлу = повідомлення про помилку
Як реалізувати розбиття за еквівалентністю
підхід до тестування програмного забезпечення
Якщо ви хочете використовувати класи еквівалентності в тестуванні, вам потрібно застосувати стратегічний підхід. Ось корисний покроковий посібник з реалізації розбиття на частини еквівалентності в тестуванні програмного забезпечення.
Крок 1: Визначте вхідні змінні
Кожне програмне забезпечення реагує на різні вхідні змінні. Для складного програмного забезпечення ці змінні можуть бути величезними. Отже, перегляньте вимоги до програмного забезпечення та специфікації і визначте всі змінні, які впливають на поведінку програмного забезпечення.
Деякі з найбільш очевидних вхідних даних включатимуть форми введення даних користувача. Однак вам потрібно розглянути ширший діапазон вхідних даних для вашого списку. Ви також можете враховувати змінні оточення, виклики API, внутрішні обчислення тощо.
Далі ви повинні зрозуміти різні типи змінних даних. Ви можете класифікувати ці змінні як цілі, логічні, рядкові тощо, щоб визначити відповідні розділи.
Нарешті, вам потрібно вивчити вхідні обмеження. Це будуть такі речі, як дозволені символи, визначені формати та мінімальні/максимальні значення.
Крок другий. Визначення дійсних і недійсних розділів
Подивіться на кожну вхідну змінну і почніть розділяти їх на допустимі та недопустимі результати. Це будуть ваші класи еквівалентності під час тестування.
1. Дійсні розділи
Допустимі перегородки можна розділити на два класи.
Позитивні класи еквівалентності:
Значення, з якими, як ви очікуєте, ваше програмне забезпечення успішно впорається. Наприклад, для програмного забезпечення, яке записує відсоткові оцінки, дійсними є значення від 0 до 100.
Негативні класи еквівалентності:
Ця категорія призначена для значень, які виходять за межі очікуваного введення, але які ваша програма повинна обробити з повідомленням про помилку. Наприклад, якщо ввести 110 для відсоткової оцінки, програма видасть повідомлення про помилку: “Усі значення мають бути від 0 до 100”.
2. Неправильні розділи
Ці класи еквівалентності включатимуть входи, які спричинятимуть помилки або неочікувану поведінку. У нашому прикладі вище це може включати спроби ввести A+ або B або подібні дані у відсоткову оцінку. Хоча ці дані можуть бути технічно правильними, вони не відповідають числовим очікуванням.
#3. Написання ефективних тестових кейсів
Далі вам потрібно розробити тестові кейси, які охоплюють кожен розділ еквівалентності хоча б один раз. Як згадувалося раніше у статті, це забезпечує належне покриття тестів.
Перш за все, ви повинні вибрати репрезентативні значення в межах кожного розділу еквівалентності, які можуть охоплювати як достовірні, так і недостовірні дані.
Поради щодо написання надійних тестових кейсів
- Подумайте про граничні значення: Переконайтеся, що ви перевірили межі ваших розділів. Мінімальний, максимальний, інклюзивний, ексклюзивний і т.д., оскільки ці області є сильними кандидатами для помилок. Наприклад, якщо ваші вхідні очікування знаходяться в діапазоні від 0 до 100, перевірте від’ємні значення, а також числа типу 101.
- Розгляньте позитивні та негативні тестові сценарії як для валідних, так і для невалідних тестових кейсів.
- Комбіноване тестування – хороша ідея. Використовуйте кілька різних підходів, описаних у розділі “Альтернативні підходи”, щоб доповнити обмеження, описані в розділі “Перевірка еквівалентності” вище.
- Задокументуйте обґрунтування того, чому вхідні значення були розділені на певні частини, і чітко окресліть очікувану поведінку кожного тесту
- Де це можливо, використовуйте візуальні інструменти, щоб внести ясність і об’єктивність у ваші тестові кейси, використовуючи діаграми або таблиці, щоб відобразити ваші розділи.
#4. Плануйте та виконуйте свої тестові кейси
Розставляйте пріоритети на основі таких факторів, як
- Які зони найчастіше мають дефекти
- Які сценарії, найімовірніше, спричинять важкі сценарії, такі як збої або зависання
Потім виконайте тести і запишіть результати та будь-які помилки, що виникли. Для складних програм з великою кількістю вхідних даних ви можете використовувати інструменти RPA для імітації дій користувача.
#5. Проаналізуйте результати
Об’єднайте зібрані тестові дані та проаналізуйте результати. Деякі методи, які вам потрібно використовувати, полягають у наступному:
- Перегляньте кожен тестовий кейс і порівняйте фактичні результати з очікуваними
- Знайдіть будь-які розбіжності, дослідіть і повідомте про будь-які помилки та дефекти.
#6 Додаткові поради
Хоча ці поради не будуть застосовні в кожному сценарії, вони виявляться корисними для складного тестування програмного забезпечення.
- Таблиці рішень – це чудовий спосіб візуалізувати ваші розділи еквівалентності та різні комбінації вхідних даних, які ви можете використовувати
- Ви можете об’єднати класи еквівалентності, якщо вони демонструють майже ідентичну поведінку, що ще більше оптимізує процес тестування
- Використовуйте тестування граничних значень для покращення виявлення дефектів
- Де можливо, автоматизуйте тестові кейси розбиття на розділи еквівалентності
Розбиття еквівалентності та аналіз граничних значень
Розбиття на розділи за еквівалентністю ґрунтується на припущенні, що кожен тест у межах розділу дасть однаковий результат. Хоча це вірно в багатьох ситуаціях, це не завжди спрацьовує. Наприклад, будь-які дані, додані до розділу помилково, можуть залишитися неперевіреними, що призведе до зменшення покриття та потенційної нестабільності програмного забезпечення в майбутньому.
Вирішенням цієї проблеми є тестування граничних значень. Це дозволяє командам тестувальників зосередитися на областях, які, найімовірніше, містять ризики, і тестувати програмне забезпечення на цій основі. Коротше кажучи, він припускає, що ризики, найімовірніше, виникають на краях або межах вхідних розділів. Тому тестувальники можуть писати тестові кейси для верхньої та нижньої меж вхідних даних, на додаток до інших тестових кейсів класу еквівалентності.
Розподіл та автоматизація еквівалентності за допомогою ZAPTEST
Інструменти автоматизації тестування програмного забезпечення, такі як ZAPTEST, можуть допомогти командам автоматизувати розбиття еквівалентності як під час створення тесту, так і під час його виконання.
Давайте розглянемо, як ZAPTEST може допомогти вам розкрити переваги цього корисного підходу до тестування за допомогою чорного ящика.
1. Вибір інструменту
Вибір правильного інструменту для роботи дуже важливий. Більшість інструментів автоматизації тестування спеціалізуються на веб-, мобільному або десктопному тестуванні. ZAPTEST може працювати з тестуванням на різних платформах і додатках, що робить його надійним вибором.
2. Написання та виконання тестових кейсів
ZAPTEST 1Script дозволяє сканувати користувальницький інтерфейс для автоматизації тестування. Крім того, ви також можете сканувати макети додатків, якщо ви перебуваєте на ранній стадії розробки. Використовуючи функцію Scan GUI, ZAPTEST просканує всі тестові об’єкти і додасть їх до списку об’єктів.
Звідси ви можете додавати об’єкти на діаграму і створювати кроки тестування.
ZAPTEST дозволяє автоматизувати написання кейсів за допомогою простого інтерфейсу перетягування. Для створення тестових кейсів за допомогою ZAPTEST вам не потрібні навички програмування. Отже, звідси ви можете вибрати відповідну операцію з випадаючого списку і створити тестовий приклад на основі вхідних значень, необхідних для вашого інтерфейсу. Потім ви можете створити тестові кейси для кожної еквівалентності та виконати свої тестові кейси. Ви навіть можете повторно використовувати тестові кейси та редагувати їх у редакторі кроків, заощаджуючи багато часу.
3. Звітність та управління тестовими кейсами
ZAPTEST дозволяє запускати тестові кейси паралельно, що значно економить час. Це може допомогти вам запустити велику кількість різних розділів еквівалентності одночасно або запустити певні групи тестів.
Результати легко збирати завдяки детальним звітам про невдачі, скріншотам, журналам виконання та метрикам продуктивності, пов’язаним з кожним тестовим кейсом.
4. Обслуговування тестових кейсів
Ви також можете просто відстежувати і підтримувати свої тестові кейси завдяки якісним можливостям контролю версій. Більше того, користувачі ZAPTEST можуть клонувати і повторно використовувати тести для досягнення нового рівня ефективності.
ZAPTEST пропонує набагато більше функціональних можливостей, окрім автоматизації тестових кейсів. Завдяки набору інструментів RPA, ZAPTEST пропонує функціональність 2-в-1, долаючи розрив між DevOps і BizOps в майбутньому, позначеному гіперавтоматизацією, де все, що може бути автоматизовано, буде автоматизовано.
Заключні думки
Розбиття на частини еквівалентності – це елегантне рішення для ситуацій, коли тестувальники повинні знайти баланс між ефективністю і точністю. З деяким програмним забезпеченням, що допускає майже нескінченний діапазон вхідних даних, розбиття на класи еквівалентності допомагає командам розбивати дані тестування на керовані, невеликі шматки, кожен з яких може бути ретельно протестований.
