Cara menguji aplikasi saat berinteraksi dengan API menggunakan SoapUI

Banyak yang menggunakan SoapUI untuk menguji baik API itu sendiri maupun aplikasi yang mengakses API. Sebuah alat yang cukup fleksibel yang memungkinkan, misalnya, mengekspor file API angkuh dan menghasilkan layanan Mock berdasarkan itu.

Belum lama ini, di perusahaan kami, saya menghadapi masalah yang sama, tetapi dengan kondisi yang tidak sepele. Data awal: perlu untuk menguji aplikasi server yang menerima tugas sebagai input, selama eksekusi, mengacu pada API, setiap permintaan selanjutnya tergantung pada respons API. Logikanya tertanam dalam aplikasi. Yaitu, semacam kotak hitam tempat Anda perlu menguji banyak pintu keluar dari skrip, ketika hanya ada satu pintu masuk ke skrip.



Di bawah ini saya mengusulkan contoh solusi yang memungkinkannya untuk dengan mudah diintegrasikan ke dalam infrastruktur regresi, serta memiliki margin untuk penskalaan, dalam hal meningkatkan cakupan berbagai skenario dan kompleksitasnya.

Pertama, buat Mock-service di SoapUI. Ini dilakukan dalam beberapa klik:



Sekarang mari kita beralih ke membuat stubs untuk kueri. Karena hanya ada satu entri ke skrip dalam tugas, kami memiliki opsi:

1. gunakan pengenal skrip dan berikan dalam setiap permintaan, dan di masing-masing rintisan menentukan respons tergantung pada pengidentifikasi ini;
2. tentukan terlebih dahulu daftar jawaban untuk setiap rintisan dan simpan dalam variabel global sebelum menjalankan tes.

Opsi pertama dapat digunakan ketika perlu menerima tanggapan dari rintisan untuk beberapa permintaan secara bersamaan. Implementasi mengharuskan aplikasi klien untuk dapat mengirimkan pengidentifikasi khusus dalam setiap permintaan API. Dalam kasus kami, ini praktis mustahil, dan pengujian simultan beberapa skenario tidak diperlukan, sehingga opsi kedua dipilih.

Jadi, untuk menetapkan daftar tanggapan rintisan, kami menjalankan kueri berikut sebelum menjalankan tes:

Post: http://mockserver:8080/setscenario Body: ScenarioId=0&Authentication=200_OK&AutoSystemHome=400_TokenIsMissing… 

Di layanan Mock, kami menambahkan permintaan yang memproses "SetScenario". Itu hanya memiliki dua jawaban: "200_OK" jika permintaan yang masuk diproses dengan benar, dan "400_BadRequest" jika permintaan itu dibuat secara tidak benar:



Dalam skrip, kami mendistribusikan nilai respons untuk stub global untuk setiap stub:

 def reqBody = mockRequest.getRequestContent() //   def reqBodyParams = [:] reqBody.tokenize("&").each //  ,    { param-> def keyAndValue = param.split("=") reqBodyParams[keyAndValue[0]]=keyAndValue[1] } if (reqBodyParams.containsKey('ScenarioId')) // ID     (    );            { //   ,         , “?:” –          : context.mockService.setPropertyValue("ScenarioId", reqBodyParams["ScenarioId"] ?: "0") context.mockService.setPropertyValue("Authentication", reqBodyParams["Authentication"] ?: "200_OK") context.mockService.setPropertyValue("AutoSystemHome", reqBodyParams["AutoSystemHome"] ?: "200_OK") //       … return "200_OK" } else { return "400_BadRequest" } 

Variabel yang ditugaskan dapat dilihat di jendela pengaturan layanan:



Dengan demikian, kami menjelaskan seluruh logika layanan Mock dalam metode ini, dan di rintisan untuk metode API, cukup menulis skrip yang membaca nilai respons dari variabel global:

 Authentication = context.mockService.getPropertyValue("Authentication") return "${Authentication}" 

 AutoSystemHome = context.mockService.getPropertyValue("AutoSystemHome") return "${AutoSystemHome}" 

Jika Anda perlu menambahkan skrip batas waktu, respons tertunda, lalu tambahkan variabel penundaan, misalnya:

 Post: http://mockserver:8080/setscenario Body: ScenarioId=0&Delay=600&Authentication=200_OK &AutoSystemHome=400_TokenIsMissing… 

Dan dalam skrip rintisan kami menambahkan:

 … Authentication = context.mockService.getPropertyValue("Authentication") Delay = context.mockService.getPropertyValue("Delay").toInteger() sleep(Delay) return "${Authentication}" 

Jika perlu untuk mendukung permintaan yang berulang, maka kami mentransfer daftar jawaban:

 Body: Authentication:400_MissingParametersClientId;400_MissingParametersClientId;200_OK 

Dan dalam skrip pemrosesan, tambahkan tokenize dan hapus respons yang sudah dikirim, jika bukan yang terakhir:

 def Authentication = [] Authentication = context.mockService.getPropertyValue("Authentication").tokenize("%3B") if (Authentication.size() > 1) { Authentication.remove(0) Authentication = Authentication.join("%3B") context.mockService.setPropertyValue("Authentication", Authentication) } 

Sebagai hasilnya, kami mendapatkan layanan Mock sederhana, yang mudah untuk dipindahkan antara bangku tes dan lingkungan, karena file proyek adalah file xml. Layanan dimulai segera setelah mengimpor, tanpa pengaturan tambahan (kecuali untuk mengubah alamat dan port server, tentu saja). Saat ini, ini membantu kami menguji aplikasi terlepas dari stabilitas server IPA dan periode waktu yang mungkin tidak dapat diaksesnya.

Apa yang kami rencanakan untuk ditambahkan: mengintegrasikan solusi ini untuk menguji aplikasi sebelum dan selama pengembangan API itu sendiri. Misalnya, ketika deskripsinya sudah siap dalam bentuk file kesombongan, tetapi server sedang dalam proses pengaturan. Siklus pengembangan API dan aplikasi klien tidak selalu bersamaan. Pada titik ini, berguna untuk menguji aplikasi klien yang sedang dikembangkan untuk sesuatu, dan layanan Mock dapat banyak membantu.

UPD: jika Anda memiliki pertanyaan dan komentar bermanfaat.