Menguji aplikasi tanpa server pada AWS - AWS Panduan Preskriptif
IkhtisarPrasyaratDefinisiTujuan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menguji aplikasi tanpa server pada AWS

Amazon Web Services (Kontributorkontributor)

Maret 2026 (sejarah dokumen)

Panduan ini membahas metodologi untuk menguji aplikasi tanpa server, menjelaskan tantangan yang mungkin Anda temui selama pengujian, dan memperkenalkan praktik terbaik. Teknik pengujian ini dimaksudkan untuk membantu Anda mengulangi lebih cepat dan melepaskan kode Anda dengan lebih percaya diri.

Panduan ini untuk pengembang yang ingin membuat strategi pengujian untuk aplikasi tanpa server mereka. Anda dapat menggunakan panduan ini sebagai titik awal untuk mempelajari strategi pengujian, dan kemudian mengunjungi repositori Sampel Uji Tanpa Server untuk melihat contoh pengujian yang mengikuti pola dan praktik terbaik yang dijelaskan dalam panduan ini. Panduan ini menjelaskan metodologi pengujian tanpa server, menjelaskan tantangan yang dihadapi pelanggan saat menguji aplikasi tanpa server, dan memperkenalkan praktik terbaik untuk menguji aplikasi tanpa server. Teknik-teknik ini dimaksudkan untuk membantu pengembang mengulangi lebih cepat dan melepaskan lebih percaya diri.

Ikhtisar

Pengujian otomatis adalah investasi penting yang membantu memastikan kualitas aplikasi dan kecepatan pengembangan. Pengujian juga mempercepat umpan balik pengembang. Sebagai pengembang, Anda ingin dapat melakukan iterasi dengan cepat pada aplikasi Anda dan mendapatkan umpan balik tentang kualitas kode Anda. Banyak pengembang terbiasa menulis aplikasi yang mereka terapkan ke lingkungan di desktop mereka, baik langsung ke sistem operasi mereka atau dalam lingkungan berbasis kontainer. Ketika Anda bekerja di desktop atau lingkungan berbasis container, Anda biasanya menulis tes terhadap kode yang di-host sepenuhnya di desktop Anda. Namun, dalam aplikasi tanpa server, komponen arsitektur mungkin tidak dapat diterapkan ke lingkungan desktop tetapi mungkin hanya ada di cloud. Arsitektur berbasis cloud mungkin mencakup lapisan persistensi, sistem pesan, konstruksi keamanan, dan komponen lainnya APIs. Ketika Anda menulis kode aplikasi yang bergantung pada komponen-komponen ini, mungkin sulit untuk menentukan cara terbaik untuk merancang dan menjalankan tes.

Panduan ini membantu Anda menyelaraskan dengan strategi pengujian yang mengurangi gesekan dan kebingungan, serta meningkatkan kualitas kode.

Prasyarat

Panduan ini mengasumsikan bahwa Anda terbiasa dengan dasar-dasar pengujian otomatis, termasuk bagaimana pengujian perangkat lunak otomatis digunakan untuk memastikan kualitas perangkat lunak. Panduan ini memberikan pengenalan tingkat tinggi untuk strategi pengujian aplikasi tanpa server, dan tidak memerlukan pengalaman menulis tes langsung.

Definisi

Panduan ini menggunakan istilah-istilah berikut:

  • Unit test adalah tes yang dijalankan terhadap kode untuk satu komponen arsitektur secara terpisah.

  • Tes integrasi dijalankan terhadap dua atau lebih komponen arsitektur, biasanya di lingkungan cloud.

  • End-to-end tes memverifikasi perilaku di seluruh aplikasi atau alur kerja.

  • Emulator adalah aplikasi (sering disediakan oleh pihak ketiga) yang dirancang untuk meniru layanan cloud tanpa menyediakan atau menggunakan sumber daya cloud apa pun.

  • Mocks (juga disebut palsu) adalah implementasi dalam aplikasi pengujian yang menggantikan ketergantungan dengan simulasi ketergantungan itu.

Tujuan

Praktik terbaik dalam panduan ini dimaksudkan untuk membantu Anda mencapai dua tujuan utama:

  • Meningkatkan kualitas aplikasi tanpa server

    • Pengujian pada batas arsitektur

    • Pengujian pada batas kode

  • Kurangi waktu untuk mengimplementasikan atau mengubah fitur

Meningkatkan kualitas perangkat lunak

Kualitas aplikasi sangat bergantung pada kemampuan pengembang untuk menguji berbagai skenario untuk memverifikasi fungsionalitas. Jika Anda tidak menerapkan pengujian otomatis, atau, lebih umum, jika pengujian Anda tidak mencakup skenario yang diperlukan secara memadai, kualitas aplikasi Anda tidak dapat ditentukan atau dijamin.

Dalam arsitektur berbasis server, tim dapat dengan mudah menentukan ruang lingkup untuk pengujian: Setiap kode yang berjalan pada server aplikasi harus diuji. Komponen lain yang memanggil ke server, atau dependensi yang dipanggil server, sering dianggap eksternal dan di luar ruang lingkup untuk pengujian oleh tim yang bertanggung jawab atas aplikasi di server.

Aplikasi tanpa server sering terdiri dari unit kerja yang lebih kecil, seperti AWS Lambda fungsi, yang berjalan di lingkungan mereka sendiri. Tim kemungkinan akan bertanggung jawab atas kelipatan unit yang lebih kecil ini dalam satu aplikasi. Beberapa fungsi aplikasi dapat didelegasikan sepenuhnya ke layanan terkelola seperti Amazon Simple Storage Service (Amazon S3) atau Amazon Simple Queue Service (Amazon SQS) tanpa menggunakan kode yang dikembangkan secara internal. Model berbasis server tradisional untuk pengujian perangkat lunak mungkin mengecualikan layanan terkelola dengan mempertimbangkannya di luar aplikasi. Hal ini dapat menyebabkan cakupan yang tidak memadai, di mana skenario kritis mungkin terbatas pada pengujian eksplorasi manual atau beberapa kasus uji integrasi di mana hasilnya bervariasi menurut lingkungan. Oleh karena itu, mengadopsi strategi pengujian yang mencakup perilaku layanan terkelola dan konfigurasi cloud dapat meningkatkan kualitas perangkat lunak.

Pengujian pada batas arsitektur

Saat aplikasi tanpa server tumbuh, mereka secara alami menyebar di beberapa komponen arsitektur. Meskipun ini menggunakan kemampuan AWS terdistribusi, itu dapat membuat end-to-end perilaku sulit dipahami.

Mengidentifikasi batas-batas alam

Saat merancang arsitektur Anda mengikuti praktik terbaik tanpa server (satu fungsi = satu pekerjaan, decoupling), Anda akan melihat batasan alami di sekitar subsistem. Batas-batas ini mewakili titik pemisahan logis dalam aplikasi Anda.

Batas sebagai kontrak pengujian

Batas-batas arsitektur ini adalah kandidat yang sangat baik untuk menguji tepi. Perlakukan setiap batas sebagai kontrak dan validasi bahwa ia berperilaku sesuai dengan spesifikasi yang ditentukan. Pikirkan batas-batas ini sebagai jahitan dalam aplikasi Anda di mana Anda dapat memasukkan validasi pengujian.

Manfaat utama

Berikut ini adalah manfaat utama pengujian pada batas arsitektur:

  • Lingkup pengujian terfokus - Uji subsistem secara independen tanpa perlu memahami seluruh aplikasi.

  • Validasi kontrak — Pastikan setiap batas mempertahankan perilaku yang diharapkan saat sistem berkembang

  • Instrumentasi tujuan ganda - Batasan yang sama ini membuat kait observabilitas yang sangat baik dalam produksi

  • Test harness - Memungkinkan Anda menguji sistem tanpa server asinkron. Ini membantu Anda menguji arsitektur berbasis peristiwa dengan menangkap dan memvalidasi peristiwa saat mereka mengalir melalui subsistem Anda.

Pengujian pada batas kode

Tentukan batas kode yang jelas dengan memisahkan kode infrastruktur, seperti kode Lambda, dari logika bisnis inti Anda. Pemisahan ini menciptakan cakupan pengujian berbeda yang menyederhanakan strategi pengujian Anda.

Pola batas

Tetapkan dua batas kode yang jelas dalam fungsi Lambda Anda:

  • Batas luar (Lambda handler) - Lapisan adaptor ramping yang menangani masalah khusus AWS Lambda

  • Batas dalam (logika bisnis) - Metode logika bisnis murni yang independen dari runtime Lambda

Handler sebagai adaptor (lingkup luar)

Handler fungsi Lambda Anda harus berupa lapisan tipis yang:

  • Mengekstrak data dari yang masuk event dan objek context

  • Memvalidasi data yang diekstraksi

  • Hanya meneruskan detail yang relevan ke metode logika bisnis

  • Mengembalikan hasil dalam format yang diharapkan untuk Lambda

Logika bisnis (lingkup dalam)

Logika bisnis inti Anda harus:

  • Beroperasi secara independen dari detail khusus untuk Lambda

  • Terima input sederhana dan tervalidasi

  • Kembalikan output yang dapat diprediksi

  • Memerlukan dependensi minimal untuk inisialisasi

Menguji manfaat berdasarkan ruang lingkup

  • Tes batas dalam — Pengujian unit komprehensif seputar logika bisnis tanpa kompleksitas Lambda atau pengaturan lingkungan

  • Tes batas luar - Tes integrasi terfokus yang memvalidasi penanganan peristiwa dan ekstraksi data lapisan adaptor

  • Overhead pengujian minimal - Tidak ada lingkungan yang kompleks atau dependensi ekstensif yang diperlukan untuk sebagian besar pengujian Anda

Pendekatan berbasis batas ini memungkinkan Anda untuk menguji sebagian besar kode Anda sebagai fungsi murni sambil menjaga pengujian Lambda tetap minimal dan ditargetkan.

Kurangi waktu untuk mengimplementasikan atau mengubah fitur

Anda dapat meminimalkan efek bug perangkat lunak dan masalah konfigurasi pada biaya dan jadwal dengan menangkap masalah ini selama siklus pengembangan berulang. Ketika pengembang gagal mendeteksi masalah ini, lebih banyak orang harus menginvestasikan upaya tambahan untuk mengidentifikasi masalah.

Arsitektur tanpa server mungkin mencakup layanan terkelola yang menyediakan fungsionalitas aplikasi penting melalui panggilan API. Untuk alasan ini, siklus pengembangan Anda harus mencakup pengujian yang memvalidasi jalur bahagia (di mana interaksi dengan layanan ini berperilaku seperti yang diharapkan) dan jalur sedih (di mana panggilan gagal, mengembalikan respons yang tidak terduga, atau berperilaku berbeda di seluruh lingkungan). Tanpa pengujian ini, Anda mungkin mengalami masalah yang berasal dari perbedaan antara lingkungan lokal Anda dan lingkungan yang diterapkan. Ketika itu terjadi, Anda harus meluangkan waktu tambahan untuk mencoba mereproduksi dan memverifikasi perbaikan, karena setiap iterasi sekarang memerlukan validasi perubahan terhadap lingkungan yang berbeda dari pengaturan pilihan Anda.

Strategi pengujian tanpa server yang tepat meningkatkan waktu iterasi Anda dengan memberikan hasil yang akurat untuk pengujian yang menyertakan panggilan ke layanan lain.