Меню

Просте керівництво з тестування сумісності (із прикладами)

simple guide interoperability testing

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

До розуміння техніки “Тестування сумісності” , Давайте спочатку зрозуміємо термін “взаємодія”.

Сумісність - це здатність однієї системи взаємодіяти з іншою системою. Ця взаємодія відбувається між 2 різними системами або 2 різними додатками разом.

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

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

Спершу дозвольте мені пояснити відмінності.

наскрізне тестування проти регресійного тестування

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

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

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

Переносимість - Це техніка, коли програма або система поводиться належним чином при переміщенні в інше середовище. Так у Переносимість тестуючи, ми експортуємо додаток до іншого середовища та перевіряємо його поведінку. Мовляв, якщо є програма, яка добре працює в Windows XP, вона також повинна добре працювати в Windows 10.

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

Цей конкретний документ зосереджений на тестуванні сумісності (IOT), тому давайте зосередимося на взаємодії. :)

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

Тестування сумісності - короткий вступ

Сумісність = Інтер + операбельна

Інтер - означає 'між собою', 'один в одному', 'взаємний'

Працює - означає 'здатний виконати поставлене завдання'

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

Приклад №1:Візьміть приклад бронювання літака. Вважайте, що вам потрібно подорожувати з Нью-Делі до Нью-Йорка. Зараз у вас немає прямого рейсу. Вам доведеться подорожувати з Нью-Делі до Лондона, а потім брати перельоти з Лондона до Нью-Йорка. Оскільки у вас є певні обмеження в часі, ви резервуєте рейс з Нью-Делі до Лондона на рейсах 'Jet Airways' та з Лондона до Нью-Йорка на 'Virgin Atlantic'. Це означає, що всі ваші дані про пасажира були переправлені від Jet Airways до Virgin Atlantic. Тож тут, Jet Airways та Virgin Atlantic, обидва є незалежною програмою разом, і, зарезервувавши рейс, ваші дані про бронювання були обмінені з Jet Airways на Virgin Atlantic у повному сенсі, без попередніх натяків.

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

То чому нам потрібно робити IOT?

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

  • Програми в мережі виконують очікувану поведінку самостійно,
  • Може обмінюватися інформацією без попереднього повідомлення
  • Інформація / дані обмінюються, не перериваючи очікувану поведінку індивіда
  • Дані / інформація, якими обмінюються, не змінюються та не змінюються

Як зробити тестування на сумісність?

Ми можемо слідувати колесу оцінки (цикл PDCA), щоб провести тестування на сумісність.

# 1) План

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

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

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

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

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

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

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

# 2) Роби

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

# 3) Перевірка

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

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

No4) Акт

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

5 кроків:

  1. Визначте всі програми, які є частиною мережі.
  2. Визначте їх відповідні функціональні можливості.
  3. Для кожної програми визначте необхідні вхідні дані та вихідні дані, які він повертає.
  4. Визначте ті дані, які проходили б по всіх / більшості програм.
  5. Визначте очікувану поведінку для кожної комбінації програми та дати, яку потрібно перевірити

Документуйте це.

Розглянемо малюнок нижче:

5 кроків

На основі малюнка спробуємо відтворити 5 ½ кроків:

  1. Програма 1, Програма 2, Програма 3 та Програма 4 - це 4 різні системи.
  2. Кожна з цих систем має певний набір функціональних можливостей, які необхідно визначити.
  3. Потрібно визначити вхідні та вихідні дані кожної системи.
  4. У випадку Application1 він видає 2 виходи. 1 вихід формує вхідну програму 3, а 1 вихід формує вхідну програму 2. Вихідний додаток 2 формує вхідну інформацію 3-ї програми та 4-ї програми тощо.
  5. Дійсність для кожного з вхідних та вихідних даних перевіряється. Основним моментом, який слід врахувати тут, є те, що дані, які обробляються у формі вводу-виводу, не змінюються, І всі програми охоплюються.

½ Цей показник у реальному житті може здатися не таким простим. Це насправді призводить до більш складної структури з n числами вхідних та вихідних умов.

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

Приклад:

Давайте розглянемо приклад проведення тесту на взаємодію для “Системи управління лікарнею”

Лікарня складається з наведених нижче відділів та підрозділів;

Система управління лікарнею

Тут кожен відділ є додатком сам по собі. Кожен відділ (додаток) має свій власний підрозділ (модулі), а кожен модуль має свої підрозділи.

Отже, щоб розглянути сферу застосування IOT, ось кілька умов тестування:

  1. Пацієнт, який зіткнувся з ДТП (відділення OPD - нещасний випадок), повинен пройти операцію на нозі (лор - загальна хірургія), потім повинен пройти фізіотерапію (допоміжне відділення - фізіотерапія), а потім отримати виписку (відділ підтримки - закриття)
  2. Дитині, яка потрапила до критичної допомоги (Педіатрія - критична допомога), потрібно пройти оперативне втручання (Педіатрія / ЛОР - загальна хірургія), а потім виписати (Відділ підтримки - закриття / PR)
  3. Зовнішній пацієнт звертається до лікаря загальної практики (відділення OPD); приймає призначені ліки (відділ підтримки - аптека) і відходить.
  4. Майбутня мама приїжджає на регулярні огляди (гінекологічне відділення - догляд за матір'ю та дитиною), приймає призначені ліки (відділ підтримки - аптека) і відходить.
  5. Стоматолог робить кореневий канал (стоматологічне відділення), приймає призначені ліки (відділ підтримки - Аптека) і відходить.
  6. Пацієнт приходить у OPD (загальний лікар), проходить лікування в (Акушерсько-гінекологічне відділення - акушерство високого ризику), приймає призначені ліки (відділ підтримки - Аптека) і виписується

Таким чином ми визначаємо всі умови тестування; маючи на увазі, що більша частина відділу повинна бути охоплена.

Ми можемо намалювати RTM, щоб відобразити висвітлення як:

RTM

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

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

Проблеми:

  1. Важко протестувати всю програму з усіма перестановками та комбінаціями.
  2. Додатки розробляються в різних комбінаціях апаратного / програмного забезпечення та встановлюються в різних середовищах, тому якщо будь-яке із середовища не працює, це впливає на тестування.
  3. Через різне програмне забезпечення та середовища визначення стратегії тестування та її виконання саме по собі є великим завданням.
  4. Стимулювати середовище для проведення тесту - це велика проблема.
  5. У разі будь-яких дефектів проведення аналізу корінних причин є великим викликом.
  6. Оскільки програми знаходяться в мережі, інколи мережа не працює. Через це тестування також впливає.

Як я можу пом'якшити ці виклики?

1) Спробуйте використовувати методи попереднього тестування, такі як:

  • OATS (техніка тестування ортогонального масиву)
  • Діаграми переходу держави,
  • Графіки причин і наслідків
  • Еквівалентність порціонування та граничний аналіз.

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

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

3) ПЛАН - Використовуйте історичні дані, минулий досвід, вміння команди, фактори навколишнього середовища для визначення стратегії тестування. Чим кращий ваш план, тим кращим буде ваше виконання.

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

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

6) Як обговорювалось у пункті 2, сплануйте свою діяльність. Якщо це планове відключення, ви повинні врахувати цей час простою, коли плануєте тестування.

Тест сумісності на мобільних телефонах:

У програмі Mobiles ми проводимо тест на сумісність кожного разу, коли новий додаток ( Мобільний додаток ). Плануючи це тестування на мобільних пристроях, ми повинні врахувати багато областей:

  • Типів мобільних пристроїв, доступних на ринку, величезна. Вам потрібно буде перерахувати, які типи пристроїв ви розглядаєте для тестування. Вам потрібно буде з'єднати тип пристрою разом із підтримуваною ОС.
  • Всі мобільні ОС розроблені різною мовою програмування. Отже, додаток потрібно перевірити на всі варіанти ОС.
  • Розуміння правових факторів та регіональних контрактів.
  • Розміри / роздільна здатність різних пристроїв різні.
  • Також слід враховувати вплив на вбудовані мобільні програми.

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

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

Висновок:

Тестування сумісності - величезне завдання. Ця техніка вимагає правильного планування, яке повинно починатися паралельно, коли починається планування системних тестів.

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

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

Сподіваюся, ця стаття була корисною для розуміння техніки тестування сумісності. Повідомте нам про ваші запитання / коментарі.

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

^