Nama saya Dasha, dan saya seorang insinyur pengujian selama 4 tahun. Ini berarti bahwa tugas-tugas menarik yang Anda sukai dengan kegembiraan "Juni" dalam mencari solusi baru semakin sedikit. Proyek, produksi, dan kasing yang sama! Tidak, saya tidak bermain seperti itu! Pengujian selalu merupakan tantangan, dan keinginan untuk mengubah dunia menjadi lebih baik tidak boleh mati. Dan begitu saya menemukan masalah ini: Anda perlu menguji bot obrolan sederhana di Telegram.
Latar belakang: tidak nyaman bagi pelanggan kami untuk melakukan tindakan rutin seperti yang disepakati, karena pada awalnya ia mengirim tautan ke perhitungan yang diperlukan, dan setiap kali ia membuka indikator yang diperlukan melalui browser untuk ditinjau, yang menambah waktu pengoperasian. Kami mengusulkan mentransfer logika ke bot obrolan untuk mengurangi waktu pengambilan keputusan dan membuat hidup lebih mudah bagi karyawan klien.
Untuk merayakan, saya memutuskan untuk mendekati masalah ini dengan semua tanggung jawab, untuk menunjukkan kecerdikan maksimal, dan hanya menikmati pekerjaan.
Pengujian dilakukan dengan menggunakan metode kotak hitam dan abu-abu. Karena itu, Anda dapat menggunakan semua imajinasi Anda untuk membuat skrip khusus.
Pernyataan: layanan pihak ketiga mengirimkan permintaan SOAP, yang harus kami proses dan simpan dalam database, dan kemudian membuat gambar dengan parameter dalam bentuk tabel dan mengirimkannya ke pengguna untuk persetujuan. Sebagai tanggapan, sistem menerima konfirmasi atau penolakan bersama dengan komentar pada keputusan.
Ada deskripsi, pensil dipertajam, daftar periksa disiapkan, kue semua dimakan. Saya siap memulai! Setiap detik muncul pertanyaan baru ...
Berhenti, berhenti, berhenti! Tetap tenang dan mulai pengujian. Jadi, untuk:
1. Dalam bentuk apa untuk menampilkan tanggal? Selalu ada masalah dengan tanggal: format, zona waktu, dll.Kami tidak dapat memperoleh persyaratan yang tepat dari sistem eksternal, jadi kami memutuskan untuk menampilkan tanggal dalam bentuk yang semula diterima. Sangat sulit untuk memprediksi dalam format apa tanggal akan diterima (bahkan bola ajaib tidak bisa melakukan ini).
2. Seberapa besar kualitas gambar yang akan diderita jika pesan tersebut mengandung banyak informasi?Kualitas gambar tergantung pada jumlah informasi yang diterima dari luar. Telegram sendiri mengurangi kualitas gambar. Jika ada sejumlah besar informasi, maka dengan mentransmisikannya dengan dokumen, kita akan mendapatkan tabel dalam bentuk yang dapat dibaca, tetapi kemudian pengguna perlu menggunakan aplikasi pihak ketiga untuk membuka file PDF yang dihasilkan. Ini akan menyulitkan kehidupan, dan tidak ada yang suka kesulitan (tapi semua orang suka kue!). Pada saat yang sama, jika Anda mengirim gambar, itu hanya akan dapat dibaca ketika sedikit data telah diterima, tetapi kemudian pengguna dapat menggunakan fungsi Telegram itu sendiri untuk melihat gambar. Kami memutuskan bahwa lebih baik meninggalkan layar dengan gambar, karena lebih nyaman untuk bekerja dengannya, dan tidak mungkin mendapatkan banyak informasi.
3. Bagaimana seharusnya sistem merespons jika tidak ada komentar yang diterima mengenai keputusan tersebut?Semuanya ternyata sangat sederhana di sini: kami menyimpan hasil keputusan yang dikirim. Dan atas permintaan kedua, mereka memberi informasi kepada pengguna tentang perlunya mengisi komentar tentang keputusan tersebut.
4. Bagaimana seharusnya pengguna memahami solusi apa yang diperlukan untuk meninggalkan komentar jika beberapa permintaan untuk persetujuan berturut-turut telah diterima?Di sini fungsi diimplementasikan sehingga pesan yang meminta komentar datang dalam bentuk respons terhadap pesan dengan informasi dasar tentang solusi.
5. Apa yang harus dilakukan sistem jika pengguna belum membuat keputusan tentang pesan lama, tetapi yang baru telah diterima?Dalam hal ini, sistem kami mengirim ulang pesan yang sama untuk disetujui (tidak ada yang berani mengabaikan kami!).
6. Berapa banyak pesan yang dapat kami terima?Untuk menjawab pertanyaan ini, saya memutuskan untuk membuat Test Suit sederhana di SOAP UI. Pilihan jatuh pada aplikasi ini, karena memiliki cakupan yang luas (mencakup verifikasi layanan web, simulasi, pengujian fungsional, pengujian beban, dll.).
Saya tidak akan memberi tahu Anda cara membuat Test Suit sederhana, karena mereka sudah cukup menulis tentang ini, saya hanya ingin menggambarkan masalah dan solusi saya.
Tangkapan utama adalah bahwa untuk setiap permintaan baru, pengidentifikasi baru harus dibuat, dan nilai yang dihasilkan ini digunakan kembali dalam XML yang sama.
Solusinya ditemukan:
Dalam kasus uji, Properti dibuat dengan atribut ID_Calc.
Kemudian, di tab skrip pengaturan, tempelkan skrip:
testCase.setPropertyValue ("ID_Calc", java.util.Random () baru. nextInt (99999) .toString ())
Setelah itu, dalam permintaan itu sendiri, di tag tempat pengenal digunakan, perlu untuk menulis:
$ {# TestCase # ID}
Dengan demikian, setiap permintaan memiliki pengidentifikasi unik, tetapi dalam kerangka pesan terpisah, pengidentifikasi itu sama.
Pekerjaan pengembangan dan pengujian dilakukan dengan sangat cepat dan harmonis, jadi kami berhasil mencapai hasilnya sesegera mungkin. Revisi segera diserahkan kepada pelanggan, dan dia puas.
Bahkan dari tugas yang paling sederhana dan paling biasa, Anda dapat melakukan pencarian yang keren, bagian yang bisa dibanggakan! Nah, jika Anda bosan, tetapi menginginkan perasaan yang jelas, temukan saja masalah pada proyek Anda dan selesaikan dengan cara yang tidak biasa :)
Semoga beruntung