Pengujian manual masih berguna untuk eksplorasi, tetapi cepat menjadi bottleneck saat API, environment, dan frekuensi rilis bertambah. Untuk pemeriksaan yang berulang—status response, struktur body, kontrak schema, dan alur antar-endpoint—gunakan pengujian otomatis agar mesin menjalankan validasi yang sama secara konsisten setiap kali ada perubahan.
Panduan ini menjelaskan konsep pengujian otomatis, kapan sebaiknya digunakan, kapan tidak, dan cara menyiapkan pengujian API otomatis di Apidog.
Apa itu pengujian otomatis
Pengujian otomatis adalah proses menjalankan skenario pengujian menggunakan perangkat lunak, bukan secara manual. Anda mendefinisikan:
- input
- langkah eksekusi
- hasil yang diharapkan
- assertion untuk menentukan pass atau fail
Setelah dibuat, pengujian dapat dijalankan:
- sesuai permintaan
- berdasarkan jadwal
- pada setiap commit
- pada pull request
- di pipeline CI/CD
Nilai utamanya bukan hanya kecepatan, tetapi konsistensi. Pengujian otomatis menjalankan pemeriksaan yang sama dengan cara yang sama, tanpa kelelahan dan tanpa variasi manual.
Pengujian otomatis dapat diterapkan di beberapa lapisan:
- Unit test untuk fungsi atau class
- Integration test untuk interaksi antar-komponen
- API test untuk endpoint dan kontrak HTTP
- End-to-end test untuk workflow lengkap
Untuk banyak tim, API test adalah titik awal yang praktis karena cepat dijalankan, lebih stabil daripada UI test, dan langsung memvalidasi logika bisnis inti.
Mengapa tim mengotomatiskan pengujian
1. Pengujian manual sulit diskalakan
Setiap endpoint baru menambah daftar pemeriksaan. Setiap environment memperbanyak kombinasi yang harus diuji.
Contoh sederhana:
20 endpoint x 3 environment x 5 skenario = 300 pemeriksaan
Jika semua dilakukan manual sebelum rilis, sebagian besar tim akan mulai melewatkan pemeriksaan tertentu. Otomatisasi membuat pemeriksaan tersebut dapat dijalankan berulang tanpa menambah beban manual.
2. Regresi lebih cepat terdeteksi
Perubahan kecil pada satu layanan dapat merusak kontrak layanan lain. Dengan test suite otomatis, Anda bisa menjalankan ulang pemeriksaan penting setiap kali ada perubahan kode.
Target praktisnya:
developer push code
↓
CI menjalankan API test
↓
regresi terdeteksi sebelum merge
3. Pengujian menjadi aset yang dapat digunakan ulang
Pengujian manual selesai setelah dijalankan. Pengujian otomatis dibuat sekali, lalu bisa digunakan berkali-kali.
Ini membuat investasi awal lebih bernilai, terutama untuk skenario yang:
- sering dijalankan
- stabil
- penting untuk bisnis
- rawan regresi
4. Feedback lebih cepat
Saat test suite berjalan di pipeline, developer mengetahui kegagalan dalam hitungan menit. Bug yang ditemukan saat konteks perubahan masih segar jauh lebih mudah diperbaiki daripada bug yang baru ditemukan di produksi.
5. Penguji bisa fokus pada pekerjaan bernilai tinggi
Otomatisasi tidak menggantikan penguji. Otomatisasi mengambil alih pemeriksaan repetitif sehingga manusia bisa fokus pada:
- exploratory testing
- edge case
- usability
- validasi workflow
- evaluasi kualitas produk secara menyeluruh
Apa yang tidak dipecahkan oleh pengujian otomatis
Pengujian otomatis bukan solusi tanpa biaya.
Pertama, test tetap perlu dibuat dan dipelihara. Ketika API berubah, assertion dan skenario juga harus diperbarui. Test suite yang sering gagal karena alasan yang salah akan membuat tim terbiasa mengabaikan build merah.
Kedua, otomatisasi hanya memeriksa hal yang Anda definisikan. Jika Anda hanya memeriksa status 200, test bisa pass meskipun response body berisi data yang salah.
Contoh assertion yang lemah:
status code == 200
Contoh assertion yang lebih berguna:
status code == 200
response body memiliki field user.id
user.email bertipe string
response sesuai schema
response time < 500ms
Ketiga, tidak semua hal layak diotomatiskan. Prioritaskan skenario yang:
- sering dijalankan
- stabil
- bernilai tinggi
- berisiko menimbulkan regresi
Biarkan eksplorasi, eksperimen UX, dan pemeriksaan satu kali tetap manual.
Cara mengatur pengujian API otomatis di Apidog
Apidog memungkinkan Anda membangun pengujian API otomatis secara visual, sehingga Anda tidak harus menulis script pengujian dari awal untuk membuat suite yang bisa dijalankan.
Berikut alur implementasinya.
Langkah 1: Definisikan atau impor API
Mulai dengan memasukkan definisi API ke Apidog.
Anda dapat:
- mengimpor file OpenAPI
- mengimpor koleksi Postman
- mendefinisikan endpoint langsung di Apidog
Pastikan setiap endpoint memiliki informasi dasar berikut:
method: GET / POST / PUT / DELETE
URL endpoint
headers
query params
request body
response schema
Jika Anda memulai dari spesifikasi, kontrak API dan pengujian lebih mudah dijaga tetap sinkron.
Langkah 2: Tambahkan assertion ke setiap request
Request tanpa assertion hanya membuktikan bahwa server merespons. Agar menjadi test yang berguna, tambahkan validasi eksplisit.
Contoh assertion API:
status code == 200
response body memiliki field data
data.id bertipe string
response sesuai schema
response time < 800ms
Di Apidog, buka panel assertion pada endpoint lalu tambahkan pemeriksaan secara visual tanpa coding.
Untuk detail konsepnya, lihat Assertion API.
Langkah 3: Buat skenario pengujian
Setelah assertion tersedia, kelompokkan request terkait ke dalam skenario.
Contoh skenario: siklus hidup pengguna
1. Register user
2. Login user
3. Ambil token dari response login
4. Gunakan token untuk mengambil profil
5. Update profil
6. Validasi data profil berubah
Pola ini penting karena banyak API tidak berdiri sendiri. Response dari satu endpoint sering menjadi input untuk endpoint berikutnya.
Contoh alur data:
POST /login
↓ menghasilkan access_token
GET /profile
↓ menggunakan Authorization: Bearer access_token
PUT /profile
↓ memvalidasi perubahan data
Setiap blok request plus assertion adalah test case. Untuk struktur lebih lengkap, baca cara menulis kasus pengujian API.
Langkah 4: Tambahkan pengujian berbasis data
Jika satu skenario perlu diuji dengan banyak variasi input, gunakan data-driven testing.
Contoh file CSV:
email,password,expected_status
valid@example.com,correct-password,200
invalid@example.com,wrong-password,401
empty@example.com,,400
Dengan pendekatan ini, Anda tidak perlu membuat banyak test case yang hampir sama. Satu skenario dapat dijalankan terhadap banyak baris data.
Format yang umum digunakan:
- CSV
- JSON
Pelajari lebih lanjut di Pengujian API berbasis data.
Langkah 5: Jalankan skenario
Jalankan skenario secara manual terlebih dahulu untuk memastikan semua request, variabel, dan assertion bekerja.
Saat menjalankan skenario, periksa:
- request berhasil dikirim
- variabel antar-step terisi
- assertion mengevaluasi nilai yang benar
- error message mudah dibaca
- hasil expected dan actual terlihat jelas
Untuk mengecek stabilitas, jalankan skenario beberapa kali, misalnya 50 iterasi. Jika hasilnya sering berubah tanpa perubahan kode, kemungkinan ada masalah flakiness pada test atau environment.
Langkah 6: Susun menjadi test suite
Setelah beberapa skenario stabil, gabungkan ke dalam test suite.
Contoh struktur suite:
API Regression Suite
├── Auth scenario
├── User profile scenario
├── Order creation scenario
├── Payment validation scenario
└── Admin workflow scenario
Test suite membantu menjaga cakupan tetap terorganisir saat jumlah endpoint dan skenario bertambah.
Langkah 7: Hubungkan ke CI/CD
Langkah ini mengubah test suite dari “bisa dijalankan” menjadi otomatis.
Jalankan suite pada:
- setiap pull request
- setiap commit ke branch utama
- sebelum deployment
- setelah deployment ke staging
Contoh alur CI/CD:
push code
↓
build aplikasi
↓
deploy ke test environment
↓
jalankan API test suite
↓
jika gagal, hentikan pipeline
Apidog dapat dijalankan di pipeline CI/CD. Lihat panduan mengotomatiskan pengujian API di CI/CD dan menjalankan pengujian API di GitHub Actions.
Anda juga dapat mengunduh Apidog untuk mulai membuat skenario otomatis pertama.
Jenis-jenis utama pengujian otomatis
Pengujian otomatis terdiri dari beberapa lapisan. Setiap lapisan menangkap jenis bug yang berbeda.
Unit test
Unit test memeriksa satu fungsi atau class secara terisolasi.
Contoh:
function add(a, b) {
return a + b;
}
test("adds two numbers", () => {
expect(add(2, 3)).toBe(5);
});
Kelebihan:
- cepat
- murah dijalankan
- cocok untuk validasi logika kecil
Keterbatasan:
- tidak memvalidasi integrasi antar-komponen
- tidak memeriksa kontrak API aktual
Integration test
Integration test memeriksa apakah beberapa komponen bekerja bersama.
Contoh cakupan:
service → database
service A → service B
API → message queue
Kelebihan:
- menangkap masalah wiring
- memvalidasi komunikasi antar-komponen
Keterbatasan:
- lebih lambat dari unit test
- membutuhkan setup environment dan data
API test
API test memanggil endpoint melalui HTTP seperti client sungguhan.
Contoh validasi:
POST /orders
status == 201
body.order_id exists
body.total == expected_total
schema valid
Kelebihan:
- cepat dibanding end-to-end test
- tidak bergantung pada browser
- memvalidasi kontrak API
- cocok untuk regresi bisnis inti
Untuk banyak tim, API test memberi return on effort terbaik karena cakupannya luas tetapi tetap relatif stabil.
End-to-end test
End-to-end test menjalankan workflow lengkap melalui sistem nyata, sering kali termasuk UI.
Contoh:
user login
memilih produk
checkout
membayar
melihat invoice
Kelebihan:
- paling mendekati perilaku pengguna nyata
- bagus untuk alur kritis
Keterbatasan:
- lambat
- lebih mudah flaky
- mahal dipelihara
Gunakan end-to-end test secara selektif untuk workflow yang benar-benar penting.
Strategi cakupan yang praktis
Gunakan struktur berlapis:
banyak unit test
lebih sedikit integration test
API test untuk kontrak dan logika bisnis
sedikit end-to-end test untuk alur kritis
Hindari suite yang terlalu bergantung pada end-to-end test karena biasanya lambat dan mudah gagal karena faktor eksternal.
API test sering menjadi titik awal terbaik karena memberi cakupan luas tanpa biaya flakiness setinggi UI automation.
Praktik terbaik agar otomatisasi tetap berguna
1. Dekatkan test dengan desain API
Jika kontrak API dan test berada di tempat yang sama, perubahan lebih mudah dilacak. Ini mengurangi risiko drift antara dokumentasi, implementasi, dan pengujian.
2. Jangan hanya memeriksa status code
Status 200 tidak cukup.
Tambahkan assertion untuk:
- field wajib
- tipe data
- schema response
- business rule
- response time
- error message
Contoh:
status == 200
data.id exists
data.email matches email format
data.role in ["admin", "user"]
3. Buat laporan kegagalan mudah dibaca
Laporan yang baik harus menunjukkan:
test yang gagal
assertion yang gagal
nilai expected
nilai actual
request dan response terkait
Semakin mudah kegagalan dibaca, semakin cepat developer memperbaikinya.
4. Jalankan test di tempat keputusan dibuat
Jika test hanya berjalan saat seseorang mengingatnya, itu belum benar-benar otomatis.
Masukkan test suite ke pipeline agar hasilnya memengaruhi keputusan merge dan release.
5. Gunakan AI untuk pekerjaan repetitif
AI dapat membantu membuat draft awal test case dari spesifikasi atau menyarankan edge case. Namun, hasilnya tetap perlu ditinjau manusia agar assertion sesuai dengan kebutuhan produk.
Baca pengujian otomatis API yang ditingkatkan AI untuk melihat area yang cocok dibantu AI dan area yang tetap membutuhkan review manual.
Pertanyaan yang sering diajukan
Apakah pengujian otomatis lebih baik dari pengujian manual?
Tidak selalu. Keduanya saling melengkapi.
Gunakan otomatisasi untuk pemeriksaan yang:
- stabil
- berulang
- bernilai tinggi
- sering dijalankan
Gunakan pengujian manual untuk:
- exploratory testing
- evaluasi usability
- validasi pengalaman pengguna
- kasus yang membutuhkan penilaian manusia
Apakah saya perlu bisa coding untuk mengotomatiskan pengujian API?
Tidak selalu. Dengan alat visual seperti Apidog, Anda dapat membuat request, assertion, dan skenario melalui UI. Script hanya diperlukan untuk logika yang tidak bisa diekspresikan oleh builder visual.
Dari mana tim sebaiknya mulai?
Mulai dari API test untuk endpoint yang paling kritis.
Prioritaskan endpoint yang:
- sering digunakan
- berdampak langsung pada bisnis
- sering berubah
- memiliki banyak dependensi
- pernah menyebabkan regresi
Contoh kandidat awal:
login
checkout
payment
create order
user profile
Berapa banyak pemeliharaan yang dibutuhkan pengujian otomatis?
Test perlu diperbarui setiap kali API berubah. Jika schema response, field, status code, atau business rule berubah, assertion juga harus disesuaikan.
Agar pemeliharaan lebih ringan:
- jaga test dekat dengan spesifikasi API
- gunakan naming yang jelas
- hindari assertion pada data volatile
- pisahkan test data dari skenario
- hapus test yang tidak lagi relevan
Apa penyebab test flaky dan bagaimana memperbaikinya?
Flakiness biasanya berasal dari:
- asumsi timing
- data bersama antar-test
- urutan test yang saling bergantung
- assertion pada timestamp atau nilai yang berubah
- environment yang tidak stabil
Cara menguranginya:
isolasi data test
gunakan setup dan cleanup yang jelas
hindari ketergantungan urutan
assert struktur, bukan nilai volatile
stabilkan test environment
Perlakukan test flaky sebagai bug. Jika tim terbiasa mengabaikan kegagalan, test suite akan kehilangan kepercayaan.
Bagaimana mengukur apakah pengujian otomatis berhasil?
Ukur kualitas test suite dari dampaknya, bukan hanya jumlah test.
Metrik yang berguna:
- jumlah bug yang tertangkap sebelum rilis
- jumlah regresi yang lolos ke produksi
- waktu eksekusi suite
- tingkat flakiness
- cakupan endpoint kritis
- kualitas assertion
Test suite yang selalu hijau tetapi tidak pernah menangkap bug mungkin tidak memvalidasi hal yang penting. Assertion yang bermakna lebih bernilai daripada jumlah test yang besar.
Top comments (0)