Disain Test Case Inter-kelas

8.2.6 Disain Test Case Inter-kelas

Disain test case menjadi lebih rumit pada saat sistem OO dimulai. Pada tahap inilah testing kolaborasi diantara kelas harus dimulai. Untuk menggambarkan pembangkitan test case inter-kelas [KIR94], contoh perbankan yang diperkenalkan diperluas untuk mencakup kelas- Disain test case menjadi lebih rumit pada saat sistem OO dimulai. Pada tahap inilah testing kolaborasi diantara kelas harus dimulai. Untuk menggambarkan pembangkitan test case inter-kelas [KIR94], contoh perbankan yang diperkenalkan diperluas untuk mencakup kelas-

Gambar 8.2 Grafik kolaborasi kelas untuk aplikasi perbankan [KIR94]

Seperti testing kelas individu, testing kolaborasi kelas dapat dilakukan dengan mengaplikasikan metode partisi dan random serta scenario based testing dan kemudian tingkah laku.

Testing kelas bertingkat

Kirani dan Tsai [KIR94] mengusulkan urutan langkah berikut untuk memunculkan test case random kelas bertingkat:

By Hendranet

1. Untuk masing-masing kelas client , gunakan operator kelas untuk memunculkan sederetan urutan random testing . Operator tersebut akan mengirim pesan ke kelas server yang lain.

2. Untuk masing-masing pesan yang dimunculkan, tentukan kelas kolaborasi dan operator yang sesuai di dalam obyek server .

3. Untuk masing-masing operator pada obyek server (yang telah dipanggil oleh pesan yang dikirim dari obyek client ), tentukan pesan yang ditransmisikannya.

4. Untuk masing-masing pesan tersebut, tentukan tingkat operasi selanjutnya yang dilakukan dan gabungkan ke dalam urutan testing.

Untuk menggambarkan [KIR94], perhatikan urutan operasi untuk kelas bank relatif terhadap sebuah kelas ATM (pada gambar 8.2)

verifyAcct • verifyPIN • [[verifypolicy • withdrawreq] ⏐ depositReq ⏐ acctInfoREQ]”

Test case random untuk kelas bank dapat berupa: Test case #r3: verifyAcct • verifyPIN • depositReq Untuk memperhatikan kolaborator yang tercakup dalam tes tersebut, pesan-pesan yang sesuai dengan masing-masing operasi yang ditulis di dalam test case r3 dipertimbangkan.

Bank harus berkolaborasi dengan validationInfo untuk mengeksekusi verifyAcct dan verifyPIN . Bank harus berkolaborasi dengan Account untuk mengeksekusi depositReq . Dengan demikian, test case yang menggunakan kolaborasi yang ditulis di atas adalah: Test case#r4:

verifyAcct bank [validAcct validationInfo ] • verifyPIN bank • [validPin validationInfo • deposit Req • [deposit account ]

pendekatan untuk testing partisi kel as bertingkat sama dengan pendekatan yang digunakan untuk testing partisi dari kelas individ ual. Kelas tunggal dipartisi seperti dibahas sebelumnya, namun urutan testing diperluas untuk meliputi operasi-operasi yang dipanggil melalui pesan ke kelas-kelas yang berkolaborasi. Pendekatan alternatif mempartisi testing berdasarkan interface ke suatu kelas tertentu. Seperti diperlihatkan pada gambar 8.1, kelas bank menerima pesan dari ATM dan kelas cashier . Metode-metode di dalam bank dapat dites dengan mempartisi metode ke dalam metode-metode yang melayani ATM dan melayani cashier . Partisi state based dapat digunakan untuk menyaring partisi-partisi lebih lanjut.

Testing yang ditarik dari mod el tingkah laku

Sebelumnya kita telah membicarakan diagram state transition (STD) sebagai model yang merepresentasikan tingkah laku dinamis dari sebuah kelas. STD untuk suatu kelas dapat digu nakan untuk me mbantu mengurutkan testing yang akan menggunakan tingkah laku dinamis dari kelas tersebut (dan kelas-kelas yang berkolab orasi dengannya). Pada gambar

8.3 [KIR94] mengilustrasikan STD untuk kelas account yang dibahas sebelumnya. Dengan men gacu pada gambar tersebut, transisi awal bergerak melalui kead aan emptyacct dan

setupacct . Mayoritas dari semua tingkah laku untuk contoh-contoh kelas tersebut terjadi By Hendranet

sem entara di dalam keadaan workingacct . Penarikan akhir ( withdrawal final ) dan close menyebabkan kelas account membuat transisi ke keadaan non-workingacct dan deadacct sec ara berurutan .

Gambar 8.3 Digram state-transition untuk kelas account [KIR94]

Testing yang didisain harus mencapai semua cakupan keadaan {KIR94], di mana urutan ope rasi harus meny ebabkan kelas account melakukan transisi melalui semua keadaan yang diijinkan: Test case #s1:

open • setupAccnt • deposit(initial) • withdraw(final) • close Harus dicatat bahwa urutan itu identik dengan urutan testing min imum yang dibahas sebelumnya. Dengan menambahkan urutan testing ke urutan minimum: Test Case #s2:

open • setupAccnt • deposit(initial) • deposit • balance • credit • withdraw (final) • close

Tes t Case #s3: open • setupAccnt • deposit(initial) • deposit • withdraw • accntInfo • with draw(final) • close

Mas ih banyak lagi test case yang dapat dilakukan untuk memastikan apakah semua tingkah laku kelas tersebut telah diperiksa secara memadai. Dalam situasi di mana tingka h laku kelas men ghasilkan kolaborasi dengan satu kelas atau lebih, digunakan ST

D bertingkat untuk menelu suri aliran tingkah laku sistem tersebut. Mod el keadaan dapat dilewatkan dengan cara “ breadth first ” [MCG94]. Breadth First men yatakan secara lengsung bahwa test case memeriksa sebuah transis i tunggal, dan bahwa transisi baru akan dites hanya setelah transisi yang dites sebelumnya digunakan. Perhatikan obyek credit card yang dibahas di atas. Keadaan awal dari cr edit card adalah

und efined (tidak ada nomor credit card yang diberikan). Melalui pembacaan kartu kredit By Hendranet

sela ma suatu penjualan, obyek menerima kea daan defined , yaitu atribut card number dan exp iration date bersama dengan pengidentifik asi bank khusus ditetapkan. Kartu kredit submitted pada saat dikirim dari satu keadaan ke keadaan lain dapat dites dengan menggunakan test case yang menyebabkan terjadinya transisi. Pendekatan breadth first ke tipe testing ini tidak akan memerik sa submitted sebelum ia menggunakan undefined dan defined . Bila ya, submitted akan menggunakan transisi yang dites sebelumnya sehingga akan menyimpang dari kriteria braedth first .