Cara Menguji Aplikasi Anda Sebelum Pelancaran: Pelan Praktikal Pra-Pelancaran

Untuk menguji aplikasi anda sebelum pelancaran, senaraikan beberapa perjalanan yang mesti dapat diselesaikan oleh pengguna, jalankan setiap satu sebagai pengguna baharu pada komputer riba dan telefon, kemudian cuba cara mereka boleh tersilap: data kosong, input buruk, akaun kedua, sambungan perlahan. Uji dengan lebih berhati-hati apa-apa yang melibatkan wang atau data peribadi, dan ulangi perjalanan utama pada URL hidup selepas penerbitan. Akhirnya, perhatikan seseorang yang belum pernah melihat aplikasi itu cuba menggunakannya.

Anda tidak memerlukan pasukan QA atau rangka kerja ujian untuk ini. Anda perlukan senarai, satu atau dua jam, dan disiplin untuk benar-benar mengklik melalui senarai itu.

Langkah 1: Tulis perjalanan yang penting

Perjalanan ialah tugas dari awal hingga akhir yang ingin dilakukan oleh pengguna. Kebanyakan aplikasi mempunyai tiga hingga enam perjalanan yang benar-benar penting. Untuk aplikasi tempahan, contohnya:

Daftar dan sahkan akaun
Cari kelas dan tempahnya
Batalkan tempahan
Bayar untuk pas kelas
Kakitangan: lihat tempahan hari ini

Jika anda telah menulis cerita pengguna, kriteria penerimaannya sudah menjadi kes ujian anda. Jika belum, tulis satu baris bagi setiap perjalanan dengan maksud "berjaya".

Susun mengikut keutamaan. Perjalanan yang menjana wang atau yang dilalui oleh setiap pengguna (pendaftaran, log masuk, tindakan teras) diuji dahulu dan paling kerap.

Langkah 2: Uji laluan gembira sebagai pengguna baharu

"Laluan gembira" ialah perjalanan yang berjalan tepat seperti yang dirancang. Uji dari sudut pandangan orang asing:

Gunakan tetingkap pelayar persendirian, supaya anda tidak log masuk dan tiada data tersimpan.
Gunakan akaun baharu dengan e-mel sebenar yang boleh anda semak.
Mula dari halaman utama atau pautan, bukan halaman yang anda tanda buku semasa membina.

Pengguna baharu tiada data. Banyak pepijat hanya muncul apabila senarai kosong, profil tiada gambar, atau belum ada apa-apa yang dibeli. Akaun anda sendiri, yang penuh dengan data ujian, menyembunyikan pepijat ini.

Langkah 3: Cuba pecahkannya

Sekarang ulangi setiap perjalanan dan lakukan perkara yang salah dengan sengaja.

Cuba ini	Yang anda semak
Hantar borang kosong, atau dengan ruang sahaja	Medan wajib dikuatkuasakan, dengan mesej yang jelas
Teks yang sangat panjang, emoji, nama dengan aksara berdiakritik	Susun atur kekal, data disimpan dengan betul
Format salah: huruf dalam medan telefon, tarikh lepas	Pengesahan pada halaman dan di pelayan
Klik dua kali butang hantar	Tiada pesanan atau tempahan berganda
Butang belakang pelayar di tengah-tengah aliran	Tiada keadaan rosak atau data hilang
Muat semula setiap halaman	Data kekal; tiada halaman kosong atau 404
Log keluar, kemudian tekan belakang	Halaman persendirian tidak dipaparkan
Dua tab mengedit perkara yang sama	Simpanan terakhir tidak memadamkan yang pertama secara senyap

Memuat semula patut diberi perhatian khusus: jika aplikasi berfungsi apabila anda mengklik melaluinya tetapi muat semula pada halaman yang lebih dalam menunjukkan 404, lihat cara membetulkan ralat 404 selepas penerbitan.

Langkah 4: Uji kebenaran dengan dua akaun

Ini ialah ujian paling penting bagi mana-mana aplikasi yang mempunyai akaun, dan yang paling sering diabaikan.

Cipta dua pengguna biasa, A dan B, dan (jika aplikasi anda ada) seorang admin.

Sebagai A, cipta satu rekod. Log masuk sebagai B. Bolehkah B melihat, mengedit atau memadamnya? Mereka sepatutnya tidak boleh, melainkan itu reka bentuknya.
Sebagai A, salin URL salah satu rekod anda. Log masuk sebagai B dan buka URL itu secara langsung.
Sebagai pengguna biasa, buka halaman admin dengan menaip URL-nya.
Log keluar sepenuhnya dan cuba URL yang sama.

Jika anda menemui masalah di sini, jangan lancarkan sehingga ia diperbaiki. Semakannya mesti berlaku di pelayan, bukan sekadar menyembunyikan butang. Senarai semak keselamatan untuk aplikasi yang dibina dengan AI kami menyelami lebih dalam.

Langkah 5: Uji pada peranti sebenar

Buka aplikasi pada telefon sebenar, bukan sekadar tetingkap pelayar yang sempit.

Bolehkah anda ketik setiap butang tanpa zum?
Adakah papan kekunci menutupi medan yang sedang anda taip?
Adakah jadual dan kandungan lebar boleh digulung atau dibungkus, dan bukannya menolak halaman ke sisi?
Adakah teks boleh dibaca tanpa dicubit?

Cuba sekurang-kurangnya satu iPhone (Safari) dan satu telefon Android (Chrome) jika anda boleh meminjamnya. Safari khususnya mempunyai kerenah tersendiri dengan tarikh, video dan elemen kedudukan tetap.

Langkah 6: Uji wang dan e-mel dari hujung ke hujung

Apa-apa yang mengenakan bayaran kad atau menghantar e-mel memerlukan ujian menyeluruh.

Pembayaran. Gunakan mod ujian pembekal pembayaran anda dan nombor kad ujian. Semak pembayaran berjaya, kad ditolak, dan daftar keluar yang dibatalkan. Sahkan pesanan atau langganan muncul dalam aplikasi anda selepas pembayaran, bukan hanya dalam papan pemuka pembekal. Jika aplikasi anda bergantung pada webhook (mesej yang dihantar pembekal pembayaran kepada pelayan anda), sahkan ia sampai pada aplikasi yang diterbitkan, bukan hanya dalam pembangunan. Kemudian, sebelum melancarkan, tukar kepada kunci langsung dan buat satu pembelian sebenar yang kecil yang anda bayar balik.

E-mel. Daftar dengan alamat sebenar pada dua atau tiga penyedia berbeza. Semak e-mel sampai, tidak masuk spam, dan setiap pautan dalamnya menghala ke domain hidup, bukan alamat pratonton.

Langkah 7: Semak kelajuan dan ralat

Buka alat pemaju pelayar (klik kanan → Inspect) dan lihat tab Console pada setiap halaman utama. Ralat merah patut diperbaiki walaupun tiada apa yang kelihatan rosak.
Muatkan laman pada telefon menggunakan data mudah alih, bukan Wi-Fi. Jika skrin pertama mengambil masa beberapa saat, semak saiz imej dahulu.
Jalankan audit percuma seperti Lighthouse dalam alat pemaju Chrome untuk bacaan pantas tentang prestasi dan kebolehcapaian.

Langkah 8: Uji aplikasi yang diterbitkan, bukan hanya pratonton

Pratonton dan aplikasi yang diterbitkan bukan persekitaran yang sama. Sebelum memberitahu sesiapa tentang pelancaran, ulangi perjalanan utama pada URL hidup:

Adakah semua pembolehubah persekitaran dan rahsia ditetapkan untuk aplikasi yang diterbitkan?
Adakah ia menggunakan pangkalan data yang betul, dengan data yang anda jangkakan?
Adakah ubah hala log masuk dan pautan e-mel menggunakan domain hidup?
Adakah muat semula pada halaman dalam dimuatkan dengan betul?

Langkah 9: Perhatikan orang lain menggunakannya

Beri seorang atau dua orang matlamat ("tempah kelas yoga untuk Sabtu"), bukan arahan. Perhatikan, jangan bantu, dan catatkan di mana mereka teragak-agak. Ini cara terpantas untuk mencari ayat yang mengelirukan dan butang yang tersembunyi. Untuk versi yang lebih besar, lihat cara menjalankan ujian beta.

Apabila mereka menemui pepijat, tulis dengan betul: langkah-langkahnya, hasil yang dijangka dan hasil sebenar. Panduan kami tentang cara menulis laporan pepijat yang baik menunjukkan formatnya.

Menggunakan AI untuk membantu anda menguji

Jika anda membina dengan AI, anda boleh memintanya membantu merancang dan menjalankan ujian:

Senaraikan perjalanan pengguna utama dalam aplikasi ini dan, untuk setiap satu, kes tepi yang paling berkemungkinan rosak: keadaan kosong, input tidak sah, kebenaran, dan muat semula. Letakkannya dalam senarai semak yang boleh saya ikuti.

Log masuk sebagai dua pengguna ujian yang berbeza dan semak sama ada pengguna B boleh melihat atau menukar apa-apa yang dicipta oleh pengguna A, termasuk dengan membuka URL rekod A secara langsung. Laporkan apa yang anda temui sebelum membetulkan apa-apa.

Anggap laporan ujian AI sebagai pusingan pertama. Tetap klik melalui perjalanan wang dan kebenaran sendiri.

Menguji dalam Mythex

Dalam Mythex, arahan /test menjalankan Ujian Aplikasi: ejen memacu pelayar terhadap pratonton langsung anda, mengklik melalui halaman, mengambil tangkapan skrin dan melaporkan aliran yang rosak dalam sembang. Ia paling berkesan dengan satu perjalanan tertentu, seperti "uji pendaftaran dan tempahan kelas". Betulkan apa yang ditemui dengan /fix atau mesej biasa, kemudian jalankan /test sekali lagi. Ujian Aplikasi menggunakan pratonton, jadi semak perjalanan utama pada URL yang diterbitkan sendiri selepas penerbitan. Lihat Ujian Aplikasi dalam dokumentasi, dan panduan kami tentang cara menyahpepijat aplikasi yang dibina dengan AI untuk apabila sesuatu gagal.

Kesilapan biasa

Menguji hanya sebagai diri sendiri. Akaun admin anda dengan banyak data menyembunyikan pepijat keadaan kosong dan kebenaran.
Menguji hanya pada komputer riba. Kebanyakan pelawat ke banyak laman tiba melalui telefon.
Mengabaikan akaun kedua. Kebocoran data antara pengguna ialah pepijat paling serius yang boleh dilancarkan oleh sesebuah aplikasi.
Mempercayai pratonton. Aplikasi hidup mempunyai tetapan yang berbeza; uji juga.
Membetulkan pepijat tanpa menguji semula kawasan sekitarnya. Pembetulan pada satu borang boleh merosakkan borang lain yang berkongsi kod.

Senarai semak pra-pelancaran

Perjalanan utama disenaraikan dan disusun mengikut keutamaan
Setiap perjalanan lulus sebagai pengguna baharu dalam tetingkap persendirian
Input kosong, tidak sah, panjang dan pendua dikendalikan
Muat semula berfungsi pada setiap halaman
Pengguna tidak dapat melihat atau menukar data satu sama lain, walaupun melalui URL
Halaman admin disekat untuk pengguna biasa dan pelawat yang belum log masuk
Berfungsi pada iPhone sebenar dan telefon Android
Pembayaran diuji: berjaya, ditolak, dibatalkan, dan aplikasi dikemas kini selepasnya
E-mel sampai, tidak masuk spam, dan pautan menghala ke domain hidup
Tiada ralat merah dalam konsol pada halaman utama
Perjalanan utama diulang pada URL yang diterbitkan
Sekurang-kurangnya seorang di luar mencubanya semasa anda memerhati

Soalan lazim

Berapa banyak ujian yang diperlukan oleh aplikasi kecil sebelum pelancaran?

Cukup untuk yakin bahawa perjalanan utama berfungsi untuk pengguna baharu pada telefon dan komputer riba, bahawa pengguna tidak dapat melihat data satu sama lain, dan bahawa apa-apa yang melibatkan wang berfungsi dari hujung ke hujung. Bagi kebanyakan aplikasi kecil, ia adalah beberapa jam yang difokuskan, bukan berminggu-minggu.

Perlukah saya ujian automatik untuk MVP?

Tidak semestinya. Ujian manual bagi perjalanan teras menangkap kebanyakan pepijat yang boleh menghalang pelancaran. Ujian automatik mula memberi manfaat apabila anda kerap menukar aplikasi dan mahu tahu dengan cepat bahawa anda tidak merosakkan sesuatu yang dahulu berfungsi.

Patutkah saya menguji pada pratonton atau pada aplikasi hidup?

Kedua-duanya. Uji dengan teliti dalam pratonton, kemudian ulangi perjalanan utama pada aplikasi yang diterbitkan, kerana pembolehubah persekitaran yang hilang, pangkalan data yang berbeza atau tetapan penghalaan boleh menjadikan versi hidup berkelakuan berbeza.

Siapa yang patut menguji aplikasi saya selain saya?

Sekurang-kurangnya seorang yang belum pernah melihatnya. Beri mereka matlamat, bukan arahan, dan perhatikan tanpa membantu. Pembina secara tidak sedar mengelak laluan yang akan rosak.