#WasMichMotiviert
Software Testing or Testing Topic, describe some of my working day as test analyst in projects
Ref:
[plantuml]
Alice -> Bob: Authentication Request
Bob --> Alice: Authentication Response
Alice -> Bob: Another authentication Request
Alice <-- Bob: another authentication Response
[/plantuml]Pada umumnya pengguna Robotframework, menggunakan Web interface Library ( SeleniumLibrary , Browser Library ) untuk automatisasi download data dari Internet.
Sebenarnya banyak cara lain yang lebih mudah digunakan untuk tujuan tersebut.
Methode 1:
mengunakan Standard libraries (Run Process) dengan menggunakan download tools yang tersedia pada umumnya seperti CURL atau WGET
${download_status} run Process curl -O ${download_uri} > ${download_target} shell=True
log many ${download_status.rc} ${download_status.stdout} ${download_status.stderr}
Directory Should Not Be Empty ${download_folder}
File Should Exist ${download_target}Methode 2:
menggunakan HTTP RequestsLibrary dengan Keyword: GET On Session
Create Session download ${HOST} verify=False debug=1
${response} Get On Session download ${MSI}
log many ${response}
Create Binary File ${download_target} ${response.content}
Directory Should Not Be Empty ${download_folder}
File Should Exist ${download_target}Kelemahan dan Problem yang ada akan hadapi dengan menggunakan
Methode 1. adalah hanya akan befungsi untuk plain text data , atau juga data yang tidak dengan format biner.
Untuk data-data dengan format biner, contohnya *.MSI anda akan mendapat Problem seperti ini, pada saat mencoba untuk menggunakan data tersebut.
Windows *.MSI data rusak dalam process download .
Hanya dengan Methode 2. anda akan mendapatkan File biner (*.MSI) tanpa kerusakan.
Semoga informasi ini berguna untuk pengguna Robotframework dimana saja.
Sedikit berbagi sumber informasi tentang pemahaman thema yang saya sebut di judul atas.
Sumber Informasi asli saya dapatkan di sini: https://www.kreyman.de/index.php/others/linux-kubernetes/232-unterschiede-zwischen-docker-containerd-cri-o-und-runc
Munculnya Docker memicu ledakan popularitas kontainer. Sejak itu, semakin banyak alat dan standar yang dirancang untuk membantu mengatur penggunaan teknologi ini.
Sayangnya, cukup sulit untuk mengikuti perkembangan. “Pertempuran” antara perusahaan teknologi besar juga membingungkan bagi banyak dari kita.
Dalam artikel ini, saya akan membahas semua nama besar yang pernah Anda dengar dan mencoba menguraikan jargon teknis untuk Anda dan menjelaskan bagaimana ekosistem kontainer akan bekerja sama pada tahun 2021.
Dan jika Anda berpikir bahwa Anda adalah satu-satunya yang tidak mengerti semua ini, jangan khawatir … Anda tidak sendirian!
Ada perbedaan antara Docker (dalam bentuk perusahaan), Docker-Containern, Docker-Images, dan Development Tools Docker yang biasa kita gunakan:
Sumber: https://twitter.com/jbeda
Seperti yang Anda lihat, Anda bukan satu-satunya yang bingung. Joe Beda , co-developer Kubernetes, setuju.
Ini adalah kesempatan sempurna untuk menjernihkan beberapa kebingungan dan membantu Anda memahami kapan itu Docker, containerd, atau CRI-O. Ini sangat penting jika Anda ingin membahas topik Kubernetes.
Penting bagi Anda untuk mengingat hal-hal berikut:
Wadah tidak lagi dikaitkan secara permanen dengan nama Docker. Ada beberapa alat kontainer yang tersedia. Docker adalah salah satunya, dan Docker (perusahaan) mendukung beberapa tetapi tidak semuanya.
Jika Anda masih berpikir bahwa container hanyalah Dockers, baca terus! Sekarang kita akan melihat lebih dekat pada ekosistem kontainer.
Ekosistem kontainer terdiri dari banyak teknologi, istilah khusus, dan perusahaan pesaing. Untungnya, perusahaan terkadang menegosiasikan gencatan senjata yang rapuh untuk menyepakati standar tertentu.
Standar ini membantu untuk mencapai interoperabilitas antara alat yang berbeda dan menghindari ketergantungan pada perusahaan atau proyek tertentu (teknologi). Standar dasar yang harus diikuti:
Diagram di bawah menunjukkan bagaimana Docker , Kubernetes , CRI , OCI , containerd dan runc cocok bersama dalam ekosistem ini:
Kami akan mulai dengan Docker karena ini adalah alat kontainer paling populer saat ini. Bagi banyak orang, nama “Docker” sendiri merupakan sinonim dari kata “container”.
Docker memulai seluruh revolusi containerisasi ini. Docker telah menciptakan alat yang sangat ergonomis dan mudah digunakan untuk bekerja dengan container, yang juga disebut Docker.
docker dapat diinstal pada sistem operasi klien atau pada sistem operasi server. docker berisi sejumlah alat yang menyederhanakan pekerjaan pengembang dan insinyur DevOps. Dengan CLI buruh pelabuhan Anda dapat membuat image container, mengambilnya dari repositori, membuat container, memulai dan mengelolanya.
Docker terdiri dari tiga proyek:
docker-cli – adalah utilitas baris perintah yangberinteraksidengan Anda menggunakan perintah docker .
containerd – adalah daemon Linux yang mengelola dan memulai container. Ini mengunduh gambar dari repositori, mengelola penyimpanan dan jaringan, dan memantau eksekusi kontainer.
Runc – adalah runtime container tingkat rendah yang benar-benar membuat container dan menjalankan. Ini termasuk libcontainer , implementasi berbasis Go asli untuk membuat container.
Saat Anda menjalankan wadah dengan docker , Anda sebenarnya menjalankannya dari daemon docker, containerd, dan kemudian runc .
Penting untuk dicatat bahwa Kubernetes hanya dapat melayani runtime container yang mendukung Container Runtime Interface (CRI). Namun, Docker tidak dapat secara langsung mendukung standar ini. Oleh karena itu, Kubernetes menyertakan komponen yang disebut dockershim, yang diperlukan untuk bekerja dengan Docker.
Di masa mendatang (dari versi 1.23) Kubernetes akan menghentikan dukungan untuk Dockershim dan juga Docker dan hanya akan bekerja dengan Container Runtime s yang mendukung Container Runtime Interface (CRI) – containerd atau CRI-O . ( FAQ Penghentian Dockershim )
Namun, ini tidak berarti bahwa Kubernetes tidak akan dapat menjalankan container berformat Docker. Baik containerd maupun CRI-O dapat menjalankan gambar berformat Docker (berformat OCI). Anda tinggal melakukannya tanpa harus menggunakan perintah docker atau daemon Docker.
Shim – Secara teknis, shim adalah komponen dalam sistem perangkat lunak yang bertindak sebagai jembatan antara berbagai API atau sebagai lapisan kompatibilitas. Terkadang shim ditambahkan saat Anda ingin menggunakan komponen pihak ketiga. Anda membutuhkan sedikit kode lem untuk membuatnya bekerja.
Apa yang disebut banyak orang sebagai Docker Image sebenarnya adalah Image yang dikemas dalam format Open Container Initiative (OCI) .
Jika Anda ingin mengunduh gambar dari Docker Hub atau repositori lain, Anda dapat melakukannya dengan perintah buruh pelabuhan atau dengan utilitas podman, atau dengan alat lain yang mendukung spesifikasi format gambar OCI.
CRI adalah API yang digunakan Kubernetes untuk mengontrol berbagai runtime container untuk membuat dan mengelola container.
CRI menyederhanakan penggunaan runtime container yang berbeda untuk Kubernetes (atau lebih tepatnya kubelet ). Alih-alih mendukung setiap kemungkinan runtime container secara terpisah, hanya standar CRI yang didukung yang digunakan. Dalam hal ini, tugas manajemen kontainer sepenuhnya terletak pada runtime kontainer.
Jadi, jika Anda lebih suka menggunakan containerd untuk menjalankan container Anda, jangan ragu untuk melakukannya. Atau, jika Anda lebih suka menggunakan CRI-O maka Anda dapat menggunakan ini dengan aman. Ini karena spesifikasi CRI diimplementasikan di kedua runtime.
Sebagian besar waktu, jika Anda adalah pengguna akhir, bagaimana Anda mengimplementasikannya tidak menjadi masalah. Implementasi CRI dirancang agar dapat dipasang dan diubah dengan mulus.
Untuk informasi Anda: Red Hat (proyek OpenShift) menggunakan CRI-O dan bertanggung jawab atas pemeliharaannya (keamanan, perbaikan bug, dll.). Sementara containerd terus dibungkus oleh Docker.
The kubelet (sebuah berjalan agen pada setiap node) bertanggung jawab untuk berinteraksi dengan runtime wadah dalam arsitektur Kubernetes. Tugas utama kubelet adalah mengirimkan instruksi start/stop ke runtime container.
Opsi berikut digunakan untuk mengonfigurasi runtime container: –container-runtime dan –container-runtime-endpoint. Anda dapat mengetahui Container Runtime mana yang sudah terinstal di infrastruktur Kubernetes Anda menggunakan rantai perintah berikut:
kubectl mendeskripsikan simpul <node_name>
containerd adalah runtime container tingkat tinggi yang berasal dari Docker dan mengimplementasikan spesifikasi CRI. ontainerd menarik gambar dari repositori, mengelolanya dan kemudian meneruskannya ke runtime bawahan, yang benar-benar membuat dan menjalankan proses kontainer.
containerd telah dihapus dari proyek Docker untuk membuat Docker lebih modular. Jadi Docker menggunakan containerd untuk dirinya sendiri.Saat Anda menginstal Docker, containerd juga diinstal secara otomatis. Selain itu, ontainerd menggunakan pluginnya sendiri untuk mendukung CRI di Kubernetes.
CRI-O adalah runtime container tingkat tinggi lainnya yang mengimplementasikan Container Runtime Interface (CRI). CRI-O adalah alternatif untuk containerd dan bekerja dengan cara yang sama.
CRI-O dikembangkan dengan dukungan Red Hat, IBM, Intel dan SUSE sebagai wadah runtime untuk Kubernetes. CRI-O menawarkan kemungkinan untuk memulai, menghentikan, atau memulai ulang container, sama seperti containerd.
OCI adalah sekelompok perusahaan teknologi yang mempertahankan spesifikasi untuk format gambar kontainer dan eksekusi kontainer.
Gagasan di balik OCI adalah Anda dapat memilih di antara berbagai runtime yang sesuai dengan spesifikasi. Masing-masing runtime ini memiliki sub-implementasi yang berbeda.
Misalnya, Anda memiliki satu runtime yang kompatibel dengan OCI untuk host Linux Anda dan satu untuk host Windows Anda. Ini adalah keuntungan memiliki standar yang dapat diterapkan oleh banyak proyek yang berbeda.
runc adalah runtime kontainer yang kompatibel dengan OCI. Ini mengimplementasikan spesifikasi OCI dan menjalankan proses container.
runc disebut sebagai implementasi referensi OCI.
Implementasi referensi adalah perangkat lunak yang telah mengimplementasikan semua persyaratan spesifikasi atau standar. Biasanya software pertama yang dikembangkan dari spesifikasinya. Dalam kasus OCI, runc menawarkan semua fungsi yang diharapkan dari runtime yang sesuai dengan OCI, meskipun setiap orang dapat mengimplementasikan runtime OCI mereka sendiri jika mereka mau.
runc menawarkan semua fungsi tingkat rendah untuk wadah dan berinteraksi dengan fitur Linux tingkat rendah yang ada seperti ruang nama dan grup kontrol. runc menggunakan fungsi-fungsi ini untuk membuat dan menjalankan proses container.
Ada juga beberapa alternatif untuk runc :
Dalam artikel ini kita melihat bahwa Docker hanyalah sebagian kecil dari keseluruhan ekosistem container. Ada standar terbuka: CRI dan OCI serta proyek seperti containerd , runc dan CRI-O . Kami akan segera melihat banyak implementasi baru dari runtime container dengan dukungan untuk standar CRI dan OCI.
Semoga artikel ini bisa memberi sedikit pencerahan tentang gelapnya dunia container.
Pengarang: Tom Donohue
Posting blog ini adalah terjemahan dari bahasa Jerman. Anda dapat menemukan artikel asli di tautan ini . (https://www.kreyman.de/index.php/others/linux-kubernetes/232-unterschiede-zwischen-docker-containerd-cri-o-und-runc)
Dalam artikel ini saya ingin sedikit berbagi pengalaman saya dalam penerapan test automatisasi dengan Robotframework dalam bentuk pengujian bersyarat (Requirements based Testing)
Sebelum itu mari kita lihat dan pahami , apa arti Pengujian berbasis Persyaratan (Requirements based Testing) secara umum.
Apa itu Pengujian Berbasis Persyaratan?
Pengujian berbasis persyaratan adalah pendekatan pengujian di mana kasus pengujian, kondisi, dan data berasal dari persyaratan. Ini termasuk tes fungsional dan juga atribut non-fungsional seperti kinerja, keandalan atau kegunaan.
Tahapan dalam Pengujian berdasarkan Persyaratan:
Persyaratan Proses pengujian:
Contoh Desain Kasus Uji dengan Robotframework:
*** Settings ***
Documentation *Kriteria Penyelesaian Test:*
... Ein SGD ePA MUSS Folgendes sicherstellen: Wenn über dessen HTTPS-SGD-Schnittstelle (vgl. ) ein POST- Request mit dem Request-Body nach [gem_SGD_ePA#Tab_KeyDerivation-Request] eintrifft, so MUSS die RVE des SGD
... - das Zertifikat im Datenfeld *Certificate* gemäß TUC_PKI_018 prüfen und
... dabei Ergebnisse nach \ \ berücksichtigen.
...
... - die Kodierung und die Signatur der ""PublicKeyECIES"" prüfen (vgl. \ und ).
... Falls eine der Prüfungen ein nicht-positives Ergebnis liefert, so MUSS die RVE des SGD mit einer entsprechenden Fehlermeldung aus [gemSpec_SGD_ePA#] dem Client antworten und die weitere Requestverarbeitung abbrechen.
...
... Die RVE des SGD MUSS die Informationen aufbereiten und an das für den Request avisierte SGD-HSM übergeben (vgl.). Liefert das SGD-HSM ein OK, so MUSS die SGD die Antwort den HTTP-POST-Request mit folgender Nachricht beantworten:
... {
... \ ""Status"" : ""OK"",
... \ ""EncryptedMessage"" : ""... Base64-kodiertes Chiffrat. Das Chiffrat wurde vom SGD-HSM erzeugt ...""
... }
... Anderenfalls (SGD-HSM meldet einen Fehler) MUSS die RVE des SGD mit einer entsprechenden Fehlermeldung aus [gemSpec_SGD_ePA#] \ dem Client antworten.
*** Test Cases ***
A_17898-1
[Documentation] *Definisi Test:*
... - Am SGD ePA trifft über die HTTPS-SGD-Schnittstelle (vgl. A_17889) ein POST-Request mit dem Request-Body nach [gem_SGD_ePA#Tab_KeyDerivation-Request] ein: die RVE des SGD prüft das Zertifikat im - Datenfeld ""Certificate"" gemäß TUC_PKI_018 \ und berücksichtigt dabei Ergebnisse nach A_17896.
... - Die RVE des SGD prüft die Kodierung und die Signatur der ""PublicKeyECIES"" (vgl. A_17900 und A_17901).
...
... *Hasil Test:*
... - Beide Prüfungen liefern ein positives Ergebnis.
... - Die RVE des SGD bereitet die Informationen auf.
... - Die RVE des SGD übergibt die aufbereiteten Informationen an das für den Request avisierte SGD-HSM.
... - Das SGD-HSM liefert ein OK.
... - Die SGD beantwortet den HTTP-POST-Request mit folgender Nachricht:{\ ""Status"" : ""OK"",\ ""EncryptedMessage"" : ""... Base64-kodiertes Chiffrat. Das Chiffrat wurde vomSGD-HSM erzeugt ...""}"
[Tags] A_17898 gemSpec_SGD_ePA owner-at prio-1
[Setup] Enable Strict Validation
sgd-clientjavaWF.Vorbedingungen für Überprüfung
sgd-clientjavaWF.Schritt1
sgd-clientjavaWF.Schritt2
sgd-clientjavaWF.Schritt3
sgd-clientjavaWF.Schritt4
sgd-clientjavaWF.Schritt6Kriteria Penyelesaian Test dapat anda implementasikan dalam fungsi [Documentation] pada Robotframework Test.
Verifikasi Cakupan Test dapat anda implementasikan dalam fungsi [Tags] pada Robotframework Test.
Verifikasi Hasil Cakupan Test akan dihasilkan oleh Robotframework Test Report dan Test Log, yang didalamnya menggambarkan jalur dan urutan Test anda.
Anda tidak membutuhkan Aplikasi atau Software extra untuk mengimplimentasikan Kriteria yang saya sebutkan di atas.
Hasil dan dokumentasi dari Test anda akan anda dapatkan selalu dari hasil akhir automatisasi Test anda dengan Robotframework.
just one sample migrating ATDD Test from Coded UI to Robotframework.
Before Test Structure:
Comparison Unit Test & ATDD Test Structure:
Reason for Migration from CodedUI to Robotframework:
Proposed Robotframework ATDD Structure:
Project / Test & Development enviroment Limitation:
Needed Infrastukture and Software for Testing with Robotframework:
Benefit of using Robotframework:
Starting the MIgration Steps:
Reports & Logs:
Installing Ride v1.7.4 on Raspberry Pi Zero with Raspbian is a Challenge, especially during preperation and installation of wxPython for pi Zero
Base setup from pi Zero:
Do SW update before installing :
sudo apt-get update
sudo apt-get upgrade
sudo apt get dist-upgradeDo Install pip3 for my pi zero:
sudo apt-get install python3-pipPrepare installation before installing wxPython on pi Zero:
sudo apt-get install dpkg-dev build-essential swig python-dev libwebkit-dev libjpeg-dev libtiff-dev checkinstall freeglut3 freeglut3-dev libgtk2.0-dev libsdl1.2-dev libgstreamer-plugins-base0.10-dev libgstreamer0.10-dev libgconf2-dev libglapi-mesa libosmesa6 libglu1-mesa-dev libglu1-mesa mesa-common-devsudo apt-get install build-essential tk-dev libncurses5-dev libncursesw5-dev libreadline6-dev libdb5.3-dev libgdbm-dev libsqlite3-dev libssl-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev
sudo apt-get install python3.7-devsudo apt-get install python-wxgtk2.8 python-wxtools wx2.8-i18n libwxgtk2.8-dev libgtk2.0-dev
sudo apt-get install gtk+-3.0 gtk+3.0-devsudo pip3 install pathlib2Now install wxPython, it can take long (+/- 24 Hours) by pi Zero!
sudo pip3 install wxPythonIf it’t passed you can install Ride !
sudo pip3 install --upgrade robotframework-rideYou can start the Ride now as remote sessions:
Ride.py &
Why using Robotframework on Raspberry pi?
As Raspberry pi user , sometimes I have problems after doing OS update with some application I currently workout on pi, mean do “sudo apt-get update” , “sudo apt-get upgrade” & do “Reboot” everythings goes Wrong 🙁 !.
I have been using Robotframework since 2006, and would like to show you how simple to run a Regresion Test with Robotframework Framework on SBC like Rasberry Pi and Co’s. Robotframe work need only python ecosystem, which are out of the box delivered by Raspbian OS. And also it needs minimal resource of space in SD card.
As a sample I will start with installation of Robotframework , please check before if you have python pip installer installed on your Rasbian before starting with the installation!
Start Installation of Robotframework on Pi
sudo apt-get install python3-pip
sudo pip3 install robotframework
Check Robotframework runner:
robot --version
You can used nano or Test IDE Ride for writing Tests .
Installing Robotframework-RIDE test IDE:
sudo pip3 install robotframework-rideStart RIDE on Mac with ssh conection to pi:
ride.py & 
now you can start writing your Test, please refer to Robotframework manual for more Information.
Let check the SD card used for Robotframework Installation, just 1% from 16 GB SD card!
Wish you happy Testing and Try Out!
For efficient testing sometime you need to created automaticaly request xml feeding soap interface. If you are familiar with robot framework, it’s great. Robotframework has already 2 external Library, which handle SOAP interfaces communication.( Süds Library or Zeep Library ) .
There are a lot of opinion in Internet about these two libraries, discussing pro and contra using one of these lib. for testing SOAP.
Important things to do, you have to find out which library can handle “your WSDL“ better!
For my task, Suds library does.
How to find it out?
Just run your SOAP Library keyword pointing out your target WSDL .
Used “Create Soap Client” keyword for testing the binding if you get all the entities and objects on your WSDL, If the answed “OK” than you can used your Library for SOAP,
| … Ports (1): …. Methods (10): addToIndex(xs:string guid, ) getProductMetadaten(xs:string guid, ) getProductMetadatenGuidList(xs:string query, ) getProductMetadatenList() … Types (62): ns3:AbstractCurveType ns3:AbstractGMLType ns3:AbstractGeometricAggregateType ns3:AbstractGeometricPrimitiveType … |
If not you have to find out other library for interfacing with SOAP.
As sample I got these error using Zeep for parsing my WSDL:
self.item_type = self.item_type.resolve()
AttributeError: ‘lxml.etree.QName’ object has no attribute ‘resolve’
These error are related to these following open issue on Zeep:
Sample of created XML request from RF with Suds Library:
this is how I wrote it in Robotframework Test Suite:
| map WSDL local | |
| Run Keyword and Continue On Failure | setProductMetadaten |
this is how I wrote it in Robotframework Test Case:
| show object setProductMetadaten | |
| setProductMetadaten |
calling internal keyword:
| ${object}= | Create WSDL Object | n2:ProductMetadata | ||
| Set Wsdl Object Attribut | ${object.commonMetadata} | identifier | ${dummy_text} | |
| Set Wsdl Object Attribut | ${object.commonMetadata} | title | ${dummy_text} | |
| Set Wsdl Object Attribut | ${object.commonMetadata.description} | summary | ${dummy_text} | |
| Set Wsdl Object Attribut | ${object.commonMetadata.description} | comments | ${dummy_text} | |
| Set Wsdl Object Attribut | ${object.commonMetadata.product} | type | ${dummy_text} | |
| Set Wsdl Object Attribut | ${object.commonMetadata.product} | subtype | ${dummy_text} | |
| Set Wsdl Object Attribut | ${object.commonMetadata} | rflAuftragsnummer | ${dummy_text} | |
| Set Wsdl Object Attribut | ${object.commonMetadata.change} | version | ${dummy_text} | |
| ${result}= | call Soap method | setProductMetadaten | ${object} |
RFlog result
Creating 100X Request with RF For loop keyword
| map WSDL local | ||
| :FOR | ${i} | IN RANGE 100 |
| setProductMetadaten |
Hope these infos help you starting your SOAP request creation with Robotframework & SudsLibrary, just another way of SOAP testing than using SOAPUI.
Most MS (Microsoft) software roll-out are release via SCCM to all Project Infrastructure (DC, AD, Application Servers, Application Clients). Usually testers are using Standards MS Tools like Powershell, MS CMD (tools: like netsh, wmic, etc) for validating Installation results on targets.
This article describe how the same tasks solve with python scripting using WMI & LDAP3 library.
Common Test Task & Rollout Workflow:
Just daily tasks for MS Administrator , as test analyst , I try to find out more efficient way.
After some investigation I find out, the way validating MS SW status over WMI Interfaces are much easier than any Powershell or Dos Batch command, especially with pywmi.
These following WMI class Objects are interesting for SW Installations
Validation :
Using pywmi, ldap3, winkerberos and common Excel library on python, I created scripts which extract the installed SW, Services Status, Drive Mapping , Domain configuration and AD Application User Accounts. All as excel files containing Tabs related to the mentions check Topics.
Status, Drive Mapping , Domain configuration and AD Application User Accounts. All as excel files containing Tabs related to the mentions check Topics
I Run it before SW update and after Update, find out the delta Information’s I got in my excel sheet and cross check if all Items match to release roll-out specifications.
Added Value:
Ref:
Webfrontend dari RTH Turbo
sangat kompakt , tidak mahal dan sangat bermanfaat untuk SW tester.
HW & Software yang anda perlukan:
Regresion Test Tools:
#WasMichMotiviert