Generator Data Palsu

Generator mock & data palsu gratis yang berjalan di browser Anda

Generator mock data ini membuat data fiktif yang realistis sesuai skema apa pun yang Anda butuhkan, lalu mengekspornya sebagai JSON, CSV, SQL, atau XML. Tidak ada yang perlu diinstal dan tidak perlu akun — Anda tentukan field, atur jumlah baris, dan buat sebanyak apa pun baris yang Anda mau, sepenuhnya di perangkat Anda sendiri. Ini alternatif praktis dibanding menulis fixture manual atau meminta ChatGPT membuat contoh baris satu per satu.

Mengisi database, mengisi mockup UI, load-testing proses impor, atau membangun demo — generator data palsu yang solid menghemat waktu berjam-jam dan menjauhkan data pelanggan asli dari lingkungan uji Anda.

Bangun skema apa pun, field demi field

Tambahkan field, beri nama tiap kolom, dan pilih dari lebih dua lusin tipe field: ID auto-increment, UUID, nama depan/belakang/lengkap, username, email, nomor telepon, jalan, kota, provinsi, negara, kode pos, perusahaan, jabatan, nama produk, tanggal dan tanggal-waktu, boolean, integer dan desimal dengan rentang min/max, harga, kode warna hex, alamat IP, URL, teks lorem, dan daftar kustom Anda sendiri. Atur ulang urutan atau hapus field kapan saja, dan berikan probabilitas kosong/null pada field mana pun agar data uji Anda mencakup nilai yang hilang seperti yang harus ditangani sistem sungguhan.

Sedang buru-buru? Preset satu klik menyediakan skema siap pakai untuk users, products, orders, employees, dan posts blog — lalu tinggal sesuaikan.

Ekspor ke JSON, CSV, SQL, atau XML

Ganti format tanpa perlu membuat ulang data. Ekspor larik objek sebagai JSON, CSV siap-spreadsheet dengan quoting yang tepat, pernyataan SQL INSERT batch untuk skrip seed Anda, atau XML — plus larik JavaScript dan TypeScript yang siap copy-paste (opsi TypeScript bahkan menyimpulkan sebuah interface). Angka tetap tanpa tanda kutip, boolean menjadi TRUE/FALSE di SQL, dan field kosong menjadi NULL, sehingga hasilnya langsung cocok dengan stack Anda.

Salin hasilnya ke clipboard, atau unduh sebagai file .json, .csv, .sql, atau .xml yang siap diimpor.

Sadar lokal, realistis, dan bisa direproduksi

Pilih lokal — US, UK, India, Jerman, atau Prancis — dan nama, jalan, format telepon, serta kode pos akan menyesuaikan wilayah tersebut, sementara email diturunkan dari nama yang dibuat sehingga setiap baris tetap konsisten. Butuh dataset yang sama dua kali? Masukkan seed dan hasilnya menjadi sepenuhnya reproducible: seed yang sama selalu membangun ulang baris yang identik, cocok untuk snapshot test dan laporan bug yang bisa dibagikan.

Baris tanpa batas, 100% privat — perbandingan dengan Mockaroo

Alat berbasis server seperti Mockaroo membatasi baris gratis sampai 1.000 per unduhan, mewajibkan akun untuk menyimpan skema, dan memproses data Anda di server mereka. Generator data acak ini bekerja berbeda: gratis, tanpa akun, dan pembuatan gaya Faker berjalan sepenuhnya di browser Anda sehingga skema dan data Anda tidak pernah meninggalkan perangkat. Buat ratusan, ribuan, atau puluhan ribu baris data uji sintetis — satu-satunya batasnya adalah kemampuan perangkat Anda sendiri.

Kegunaan umum data palsu

Developer memakai generator data dummy untuk mengisi database development dan staging, mengisi tabel dan dashboard admin untuk keperluan screenshot, membuat fixture CSV dan SQL untuk pengujian otomatis, membuat prototipe respons API, dan menguji beban paginasi, pencarian, serta impor dalam skala besar. Desainer memakainya untuk mengisi mockup dengan konten yang meyakinkan alih-alih lorem ipsum, dan tim QA memakai dataset ber-seed untuk mereproduksi kasus tepi. Kapan pun Anda butuh data yang meyakinkan secara cepat — tanpa menyentuh data pengguna asli — inilah alat yang tepat.

GDPR, privacy by design, dan mengapa data pelanggan asli tidak boleh masuk ke lingkungan development

GDPR Pasal 25 menetapkan prinsip 'data protection by design and by default', yang dalam praktiknya berarti data pribadi harus dijauhkan dari sistem yang tidak membutuhkannya — termasuk laptop developer, server staging, runner CI, dan file log. Menggunakan dump database produksi di staging, sekalipun dengan niat baik, mengekspos nama asli, alamat email, dan nomor telepon ke setiap developer yang punya akses database, ke alat monitoring pihak ketiga, dan ke baris log mana pun yang tak sengaja merekam hasil query. Satu lingkungan staging yang salah konfigurasi saja pernah menyebabkan denda GDPR bernilai jutaan euro.

Alternatif yang aman adalah membangun pipeline data development dan staging berbasis data uji sintetis sejak awal. Rekaman palsu yang dihasilkan secara struktural identik dengan data produksi — tipe kolom sama, kardinalitas sama, constraint referensial sama — sehingga setiap query, migrasi, dan skrip impor yang berhasil di staging akan berhasil pula di produksi, tanpa ada informasi pribadi asli yang meninggalkan batas produksi. Regulator di UE, Inggris, dan California (CCPA) semakin memperlakukan penggunaan PII asli di lingkungan non-produksi sebagai celah kepatuhan, menjadikan data sintetis bukan sekadar kemudahan tapi juga pengaman hukum.

Di luar risiko regulasi, data palsu menghilangkan efek menghambat pada development. Ketika setiap developer dan QA engineer bisa membuat dataset segar yang realistis sesuai permintaan, tidak ada lagi bottleneck menunggu dump produksi yang sudah disanitasi, tidak ada perdebatan soal perjanjian berbagi data, dan tidak ada risiko tak sengaja mengirim email konfirmasi pesanan uji ke alamat pelanggan asli yang tersimpan di database staging.

Mengapa data palsu yang realistis lebih penting daripada sekadar noise acak

Data uji paling awal adalah noise acak — string acak di field nama, integer acak di field telepon. Data semacam itu lolos sebagian besar uji logika bisnis tetapi melewatkan satu kelas bug dunia nyata. Field nama depan yang diisi 'xxxxxxxx' tidak akan pernah mengungkap bug encoding multi-byte yang crash saat pengguna bernama Müller atau 李明 mendaftar. Field telepon berisi '12345' tidak akan pernah memicu bug off-by-one pada formatter yang mengasumsikan sepuluh digit. Data palsu yang realistis dan sadar lokal — nama diambil dari tabel frekuensi nyata, email diturunkan dari nama tersebut, nomor telepon sesuai format rencana penomoran sungguhan — jauh lebih mungkin memicu kasus tepi yang baru muncul begitu produk mencapai pengguna nyata.

Inilah filosofi inti di balik pustaka seperti Faker.js: buat data yang secara struktural tidak bisa dibedakan dari data produksi, sehingga test suite yang dijalankan pada data palsu benar-benar mewakili perilaku produksi. Prinsip yang sama berlaku untuk pengujian UI: dashboard yang dibuat dengan 'Lorem Name' di setiap sel akan tampak baik-baik saja di screenshot, tetapi dashboard yang diisi dengan 'Bartholomew Christodoulopoulos-Nakamura' akan langsung mengungkap bahwa pemotongan ellipsis Anda meleset 40 karakter.

Nilai kosong dan null sama pentingnya. Database sungguhan itu berantakan — field opsional sering kosong, CSV hasil impor punya celah, pengguna melewatkan field formulir. Probabilitas null per field mensimulasikan keberantakan itu dalam data yang dihasilkan, sehingga kode penanganan null pada aplikasi Anda teruji lebih dulu sebelum bertemu pengguna asli yang membiarkan nama tengahnya kosong.

Reproducibility berbasis seed dan perannya dalam pengujian

Pseudo-random number generator (PRNG) menghasilkan urutan deterministik dari nilai awal yang sama — seed. Setiap pustaka data palsu yang baik mengekspos seed ini agar sebuah test bisa mencatat seed persis yang dipakai untuk membuat fixture-nya dan memutarnya kembali secara identik di mesin mana pun kapan saja. Tanpa seed, test yang flaky dan hanya gagal saat email yang dihasilkan kebetulan mengandung tanda kutip hampir mustahil direproduksi; dengan seed, Anda bisa mengunci pembuatan data, membuka data yang sama di debugger, dan menemukan bugnya.

Pembuatan ber-seed juga memungkinkan snapshot testing: buat 500 baris dengan seed 42, render menjadi HTML, dan simpan HTML itu sebagai snapshot yang diharapkan. Pada run CI berikutnya, buat ulang dengan seed yang sama, render ulang, dan bandingkan. Jika snapshot berubah, Anda tahu persis jalur kode mana yang mengubah outputnya, bukan sekadar bahwa sesuatu berubah. Alat seperti toMatchSnapshot Jest dan perbandingan visual Playwright mengandalkan pola ini.

Dalam praktiknya, tim sering menyimpan seed bersama file fixture mereka — komentar di skrip seed, key seed di fixture JSON, atau variabel environment di konfigurasi CI. Ketika sebuah bug dilaporkan, menyertakan seed yang menghasilkan dataset bermasalah adalah cara tercepat untuk menyerahkan kasus yang bisa direproduksi ke developer lain.

Pustaka data palsu, pola seeding database, dan pipeline CI/CD

Beberapa pustaka open-source mengimplementasikan pola Faker dalam skala besar. Faker.js (JavaScript/TypeScript) paling banyak dipakai di front end dan Node.js, dengan dukungan bawaan lebih dari 70 lokal dan puluhan kategori data termasuk internet, commerce, finance, dan data kendaraan. Faker (Python) mencerminkan API yang sama untuk workflow backend dan data engineering. Bogus (.NET) mengikuti paradigma yang sama dan menambahkan Fluent API untuk mendefinisikan factory entitas. Datafaker (Java) menggantikan pustaka Java Faker yang kini sudah diarsipkan dan terintegrasi dengan JUnit 5. Semuanya mendukung pembuatan ber-seed; semuanya open source dan gratis. Ketika proyek Anda sudah memakai salah satunya, membangun langsung di atasnya biasanya pilihan yang tepat. Ketika Anda butuh dataset cepat sekali pakai tanpa menambah dependency — untuk demo, spreadsheet, atau laporan bug — generator berbasis browser seperti ini lebih cepat.

Pada level database, data palsu menggerakkan dua pola berbeda: fixture dan factory. Fixture adalah file statis — file JSON atau SQL yang di-commit ke repository dan selalu memuat baris yang sama. Cepat dan bisa diprediksi tapi jadi usang seiring perkembangan skema. Factory adalah kode yang membuat baris sesuai permintaan di setiap run test, sehingga otomatis tetap sinkron dengan migrasi skema. Sebagian besar stack test modern (Rails FactoryBot, Laravel Model Factories, Django mixer, Prisma fixtures) memakai pola factory untuk test unit dan integrasi, lalu beralih ke file fixture untuk test integrasi lambat yang butuh dataset besar dan stabil yang dimuat sekali per sesi test.

Dalam pipeline CI/CD yang dirancang dengan baik, data palsu muncul di beberapa tahap. Tahap unit-test menjalankan factory di memori, tanpa database. Tahap integration-test mengisi kontainer database baru dengan baris yang dihasilkan sebelum test suite dimulai dan membongkarnya setelahnya. Lingkungan staging diisi sekali dari dataset besar yang dihasilkan untuk meniru volume produksi, memungkinkan load test dan profiling performa tanpa data pengguna asli. Hasilnya adalah pipeline di mana setiap tahap punya data yang dibutuhkannya, dihasilkan sesuai permintaan, pada skala yang tepat, dengan risiko privasi nol.