API тестийн заавар: Эхлэгчдэд зориулсан бүрэн гарын авлага

Энэхүү API-ийн гүнзгий туршилтын заавар нь API тест, вэб үйлчилгээ болон API тестийг танай байгууллагад хэрхэн нэвтрүүлэх талаар бүгдийг тайлбарладаг:

API тестийн талаар гүн гүнзгий ойлголттой болох Энэхүү танилцуулга хичээлээс зүүн тийш шилжих тест болон вэб үйлчилгээний тухай ойлголт.

Вэб API, API хэрхэн ажилладаг (бодит жишээгээр) болон вэб үйлчилгээнээс юугаараа ялгаатай вэ гэх мэт ойлголтуудыг энд жишээн дээр сайн тайлбарласан болно. заавар.

API тестийн хичээлүүдийн жагсаалт

Заавар №1: API тестийн заавар: Эхлэгчдэд зориулсан бүрэн гарын авлага

Заавар №2: Вэб үйлчилгээний заавар: Бүрэлдэхүүн хэсэг, Архитектур, Төрөл & Жишээ

Заавар №3: Шилдэг 35 ASP.Net болон Вэб API ярилцлагын асуултуудын хариулттай

Заавар №4: POSTMAN заавар: API тест POSTMAN-г ашиглах

Заавар №5: Apache HTTP Client ашиглан вэб үйлчилгээг турших

Энэхүү API туршилтын цувралын хичээлүүдийн тойм

Заавар # Та юу сурах вэ
Заавар_№1: API туршилтын заавар : Эхлэгчдэд зориулсан иж бүрэн гарын авлага

Энэхүү гүнзгийрүүлсэн API туршилтын заавар нь API тест, вэб үйлчилгээний талаар дэлгэрэнгүй тайлбарлахаас гадна танай байгууллагад API тестийг хэрхэн нэвтрүүлэх талаар танд зааж өгөх болно.

Заавар_№2: Вэб үйлчилгээний заавар: Бүрэлдэхүүн хэсэг, Архитектур, Төрөл & Жишээ

Энэ вэбХүчинтэй болон хүчингүй хариултын API-ийн хариултуудын зөв эсэх нь үнэхээр чухал юм. Туршилтын API-аас хариу болгон 200 (бүгд зүгээр гэсэн үг) төлөвийн код хүлээн авсан ч хариу бичвэрт алдаа гарсан гэж бичсэн бол энэ нь доголдол гэсэн үг.

Үүнээс гадна, хэрэв алдааны мессеж байвал Энэ нь өөрөө буруу, тэгвэл энэ нь энэ API-тай нэгдэхийг оролдож буй эцсийн хэрэглэгчийг төөрөгдүүлж болзошгүй.

Доорх дэлгэцийн зураг дээр хэрэглэгч буруу жин оруулсан бөгөөд энэ нь зөвшөөрөгдөх 2267 кг-аас их байна. API нь алдааны төлөвийн код болон алдааны мессежээр хариу өгдөг. Гэсэн хэдий ч алдааны мэдэгдэлд жингийн нэгжийг KG биш харин фунт гэж буруу дурдсан байна. Энэ нь эцсийн хэрэглэгчийг төөрөгдөлд оруулж болзошгүй согог юм.

(ii) Ачаалал ба гүйцэтгэлийн туршилт

API-ууд нь дизайны хувьд өргөтгөх боломжтой байх ёстой.

Энэ нь эргээд ачааллын болон гүйцэтгэлийн туршилтыг чухал болгодог, ялангуяа зохион бүтээж буй систем нь шаардлагаас хамааран нэг минут эсвэл цагт хэдэн мянган хүсэлтийг хангахаар хүлээгдэж байгаа бол. API дээр Ачаалал болон Гүйцэтгэлийн Туршилтыг тогтмол хийх нь гүйцэтгэл, оргил ачаалал болон эвдрэлийн цэгийг жишиг тогтооход тусална.

Энэ өгөгдөл нь программыг өргөжүүлэхээр төлөвлөхөд хэрэг болно. Ийм мэдээлэлтэй байх нь шийдвэр гаргах, төлөвлөхөд дэмжлэг үзүүлэх болно, ялангуяа байгууллага илүү олон үйлчлүүлэгч нэмэхээр төлөвлөж байгаа бол энэ нь илүү их орж ирж байгаа гэсэн үг юм.хүсэлтүүд.

API тестийг өөрийн байгууллагад хэрхэн нэвтрүүлэх вэ

Аливаа байгууллагад API тестийг нэвтрүүлэх үйл явц нь бусад туршилтын хэрэгсэл, тогтолцоог хэрэгжүүлэх эсвэл нэвтрүүлэхэд ашигладаг үйл явцтай төстэй.

Доорх хүснэгтэд үндсэн алхамуудыг алхам бүрийн хүлээгдэж буй үр дүнгийн хамт нэгтгэн харуулав.

Үе шат Алхам Хүлээгдэж буй үр дүн
Хэрэгслийн сонголт Шаардлага цуглуулж, хязгаарлалтыг тодорхойлох

Судалгаанд тавигдах шаардлагуудыг ойлгох тохирох API тестийн хэрэглүүрийг зах зээлд нийлүүлнэ.

Жишээ нь:

Ямар төрлийн API-г туршиж байна - SOAP эсвэл REST?

Бид энэ үүрэгт шалгагч хөлслөх эсвэл одоо байгаа шалгагчийг сургах шаардлагатай юу?

Функциональ, гүйцэтгэлийн сорил гэх мэт ямар төрлийн шинжилгээг хийх вэ.

Хэрэгжүүлэхэд ямар төсөв зарцуулагдсан бэ?

Боломжтой хэрэглүүрүүдийг үнэлэх Боломжтой хэрэгслүүдийг харьцуулж, шаардлагад хамгийн сайн нийцэх 1 эсвэл 2 хэрэгслийг сонго.
Үзэл баримтлалын баталгаа Товч жагсаалтад орсон хэрэглүүрийн тусламжтайгаар дэд багц туршилтуудыг хэрэгжүүлнэ.

Судалгааны үр дүнг оролцогч талуудад танилцуулна.

Хэрэгжүүлэх хэрэглүүрийг эцэслэнэ.

Хэрэгжилт Эхлэх Та сонгосон хэрэглүүрээсээ шалтгаалаад PC, Виртуал машин эсвэл сервер дээр шаардлагатай хэрэгслийг суулгах шаардлагатай болно.

Хэрэв сонгосон хэрэгсэл нь захиалга дээр суурилсан бол. , шаардлагатай багийг бүрдүүлэхданс.

Шаардлагатай бол багаа сургах.

Ажилд орох Тест үүсгэх

Тест хийх

Алдааг мэдээлэх

Нийтлэг сорилтууд ба тэдгээрийг бууруулах арга замууд

ЧД-ийн багуудад тохиолддог нийтлэг бэрхшээлүүдийн талаар ярилцъя. Байгууллагад API тестийн тогтолцоог хэрэгжүүлэх гэж оролдож байх үед тулгардаг.

#1) Зөв хэрэгслийг сонгох

Ажилд тохирох хэрэгслийг сонгох нь хамгийн нийтлэг бэрхшээл юм. Зах зээл дээр байгаа хэд хэдэн API туршилтын хэрэгсэл байдаг.

Зах зээл дээр байгаа хамгийн сүүлийн үеийн, хамгийн үнэтэй хэрэгслийг хэрэгжүүлэх нь маш сонирхолтой мэт санагдаж болох ч хэрэв энэ нь хүссэн үр дүнг авчрахгүй бол тэр хэрэгслийг ашиглах боломжтой. ямар ч ашиггүй.

Тиймээс байгууллагынхаа хэрэгцээнд тулгуурлан "заавал байх ёстой" хэрэгслийг сонгох хэрэгтэй. боломжтой API хэрэгслүүд

Хэрэгслүүд Үнэ Тэмдэглэл
Soap UI SoapUI Нээлттэй эхийн (Функциональ тест)-д зориулсан үнэгүй хувилбар * REST, SOAP болон бусад алдартай API болон IoT протоколууд.

* Үнэгүй хувилбарт багтсан

SOAP болон REST түр зуурын тест

Зурвас баталгаажуулалт

Чир & Дусал тест үүсгэх

Туршилтын бүртгэл

Туршилтын тохиргоо

Бичлэгээс тест хийх

Нэгжийн тайлан гаргах.

* Онцлогуудын бүрэн жагсаалтыг дараах байдлаар хийж болно. тэднээс олдсонвэб сайт.

Шуудангийн ажилтан Үнэгүй шууданч апп боломжтой * АМРАЛТАД хамгийн их ашигладаг.

* Онцлогуудыг вэбсайтаас олж болно.

Parasoft Энэ нь төлбөртэй хэрэгсэл бөгөөд лиценз худалдаж авах шаардлагатай бөгөөд дараа нь суулгах шаардлагатай. хэрэгслийг ашиглахаас өмнө. * API цогц туршилт: функциональ, ачаалал, аюулгүй байдлын туршилт, туршилтын өгөгдлийн менежмент
vREST Хэрэглэгчийн тоонд үндэслэсэн * Автоматжуулсан REST API-ийн туршилт.

* Бичлэг хийх, дахин тоглуулах.

* Хуурамч API-уудыг ашиглан урд болон арын хэсгээс хамаарлыг арилгана.

* Хүчирхэг хариу үйлдэл баталгаажуулалт.

* Localhost/intranet/internet дээр байрлуулсан туршилтын програмуудад зориулагдсан.

* JIRA Integration, Jenkins Integration Swagger, Postman-аас импортлодог.

HttpMaster Express Edition: Үнэгүй татаж авах

Мэргэжлийн хувилбар: Хэрэглэгчийн тооноос хамаарч

* Вэб сайтын тест болон API тест хийхэд тусалдаг.

* Бусад функцууд нь глобал параметрүүдийг тодорхойлох чадварыг багтаасан бөгөөд хэрэглэгчдэд баталгаажуулалтын том багцыг ашиглан өгөгдлийн хариу баталгаажуулалтын шалгалтыг үүсгэх боломжийг олгодог. үүнийг дэмждэг.

Runscope Хэрэглэгчийн тоо болон төлөвлөгөөний төрлүүд дээр үндэслэн

* API-г хянах, туршихад зориулагдсан.

* Зөв өгөгдлийг буцааж өгөхийн тулд өгөгдлийг баталгаажуулахад ашиглаж болно.

*API гүйлгээний алдаа гарсан тохиолдолд хянах, мэдэгдэх (хэрэв таны аппликешн төлбөрийн баталгаажуулалт шаардлагатай бол энэ хэрэгсэл нь сайн сонголт байх болно).

LoadFocus Хэрэглэгчдийн тоо болон төлөвлөгөөний төрлүүд дээр үндэслэн * API ачааллын туршилтанд ашиглах боломжтой - API-ийн дэмжиж чадах хэрэглэгчдийн тоог мэдэхийн тулд цөөн хэдэн тест хийх боломжийг олгодог.

* Хэрэглэхэд хялбар - хөтөч дотор туршилт явуулах боломжийг олгодог.

PingAPI 1 төсөлд үнэ төлбөргүй (1000 хүсэлт) ) * API-ийн автоматжуулсан туршилт, хяналтад ашигтай.

#2) Туршилтын үзүүлэлт дутуу

Тестерийн хувьд бид мэдэх хэрэгтэй. програмыг үр дүнтэй туршихын тулд хүлээгдэж буй үр дүн. Хүлээгдэж буй үр дүнг мэдэхийн тулд бид тодорхой шаардлага тавих шаардлагатай байдаг тул энэ нь ихэвчлэн бэрхшээлтэй байдаг - энэ нь тийм биш юм.

Жишээ нь , доор өгсөн шаардлагуудыг авч үзье:

“Аппликешн нь зөвхөн хүчинтэй тээвэрлэлтийн огноог хүлээн авах ёстой бөгөөд бүх хүчингүй шаардлагыг үгүйсгэх ёстой”

Эдгээр шаардлагуудад гол дэлгэрэнгүй мэдээлэл дутуу байгаа бөгөөд маш хоёрдмол утгатай байна – бид хүчинтэй огноог хэрхэн тодорхойлох вэ? Форматын талаар юу хэлэх вэ? Бид эцсийн хэрэглэгч гэх мэт татгалзсан мессежийг буцааж байна уу?

Тодорхой шаардлагын жишээ:

1) Програм нь зөвхөн Хүчинтэй тээвэрлэлтийн огноог хүлээн авна уу.

Тээвэрлэлтийн огноо нь хүчинтэй гэж тооцогддогбайна

  • Өнгөрсөн хугацаанд биш
  • Өнөөдрийн огнооноос их эсвэл тэнцүү байна
  • Зөвшөөрөгдсөн форматтай байна: DD/MM/YYYY

2)

Хариултын төлөвийн код = 200

Зурвас: OK

3) Тээвэрлэлтийн огноо дээрх шалгуурыг хангаагүй бол хүчингүйд тооцно. Хэрэв үйлчлүүлэгч буруу илгээсэн огноог илгээсэн бол тэрээр дараах алдааны мэдэгдлээр хариулах ёстой:

3.1

Хариултын төлөвийн код 200 БИШ

Алдаа: Хүргэлтийн огноо буруу байна; Огноо нь DD/MM/YYYY форматтай байгаа эсэхийг шалгана уу

3.2

Хариултын төлөвийн код 200 БИШ

Алдаа: Тээвэрлэлтийн огноог заасан байна өнгөрсөн

#3) Сурах муруй

Өмнө дурьдсанчлан API тестийн арга нь GUI-д суурилсан програмуудыг турших явцад дагаж мөрддөг арга барилтай харьцуулахад өөр байна.

Хэрэв та API туршилтын чиглэлээр мэргэжилтэн эсвэл зөвлөхүүдийг ажилд авч байгаа бол API тестийн арга эсвэл API тестийн хэрэгслийн суралцах муруй хамгийн бага байж болно. Энэ тохиолдолд аливаа сургалтын муруй нь бүтээгдэхүүн эсвэл хэрэглээний мэдлэгийг олж авахтай холбоотой байх болно.

Хэрэв одоо байгаа багийн гишүүн API тестийг сурахаар томилогдсон бол сонгосон хэрэглүүрээс хамааран сургалтын муруй байж болно. туршилтын арга барилыг өөрчлөхийн хамт дундаас өндөр. Бүтээгдэхүүн эсвэл хэрэглээний сургалтын муруй нь энэ шалгагч туршиж үзсэн эсэхээс хамаарч бага-дунд байж болноэнэ программыг өмнө нь хийсэн эсэх.

#4) Одоо байгаа ур чадварын багц

Энэ нь сургалтын муруйны өмнөх цэгтэй шууд холбогддог.

Хэрэв тестер дараахаас шилжиж байсан бол GUI дээр суурилсан тест хийвэл шалгагч нь туршилтын арга барилаа өөрчилж, шаардлагатай бол шинэ хэрэгсэл эсвэл хүрээг сурах шаардлагатай болно. Жишээ нь: Хэрэв API нь JSON форматын хүсэлтийг хүлээн авдаг бол шалгагч тест үүсгэж эхлэхийн тулд JSON гэж юу болохыг мэдэх шаардлагатай болно.

Кейс судалгаа

Даалгавар

Одоо байгаа программыг өргөжүүлэхийн тулд компани API болон стандарт GUI програмыг санал болгохыг хүссэн. QA багаас ердийн GUI-д суурилсан тестүүдээс гадна API тестийг даатгахад бэлэн байгаа эсэхийг шалгахын тулд Туршилтын хамрах хүрээний төлөвлөгөөг гаргаж өгөхийг хүссэн.

Бэрхшээлүүд

  • Байхгүй. Бусад програм хангамжийн бүтээгдэхүүнүүд нь API-д суурилсан архитектуртай байсан тул энэ даалгаврыг тойрон туршилтыг зохион байгуулахын тулд баг API туршилтын процессыг эхнээс нь бий болгох хэрэгтэй. Энэ нь багаж хэрэгслийг үнэлж, шалгаруулж, эцэслэн боловсруулж, багийг туршилтанд сургах ёстой гэсэн үг юм.
  • Багажийг олж авах, хэрэгжүүлэхэд нэмэлт төсөв төсөвлөөгүй. Энэ нь баг нь үнэгүй эсвэл нээлттэй эх сурвалжтай API тестийн хэрэгслийг сонгох ёстой бөгөөд одоо байгаа багийн хэн нэг нь энэ даалгаврыг гүйцэтгэхэд сургагдсан байх ёстой гэсэн үг юм.
  • API талбар болон өгөгдөлд тавигдах шаардлага байхгүй байсан.баталгаажуулалт. Шаардлагууд нь “харгалзах GUI програмтай адил ажиллах ёстой” байсан.

Эрсдэлийг бууруулах, сорилт бэрхшээлийг тойрон гарахын тулд багийн баримталж буй арга барил

  • ЧДҮ-ний баг төслийн багтай хамтран дараах шаардлагуудыг тодорхойлсон:
    • API төрөл (REST/SOAP ): REST
    • Шаардлагатай туршилт (Функциональ, Ачаалал, аюулгүй байдал): Зөвхөн функциональ туршилт
    • Автоматжуулсан туршилт шаардлагатай (Тийм/Үгүй): Одоохондоо сонголттой
    • Туршилтын тайлан (Тийм/Үгүй) ): Шаардлагатай
  • ЧА-ын баг заавал байх ёстой шаардлагуудын үндсэн дээр боломжтой API туршилтын хэрэгслүүд дээр багажийн үнэлгээ хийсэн. Postman API хэрэгсэл нь үнэ төлбөргүй, ашиглахад хялбар тул сургалтын муруйг багасгаж, тестийг автоматжуулах чадвартай, сайн дотоод тайлантай байсан тул тэдний сонгосон хэрэгсэл болгон эцэслэн гаргасан.
  • Аппликешныг туршиж үзсэн ижил шалгагч нь Postman программыг ашиглан анхан шатны туршилтуудыг бий болгосноор бүтээгдэхүүний мэдлэгийн цоорхойг арилгахад сургагдсан.
  • Алга болсон шаардлагуудыг арилгахын тулд төслийн баг Swagger ашиглан өндөр түвшний хээрийн түвшний баримт бичгийг бүтээсэн. . Гэсэн хэдий ч энэ нь хүлээн зөвшөөрөгдөх өгөгдлийн форматын хувьд зарим нэг цоорхойг үлдээсэн бөгөөд энэ талаар төслийн багтай ярилцаж, хүлээгдэж буй форматуудыг тохиролцож, баримтжуулсан.

Дүгнэлт

API-д суурилсан програмууд сүүлийн үед алдартай болсон. Эдгээр програмууд илүү их байдагУламжлалт хэрэглүүрүүд/програм хангамжтай харьцуулахад өргөтгөх боломжтой бөгөөд бусад API эсвэл програмуудтай хялбар нэгтгэх боломжийг олгодог.

Энэхүү API Туршилтын заавар нь API туршилт, зүүн тийш шилжүүлэх тест, вэб үйлчилгээ, вэб API-ийн талаар дэлгэрэнгүй тайлбарласан. Мөн бид вэб үйлчилгээ болон вэб API хоёрын ялгааг жишээн дээр судалсан.

Хичээлийн хоёр дахь хэсэгт API тестийн бүрэн хүрээ, танай байгууллагад API тестийг хэрхэн нэвтрүүлэх болон зарим нийтлэг бэрхшээлүүдийн талаар ярилцсан. Энэ үйл явц нь тэдэнд зориулсан шийдлүүдийн хамт.

Жишээний хамт Вэб үйлчилгээний талаар илүү ихийг мэдэхийн тулд бидний удахгүй гарах зааварчилгааг үзнэ үү!!

Дараах заавар

Үйлчилгээний заавар нь Архитектур, төрөл & AMP-ыг тайлбарладаг; Вэб үйлчилгээний бүрэлдэхүүн хэсгүүдийн хамт чухал нэр томьёо ба SOAP ба REST хоёрын ялгаа.
Заавар_№3: Хариулт бүхий шилдэг 35 ASP.Net болон Web API ярилцлагын асуултууд

Та хамгийн түгээмэл байнга асуудаг ASP.Net болон Web API ярилцлагын асуултуудын жагсаалтыг хариултын хамт судлах боломжтой. Энэ зааварт эхлэгчдэд болон туршлагатай мэргэжилтнүүдэд зориулсан жишээнүүд.

Заавар_#4: POSTMAN заавар: API ашиглах туршилт POSTMAN

Энэхүү алхам алхмаар зааварчилгаа нь POSTMAN-ийн үндсэн ойлголт, түүний бүрэлдэхүүн хэсгүүд болон дээжийн хүсэлт & Таныг хялбархан ойлгохын тулд энгийн үгээр хариулна уу.

Заавар_№5: Apache HTTP Client ашиглан вэб үйлчилгээний туршилт

Энэхүү API заавар нь Apache HTTP Client-ийг ашиглан вэб үйлчилгээнүүд дээр төрөл бүрийн CRUD үйлдлүүд хийх, вэб үйлчилгээг турших тухай юм

API туршилтын заавар

Энэ хэсэг нь танд вэб үйлчилгээ болон вэб API-ийн талаар үндсэн ойлголт авахад туслах бөгөөд энэ нь эргээд энэхүү API туршилтын цуврал хичээлүүдийн үндсэн ойлголтуудыг ойлгоход тустай байх болно.

API ( Хэрэглээний програмчлалын интерфэйс) нь програмын өгөгдөл эсвэл функцэд хандах замаар програм үүсгэх боломжийг олгодог бүх процедур, функцүүдийн багц юм.үйлдлийн систем эсвэл платформууд. Ийм журмын туршилтыг API тест гэж нэрлэдэг.

Зүүн шилжилтийн тест

Өнөө үед API туршилтын ярилцлагад тавигдаж байгаа чухал сорилтын нэг бол Shift Left Testing юм. Энэ төрлийн туршилтыг Agile аргачлалыг дагаж мөрддөг бараг бүх төслүүдэд хэрэгжүүлдэг.

Swift Left Testing нэвтрүүлэхээс өмнө кодчилол хийж дуусаад кодыг шалгагчдад хүргэсний дараа л программ хангамжийн туршилт гарч ирсэн. Энэхүү дадлага нь эцсийн хугацааг дуусгахын тулд яаравчлахад хүргэсэн бөгөөд энэ нь бүтээгдэхүүний чанарт ихээхэн саад учруулсан.

Үүнээс гадна хийсэн хүчин чармайлт (үйлдвэрлэхээс өмнөх сүүлийн шатанд согогийг мэдээлсэн) Хөгжүүлэгчид дизайн болон кодчиллын үе шатыг дахин давах шаардлагатай байсан тул асар том юм.

Програм хангамж хөгжүүлэх амьдралын мөчлөг (SDLC) Зүүн шилжилтийн туршилтаас өмнө

Уламжлалт SDLC урсгал нь: Шаардлага - > Дизайн –> Кодлох –> Туршилт.

Уламжлалт сорилтын сул тал

  • Тест нь туйлын баруун талд байна. Алдааг эцсийн мөчид олж илрүүлэхэд маш их зардал гардаг.
  • Алдааг шийдэж, үйлдвэрлэлд нэвтрүүлэхээс өмнө дахин туршихад зарцуулсан цаг хугацаа асар их байна.

Тиймээс, Туршилтын үе шатыг зүүн тийш шилжүүлэх шинэ санаа гарч ирсэн нь зүүн тийш шилжих туршилтыг явуулахад хүргэсэн.

Зөвлөж буй унших => Зүүн тийш шилжүүлэх туршилт: AПрограм хангамжийн амжилтын нууц тарни

Зүүн ээлжийн туршилтын үе шатууд

Зүүн ээлжийн туршилт нь Согог илрүүлэхээс согогоос урьдчилан сэргийлэх рүү амжилттай шилжихэд хүргэсэн. Энэ нь мөн програм хангамжийг хурдан доголдуулж, бүх алдааг хурдан засахад тусалсан.

Web API

Ерөнхийдөө Вэб API нь үйлчлүүлэгчийн хүсэлтийг хүлээн авдаг зүйл гэж тодорхойлж болно. системийг вэб сервер рүү илгээдэг бөгөөд хариуг вэб серверээс клиент машин руу илгээдэг.

API хэрхэн ажилладаг вэ?

Олон агаарын тээврийн компанийн мэдээллийг нэгтгэдэг онлайн аялалын үйлчилгээ болох www.makemytrip.com дээр нислэг захиалах нийтлэг хувилбарыг авч үзье. Та нислэгийн захиалга авахаар очихдоо аялсан огноо/буцах огноо, анги гэх мэт мэдээллийг оруулаад хайлт дээр дарна уу.

Энэ нь танд олон агаарын тээврийн компанийн үнэ болон тэдгээрийн бэлэн байдлыг харуулах болно. Энэ тохиолдолд аппликейшн нь олон агаарын тээврийн компаниудын API-тай харилцаж, улмаар агаарын тээврийн компанийн мэдээлэлд хандах боломжийг олгодог.

Өөр нэг жишээ бол www.trivago.com бөгөөд өөр өөр зочид буудлуудын үнэ, бэлэн байдал гэх мэтийг харьцуулж, жагсаан бичдэг. тодорхой хотоос. Энэ вэб сайт нь олон зочид буудлын API-уудтай холбогдож мэдээллийн санд нэвтэрч, тэдний вэб сайтаас үнэ болон хүртээмжийг жагсаан бичдэг.

Тиймээс Вэб API нь "үйлчлүүлэгч машин болон зочид буудлын хоорондын харилцааг хөнгөвчлөх интерфейс" гэж тодорхойлж болно. ньвэб сервер”.

Вэб үйлчилгээ

Вэб үйлчилгээ нь (Вэб API гэх мэт) нэг машинаас нөгөө машинд үйлчлэх үйлчилгээ юм. Гэвч API болон Вэб үйлчилгээний хооронд үүсдэг гол ялгаа нь вэб үйлчилгээ нь сүлжээг ашигладаг явдал юм.

Бүх Вэб үйлчилгээнүүд нь Вэб API боловч бүх Вэб API нь Вэб үйлчилгээ биш (энэ хэсэгт тайлбарласан) гэж хэлж болно. Өгүүллийн сүүлчийн хэсэг). Тиймээс Вэб үйлчилгээ нь Web API-ийн дэд хэсэг юм. Вэб API болон вэб үйлчилгээний талаар илүү ихийг мэдэхийг хүсвэл доорх диаграммыг харна уу.

Вэб API ба вэб үйлчилгээ

Вэб үйлчилгээ vs. Вэб API

Вэб API болон вэб үйлчилгээ хоёулаа үйлчлүүлэгч болон сервер хоорондын харилцааг хөнгөвчлөхөд ашиглагддаг. Гол ялгаа нь зөвхөн харилцах арга барилд л байдаг.

Тэд тус бүр нь тодорхой хэлээр хүлээн зөвшөөрөгдөх хүсэлтийн хэсэг, аюулгүй холболтоор хангах ялгаа, сервертэй холбогдох болон хариу өгөх хурд зэргийг шаарддаг. үйлчлүүлэгчид гэх мэт.

Вэб үйлчилгээ болон вэб API-ийн ялгааг доор жагсаасан болно.

Вэб үйлчилгээ

  • Вэб үйлчилгээнүүд нь ерөнхийдөө XML (Extensible Markup Language) ашигладаг бөгөөд энэ нь илүү найдвартай гэсэн үг юм.
  • Вэб үйлчилгээнүүд болон API-ууд өгөгдөл дамжуулах явцад SSL (Secure Socket Layer)-аар хангадаг тул илүү аюулгүй байдаг. , гэхдээ энэ нь бас WSS (Вэб үйлчилгээний аюулгүй байдал) -аар хангадаг.
  • Вэб үйлчилгээ нь Web API-ийн дэд хэсэг юм. Жишээ нь, Вэб үйлчилгээ нь зөвхөн гурван төрлийн хэрэглээний загвар дээр суурилдаг, тухайлбал SOAP, REST болон XML-RPC.
  • Вэб үйлчилгээнүүд ажиллахын тулд үргэлж сүлжээ хэрэгтэй.
  • Вэб үйлчилгээ нь “Нэг код өөр программ”-ыг дэмждэг. Энэ нь илүү ерөнхий кодыг өөр өөр программуудад бичдэг гэсэн үг.

Вэб API

  • Вэб API нь ерөнхийдөө JSON (JavaScript Object Notation) ашигладаг. Энэ нь Вэб API илүү хурдан гэсэн үг.
  • Вэб API нь XML-ээс ялгаатай нь JSON хөнгөн жинтэй тул илүү хурдан байдаг.
  • Вэб API нь Вэб үйлчилгээний дээд багц юм. Жишээ нь, Вэб үйлчилгээний бүх гурван загвар нь Вэб API-д байдаг, гэхдээ үүнээс гадна JSON – RPC гэх мэт өөр хэв маягийг ашигладаг.
  • Вэб API нь заавал байх албагүй. сүлжээ.
  • Вэб API нь систем эсвэл програмын шинж чанараас хамааран харилцан ажиллах чадварыг дэмжих эсвэл дэмжихгүй байж болно.

API тестийг танай байгууллагад нэвтрүүлэх

Өдөр тутмын амьдралдаа бид бүгд API-тай апп-уудтай харьцахад маш их дассан ч үндсэн функцийг удирддаг арын процессуудын талаар огт боддоггүй.

Жишээ нь: , Та Amazon.com дээрх бүтээгдэхүүнүүдийг үзэж байгаа бөгөөд танд үнэхээр таалагдсан бүтээгдэхүүн/гэрээг харж, үүнийгээ Facebook сүлжээндээ хуваалцахыг хүсэж байна гэж үзье.

Таныг дарах тэр мөчид. хуудасны хуваалцах хэсгийн Facebook дүрс дээр өөрийн гэсэн бичнэ үүХуваалцах Facebook дансны итгэмжлэлүүд, та Амазоны вэб сайтыг Facebook-тэй саадгүй холбож байгаа API-тай харилцаж байна.

API тест рүү шилжихийг анхаарч үзээрэй

API тестийн талаар дэлгэрэнгүй ярихаасаа өмнө шалтгааныг ярилцъя. API дээр суурилсан программууд сүүлийн үед түгээмэл болж байна.

Ямар байгууллагууд API дээр суурилсан бүтээгдэхүүн, програм руу шилжиж байгаа хэд хэдэн шалтгаан бий. Тэдгээрийн цөөхөн хэд нь таны лавлагаанд зориулж доор жагсаасан болно.

#1) API дээр суурилсан програмууд нь уламжлалт програмууд/програм хангамжтай харьцуулахад илүү томруулж чаддаг. Код боловсруулах хурд нь илүү хурдан бөгөөд ижил API нь ямар ч томоохон код эсвэл дэд бүтцийн өөрчлөлтгүйгээр илүү олон хүсэлтэд үйлчлэх боломжтой.

#2) Хөгжүүлэгч багууд кодчилол бүрийг эхнээс нь эхлүүлэх шаардлагагүй. Тэд ямар нэгэн функц эсвэл програм хөгжүүлэхээр ажиллаж эхлэх үед. API нь ихэвчлэн одоо байгаа, давтагдах функц, номын сан, хадгалагдсан процедур гэх мэтийг дахин ашигладаг бөгөөд иймээс энэ үйл явц нь тэдгээрийг бүхэлд нь илүү бүтээмжтэй болгож чадна.

Жишээ нь, Хэрэв та програм дээр ажиллаж байгаа хөгжүүлэгч бол цахим худалдааны вэб сайт болон та Amazon-ыг төлбөрийн процессор болгон нэмэхийг хүсэж байгаа бол кодыг эхнээс нь бичих шаардлагагүй болно.

Та хийх ёстой зүйл бол өөрийн вэбсайт болон Amazon API-г ашиглан интеграцчлалыг тохируулах явдал юм. Тооцоо хийх явцад төлбөр боловсруулахын тулд интеграцийн түлхүүрүүд болон Amazon API руу залгана уу.

#3) API-г зөвшөөрдөгДэмжигдсэн бие даасан програмууд болон API дээр суурилсан програм хангамжийн бүтээгдэхүүнүүдтэй хялбар интеграцчилал.

Жишээ нь , Та Торонтогоос Нью Йорк руу ачаа илгээхийг хүсэж байна гэж бодъё. . Та онлайнаар нэвтэрч, сайн мэдэх Ачаа, Логистикийн вэб сайт руу орж, шаардлагатай мэдээллийг оруулна уу.

Заавал мэдээллийг оруулсны дараа, арын хэсэгт байгаа Үнэ авах товчийг дарахад энэ логистикийн вэб сайт холбогдсон байж магадгүй. Хэд хэдэн оператор болон үйлчилгээ үзүүлэгчийн API болон хэрэглээний байршлын гарал үүслээс хүрэх цэгийн динамик хурдыг авах боломжтой.

API туршилтын бүрэн спектр

API-г турших нь хүсэлт илгээхээр хязгаарлагдахгүй. API руу шилжүүлж, хариултыг зөвхөн зөв эсэхийг шинжлэх. API-уудыг өөр өөр ачааллын дор ажиллахдаа эмзэг байдлын үүднээс шалгах шаардлагатай.

Үүнийг дэлгэрэнгүй авч үзье.

(i) Үйл ажиллагааны туршилт

GUI интерфэйс байхгүйгээс функциональ тест хийх нь хэцүү ажил байж болох юм.

API-д зориулсан функциональ тестийн арга нь GUI дээр суурилсан программаас юугаараа ялгаатай болохыг харцгаая. Мөн бид түүний эргэн тойронд зарим жишээг авч үзэх болно.

a) Хамгийн тод ялгаа нь харьцах GUI байхгүй. Ихэвчлэн GUI дээр суурилсан функциональ тест хийдэг тестерүүд нь GUI бус програмын тест рүү шилжихэд арай хэцүү байдаг.үүнийг аль хэдийн мэддэг хүн.

Эхэндээ API-г туршиж эхлэхээсээ өмнө баталгаажуулах процессыг өөрөө туршиж, баталгаажуулах шаардлагатай болно. Баталгаажуулах арга нь нэг API-аас нөгөө API-д харилцан адилгүй байх ба баталгаажуулалтад зориулсан ямар нэг түлхүүр эсвэл жетон агуулна.

Хэрэв та API-д амжилттай холбогдож чадахгүй бол цаашдын туршилтыг үргэлжлүүлэх боломжгүй. Энэ процессыг програмд ​​нэвтэрч, ашиглахын тулд хүчинтэй итгэмжлэл шаардлагатай стандарт програмуудын хэрэглэгчийн баталгаажуулалттай харьцуулж болно.

b) Талбайн баталгаажуулалт эсвэл оролтын өгөгдлийн баталгаажуулалтыг турших нь маш чухал юм. API-г турших явцад. Хэрэв бодит хэлбэрт суурилсан (GUI) интерфэйс байгаа бол талбарын баталгаажуулалтыг урд эсвэл арын хэсэгт хийж болох бөгөөд ингэснээр хэрэглэгч талбарын хүчингүй утгыг оруулахыг зөвшөөрөхгүй болно.

Жишээ нь, Хэрэв аппликешнд огнооны формат DD/MM/YYYY байх шаардлагатай бол бид энэ баталгаажуулалтыг мэдээлэл цуглуулах маягт дээр хэрэглэж, уг программыг хүлээн авч, хүчинтэй огноог боловсруулж байгаа эсэхийг баталгаажуулах боломжтой.

Гэхдээ энэ нь API програмуудын хувьд адил биш юм. Бид API нь сайн бичигдсэн, эдгээр бүх баталгаажуулалтыг хэрэгжүүлэх, хүчинтэй болон хүчингүй өгөгдлийг ялгах, статус код болон баталгаажуулалтын алдааны мэдэгдлийг эцсийн хэрэглэгч рүү хариу илгээх чадвартай эсэхийг баталгаажуулах хэрэгтэй.

в) Туршилт хийх

Дээд тал рүү орох