Apakah proses ujian APP Android dan masalah biasa?

WBOY
Lepaskan: 2023-05-13 21:58:04
ke hadapan
1206 orang telah melayarinya

1. Ujian automatik

Pengujian automatik terutamanya merangkumi beberapa bahagian, ujian automatik fungsi UI, ujian automatik antara muka dan ujian automatik khusus lain.

Ujian automatik 1.1 fungsi UI

Ujian automatik fungsi UI, juga dikenali sebagai ujian automatik, terutamanya ujian automatik berdasarkan antara muka UI, dan klik fungsi UI direalisasikan melalui skrip Gantikan ujian manual dengan automasi.

Kelebihan ujian ini adalah untuk mengeluarkan tenaga manusia ujian secara berkesan untuk ujian fungsi ciri antara muka yang sangat berulang, dan menggunakan pelaksanaan skrip untuk mencapai pengembalian fungsi yang pantas dan cekap.

Walau bagaimanapun, kelemahan ujian jenis ini juga jelas, termasuk kos penyelenggaraan yang tinggi, mudah salah menilai dan keserasian yang tidak mencukupi. Kerana ia berdasarkan operasi antara muka, kestabilan antara muka telah menjadi kekangan terbesar untuk mengekalkan skrip. Interaksi antara muka yang kerap berubah bermakna skrip kes ujian perlu sentiasa dikemas kini, menduduki sejumlah besar sumber ujian.

=

Salah penilaian cenderung berlaku terutamanya kerana pengenalan berdasarkan kawalan UI dengan mudah boleh membawa kepada pemuatan yang perlahan atau tidak normal disebabkan oleh keadaan rangkaian, konfigurasi peranti, persekitaran ujian, dsb., yang mengakibatkan ujian pelaksanaan kes Beberapa penghakiman semasa proses adalah tidak tepat, yang menjejaskan ketepatan ujian. Keserasian yang tidak mencukupi terutamanya bermakna bahawa pelaksanaan skrip ujian pada peranti yang berbeza, sistem pengendalian yang berbeza, persekitaran perkakasan yang berbeza, dll. akan menyebabkan situasi yang tidak dapat diramalkan, yang membawa kepada keputusan pelaksanaan kes ujian yang tidak tepat.

Berdasarkan perbandingan kelebihan dan kekurangan di atas, dalam ujian automatik fungsi UI, kami terutamanya melaksanakan ujian laluan teras APP dan menjalankan ujian UI pada modul berfungsi yang memerlukan sejumlah besar pelaksanaan berulang, pengesahan berulang dan kekerapan rendah perubahan antara muka UI Pelaksanaan ujian automatik berfungsi.

Keperluan untuk sejumlah besar pelaksanaan berulang dan pengesahan berulang bermakna kadar penggunaan selepas automasi adalah tinggi, dan kekerapan perubahan antara muka UI adalah rendah, yang bermakna kos penyelenggaraan berikutnya tidak tinggi bagi kami , ketiga-tiga jenis kes penggunaan ini adalah Untuk bahagian yang mempunyai input dan output yang agak tinggi, kami akan memberi keutamaan tertinggi kepada amalan ujian automatik fungsi UI.

Semasa proses ujian fungsi UI automatik, kawalan yang berkaitan, kes ujian dan set ujian boleh disusun dan diuruskan dengan berkesan, dan kerja berulang boleh digabungkan tepat pada masanya untuk mengurangkan pembaziran sumber. Apabila fungsi UI berubah, ia juga boleh diselenggara pada kos yang lebih kecil, mengurangkan kos penyelenggaraan.

1.2 Pengujian Automatik Antara Muka

Dalam bahagian ujian automatik fungsi UI, kami menyebut kekangan untuk automasi: kestabilan. Tepat kerana antara muka UI tidak stabil, kos mengautomasikan fungsi UI adalah agak tinggi Jadi kami secara semula jadi memikirkan bahagian yang lebih stabil dan lebih kondusif untuk automasi daripada fungsi UI, dan itu adalah antara muka.

Antara muka APP mungkin berubah disebabkan oleh permintaan pengurus produk yang berbeza pada peringkat yang berbeza, tetapi antara muka di belakangnya biasanya agak stabil, yang bermanfaat untuk kami menjalankan ujian automatik.

Kita perlu menyediakan antara muka yang dipanggil oleh APP, menyusunnya mengikut modul berfungsi, mengutamakannya untuk automasi, memahami maksud setiap antara muka, julat nilai parameter yang berbeza dan cara mengendalikan yang berbeza input Inventori situasi yang menghasilkan pelbagai output, dan ringkaskan ralat atau pengembalian pengecualian untuk memastikan keberkesanan dan kesempurnaan ujian antara muka.

Selepas ujian automasi antara muka dimulakan, dokumen antara muka perlu diselenggara bersama-sama dengan jurutera pembangunan Sama ada terdapat peningkatan atau penurunan dalam antara muka atau perubahan berkaitan antara muka sedia ada, jurutera ujian boleh mengetahui dengan segera dan Buat pelarasan yang sepadan dengan kes penggunaan untuk ujian automasi antara muka.

1.3 Ujian automatik khas lain

Selain dua kategori automasi di atas, kami juga boleh menggunakan automasi untuk melakukan beberapa ujian khas untuk membantu meningkatkan kualiti ujian dan kecekapan ujian kami. Di sini, kita perlu berfikir dengan tekun dalam kerja ujian harian kita, memikirkan tugas mana yang boleh dicapai melalui automasi, ujian mana yang boleh diautomasikan untuk meningkatkan kecekapan ujian, titik fungsi mana yang boleh diautomasikan untuk mencapai pemantauan ujian jangka panjang, dsb.

Sebagai contoh, dalam projek yang saya bertanggungjawab, terdapat fungsi semasa ujian manual, kami hanya boleh mengesahkannya dengan bilangan klik yang terhad, dan kekerapan klik adalah rendah , kami boleh melaksanakannya semasa proses ujian Untuk operasi klik yang lebih pantas dan lebih lama, kami boleh menggunakan automasi untuk mencapainya. Ia bukan sahaja boleh dilaksanakan pada peralatan ujian anda sendiri, tetapi ia juga boleh dilaksanakan pada peranti yang berbeza Ujian automatik ini berkesan dan boleh meningkatkan kecekapan ujian dan kualiti ujian. Walaupun ujian ini tidak akan ditambahkan pada set kes penggunaan untuk automasi fungsi UI atas pelbagai sebab, dalam versi semasa, automasi sememangnya telah membawa kami bantuan yang sangat berguna, dan inilah yang kami perlukan untuk menyokong.

Ringkasnya, kami boleh menggunakan pelbagai alat ujian automatik dan kaedah ujian untuk membantu kami dalam ujian, yang layak diiktiraf.

2. Ujian prestasi

Dalam sistem ujian projek yang saya bertanggungjawab, ujian prestasi terutamanya merangkumi ujian prestasi dalam tiga dimensi, iaitu ujian prestasi dalam dimensi masa, ujian prestasi dalam dimensi sumber, dan ujian Kefasihan.

2.1 Dimensi Masa

Ujian prestasi dalam dimensi masa terutamanya merujuk kepada tindak balas masa ciri berfungsi selepas operasi klik. Kami lebih biasa dengan masa memuatkan skrin pertama, masa buka lompat tindak balas selepas mengklik, dsb.

Terdapat banyak cara untuk melakukan ujian prestasi dalam dimensi masa Anda boleh menggunakan rakaman skrin untuk mengira masa, anda juga boleh menggunakan cap masa dalam program untuk mengira masa, anda juga boleh menggunakan skrip pihak ketiga untuk mengira. masa, atau anda boleh melalui pengecaman imej Teknologi untuk mengira masa, dsb.

Semasa proses ujian, kita perlu menjalankan pra-penyelidikan ke atas alat itu bersama-sama dengan projek itu sendiri Adakah ia ujian sekali sahaja atau memerlukan ujian berterusan Adakah ia perlu ditukar kepada a alat untuk kegunaan jangka panjang berikutnya? Adakah ia pada satu peranti, anda masih perlu mempertimbangkan keserasian untuk digunakan dalam persekitaran peranti yang berbeza, sama ada alat itu adalah sumber terbuka atau menyediakan antara muka data untuk penyepaduan seterusnya dengan ujian pasukan platform, dan sebagainya.

2.2 Dimensi Sumber

Ujian prestasi dimensi sumber terutamanya merujuk kepada penggunaan pelbagai sumber sistem semasa penggunaan APP, termasuk CPU, memori, kuasa, trafik, dsb.

Pilihan alat ujian bergantung pada terminal ujian yang berbeza Dimensi yang perlu dipantau semasa ujian juga ditentukan berdasarkan projek Kaedah ujian khusus tidak akan dibincangkan di sini.

Apa yang perlu dinyatakan di sini ialah ujian prestasi dalam dimensi sumber boleh melakukan dua bahagian kerja, satu ujian prestasi semasa proses ujian, dan satu lagi ialah pengumpulan data prestasi dalam talian.

Ujian prestasi semasa proses ujian boleh dinilai berdasarkan keperluan ujian perniagaan yang manakah perlu diuji Adakah ujian satu kali bagi versi semasa atau ujian yang memerlukan perbandingan setiap versi berikutnya? Adakah hanya perlu untuk menguji versi ini? Data prestasi mesin masih perlu dikumpulkan pada berbilang peranti Ia hanya perlu diuji oleh APP ini, dan ia masih perlu dibandingkan dengan produk pesaing dan diuji.

Atas dasar ini, nilaikan sama ada perlu untuk melaksanakan kes ujian melalui skrip automatik untuk penggunaan semula seterusnya. Jika ujian perbandingan membujur berikutnya dengan versi sejarah diperlukan, adalah perlu untuk memastikan bahawa persekitaran ujian dan peralatan ujian adalah sekonsisten yang mungkin untuk menjadikan keputusan ujian lebih sahih dan boleh dipercayai.

Satu lagi perkara kecil untuk ditambah ialah pemprosesan dan pengiraan data ujian boleh direalisasikan melalui skrip automatik, menjimatkan kos sumber pengkomputeran manusia. Jika perlu, anda juga boleh membina platform mudah dan menyimpan semua data ujian pada platform untuk analisis dan rujukan seterusnya.

Pengumpulan data prestasi dalam talian memerlukan jurutera pembangunan melaporkan data yang berkaitan semasa proses pelaksanaan fungsi Selepas fungsi dikeluarkan, data dalam talian mesti diambil, diproses dan dikira untuk menemui masalah yang mungkin berlaku. Dengan kerjasama log jurutera pembangunan dan log pengguna yang mengalami ralat, kami boleh mencari, menganalisis dan menyelesaikan masalah prestasi yang berkaitan.

2.3 Ujian kefasihan

Sebagai pengalaman pengguna yang paling intuitif, ujian kefasihan juga mesti dimiliki untuk banyak ujian prestasi. Tidak perlu menjelaskan secara terperinci di sini tentang kaedah melakukan ujian kefasihan, tetapi terdapat beberapa perkara yang perlu diberi perhatian:

Yang pertama ialah cara kami merancang kes penggunaan untuk ujian kefasihan, dan kedua ialah cara kami menggunakan data keputusan ujian selepas ujian kefasihan Untuk menganalisis dan menambah baik, yang ketiga ialah bagaimana kami perlu memantau kefasihan daripada data dalam talian selepas APP dikeluarkan.

Berkenaan reka bentuk kes ujian kelancaran, ia perlu direka bentuk berdasarkan fungsi teras APP dan laluan pengguna biasa Adalah lebih baik untuk mempunyai data dalam talian untuk menyokong bahagian ini, bukannya hanya memikirkannya ia. Laluan lompat kebanyakan pengguna dalam APP yang diperoleh dengan sokongan data adalah perkara yang perlu kita fokuskan. Di samping itu, kita perlu memberi perhatian kepada laluan yang terdedah kepada ketinggalan yang dipantau dalam data dalam talian semasa proses ujian.

Analisis dan penggunaan data selepas ujian kefasihan, serta pemantauan data kefasihan dalam talian, memerlukan perancangan bersama dan penyiasatan bersama oleh jurutera ujian dan jurutera pembangunan. Artikel ini tidak akan menghuraikannya.

3. Ujian kestabilan

Mengenai bahagian ini, anda boleh bermula dari dua peringkat fasa ujian sebelum keluaran APP dan fasa operasi dalam talian selepas keluaran, dan menjalankan kerja secara berasingan .

Semasa fasa ujian, kami boleh menjalankan ujian kestabilan sekitar ujian Monyet dan semakan kod Pasukan yang layak juga boleh menggunakan alat pengimbasan kod statik pada peringkat ini. Semasa proses ujian Monyet, perhatian harus diberikan kepada peralatan, persekitaran, dan kekerapan pelaksanaan ujian Masalah yang ditemui semasa proses juga harus dianalisis pada tahap tertentu, dan perhatian khusus harus diberikan kepada bahagian yang terdedah kepada masalah. Panduan kod boleh digabungkan dengan modul yang terdedah kepada ranap semasa ujian berfungsi untuk menjalankan panduan penting, menggalakkan pembangunan dan memasangkan pengaturcaraan serta menyemak kemungkinan masalah dalam modul ini. Bagi pengimbasan kod statik, pelajar pembangunan perlu menyelesaikan masalah yang diimbas dan membangunkan tabiat pengekodan yang baik untuk mengelakkan kebocoran masalah berkaitan.

Semasa fasa operasi, kami boleh menjalankan ujian kestabilan di sekitar pelaporan dan analisis data ranap rangkaian luaran. Bahagian ini lebih bergantung kepada jurutera pembangunan untuk menyelesaikannya. Walau bagaimanapun, semasa proses ini, jurutera ujian boleh menganalisis data yang dilaporkan dan mencari beberapa data asas ranap, seperti sistem biasa, model, dsb., untuk meningkatkan dan mengoptimumkan ujian seks harian .

Atas ialah kandungan terperinci Apakah proses ujian APP Android dan masalah biasa?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Label berkaitan:
sumber:yisu.com
Kenyataan Laman Web ini
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Tutorial Popular
Lagi>
Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan