BAB V HASIL UJI COBA DAN EVALUASI
5.3 Pengujian Fungsionalitas
5.3.4 Pengujian Sinkronisasi Basis Data
Uji coba ini dilakukan untuk menguji apakah fungsionalitas pengiriman data telah diimplementasikan dengan benar dan berjalan sebagaimana mestinya, serta akan dihitung selisih antara total waktu aplikasi berjalan dan waktu untuk memproses data (overhead). Uji coba akan didasarkan pada beberapa skenario untuk menguji validasi pengiriman data Sync ITS. Skenario pengujian terdari dari 5 bagian yaitu sebagai berikut.
1. Skenario pengiriman data awal. 2. Skenario pengiriman perubahan data.
3. Skenario sinkronisasi data pada tabel yang memiliki relasi terhadap tabel lain (prioritas).
4. Skenario sinkronisasi data pada tabel yang memiliki relasi terhadap tabel yang sama (self-reference). 5. Skenario melanjutkan sinkronisasi yang terputus. 6. Skenario kegagalan sinkronisasi
Gambar 5.2 Pengaturan Queue untuk Pengujian
5.3.4.1 Skenario Uji Coba 1
Skenario uji coba 1 merupakan skenario pengiriman data awal dari salah satu tabel. Kondisi ini merupakan sinkronisasi pertama antar tabel referensi ke tabel replika. Tabel yang digunakan adalah tabel unit dengan jumlah data 184 baris. Jumlah baris yang akan dikirimkan per chunk adalah 10 baris, sehingga total ada 19 chunk. Listener mendeteksi urutan chunk dengan menggunakan delivery_tag pada queue header. Skenario pengujian dijelaskan pada Tabel 5.10. Ilustrasi sinkronisasi diperlihatkan pada Gambar 5.3, Gambar 5.4, dan Gambar 5.5. Tabel 5.11 merupakan data berapa kali queue diproses saat sinkronisasi.
Tabel 5.10 Skenario Uji Coba 1
Nomor PE-008
Nama Sinkronisasi data awal
Tujuan Memeriksa fungsi pengiriman data awal dari tabel referensi ke tabel replika berfungsi atau tidak
Kondisi awal Data tabel referensi masih kosong
Skenario Administrator menjalankan perintah sinkronisasi
Masukan Perintah sinkronisasi Keluaran yang
diharapkan
Isi tabel referensi sama dengan tabel replika Hasil Pengujian Berhasil
77
Gambar 5.3 Isi Tabel Unit (Referensi)
Gambar 5.4 Isi Tabel Unit (Replika) Sebelum Sinkronisasi
Gambar 5.5 Isi Tabel Unit (Replika) setelah Sinkronisasi
5.3.4.2 Skenario Uji Coba 2
Skenario uji coba 2 merupakan skenario pengiriman perubahan data. Tabel yang digunakan adalah tabel unit dengan jumlah perubahan 2 baris. Jumlah baris yang akan dikirimkan per chunk adalah 10 baris, sehingga total ada 1 chunk. Listener mendeteksi urutan chunk dengan menggunakan delivery_tag pada queue header. Skenario pengujian dijelaskan pada Tabel 5.12Tabel 5.10. Ilustrasi sinkronisasi diperlihatkan pada Gambar 5.6, Gambar 5.7, dan Gambar 5.8. Tabel 5.13 merupakan log berapa kali queue diproses saat sinkronisasi.
Tabel 5.11 Jumlah Pemrosesan Queue Uji Coba 1
Delivery Tag Jumlah Waktu Proses (detik)
1 1 0,068997622 2 1 0,057002783 3 1 0,083241224 4 1 0,056241035 5 1 0,059452057 6 1 0,050045729 7 1 0,057916164 8 1 0,096057177 9 1 0,060996056 10 1 0,061323881 11 1 0,065600157 12 1 0,050021887 13 1 0,079592943 14 1 0,078892946 15 1 0,086414814 16 1 0,066524267 17 1 0,05420661 18 1 0,054302931 19 1 0,018675089
Total Per Data 1,205505371
Total Waktu Pemrosesan 1,233798742 Overhead 0.028293
79
Tabel 5.12 Skenario Uji Coba 2
Nomor PE-009
Nama Sinkronisasi perubahan data.
Tujuan Memeriksa fungsi pengiriman perubahan data dari tabel referensi ke tabel replika berfungsi atau tidak.
Kondisi awal Data tabel referensi sudah terisi.
Skenario Administrator menjalankan perintah sinkronisasi
Masukan Perintah sinkronisasi. Keluaran yang
diharapkan
Isi tabel referensi sama dengan tabel replika. Hasil Pengujian Berhasil.
Gambar 5.6 Data pada Tabel Referensi
Gambar 5.7 Perubahan Data
Tabel 5.13 Jumlah Pemrosesan per Queue Uji Coba 2
Delivery Tag Jumlah diproses Waktu Proses (detik)
1 1 0,020329704
Total Per Data 0,020329704
Total Waktu Pemrosesan 0,030311210 Overhead 0,009981506 5.3.4.3 Skenario Uji Coba 3
Skenario uji coba 3 adalah sinkronisasi data pada tabel yang memiliki relasi terhadap tabel lain (prioritas). Tabel yang digunakan pada skenario ini adalah tabel unit dan stakeholder. Relasi stakeholder dan unit seperti pada Gambar 5.9. Tabel stakeholder berisi 100 data (10 chunk), sedangkan tabel unit berisi 184 data (19 chunk). Skenario dijelaskan pada Tabel 5.14. Gambar 5.11 dan Gambar 5.3 merupakan data pada tabel referensi. Gambar 5.4 dan Gambar 5.10 merupakan data pada tabel replika sebelum sinkronisasi. Gambar 5.5 dan Gambar 5.12 merupakan tabel replika setelah sinkronisasi. Tabel 5.15 merupakan tabel yang menunjukkan berapa kali queue diproses oleh listener.
81
Tabel 5.14 Skenario Uji Coba 3
Nomor PE-010
Nama Sinkronisasi tabel yang berelasi.
Tujuan Memeriksa fungsi pengiriman data berdasarkan prioritas berfungsi atau tidak. Kondisi awal Data tabel referensi sudah terisi. Tabel replika
masih kosong.
Skenario Administrator menjalankan perintah sinkronisasi
Masukan Perintah sinkronisasi. Keluaran yang
diharapkan
Isi tabel referensi sama dengan tabel replika. Hasil
Pengujian
Berhasil.
Gambar 5.10 Data Tabel Stakeholder (Replika) sebelum Sinkronisasi
Gambar 5.11 Data Tabel Stakeholder (Referensi)
Tabel 5.15 Jumlah Pemrosesan Stakeholder per Queue Uji Coba 3
Delivery Tag Jumlah Proses Waktu Proses (detik)
1 1 0,127249969 2 1 0,034129903 3 1 0,045481235 4 1 0,034972972 5 1 0,031919003 6 1 0,046865566 7 1 0,031229704 8 1 0,017913134 9 1 0,031101568 10 1 0,028483561
Total Per Data1 0,42934662
Total Waktu Pemrosesan 0,43211234
Overhead 0,002766
5.3.4.4 Skenario Uji Coba 4
Skenario uji coba 4 adalah sinkronisasi data pada tabel yang memiliki relasi terhadap diri sendiri (self-reference). Tabel 5.16 merupakan skenario pengujian uji coba 4. Tabel yang digunakan pada uji coba ini adalah tabel stakeholder. Kolom parent_id merupakan kolom yang mereferensi kolom id. PDM tabel stakeholder seperti Data tabel stakeholder dimodifikasi agar mempunyai data circular, yaitu data dengan id 4 dan 15. Gambar 5.9. Ilustrasi skenario uji coba 4 seperti Gambar 5.13, Gambar 5.10 dan Gambar 5.14. Tabel 5.17 merupakan tabel pemrosesan data per queue. Tabel 5.17 menunjukkan bahwa delivery tak 1 diproses 2 kali, karena ketika proses penambahan data, data dengan id 15 belum masuk. Sehingga dilakukan penambahan data tanpa foreign key lalu queue dipublish ulang dan diletakkan pada urutan queue terakhir. Pada iterasi kedua, data dengan id 4 diperbarui. Data dengan id 15 hanya diproses sekali karena data dengan id 4 sudah masuk pada iterasi pertama.
83
Tabel 5.16 Skenario Uji Coba 4
Nomor PE-011
Nama Sinkronisasi tabel yang berelasi terhadap diri sendiri.
Tujuan Memeriksa fungsi pengiriman data yang berelasi terhadap diri sendiri berfungsi atau tidak.
Kondisi awal Data tabel referensi sudah terisi. Tabel replika masih kosong.
Skenario Administrator menjalankan perintah sinkronisasi
Masukan Perintah sinkronisasi. Keluaran yang
diharapkan
Isi tabel referensi sama dengan tabel replika. Hasil
Pengujian
Berhasil.
Gambar 5.13 Data Stakeholder (Referensi)
Tabel 5.17 Jumlah Pemrosesan Queue pada Uji Coba 4
Delivery Jumlah Proses Waktu Proses (detik)
1 2 0,127249969 2 1 0,034129903 3 1 0,045481235 4 1 0,034972972 5 1 0,031919003 6 1 0,046865566 7 1 0,031229704 8 1 0,017913134 9 1 0,031101568 10 1 0,028483561
Total Per Data 0,020329704
Total Waktu Pemrosesan 0,030311210 Overhead 0,009981506 5.3.4.5 Skenario Uji Coba 5
Skenario uji coba 5 adalah melanjutkan sinkronisasi yang putus. Skenario uji coba 5 seperti Tabel 5.18. Hasil uji coba 5 seperti Gambar 5.11, Gambar 5.10 dan Gambar 5.12.
85
Tabel 5.18 Skenario Uji Coba 5
Nomor PE-012
Nama Melanjutkan sinkronisasi yang putus.
Tujuan Memeriksa fungsi melanjutkan sinkronisasi yang terputus berfungsi atau tidak.
Kondisi awal Data tabel referensi sudah terisi. Tabel replika masih kosong.
Skenario 1. Administrator menjalankan perintah sinkronisasi
2. Listener tiba2 dimatikan. 3. Listener dihidupkan kembali. Masukan Perintah sinkronisasi.
Keluaran yang diharapkan
Bisa melanjutkan sinkronisasi walaupun koneksi terputus. Isi tabel referensi sama dengan tabel replika.
Hasil Berhasil.
Tabel 5.19 Hasil Pemrosesan per Queue
Delivery Tag Jumlah Proses Waktu Proses (detik)
1 2 0,126240969 2 1 0,034689903 3 1 0,045480251 4 1 0,034977198 5 1 0,031919003 6 1 0,046765566 7 1 0,030329704 8 1 0,010913134 9 1 0,031001568 10 1 0,02878356
Total Per Data 0,421100855
Total Waktu Pemrosesan 0,462546825 Overhead 0,041445971
5.3.4.6 Skenario Uji Coba 6
Skenario uji coba 6 merupakan skenario mendeteksi kegagalan sinkronisasi. Gagal sinkronisasi disebabkan oleh beberapa hal seperti salah mapping sehingga tipe data tidak sesuai atau kesalahan pada kode. Tabel 5.20 merupakan skenario pengujian uji coba 6. Gambar 5.15 menunjukkan ketidaksesuaian mapping dari kolom tabel referensi ke tabel replika. Kolom id (integer) ke kolom name (string), dan sebaliknya. Gambar 5.16 menunjukkan sebelum sinkronisasi dijalankan, tidak ada catatan error. Setelah sinkronisasi dijalankan, listener mengalami gagal proses sehingga Sync ITS mencatat kegagalan tersebut. Contoh hasil pencatatan kegagalan seperti Gambar 5.17.
Tabel 5.20 Skenario Uji Coba 6
Nomor PE-013
Nama Mendeteksi kegagalan sinkronisasi
Tujuan Memeriksa fungsi mendeteksi kegagalan sinkronisasi berfungsi atau tidak.
Kondisi awal 1. Data tabel referensi sudah terisi. 2. Tabel replika masih kosong.
3. Tipe data kolom referensi dan kolom replika tidak sama.
Skenario Administrator menjalankan perintah sinkronisasi
Masukan Perintah sinkronisasi Keluaran yang
diharapkan
Bisa mendeteksi kegagalan dan mencatat kegagalan ke basis data
87
Gambar 5.15 Mapping Tabel Referensi ke Tabel Replika
Gambar 5.16 Tampilan Error Log sebelum Sinkronisasi