Serangkaian pengujian yang berhasil hanya membantu jika tetap berhasil. Alur checkout Anda berfungsi hari ini, tetapi sebuah dependensi mengeluarkan perubahan yang merusak pada pukul 2 pagi, sertifikat kedaluwarsa di akhir pekan, atau pergeseran konfigurasi menjatuhkan endpoint pembayaran pada hari Minggu. Anda mengetahuinya dari pelanggan yang marah alih-alih dari hasil pengujian. Solusinya membosankan dan dapat diandalkan: jalankan pengujian API Anda sesuai jadwal, tanpa campur tangan manusia mengklik tombol, dan dapatkan pemberitahuan saat sesuatu rusak.
Apidog memiliki fitur Tugas Terjadwal bawaan untuk tujuan ini. Anda mengarahkannya ke skenario pengujian yang sudah Anda buat, mengatur ritme, memilih mesin untuk dijalankan, dan menghubungkan peringatan. Panduan ini menjelaskan semuanya secara jujur, termasuk batasan saat ini. Jika Anda baru dalam menjalankan pemeriksaan otomatis terhadap endpoint langsung, pengantar kami tentang pemantauan API menetapkan konteks yang lebih luas, dan dokumentasi Tugas Terjadwal Apidog adalah sumber informasi utama untuk UI.
Satu catatan singkat sebelum Anda memulai. Fitur Tugas Terjadwal saat ini berlabel Beta, dan jumlah pasti jadwal berjalan yang didapat akun Anda bergantung pada paket Anda. Ingatlah keduanya saat Anda membaca.
Apa yang dilakukan tugas terjadwal (dan bagaimana perbedaannya dengan scraper terjadwal)
Tugas terjadwal di Apidog menjalankan satu atau lebih Skenario Pengujian yang tersimpan dalam siklus berulang. Bayangkan regresi malam hari di seluruh API inti Anda, pemeriksaan asap setiap beberapa jam terhadap staging, atau sapuan kesehatan akhir pekan. Tugas tersebut mengingat skenario mana yang akan dijalankan, lingkungan mana yang akan dituju, seberapa sering akan diaktifkan, mesin mana yang akan menjalankan pekerjaan, dan siapa yang akan diberitahu jika gagal.
Jika Anda pernah melihat frasa “tugas terjadwal” yang terkait dengan web scraping atau pengumpulan data, itu adalah hal yang berbeda. Fitur ini bukan tentang menjelajahi halaman sesuai waktu. Fitur ini berada di dalam modul Pengujian dan menggerakkan skenario pengujian API Anda: penegasan, permintaan berantai, variabel yang diekstraksi, dan lainnya. Hasilnya adalah laporan lulus atau gagal pada kontrak API Anda, bukan kumpulan data yang discrape.
Perbedaan itu penting karena mengubah apa yang Anda konfigurasikan. Anda tidak menulis selector atau aturan perayapan. Anda memilih skenario pengujian yang sudah ada dan memberi tahu Apidog kapan dan di mana harus menjalankannya.
Sebelum Anda memulai: konfigurasikan Runner yang di-host sendiri
Berikut adalah prasyarat yang sering membuat orang bingung. Untuk menjalankan tugas terjadwal, Anda perlu mengonfigurasi Runner yang di-host sendiri terlebih dahulu. Dokumentasi secara eksplisit menyatakan hal ini.
Runner adalah mesin yang menjalankan rangkaian pengujian. Saat tugas terjadwal diaktifkan, Apidog tidak menjalankan permintaan di klien desktop Anda; ia menyerahkan pekerjaan tersebut ke Runner yang Anda pilih, dan setiap permintaan dalam rangkaian dikirim dari mesin tersebut. Kotak CI, server kecil yang selalu aktif, atau VM khusus semuanya berfungsi dengan baik. Apapun yang Anda pilih akan tetap aktif dan dapat dijangkau sesuai jadwal yang Anda inginkan.
Bidang target runner menawarkan dua pilihan: Apidog Cloud, yang ditandai “segera hadir,” atau Runner yang di-host sendiri. Karena Apidog Cloud belum tersedia, Runner yang di-host sendiri adalah satu-satunya pilihan yang berfungsi saat ini. Jangan merencanakan eksekusi cloud sampai dirilis.
Karena permintaan berasal dari mesin Runner, lingkungan jaringannya membentuk hasil Anda. Runner di belakang VPN perusahaan, wilayah yang berbeda, atau subnet yang dilindungi firewall mungkin melihat respons yang berbeda dari laptop Anda. Itu biasanya yang Anda inginkan untuk pemantauan yang realistis, tetapi penting untuk diketahui saat jadwal berjalan tidak sesuai dengan yang lokal.
Langkah demi langkah: membuat tugas terjadwal
Setelah Runner terdaftar, sisanya terjadi di klien. Contoh yang berjalan di bawah ini adalah rangkaian regresi malam hari untuk API e-commerce yang mencakup pendaftaran pengguna, daftar produk, keranjang, dan checkout yang didukung oleh Stripe.
1. Buka Tugas Terjadwal di modul Pengujian
Buka modul Pengujian di klien Apidog. Di pohon folder Pengujian, klik Tugas Terjadwal untuk melihat dan mengelola setiap tugas terjadwal dalam proyek. Semua tugas di seluruh proyek ditampilkan di sini di bawah bagian Tugas Terjadwal, jadi ini adalah satu-satunya tempat Anda untuk melihat apa yang sedang berjalan dan kapan.
2. Buat tugas
Klik + Baru untuk membuat tugas terjadwal baru. Anda juga dapat membuat folder di sini untuk mengelompokkan tugas terkait, yang berguna setelah Anda memiliki rangkaian terpisah untuk staging dan produksi atau untuk layanan yang berbeda.
Berikan tugas Nama Tugas dan Deskripsi yang jelas. Ini ada untuk membedakan tugas dan menjelaskan tujuannya, sehingga Anda di masa depan tahu apa sebenarnya yang dicakup oleh “Regresi malam, prod” tanpa membukanya. Setiap tugas juga memiliki tombol aktifkan/nonaktifkan, dan tugas di pohon dapat diaktifkan atau dinonaktifkan kapan saja.
3. Pilih skenario pengujian yang akan dijalankan
Di bawah Skenario Pengujian, pilih satu atau lebih skenario untuk disertakan. Untuk contoh e-commerce, Anda mungkin memilih “Daftar dan masuk,” “Jelajahi dan tambahkan ke keranjang,” dan “Checkout dengan kartu uji Stripe” sehingga satu tugas mencakup seluruh jalur kritis.
Setiap skenario dapat memiliki pengaturan eksekusinya sendiri: Lingkungan, data pengujian, iterasi, penundaan, dan apakah akan menyimpan permintaan dan respons. Jika Anda lebih suka tidak menyetel masing-masing, aktifkan Gunakan konfigurasi eksekusi yang sama untuk menerapkan satu konfigurasi runtime ke setiap skenario yang dipilih sekaligus. Itu menjaga rangkaian besar tetap konsisten dan cepat disiapkan.
Pemilihan lingkungan adalah pengaturan yang paling diperhatikan orang. Arahkan pemantau produksi malam hari ke lingkungan produksi Anda, dan arahkan pengujian asap pra-rilis ke staging. Karena setiap skenario dapat menentukan lingkungannya sendiri, satu tugas bahkan dapat mencampur target jika Anda membutuhkannya, meskipun menjaga satu tugas ke satu lingkungan lebih bersih untuk dipikirkan.
4. Atur siklus berjalan
Atur bidang jadwal berjalan ke ritme yang Anda inginkan. Tergantung pada layar yang Anda gunakan, bidang ini terbaca Siklus Berjalan atau Mode Berjalan; ini adalah pengaturan yang sama, dan penulisan label bervariasi di seluruh UI. Dokumen memberikan contoh konkret yang dapat Anda tiru: setiap Minggu pukul 11 malam, setiap 6 jam, atau setiap 8 jam.
Untuk regresi malam hari, menjalankan pengujian setiap malam hari menjaga kebisingan tetap rendah dan menangkap masalah sebelum hari kerja. Untuk pengujian asap staging, setiap 6 jam memberi Anda umpan balik yang lebih cepat tanpa membebani lingkungan.
5. Pilih di mana ia berjalan
Atur bidang runner ke Runner yang di-host sendiri. Seperti bidang jadwal, yang satu ini diberi label secara tidak konsisten di berbagai layar sebagai Berjalan di, Jalankan Pada, atau Berjalan Pada; semuanya memiliki arti yang sama, yaitu mesin yang menjalankan rangkaian. Apidog Cloud juga muncul di sini tetapi akan segera hadir, jadi pilih Runner yang di-host sendiri. Jika Anda telah mendaftar beberapa Runner serbaguna, pilih yang spesifik yang Anda inginkan, misalnya Runner yang berada di dalam VPC yang sama dengan API Anda.
Ingat bahwa semua permintaan yang dimulai dalam rangkaian pengujian dikirim dari mesin yang ditentukan di sini, jadi pilih Runner yang jaringannya melihat API Anda seperti lalu lintas nyata.
6. Aktifkan notifikasi
Aktifkan Notifikasi agar tugas memberi tahu Anda saat sesuatu rusak. Dokumen merekomendasikan ini untuk tugas terjadwal, dan itulah inti dari eksekusi tanpa pengawasan: keheningan harus berarti keberhasilan, dan kegagalan harus mencapai Anda dengan cepat.
Apidog mendukung saluran-saluran ini berdasarkan nama: Slack, Teams, Webhook, Jenkins, dan Email. Untuk Email, alamat anggota proyek akan melengkapi secara otomatis, dan Anda dapat mengetik alamat non-anggota secara manual untuk rotasi on-call atau kotak masuk bersama. Slack akan langsung mengirimkan kegagalan ke saluran tim Anda; opsi Webhook memungkinkan Anda menyebarkan ke apa pun yang Anda jalankan, dari PagerDuty hingga endpoint kustom.
Anda juga memilih kapan peringatan dipicu: setelah setiap eksekusi, atau hanya pada kegagalan. Untuk rangkaian malam yang sehat, hanya kegagalan yang membuat saluran tetap tenang sampai penting. Selama peluncuran yang tidak stabil, setiap eksekusi memberi Anda detak jantung yang mengkonfirmasi bahwa pekerjaan bahkan sedang dieksekusi.
7. Simpan dan aktifkan
Alihkan tombol tugas untuk mengaktifkannya, dan ia akan mulai berjalan sesuai ritme yang Anda atur. Anda dapat menonaktifkannya nanti tanpa menghapusnya, yang berguna selama pemadaman terencana atau jendela migrasi yang bising.
8. Baca riwayat eksekusi
Setelah setiap eksekusi, hasil akan diunggah secara otomatis dari Runner kembali ke server. Buka bagian Tugas Terjadwal - Riwayat Eksekusi di klien untuk melihatnya. Ini adalah jejak audit Anda: eksekusi mana yang berhasil, mana yang gagal, penegasan mana yang rusak, dan kapan. Ketika peringatan muncul di Slack, Riwayat Eksekusi adalah tempat Anda pergi untuk melihat detail di baliknya.
Pengaturan dan variasi lanjutan
Setelah tugas dasar berjalan, beberapa opsi membuatnya lebih kokoh.
Cakupan variabel. Ketika skenario Anda meneruskan data antar eksekusi, Apidog memberi Anda tiga tingkat berbagi, dari terkecil hingga terbesar: Bagikan hanya dalam skenario pengujian saat ini, yang menyimpan variabel dalam file khusus untuk skenario tersebut; Bagikan di seluruh skenario pengujian dalam tugas terjadwal saat ini, yang memungkinkan skenario dalam tugas yang sama membaca nilai satu sama lain; dan Bagikan di seluruh tugas terjadwal dalam folder tugas terjadwal saat ini, cakupan terluas. Pilih cakupan terkecil yang masih memungkinkan aliran data Anda, sehingga token otentikasi dari satu skenario tidak bocor ke skenario yang tidak terkait.
Persistensi variabel. Nilai hanya akan terbawa dari satu eksekusi ke eksekusi berikutnya jika opsi Pertahankan nilai variabel diaktifkan pada halaman desain skenario pengujian. Jika eksekusi malam Anda memerlukan ID pesanan yang diambil kemarin atau token yang diperbarui, aktifkan ini. Tanpa itu, setiap eksekusi dimulai dari awal dan setiap asumsi lintas eksekusi akan rusak secara diam-diam.
Mengelompokkan dengan folder. Saat rangkaian Anda bertambah besar, buat folder di bawah Tugas Terjadwal untuk memisahkan, misalnya, pemantau produksi dari pemeriksaan pra-rilis. Cakupan variabel tingkat folder kemudian memungkinkan sekelompok tugas terkait berbagi pengaturan dengan rapi.
Batasan paket. Jumlah eksekusi terjadwal yang Anda dapatkan bergantung pada langganan Anda. Dokumen merujuk ke halaman harga Apidog untuk angka pastinya, jadi periksa paket Anda sebelum Anda menetapkan ritme setiap jam yang agresif. Jika Anda memerlukan cakupan pengelompokan yang lebih dalam dan pola penjadwalan yang lebih berat, panduan kami tentang tugas terjadwal lanjutan menjelaskan lebih jauh, dan panduan terkait tentang logika kondisional dalam skenario pengujian API membantu Anda membangun skenario yang layak dijadwalkan sejak awal. Untuk tim yang menyiapkan pemeriksaan tanpa pengawasan pertama mereka, artikel eksekusi pengujian API malam hari di CI cocok dengan yang ini.
Otomatiskan alur kerja dengan Apidog CLI
UI Tugas Terjadwal adalah salah satu jalur. Apidog CLI adalah yang ketiga, dan ini adalah solusi nyata: Anda menjalankan skenario yang tersimpan tanpa antarmuka grafis, lalu membiarkan cron atau penyedia CI Anda menangani ritmenya. Agar jelas, CLI tidak memiliki perintah jadwal bawaan; penjadwalan berada di luar Apidog dalam alat yang sudah Anda percayai untuk cron.
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit
Di sini -t adalah ID skenario pengujian, -e adalah ID lingkungan, dan -r adalah pelapor (cli, html, atau junit, dipisahkan koma untuk beberapa). Untuk menjalankannya setiap malam dengan cron, tambahkan satu baris:
0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1
Atau picu dari tugas GitHub Actions terjadwal. Bagaimanapun, laporan JUnit akan masuk ke dasbor pipeline Anda yang sudah ada. Lihat Apidog CLI di pipeline CI/CD Anda untuk pengaturan lengkapnya, termasuk cron dan pemicu jadwal GitHub Actions.
FAQ
Bisakah saya menjalankan pengujian terjadwal di Apidog Cloud hari ini? Belum. Target runner mencantumkan Apidog Cloud sebagai "segera hadir," jadi Runner yang di-host sendiri adalah satu-satunya mesin eksekusi yang berfungsi saat ini. Daftarkan Runner terlebih dahulu, lalu pilih di tugas.
Seberapa sering tugas terjadwal dapat berjalan? Sesering yang diizinkan oleh paket Anda. Ritmenya sendiri fleksibel, dengan contoh yang didokumentasikan seperti setiap 6 jam atau setiap Minggu pukul 11 malam, tetapi jumlah eksekusi terjadwal dibatasi oleh langganan Anda. Periksa halaman harga Apidog untuk batas pasti tingkatan Anda daripada mengasumsikan angka.
Bagaimana cara saya hanya mendapatkan notifikasi saat pengujian gagal? Di pengaturan Notifikasi tugas, pilih opsi hanya kegagalan alih-alih setiap eksekusi, lalu tambahkan saluran: Slack, Teams, Webhook, Jenkins, atau Email. Ini menjaga saluran Anda tetap tenang di malam yang sukses dan berbunyi keras saat ada masalah. Pasangkan dengan pemeriksaan kesehatan API yang ringan untuk sinyal keaktifan yang cepat di samping rangkaian regresi yang lebih dalam.
Mengapa hasil terjadwal saya berbeda dari hasil pengujian lokal saya? Karena permintaan berasal dari mesin Runner, bukan laptop Anda. Jaringan, wilayah, dan VPN atau firewall apa pun membentuk respons. Itu sudah diduga, dan itu sering kali merupakan pandangan yang lebih realistis tentang apa yang dihadapi pengguna Anda.
Variabel saya diatur ulang setiap kali dijalankan. Apa yang saya lewatkan? Opsi Pertahankan nilai variabel pada halaman desain skenario pengujian. Aktifkan agar nilai yang ditangkap tetap ada dari satu eksekusi ke eksekusi berikutnya. Tanpa itu, setiap eksekusi terjadwal dimulai dari awal dan setiap dependensi lintas eksekusi akan gagal.
Ringkasan
Pengujian terjadwal mengubah "kami pikir API berfungsi" menjadi "kami tahu, dan kami pasti sudah tahu sekarang jika tidak." Bangun skenario Anda sekali, daftarkan Runner yang di-host sendiri, atur Siklus Berjalan, hubungkan Slack atau email saat gagal, dan biarkan berjalan saat Anda tidur. Ketika Anda menginginkan pemeriksaan yang sama di dalam pipeline, CLI ditambah cron memberi Anda jalur ketiga tanpa alat tambahan. Unduh Apidog untuk menyiapkan rangkaian regresi terjadwal pertama Anda. Gratis untuk memulai, tidak diperlukan kartu kredit.