Меню

Що таке тестування компонентів або модульне тестування (Дізнайтеся на прикладах)

what is component testing

Спробуйте Наш Інструмент Для Усунення Проблем

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

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

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

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

Як відсортувати масив цілих чисел у Java - -

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

Що таке тестування компонентів

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

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

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

Тестування компонентів

Це своєрідне тестування білої скриньки.

Отже, тестування компонентів шукає помилки та перевіряє роботу модулів / програм, які можна перевірити окремо.

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

Тестування компонентів

Мета тестування компонентів

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

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

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

  • План випробувань проекту
  • Системні вимоги
  • Технічні характеристики компонентів
  • Впровадження компонентів

Хто проводить тестування компонентів?

Тестування компонентів проводиться службами контролю якості або тестером.

Що перевіряється в рамках тестування компонентів?

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

Це може бути тестування поведінки ресурсів (наприклад, визначення витоків пам'яті), тестування продуктивності, структурні тестування тощо.

Коли тестування компонентів завершено?

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

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

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

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

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

Тестування стратегії тестування компонентів

Залежно від глибини рівня випробування, випробування компонентів ділиться на дві частини:

  1. Тестування компонентів у малому (ctis)
  2. Тестування компонентів у великих розмірах (CTIL)

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

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

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

Заглушки та драйвери

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

Техніка інтеграційного тестування - це техніка, при якій ми послідовно поєднуємо 2 компоненти та тестуємо інтегровану систему разом. Дані однієї системи передаються іншій системі, а правильність даних перевіряється для інтегрованої системи.

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

Використання як інтеграції, так і компонентів Заглушки та драйвери .

“Водії” це фіктивні програми, які використовуються для виклику функцій найнижчого модуля на випадок, якщо функція виклику не існує.

“Заглушки” може називатися фрагментом коду, який приймає входи / запити від верхнього модуля і повертає результати / відповідь

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

Таким чином ми гарантуємо, що окремі компоненти ретельно перевірені.

окремі компоненти ретельно перевіряються

Тут ми бачимо, що:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— є компонентами
  • C1, C2 і C3 разом складають Субодиницю 1
  • C4 і C5 разом складають підрозділ 2
  • C6, C7 і C8 разом складають підрозділ 3
  • C9 сам по собі робить субодиницю 4
  • Підрозділ 1 і Підрозділ 2 об'єднуються в бізнес-підрозділ 1
  • Підрозділ 3 та Підрозділ 4 об'єднуються в бізнес-підрозділ 2
  • Бізнес-підрозділ 1 та підрозділ 2 об’єднуються для подання заявки.
  • Отже, тестування компонентів, у цьому випадку, мало б протестувати окремі компоненти, які є C1 - C9.
  • Мережа стрілка між підблоком 1 та підрозділом 2 показує точку тестування інтеграції.
  • Подібним чином Мережа стрілка між підрозділом 3 та підрозділом 4 показує пункт тестування інтеграції
  • Зелена стрілка між бізнес-підрозділом 1 та підрозділом 2 показує пункт тестування інтеграції

Отже, ми будемо робити:

  • КОМПОНЕНТ тестування на С1-С9
  • ІНТЕГРАЦІЯ тестування між підрозділами та підрозділами бізнесу
  • СИСТЕМА тестування Програми в цілому

Приклад

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

безкоштовне програмне забезпечення брандмауера для Windows 10

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

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

Перевагами тестування вашої сторінки входу на даний момент буде:

відео конвертер YouTube у формат mp4 - -
  • Інтерфейс користувача перевіряється на зручність використання (орфографічні помилки, логотипи, вирівнювання, форматування тощо)
  • Спробуйте використати методи негативного тестування як автентифікація та авторизація. У цих випадках існує величезна ймовірність виявлення дефектів.
  • Використання таких методів, як ін’єкції SQL забезпечить перевірку порушення безпеки на дуже ранній стадії.

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

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

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

Як написати тестові кейси для компонентів?

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

Нижче наведено зразок фрагмента тесту для компонентів для модуля входу.

Ми можемо писати інші тестові приклади подібним чином.

тестові кейси

Тестування компонентів проти модульного тестування

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

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

Отже, тестування компонентів схоже на модульне тестування, але воно проводиться на більш високому рівні інтеграції та в контексті програми (не лише в контексті цієї модульної програми / програми, як у модульному тестуванні).

Тестування компонента проти інтерфейсу проти інтеграції проти систем

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

Ан інтерфейс - шар, що з'єднує 2 компоненти. Тестування платформи або інтерфейсу, на якому взаємодіють 2 компоненти, називається тестуванням інтерфейсу.

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

Після закінчення тестування інтерфейсу з'являється Інтеграційне тестування .

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

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

Висновок

Я б так сказав Блокове тестування і Тестування компонентів проводиться поряд.

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

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

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

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

^