Bab 3 — Materi + Quiz 11

🔗 Integration, System & Acceptance Testing

Dari menguji hubungan antar komponen, seluruh sistem, hingga penerimaan oleh pengguna akhir.

📑 Daftar Isi

  1. Bagian 1: Integration Testing
  2. Test Doubles (SANGAT PENTING!)
  3. Bagian 2: System Testing
  4. Bagian 3: Acceptance Testing
  5. Integration Testing untuk Keamanan
  6. Poin-Poin Penting
  7. Tips Menghafal
  8. Contoh Soal & Jawaban
  9. Latihan Soal Interaktif

📖 Bagian 1: Integration Testing

Integration Testing adalah pengujian yang menguji interaksi antar komponen/modul yang sudah diuji secara individual (unit test). Tujuannya memastikan komponen-komponen tersebut bisa bekerja sama dengan benar.

Analogi

Unit testing = tes setiap pemain bola satu per satu (dribble, tendangan). Integration testing = tes apakah pemain-pemain ini bisa kerja sama (passing, strategi). Masing-masing pemain mungkin jago sendiri, tapi belum tentu bisa kompak.

Pendekatan Integration Testing

1. Big Bang Integration

Semua komponen digabung sekaligus dan diuji bersama-sama.

2. Incremental Integration (Bertahap)

Komponen digabung dan diuji satu per satu secara bertahap. Ada 2 sub-pendekatan:

🔽 Top-Down

Pengujian dimulai dari modul paling atas (level tertinggi), lalu turun ke modul di bawahnya.

Modul bawah yang belum siap digantikan oleh Stub (komponen tiruan sederhana).

Urutan: Main Module → Sub-Module → Detail Module

🔼 Bottom-Up

Pengujian dimulai dari modul paling bawah (level terendah), lalu naik ke atas.

Modul atas yang belum siap digantikan oleh Driver (komponen yang memanggil modul bawah).

Urutan: Detail Module → Sub-Module → Main Module

💡 Tips Hafalan Pendekatan Integrasi

  • Big Bang = "Duarrr semua langsung" → gabungin semua sekaligus
  • Top-Down = "Dari atap ke lantai" → pakai Stub (pengganti modul bawah)
  • Bottom-Up = "Dari fondasi ke atap" → pakai Driver (pengganti modul atas)
  • Ingat: Stub = yang dibawah (karena stub itu "tiang" yang menopang dari bawah), Driver = yang menggerakkan dari atas

🎭 Test Doubles (SANGAT PENTING!)

Test Double adalah objek pengganti yang digunakan saat testing untuk menggantikan komponen asli yang belum siap atau sulit diakses. Ada 4 jenis:

JenisPenjelasanContoh
DummyObjek yang dikirim tapi tidak benar-benar digunakan. Hanya sebagai pengisi parameter.Mengirim objek kosong ke fungsi yang butuh parameter tapi isinya tidak penting untuk tes ini
FakeImplementasi nyata tapi disederhanakan. Berfungsi, tapi tidak untuk production.In-memory database (database palsu yang hidup di memori, bukan database sungguhan)
StubMengembalikan data statis/hardcoded yang sudah ditentukan sebelumnya. Untuk state verification.Fungsi yang selalu return "LUNAS" tanpa cek apapun
MockObjek dinamis yang bisa memverifikasi apakah method dipanggil dengan benar (parameter, frekuensi). Untuk behavior verification.Memverifikasi bahwa method send_email() dipanggil tepat 1 kali dengan parameter yang benar

⚠️ WAJIB PAHAM: Stub vs Mock

Ini yang paling sering keluar di soal dan paling sering membingungkan:

AspekStubMock
SifatStatis (hardcoded)Dinamis (berdasarkan ekspektasi)
Apa yang diverifikasi?State — "Apakah HASIL-nya benar?"Behavior — "Apakah METHOD-nya dipanggil dengan benar?"
MengembalikanNilai tetap yang sudah ditentukanBisa bervariasi + mencatat pemanggilan
Contoh di kodereturn "LUNAS" (selalu)verify(mock).sendEmail("user@mail.com")

Contoh Kode: Stub

# STUB: Selalu mengembalikan nilai statis "LUNAS" class StubPaymentService: def check_payment_status(self, order_id): return "LUNAS" # ← Selalu "LUNAS", tidak peduli order_id apa # Penggunaan dalam test: def test_order_completion(): stub = StubPaymentService() result = stub.check_payment_status("ORDER-123") assert result == "LUNAS" # State verification: cek NILAI hasilnya

Contoh Kode: Mock

# MOCK: Memverifikasi bahwa method dipanggil dengan benar from unittest.mock import Mock def test_send_notification(): mock_email = Mock() # Panggil fungsi yang menggunakan email service process_order(email_service=mock_email) # Behavior verification: cek APAKAH method dipanggil mock_email.send_email.assert_called_once_with("user@mail.com") # ↑ Bukan cek hasilnya, tapi cek PERILAKUNYA

💡 Tips Hafalan Stub vs Mock

  • Stub = "Statis" & "State" → Nilai tetap, cek hasil
  • Mock = "Monitoring" & "Method call" → Dinamis, cek apakah method dipanggil
  • Kalau di soal ada kode yang selalu return nilai yang sama → itu Stub
  • Kalau di soal ada verify() atau assert_called() → itu Mock

📖 Bagian 2: System Testing

System Testing adalah pengujian terhadap keseluruhan sistem yang sudah terintegrasi. Sistem diuji sebagai satu kesatuan yang utuh.

Jenis-Jenis System Testing

JenisMenguji Apa?Contoh
Functional TestingApakah fitur-fitur berfungsi sesuai requirementLogin, checkout, search berjalan benar
Performance TestingKecepatan dan kemampuan sistemResponse time < 2 detik
Security TestingKeamanan sistem dari ancamanSQL Injection, XSS tidak bisa dilakukan
Compatibility TestingKompatibilitas dengan berbagai platformBerjalan di Chrome, Firefox, Safari
Usability TestingKemudahan penggunaanUser bisa menyelesaikan task tanpa kebingungan
Recovery TestingKemampuan sistem pulih dari kegagalanSistem bisa restart setelah crash

📖 Bagian 3: Acceptance Testing

Acceptance Testing adalah pengujian terakhir sebelum software dianggap siap digunakan. Tujuannya memastikan software memenuhi kebutuhan bisnis dan diterima oleh pengguna/stakeholder.

Ada 2 jenis utama:

1. UAT (User Acceptance Testing)

Pengujian oleh pengguna akhir (end user) untuk memastikan software sesuai kebutuhan mereka.

Alpha Testing

Beta Testing

Contoh UAT

Skenario: Seorang mahasiswa mencoba fitur pengisian IRS (Isian Rencana Studi) di SIAKAD — menambah mata kuliah, menyimpan, dan mencetak KRS. Jika semua berjalan lancar dan sesuai kebutuhan, UAT berhasil.

2. OAT (Operational Acceptance Testing)

Pengujian oleh tim operasional/IT untuk memastikan software siap di-operasikan di production.

OAT menguji aspek operasional seperti:

Contoh OAT

Skenario: Admin IT melakukan restart server aplikasi, melakukan backup database, lalu memulihkan data dari backup tersebut. Jika semua berhasil, OAT lolos.

💡 Tips Hafalan UAT vs OAT

  • UAT = "User" → Dilakukan oleh pengguna akhir → "Apakah ini yang saya butuhkan?"
  • OAT = "Operational" → Dilakukan oleh tim IT/operasional → "Apakah ini bisa di-jalankan di server?"
  • Alpha = Awal = di dalam (internal)
  • Beta = Belakangan = di luar (eksternal, user sungguhan)

🔐 Integration Testing untuk Keamanan

Integration testing juga bisa digunakan untuk menguji keamanan di level interaksi antar komponen. Contoh paling umum:

Pengujian Injeksi pada Halaman Login

Menguji apakah form login bisa menangkal SQL Injection saat frontend mengirim data ke backend.

# Integration test: frontend + backend + database def test_login_sql_injection_integration(): # Simulasi user memasukkan payload SQL injection di form login response = client.post("/login", data={ "username": "' OR 1=1 --", "password": "anything" }) assert response.status_code == 401 # Login HARUS gagal assert "Login Failed" in response.text

📌 Poin-Poin Penting (WAJIB DIHAPAL)

✅ Ringkasan Kunci untuk UAS

  1. Integration Testing = menguji interaksi antar komponen
  2. Big Bang = gabung semua sekaligus, Top-Down = dari atas (pakai Stub), Bottom-Up = dari bawah (pakai Driver)
  3. Stub = nilai statis/hardcoded, untuk state verification (cek hasil)
  4. Mock = dinamis, untuk behavior verification (cek pemanggilan method)
  5. Kalau kode selalu return "LUNAS" → itu Stub
  6. Dummy = pengisi parameter saja, Fake = implementasi sederhana (misal in-memory DB)
  7. System Testing = menguji seluruh sistem sebagai satu kesatuan
  8. UAT = oleh pengguna akhir (mahasiswa coba IRS)
  9. OAT = oleh tim IT/operasional (admin restart server, backup database)
  10. Alpha = di internal, Beta = di eksternal (user sungguhan)

🧠 TIPS MENGHAFAL — Bab 3: Integration, System & Acceptance

  1. "Big Bang" = Gabung semuanya sekaligus.
  2. "Top-Down pakai Stub, Bottom-Up pakai Driver" → Ingat: Stub = penopang dari bawah (untuk Top-Down). Driver = sopir di atas (untuk Bottom-Up).
  3. "Stub vs Mock" (WAJIB INGAT) → Stub = Statis/Hardcoded (selalu return "LUNAS"). Mock = Dinamis/Verifikasi Pemanggilan (verify method).
  4. "Dummy vs Fake"Dummy = Cuma numpang lewat (pengisi parameter). Fake = Jalan beneran tapi sederhana (misal in-memory database).
  5. "System Testing = Seluruhnya" → Tes lengkap semua komponen jadi satu kesatuan (fungsional, load, security, dll).
  6. "UAT = User" → Dilakukan sama End User (pengguna asli) buat ngecek apakah sesuai kebutuhan mereka.
  7. "OAT = Operational/IT" → Dilakukan sama tim IT/Admin buat ngecek kesiapan server (backup, restore, instalasi).
  8. "Alpha = Internal, Beta = Eksternal" → Alpha di dalam kantor dev, Beta dilepas ke user asli di luar.

📝 Contoh Soal & Jawaban

Contoh Soal 1

Perhatikan kode berikut:

class PaymentStub: def get_status(self, order_id): return "LUNAS"

Kode di atas adalah contoh dari...

A. Mock
B. Fake
C. Stub
D. Driver

Jawaban: C (Stub) — Karena selalu mengembalikan nilai statis "LUNAS" tanpa logika apapun.

Contoh Soal 2

Seorang mahasiswa mencoba menambahkan mata kuliah di sistem IRS, menyimpan, dan mencetak KRS. Pengujian ini termasuk jenis apa?

A. Unit Testing
B. OAT (Operational Acceptance Testing)
C. UAT (User Acceptance Testing)
D. Regression Testing

Jawaban: C (UAT) — Karena dilakukan oleh pengguna akhir (mahasiswa) untuk memvalidasi kebutuhan mereka.

Contoh Soal 3

Admin IT melakukan restart server dan memulihkan database dari backup. Ini termasuk pengujian apa?

A. UAT
B. Integration Testing
C. Unit Testing
D. OAT (Operational Acceptance Testing)

Jawaban: D (OAT) — Karena dilakukan oleh tim operasional untuk memastikan kesiapan sistem di production.

🎮 Latihan Soal Interaktif — Integration, System & Acceptance

Kerjakan 15 soal berikut, lalu klik Submit untuk melihat hasilnya.

0/15
Skor Anda