Tutorial Ujian API: Panduan Lengkap untuk Pemula

Tutorial Pengujian API Mendalam Ini Menjelaskan Semua Mengenai Pengujian API, Perkhidmatan Web dan Cara Memperkenalkan Pengujian API Dalam Organisasi Anda:

Dapatkan pandangan mendalam tentang Ujian API bersama-sama dengan konsep ujian anjakan kiri dan perkhidmatan web daripada tutorial pengenalan ini.

Konsep seperti API Web, cara API berfungsi (dengan contoh dunia sebenar) dan bagaimana ia berbeza daripada Perkhidmatan Web dijelaskan dengan baik dengan contoh dalam ini tutorial.

Senarai Tutorial Pengujian API

Tutorial #1: Tutorial Pengujian API: Panduan Lengkap Untuk Pemula

Tutorial #2: Tutorial Perkhidmatan Web: Komponen, Seni Bina, Jenis & Contoh

Tutorial #3: Top 35 Soalan Temuduga ASP.Net Dan Web API Dengan Jawapan

Tutorial #4: Tutorial POSTMAN: Ujian API Menggunakan POSTMAN

Tutorial #5: Pengujian Perkhidmatan Web Menggunakan Klien HTTP Apache

Gambaran Keseluruhan Tutorial Dalam Siri Pengujian API Ini

Tutorial # Apa yang Anda Akan Pelajari
Tutorial_#1: Tutorial Ujian API : Panduan Lengkap Untuk Pemula

Tutorial Ujian API Mendalam ini akan menerangkan semua tentang Ujian API dan Perkhidmatan Web secara terperinci dan juga mendidik anda tentang cara Memperkenalkan Ujian API dalam organisasi anda.

Tutorial_#2: Tutorial Perkhidmatan Web: Komponen, Seni Bina, Jenis & Contoh

Web Iniketepatan jawapan daripada API untuk respons yang sah dan tidak sah sememangnya penting. Jika kod status 200 (bermaksud semua Okay) diterima sebagai respons daripada API ujian, tetapi jika teks respons menyatakan ralat telah ditemui, maka ini adalah kecacatan.

Selain itu, jika mesej ralat itu sendiri tidak betul, maka itu boleh menjadi sangat mengelirukan kepada pelanggan akhir yang cuba menyepadukan dengan API ini.

Dalam tangkapan skrin di bawah, pengguna telah memasukkan berat tidak sah, iaitu lebih daripada 2267 Kgs yang boleh diterima. API bertindak balas dengan kod status ralat dan mesej ralat. Walau bagaimanapun, mesej ralat salah menyebut unit berat sebagai lbs dan bukannya KG. Ini adalah kecacatan yang boleh mengelirukan pelanggan akhir.

(ii) Ujian Muatan dan Prestasi

API dimaksudkan untuk berskala mengikut reka bentuk.

Ini, seterusnya, menjadikan Ujian Beban dan Prestasi penting, terutamanya jika sistem yang direka bentuk dijangka menyediakan beribu-ribu permintaan seminit atau jam, bergantung pada keperluan. Melakukan Ujian Beban dan Prestasi secara rutin pada API boleh membantu menanda aras prestasi, beban puncak dan titik putus.

Data ini berguna semasa merancang untuk menaikkan skala aplikasi. Mempunyai maklumat ini tersedia akan membantu menyokong keputusan dan perancangan terutamanya jika organisasi merancang untuk menambah lebih ramai pelanggan, yang bermakna lebih banyak pelanggan masuk.permintaan.

Cara Memperkenalkan Ujian API dalam Organisasi Anda

Proses untuk memperkenalkan ujian API dalam mana-mana organisasi adalah serupa dengan proses yang digunakan untuk melaksanakan atau melancarkan sebarang alat dan rangka kerja ujian lain.

Jadual di bawah meringkaskan langkah-langkah utama bersama-sama dengan hasil yang dijangkakan bagi setiap langkah.

Fasa Langkah Hasil Jangkaan
Pemilihan Alat Kumpulkan keperluan dan kenal pasti kekangan

Fahami keperluan untuk penyelidikan pasaran untuk alat ujian API yang sesuai.

Cth.

Apakah jenis API yang sedang diuji - SOAP atau REST?

Adakah kita perlu mengupah penguji untuk peranan ini atau melatih penguji sedia ada?

Apakah jenis ujian yang akan dilakukan - kefungsian, ujian prestasi dll.

Berapakah belanjawan untuk pelaksanaan?

Nilai alatan yang tersedia Bandingkan alatan yang tersedia dan senarai pendek 1 atau 2 alatan yang paling memenuhi keperluan.
Bukti Konsep Laksanakan subset ujian dengan alat yang disenarai pendek.

Bentangkan penemuan kepada pihak berkepentingan.

Tamatkan alat yang akan dilaksanakan.

Pelaksanaan Bermula Bergantung pada alat pilihan anda, anda perlu memasang alat yang diperlukan pada PC, mesin Maya atau pelayan.

Jika alat pilihan adalah berasaskan langganan , cipta pasukan yang diperlukanakaun.

Latih pasukan jika perlu.

Teruskan Buat ujian

Laksanakan ujian

Laporkan kecacatan

Cabaran Biasa Dan Cara Mengurangkannya

Mari kita bincangkan beberapa cabaran biasa yang dihadapi oleh pasukan QA hadapi semasa cuba melaksanakan rangka kerja ujian API dalam organisasi.

#1) Memilih Alat yang Tepat

Memilih alat yang betul untuk tugas ialah cabaran yang paling biasa. Terdapat beberapa alat ujian API yang tersedia di pasaran.

Ia mungkin kelihatan sangat menarik untuk melaksanakan alat terbaharu dan paling mahal yang terdapat di pasaran- tetapi jika ia tidak membawa hasil yang diingini, maka alat itu tidak berguna.

Oleh itu, sentiasa pilih alat yang menangani keperluan 'mesti ada' berdasarkan keperluan organisasi anda.

Berikut ialah contoh matriks penilaian alat untuk Alat API tersedia

Alat Harga Nota
Soap UI Versi Percuma tersedia untuk SoapUI Open Source (Ujian fungsional) * REST, SOAP dan protokol API dan IoT popular yang lain.

* Termasuk dalam versi Percuma

Ujian ad-hoc SOAP dan REST

Penegasan Mesej

Seret & Gugurkan Penciptaan Ujian

Log Ujian

Konfigurasi Ujian

Ujian daripada Rakaman

Pelaporan Unit.

* Senarai lengkap ciri boleh terdapat dalam merekatapak web.

Posmen Apl Posmen Percuma tersedia * Paling kerap digunakan untuk REHAT.

* Ciri boleh didapati di tapak web mereka.

Parasoft Ia adalah alat berbayar, memerlukan pembelian lesen dan kemudian memerlukan pemasangan sebelum alat boleh digunakan. * Ujian API komprehensif: berfungsi, beban, ujian keselamatan, pengurusan data ujian
vREST Berdasarkan Bilangan pengguna * Ujian REST API Automatik.

* Rakam dan main semula.

* Mengalih keluar pergantungan daripada bahagian hadapan dan bahagian belakang menggunakan API palsu.

* Pengesahan Respons Berkuasa.

* Berfungsi untuk aplikasi ujian yang digunakan pada localhost/intranet/internet.

* Integrasi JIRA, Integrasi Jenkins Import daripada Swagger, Posmen.

HttpMaster Edisi Ekspres: Percuma untuk dimuat turun

Versi profesional: Berdasarkan Bilangan pengguna

* Membantu dalam ujian Laman Web serta ujian API.

* Ciri-ciri lain termasuk keupayaan untuk menentukan parameter global, memberikan pengguna keupayaan untuk membuat semakan untuk pengesahan respons data dengan menggunakan set besar jenis pengesahan yang ia menyokong.

Runscope Berdasarkan bilangan pengguna dan jenis pelan

* Untuk memantau dan menguji API.

* Boleh digunakan untuk pengesahan data untuk memastikan data yang betul dikembalikan.

* Mengandungi cirimenjejaki dan memberitahu sekiranya berlaku sebarang kegagalan transaksi API (jika permohonan anda memerlukan pengesahan pembayaran, maka alat ini boleh menjadi pilihan yang baik).

LoadFocus Berdasarkan bilangan pengguna dan jenis pelan * Boleh digunakan untuk ujian beban API - membenarkan menjalankan beberapa ujian untuk mengetahui bilangan pengguna yang boleh disokong oleh API.

* Mudah digunakan - membenarkan menjalankan ujian dalam penyemak imbas.

PingAPI Percuma untuk 1 projek (1,000 permintaan ) * Bermanfaat untuk Pengujian dan Pemantauan API Automatik.

#2) Tiada Spesifikasi Ujian

Sebagai penguji, kita perlu tahu keputusan yang diharapkan untuk menguji aplikasi dengan berkesan. Ini selalunya merupakan satu cabaran, kerana untuk mengetahui hasil yang dijangkakan, kita perlu mempunyai keperluan yang tepat yang jelas – yang tidak berlaku.

Sebagai Contoh , pertimbangkan keperluan yang disediakan di bawah:

“Permohonan hanya boleh menerima tarikh penghantaran yang sah dan semua keperluan yang tidak sah harus ditolak”

Keperluan ini tiada butiran penting dan sangat samar – bagaimanakah kita menentukan tarikh yang sah? Bagaimana dengan formatnya? Adakah kami mengembalikan sebarang mesej penolakan kepada pengguna akhir, dsb.?

Contoh Keperluan Jelas:

1) Permohonan hendaklah hanya terima tarikh penghantaran yang sah.

Tarikh penghantaran dianggap sah jika iaialah

  • Bukan pada masa lalu
  • Lebih besar atau sama dengan tarikh hari ini
  • Adalah dalam format yang boleh diterima: DD/MM/YYYY

2)

Kod Status Balasan = 200

Mesej: OK

3) Tarikh penghantaran yang tidak memenuhi kriteria di atas harus dianggap tidak sah. Jika pelanggan menghantar tarikh penghantaran yang tidak sah, maka ia mesti membalas dengan mesej ralat berikut:

3.1

Kod Status Balasan NOT 200

Ralat: Tarikh penghantaran yang diberikan adalah tidak sah; sila pastikan tarikh dalam format DD/MM/YYYY

3.2

Kod Status Balasan NOT 200

Ralat: Dengan syarat tarikh penghantaran adalah dalam masa lalu

#3) Lengkung Pembelajaran

Seperti yang dinyatakan sebelum ini, pendekatan untuk ujian API adalah berbeza jika dibandingkan dengan pendekatan yang diikuti semasa menguji aplikasi berasaskan GUI.

Jika anda sedang mengambil pakar sama ada dalaman atau perunding untuk ujian API, maka keluk pembelajaran pendekatan ujian API atau alat ujian API mungkin minimum. Sebarang keluk pembelajaran, dalam kes ini, akan dikaitkan dengan memperoleh produk atau pengetahuan aplikasi.

Jika ahli pasukan sedia ada ditugaskan untuk mempelajari ujian API, maka bergantung pada alat pilihan, keluk pembelajaran mungkin sederhana hingga tinggi, bersama-sama dengan mengubah pendekatan ujian. Keluk pembelajaran untuk produk atau aplikasi itu sendiri mungkin sederhana rendah bergantung pada sama ada penguji ini telah diujiaplikasi itu sebelum atau tidak.

#4) Set Kemahiran Sedia Ada

Ini berkaitan secara langsung dengan titik sebelumnya tentang keluk pembelajaran.

Jika penguji sedang beralih daripada Ujian berasaskan GUI, maka penguji perlu menukar pendekatan ujian dan mempelajari alat atau rangka kerja baharu seperti yang diperlukan. Cth. Jika API menerima permintaan dalam format JSON, maka penguji perlu mempelajari apa itu JSON, untuk mula membuat ujian.

Kajian Kes

Tugas

Untuk meningkatkan skala aplikasi sedia ada, sebuah syarikat ingin menawarkan produk dalam API serta aplikasi GUI standard. Pasukan QA diminta menyediakan Pelan Liputan Ujian untuk memastikan bahawa mereka bersedia untuk menampung ujian API melebihi ujian berasaskan GUI biasa.

Cabaran

  • Tiada daripada produk perisian lain mempunyai seni bina berasaskan API, oleh itu untuk menampung ujian di sekitar tugas ini, pasukan perlu mewujudkan proses ujian API dari awal. Ini bermakna alat itu akan dinilai, disenarai pendek, dimuktamadkan dan pasukan perlu dilatih untuk ujian.
  • Tiada belanjawan tambahan diperuntukkan untuk memperoleh dan melaksanakan alat tersebut. Ini bermakna pasukan perlu memilih alat ujian API percuma atau sumber terbuka dan seseorang daripada pasukan sedia ada perlu dilatih untuk melaksanakan tugas ini.
  • Tiada keperluan untuk medan dan data APIpengesahan. Keperluan adalah "sepatutnya berfungsi sama seperti aplikasi GUI yang sepadan".

Pendekatan yang diikuti oleh pasukan untuk mengurangkan risiko dan mengatasi cabaran

  • Pasukan QA bekerjasama dengan pasukan projek untuk mengenal pasti keperluan berikut:
    • Jenis API (REST/SOAP ): REHAT
    • Ujian diperlukan (Fungsian, Muat, Keselamatan): Ujian berfungsi sahaja
    • Ujian Automatik diperlukan (Ya/Tidak): Pilihan buat masa ini
    • Laporan ujian (Ya/Tidak ): Diperlukan
  • Pasukan QA melakukan penilaian alat pada alat ujian API yang tersedia berdasarkan keperluan yang mesti ada. Alat API Postman telah dimuktamadkan sebagai alat pilihan mereka kerana ia percuma dan mudah digunakan juga, sekali gus meminimumkan keluk pembelajaran, dan berpotensi untuk mengautomasikan ujian, dan disertakan dengan laporan terbina yang baik.
  • Penguji yang sama yang menguji aplikasi telah dilatih untuk menggunakan Posmen untuk membuat ujian awal dengan itu menghapuskan sebarang jurang pengetahuan produk.
  • Untuk menangani keperluan yang tiada, pasukan projek membina dokumentasi peringkat medan peringkat tinggi menggunakan Swagger . Walau bagaimanapun, ini meninggalkan beberapa jurang dari segi format data yang boleh diterima dan ini telah diambil bersama pasukan projek dan format yang diharapkan telah dipersetujui dan didokumenkan.

Kesimpulan

Aplikasi berasaskan API telah mendapat populariti sejak kebelakangan ini. Aplikasi ini lebihberskala berbanding dengan aplikasi/perisian tradisional dan membenarkan penyepaduan yang lebih mudah dengan API atau aplikasi lain.

Tutorial Ujian API ini menerangkan semua tentang Ujian API, Ujian Shift Kiri, Perkhidmatan Web dan API Web secara terperinci. Kami juga meneroka perbezaan antara Perkhidmatan Web berbanding API Web dengan contoh.

Dalam bahagian kedua tutorial, kami membincangkan spektrum penuh Ujian API, cara memperkenalkan Ujian API dalam organisasi anda dan beberapa cabaran biasa dalam proses ini bersama-sama dengan penyelesaian untuk mereka.

Lihat tutorial kami yang akan datang untuk mengetahui lebih lanjut tentang Perkhidmatan Web berserta contoh!!

Tutorial SETERUSNYA

Tutorial perkhidmatan menerangkan Seni Bina, Jenis & Komponen Perkhidmatan Web bersama-sama dengan Istilah Penting dan Perbezaan antara SOAP vs REST.
Tutorial_#3: 35 Soalan Temuduga ASP.Net Dan API Web Teratas Dengan Jawapan

Anda boleh meneroka senarai Soalan Temuduga ASP.Net dan API Web yang paling popular dengan jawapan & contoh untuk pemula dan profesional berpengalaman dalam tutorial ini.

Tutorial_#4: Tutorial POSTMAN: Pengujian API Menggunakan POSTMAN

Tutorial langkah demi langkah ini akan menerangkan Pengujian API Menggunakan POSTMAN bersama-sama dengan Asas POSTMAN, Komponennya dan Permintaan Contoh & Balas dalam istilah mudah untuk pemahaman anda yang mudah.

Tutorial_#5: Pengujian Perkhidmatan Web Menggunakan Klien HTTP Apache

Tutorial API ini adalah tentang melaksanakan pelbagai Operasi CRUD pada Perkhidmatan Web dan Menguji Perkhidmatan Web menggunakan Klien HTTP Apache

Tutorial Pengujian API

Bahagian ini akan membantu anda mendapatkan pemahaman asas tentang Perkhidmatan Web dan API Web, yang seterusnya, akan membantu dalam memahami konsep utama dalam tutorial akan datang dalam siri Ujian API ini.

API ( Antara Muka Pengaturcaraan Aplikasi) ialah satu set semua prosedur dan fungsi yang membolehkan kami membuat aplikasi dengan mengakses data atau cirisistem pengendalian atau platform. Pengujian prosedur sedemikian dikenali sebagai Ujian API.

Ujian Shift Kiri

Salah satu jenis ujian penting yang ditanya pada masa kini dalam Temuduga Ujian API ialah Ujian Shift Kiri. Ujian jenis ini diamalkan dalam hampir semua projek yang mengikut Metodologi Agile.

Sebelum Ujian Shift Kiri diperkenalkan, ujian perisian muncul hanya selepas pengekodan selesai dan kod dihantar kepada penguji. Amalan ini membawa kepada kesibukan saat akhir untuk memenuhi tarikh akhir dan ia turut menjejaskan kualiti produk ke tahap yang besar.

Selain itu, usaha yang dilakukan (apabila kecacatan dilaporkan pada fasa terakhir sebelum pengeluaran) adalah besar kerana pembangun perlu melalui kedua-dua fasa reka bentuk dan pengekodan sekali lagi.

Kitaran Hayat Pembangunan Perisian (SDLC) Sebelum Ujian Shift Kiri

Aliran SDLC Tradisional ialah: Keperluan – > Reka bentuk –> Pengekodan –> Pengujian.

Kelemahan Pengujian Tradisional

  • Pengujian berada di bahagian paling kanan. Banyak kos ditanggung apabila pepijat dikenal pasti pada saat akhir.
  • Masa yang digunakan untuk menyelesaikan pepijat dan mengujinya semula sebelum mempromosikannya kepada pengeluaran adalah besar.

Oleh itu, idea baharu muncul untuk mengalihkan fasa ujian ke kiri yang seterusnya membawa kepada Ujian Shift Kiri.

Cadangan Baca => Ujian Shift Kiri: AMantra Rahsia Untuk Kejayaan Perisian

Fasa Ujian Anjakan Kiri

Ujian Anjakan Kiri membawa kepada penghijrahan yang berjaya daripada Pengesanan Kecacatan kepada Pencegahan Kecacatan. Ia juga membantu perisian gagal dengan pantas dan membetulkan semua kegagalan seawal-awalnya.

API Web

Secara umum, API Web boleh ditakrifkan sebagai sesuatu yang mengambil permintaan daripada pelanggan sistem kepada pelayan web dan menghantar semula respons daripada pelayan web kepada mesin pelanggan.

Bagaimana API Berfungsi?

Mari kita ambil senario yang sangat biasa untuk menempah penerbangan di www.makemytrip.com, iaitu perkhidmatan pelancongan dalam talian yang mengagregatkan maklumat daripada berbilang syarikat penerbangan. Apabila anda membuat tempahan penerbangan, anda memasukkan maklumat seperti tarikh perjalanan/tarikh pulang, kelas, dsb. dan klik pada carian.

Ini akan menunjukkan kepada anda harga berbilang syarikat penerbangan dan ketersediaannya. Dalam kes ini, aplikasi berinteraksi dengan API berbilang syarikat penerbangan dan dengan itu memberikan akses kepada data syarikat penerbangan.

Contoh lain ialah www.trivago.com yang membandingkan dan menyenaraikan harga, ketersediaan, dsb. hotel yang berbeza dari bandar tertentu. Laman web ini berkomunikasi dengan API berbilang hotel untuk mengakses pangkalan data dan menyenaraikan harga serta ketersediaan daripada tapak web mereka.

Oleh itu, API Web boleh ditakrifkan sebagai "antara muka yang memudahkan komunikasi antara mesin pelanggan dan yangpelayan web”.

Perkhidmatan Web

Perkhidmatan Web ialah (seperti API Web) perkhidmatan yang berkhidmat dari satu mesin ke mesin lain. Tetapi perbezaan utama yang timbul antara API dan Perkhidmatan Web ialah Perkhidmatan Web menggunakan rangkaian.

Adalah selamat untuk mengatakan bahawa semua Perkhidmatan Web ialah API Web tetapi semua API Web bukan Perkhidmatan Web (diterangkan dalam bahagian akhir artikel). Oleh itu, Perkhidmatan Web ialah subset API Web. Rujuk rajah di bawah untuk mengetahui lebih lanjut tentang API Web dan Perkhidmatan Web.

API Web lwn Perkhidmatan Web

Perkhidmatan Web lwn API Web

Kedua-dua API Web dan Perkhidmatan Web digunakan untuk memudahkan komunikasi antara klien dan pelayan. Perbezaan utama hanya terdapat dalam cara mereka berkomunikasi.

Setiap daripada mereka memerlukan badan permintaan yang boleh diterima dalam bahasa tertentu, perbezaan mereka dalam menyediakan sambungan yang selamat, kelajuan mereka berkomunikasi dengan pelayan dan membalas balik kepada pelanggan, dsb.

Perbezaan Antara Perkhidmatan Web dan API Web disenaraikan di bawah untuk rujukan anda.

Perkhidmatan Web

  • Perkhidmatan Web biasanya menggunakan XML (Bahasa Penanda Boleh Diperluaskan), yang bermaksud ia lebih selamat.
  • Perkhidmatan Web lebih selamat kerana kedua-dua Perkhidmatan Web dan API menyediakan SSL (Lapisan Soket Selamat) semasa penghantaran data , tetapi ia juga menyediakan WSS (Keselamatan Perkhidmatan Web).
  • Perkhidmatan Web ialah subset API Web. Sebagai contoh, Perkhidmatan Web hanya berdasarkan tiga gaya penggunaan iaitu SOAP, REST dan XML-RPC.
  • Perkhidmatan Web sentiasa memerlukan rangkaian untuk beroperasi.
  • Perkhidmatan Web menyokong “Aplikasi berbeza Satu Kod”. Ini bermakna kod yang lebih generik ditulis merentas aplikasi yang berbeza.

API Web

  • API Web biasanya menggunakan JSON (JavaScript Object Notation), yang bermaksud API Web lebih pantas.
  • API Web lebih pantas kerana JSON berwajaran ringan, tidak seperti XML.
  • API Web ialah superset Perkhidmatan Web. Sebagai Contoh, Ketiga-tiga gaya Perkhidmatan Web juga terdapat dalam API Web, tetapi selain itu, ia menggunakan gaya lain seperti JSON – RPC.
  • API Web tidak semestinya memerlukan rangkaian untuk beroperasi.
  • API Web mungkin atau mungkin tidak menyokong kesalingoperasian bergantung pada sifat sistem atau aplikasi.

Memperkenalkan Ujian API Dalam Organisasi Anda

Dalam kehidupan seharian kita, kita semua sudah terbiasa berinteraksi dengan Apl dengan API, namun kita tidak memikirkan proses bahagian belakang yang mendorong kefungsian asas.

Sebagai Contoh , Mari kita pertimbangkan bahawa anda menyemak imbas produk di Amazon.com dan anda melihat produk/tawaran yang anda sangat suka dan anda ingin berkongsi dengan rangkaian Facebook anda.

Setelah anda mengklik pada ikon Facebook pada bahagian kongsi halaman dan masukkan andaBukti kelayakan akaun Facebook untuk dikongsi, anda sedang berinteraksi dengan API yang menghubungkan tapak web Amazon dengan lancar ke Facebook.

Anjakan Fokus kepada Ujian API

Sebelum membincangkan lebih lanjut mengenai ujian API, mari kita bincangkan sebabnya yang mana aplikasi berasaskan API telah mendapat populariti sejak kebelakangan ini.

Terdapat beberapa sebab organisasi beralih kepada produk dan aplikasi berasaskan API. Dan beberapa daripada mereka disenaraikan di bawah untuk rujukan anda.

#1) Aplikasi berasaskan API lebih berskala jika dibandingkan dengan aplikasi/perisian tradisional. Kadar pembangunan kod adalah lebih pantas dan API yang sama boleh menyediakan lebih banyak permintaan tanpa sebarang kod utama atau perubahan infrastruktur.

#2) Pasukan pembangunan tidak perlu memulakan pengekodan dari awal setiap masa mereka mula bekerja untuk membangunkan ciri atau aplikasi. API paling kerap menggunakan semula fungsi sedia ada, boleh berulang, perpustakaan, prosedur tersimpan, dsb. dan oleh itu proses ini boleh menjadikannya lebih produktif secara keseluruhan.

Sebagai contoh, Jika anda seorang pembangun yang bekerja pada tapak web e-dagang dan anda ingin menambah Amazon sebagai pemproses pembayaran – maka anda tidak perlu menulis kod dari awal.

Apa yang anda perlu lakukan ialah menyediakan penyepaduan antara tapak web anda dan API Amazon menggunakan Kunci integrasi dan hubungi Amazon API untuk memproses pembayaran semasa pembayaran.

#3) API membenarkanpenyepaduan mudah dengan sistem lain untuk aplikasi kendiri yang disokong dan juga dengan produk perisian berasaskan API.

Sebagai Contoh , Mari kita pertimbangkan bahawa anda ingin menghantar penghantaran dari Toronto ke New York . Anda pergi ke dalam talian, navigasi ke laman web Freight atau Logistics yang terkenal dan masukkan maklumat yang diperlukan.

Selepas memberikan maklumat wajib, apabila anda mengklik butang Dapatkan Kadar – di bahagian belakang, laman web logistik ini mungkin bersambung dengan beberapa API pembawa dan pembekal perkhidmatan dan aplikasi untuk mendapatkan kadar dinamik bagi gabungan lokasi asal ke destinasi.

Spektrum Penuh Pengujian API

Pengujian API tidak terhad kepada menghantar permintaan kepada API dan menganalisis respons untuk ketepatan sahaja. API perlu diuji untuk prestasinya di bawah beban yang berbeza untuk kelemahan.

Mari bincangkan perkara ini secara terperinci.

(i) Ujian Fungsian

Ujian fungsional boleh menjadi tugas yang mencabar kerana kekurangan antara muka GUI.

Mari kita lihat bagaimana pendekatan ujian berfungsi untuk API berbeza daripada aplikasi berasaskan GUI dan kami juga akan membincangkan beberapa contoh di sekelilingnya.

a) Perbezaan yang paling jelas ialah tiada GUI untuk berinteraksi. Penguji yang biasanya melakukan ujian fungsian berasaskan GUI mendapati sukar sedikit untuk beralih ke ujian aplikasi bukan GUI jika dibandingkan denganseseorang yang sudah biasa dengannya.

Pada mulanya, walaupun sebelum anda mula menguji API, anda perlu menguji dan mengesahkan proses Pengesahan itu sendiri. Kaedah pengesahan akan berbeza dari satu API ke API yang lain dan akan melibatkan sejenis kunci atau token untuk pengesahan.

Jika anda tidak dapat menyambung ke API dengan jayanya, maka ujian lanjut tidak boleh diteruskan. Proses ini boleh dianggap setanding dengan pengesahan pengguna dalam aplikasi standard di mana anda memerlukan bukti kelayakan yang sah untuk log masuk dan menggunakan aplikasi.

b) Menguji pengesahan medan atau pengesahan data input adalah sangat penting semasa menguji API. Jika antara muka berasaskan borang (GUI) sebenar tersedia, maka pengesahan medan boleh dilaksanakan di hujung hadapan atau belakang, dengan itu memastikan pengguna tidak dibenarkan memasukkan nilai medan yang tidak sah.

Sebagai Contoh, Jika permohonan memerlukan format tarikh ialah DD/MM/YYYY, maka kami boleh menggunakan pengesahan ini pada borang pengumpulan maklumat untuk memastikan bahawa permohonan itu menerima dan memproses tarikh yang sah.

Walau bagaimanapun, ini tidak sama untuk aplikasi API. Kami perlu memastikan bahawa API ditulis dengan baik dan dapat menguatkuasakan semua pengesahan ini, membezakan antara data yang sah dan tidak sah dan mengembalikan kod status dan mesej ralat pengesahan kepada pengguna akhir melalui respons.

c) Menguji

Gulung ke atas