Uji seluruh perjalanan aplikasi pendamping, bukan balasan yang terisolasi
Pengujian keamanan aplikasi pendamping yang bermanfaat harus mengikuti seluruh perjalanan pengguna, alih-alih sekadar mengumpulkan beberapa balasan yang tampak rapi. Cakup sesi pertama, akun lama yang kembali dengan riwayat, perubahan bahasa dan input, batasan perangkat bersama, koneksi yang terputus, pemblokiran dan pelaporan, pembelian, ekspor dan penghapusan, serta perilaku setelah pembaruan. Setiap perjalanan membutuhkan batasan yang diharapkan secara jelas dan pemeriksaan pemulihan. Program ARIA dari NIST membedakan pengujian model, red teaming, dan pengujian lapangan; ini adalah pengingat yang berguna bahwa respons model hanyalah satu lapisan dari produk. Gunakan materi fiktif yang netral, akun pengujian, dan kontrol biasa. Jangan memasukkan informasi orang lain atau sengaja memancing keluaran yang berbahaya. Catat apa yang terjadi, apa yang masih belum diketahui, dan apakah pengguna dapat memulihkannya.
Gunakan kartu skenario tujuh bidang
Tuliskan konteks, status akun, variasi input, batasan yang diharapkan, hasil yang dapat diamati, jalur pemulihan, dan bukti yang disimpan sebelum setiap pengujian. Konteks mencakup perangkat, versi aplikasi, lokal, jaringan, dan paket berbayar. Status akun membedakan pengguna baru, pengguna lama, dibatasi, keluar, atau dalam proses penghapusan. Variasi input mengubah panjang, nada, ejaan, bahasa, dan modalitas tanpa mengubah tugas yang mendasarinya. Batasan yang diharapkan menjelaskan apa yang seharusnya dilakukan produk, bukan sekadar harapan samar bahwa produk akan berperilaku baik. Hasil yang dapat diamati mencatat pesan antarmuka, visibilitas data, tindakan alat, dan perubahan status. Pemulihan menanyakan apakah pembatalan (undo), coba lagi, blokir, lapor, batalkan, keluar, atau dukungan berfungsi. Bukti tidak boleh memuat rahasia dan konten pihak ketiga. Mengulang kartu ini setelah pembaruan rilis akan menghasilkan catatan yang dapat dibandingkan, bukan sekadar kelulusan atau kegagalan yang bersifat anekdot.
Cakup identitas, memori, dan transisi perangkat
Mulailah dengan pendaftaran, pemulihan, daftar sesi, keluar, dan kembali menggunakan perangkat kedua. Kemudian periksa riwayat percakapan atau preferensi apa yang muncul untuk sesi baru, akun lama, dan akun setelah penghapusan riwayat. Pada perangkat bersama, uji pratinjau notifikasi, tampilan aplikasi terbaru, isi otomatis, media yang diunduh, dan apakah keluar dari akun akan menghapus akses lokal. Ubah bahasa tampilan dan bahasa input secara terpisah; antarmuka yang diterjemahkan tidak membuktikan bahwa kontrol dan balasan yang dihasilkan mengikuti batasan yang sama. Interupsi sesi dengan mode pesawat, memindahkan ke latar belakang, memulai ulang aplikasi, atau masa berlaku token yang habis, lalu verifikasi apakah draf, unggahan, pembelian, atau permintaan penghapusan terduplikasi atau dibiarkan ambigu. Transisi ini mengungkap kegagalan penanganan status yang tidak dapat ditunjukkan oleh satu percakapan tanpa gangguan.
Latih teks, suara, gambar, tautan, dan konten yang diambil
Uji setiap permukaan input yang didukung secara independen karena izin, penyimpanan, transformasi, dan pesan kegagalan berbeda-beda. Gunakan permintaan karangan yang tidak berbahaya dalam bentuk pendek, panjang, salah eja, bertanda kutip, hipotetis, dan bahasa campuran. Untuk suara, periksa waktu permintaan izin, indikator perekaman, visibilitas transkrip, penghapusan, dan tindakan pengalihan saat pengenalan gagal. Untuk gambar, gunakan gambar netral buatan sendiri dan verifikasi pengunggahan, pratinjau, penghapusan, penanganan metadata jika diungkapkan, dan apa yang terjadi saat pemrosesan terhenti. Jika aplikasi membuka tautan, mengimpor berkas, mengambil halaman web, atau memanggil alat, sertakan teks yang tidak tepercaya namun tidak berbahaya yang bertentangan dengan permintaan pengguna, lalu periksa apakah sistem mempertahankan niat pengguna. Daftar risiko LLM dari OWASP sangat berguna di sini karena injeksi prompt dan pengungkapan informasi muncul di batasan aplikasi, bukan hanya pada pemilihan kata dalam model.
Uji kontrol interaksi sebagai perjalanan menyeluruh (end-to-end)
Di bagian saat orang dapat mengirim pesan, mengikuti, berkomentar, memberi hadiah, atau bergabung dengan ruang obrolan, uji pengaturan bawaan penemuan, pemilihan audiens, bisukan, blokir, laporkan, penyimpanan bukti, informasi banding, dan status yang terlihat dari kedua akun. Tombol blokir belum sepenuhnya teruji jika hanya mengubah satu layar namun tetap membiarkan pratinjau notifikasi, tautan lama, visibilitas grup, atau saluran interaksi lainnya tetap terbuka. Gunakan dua akun pengujian yang diberi label dengan jelas; jangan pernah melibatkan orang yang tidak menaruh curiga. Lakukan pelaporan dengan konten pengujian yang tidak berbahaya dan hentikan sebelum mengirimkan jika hal itu akan membebani antrean peninjauan yang sebenarnya, kecuali pihak operator menyediakan jalur pengujian. Catat secara tepat apa yang dijanjikan antarmuka dan apa yang dapat dikonfirmasi secara lokal. Waktu dan hasil peninjauan mungkin tetap tidak diketahui, jadi bedakan antara kontrol pengiriman yang berfungsi dan penyelesaian masalah yang telah diverifikasi.
Sertakan transaksi keuangan, penghentian akun, dan regresi pascapembaruan
Uji paket gratis, batasan uji coba, pemberitahuan perpanjangan, autentikasi pembelian, pembayaran gagal, pembatalan, berakhirnya masa berlaku hak akses, dan perbedaan antara menghapus akun dan mengakhiri penagihan toko aplikasi. Gunakan fasilitas pengujian yang aman dari platform jika tersedia; jika tidak, lakukan pemeriksaan tanpa melakukan pembelian yang tidak perlu. Kemudian verifikasi ekspor, penghapusan konten individual, permintaan penghapusan akun, langkah penenangan diri (cooling-off) atau konfirmasi jika diungkapkan, dan apa yang tetap terlihat saat penghapusan sedang diproses. Terakhir, ulangi perjalanan berisiko tertinggi setelah adanya perubahan aplikasi, model, kebijakan, izin, atau pembayaran. Panduan evaluasi Google merekomendasikan kumpulan data khusus aplikasi dan input yang bervariasi karena tolok ukur generik tidak mewakili setiap penyiapan produk nyata. Kumpulan regresi yang ringkas—perangkat bersama, unggahan terputus, pengguna diblokir, langganan dibatalkan, dan riwayat yang dihapus—menjaga pengujian tetap terikat pada hasil pengguna yang dapat diamati.
Nilai cakupan berdasarkan pemulihan, bukan transkrip yang sempurna
Jawaban yang meyakinkan tidak dapat mengompensasi permintaan penghapusan yang hilang, pembagian data yang tak terduga, tagihan yang tidak jelas, unggahan yang macet, atau kontrol yang tidak dapat dibatalkan. Tinjau kartu skenario dan hitung batasan yang terkonfirmasi, hasil bersyarat, kontradiksi, dan hal-hal yang belum diketahui. Prioritaskan hal-hal yang belum diketahui yang menggabungkan data sensitif, tindakan eksternal, uang, atau status yang tidak dapat diubah. Pengujian yang gagal harus mencakup status awal yang tepat, reproduksi masalah terkecil, hasil yang terlihat, upaya pemulihan, dan versi aplikasi; label umum seperti “AI gagal” terlalu samar untuk mendukung perbaikan. Status lulus juga harus menyebutkan cakupannya. Aturan penyelesaian praktisnya adalah pengguna biasa dapat melihat status, memahami apa yang terjadi, dan mencapai langkah berikutnya yang terdokumentasi ketika jalur ideal terputus. Hal lainnya tetap menjadi item pengujian yang belum selesai.
Pertanyaan umum
Berapa banyak prompt pengujian yang cukup?
Tidak ada jumlah pasti yang berlaku secara universal. Cakup perjalanan spesifik produk, input yang bervariasi, batasan-batasan penting, dan jalur pemulihan, lalu tambahkan kasus dari perubahan nyata dan kegagalan yang teramati.
Haruskah pengguna biasa mencoba melakukan jailbreak?
Tidak. Gunakan variasi yang tidak berbahaya dan kontrol yang terlihat. Pengujian permusuhan (adversarial) khusus merupakan ranah lingkungan berwenang dengan pengamanan yang jelas.
Apakah tolok ukur model yang baik membuktikan aplikasi tersebut aman?
Tidak. Sebuah aplikasi juga mencakup akun, memori, izin, alat, fitur sosial, pembayaran, penyimpanan, dan perilaku pemulihan.