Strategi testing C/S keseluruhan
9.2.1 Strategi testing C/S keseluruhan
Pad a umumnya, testing software C/S terjadi pada tiga tingkat yang berbeda: (1 ) aplikasi client individua l dites dalam cara yang “ diconnected ” / tak terhubung, artinya tidak
mem perhatikan pengoperasian server dan jaringan yang membawahinya; (2) software client dan aplikasi server terkaitnya dites bersama-sama, tetapi pengoperasian jaringannya tidak dija lankan sepenuhnya; (3) arsitektur C/S sepenuhnya, termasuk operasi jaringan dan pen ampilannya, dites. Wa laupun banyak jenis tes dilaksanakan pada masing-masing tingkat di atas dilakukan sec ara lebih mendetil, cara testing berikut biasa dijumpai untuk aplikasi C/S:
Tes fungsi aplikasi. Daya fungsi aplikasi client dites dengan memakai metode yang sudah dibicarakan pada buku ini. Intinya, aplikasi tersebut dites dalam model standar untuk menemukan kesalahan pengoperasiannya.
Tes server . Koordinasi dan fungsi manajemen data pada By Hendranet server dites. Kinerja server ( respon time dan data throuhput keseluruhan) juga diperhatikan. Tes database .K eakuratan / ketepatan dan integritas data yang disimpan oleh server dites. Transaksi yang dilakukan oleh aplikasi client diperiksa untuk memastikan bahwa data sudah disimpan dengan benar, diperbaharui, dan dipanggil kembali. Pengarsipan
juga dites. Testing transaksi. Serangkaian tes dibuat untuk memastikan bahwa masing-masing kelas transaksi diproses menurut pe rsyara nnya. Tes difokuskan pada ketepatan pemrosesan ta dan juga kinerjanya (misal: waktu pemrosesan transaksi dan testing volume transaksi). Testing komunikasi jaringan. Tes ini menguji apakah komunikasi antar nodes jaringan berlangsung dengan benar dan apakah pengiriman pesan, transaksi, dan jaringan terkait tanpa kesalahan. Tes keamanan jaringan mungkin juga dapat dilaksanakan sebagai bagian dari testing ini.
Unt uk melakuka n pendekatan testing tersebut, Musa (MUS93) menyarankan perkembangan profil operasional yang diambil dari skenario pemakai C/S. Profil operasional menunjukkan bagaimana jenis pemakai yang berbeda-beda ber-interoperasi dangan sistem C/S. artinya profil tersebut menyediakan pola penggunaan yang dapat diaplikasi ketika testing didisain
dan dilaksanakan. Misalnya, untuk jenis pemakai tertentu, berapa persen dari transaksi yang aka n diperiksa, diperbaharui, diurutkan? Unt uk mengemba ngkan profil operasional, penting untuk mengambil serangkaian skenario pem akai [BIN95]. Masing-masing skenario merujuk pada siapa, di mana, apa, dan mengapa. Artinya, siapakah pemakainya, di mana (dalam arsitektur C/S fisik) interaks i sistem terjadi, apa transaksinya, dan mengapa terjadi. Skenario dapat diambil selama pertemuan FAST atau lew at hal lain yang kurang formal dengan “pengguna akhir.” Tetapi hasilnya harus sama. T iap skenario harus menyedia kan indikasi fungsi sistem yang akan diperlukan untuk mel ayani pengguna tertentu, urutan yang memerlukan fungsi tersebut, timing dan respon yang di harapkan, dan frekuensi yang dengannya setiap fungsi digun akan. Data-data itu lalu diga bungkan (untuk semua pengguna) untuk menciptakan profil operasional. Strategi untuk menguji arsitektur C/S ini sama dengan strategi testing untuk sistem berbasis software . Testingnya dimulai dengan “ in-the-small ”, yaitu menguji aplikasi client tunggal. Integras i client , server , dan jaringan dites secara berurut an. Akhirnya, sistem keseluruhan dites sebagai satu entitas operasional. Testing model lama memandang modul/subsistem/integrasi sistem dan testing sendiri bers ifat top-down, bottom-up , atau variasi keduanya. Integrasi modul dalam perkembangan C/S mungkin punya beberapa aspek top-down atau bottom-up , tetapi integrasi dalam proyek C/S cenderung ke arah perkembangan pararel dan itegrasi moduln ya melewati semua tingkat disain. Jadi, testing integrasi dalam proyek C/S kadang-kadang paling baik dica pai dengan menggunakan pendekatan “ non incremental ” atau “ big bang ” Sist em yang memang tidak dibuat untuk m emakai perangkat keras dan software khusus ini mempengaruhi testing sistem. Sifat “ By Hendranet cross-paltform ” jaringan dari sistem C/S menuntut perh atian besar terhadap testing ko nfigurasi dan testing kompabilitas. Aturan tes konfigurasi mendorong tes sistem dalam semua lingkungan perangkat keras dan software tempat sistem akan dioperasikan. Tes kompabilitas memastikan interface yang kon sisten lewat platform perangkat keras dan software . Misalnya, interf ace jenis windows mungkin tampak berbeda tergantung pada lingkungan implementasinya, tetapi perilaku pem akai dasar yang sama harus menghasilkan hasil yang sama juga, apapun interface clie nt- nya , baik dari IBM, MS, Apple, dll.