Kami di Alfastrakhovanie menggunakan SAP ERP sebagai sistem penyelesaian kerugian proses. Dan kebetulan kami sedikit menyelesaikannya, ini pasti mengarah pada kesalahan dalam kode. Jika kesalahan mencapai sistem yang produktif, ini buruk. Ini harus dihindari, salah satu caranya adalah pengujian regresi. Dalam artikel ini saya akan berbicara tentang bagaimana kita melakukan "regresi" untuk SAP, karena kita melakukannya (oh!) Non-standar.
Semuanya dimulai beberapa tahun yang lalu. Pada tahun-tahun itu, kami sudah secara aktif menggunakan pengujian regresi, tetapi kami tidak bisa melakukannya di SAP - alat yang digunakan tidak bekerja dengan SAP, tim pengujian tidak ingin mempelajari alat yang "diasah" untuk SAP. Saya tidak ingat persis mengapa, tetapi saya menganggapnya sebagai tantangan (ini sebelum saya beralih ke rekayasa tanggal) dan memutuskan untuk "mempelajari" masalah ini.
Hasil penelitian (dan juga "melakukan") - dalam artikel ini (di bawah), saya akan secara singkat mengatakan ini: kami secara otomatis menguji SAP (dan lingkungan terdekatnya), kami melakukannya dengan cukup efektif (dalam segala hal), kami tidak menghabiskan satu rubel pun untuk lisensi dan pelatihan, pendekatan kami sederhana dan sepenuhnya dapat direproduksi. Dan kami tidak menggunakan alat SAP apa pun untuk pengujian otomatis SAP (kecuali di tempat kami membangun sistem transpornya).
Stroke besar
Ada bahaya masuk ke detail dan kehilangan pembaca, saya akan mencoba untuk tidak melakukan ini (sebagai penulis, saya tahu semua detail).
Semuanya dimulai dengan belajar, berkomunikasi dengan SAP, mitra kami dan Mr. Google.
Hasil komunikasi ini adalah sebagai berikut:
- SAP memiliki alat untuk menguji otomatisasi (kami melihat eCATT, SAP SAPTA)
- mereka membutuhkan perendaman substansial (terutama SAP CBTA)
- pembatasan mungkin diperlukan, jika perlu, melampaui batas SAP (dia tidak berada dalam "kekosongan" dengan kami)
- ada produk pihak ketiga (misalnya, HP), tetapi kami tidak memiliki kompetensi untuk mereka, sama seperti kami membeli lisensi
- ada cara untuk "mengelola" SAP dari luar (perusahaan Convista memberi tahu saya gagasan ini, terima kasih banyak untuk itu)
Karena saya pribadi tidak memiliki pengetahuan tentang SAP, saya memutuskan untuk mencoba menggali ke arah terakhir - mengelola SAP bukan dari SAP. Google dengan cepat menyediakan dokumen "SAP Script API GUI untuk Windows dan Platform Java", yang merupakan awal yang baik untuk inisiatif ini. Tes cepat pada python favorit saya menunjukkan itu berfungsi.
Selanjutnya, itu masalah kecil - untuk menemukan kerangka kerja yang cocok untuk otomatisasi pengujian. Karena python adalah bahasa favorit saya, Kerangka Robot dengan cepat menjadi pertimbangan. Dan, faktanya, setelah dia masuk daftar dan diadili, maka hanya dia yang ada di daftar. Disuap oleh fakta bahwa "itu" segera bekerja (melihat ke depan - dan masih berfungsi, saya tidak menyesal satu menit pun tentang pilihan saya).
Seorang pilot kecil menunjukkan bahwa SAP sangat "dikendalikan" oleh robot (saya akan menyebut Kerangka Robot itu kata Rusia): dengan cepat, serempak, dapat diprediksi, dan andal. Pada saat yang sama - saya tekankan - kami menggunakan cara SAP yang terdokumentasi untuk berinteraksi dengan SAP GUI (bukan semacam "kruk").
Arsitektur
(ya biarkan saya menggunakan kata ini di sini)
Cara kerjanya:
- skrip dieksekusi di server (kata "server" digunakan di sini dalam arti bahwa komputer ini melayani permintaan pengujian kami. Dalam kasus khusus ini, lebih tepat untuk menggunakan kata "klien" karena skrip yang mengontrol proses pengujian)
- melalui mekanisme standar robot Remote, skrip berinteraksi dengan komponen server dari robot yang berjalan pada SUT (sistem sedang diuji)
- komponen server ini memanggil metode perpustakaan manajemen SAP
- SAP GUI memproses permintaan ini (secara serempak, ini penting)
- hasil dari eksekusi query atau hanya "beats" dikembalikan ke skrip di "server", di mana mereka digunakan dalam proses pengujian
Secara teknis
- "server" adalah mesin virtual di bawah Ubuntu
- SUT - workstation tempat SAP workstation diinstal dan dikonfigurasi (dalam kasus kami, ini adalah komputer Windows atau mesin virtual)
- pustaka manajemen SAP ditulis dengan python (ada beberapa - beberapa ratus baris)
- "script" adalah "program" dalam bahasa yang dipahami oleh Kerangka Robot
- robot (dengan demikian) menyiratkan baris perintah, karena pengembang ABAP tidak terbiasa, saya membuat antarmuka WEB yang menyediakan, khususnya, kerja kolektif (tentang hal itu sedikit kemudian).
Luar biasa
Sebenarnya, apa yang kita dapatkan, kecuali kurangnya beban lisensi?
Banyak hal, jika singkat dan tentang hal utama:
Bahasa rusia
Scriptnya terlihat seperti ini:
Di awal perjalanan (mungkin selama uji coba), saya pikir - dan bahwa kita akan mematahkan lidah dan menghasilkan kata-kata yang tidak dapat dipahami bahkan untuk kita sendiri? Robot menyiratkan pembuatan kata kunci Anda sendiri (maaf untuk terminologi - ini dia menyebutnya). Jadi mengapa kita tidak segera membuat mereka dalam bahasa Rusia? Dia bertanya di komunitas penguji (di suatu tempat di perut Internet) - mereka "mengecewakan" saya: itu berbahaya, mengapa, siapa yang mengatakannya, dll. Saya memang menggunakan cara saya sendiri - kami memiliki segalanya dalam bahasa Rusia (variabel, kata-kata, hanya struktur kontrol robot yang tersisa, tetapi mereka harus disembunyikan di dalam kata kunci - jika Anda melihat bahasa Inggris, maka sekarang saatnya untuk refactor).
Apa yang baik tentang bahasa Rusia (kecuali untuk dapat dimengerti tanpa kamus) - skrip dapat ditampilkan kepada spesialis non-IT, pebisnis. Anda dapat menulis skrip ini secara langsung dengannya (saya bahkan tidak akan mencoba masuk ke topik ATDD di sini - ini adalah pos yang terpisah dan besar, suatu hari nanti saya akan menulisnya).
Kontrol total dan total dan ekstensibilitas
Saya tahu persis apa yang terjadi selama proses pengujian. Tidak ada sihir sama sekali - semuanya sangat jelas. Saya tidak tahu bagaimana orang, saya suka itu.
Tentang ekstensibilitas - fungsionalitas dapat dikembangkan ke segala arah, yang kami gunakan secara aktif:
- Saya berhasil membuat "bahasa" skrip tes saya sendiri, dapat dimengerti oleh bisnis
- dimungkinkan untuk secara otomatis memeriksa apakah bidang dalam antarmuka diisi dengan benar pada akhir tes (untuk ini, khususnya, kami membagi variabel robot menjadi parameter startup dan parameter antarmuka, memungkinkan untuk menentukan elemen antarmuka mana yang harus memiliki parameter startup yang mana)
- breakpoint dapat ditambahkan ke tes, selama breakpoint, lihat nilai-nilai variabel
- Kami menerapkan mekanisme untuk membuat templat file dan memasukkannya ke dalam proses eksekusi - tanpa ini, pengujian hewan seperti VLP tidak akan mungkin (dan kami mengujinya dalam mode yang sepenuhnya otomatis - mulai dari membuat aplikasi hingga mengurai ekstrak)
Kehadiran antarmuka web kami sendiri menambahkan lebih banyak opsi ekspansi - misalnya, kami mampu memodifikasi bahasa robot (kami datang dengan, misalnya, operator kondisional kami - kami dan pengguna bisnis kami tidak menyukai standar "Jalankan kata kunci jika"). Ini menjadi mungkin karena file dengan kode sumber tes dihasilkan untuk robot oleh aplikasi web.
Kemudahan masuk
Sebagai aturan, penguji tidak memiliki pengetahuan tentang infrastruktur SAP dan, terutama, pemrograman SAP. Mereka berhasil menguasai robot dan perbaikan kami dalam beberapa minggu.
Instruksi Pengguna
Kami juga beralih ke "Our William ..." - ke dokumentasi. Bukan rahasia bagi siapa pun - sebagai aturan, tidak ada dokumentasi untuk sistem, dan bahkan jika ada, sangat cepat menjadi usang. Pengguna melewati aturan bekerja dengan sistem "dari mulut ke mulut". Jika kode tes otomatis adalah deskripsi cara menggunakan sistem menurut penulis, lalu mengapa tidak mengubahnya menjadi instruksi?
Tentu saja, detailnya sulit dilihat pada fragmen ini, penting bahwa instruksi dibuat dan diperbarui dalam mode otomatis penuh, termasuk tangkapan layar. Instruksi selalu up to date (karena autotest selalu berfungsi). Dalam kasus SAP, tangkapan layar umumnya diterima dengan baik - dalam SAP Anda selalu dapat menemukan elemen antarmuka - persegi panjang yang koordinatnya akan relevan dengan tempat saat ini dalam kode uji, kontrol (tidak terlihat oleh mata) ini digunakan sebagai parameter untuk kata kunci "ambil tangkapan layar" (kata ini , tentu saja, ini hanya berfungsi dengan mode peluncuran uji yang sesuai - mengapa menghabiskan listrik begitu saja).
Kami memformat instruksi menggunakan Sphinx (saya yakin banyak yang telah mempelajari skema warna), oleh karena itu tersedia dalam manual online dan juga dalam bentuk cetak.
Sedikit tentang Kerangka Robot
Namun demikian, tidak ada yang bisa dikatakan tentang robot - itu akan menjadi terlalu tidak bisa dipahami dan dangkal. Saya akan coba sebentar.
Gagasan utama dari kerangka kerja ini adalah kemampuan untuk membuat bahasa pengujian Anda sendiri (dalam terminologi robot, unit yang dapat dieksekusi adalah kata kunci - kata kunci). Kerangka kerja menyediakan
- lingkungan eksekusi program (programmer - jangan tersinggung) dalam bahasa ini
- pustaka kaya fungsional (dari bekerja dengan string dan daftar ke ssh dan selenium)
- pelaporan (dalam proses penggunaan, bahkan tidak ada pemikiran untuk menulis laporan apa pun)
- sebuah paradigma sederhana untuk membentuk suatu program dari kata kunci (sedikit aneh, tetapi Anda dapat membiasakan diri dengannya), ada hal-hal seperti variabel, parameter dan hasil "panggilan" (kata kunci)
- ekstensibilitas yang sederhana dan kuat - sangat mudah untuk membuat perpustakaan Anda sendiri dengan python (misalnya, kami bekerja dengan Excel), baik lokal (mis. dijalankan di tempat yang sama dengan kode pengujian), dan jarak jauh (misalnya, yang mengontrol SAP GUI)
Proses membuat tes cukup mudah
- kami membentuk urutan tindakan dan menerjemahkannya ke dalam istilah robot (sedikit lebih rendah akan lebih spesifik tentang interaksi dengan sistem yang diuji)
- mengulangi urutan urutan dalam kata kunci (baru) mereka
- jalankan tes, lihat cara kerjanya, perbaiki, tingkatkan
- debugging disediakan oleh breakpoints (dengan kemampuan untuk melihat variabel - disediakan oleh arsitektur, lebih tepatnya - penggunaan perpustakaan remote robot)
Hasilnya bahkan bukan program (lihat contoh di atas), melainkan urutan tindakan yang diformalkan, yang, secara kebetulan, menggambarkan penggunaan program dalam bentuk yang dimaksudkan penulis (lihat ATDD di atas).
Interaksi dengan sistem yang diuji
Dalam kasus kami, kami menguji pada tingkat antarmuka pengguna (mis., Pengujian kami berinteraksi dengan SAP di tingkat GUI - mereka "mengklik" tombol, mengisi bidang teks, dll.). Secara umum diterima bahwa cara penulisan tes ini bukan yang terbaik. Saya sebagian setuju dengan ini, tetapi saya siap mendengarkan dan mendiskusikan bagaimana cara menguji aplikasi SAP GUI (seperti SAP FS CM kami).
Ada guru seperti itu - Robert Martin (alias "paman Bob" - penulis "Clean coder", kalau ada yang membaca), kami berkorespondensi sedikit tentang ini. Mereka setuju bahwa jika itu tidak terlalu sulit untuk dilakukan, itu tidak sering berubah (melanggar tes), maka oke - Anda juga dapat menguji melalui antarmuka.
Bagi saya, saya dapat mengatakan ini: dalam kasus SAP GUI, tidak ada banyak pilihan untuk mengimplementasikan antarmuka pengguna. Jika Anda perlu menambahkan kemampuan, misalnya, untuk melacak kode IMEI, Anda dapat melakukan ini dalam hampir satu cara - dengan menambahkan bidang yang sesuai ke salah satu bookmark. Jadi saya berpikir bahwa semua nuansa "penambahan" ini dapat dan harus dipikirkan oleh pelanggan (bagaimana bidang ini akan disebut dalam antarmuka, lebar, urutan penggunaan, dll.). Dan dia dapat melakukannya secara langsung dalam sebuah skrip, yang kemudian akan mengujinya secara otomatis. Jika Anda tidak dapat memikirkan revisi sampai akhir (seperti yang mereka katakan - baik, Anda melakukannya, dan kami akan melihat), maka lebih baik untuk tidak melakukan revisi ini. Dan untuk melakukan apa yang dapat Anda pikirkan. Yah, saya masuk ke ATDD lagi ...
Kembali ke interaksi dengan SAP GUI: kami berhasil, seperti yang sudah saya tulis, sekitar 200 baris dalam python dan sekitar 10 fungsi manajemen antarmuka yang berbeda (seperti "buka bookmark", "isi bidang", "tekan tombol"). Set ini terbentuk hampir di awal-awal dan kemudian tidak berkembang banyak. Untuk memuji SAP, saya perhatikan bahwa semuanya bekerja sangat cepat - mata tidak punya waktu untuk melacak bagaimana antarmuka "berkedip", penundaan dimasukkan ke dalam siklus kontrol untuk memperlambat (dalam kasus di mana pemantauan visual diperlukan). Saya juga mencatat keuntungan operasi sinkron - di mana pun dalam kode Anda tidak perlu menunggu apa pun, jika, misalnya, tombol ditekan, maka tindakan yang terkait dengan klik tombol telah selesai (misalnya, kerugian telah disimpan).
def get_ctrl_attr ( self, uid, attr ): """ ( ) ( ) exception = ( log) """ ctrl = self._get_ctrl(uid) try: retText = getattr( ctrl, attr ) except: raise AssertionError(" {1} {0}".decode("utf-8").format(attr,uid)) return retText
Beberapa komentar pada kode
- fragmen perpustakaan manajemen SAP GUI
- perpustakaan adalah objek, metode langsung tersedia dalam tes (dalam kata kunci), misalnya, metode di atas dapat disebut seperti ini: "res = get ctrl attr $ {UID} teks" (menggunakan notasi robot)
- jika terjadi kesalahan, teks pengecualian akan terlihat di log robot (Anda tidak perlu melakukan apa pun untuk ini - cukup pengecualian "bunuh"
Kode ini sangat sederhana, itu menyenangkan.
Menjalankan tes
Mengikuti logika robot, pengujian individual digabungkan dalam proyek kami. Tes atau proyek dapat dimulai secara manual dari antarmuka web. Proses pengujian regresi juga terintegrasi ke dalam sistem transportasi SAP:
- pemilik produk pada akhir fase pengujian bisnis menyetujui permintaan transportasi untuk transfer
- permintaan yang disetujui "memindahkan" satu per satu ke lingkungan pra-produksi, di mana, sesuai dengan pengaturan, satu atau serangkaian tes lain diluncurkan (lebih tepatnya, proyek)
- jika hasil tes positif, permintaan dilepaskan dan "masuk" ke lingkungan produksi
- ketika kesalahan terjadi, penulis permintaan dikirim surat dengan tautan ke laporan pengujian (dihasilkan oleh robot), permintaan tidak melangkah lebih jauh
Penting - antarmuka web secara signifikan mengurangi ambang untuk memasuki proses pengujian: untuk memulai tes sederhana - klik tombol "mulai". Pada saat yang sama (karena penggunaan Kerangka Robot), semua keuntungan dari representasi file pengujian (kontrol versi, baris perintah dan otomatisasi terkait, dll.) Dipertahankan.
Bukan getah om
Kami berhasil menerapkan pengembangan kami untuk menguji tidak hanya SAP GUI, saya memiliki pengembangan kecil (antarmuka pendaftaran kerugian disederhanakan) dalam python dan Django. Karena semua poin dasar yang telah kami terapkan, semua yang harus dilakukan adalah menulis pustaka manajemen browser (sama seperti saya harus mengelola SAP GUI, hanya melalui Selenium). Dan ternyata hebat:
- tes masih bekerja di mesin virtual Linux (pada yang sama - tes SAP dan bukan tes SAP hidup dalam "contoh" yang sama)
- browser "berkedip" di tempat kerja tester (kontrol visual penuh tanpa trik)
- laporan standar, alat yang sudah dikenal
Dalam pengujian sistem ini, saya melangkah lebih jauh (menuju ATDD) - elemen yang terlihat secara visual (label dan placeholder) dibentuk pada awalnya dalam tes, di sana mereka setuju dengan bisnis dan dari sana "jatuh" ke dalam kode sumber sistem itu sendiri (ternyata agak KERING) - Anda tidak dapat tulis kode tanpa menulis tes terlebih dahulu. Keren
Tentu saja, banyak alat telah dikembangkan untuk aplikasi web, tetapi saya tidak dapat mengatakan bahwa saya mengalami ketidaknyamanan selama bekerja. Ternyata baik-baik saja di sini ...
Untuk meringkas
Dunia SAP besar dan berisi, tampaknya, semua yang diperlukan untuk kebahagiaan pengembang. Tetapi ini tidak berarti bahwa Anda hanya perlu berjalan di sepanjang jalur yang telah "berjalan" oleh SAP dan ekosistemnya. Berguna di awal jalan untuk bertanya pada diri sendiri pertanyaan: apakah saya benar-benar ingin melakukan "seperti orang lain"? Kami di Alfastrakhovanie bertanya kepadanya sendiri, dan tidak hanya di IT.
Dan, sekali lagi, semuanya mungkin dalam pemrograman, pertanyaannya hanya waktu dan uang (motivasi).