Geekly articles weekly

IBM System i (alias AS / 400) - Bagaimana kami melakukan tes otomatis aplikasi layar hijau

Hai Nama saya Anton Vorobyov, saya bertanggung jawab di Alfa Bank untuk pengembangan aplikasi untuk sistem perbankan terpusat.

Dalam posting ini, saya akan memberi tahu Anda tentang apa aplikasi layar hijau, mengapa mereka diperlukan dan bagaimana kami melakukan autotest untuk mereka dengan menulis solusi kami sendiri untuk ini, yang memungkinkan kami untuk mempercepat autotests sebanyak 11 kali.



Platform AS / 400 (Sistem Aplikasi / 400) lahir pada tahun 1988. OS pertama untuk platform ini adalah OS / 400, yang kemudian diubah namanya menjadi i5 / OS dan bahkan kemudian menjadi IBM i. Belum lama berselang, dia merayakan hari ulang tahunnya yang ketiga puluh.

Terjun ke dunia pengembangan di bawah sistem operasi IBM i, Anda memahami bahwa ini sebenarnya bukan "warisan" dalam arti kata klasik. Ini adalah lingkungan yang berbeda dan sangat berbeda, yang sedikit mirip dengan sistem Windows atau Unix yang biasa. Tugas utama OS ini adalah menjadi seproduktif mungkin pada peralatan yang digunakannya, dan tidak nyaman bagi pengguna.

IMHO, OS ini dapat membuat Anda gila tentang betapa tidak efektifnya pendekatan yang biasa digunakan untuk menulis kode C ++ tidak efektif di atasnya (hingga puluhan kali kehilangan CPU), bahwa beberapa antipemut yang ditunjukkan dalam buku teks adalah praktik terbaik dari kode yang efektif, dan sumber dengan tanggal penulisan untuk 1978 tidak hanya berkumpul tanpa masalah, tetapi juga bekerja seperti yang dirancang! Semua ini membuat kami memperhatikan pendekatan modern untuk pengembangan perangkat lunak.

Pendahuluan


Masalah peningkatan kualitas perangkat lunak dalam pengembangan menggairahkan pikiran masing-masing tim pengembangan. Salah satu tim kredit kami, yang tugasnya mengembangkan dan mengembangkan bagian belakang modul untuk sistem perbankan otomatis Misys Equation, belum melewati momen ini juga. Keunikan dari ABS ini adalah:

  • versi pertama dari ABS bekerja di bawah AS / 400 pendahulunya - platform IBM System / 38 (muncul pada tahun 1978) di bawah CPF OS - “Control Program Facility”;
  • Ini telah dikembangkan sejak tahun 70-an abad kedua puluh, dan Anda dapat menemukan kode yang ditulis sebelum kelahiran Anda (banyak kode lama);
  • fitur bekerja dengan ABS adalah karena integrasi yang erat dengan IBM i, dan karena kompatibilitas mundur yang besar dari yang terakhir, tampaknya Anda bekerja sebagai arkeolog dalam penggalian Piramida Besar.



IBM i (logo)

Pengembangan aplikasi untuk ABS ini (opsi ABS) dilakukan sesuai dengan standar paket pengembang ITP Misys, Paket Teknis Integrator, yang menetapkan bahwa opsi tersebut harus terdiri dari program interaktif untuk interaksi terminal dengan pengguna akhir dan mengimplementasikan API menggunakan antarmuka yang dipasang untuk eksekusi latar belakang. .

Program interaktif semacam itu yang dikembangkan di bawah sistem operasi IBM i secara historis disebut aplikasi layar hijau dan merupakan satu-satunya UI yang berinteraksi dengan pengguna ABS ini.

Apa itu aplikasi layar hijau?


Jawaban sederhana adalah aplikasi yang terlihat seperti ini:



Atau lebih :



Mengapa aplikasi layar hijau?


Secara historis, satu-satunya aplikasi interaktif yang berjalan pada sistem rendah dan menengah keluarga AS / 400 dan mainframe IBM lainnya yang memungkinkan Anda untuk meminta input pengguna adalah aplikasi layar hijau. Instalasi, administrasi, konfigurasi dan pengembangan pada sistem operasi IBM i (dan pendahulunya i5 / OS dan AS400) dilakukan (dan masih dilakukan di suatu tempat) secara eksklusif menggunakan aplikasi layar hijau.

Gambar aplikasi layar hijau memiliki dua ukuran - 24x80 dan 27x132 karakter dan 16 warna yang memungkinkan. Dalam skala ini, sebagian besar pekerjaan pengembang dan pengguna sistem operasi ini dilakukan.

Ukuran layar tersebut adalah hasil dari evolusi "workstation" yang terhubung ke nenek moyang AS400 dari segmen kelas bawah dan menengah komputer bisnis IBM System / 32, System / 34, System / 36 dan System / 38. Stasiun kerja ini disebut terminal dan terdiri dari layar dalam kotak logam dengan keyboard dan peralatan tambahan dalam bentuk pena cahaya. Pada awalnya, hanya dua warna layar yang didukung - hijau dan hijau terang, itulah sebabnya ungkapan "aplikasi layar hijau" (aplikasi layar hijau dalam literatur bahasa Inggris) berjalan. Pada 1970-an, jumlah warna yang didukung meningkat menjadi 16.


5251 Model Stasiun Display 11

Opsi terminal yang paling umum adalah 5251 Stasiun Layar Model 1 (960 karakter pada layar) dan Model 11 (1920 karakter pada layar) dengan dimensi Lebar / Kedalaman / Tinggi masing-masing sebesar 530/400/400 mm, dan berat 34 kg. Resolusi layar Model 1 adalah 12x80, Model 11 - 24x80. Terminal terhubung langsung ke sistem host.

Terminal 5251 Display Station Model 2 (960 karakter pada layar) dan Model 12 (1920 karakter pada layar) dengan dimensi besar dan berat 45 kg juga cukup umum. Mereka dibedakan dari Model 1 dan Model 11 dengan kemungkinan meneruskan koneksi hulu melalui diri mereka ke mesin host dari klien yang lebih murah dalam bentuk Model 1 (atau 11) terminal dengan printer desktop atau printer lantai terpisah. Dengan demikian, model 2 dan 12 bertindak sebagai hub, proksi sambungan ke host dari perangkat yang memerlukan koneksi langsung ke mesin host, dan harganya jauh lebih mahal.

Terminal seri 5252 Dual Display Station juga akan tampak tidak biasa bagi orang awam modern.


Gambar promosi dari brosur IBM System / 38 Equipment and Programs (5252 Dual Display Station)

Harga satu terminal kit dengan printer yang terhubung dapat mencapai beberapa ribu dolar AS.

Terminal dihubungkan melalui kabel twinaxial ke mesin host dengan topologi bus dalam mode half-duplex dengan kecepatan transmisi hingga 1 Mbps. Jumlah maksimum terminal yang didukung oleh twinaxial hingga 6 terminal, dan terminal yang paling jauh dari host harus berada pada jarak tidak lebih dari 1500 meter.

Jumlah setiap terminal diatur selama pemasangannya oleh tiga sakelar, sehingga alamat unik ditentukan di dalam bus. Di hadapan jaringan koaksial yang ada, dimungkinkan untuk menggunakan adaptor dari kabel twinaxial ke kabel koaksial dan satu set terminasi kabel yang sesuai untuk crimping. Dengan skema ini, dimungkinkan untuk menghubungkan hanya dua perangkat di bus dengan panjang segmen maksimum hingga 30 meter. Jumlah total perangkat yang terhubung bervariasi dari selusin hingga beberapa lusin, tergantung pada modelnya.

Dengan pengembangan sistem Desktop dan jaringan akses, terminal besar digantikan oleh workstation, di mana berbagai kartu ekspansi dari perusahaan pihak ketiga digunakan sebagai sarana akses ke mesin host, mendukung koneksi langsung melalui twinaxial. Setelah IBM mengembangkan teknologi Token Ring pada tahun 1984, solusi perangkat lunak untuk mengakses mesin, termasuk melalui antarmuka ini, muncul.


5250 adaptor ke bus ISA (produsen tidak diketahui)


Kartu Adaptor Blackbox 5250 (PC470C, PC471C, PC472C, PC473C, PC478C)

Emulator untuk MS-DOS dan MS Windows muncul baik dari IBM maupun dari produsen pihak ketiga, termasuk implementasi OpenSource (misalnya, tn5250j.sourceforge.net) .Pada pertengahan 90-an, tumpukan TCP / IP masuk ke dunia pertengahan -range dan mesin bisnis low-end. Untuk mendukung akses host melalui protokol baru, IBM sedang mengembangkan emulator terminal seri 5250.

Untuk membuat protokol host, IBM sedang mengembangkan
Ekstensi protokol Telnet (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), secara kolektif disebut sebagai Telnet5250 (TN5250), yang menggambarkan proses penerimaan dan pengiriman stream 5250 aliran data (5250 aliran data) melalui protokol Telnet standar.


IBM Client Access / 400 untuk Pemasang Windows 3.1

Apa yang istimewa tentang IBM 5250?


Fitur terminal IBM 5250 (dan sesuai dengan itu, protokol TN5250) adalah orientasi bloknya, berbeda dengan terminal * nix biasa, yang berorientasi simbol . Ini berarti bahwa 5250 data mengalir dimana host berkomunikasi dengan terminal ditransmisikan oleh blok data, dan simbol terpisah di dalamnya tanpa konteks blok yang ditransmisikan tidak masuk akal.

Sebagai contoh, mesin host mentransmisikan ke terminal suatu blok data yang berisi informasi statis yang ditampilkan pada layar bersama dengan atribut dan koordinat bidang input dan indikasi offset di blok ini, di mana untuk menulis hasil input pengguna ke bidang. Setelah itu, mesin host mengharapkan pesan dari terminal dan tidak berpartisipasi dalam proses input pengguna.


Layar login untuk IBM saya host RZKH.de (pub400.com)

Selanjutnya, tugas terminal emulator adalah menginterpretasikan blok data dari mesin dan membentuk layar input untuk pengguna, di mana ia diberi kesempatan untuk memasukkan informasi apa pun ke dalam bidang yang diizinkan. Selain itu, tugas terminal emulator mencakup reaksi terhadap tindakan pengguna. Tombol F1-F24 (F13-F24 disimulasikan melalui SHIFT + Fx), Enter, Home, End, PageUp, PageDn, dan beberapa tombol khusus lainnya yang tidak tersedia pada keyboard modern dianggap sebagai kunci host. Ini berarti bahwa dengan menekan tombol ini, buffer aliran dengan informasi dari bidang input dan posisi kursor pada layar, yang sebelumnya diisi dengan emulator terminal, akan dikirim ke host untuk diproses.


WIreshark 5250 upaya masuk Stream Data dibuang di pub400.com

Host menerima buffer, mem-parsingnya, dan hasil input ditransmisikan ke program yang meminta reaksi pengguna untuk validasi data lebih lanjut dan aplikasi terus bekerja, sementara aplikasi menerima kode dari kunci host yang ditekan.

Mengapa ada autotest di sini?


Kami berpikir tentang mengotomatiskan pengujian manual aplikasi layar hijau ketika kami dihadapkan dengan kebutuhan untuk menguji ratusan layar dari modul yang dikembangkan, di mana hingga delapan puluh pemeriksaan bisnis yang berbeda (validasi) dapat terjadi pada satu layar.

Rasa sakit khusus tim adalah hampir tidak ada yang lengkap untuk 2017 alat pengujian otomatis layar hijau, kecuali untuk solusi UIPath berpemilik. Bahkan saat ini tidak ada banyak solusi serupa, penulis tahu Automate from HelpSystems dan ekstensi JMeter untuk BlazeMeter (saya akan senang menerima informasi tentang produk serupa lainnya).

Penelitian pertama tentang masalah tersebut


Emulator standar terminal TN5250 yang dipasang di tempat kerja di bank adalah IBM Personal Communications for Windows 6.0 (PCOMM 6.0). Kolega menemukan bahwa produk ini memiliki cara reguler untuk mengotomatisasi manajemennya dalam bentuk API yang beragam, yaitu:

  1. Antarmuka Program Aplikasi Bahasa (HLLAPI) tingkat tinggi;
  2. HLLAPI yang ditingkatkan;
  3. Windows HLLAPI
  4. Host Access Client Library (HACL).

Tiga antarmuka pertama adalah yang tertua dan telah didukung sejak DOS dan versi 16-bit Windows. Bekerja pada antarmuka EHLLAPI diimplementasikan dengan memanggil fungsi tunggal sesuai dengan prototipe berikut:

long hllapi (LPWORD, LPSTR, LPWORD, LPWORD);

di mana parameter pertama adalah penunjuk ke nomor numerik dari fungsi yang dieksekusi, dua lainnya adalah argumennya konteks-sensitif terhadap fungsi yang dipanggil, dan yang terakhir adalah hasil dari fungsi. Artinya, untuk meminta status koneksi 'A' (sesi dalam emulator diberi nomor dengan huruf Latin dari rentang dari 'A' hingga 'Z'), Anda harus menjalankan kode berikut (diambil dari dokumentasi IBM):

  #include "hapi_c.h" struct HLDQuerySessionStatus QueryData; int Func, Len, Rc; long Rc; memset(QueryData, 0, sizeof(QueryData)); // Init buffer QueryData.qsst_shortname = 'A'; // Session to query Func = HA_QUERY_SESSION_STATUS; // Function number Len = sizeof(QueryData); // Len of buffer Rc = 0; // Unused on input hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI if (Rc != 0) { // Check return code // ...Error handling }

Jumlah fungsi yang tersedia untuk menelepon dengan cara ini adalah sekitar 60.

Antarmuka WinHLLAPI sedikit memperluas fungsionalitas ini dengan beberapa fungsi tambahan yang memungkinkan mendaftarkan fungsi panggilan balik untuk panggilan asinkron untuk memberi tahu tentang peristiwa membangun koneksi dengan host, memutuskan koneksi dari host, mengubah data pada layar terminal, dll.

Antarmuka Host Access Client Library (HACL) tampaknya lebih ramah pengguna, karena, berbeda dengan memanggil "fungsi dengan nama yang sama", varian hierarki kelas berorientasi objek disediakan yang sepenuhnya meniru tindakan pengguna apa pun.


HACL Emulator Class Library Class Hierarchy (C ++)

Ada implementasi HACL untuk C ++, Java, LotusScript dan server otomatisasi COM untuk Windows (nyaman untuk Visual Basic dan .NET).

Prototipe pertama


Karena kompleksitas yang sangat besar dari protokol aliran data 5250 dan informasi yang sangat langka tentang perangkat internal dengan tautan ke literatur berbayar tertutup dari IBM, menjadi jelas bahwa mengembangkan emulator Anda sendiri sangat tidak sepele dan memakan waktu. Dalam hal ini, muncul ide untuk menggunakan lapisan middleware yang akan memungkinkan Anda untuk mengontrol emulator terminal dalam fungsionalitas minimum yang diperlukan, khususnya "memasukkan nilai di lapangan", "membandingkan bagian layar dengan standar" atau "tekan tombol host F22".

Kolega yang sebelumnya menggunakan antarmuka HACL mengklaim (dan pencarian di StackOverflow dikonfirmasi) bahwa objek COM memiliki masalah stabilitas dan bisa hang setelah sejumlah perintah dieksekusi. Hanya me-restart proses server otomatisasi yang membantu. Analisis cepat dari versi Java menunjukkan bahwa Wrapper digunakan melalui antarmuka C ++ melalui JNI. Oleh karena itu, pilihan jatuh pada antarmuka C ++. File header dan file .lib yang sesuai tersedia di direktori instalasi Personal Communications For Windows itu sendiri.

Prototipe pertama didasarkan pada Qt5, di mana dimungkinkan untuk mengeksekusi kode JavaScript melalui QtScript. Dalam lingkungan skrip yang dapat dieksekusi, sebuah objek didaftarkan dengan sejumlah kecil metode yang memungkinkan mengeksekusi perintah dalam emulator terminal seolah-olah sedang dieksekusi oleh seseorang (memasuki bidang, menekan tombol host, menunggu garis muncul di layar). Kami mendemonstrasikan "demo" langsung, di mana kami membuat skrip kasus pengguna untuk meluncurkan aplikasi layar hijau dari ABS Equation dengan uji reaksi aplikasi terhadap input yang salah ke bidang. Demonstrasi menunjukkan bahwa prototipe berhasil dan kita dapat melanjutkan.

Penampilan tetangga


Seiring dengan demonstrasi prototipe pertama, rekan-rekan dari departemen lain mengumpulkan sekelompok modul Ruby + Mentimun + Quick3270 + Ruby ( cheeze / te3270 ). Opsi yang diajukan menggunakan modul Ruby yang berinteraksi dengan emulator terminal DN32 Computing Quick3270 melalui objek COM khusus (tidak kompatibel dengan antarmuka HACL). Itu adalah solusi lengkap untuk aplikasi pengujian otomatis layar hijau bergaya BDD, dengan beberapa langkah yang telah dijelaskan sebelumnya. Namun, dalam solusi yang diusulkan, kami khawatir dengan yang berikut:

  1. Kami menggunakan emulator berbayar pihak ketiga bukan dari IBM (semua emulator bekerja sedikit berbeda, tetapi kami perlu memeriksa pekerjaan pada yang standar yang digunakan di bank, harga kesalahan sangat tinggi);
  2. Implementasi langkah-langkah Cucumber untuk Quick3270 menggunakan sejumlah besar tidur untuk menunggu respons dari mesin;
  3. Performa Quick3270 yang sangat buruk melalui antarmuka otomatisasi (bekerja dengan HACL dalam prototipe melalui antarmuka C ++ tampak jauh lebih dinamis).


Emulator terminal Quick3270

Berdasarkan prototipe, kami memutuskan untuk mencoba menerapkan server otomasi kami sendiri untuk menyambungkan Mentimun ke Komunikasi Pribadi untuk Windows dan merancang langkah-langkah sehingga waktu henti antar tindakan pada layar emulator minimal.

Penyimpangan liris . Terlepas dari kenyataan bahwa ada sejumlah besar masalah teknis di sekitar "warisan" yang seharusnya IBM, yang, tampaknya, harus sudah diselesaikan untuk sistem tingkat bisnis menengah dan perusahaan, relevansi mengadaptasi dan mentransfer solusi teknis yang ada sangat tinggi hanya karena ketidakhadiran mereka di platform. Seringkali ketidakhadiran terhubung dengan fitur-fitur OS ini, yang pada dasarnya berbeda dari * nix modern, Windows atau MacOS X, yang memerlukan optimalisasi perangkat lunak yang signifikan untuk tumpukan ini.

Keputusan sendiri


Sebagai solusi kami sendiri, kami menciptakan server otomasi sebagai pengembangan dari prototipe yang ditunjukkan sebelumnya. Server ini menjalankan perintah untuk mengotomatisasi interaksi dari konsumen melalui server RPC (Qt5 WebSocket). Ini berinteraksi dengan Komunikasi Pribadi untuk Windows, yang merupakan bagian dari gambar sistem operasi Windows perusahaan, dan memungkinkan Anda untuk:

  • memulai / menghentikan sesi terminal emulator;
  • Lakukan Screen Scraping Green Screen;
  • mencari kolom input di layar;
  • mengontrol kursor dan mensimulasikan penekanan tombol (termasuk host);
  • dan lainnya


Mulai Server Otomasi

Namun, untuk semua kelebihan API HACL, ia memiliki satu kelemahan - ia tidak tahu cara bekerja dengan DB2 untuk i DBMS yang dibangun ke dalam OS dan tidak memungkinkan menjalankan perintah yang penting untuk membangun lingkungan tiruan di mana skrip uji akan dieksekusi. Jika klien DB2 untuk Ruby ada dari IBM, maka klien untuk perintah jarak jauh dan server panggilan program terdistribusi hanya untuk Java dalam bentuk perpustakaan JTOpen : Versi Open Source dari IBM Toolbox for Java (juga dikenal sebagai jt400 ) Kami "mengintip" solusi untuk masalah ini di IBM sendiri dengan menganalisis perilaku produk-produknya dengan fungsionalitas yang serupa (khususnya, Komunikasi Pribadi untuk Transfer Data Windows, iSeries ke PC / PC ke Transfer iSeries, dll.). Ternyata produk-produk ini, dengan implementasinya, menjalankan IBM JRE 6 atau 8, tergantung pada versi aplikasi, dan menggunakan perpustakaan jt400.

Untuk server otomatisasi, kami memutuskan untuk melakukan hal yang sama. JNI meluncurkan IBM JVM, yang dikirimkan bersama Personal Communications for Windows. Menggunakan metode pembungkus khusus, perintah dari server RPC yang datang dari luar dieksekusi dengan mem-proksi mereka ke dalam panggilan ke fungsionalitas jt400 yang diperlukan. Karena yang terakhir ini juga berisi driver JDBC untuk DB2, diputuskan untuk menggunakannya untuk mengakses DBMS pada IBM i.

Penting untuk dicatat bahwa Anda tidak dapat menggunakan Oracle JVM saat menggunakan HACL. Jika Anda menjalankan sesi emulator terminal, maka mencoba membuat instance dari mesin virtual akan macet. Demikian pula, jika Anda menjalankan Oracle JVM di ruang alamat suatu proses yang berinteraksi dengan HACL, yang terakhir hang tanpa penjelasan.

Seiring waktu, solusinya diimplementasikan pada peningkatan jumlah pekerjaan. Ini bekerja lebih cepat daripada solusi dengan Quick3270. Popularitas tumbuh, demikian pula jumlah autotest. Namun, selama operasi, kesulitan tambahan muncul:

  1. Terminal sesekali membeku;
  2. Ketidakmampuan untuk bekerja pada dudukan regresi karena emulator terminal menolak untuk memulai jika desktop pengguna di mana emulator mulai diblokir atau sesi RDP-nya diblokir;
  3. Khusus Windows;
  4. Prosedur kompleks untuk menginstal, mengkonfigurasi, dan memperbarui alat (melalui paket MSI);
  5. Siklus regresi kami untuk 130 autotest (sekitar 4000 langkah) mulai memakan waktu 7-8 jam.

Sesuatu perlu dilakukan ...


Dengan menganalisis jejak jejak dari banyak peluncuran autotest, menemukan hambatan dalam kinerja langkah-langkah yang sering digunakan, total waktu pelaksanaan regresi berkurang menjadi 4-5 jam. Tetapi jelas bahwa menggunakan lapisan middleware dalam bentuk server RPC otomatisasi bersamaan dengan antarmuka HACL, yang juga memiliki kesalahan "mengambang" yang terakumulasi selama durasi seluruh sistem, tidak akan membantu dalam meningkatkan kinerja solusi.

Di sisi lain, sebagai alternatif dari IBM Personal Communications untuk Windows, vendor menyediakan solusi lintas platform yang disebut IBM i Access - Solusi Klien.


IBM i Access - Solusi Klien

Analisis struktur internal pada hari Sabtu dan Minggu pagi di atas cangkir kopi menunjukkan bahwa basis kodenya didasarkan pada produk lain dari IBM yang disebut IBM Host on-Demand (IBM HOD). Ini adalah solusi lengkap untuk mengakses IBM i, dikembangkan di Java 6, yang tidak hanya memiliki implementasi penuh dari berbagai protokol komunikasi yang digunakan dalam mesin IBM (TN3270, TN5250, VTxxx, dll.), Tetapi juga komponen java-swing UI tingkat tinggi, digunakan untuk membangun emulator terminal mereka sendiri dalam bentuk konstruktor, yang dapat dikumpulkan dari dokumentasi IBM yang sedikit Studi yang lebih rinci tentang IBM HOD menunjukkan bahwa komponen UI didasarkan pada implementasi Java dari antarmuka HACL, yang dokumentasinya terbuka. Perilaku mereka bertepatan dengan hanya sedikit perbedaan dari dokumentasi C ++ HACL.


IBM Host On-Demand (logo)

Selanjutnya, kami membuat perpustakaan Java untuk penggunaan internal, yang mengimplementasikan antarmuka yang sama dengan server otomatisasi C ++ RPC, tetapi secara internal menggunakan IBM HOD. Untuk mengurangi overhead selama pelaksanaan langkah-langkah autotest, kami bermigrasi dari Ruby Cucumber ke cucumber-jvm dengan implementasi ulang semua langkah yang mirip dengan opsi Ruby. Di hadapan antarmuka perangkat lunak yang mirip dengan server RPC, ini bukan masalah besar, terutama mengingat bahwa kami mencoba menahan pertumbuhan tak terkendali dalam jumlah langkah itu sendiri dan kami memiliki nilai ini di wilayah 30 unit.

Apa hasilnya


Akibatnya, kami mencapai operabilitas semua autotes tanpa mengubahnya, dan kecepatan kerja menjadi sangat tinggi sehingga kami harus memperkenalkan penundaan artifisial di antara langkah-langkah sehingga ketika mengembangkan autotest, Anda dapat mengamati kerjanya, jika tidak, UI tidak punya waktu untuk menggambar layar sampai akhir.

Sudah ada 180 autotest dengan lebih dari 16.000 langkah dengan penundaan set 60 ms antara langkah mulai berjalan sekitar 30 menit terhadap 5 jam 30 menit, yang sesuai dengan peningkatan sebelas kali lipat dalam kinerja stand regresi.

Hasilnya melebihi semua harapan. Kami dekat dengan batas fisik protokol TN5250.

Hingga saat ini, keputusan tersebut telah dipublikasikan ke seluruh bank, dan rekan-rekan dari kota-kota lain telah ikut serta dalam perbaikan. Dari perubahan terbaru, kolega mengintegrasikan solusi dengan Jenkins, dalam versi pengujian, pengujian peluncuran pada server Linux dengan Xvfb selesai dan tahap operasi percontohan menjalankan autotest dimulai.

Terima kasih sudah membaca sampai akhir!
Semua sukses!

PS Pada bulan Desember 2018, Konferensi Pengembang IBMi berikutnya diadakan, di mana sebuah laporan dibuat tentang topik artikel ini.

Hingga saat ini, kami telah menyelenggarakan Konferensi setiap tahun hanya untuk karyawan Bank. Mulai 2019, kami akan mengundang peserta dari perusahaan lain. Sangat menarik untuk memperluas lingkaran komunikasi profesional dan pribadi, berbagi emosi, pengetahuan, dan pengalaman.

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

More articles:


All Articles