Меню

Просто ръководство за тестване на оперативната съвместимост (с примери)

simple guide interoperability testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Преди да разберете техниката на „Тестване на оперативната съвместимост“ , Нека първо разберем термина „оперативна съвместимост“.

swf файлове, които не се възпроизвеждат в браузъра

Оперативната съвместимост е способността на една система да взаимодейства с друга система. Това взаимодействие е между 2 различни системи или 2 различни приложения заедно.

Много често оперативната съвместимост се бърка с Интеграция , съвместимост и преносимост. Е, има разлики между тези техники.

Какво е тестване на оперативната съвместимост

Нека първо започна, като обясня разликите.

Интеграция - Е техника, когато компонентите на една и съща система взаимодействат помежду си. Така че в света на тестване, когато правим тестове за интеграция, ние всъщност тестваме поведението на 2 или повече, най-ниските нива на компонентите на една и съща система.

Съвместимост - Това е техника, при която 2 или повече приложения взаимодействат в една и съща среда. Така че в света на тестване, когато правим тестване за съвместимост; проверяваме дали 2 или повече приложения или системи се държат, както се очаква, в същата среда.

Тук намерението е да се провери дали двете системи изпълняват очакваните си задачи, без да се намесват взаимно в една и съща среда. Подобно - MS Word и калкулаторът са 2 различни приложения и те изпълняват очакваното си поведение независимо в една и съща операционна система. Затова казваме, че тези 2 приложения са съвместими помежду си.

Преносимост - Дали е техника, когато дадено приложение или система се държи както се очаква при преместването им в друга среда. Така че в Преносимост тестване, ние експортираме приложението в друга среда и тестваме поведението му. Например, ако има приложение, което работи добре в Windows XP, трябва да работи добре и в Windows 10.

Оперативна съвместимост - Е техника, как приложението взаимодейства с друго приложение. Така че, когато правим тестване на оперативната съвместимост, ние проверяваме как данните от 1 приложение се прехвърлят в друго приложение без предварително намекване, по смислен начин, и се обработват допълнително, за да дадат приетия изход.

Тази конкретна статия се фокусира върху тестването за оперативна съвместимост (IOT), така че нека запазим фокуса си върху оперативната съвместимост. :)

Какво ще научите:

Тестване на оперативната съвместимост - кратко въведение

Оперативна съвместимост = Inter + операбилен

Интер - означава „помежду ни”, „помежду си”, „взаимно”

Операбилен - означава „способен да изпълни дадената задача“

Така че комбинирането на двата термина заедно - оперативната съвместимост означава 2 (или повече) системи, способни да изпълняват самостоятелно зададената си задача и способни да комуникират помежду си, както се очаква, без да засягат тяхната индивидуално определена функционалност.

Пример # 1:Вземете пример за резервация на вашия полет. Помислете, че трябва да пътувате от Ню Делхи до Ню Йорк. Сега нямате директен полет. Трябва да пътувате от Ню Делхи до Лондон и след това да вземете свързващ полет от Лондон до Ню Йорк. Тъй като имате ограничения във времето, резервирате полета си от Ню Делхи до Лондон в авиолиниите „Jet Airways“ и от Лондон до Ню Йорк в „Virgin Atlantic“. Това означава, че всички ваши данни за пътниците са преминали от Jet Airways до Virgin Atlantic. И така, тук, Jet Airways и Virgin Atlantic, и двете са независимо приложение и заедно, и докато резервирате вашия полет, вашите данни за резервация са обменени от Jet Airways до Virgin Atlantic по смисъл пълен начин, без предварително намекване.

Пример # 2:В подобни редове помислете за системата на болничната администрация, където записите на пациентите се обменят между 1 отдел и друг отдел. Така че тук отделът може да бъде свързан с приложение. Данни за пациента се обменят между 1 приложение с друго приложение без предварително уведомление.

И така, защо трябва да правим IOT?

Ще трябва да направим теста за оперативна съвместимост, за да гарантираме това

  • Приложенията в мрежата изпълняват очакваното си поведение независимо,
  • Може да обменя информация без предварително уведомление
  • Информацията / данните се обменят, без да се прекъсва индивидуалното очаквано поведение
  • Данните / информацията, които се обменят, не се променят или променят

Как да направя тестване за оперативна съвместимост?

Можем да следваме Deeming колелото (PDCA цикъл), за да извършим теста за оперативна съвместимост.

# 1) План

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

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

Бих препоръчал също така всяко приложение да бъде напълно функционално тествано без дефекти, преди да го подготвите за тестване на оперативната съвместимост. Така че, когато планирате, не мислете само за 1 или 2 приложения, помислете за всички приложения като за една единица. Трябва да имате птичи поглед, когато планирате тази техника за тестване. Излишно е да казвам това - документирайте плана си.

Можем да използваме нашите стандартен документ за план за изпитване и да го приспособите малко според изискването за документиране на планирането на IOT. След като планът ви за изпитване е на място, продължете напред, за да изведете условията си за тест.

Фокусът върху извеждането на вашето тестово състояние не трябва да се ограничава до отделните приложения; вместо това трябва да се основава на потока от данни през всички приложения. Условията трябва да бъдат проектирани по такъв начин, че ако не всички, но повечето приложения в мрежата да бъдат обходени.

След като условията на теста ви бъдат идентифицирани, преминете към дизайна или скрипта (в случай че планирате да автоматизирате) вашите тестови случаи. Можеш създайте RTM (Изисквания за проследяване на матрицата) за картографиране на вашите тестови случаи с тестови условия и вашите тестови условия с тестови условия / изисквания за приемане.

Когато работите в мрежа, отново е важно да планирате и нефункционални тестови дейности. Това може да не е написано или документирано никъде, но е задължително да се провери за нефункционалните аспекти на системата като цяло. Тези нефункционални области ще включват производителност и сигурност. Ако е необходимо, можете да създадете отделен план за функционално тестване, тестване на производителността и тестване на сигурността; или създайте единен план и различен документ за условията на изпитване за всеки от тези видове тестване.

# 2) Направете

Do - е интервалът от време, в който действително извършвате изпълнението си. Планирайте съответно времето си, за да изпълните функционалното и нефункционалното тестване. Ние следваме цикъла на тестване в тази фаза на изпълнение на случаите, регистриране на дефектите, проследяване на екипа за разработка, за да ги разрешим, извършване на повторен тест и регресионен тест на системата като цяло, докладване на резултатите от теста и преместване в закриване.

# 3) Проверете

Проверка - Фазата ли е, когато преразглеждаме резултатите от теста си и се опитваме да картографираме тези с RTM и да проверим дали всички очаквани изисквания са изпълнени и дали всички приложения са обходени. Проверяваме дали данните се обменят и обменят правилно и гладко между приложенията / системите. Също така ще трябва да потвърдим, че данните, които се обхождат, не се променят.

Помислете също така да направите ретроспекция на целия процес на тестване на оперативната съвместимост. Идентифицирайте областите, които са работили добре, тези, които не са се справили добре, и всички действия, за които трябва да се погрижите.

# 4) Закон

Закон - Е да се действа по ретроспективните елементи. Точките, които бяха идентифицирани като „добри практики“, продължават да изпълняват тези и точките, които биха могли да бъдат по-добре обработени, идентифицират стъпките за коригиране на тези и действат по съответния начин. Имайте предвид едно нещо, че областите или стъпките, които не са работили добре, НЕ трябва да се повтарят. В края на краищата трябва да се учим от грешките си и да не ги повтаряме.

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.

как да извлечете 7z файлове на

Както в този пример, виждаме, че „Отдел за поддръжка“ е приложението, което е изходна точка за всички (по-голямата част) от приложението, следователно усилията за тестване за това конкретно приложение са малко повече в сравнение с други приложения.

Предизвикателства:

  1. Трудно е да се тества цялото приложение с всички пермутации и комбинации.
  2. Приложенията се разработват в различни хардуерни / софтуерни комбинации и се инсталират в различни среди, така че ако някоя от околната среда не работи, това влияе на тестването.
  3. Поради различния софтуер и среди, определянето на стратегията за тестване и нейното изпълнение е голяма задача.
  4. Стимулирането на средата за провеждане на теста е голямо предизвикателство.
  5. В случай на дефект, извършването на анализ на основната причина е голямо предизвикателство.
  6. Тъй като приложенията са в мрежа, има моменти, когато мрежата не работи. Поради това тестването също се повлиява.

Как мога да смекча тези предизвикателства?

1) Опитайте се да използвате техниките за предварително тестване като:

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

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

2) Опитайте се да идентифицирате някои исторически данни като - при какви обстоятелства системите са били в работно състояние, колко време е необходимо, за да се върне в действие. В този случай се опитайте да изпълните тези сценарии, чиито приложения не са засегнати, или използвайте времето за документиране на сценариите и докладване на резултатите. Освен това винаги, когато планирате или планирате тестването, винаги разглеждайте тези исторически данни като вход за вашата оценка и планирайте съответно.

3) ПЛАН - Използвайте исторически данни, предишен опит, умения на екипа, фактори на околната среда, за да идентифицирате стратегията на тестването. Колкото по-добър е вашият план, толкова по-добро ще бъде изпълнението ви.

4) Започнете да работите по подготовката на средата много по-рано от действителното ви изпълнение. Излишно е да казвам - планирайте стъпките си, когато подготвяте околната среда. Уверете се, че вашата среда е настроена, готова и работеща, когато започне изпълнението ви.

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

6) Както е обсъдено в точка 2, планирайте дейността си. Ако е планирано прекъсване, трябва да обмислите този престой, когато планирате тестването си.

Тест за оперативна съвместимост на мобилни телефони:

В Mobiles правим тест за оперативна съвместимост, когато се появи ново приложение ( Мобилно приложение ) стартира. Има много области, които трябва да вземем предвид при планирането на това тестване на мобилни устройства:

  • Видовете мобилни устройства, предлагани на пазара, са огромни. Ще трябва да посочите кои всички видове устройства бихте обмислили за вашето тестване. Ще трябва да сдвоите тип устройство заедно с поддържаната от него операционна система.
  • Всички мобилни ОС са разработени на различен език за програмиране. Следователно приложението трябва да бъде тествано спрямо всички вариации на ОС.
  • Разбиране на правните фактори и свързаните с региона договори.
  • Размерът / разделителната способност на различните устройства са различни.
  • Въздействието върху мобилните вградени приложения също трябва да се има предвид.

Така че, за да правите IOT на мобилни телефони, ще ви е необходимо да планирате и създадете RTM точно както направихме за компютърно базирано тестване на приложения.

Намерението, стратегията, рисковете и изпълнението биха били същите, но инструменти и техники би било различно в случай на мобилни телефони.

Заключение:

Тестването на оперативна съвместимост е огромна задача. Тази техника изисква правилно планиране, което трябва да започне паралелно, когато започне планирането на системни тестове.

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

Това може да се случи, че да не постигнете 100% покритие , но трябва да сме достатъчно умни, за да подберем нашите случаи по такъв начин, че повечето приложения да бъдат обхванати в един поток, като използваме добри техники за писане на тестови случаи.

Надявам се тази статия да е била полезна за разбиране на техниката за тестване на оперативната съвместимост. Уведомете ни за вашите запитвания / коментари.

Препоръчително четене

^