Isi
Kata "API" berkedip-kedip di lowongan, bahkan untuk penguji pemula. Entah REST API, lalu SOAP API, lalu hanya API. Hewan apa ini? Mari kita cari tahu!
"Kenapa aku butuh ini?" Saya sebenarnya sedang menguji web! Sekarang, jika saya masuk ke otomatisasi, maka ya ... Ya, mereka juga mengujinya di perusahaan, saya mendengar ...
Dan tidak! Baik bagi setiap penguji untuk mengetahui tentang API. Karena di dalamnya sistem saling berinteraksi. Dan Anda melihat interaksi ini setiap hari bahkan di situs yang paling sederhana dan kumuh.
Pembayaran apa pun melalui API sistem pembayaran. Membeli tiket film? Kaos di toko online? Buku? Segera setelah Anda mengklik "bayar", situs menghubungkan Anda ke sistem pembayaran.
Tetapi bahkan jika Anda tidak memiliki integrasi dengan sistem lain, Anda masih memiliki API! Karena sistem di dalamnya sendiri juga berkomunikasi melalui api. Dan sementara pengembang depan sangat menggerogoti GUI (antarmuka grafis), Anda dapat:
- bosan saat menunggu;
- periksa logika kerja API
Tentu saja, saya memilih opsi kedua! Jadi mari kita pahami apa itu API. Anda dapat menonton video di
youtube , atau membaca sebagai artikel.
Apa itu API?
API (Antarmuka pemrograman aplikasi) adalah kontrak yang disediakan oleh suatu program. "Aku bisa dihubungi dengan cara ini dan itu, aku berjanji untuk melakukan ini dan itu."
Jika diterjemahkan ke dalam bahasa Rusia, itu akan menjadi kata "kontrak". Perjanjian antara dua pihak, sebagai perjanjian untuk membeli mobil:
- tanggung jawab saya adalah membuat jumlah sebesar itu
- tugas penjual adalah memberi mobil.
Anda bisa menerjemahkan, ya. Tapi tidak ada yang melakukan itu ¯ \ _ (ツ) _ / ¯
Semua orang menggunakan kata "kontrak." Sangat diterima. Selain itu, kata ini termasuk dalam nama gaya pengembangan:
- Kode pertama - pertama kita menulis kode, lalu kita membuat kontrak untuk itu
- Kontrak dulu - pertama kita membuat kontrak, lalu kita menulis atau membuat kode di atasnya (dalam artikel ini saya akan berbicara tentang gaya ini)
Kami tidak mengatakan "kontrak untuk penjualan mobil"? Jadi para pengembang tidak mengatakan "kontrak." Perjanjian diam-diam.
API - set fitur
Ketika Anda membeli mobil, Anda membuat kontrak di mana Anda meresepkan semua poin yang penting bagi Anda. Demikian pula, kontrak harus dibuat antar program. Mereka menunjukkan bagaimana satu atau program lain dapat diakses.
Dengan demikian, API menjawab pertanyaan "Bagaimana saya bisa menghubungi sistem saya?", Dan termasuk:
- operasi itu sendiri yang bisa kita lakukan
- input data
- data keluaran (konten data atau pesan kesalahan).
Di sini Anda dapat memberi tahu saya:
- Hmm, tunggu sebentar. Operasi, data input, data keluaran - entah bagaimana semua ini sangat mirip dengan deskripsi fungsi!
Jika Anda pernah menemukan pengembangan atau hanya belajar bahasa pemrograman, Anda mungkin tahu apa fungsi itu. Faktanya, kita memiliki data input, ada data output, dan beberapa sihir yang mengubah satu sama lain.Dan ya! Anda akan benar bahwa definisinya sama. Mengapa Ya, karena API adalah sekumpulan fungsi. Ini mungkin satu fungsi, atau mungkin banyak.
Bagaimana set fitur dikompilasi
Ya, bagaimanapun caranya. Seperti yang diinginkan pengembang, ia akan dikelompokkan. Misalnya, Anda dapat mengelompokkan API berdasarkan fungsionalitas. Itu adalah:
- API terpisah untuk memasuki sistem, tempat pendaftaran dan otorisasi akan;
- API terpisah untuk pelaporan - laporan 1, laporan 2, laporan 3 ... laporan N. Untuk laporan berbeda, kami memiliki rumus berbeda = fungsi berbeda. Dan kita semua mengumpulkannya dalam satu set, api untuk pelaporan.
- API sistem pembayaran terpisah - ada fungsi untuk bekerja dengan masing-masing bank.
- ...
Anda tidak dapat mengelompokkan sama sekali, tetapi membuat satu API yang umum.
Satu API umum dapat dibuat, dan sisanya dapat dibuat sesuai pesanan. Jika Anda memiliki produk kotak, maka biasanya mencakup serangkaian fitur standar. Dan setiap pelanggan Wishlist dibuat secara terpisah.
Ternyata dalam sistem kami ada beberapa API yang berbeda, untuk masing-masingnya kami memiliki kontrak tertulis. Setiap kontrak dengan jelas menjabarkan operasi apa yang dapat dilakukan, fungsi apa yang akan ada
Dan tentu saja, fungsi dapat digunakan kembali. Artinya, fungsi yang sama dapat dimasukkan dalam set yang berbeda, dalam api yang berbeda. Tidak ada yang melarang ini.
Rupanya pengembang itu datang dengan jenis API apa yang akan dimilikinya. Entah umum, atau mendistribusikan sesuai dengan fungsionalitas atau beberapa kriteria sendiri, dan di masing-masing api menambahkan set fungsi yang dibutuhkan.
Apa kata "antarmuka"
- Tunggu sebentar, Olya! Anda sendiri yang menulis di atas bahwa API adalah antarmuka pemrograman Aplikasi. Mengapa Anda kemudian berbicara tentang kontrak, meskipun ada antarmuka kata?
Ya, karena dalam pemrograman kontrak adalah antarmuka. Dalam deskripsi klasik OOP (Pemrograman Berorientasi Objek) ada 3 paus:
- Enkapsulasi
- Warisan
- Polimorfisme
Enkapsulasi adalah saat kita menyembunyikan implementasinya. Untuk pengguna, semuanya mudah dan jelas. Saya mengklik tombol - Saya mendapat laporan. Dan cara kerjanya dari dalam ke luar - dia tidak peduli. Basis data mana yang disembunyikan di bawah tenda? Oracle? MySQL? Bahasa pemrograman apa yang tertulis dalam program ini? Bagaimana tepatnya kode ini disusun? Bukan itu intinya. Program ini menyediakan antarmuka, dan menggunakannya.
Tidak selalu program menyediakan antarmuka grafis. Ini bisa berupa SOAP, antarmuka REST, atau API lainnya. Untuk menggunakan antarmuka ini, Anda harus mengerti:
- apa yang harus dimasuki;
- apa yang keluar;
- pengecualian apa yang perlu ditangani.
Pengguna bekerja dengan
GUI - antarmuka pengguna grafis . Program bekerja dengan
API - Antarmuka pemrograman aplikasi . Mereka tidak membutuhkan grafik, hanya kontrak.
Bagaimana API disebut
Anda dapat memanggil api baik secara langsung maupun tidak langsung.
Secara langsung:
- Sistem memanggil fungsi di dalam dirinya sendiri.
- Sistem memanggil metode sistem lain
- Manusia memanggil suatu metode
- Metode tarik otomatis
Secara tidak langsung:
- Pengguna bekerja dengan GUI
Panggilan API secara langsung
1. Sistem memanggil fungsi di dalam dirinya sendiri
Bagian-bagian berbeda dari program entah bagaimana berkomunikasi satu sama lain. Mereka melakukan ini di tingkat program, yaitu, di tingkat API!
Ini adalah cara termudah untuk digunakan, karena pembuat API yang dipanggil adalah pengembang. Dan dia adalah konsumennya! Jadi, tidak ada masalah dengan dokumentasi yang tidak relevan =)
Hanya bercanda, selalu ada masalah dengan dokumentasi. Hanya dalam kasus ini, sebagai dokumentasi, akan ada komentar dalam kode. Tapi sayangnya, mereka juga tidak relevan. Entah para pengembang berbeda, atau satu, tapi saya sudah lupa bagaimana saya melakukan api asli dan bagaimana seharusnya bekerja ...
2. Sistem memanggil metode sistem lain
Tapi ini adalah kasus khas yang diuji penguji dalam integrator. Atau penguji yang menguji integrasi sistem mereka dengan orang lain.
Satu sistem menarik api beberapa metode sistem lain. Dia mungkin mencoba mendapatkan data dari sistem lain. Atau sebaliknya, kirim data ke sistem ini.
Misalkan saya memutuskan untuk menghubungkan permintaan dari Dadata ke toko online saya, sehingga pengguna dengan mudah memasukkan alamat pengiriman.
Saya menghubungkan petunjuk API. Dan sekarang, ketika pengguna mulai memasukkan alamat di situs saya , ia melihat petunjuk dari Dadata . Bagaimana hasilnya:
- Dia memasukkan surat ke situs saya
- Situs saya mengirim permintaan di petunjuk API Dadat
- Dadata mengembalikan jawabannya
- Situs saya memprosesnya dan menampilkan hasilnya kepada pengguna.
Ada begitu banyak langkah! Dan untuk setiap karakter yang dimasukkan. Pengguna tidak melihat interaksi ini, tetapi interaksi itu terjadi.
Dan, tentu saja, jangan lupa tentang kasus ketika kita mengembangkan metode API. Yang hanya bisa dipanggil melalui SOAP, tidak ditemukan di antarmuka. Apa yang dipesan Pelanggan, kami lakukan ¯ \ _ (ツ) _ / ¯
Contoh dapat ditemukan di Pengguna. Metode MagicSearch didasarkan pada peristiwa nyata. Meskipun harus saya akui, dalam logika asli bahkan lebih canggih, saya menyesuaikannya dengan situs saya.
Tapi triknya di sini adalah bahwa dalam sistem itu sendiri di antarmuka pengguna hanya ada pencarian biasa, hanya jalur input. Yah, mungkin beberapa filter. Tetapi integrasi membutuhkan sejumlah fitur tambahan, yang dilakukan melalui metode SOAP.
Fungsionalitas pencarian super hanya tersedia oleh API, pengguna di antarmuka tidak merasakannya.
Dalam hal ini, Anda biasanya memiliki TK, yang sesuai dengan metode API bekerja. Tugas Anda adalah memeriksanya. Tugas khas seorang penguji, cukup tambahkan ke desain pengujian standar untuk menguji fitur-fitur pengujian API, dan semuanya tergantung pada kemampuan!
(apa sebenarnya yang perlu diuji di API - saya akan ceritakan di artikel terpisah nanti)3. Orang tersebut memanggil metode
Alasannya berbeda:
- Untuk mempercepat kerja
- Untuk melokalkan bug (di mana masalahnya? Di server atau klien?)
- Untuk menguji logika tanpa putaran tepi
Jika sistem menyediakan API, biasanya lebih mudah menariknya daripada melakukan hal yang sama melalui antarmuka grafis. Selain itu, panggilan API dapat disimpan di alat. Setelah disimpan - Anda berlaku di pangkalan mana pun, bahkan jika itu dibersihkan 10 kali sehari.
Sebagai contoh, kita kembali ke Pengguna . Jika kami ingin membuat pengguna, kami harus mengisi banyak kolom!
Tentu saja, ini dapat dilakukan dengan menggunakan plugin khusus seperti Form Filler . Tetapi bagaimana jika Anda membutuhkan data uji yang memadai untuk sistem Anda? Dan dalam bahasa Rusia?
Mengisi ladang secara manual menyedihkan dan menyedihkan! Dan jika Anda perlu mengulanginya setiap minggu atau hari dengan dasar tes bersih - umumnya mimpi buruk. Ini segera menjadi prioritas pertama pada otomatisasi tindakan rutin.
Dan dalam hal ini, peran otomatisasi melakukan ... Tukang pos. Seorang pengguna dapat dibuat melalui permintaan CreateUser REST. Setelah terdaftar data "seperti nyata" yang normal, setiap kali kami menggunakannya. Untung!
Alih-alih mengisi formulir secara manual (1 menit mengisi kolom tanpa berpikir dengan nilai "lprulpk"), kita mendapatkan 1 detik dengan menekan tombol "Kirim". Dalam hal ini, nilainya akan jauh lebih memadai.
Dan di tukang pos Anda dapat membuat folder terpisah untuk menyiapkan basis tes, menjejalkan selusin permintaan di sana. Dan sekarang di pangkalan mana pun dalam beberapa detik Anda mendapatkan data sebanyak yang Anda bisa berkendara secara manual selama berjam-jam!
Jika Anda menemukan bug dan tidak mengerti kepada siapa harus menggantungnya - pengembang front-end atau back-end, hapus semua yang tidak perlu. Panggil metode tanpa antarmuka grafis. Dan Anda dapat menguji logika program hingga antarmuka siap atau rusak.
4. Autotests menarik metode
Ada piramida otomatisasi khas:
- Tes GUI adalah tes jujur, "bagaimana pengguna akan melakukannya."
- Tes API - kami turun ke level di bawah, membuang terlalu banyak.
- Tes unit - tes untuk satu fungsi
Kata API mengisyaratkan apa yang akan digunakan dalam pengujian ツ
Katakanlah kita memiliki:
- operasi : unduhan laporan;
- di input : data dari penyesuaian manual atau otomatis atau dari beberapa tempat lain;
- output : laporan yang dibuat sesuai dengan aturan tertentu
Laporkan aturan bangunan:
- Sel 1 : X - Y
- Sel 2 : Z * 6
- ...
Tes GUI adalah tes jujur, robot melakukan semua yang pengguna akan lakukan. Ini membuka browser, menekan tombol ... Tetapi jika sesuatu jatuh, Anda akan mencari tahu di mana tepatnya untuk waktu yang lama.
Tes API sama, hanya tanpa browser. Kami hanya mengirimkan data ke input dan memeriksa data di output. Misalnya, Anda dapat memasukkan jawaban terakhir di Excel, dan membiarkan robot merekonsiliasi, apakah data diisi dengan benar? Menemukan masalah menjadi lebih mudah.
Tes unit adalah saat kami menguji setiap fungsi secara terpisah. Kami melihat secara terpisah pada perhitungan untuk sel 1, secara terpisah untuk sel 2, dan seterusnya. Tes semacam itu paling cepat dikejar dan bug mudah dilokalisasi.
Panggilan API tidak langsung
Ketika pengguna bekerja dengan GUI, pada kenyataannya, ia juga bekerja dengan API. Dia sama sekali tidak tahu tentang itu, dia sama sekali tidak membutuhkannya.
Yaitu, ketika pengguna membuka sistem dan mencoba mengunduh laporan, tidak masalah bagaimana sistem itu bekerja, jenis sihir apa yang ada di dalamnya. Dia memiliki tombol "unduh laporan", yang dia klik. Pengguna bekerja melalui GUI (antarmuka pengguna grafis).
Namun pada kenyataannya, ada API di bawah antarmuka pengguna grafis ini. Dan ketika pengguna mengklik tombol, tombol memanggil fungsi pembuatan laporan.
Dan fungsi pembuatan laporan sudah dapat memanggil 10 fungsi lain yang berbeda, jika perlu.
Dan sekarang pengguna melihat laporan yang sudah jadi di depannya. Dia menyebut API kompleks tanpa menyadarinya!
Apakah maksud Pengujian API?
Pertama-tama, maksud kami adalah pengujian VIA API. "Pengujian API" adalah istilah yang umum digunakan, mereka benar-benar mengatakannya, tetapi secara teknis istilah itu salah. Kami tidak menguji API, kami tidak menguji GUI (antarmuka grafis). Kami sedang menguji beberapa jenis fungsi melalui antarmuka grafis atau perangkat lunak.
Tapi ini adalah ekspresi yang mapan. Anda dapat menggunakannya dan mengatakan "pengujian API". Dan ketika kita membicarakannya, maksud kita:
- Tes mandiri tingkat API
- atau integrasi antara dua sistem yang berbeda.
Integrasi - ketika satu sistem berkomunikasi dengan yang lain melalui semacam protokol transfer data. Ini disebut Remote API, yaitu komunikasi melalui jaringan, melalui beberapa protokol (HTTP, JMS, dll.). Berbeda dengan itu, ada juga API Lokal (alias "Shared memory API") - ini adalah API yang dengannya program berkomunikasi dengan dirinya sendiri atau berkomunikasi dengan program lain dalam memori virtual yang sama.
Ketika kita berbicara tentang pengujian API, yang paling sering kita maksudkan adalah pengujian Remote APIs. Ketika kami memiliki dua sistem yang terletak di komputer yang berbeda yang entah bagaimana berkomunikasi satu sama lain.
Dan jika Anda melihat "pengujian API" dalam lowongan, kemungkinan besar ini menyiratkan kemampuan untuk memanggil layanan SOAP atau REST dan mengujinya. Meskipun selalu layak diklarifikasi!
Ringkasan
API (Antarmuka pemrograman aplikasi) adalah kontrak yang disediakan oleh suatu program. "Aku bisa dihubungi dengan cara ini dan itu, aku berjanji untuk melakukan ini dan itu."
Kontrak tersebut meliputi:
- operasi itu sendiri yang bisa kita lakukan
- input data
- data keluaran (konten data atau pesan kesalahan). ".