“Both testing and Simulation can detect bugs, but they cannot guarantee the absence of bugs.” — Dijkstra, 1970
SOA Testing Approach
Mirip proses testing “normal”: (1) Requirement review → (2) Test planning → (3) Test design → (4) Environment setup → (5) Execution phase → (6) Reporting phase.
SOA Testing Layers
Karena sifat SOA yang berlapis (layered), testing harus fokus pada 3 layer:
- Service level
- Interface level
- End-to-end level
Pendekatan top-down dipakai untuk Test Designing; pendekatan bottom-up dipakai untuk Test Execution.
Stages in SOA Testing (4 Tier)
| Tier | Jenis Testing |
|---|---|
| Tier 1 | Service level testing, Functional testing, Security testing, Performance testing |
| Tier 2 | Process testing |
| Tier 3 | End-to-end testing |
| Tier 4 | Regression testing |
Tier #1 — Service Level Testing
Tiap service diuji individual berdasarkan metode request and response. Testing ini wajib dan sangat penting sebagai prasyarat proses testing lainnya.
Functional testing: menguji apakah response yang diterima sesuai kebutuhan bisnis. Kebutuhan bisnis diubah dulu jadi test case & pernyataan request; request diproses untuk cek response benar; input tidak valid harus memicu error code/message yang tepat; format response & skenario negatif juga harus dieksekusi.
Security testing: keamanan berperan kunci dalam kesuksesan proses testing web service. Authentication gateway, payment gateway, dll. harus terenkripsi saat data di-parse. Untuk XML, kerentanan seperti CSRF, SQL Injection harus diverifikasi.
Performance testing: memastikan kredibilitas service yang dipakai banyak aplikasi lain. Tujuan: menentukan stabilitas, memvalidasi skalabilitas, memeriksa perilaku di bawah beban puncak, dan menemukan waktu respons lintas-service.
Tier #2 — Process Testing
Menguji berbagai proses bisnis — mencakup skenario integrasi web service & aplikasi yang mencakup kebutuhan bisnis. Memakai simulator untuk menghasilkan data input sampel & validasi output. Alur data dari layer berbeda diuji untuk membuktikan sistem berfungsi mulus saat terintegrasi.
Tier #3 — End-to-end Testing
Memvalidasi kebutuhan bisnis baik secara fungsional maupun non-fungsional: UI aplikasi divalidasi, proses bisnis diuji, alur data end-to-end divalidasi, kerja semua service saat terintegrasi divalidasi.
Tier #4 — Regression Testing
Memvalidasi stabilitas sistem pada rilis build inkremental. Bisa dilakukan lewat manual testing atau automation testing.
Tantangan SOA Testing
- Sulit mensimulasikan lingkungan testing.
- Produk dalam model bisa sama/beda teknologi/vendor — makin banyak masalah kombinasi.
- Kombinasi testing meningkat pesat seiring bertambahnya jumlah service/komponen.
- Kompleksitas model tinggi; sulit mengisolasi defect karena arsitektur multilayer.
- Sulit memprediksi beban karena service dipakai lewat berbagai interface — membuat perencanaan performance test rumit.
- SOA = kumpulan teknologi heterogen → butuh SDM lintas skillset, menaikkan biaya perencanaan & eksekusi.
- Validasi keamanan (autentikasi & otorisasi) cukup sulit karena aplikasi merupakan integrasi banyak service.
- Lack of interfaces untuk beberapa service (tidak ada GUI); proses testing mencakup banyak sistem, menciptakan kebutuhan data kompleks; regression testing jadi lebih sering karena komponen sering berubah.
Strategi Testing
Test Planning Approach
- SOA Tester harus memahami arsitektur aplikasi secara menyeluruh.
- Aplikasi dipecah jadi service independen (punya struktur request/response sendiri, tidak bergantung service lain untuk membentuk response).
- Struktur aplikasi direorganisasi jadi 3 komponen: Data, Services, Front-end applications.
- Semua komponen dianalisis, skenario bisnis dipetakan; skenario diklasifikasikan umum vs spesifik aplikasi.
- Traceability Matrix dibuat, semua test case ditelusuri ke skenario bisnis.
Test Execution Approach
- Tiap komponen service diuji.
- Integration Testing komponen service — validasi alur data & integritas data lewat service.
- System Testing model lengkap — validasi alur data antara aplikasi front-end & database.
- Performance Testing — untuk fine-tuning & performa optimal.
Business Scenario Driven Data-based Testing
Aspek bisnis dianalisis; skenario dikembangkan dari integrasi antar web service dan web service ↔ aplikasi; setup data dibuat berdasarkan skenario tersebut, mencakup skenario end-to-end.
Stubs
Dummy interface yang dibuat untuk keperluan testing service. Berbagai input diberikan lewat interface ini, output divalidasi. Ketika aplikasi memakai interface ke service eksternal yang tidak diuji (third-party), stub dibuat selama Integration Testing.
SOA Testing Tools
SoapUI, Postman, JMeter, Selenium, Katalon Studio, Apigee, JProfiler, HP Service Test, iTKO LISA, Parasoft SOA Test.
Mocking
Apa itu Mock Object?
Objek dummy yang menggantikan objek nyata yang tidak tersedia atau sulit dipakai dalam test case. (Definisi lebih ketat) mock object harus mampu mengatur ekspektasi dan menyediakan mekanisme self-validasi.
Mengapa Memakai Mock Object?
Menjaga desain decoupled; memeriksa penggunaan objek lain oleh kode; testing inside-out; mempercepat test; memudahkan menulis kode untuk resource bermasalah; menunda penulisan kelas; menguji komponen dalam isolasi; mempromosikan desain berbasis interface; mendorong komposisi dibanding inheritance; memperbaiki interface; menguji situasi unusual, unlikely, exceptional.
Kapan Memakai Mock Object?
- Perilaku non-deterministic/acak.
- Setup sulit.
- Perilaku sulit dipicu.
- Objek nyata lambat.
- Objek nyata punya/adalah UI.
- Test butuh query yang tidak tersedia di objek nyata.
- Objek nyata belum ada (mis. Tim A butuh
Y.ydari Tim B yang masih mengerjakan Y — Tim A bisa mockY.y).
To Mock or Not to Mock
| Mock | Jangan Mock |
|---|---|
| Kode yang langsung menjadi dependency kode diuji | Sekadar demi mocking — coba refactor dulu untuk hilangkan kebutuhan mock |
| Objek yang sulit dipakai/di-setup | Resource seperti database (jangan asal mock) |
| Objek dengan perilaku sulit diprediksi | Ketika menulis kode asli lebih mudah dari menulis mock |
| Objek yang butuh banyak resource / lambat / mahal komputasi | Yang justru memperlambat unit test |
Tools untuk Object Mocking
MockObjects framework, MockMaker, JMock, NMock, EasyMock (banyak dipakai).
Final Remark
SOA quality lebih dari sekadar testing service — dibutuhkan solusi komprehensif yang: (1) menguji fungsionalitas, performa, keamanan service; (2) mengelola SOA test (kualitas-hasil-test case); (3) terintegrasi dengan ekosistem SOA & siklus hidupnya.
Flashcard
flashcards Sebutkan 3 layer SOA Testing dan pendekatan top-down/bottom-up-nya :: Service level, Interface level, End-to-end level — Top-down dipakai untuk Test Designing, Bottom-up dipakai untuk Test Execution. Sebutkan 4 tier stages dalam SOA testing :: Tier 1 (Service level: functional, security, performance testing), Tier 2 (Process testing), Tier 3 (End-to-end testing), Tier 4 (Regression testing). Apa yang diuji dalam Functional testing di Tier 1? :: Apakah response yang diterima sesuai kebutuhan bisnis — kebutuhan diubah jadi test case & request statement, dicek responsenya, termasuk skenario error/negatif. Apa fokus Security testing di Tier 1? :: Enkripsi pada authentication/payment gateway saat parsing data, dan verifikasi kerentanan seperti CSRF & SQL Injection pada XML. Sebutkan 4 hal yang diuji Performance testing di Tier 1 :: Menentukan stabilitas, memvalidasi skalabilitas, memeriksa perilaku di bawah beban puncak, menemukan waktu respons lintas-service. Apa itu Stub dan kapan dipakai dalam SOA testing? :: Dummy interface untuk keperluan testing service; dipakai saat aplikasi memakai interface ke service eksternal (third-party) yang tidak diuji, dibuat selama Integration Testing. Apa perbedaan Mock object dan Stub secara umum? :: Stub menyediakan jawaban tetap untuk panggilan yang dibuat selama test, sedangkan Mock object bisa mengatur ekspektasi dan menyediakan mekanisme self-validasi terhadap bagaimana ia dipanggil. Sebutkan 3 kondisi kapan sebaiknya memakai Mock Object :: Perilaku objek nyata non-deterministic/acak, setup sulit, objek nyata lambat/punya UI/butuh banyak resource, atau objek nyata belum ada. Sebutkan komponen Traceability Matrix dalam Test Planning Approach SOA :: Menelusuri semua test case ke skenario bisnis (baik skenario umum maupun spesifik aplikasi), dibuat setelah aplikasi direorganisasi jadi komponen Data, Services, dan Front-end applications. Apa kesimpulan utama (Final Remark) tentang SOA quality? :: SOA quality lebih dari sekadar testing service — butuh solusi komprehensif yang menguji fungsionalitas/performa/keamanan, mengelola SOA test, dan terintegrasi dengan ekosistem & siklus hidup SOA.