Geekly articles weekly

Otomatisasi Pengujian Akhir-2-End dari sistem informasi terintegrasi. Bagian 2. Teknis

Dengan artikel ini, kami melanjutkan serangkaian publikasi tentang bagaimana kami mengotomatisasi di salah satu proyek LANIT utama proses otomatis pengujian manual (selanjutnya disebut sebagai autotests) dari sistem informasi besar (selanjutnya disebut sebagai Sistem) dan apa yang datang darinya.

Bagian kedua dari publikasi ini terutama difokuskan pada para pemimpin kelompok otomasi pengujian end-2-end UI dan otomatisasi pengujian terkemuka. Di sini mereka akan menemukan resep khusus untuk organisasi arsitektural kode dan penyebaran, yang mendukung pengembangan paralel-massal kelompok besar pengujian dalam menghadapi variabilitas spesifikasi pengujian yang konstan. Bagian ini berisi daftar lengkap fungsi yang diperlukan untuk pengujian UI dengan beberapa detail implementasi, serta daftar kejutan yang mungkin Anda temui.

Di sini Anda akan menemukan Bagian 1. (Mengapa kita perlu otomatisasi. Organisasi pengembangan dan proses manajemen. Organisasi penggunaan)

Sumber

Stack Arsitektur dan Teknologi


Struktur umum sistem dan lingkungannya - Desain Tingkat Tinggi


Teknologi dan perpustakaan utama yang digunakan dalam proyek:

  • JavaSE8 & maven & JUnit - tumpukan pengembangan;
  • Selenium - perpustakaan untuk mengotomatiskan tindakan browser web;
  • Selenide - add-on untuk Selenium, yang memiliki API elegan yang sangat menyederhanakan interaksi dengan elemen browser dan halaman;
  • Selenoid & GGR - implementasi Selenium Grid dan penyeimbang beban untuk menjalankan pengujian pada server CI + wadah yang telah dikonfigurasi sebelumnya dengan browser;
  • Yandex Allure - untuk laporan di server CI.

Diagram umum dari komponen autotests dan infrastruktur Selenoid ditunjukkan pada diagram di bawah ini, termasuk komentar penjelasan:

Kerangka kerja protes otomatis
Aplikasi untuk otomatisasi regresi antarmuka pengguna.
Dikirim dalam kode sumber. Menggunakan JUnit4

run.properties
File konfigurasi untuk menjalankan Autotests. Menentukan nama kondisional dudukan yang digunakan dan jenis eksekusi - lokal atau melalui wadah eksternal dan variabel lainnya.

Plugin daya pikat
File yang dapat dieksekusi khusus yang diinstal pada server Bamboo.
Membuat laporan pengujian HTML yang dapat diakses melalui server Bamboo.

Laporan pengujian
Tes laporan HTML tersedia melalui server Bamboo.
Ini disimpan di server Bamboo di paket hasil dalam tab terpisah.

Bambu
Menyediakan peluncuran pengujian integrasi dalam mode otomatis dan manual.
Menyimpan laporan pengujian dalam format Allure.

ggr-server
Server-penyeimbang server Selenoid.
Menyediakan penyeimbangan permintaan dari autotests (RemoteWebDriver) ke beberapa contoh server selenium.

Docker
Server Docker untuk menjalankan kontainer dan browser server Selenoid.

Server selenoid
Server Pengujian Jarak Jauh
Menyediakan peluncuran tes dalam wadah buruh pelabuhan khusus menggunakan browser "tanpa kepala".
Melakukan tes dalam mode paralel sesuai dengan jumlah utas simultan yang ditentukan.

Selenoid-ui
Antarmuka pengguna server ke server Selenoid.
Mengizinkan pemantauan kemajuan uji langsung melalui VNC.

Selenoid-webdriver
Wadah khusus dengan browser tanpa kepala untuk menjalankan pengujian jarak jauh.
Disediakan dari repositori Selenoid.

Gitlab
Menyimpan kode sumber aplikasi Autotests.


Skema kerja


Diagram berikut menunjukkan skema umum layanan AutoTests di tingkat Desain Tingkat Tinggi.


Instalasi dan Penempatan


Autotests didasarkan pada empat server, satu di antaranya adalah server eksekusi, dan tiga lainnya menyediakan peluncuran browser tanpa kepala dalam wadah. Kekuatan autotest saat ini menyediakan 60 aliran simultan dan dapat diperluas jika perlu.

Diagram penyebaran saat ini ditunjukkan pada diagram berikut. Secara umum, jika Anda tidak membutuhkan lebih dari 20 browser simultan (pengujian thread), maka sangat mungkin untuk meletakkan semuanya di satu server 12 Kernel + 24 RAM. Kami mulai dengan konfigurasi ini, tetapi ketika persyaratan untuk kekuatan autotest bertambah, kami menemukan secara empiris bahwa konfigurasi yang paling stabil dan hemat biaya adalah server 12 Kernel + 24 RAM “khas” + 24 RAM.

Dalam pengalaman kami, untuk pengujian sistem dengan antarmuka web pada Angular, konfigurasi wadah yang dapat diterima dengan browser harus menjadi lantai kernel + GB memori. Konfigurasi yang lebih kecil memperlambat browser dan bahkan dapat menyebabkan crash yang tidak dapat diidentifikasi.


Struktur dan organisasi kode


Sebelum beralih ke struktur dan organisasi kode, saya akan sekali lagi mencantumkan kebijakan dan batasan yang pada akhirnya menentukan arah pengembangan arsitektur:

  • Sejumlah besar skrip uji ujung ke ujung yang kompleks. Intensitas pembangunan yang tinggi;
  • volatilitas tinggi skenario pengujian (variabilitasnya);
  • kecepatan pengiriman skenario yang terus menerus tinggi (pengembangan dan revisi);
  • kualifikasi awal pengembang autotest;
  • Pengembangan pengembang yang terencana tinggi.

Berdasarkan hal tersebut di atas, driver arsitektur utama adalah sebagai berikut:

  • memastikan kode yang sangat terstruktur untuk kemudahan pembacaan dan pengelolaan;
  • pemisahan dan isolasi maksimum antara implementasi aplikasi tes khusus dan kelas lintas fungsi fungsional umum;
  • pengurangan maksimum dari dependensi yang diperlukan untuk kemudahan perubahan;
  • Penggunaan kembali kode secara wajar di tingkat kelas lintas sektor dengan kemungkinan duplikasi kode di tingkat kelompok uji independen (subsistem fungsional) untuk mengurangi ketergantungan dan menggabungkan konflik di tingkat pengembangan;
  • penolakan kerangka kerja yang kompleks seperti musim semi, aspekJ untuk mengurangi waktu untuk "masuknya" pengembang pemula ke dalam proyek.

Secara umum, pendekatan arsitektural ini memungkinkan untuk mengimplementasikan pengembangan cepat yang independen di bawah kondisi skenario dengan variabilitas tinggi dengan proses yang hampir berkesinambungan untuk memberikan pengujian baru kepada yang produktif. Arsitektur dan sekarang berhasil menahan "pemuatan dan penyempurnaan" meskipun sistem telah menerapkan lebih dari 1.500 skenario bisnis.

Struktur kode umum dan deskripsi dari solusi spesifik utama diberikan di bawah ini.

Struktur kode umum dan pola pengembangan


Struktur umum organisasi kode didasarkan pada arsitektur "berlapis" (lihat diagram), yang umumnya mewarisi Pola Halaman yang direkomendasikan oleh pengembang Selenium. Kami memperluas pola ini dengan menambahkan tingkat elemen web ke pangkalan dan menyoroti tingkat skenario pengujian:

  • tingkat kelas tes
  • tingkat skenario pengujian
  • tingkat halaman web
  • tingkat elemen web
  • kerangka pengujian (ditunjukkan dengan meredupkan diagram).

Setiap tingkat dalam skema ini memiliki serangkaian tanggung jawab dan fungsi tertentu. Perpotongan fungsional antara lapisan atau dependensi tidak sah di antara mereka tidak diizinkan dan merupakan alasan utama untuk mengembalikan komit untuk revisi sebagai bagian dari tinjauan kode sebelum permintaan penggabungan.

Selain itu, struktur "berlapis" diperbaiki dalam pembagian kode ke dalam paket (lihat diagram di bawah).

Skema semacam itu memungkinkan untuk membagi semua subsistem (yang ada secara signifikan lebih banyak daripada dalam skema) antara pengembang dan, sebagai hasilnya, memungkinkan untuk dikembangkan secara mandiri dengan jumlah konflik merger yang praktis menghilang.

Diagram di bawah ini menunjukkan struktur umum implementasi kelas uji dan skema distribusi untuk implementasi paket proyek.



Tes tingkat kelas


Level kelas tes mencakup satu kelas tunggal untuk tes individu tertentu (tes ini dijelaskan dalam sistem manajemen tes sebagai urutan linear dari skrip tes). Kelas tes adalah kelas Junit dengan penjelasan tes @ metode yang sesuai. Secara umum, kelas tes hanya mengimplementasikan satu metode tes.

Setiap kelas uji mewarisi dari kelas dasar yang tugasnya adalah menginisialisasi semua TestRules di RuleChain, yaitu, menginisialisasi infrastruktur uji seperti menginisialisasi driver web, mengatur direktori sementara, dan penangan utilitas keperluan umum lainnya.

Kelas tes bertanggung jawab untuk mengatur pelaksanaan skenario pengujian melalui:

  1. inisialisasi data bisnis uji (tempat uji),
  2. panggilan berurutan dari skrip uji individual (Tindakan) sesuai dengan skenario yang diperlukan dengan transfer data uji yang diinisialisasi kepada mereka dari langkah 2.

Selain itu, pada langkah 2 harus ada urutan linier tanpa cabang atau titik keputusan. Templat implementasi kelas ditunjukkan di bawah ini.

Tingkat uji kasus


Level test case bertanggung jawab untuk implementasi test case spesifik seperti yang dijelaskan. Skenario pengujian dalam konteks ini adalah urutan operasi yang dilakukan oleh pengguna pada sistem melalui interaksi dengan elemen pada halaman web aplikasi.

Tujuan utama dari kelas kasus uji:

  • jalankan urutan tertentu dari skrip uji dengan mengakses metode kelas bawah Halaman, menggunakan

    o mentransmisikan data adegan pengujian,
    o data diterima dari halaman web (dari kelas Halaman);
  • Lakukan tes bisnis yang diperlukan untuk keberhasilan tes dalam konteks model bisnis dan suasana pengujian. Dengan kata lain, kelas test case TIDAK memeriksa markup, ketersediaan dan aksesibilitas elemen, tetapi beroperasi pada model bisnis dari adegan pengujian, sebenarnya melakukan pengujian bisnis.

Kelas uji kasus diatur sebagai "antarmuka fungsional":

  • hanya mengandung satu metode publik "apply" (@ Step), yang:

    o menyediakan implementasi skrip sebagai panggilan ke urutan "tindakan" (metode yang disediakan oleh kelas Halaman),
    o menerima semua objek bisnis yang diperlukan sebagai input, sementara TIDAK MENCIPTAKAN objek bisnis itu sendiri dan TIDAK berinteraksi langsung dengan apa pun selain kelas Halaman;
  • berisi metode pribadi X (@ Langkah), yang masing-masing menerapkan langkah terpisah yang terpisah dari skrip pengujian (seperti yang dijelaskan dalam TMS - Sistem Manajemen Tes);
  • Tidak berinteraksi (tidak memanggil metode) dengan aktivitas lain, bahkan aktivitas subsistem yang sama;
  • tidak menerima input dan tidak beroperasi pada data login. Dengan kata lain, tidak tahu apa-apa tentang peran dari mana ia diluncurkan.

Organisasi kelas ini memungkinkan Anda untuk:

  • Berikan laporan dokumentasi mandiri. Setiap metode sesuai dengan titik tertentu dalam spesifikasi pengujian dan dijelaskan oleh penjelasan daya tarik @ Langkah;
  • menggunakan kembali kelas skrip tes dalam tes yang berbeda, karena skrip tes 1) tidak membuat adegan tes dan 2) tidak tergantung pada login pengguna (operasi login-relogin dilakukan pada level kelas tes) 3), tes tidak tergantung pada kelas lain scripting.

Tingkat halaman web


Level halaman web adalah Pola Halaman klasik untuk pengujian di Selenium. Kelas halaman berisi definisi elemen web tertentu dan serangkaian metode publik untuk melakukan tindakan grup tertentu dalam konteks langkah-langkah kasus pengujian.

Kelas halaman secara langsung bertanggung jawab untuk memasukkan data bisnis ke elemen antarmuka spesifik, bekerja dengan driver web (meluncurkan JS, misalnya) dan, karenanya, menguji format, memeriksa tata letak dan struktur halaman web untuk pemeriksaan dasar seperti: elemen tidak ditemukan / tidak tersedia dan item tidak mengandung nilai yang diperlukan.

Kelas halaman juga tidak termasuk dan tidak dapat mengakses halaman lain dan metode mereka. Juga, kelas halaman tidak melakukan pemeriksaan bisnis, membatasi diri hanya untuk pemeriksaan struktural di tingkat elemen web dalam kasus umum, memberikan "hingga" ke tingkat data "script tes" yang diterima dari halaman.

Tingkat elemen web


Lapisan elemen web mencakup pustaka elemen hingga yang mungkin ada di halaman web. Ini mencakup primitif spesifik dan konglomerat yang lebih kompleks, yang terdiri dari beberapa elemen yang kita sebut widget. Contoh widget dapat berupa konstruksi seperti "pajinator", menu global, berbagai bingkai dan jendela modal, elemen kompleks seperti YandexMap atau pemutar Youtube. Elemen web mengatur komposisi dengan kelas halaman tertentu dan juga tidak tahu apa-apa tentang elemen lain.

Secara umum, jika proyek memiliki semacam identifikasi unik global dari semua elemen antarmuka dengan ID mereka, maka masuk akal untuk mengatur tingkat elemen web sebagai pustaka global dengan permintaan elemen tertentu dengan ID mereka melalui kelas konfigurasi pabrik atau \ xml di pustaka pegas. Tetapi tidak di setiap proyek ini mungkin.

Kerangka pengujian


Konsep pengembangan autotest, seperti yang ditunjukkan pada diagram di atas, didasarkan pada gagasan kerangka kerja di mana seperangkat fungsi sistem disediakan untuk semua autotest - mereka terintegrasi dengan mulus dan memungkinkan pengembang autotest untuk fokus pada masalah spesifik implementasi bisnis kelas uji.

Kerangka kerja ini meliputi blok fungsional berikut:

  • Aturan - inisialisasi dan finalisasi komponen infrastruktur pengujian sebagai inisialisasi WebDriver dan menerima tes video (dijelaskan secara lebih rinci di bawah);
  • WebDriverHandlers - fungsi pembantu untuk bekerja dengan driver web seperti mengeksekusi Java Script atau mengakses log browser. Diimplementasikan sebagai satu set metode statis tanpa-negara;
  • WebElements - pustaka elemen web biasa atau grup mereka, berisi fungsionalitas lintas fungsi yang diperlukan dan perilaku tipikal. Dalam kasus kami, fungsionalitas ini mencakup kemungkinan pemeriksaan penyelesaian operasi asinkron di sisi browser web. Diimplementasikan sebagai ekstensi elemen web dari perpustakaan Selenium dan Selenide.

Inisialisasi lingkungan pengujian. Aturan


Kelas utama untuk semua kelas tes adalah BaseTest, dari mana semua kelas tes diwarisi. Kelas BaseTest mendefinisikan "runner" Junit dari tes dan RuleChain yang digunakan, seperti yang ditunjukkan di bawah ini. Akses dari kelas uji aplikasi ke fungsi yang disediakan oleh kelas aturan dilakukan melalui metode statis kelas aturan menggunakan "utas" pengenal utas sebagai kunci.

Rincian implementasi kelas dasar untuk kerangka kerja autotest akan diperlihatkan di bagian selanjutnya artikel: lihat Bagian 2-1. Implementasi kelas dasar untuk semua tes dan JUnit ChainRule.

Mendokumentasikan hasil melalui laporan Allure.


Untuk laporan terperinci tentang pengujian yang dilakukan, Allure Framework digunakan, terintegrasi dengan Bamboo melalui Allure Plugin . Ini memberikan peluang bagi konsumen pengujian khusus (tim pengujian fungsional) tidak hanya untuk menerima data tentang fakta crash tes tertentu, tetapi juga untuk dengan mudah mengembalikan dan, jika perlu, ulangi tes jatuh secara manual.

Untuk mendokumentasikan laporan pengujian, fungsi berikut digunakan:

  • Anotasi Allure dan Junit untuk menandai laporan dengan langkah-langkah skrip pengujian, serta deskripsi statis metadata untuk pengujian;
  • Lampiran daya pikat untuk dilampirkan ke laporan informasi tambahan seperti tes video, tangkapan layar, hasil diagnostik tambahan dari penyebab kecelakaan, log browser web diunduh ke / dari browser file.

Anotasi Allure dan Junit berikut digunakan untuk menandai laporan.

  • Di tingkat kelas tes:

    o @ Fitur - nama subsistem fungsional yang menjadi tempat pengujian;
    o @ Story - nama kasus uji tertentu;
    o @ Pemilik - nama pengembang yang terakhir kali melakukan perubahan pada tes;
    o @ TmsLink - tautan ke deskripsi tes di “sistem manajemen pengujian” yang digunakan.
  • Pada tingkat metode pengujian (@ Tes) dari kelas tes:

    o @ DisplayName - nama lengkap skrip uji. Ini berbeda dari @ Story karena memungkinkan Anda untuk berbagi skrip yang sama, yang hanya berbeda dalam komposisi adegan pengujian;
  • Pada tingkat metode yang sesuai dengan langkah-langkah spesifik dari skenario pengujian:

    o @ Step - nama yang berarti dari langkah uji yang mencerminkan esensi bisnis dari apa yang terjadi.

Penamaan langkah-langkah pengujian melalui @ Langkah memungkinkan Anda membuat laporan terperinci yang sepenuhnya mengulangi semua langkah dan item yang dijelaskan dalam skenario pengujian. Hal ini memungkinkan pengguna autotest untuk dengan mudah melacak jalannya skenario pengujian dan membantu menentukan titik kejadian.

Secara umum, menggunakan Allure Framework terbukti sangat berguna dan mudah, dengan pengecualian beberapa fitur yang terkait dengan sejumlah besar data yang dihasilkan dalam kasus kami untuk sejumlah besar skrip tes rumit yang panjang (dijelaskan nanti di bagian "Retrospektif").

Apa yang mungkin telah dilakukan secara berbeda segera? Gunakan Spring Framework


Terlepas dari kenyataan bahwa ketika menerapkan autotest, kami sengaja menolak untuk menggunakan Spring Core, secara umum, saya menganggap penggunaannya dibenarkan dan berfungsi. Prototipe yang diimplementasikan menunjukkan bahwa menggunakan Spring Core berfungsi untuk tugas-tugas berikut (walaupun tentu saja kami tidak mengujinya sepenuhnya):

  • inisialisasi adegan uji;
  • inisialisasi halaman web dan elemen.

Satu-satunya fitur adalah kebutuhan untuk menggunakan konteks lingkup "default" dari tingkat prototipe.

Inisialisasi adegan uji. Dalam autotest, adegan tes diinisialisasi dengan metode klasik untuk membuat instance kelas langsung di kelas tes melalui pabrik objek atau objek baru. Di sini cukup masuk akal untuk menggunakan inisialisasi baik melalui kelas konfigurasi, atau melalui file xml atau file eksternal. Keuntungannya adalah sebagai berikut: ini 1) menyederhanakan kode ulasan, karena perubahan pada adegan pengujian tidak lagi berlaku untuk kelas-kelas utama, 2) memungkinkan Anda untuk menghubungkan adegan pengujian yang berbeda untuk tegakan yang berbeda atau kondisi lainnya. Sekarang poin 2 tidak digunakan bersama kami.

Inisialisasi halaman web dan elemen. Injeksi kelas halaman web dan elemen web bekerja berdasarkan malas inisialisasi malas elemen web selenide.

Dengan demikian, menjadi mungkin untuk membuat perpustakaan elemen web dan halaman sesuai dengan spesifikasi global tertentu dari antarmuka pengguna dan menerima tautan kode ke elemen-elemen ini bukan oleh path dan id absolut, tetapi oleh id proyek sesuai dengan spesifikasi.

Saya harus segera mengatakan bahwa saya tidak menguji ini dengan sangat hati-hati, bahkan saya membatasi diri saya pada implementasi uji “halaman” dari login dan “info” halaman pengguna pada prinsip ini.

Retrospektif. Kejutan


Di sini saya menggambarkan kejutan tak terduga yang muncul selama pengembangan proyek, ditambah beberapa pertimbangan tentang apa yang bisa dilakukan dengan lebih baik jika “tidak”.

Markup front-end ramah selenium (Angular)


Salah satu kejutan paling serius yang kami temui adalah tata letak halaman "mengambang", yang mengarah pada fakta bahwa setelah memperbarui aplikasi Angular, tes jatuh karena Selenium tidak dapat menemukan elemen karena ID mereka (id, kelas atau ng-model) atau path (untuk XPath). Hal ini menyebabkan ketidakstabilan tes dan ketidakjelasan alasan jatuh.

Sayangnya, masalah ini pada umumnya tidak dapat diselesaikan. Kami mengelak dengan langkah-langkah organisasi: 1) pada awal pengujian kandidat baru untuk rilis, semua pengembang autotest fokus pada penghapusan dan penyempurnaan cepat dalam hal mengedit nilai-nilai pencari elemen web; 2) pada akhirnya, kami datang untuk menggunakan XPath relatif, yang, sayangnya, tidak meningkatkan kinerja sama sekali.

– , - .

«download»


«» :


.

. , , . , .


. , «» . , , , , , - ( ) - .

, , , . .

, . «» , , , .


. , . (~ 1000 ) 6 .

Selenoid-ggr . junit 20 ( Selenoid-) 60 ( ), . «» , 60 .

, , , 3-4 , preQA-. . , , AWS c , Selenoid- , AWS Selenoid, in/out .
, , E2E . preQA.

«»


, 60 60 .

«Timeline» « » ( ). , .


Ada dua alasan. "Steker" awal disebabkan oleh seruan massa ke layanan otorisasi dan akun pribadi. Semua browser secara bersamaan mulai masuk dan membebani layanan di sisi bangku tes.

"Kolom" berikutnya ternyata terkait dengan fakta bahwa kelas uji terletak di folder oleh subsistem dan junit menjalankannya hampir secara bersamaan, sehingga memuat subsistem fungsional spesifik dudukan dan melampaui batas kinerja konfigurasi dudukan.

Kami memecahkan masalah pertama dengan membungkus metode skrip login di balancer, yang membatasi jumlah maksimum operasi login ke konstanta yang diberikan.

@Step(":    ")     public void apply(User user) {     try {         LoadCounter.get(); //   .              try {                 applyLogin(user); //          } catch (Throwable t) {             throw t; //                   } finally {             LoadCounter.release(); //            }         } catch (LoadCounterException e) { //                  throw new StandRuntimeException("Can not get loadcounter for Login action.", e);     }     }

Masalah kedua diselesaikan dengan menyalakan opsi uji coba acak, yang dimiliki plugin junit maven.

    <plugin>               <groupId>org.apache.maven.plugins</groupId>                <artifactId>maven-surefire-plugin</artifactId>         <version>….</version>            <configuration>                <!-- Defines the order the tests will be run in. Supported values are "alphabetical",                     "reversealphabetical", "random","hourly", "failedfirst", "balanced" and "filesystem". -->                <runOrder>random</runOrder>                …

Harus dicatat bahwa masalah ini terkait dengan fakta bahwa kami tidak memiliki kesempatan untuk meningkatkan kinerja bangku tes karena sumber daya yang terbatas, dan juga karena sumber daya ini akan menganggur sebagian besar waktu.

Secara umum, ternyata sistem swa-uji E2E web-UI internal dapat digunakan untuk pengujian beban pengganti dan penyaringan kinerja dan stabilitas sistem yang diuji secara keseluruhan.

Beban tinggi di server Bamboo dan penyimpanannya


Jika Anda memiliki banyak tes dengan sejumlah besar operasi (misalnya, jumlah operasi yang masuk melalui Langkah adalah 200 hingga 2000 dengan jumlah tes sekitar 1300), maka volume laporan Allure menjadi lebih dari signifikan. Jika Anda menambahkan di sini juga berbagai lampiran seperti tangkapan layar dan file yang diunggah / diunggah, maka volumenya sudah mencapai ratusan megabita. Misalnya, sekarang untuk regresi setiap malam dari 900 tes, jumlah data yang diunggah ke Bamboo Allure saja sekitar 600 MB.

Jelas bahwa para insinyur DevOps tidak antusias tentang intensitas konsumsi ruang disk dan secara aktif menyatakan ketidakpuasan, terutama sehubungan dengan kebutuhan untuk menyimpan data selama setidaknya satu tahun.

Kami melihat jalan keluar dari situasi ini dengan menggunakan server eksternal untuk menyimpan dan memproses laporan, misalnya, seperti Allure Enterprise. Server ini sudah dibayar, tetapi memungkinkan kami untuk menyelesaikan masalah ini. Kami saat ini sedang mengerjakan pengujian dan mengintegrasikan Allure Enterprise ke dalam proyek kami.

Untuk dilanjutkan


Pada artikel berikutnya, kolega saya akan melanjutkan cerita dan menggambarkan sejarah yang menarik dari pengujian layanan web menggunakan Smartbear SoapUI Pro. Kekuatan dua insinyur otomasi berhasil mengotomatisasi sekitar 500 skrip pengujian, untuk tujuan ini, saya harus menerapkan kerangka kerja tambahan yang secara signifikan memperluas fungsi fungsi SOAP UI standar, tetapi lebih pada hal itu nanti.

Artikel ini ditulis bekerja sama dengan manajer proyek dan pemilik produk kotalesssk .

Bagian 1. Organisasi dan manajerial. Kenapa kita perlu otomatisasi. Organisasi proses pengembangan dan manajemen. Organisasi penggunaan
Bagian 2. Teknis. Arsitektur dan tumpukan teknis. Detail implementasi dan kejutan teknis
Bagian 2-1. Implementasi kelas dasar untuk semua tes dan JUnit ChainRule
Bagian 2-2. Implementasi proses mengunggah file dari wadah dengan browser ke kerangka uji. Cari nama file yang diunduh oleh browser

Kami memiliki lowongan, datanglah ke kami!

Source: https://habr.com/ru/post/id477044/

More articles:


All Articles