Pengujian manual berfungsi dengan baik sampai tidak lagi. Seorang pengembang dapat mengklik beberapa _endpoint_ sebelum rilis. Tim yang menjalankan lima puluh layanan di selusin _environment_ tidak bisa, dan pada hari mereka mencoba, sesuatu yang belum diuji akan terkirim. Pengujian otomatis adalah jawaban untuk masalah penskalaan tersebut: biarkan mesin menjalankan pemeriksaan berulang, setiap saat, sehingga manusia mencurahkan perhatian mereka pada hal yang penting.
Panduan ini menjelaskan apa itu pengujian otomatis, di mana ia membantu dan di mana ia tidak, serta memandu pengaturan pengujian API otomatis langkah demi langkah di Apidog.
Apa itu pengujian otomatis
Pengujian otomatis berarti menggunakan perangkat lunak untuk menjalankan pengujian dan memeriksa hasil, alih-alih seseorang melakukan setiap langkah secara manual. Anda mendefinisikan sebuah pengujian satu kali: masukan, tindakan, dan hasil yang diharapkan. Sejak saat itu, sebuah alat menjalankannya sesuai permintaan, sesuai jadwal, atau pada setiap perubahan kode, dan melaporkan berhasil atau gagal tanpa perlu ada yang mengawasinya.
Pergeseran ini bukan hanya soal kecepatan. Ini tentang konsistensi. Penguji manusia yang menjalankan pemeriksaan yang sama lima puluh kali akan menjalankannya sedikit berbeda setiap saat dan akan lelah pada yang keempat puluh. Sebuah pengujian otomatis menjalankan putaran kelima puluh persis seperti yang pertama. Kemampuan pengulangan itulah produk nyata dari otomatisasi.
Pengujian otomatis berlaku di seluruh tumpukan: _unit test_ untuk fungsi, _integration test_ untuk komponen, _UI test_ untuk antarmuka, dan _API test_ untuk _endpoint_. Pengujian API seringkali merupakan tempat bernilai tertinggi untuk memulai, karena API stabil, cepat dipanggil, dan membawa logika bisnis inti. Sebuah pengujian API berjalan dalam hitungan milidetik dan tidak memiliki _browser_ yang _flaky_ untuk dilawan.
Mengapa tim mengotomatiskan pengujian
Pengujian manual tidak dapat diskalakan. Setiap _endpoint_ baru menambah pemeriksaan. Setiap _environment_ melipatgandakannya. Melebihi ukuran tertentu, cakupan manual penuh sebelum setiap rilis menjadi mustahil secara fisik, sehingga ada bagian yang diabaikan secara diam-diam.
Regresi luput tanpa itu. Perubahan pada satu layanan dapat merusak kontrak tiga layanan berikutnya. Hanya _suite_ yang menjalankan ulang semuanya pada setiap perubahan yang dapat mendeteksinya, dan hanya otomatisasi yang membuat "jalankan ulang semuanya" cukup murah untuk dilakukan secara konstan.
Pengujian menjadi aset yang dapat digunakan kembali. Pengujian manual selesai begitu dijalankan. Pengujian otomatis ditulis sekali dan dijalankan ribuan kali. Biayanya di awal; hasilnya berlipat ganda.
Umpan balik menjadi cepat. Ketika pengujian berjalan otomatis dalam _pipeline_, seorang pengembang akan mengetahui dalam hitungan menit bahwa sebuah perubahan merusak sesuatu, sementara konteksnya masih segar. _Bug_ yang ditemukan di produksi jauh lebih mahal untuk diperbaiki daripada _bug_ yang sama yang ditemukan di CI.
Orang melakukan pekerjaan yang lebih baik. Otomatisasi tidak menggantikan penguji. Ini membebaskan mereka dari klik-klik yang berulang-ulang sehingga mereka dapat melakukan _exploratory testing_, mencari kasus-kasus ekstrem (_edge-case_), dan pekerjaan kegunaan, hal-hal yang tidak bagus dilakukan oleh mesin.
Apa yang tidak dipecahkan oleh pengujian otomatis
Otomatisasi tidak gratis, dan berpura-pura sebaliknya akan menyebabkan kekecewaan.
Pengujian otomatis membutuhkan upaya untuk ditulis dan upaya untuk dipelihara. Ketika API berubah, pengujian juga ikut berubah. _Suite_ pengujian yang usang yang gagal karena alasan yang salah lebih buruk daripada tidak memiliki _suite_ sama sekali, karena tim akan terbiasa mengabaikan _build_ yang merah.
Otomatisasi juga tidak dapat menilai apakah perangkat lunak itu baik, hanya apakah itu sesuai dengan apa yang Anda perintahkan untuk diharapkan dalam pengujian. Ia tidak akan menyadari bahwa _workflow_ membingungkan atau bahwa respons, meskipun secara teknis benar, tidak berguna bagi klien. Penilaian itu tetap ada pada manusia.
Dan tidak semua hal layak untuk diotomatiskan. Pemeriksaan yang akan Anda jalankan dua kali tidak. Pemeriksaan yang akan Anda jalankan pada setiap _commit_ selama dua tahun jelas layak. Otomatiskan jalur yang stabil, berulang, dan bernilai tinggi terlebih dahulu; biarkan pekerjaan yang jarang dan _exploratory_ tetap manual.
Cara mengatur pengujian API otomatis di Apidog
Apidog membangun pengujian API otomatis secara visual, sehingga Anda tidak perlu menulis atau memelihara _script_ pengujian untuk mendapatkan _suite_ yang berfungsi. Berikut adalah alur lengkapnya.
Langkah 1: Definisikan atau impor API Anda. Masukkan _endpoint_ Anda dari file OpenAPI, koleksi Postman, atau definisikan langsung di Apidog. Setiap _endpoint_ membawa skema permintaan dan skema responsnya, yang menjadi dasar untuk _assertion_. Jika Anda memulai dari spesifikasi, kontrak API dan pengujian akan tetap sinkron secara otomatis.
Langkah 2: Tambahkan _assertion_ ke setiap permintaan. Untuk sebuah _endpoint_, buka panel _assertion_ dan tambahkan pemeriksaan tanpa _coding_: status sama dengan 200, _field_ _body_ ada dan memiliki tipe yang benar, respons sesuai dengan skema, waktu respons di bawah anggaran Anda. _Assertion_ API visual ini adalah inti dari pengujian; permintaan tanpa _assertion_ hanya membuktikan bahwa server menjawab.
Langkah 3: Buat skenario pengujian. Kelompokkan permintaan terkait ke dalam skenario bernama, misalnya "siklus hidup pengguna". Rantai (_chain_) mereka sehingga _output_ mengalir ke bawah: sebuah _login_ mengembalikan _token_, permintaan berikutnya mengonsumsinya. Setiap blok permintaan-plus-_assertion_ adalah kasus pengujian; cara menulis kasus pengujian API membahas strukturnya.
Langkah 4: Tambahkan cakupan berbasis data. Lampirkan file CSV atau JSON sehingga satu skenario berjalan terhadap banyak baris masukan. Alih-alih menulis dua puluh kasus yang hampir identik, Anda menulis satu dan memberinya dua puluh _dataset_. Pengujian API berbasis data adalah cara sebuah _suite_ kecil mencakup ruang masukan yang besar.
Langkah 5: Jalankan skenario. Eksekusi sesuai permintaan dan atur jumlah iterasi, katakanlah lima puluh kali, untuk memeriksa stabilitas di bawah pengulangan. Apidog menjalankan setiap kasus, mengevaluasi setiap _assertion_, dan menghasilkan laporan yang menyebutkan _assertion_ yang gagal secara tepat, dengan nilai yang diharapkan dan aktual.
Langkah 6: Susun menjadi _test suite_. Kumpulkan skenario ke dalam _test suite_ sehingga seluruh API dapat dijalankan dalam satu klik. _Suite_ menjaga _basis_ pengujian yang berkembang tetap mudah dikelola seiring dengan perluasan cakupan.
Langkah 7: Hubungkan ke CI/CD. Ini adalah langkah yang mengubah _test suite_ menjadi pengujian otomatis. Jalankan _suite_ pada setiap _commit_ atau _pull request_ sehingga regresi muncul sebelum penggabungan (_merge_). Apidog berjalan di _pipeline_ mana pun; mengotomatiskan pengujian API di CI/CD menjelaskannya, dan menjalankan pengujian API di GitHub Actions mencakup platform tersebut secara khusus.
Unduh Apidog untuk membangun skenario otomatis pertama Anda dan melihatnya berjalan.
Jenis-jenis utama pengujian otomatis
Pengujian otomatis bukanlah satu hal. Ini adalah kumpulan jenis pengujian yang berlapis, masing-masing menangkap kelas _bug_ yang berbeda dengan biaya yang berbeda.
_Unit test_ memeriksa satu fungsi atau kelas secara terpisah. Mereka cepat, murah, dan berjalan ribuan kali, tetapi mereka tidak dapat menangkap masalah yang hanya muncul ketika komponen saling berkomunikasi.
_Integration test_ memeriksa apakah komponen bekerja sama: sebuah layanan dan basis datanya, atau dua layanan di batas jaringan. Mereka menangkap _bug_ _wiring_ yang dilewatkan oleh _unit test_, dengan biaya yang lebih lambat dan membutuhkan lebih banyak pengaturan.
_API test_ berada pada titik yang strategis. Mereka melatih sebuah _endpoint_ melalui HTTP, dengan cara yang sama seperti klien sungguhan, sehingga mereka memverifikasi kontrak aktual. Mereka berjalan cepat, tidak memerlukan _browser_, dan mencakup logika bisnis yang paling penting. Bagi sebagian besar tim, ini adalah lapisan dengan _return on effort_ terbaik.
_End-to-end test_ menjalankan alur kerja lengkap melalui sistem nyata, seringkali termasuk UI. Mereka adalah yang paling realistis dan paling lambat, dan cenderung paling _flaky_, sehingga tim membatasi jumlahnya dan fokus pada alur-alur kritis.
Piranti pengujian yang sering dikutip menggambarkan keseimbangan: banyak _unit test_ yang cepat di bagian dasar, lebih sedikit _integration_ dan _API test_ di tengah, dan lapisan tipis _end-to-end test_ di atas. Sebuah _suite_ yang berbentuk terbalik, sebagian besar _end-to-end test_ yang lambat, berjalan lambat dan gagal secara tidak terduga. _API test_ adalah tempat sebuah tim mendapatkan cakupan yang luas dan andal tanpa membayar "pajak _end-to-end_", itulah mengapa mereka adalah titik awal yang direkomendasikan.
Membuat otomatisasi membuahkan hasil
Beberapa kebiasaan membedakan _suite_ yang memberikan manfaat dari _suite_ yang menjadi usang.
Dekatkan pengujian dengan desain API. Ketika kontrak dan pengujian berada di satu tempat, perubahan kontrak sulit untuk dilupakan dalam pengujian. Pergeseran (_drift_) adalah alasan utama _suite_ memburuk.
Nyatakan hasil yang sebenarnya, bukan hanya kode status. Pengujian otomatis yang hanya memeriksa kode 200 akan lulus (_pass_) meskipun mengembalikan data yang tidak relevan (_garbage_). Otomatiskan _assertion_ yang kuat atau Anda telah mengotomatiskan rasa aman yang palsu.
Buat kegagalan dapat dibaca. Laporan yang baik menyebutkan _assertion_ yang gagal, bukan hanya pengujian yang gagal. Semakin cepat seorang pengembang dapat membaca kegagalan, semakin tim mempercayai _suite_ tersebut.
Jalankan di mana keputusan dibuat. _Suite_ yang hanya berjalan ketika seseorang mengingatnya bukanlah otomatisasi. Masukkan ke dalam _pipeline_ agar berjalan tanpa diminta.
Andalkan AI untuk bagian-bagian yang membosankan. Menghasilkan draf pertama kasus dari spesifikasi, atau memperluas kasus ekstrem (_edge case_), sangat cocok untuk bantuan; pengujian otomatis API yang ditingkatkan AI menunjukkan di mana itu membantu dan di mana tinjauan manusia masih diperlukan.
Pertanyaan yang sering diajukan
Apakah pengujian otomatis lebih baik dari pengujian manual? Keduanya tidak saling menggantikan. Otomatiskan pemeriksaan yang stabil, berulang, dan bernilai tinggi. Pertahankan _exploratory testing_, tinjauan kegunaan, dan pekerjaan yang membutuhkan banyak penilaian secara manual. Tim terbaik melakukan keduanya.
Apakah saya perlu tahu cara _coding_ untuk mengotomatiskan pengujian API? Tidak dengan alat visual. Di Apidog Anda membangun permintaan, _assertion_, dan skenario dengan mengklik, dan masuk ke _script_ hanya untuk logika yang tidak dapat diekspresikan oleh _builder_ visual.
Di mana tim harus memulai dengan otomatisasi? Pengujian API. Mereka cepat, stabil, dan mencakup logika inti, tanpa ketidakstabilan (_flakiness_) otomatisasi UI. Mulai dengan _endpoint_ kritis dan perluas.
Berapa banyak pemeliharaan yang dibutuhkan pengujian otomatis? Mereka berubah setiap kali API berubah. Menjaga pengujian tetap dekat dengan desain API meminimalkan kejutan, tetapi anggarkan waktu berkelanjutan; _suite_ yang tidak terpelihara berhenti dapat dipercaya.
Apa yang membuat pengujian otomatis tidak stabil (_flaky_), dan bagaimana cara memperbaikinya? Ketidakstabilan (_flakiness_) biasanya berasal dari asumsi waktu, status bersama antar pengujian, atau _assertion_ pada data yang tidak stabil seperti _timestamp_. Perbaiki dengan mengisolasi data pengujian, menyatakan pada struktur daripada nilai _volatile_ yang tepat, dan menghapus urutan implisit antar pengujian. _Suite_ yang tidak stabil (_flaky_) melatih tim untuk mengabaikan kegagalan, jadi perlakukan ketidakstabilan sebagai _bug_ yang nyata.
Bagaimana cara mengukur apakah pengujian otomatis saya berfungsi? Lacak berapa banyak _bug_ nyata yang ditangkap _suite_ sebelum rilis dibandingkan berapa banyak yang lolos ke produksi, dan seberapa cepat _suite_ berjalan. _Suite_ yang hijau selama berbulan-bulan sementara _bug_ produksi lolos tidak melindungi Anda; cakupan _assertion_ yang bermakna lebih penting daripada jumlah pengujian mentah.