Generator Data Dummy
Dibuat di peramban Anda dan tidak pernah dikirim ke mana pun. Nama bersifat fiktif, nomor telepon memakai rentang 555-01xx yang dicadangkan, dan alamat IP berasal dari blok dokumentasi RFC 5737 - tidak ada yang menjadi milik orang atau host sungguhan.
Apa pun yang Anda masukkan di sini tidak disimpan, dicatat, atau dibagikan.
Tentukan kolom yang Anda perlukan dan buat hingga 1.000 baris data dummy realistis dalam bentuk JSON, CSV, atau pernyataan INSERT SQL. Semuanya dibuat di peramban Anda, jadi tidak ada yang diunggah dan tidak ada data pribadi asli yang dipakai.
Cara memakai
- Beri nama tiap kolom dan pilih jenis nilai yang harus diisinya.
- Pilih berapa baris yang Anda perlukan dan format JSON, CSV, atau SQL.
- Tekan Buat, lalu salin hasilnya.
Mengapa rentang yang dicadangkan itu penting
Setiap nilai yang dihasilkan diambil dari rentang yang secara resmi disisihkan untuk keperluan fiktif. Ini bukan soal teliti berlebihan - inilah perbedaan antara rangkaian tes yang aman dijalankan dan yang tidak.
Nomor telepon memakai +1-555-01xx, blok seratus nomor yang dicadangkan North American Numbering Plan untuk penggunaan fiktif; nomor 555 lainnya sudah dilepas untuk penggunaan nyata bertahun-tahun lalu, jadi kebiasaan lama memakai sembarang nomor 555 tidak lagi aman. Alamat email dan URL memakai example.com, example.org, dan example.net, yang dicadangkan oleh RFC 2606 dan dijamin tidak akan pernah didaftarkan siapa pun. Alamat IP diambil dari blok dokumentasi RFC 5737 yang tidak dirutekan.
Kegagalan yang dicegah sudah banyak terdokumentasi dan terus terjadi: tes yang dijalankan dengan fixture berisi alamat yang tampak asli mengirim email sungguhan ke orang sungguhan, load test menelepon nomor telepon asli, atau database staging yang diisi data seed terhubung ke relay SMTP produksi. Fixture yang tidak bisa menjangkau siapa pun menyelesaikan masalah itu secara struktural, bukan lewat prosedur.
Fixture yang benar-benar menemukan bug
Data yang semuanya wajar memang nyaman, tetapi kurang berguna. Setiap nama enam sampai sepuluh huruf, setiap string ASCII, setiap kolom opsional terisi: rangkaian tes yang dibangun dari data seperti itu akan lolos tanpa memberi tahu apa pun tentang yang terjadi di produksi.
Kasus yang layak ditambahkan secara manual setelah punya data dasar: string kosong dan null di setiap kolom yang boleh null, karena keduanya melewati jalur berbeda. Nama dengan apostrof, tanda hubung, dan aksara non-Latin, tempat bug encoding dan escaping yang naif muncul. Nilai yang panjangnya persis sama dengan batas kolom dan satu yang lebih satu karakter. Tanggal di batas - akhir bulan, akhir tahun, 29 Februari, hari pergantian waktu musim panas. Nilai duplikat di kolom yang Anda anggap unik. Satu record yang sangat besar di antara record-record kecil.
Data hasil generator cepat memberi volume dan bentuk, dan itulah yang Anda perlukan untuk paginasi, pengurutan, perilaku indeks, dan rendering. Baris-baris yang merepotkan adalah yang Anda perlukan untuk menguji kebenaran, dan biasanya lebih baik ditulis dengan sengaja daripada berharap generator menghasilkannya.
Tiga format output
JSON adalah pilihan saat tujuannya adalah kode: fixture API, mock server, skrip seed, atau file yang dibaca tes saat mulai. Record dihasilkan sebagai array objek dengan nama field Anda sebagai kunci.
CSV cocok untuk jalur impor massal - spreadsheet, COPY di database, formulir unggah di panel admin - dan tepat dipilih saat Anda ingin melihat data sebagai tabel sebelum memuatnya. Peringatan umum CSV berlaku di sisi penerima: program yang menebak tipe data akan mengambil keputusannya sendiri atas apa pun yang terlihat seperti angka.
SQL menghasilkan pernyataan INSERT biasa untuk nama tabel yang Anda berikan, satu per baris, yang bisa dijalankan di klien apa pun tanpa driver atau skrip. Nilai string di-escape dengan menggandakan tanda kutip, angka ditulis apa adanya, boolean sebagai TRUE dan FALSE, dan identifier yang bukan kata sederhana diberi tanda kutip ganda. Untuk seed yang besar, sebaiknya bungkus output dalam transaksi, karena seribu pernyataan terpisah di luar transaksi berjalan lambat di sebagian besar engine.
Jangan menganonimkan data produksi sebagai gantinya
Jalan pintas yang menggoda saat butuh data tes realistis adalah menyalin database produksi lalu membersihkan kolom data pribadi. Ada baiknya memahami mengapa cara ini terus bermasalah.
Menghapus nama dan alamat email tidak membuat dataset menjadi anonim. Kombinasi atribut biasa - kode pos, tanggal lahir, jenis kelamin; atau beberapa timestamp dan lokasi - sering kali hanya cocok dengan satu orang, dan riset tentang identifikasi ulang dataset yang katanya anonim sudah sangat banyak dan hasilnya konsisten. Sementara itu, salinan yang sudah dibersihkan tetaplah dataset produksi dengan detail penuh yang berada di lingkungan dengan kontrol akses lebih lemah, akses developer lebih luas, dan backup yang tidak dilacak siapa pun.
Menghasilkan data dari skema menghindari seluruh kategori masalah itu. Datanya berbentuk benar tetapi tidak berasal dari siapa pun, sehingga kebocoran dari staging tidak membocorkan apa-apa. Jika Anda benar-benar membutuhkan distribusi yang mirip produksi, cara yang bisa dipertanggungjawabkan adalah memodelkan statistiknya lalu menghasilkan data dari model tersebut, bukan mengubah record aslinya.
Merancang sebuah dataset, bukan sekadar mengisi kolom
Data uji yang realistis bukanlah data acak; ia adalah data yang bentuknya menyerupai produksi. Tabel sungguhan itu miring sebarannya: sebagian besar pelanggan punya satu pesanan dan segelintir punya ribuan, sebagian besar dokumen pendek dan satu sangat besar, sebagian besar sesi berlangsung semenit dan beberapa berlangsung seharian. Fixture yang setiap pelanggannya punya tepat tiga pesanan tidak akan pernah memunculkan kueri yang ambruk pada pelanggan dengan empat ribu pesanan.
Volume penting karena alasan yang sama. Paginasi, pengurutan, dan perilaku indeks tidak kelihatan pada lima puluh baris dan langsung terlihat pada lima puluh ribu, dan halaman yang tampil seketika dengan daftar pendek bisa butuh beberapa detik dengan daftar yang realistis. Membuat data satu orde lebih banyak daripada perkiraan Anda adalah uji beban termurah yang tersedia.
Integritas referensial adalah bagian ketiga. Pesanan butuh pelanggan yang benar-benar ada, komentar butuh posting, dan record anak butuh induk dengan tanggal yang masuk akal - pesanan yang dibuat sebelum pelanggannya mendaftar adalah baris yang akan membingungkan setiap laporan yang kelak dibangun di atasnya.
Seed, determinisme, dan keterulangan
Tes yang membuat data acak baru setiap kali dijalankan akan gagal secara sporadis, dan kegagalan sporadis lebih buruk daripada kegagalan yang konsisten karena tidak ada yang bisa mereproduksinya. Disiplin yang lazim adalah seed tetap: urutan yang sama pada setiap jalannya, sehingga kegagalan bisa diulang dan bisect jadi bermakna.
Itu bertabrakan dengan keinginan akan data yang beragam, dan kompromi yang dipilih kebanyakan tim adalah generator ber-seed yang seed-nya dicetak di keluaran tes. Jalannya bisa direproduksi saat Anda membutuhkannya sekaligus beragam dari waktu ke waktu, dan ketika kombinasi langka merusak sesuatu, seed di log merekonstruksinya persis seperti semula.
Skrip seed juga sebaiknya idempoten. Menjalankan seed dua kali seharusnya meninggalkan basis data dalam keadaan yang sama, bukan menggandakan isi setiap tabel, yang dalam praktiknya berarti melakukan truncate lebih dulu atau upsert berdasarkan kunci alami. Pengembang yang harus menghapus basis datanya untuk bisa menyemai ulang akan menghindari menyemai ulang, dan data lokal yang basi adalah kategori bug tersendiri.
Fixture, factory, dan snapshot
Ada tiga pola yang mendominasi, dan ketiganya memecahkan masalah yang berbeda. Fixture adalah berkas statis yang dimuat sebelum tes: mudah ditebak, mudah dibaca, dan merepotkan untuk dirawat karena satu perubahan skema berarti menyunting semua berkas. Factory membangun objek lewat kode dengan nilai default yang masuk akal dan penimpaan per tes, sehingga sebuah tes hanya menyebutkan field yang benar-benar ia pedulikan - pendekatan yang paling luas dipakai di kebanyakan suite modern.
Snapshot merekam keluaran sebuah fungsi dan menegaskan bahwa keluaran itu tidak berubah. Snapshot sangat bagus untuk rendering dan serialisasi, dan berbahaya ketika tidak ada yang membaca diff-nya: snapshot yang diperbarui lalu mengabadikan sebuah bug adalah bentuk kegagalan yang umum di suite besar.
Data hasil generator seperti yang dibuat perkakas ini berada di bawah ketiganya. Ia mengisi bagian yang bervolume besar - ribuan baris yang membuat performa dan paginasi terasa nyata - sementara record khusus yang merepotkan ditulis dengan tangan, karena kasus yang merusak produksi bulan lalu layak dinyatakan secara eksplisit ketimbang berharap generator kebetulan menghasilkannya lagi.
Mengapa menyalin data produksi terus-menerus bermasalah
Mengambil dump produksi lalu mengosongkan nama-namanya terasa seperti jalan tercepat menuju data yang realistis, dan cara itu gagal karena alasan struktural, bukan prosedural. Membuang pengenal langsung tidak membuat sebuah dataset menjadi tak teridentifikasi: kombinasi atribut biasa seperti kode pos, tanggal lahir, dan jenis kelamin kerap hanya cocok pada satu orang, dan riset tentang identifikasi ulang dataset yang katanya anonim sudah sangat banyak dan konsisten hasilnya.
Masalah operasionalnya terpisah dan sama seriusnya. Salinan yang sudah dibersihkan itu tetaplah dataset produksi dengan kesetiaan penuh yang kini hidup di lingkungan dengan kontrol akses lebih lemah, akses pengembang lebih luas, dan cadangan yang tak seorang pun melacaknya. Di bawah GDPR, data yang dipseudonimkan tetap merupakan data pribadi dan tetap masuk cakupan; ini pengamatan umum, bukan nasihat hukum, dan detailnya bergantung pada yurisdiksi Anda serta petugas perlindungan data Anda.
Membangkitkan data dari skema menghindari seluruh kategori persoalan itu. Datanya punya bentuk yang tepat tanpa asal-usul sama sekali, jadi kebocoran dari staging adalah insiden tentang ketiadaan apa pun. Kalau distribusi mirip produksi memang benar-benar dibutuhkan, versi yang bisa dipertanggungjawabkan adalah memodelkan statistiknya lalu membangkitkan data dari model itu, bukan mengubah-ubah record yang asli.
Memuat hasilnya ke tempat yang dituju
Untuk basis data, keluaran SQL bisa dijalankan di klien mana pun tanpa driver, dan membungkusnya dalam satu transaksi membuat proses seeding besar jauh lebih cepat - seribu pernyataan terpisah di luar transaksi itu lambat di hampir semua mesin basis data. Khusus untuk PostgreSQL, COPY dari sebuah CSV mengungguli pernyataan INSERT dengan selisih besar begitu jumlah barisnya melewati beberapa ribu.
Untuk aplikasi, JSON biasanya sasaran yang tepat: berkas fixture yang dimuat tes saat mulai, respons untuk mock server, atau skrip seed yang dibaca ORM. Nama field keluar persis seperti yang Anda atur, jadi menyamakannya dengan nama properti pada model menghemat satu langkah pemetaan.
CSV adalah format untuk jalur yang melibatkan manusia - lembar kerja untuk dilihat sekilas sebelum diimpor, formulir unggah untuk admin, perkakas impor massal. Hanya saja ingat peringatan CSV yang biasa di ujung sana: konsumen yang menebak tipe data akan mengambil keputusannya sendiri atas apa pun yang tampak seperti angka, dan angka nol di depan pada nomor referensi biasanya jadi korbannya.
Pertanyaan umum
- Apakah aman menyimpan data hasil generator ini ke repositori?
- Aman, dan itu memang disengaja. Nama diambil dari daftar fiktif, nomor telepon memakai rentang +1-555-01xx yang dicadangkan rencana penomoran Amerika Utara untuk fiksi, email dan URL memakai keluarga example.com yang dicadangkan RFC 2606, dan alamat IP berasal dari blok dokumentasi RFC 5737. Tidak ada yang dibuat di sini mengarah ke host sungguhan atau menelepon orang sungguhan.
- Kenapa tidak minta data uji ke asisten AI saja?
- Untuk tiga baris, silakan. Untuk 500 baris dengan skema tetap, Anda butuh keterulangan dan nama kolom yang persis, dan itulah yang diberikan generator, bukan jendela obrolan. Mengubah satu tipe kolom lalu membuat ulang juga lebih cepat daripada menulis ulang prompt, dan hasilnya tidak pernah meninggalkan perangkat Anda.
- Apa bedanya data dummy, data uji, dan data palsu?
- Dalam praktiknya tidak ada bedanya - ketiga istilah itu menyebut hal yang sama, dan halaman ini melayani semuanya. Yang penting adalah bentuknya: rekaman terstruktur dengan kolom bernama dan bertipe, berbeda dari teks pengisi seperti lorem ipsum yang hanya memenuhi tata letak tetapi tidak bisa dimuat ke basis data atau API.
- Bagaimana cara memakai keluaran SQL?
- Keluarannya adalah pernyataan INSERT biasa untuk nama tabel yang Anda isi, satu baris satu pernyataan, sehingga bisa langsung dijalankan di klien SQL mana pun. Teks di-escape dengan menggandakan tanda kutip, angka tanpa kutip, dan boolean ditulis TRUE dan FALSE. Nama kolom atau tabel yang bukan pengenal biasa akan diapit tanda kutip ganda.
- Kenapa batasnya 1.000 baris?
- Seribu baris JSON sudah sekitar 100KB teks, dan di titik itulah area teks mulai terasa lambat. Jika perlu lebih, buat secara bertahap - kolom ID selalu mulai lagi dari 1, jadi sesuaikan bila semuanya dimuat ke satu tabel.
- Apakah keacakannya bisa diandalkan?
- Berasal dari crypto.getRandomValues dengan rejection sampling, sumber acak tanpa bias yang sama dengan yang dipakai generator kata sandi dan UUID di situs ini. Untuk nama kota fiktif hal itu tidak sepenting kata sandi, tetapi menjaga satu implementasi keacakan berarti hanya ada satu tempat yang harus benar.
Terakhir diperbarui:
Sertakan langkah, hasil yang diharapkan, dan hasil sebenarnya. Hapus rahasia dan data pribadi.