Keuntungan:
- Kemampuan untuk memahami lapisan fungsional, regresi, kasus tepi, dan uji kerusakan serta menghasilkan skenario pengujian dan daftar kasus tepi dengan kecerdasan buatan
- Kemampuan untuk mempercepat proses debug dengan menulis kode pengujian otomatis dengan kecerdasan buatan dan mengekstraksi pola dalam log dan analisis kerusakan
- Mampu memahami bahwa diagnosis kesalahan kecerdasan buatan bukanlah bukti melainkan hipotesis, penyebabnya harus dibuktikan dengan log dan reproduksi, dan pentingnya laporan kesalahan dapat direproduksi.
Saat sebuah game dirilis, pemain memainkannya dengan cara yang tidak pernah dibayangkan oleh pengembangnya: terjebak di dinding, mengeksploitasi inventaris, mencapai tempat yang mustahil, memicu crash. Jaminan kualitas (QA — jaminan kualitas); Ini adalah proses pengujian game secara sistematis sebelum dirilis dan menemukan serta memperbaiki kesalahan (bug), kerusakan, ketidakstabilan, dan pengalaman buruk. Ini adalah salah satu mata rantai yang paling padat karya namun penting dalam produksi game. AI mempercepat QA dalam banyak hal: pembuatan kasus uji, analisis laporan bug, peninjauan log, penulisan kode pengujian otomatis, proses debug, dan penyempurnaan langkah-langkah produksi. Namun AI tidak menggantikan intuisi dan evaluasi penguji manusia terhadap nuansa permainan.
Di unit ini Anda akan mempelajari cara menggunakan AI dalam QA dan debugging; Anda akan mempelajari desain skenario pengujian, analisis log, penulisan pengujian otomatis, dan disiplin pelaporan kesalahan.
Lapisan QA dan tempat AI
QA berlapis-lapis. Pengujian fungsional: apakah fitur berfungsi (apakah pintu terbuka, apakah rekaman dimuat). Pengujian regresi: apakah perubahan baru merusak apa yang sudah berjalan sebelumnya? Pengujian kasus tepi: masukan yang tidak biasa (setel ulang inventaris, dua kunci sekaligus, nilai batas). Pengujian kinerja/kerusakan: apakah game stabil. Tes gameplay/pengalaman: menyenangkan, intuitif. AI kuat dalam empat hal pertama: menghasilkan skenario, membuat daftar kasus edge, menulis kode pengujian, menganalisis log. Yang terakhir—pengalaman—adalah milik manusia.
Alur QA langkah demi langkah:
- Hasilkan kasus uji (daftar kasus fungsional dan edge dengan AI).
- Tulis pengujian otomatis (kode untuk pemeriksaan berulang).
- Jalankan dan kumpulkan (kesalahan log, log, crash).
- Analisis (periksa log dan pola kesalahan dengan AI).
- Laporkan dan verifikasi (laporan bug yang jelas dan dapat direproduksi; perbaikan uji).
Petunjuk: Sulit untuk menemukan kasus edge karena desainer memainkan permainannya dengan "benar". Tanyakan kepada AI “apa yang akan dicoba pemain jika mereka ingin merusak sistem ini?” Buat daftar eksploitasi dan kasus edge.
Pengujian otomatis: serahkan pengulangan pada mesin
Menguji hal yang sama secara manual di setiap rilis melelahkan dan rawan kesalahan. Pengujian otomatis memasukkan pemeriksaan ini ke dalam kode: apakah suatu fungsi mengembalikan hasil yang benar setiap kali dipanggil, apakah sistem berada dalam keadaan yang diharapkan. Unity dan Unreal menawarkan kerangka pengujian; AI cepat dalam menulis tes ini. Hal ini sangat berguna untuk regresi: jika suatu perubahan merusak sesuatu yang berfungsi sebelumnya, pengujian akan berubah menjadi merah. Tinjau tes yang dihasilkan AI, pastikan mereka memeriksa apa yang benar-benar bermakna — tes kosong lebih buruk daripada tidak ada tes.
Perhatian: Saat melakukan debug, AI terkadang menghasilkan penjelasan yang dibuat-buat sebagai "kemungkinan penyebab" (halusinasi). Jangan menerima penyebab bug hanya karena AI memberitahu Anda demikian; Buktikan penyebabnya dengan mencatat, mereproduksi, dan menguji. Kesalahan diagnosis menunda menemukan diagnosis yang tepat.
Reproduksi: inti dari debugging
Persyaratan pertama untuk memperbaiki bug adalah mereproduksinya dengan andal. Bug yang dijelaskan sebagai "terkadang terjadi" tidak dapat diperbaiki karena Anda tidak dapat memverifikasi apakah perbaikan tersebut berhasil. Jadi pekerjaan debugging yang paling berharga adalah mempersempit kondisi yang tepat di mana bug terjadi (langkah apa, situasi apa, waktu apa). AI membantu mempersempit hal ini: Anda dapat memberikan gejala dan langkah-langkah reproduksi parsial dan mengatakan “menyarankan kondisi dan mempersempit strategi yang mungkin memicu perilaku ini.” Namun Anda sebenarnya melakukan penyempitan dengan menjalankan permainan; AI menghasilkan hipotesis, Anda menghilangkannya.
Terutama yang berhubungan dengan waktu (kondisi balapan) dan kesalahan yang berhubungan dengan status memori adalah hal yang berbahaya; ini hanya terjadi dalam urutan atau beban tertentu. Untuk kesalahan seperti itu, penting untuk menambahkan informasi stempel waktu dan status ke log; AI dapat menganalisis log kaya ini dan melihat polanya (“kesalahan selalu terjadi ketika dua peristiwa ini terjadi baru-baru ini”). Ingat aturan emas debugging: pahami dulu, lalu perbaiki. Koreksi tanpa pemahaman menyembunyikan kesalahan tetapi tidak menyelesaikannya dan seringkali menimbulkan kesalahan baru di tempat lain.
tiga kasus mini
Kasus 1 - Perburuan kasus tepi. Dalam RPG, tim menguji sistem inventaris dalam gameplay "normal" dan menganggapnya solid. Mereka meminta AI mengatakan "coba pecahkan inventaris ini" dan menghasilkan 30 skenario kasus tepi; 4 di antaranya adalah kesalahan sebenarnya (0 pemisahan item berat, sekali pakai). Dikoreksi sebelum dipublikasikan.
Kasus 2 — Analisis log mengatasi kerusakan tersebut. Sebuah game mogok secara acak; log kerusakan berjumlah ratusan baris. Ketika AI diberikan log dan dimintai polanya, terungkap bahwa crash selalu terjadi pada transisi adegan tertentu dan memori rendah. Dengan petunjuk ini, pemrogram menemukan kebocoran memori; Tingkat kecelakaan turun menjadi nol.
Kasus 3 — Kembali dari kesalahan diagnosis. Seorang programmer mempercayai penjelasan AI bahwa "kesalahan ini disebabkan oleh fungsi ini" dan mengutak-atiknya selama setengah hari; tidak ada hasil yang keluar. Ketika dia mengklarifikasi dan mencatat kembali langkah-langkah produksi, kesalahannya berada di tempat yang sama sekali berbeda. Pelajaran: Diagnostik AI adalah hipotesis, bukan bukti.
Empat templat yang dapat disalin
1) Pembuatan skenario kasus tepi/eksploitasi:
Peran Anda: penguji QA yang berbahaya. Saya menjelaskan sistem berikut: [sistem, aturan]. Tugas: membuat daftar 20 skenario kasus ekstrem yang akan mencoba merusak, mengeksploitasi, atau membuat sistem ini berada dalam kondisi yang tidak terduga. Untuk masing-masing: apa yang harus dicoba, hasil yang diharapkan, kemungkinan kesalahan.
2) Penulisan tes otomatis:
Mesin: [Unity 2022.3 / Unreal 5.3]. Kerangka pengujian: [tentukan].Tulis pengujian otomatis untuk fungsi/sistem berikut: [deskripsi/kode].Sertakan kasus normal, kasus batas, dan masukan yang salah.Pastikan setiap pengujian memverifikasi sesuatu yang benar-benar bermakna; Menulis tes yang kosong/tidak berarti.
3) Analisis log/kerusakan:
Di bawah ini adalah log kerusakan/kesalahan permainan: [log].Tugas: menandai pola yang berulang, kondisi umum (adegan, memori, waktu), dan kemungkinan akar penyebabnya.Sajikan setiap penyebab sebagai "hipotesis yang harus dibuktikan"; berbicara dengan jelas. Juga beri tahu saya cara memverifikasi.
4) Klarifikasi laporan bug:
Jadikan laporan kesalahan samar berikut ini jelas dan dapat direproduksi: [laporan mentah]. Keluaran: judul, reproduksi langkah demi langkah, hasil yang diharapkan, hasil aktual, frekuensi, lingkungan. Jika ada informasi yang kurang, cantumkan informasi apa saja yang diperlukan.
Perintah lemah / Perintah kuat
Perintah yang lemah:
Ada bug di game saya, perbaiki.
Tanpa konteks, tanpa catatan, tanpa reproduksi; AI bersifat prediktif dan risiko halusinasinya tinggi.
Perintah yang kuat:
Ada bug di game Unity 2022.3 saya: inventaris terkadang berlipat ganda saat pemain melakukan penyimpanan cepat. Reproduksi: [langkah]. Kode terkait: [tempel]. Log: [tempel].Tugas: membuat daftar kemungkinan akar penyebab sebagai hipotesis yang harus dibuktikan, berikan cara memverifikasi dan kemungkinan perbaikan untuk masing-masing penyebab.Buatlah penyebab yang tidak ada; Jika Anda tidak yakin, beri tahu saya.
Reproduksi, kode, log, dan permintaan "disajikan sebagai hipotesis" membuat diagnosis dapat diandalkan.
Tabel lapisan QA
lapisan
Apa yang diujinya?
Kontribusi AI
bagian manusia
fungsional
Apakah fitur ini berfungsi?
Skrip, kode uji
Keputusan penerimaan
regresi
Apakah yang lama rusak?
tes otomatis
Keputusan ruang lingkup
kasus ekstrim
masukan yang tidak biasa
Produksi naskah
prioritas
Kecelakaan/kinerja
tekad
Analisis log
Konfirmasi akar permasalahan
Pengalaman
hiburan, intuisi
terbatas
sepenuhnya manusia
Kesalahan umum
- Hanya menguji gameplay "normal". Kasing tepi meledak setelah dirilis.
- Salah mengira diagnosis AI sebagai bukti. Mengapa dibuktikan dengan log dan pengujian.
- Menulis tes otomatis kosong. Pengujian yang tidak berarti memberikan ilusi kepercayaan diri.
- Laporan bug yang tidak jelas. Kesalahan yang tidak dapat direproduksi tidak dapat diperbaiki.
- Melewatkan pengujian regresi. Setiap koreksi dapat menyebabkan kesalahan baru.
Singkatnya
QA adalah disiplin yang membuat permainan siap untuk pemain. AI; menghasilkan skenario kasus tepi, menulis pengujian otomatis, menganalisis log, dan mengklarifikasi laporan kesalahan. Namun diagnosis mereka hanyalah hipotesis, evaluasi pengalaman bersifat manusiawi, dan setiap koreksi memerlukan pengujian ulang. Replikasi refleks "siapa yang bisa memecahkan ini dan bagaimana" dengan AI; Anda mengumpulkan bukti.
Tugas aplikasi
Pilih sistem dari game Anda. Buatlah 20 skenario dengan templat “pembuatan skenario kasus tepi/eksploitasi” dan uji 5 skenario yang paling berisiko. Buat laporan yang dapat direproduksi untuk bug yang Anda temukan dengan template "Penyempurnaan laporan bug".
daftar periksa
- [ ] Saya membuat kasus tepi dengan "Siapa yang dapat memecahkan ini dan bagaimana caranya?"
- [ ] Menulis dan meninjau pengujian otomatis untuk pemeriksaan berulang.
- [ ] Saya menganggap diagnosis AI sebagai hipotesis dan membuktikannya dengan log/tes.
- [ ] Saya melaporkan kesalahan secara berulang.
- [] Saya menguji ulang setiap perbaikan untuk regresi.