Tugas RPL tentang UML dan digram UML serta Dasar-dasar pengujian perangkat lunak

                                                       

A.    UML (UNIFIED MODELING LANGUAGE)

1.      Pengertian UML

            UML (Unified Modeling Language) adalah sebuah bahasa untuk menetukan, visualisasi, kontruksi, dan mendokumentasikan artifact (bagian dari informasi yang digunakan atau dihasilkan dalam suatu proses pembuatan perangkat lunak. Artifact dapat berupa model, deskripsi atau perangkat lunak) dari system perangkat lunak, seperti pada pemodelan bisnis dan system non perangkat lunak lainnya.

            UML tidak hanya digunakan dalam proses pemodelan perangkat lunak, namun hampir dalam semua bidang yang membutuhkan pemodelan.

2.      BAGIAN-BAGIAN UML

Bagian-bagian utama dari UML adalah view, diagram

a.      View

View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram.

Beberapa jenis view dalam UML antara lain:

·         Use case view

·         Logical view

·         Component view

·          Concurrency view, dan

·         deployment View.

a)      Usecase view

Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya.

View ini digambarkan dalam use case diagrams dan kadang-kadang dengan activity diagrams. View ini digunakan terutama untuk pelanggan, perancang (designer), pengembang (developer), dan penguji sistem (tester).

b)      Logical view

Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object,dan relationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu.

View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence, collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk perancang (designer) dan pengembang (developer).

c)      Component view

Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administrative lainnya.

View ini digambarkan dalam component view dan digunakan untuk pengembang (developer).

d)     Concurrency view

Membagi sistem ke dalam proses dan prosesor. View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

e)      Deployment view

Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana hubungannya dengan lainnya.

View ini digambarkan dalam deployment diagrams dan digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

b.      Diagram

Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. Adapun jenis diagram antara lain :

·         Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai. Use case merupakan konstruksi untuk mendeskripsikan bagaimana system akan terlihat di mata user. Sedangkan use case diagram memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client.

·         Class Diagram

Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan relasi yang sama. Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah system. Hal tersebut tercermin dari class- class yang ada dan relasinya satu dengan yang lainnya. Sebuah sistem biasanya mempunyai beberapa class diagram. Class diagram sangat membantu dalam visualisasi struktur kelas dari suatu system.

·         Component Diagram

Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya.

Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.

Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

·         Deployment Diagram

Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal

·         Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).

Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.

Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.

·         Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.

·         Collaboration Diagram

Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message.

Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.

·         Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.

Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.

Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.

Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

3.      Tujuan Penggunaan UML

a)      Memberikan bahasa pemodelan yang bebas dari berbagai bahas pemrograman dan proses rekayasa.

b)      Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.

c)      Memberikan model yang siap pakai, bahsa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.

d)     UML bisa juga berfungsi sebagai sebuah (blue print) cetak biru karena sangat lengkap dan detail. Dengan cetak biru ini maka akan bias diketahui informasi secara detail tentang coding program atau bahkan membaca program dan menginterpretasikan kembali ke dalam bentuk diagram (reserve enginering).

4.      Langkah-Langkah Penggunaan UML

Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML

1.      Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.

2.      Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.

3.      Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.

4.      Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.

5.      Berdasarkan use case diagram, mulailah membuat activity diagram.

6.      Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.

7.      Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.

8.      Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.

9.      Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.

10.  Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.

11.  Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :

·         Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.

·         Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.

12.  Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.

13.  Piranti lunak siap dirilis.

Dari batasan masalah yang pemakalah batasi sebelumnya dapat dilihat bahwa Usecase diagram termasuk kepada bagian dari diagram UML.

Untuk lebih jelasnya mengenai Usecase Diagram,akan dibahas pada pembahasan selanjutnya.

B.     DIAGARAM USECASE

1.      Pengetian Diagram Usecase

            Digram usecase menggambarkan interaksi antara usecase dan aktor,dimana usecase merepresentasikan fungsionalitas sistem dan kebutuhan sistem dari sudut pandang pengguna.Sementara aktor merepresentasikan orang atau sistem yang menyediakan atau menerima informasi dari sistem.

            Dengan kata lain usecase merupakan sebuah pekerjaan tertentu,misalnya login kesistem,mencreate sebuah daftar belanja,dan sebagainya.

            Aktor sebuah entitas manusia atau mesin yang berinteraksi dengan sistem
untuk melakukan pekerjaan-pekerjaan tertentu.

            Diagram usecase mengggambarkan fungsionalitas yang diharapkan dari sebuah sistem,yang ditekankan adalah “apa”yang duat sistem,bukan “bagaimana”.

2.       Komponen/Elemen Pembentuk Diagram Usecase

           Agar kita mengerti mengenai Use Case diagram, maka pertama-tama kita harus mengerti dulu elemen-elemen atau komponen-komponen yang ada di dalamnya.

a.      Actor

           Pada dasarnya actor bukanlah bagian dari diagram usecase,namun untuk dapat terciptanya suatu diagram usecase diperlukan beberapa actor.Actor tersebut merepresentasikan seseorang atau sesuatu,seperti perangkat,sistem lain,alat eksternal dan waktu yang berinteraksi dengan sistem.

           Sebuah actor hanya dapat memberikan inputan informasi pada sistem atau hanya menerima informasi dari sistem.

           Actor hanya bisa berinteraksi dengan usecase tetapi tidak memiliki control atas usecase.

Actor memiliki beberapa tipe,tipe-tipe tersebut adalah :

a)      Pengguna Sistem

Merupakan gambaran secara fisik dan umum yang selalu ada pada setiap sistem.Beberapa ketentuan ketika memberi nama actor gunakan nama peranan dan jangan nama posise karena seorang individu dapat memainkan beberapa peranan,contoh:Andi adalah seorang pasien,namu dalam kesempatan lain ia menjadi pegawai puskesmas,maka ia memainkan peranan sebagai petugas kesehatan.

b)      Sistem yang lain dan berhubungan

Misalkan pada sebuah Sistem Informasi PUSKESMAS memerlukan koneksi denagn aplikasi sistem yang lain yaitu SIM Rumah Sakit.Maka pada tipe kedua ini actornya adalah SIM Rumah Sakit.

c)      Waktu

Wakut dapat menjadi actor jika seiring perjalanan waktu dapat memicu kejadian/even dalam sistem.

Misalkan bagian registrasi mendata pasien yang berulang tahun pada hari kesehatan anak untuk mendapat pengobatan secara gratis.Maka secara otomatis sistem menyeleksi pasien secara acak untuk mendapat hadiah tersebut.Karna waktu berada diluar kendali kita maka ia bisa menjadi actor.

b.      Use Case

           Adalah bagian fungsionalitas tingkat tinggi yang disediakan oleh sistem.Dengan kata lain, use case menggambarkan bagaimana seseorang menggunakan sistem.

           Cara menentukan Use Case dalam suatu sistem:

a)      Pola perilaku aplikasi perangkat lunak.

b)      Gambaran tugas dari sebuah actor.

c)      Sistem atau benda yang memberikan sesuatu yang bernilai kepada actor.

d)     Apa yang dikerjakan oleh suatu perangakat lunak bukan bagaimana cara mengerjakannya.

3.      Relationship

a.    Relasi Asosiasi

        Relasi antara actor dan use case.Dinotasikan seperti gambar berikut:

        Arah panah menunjukkan siapa yang mengawali komunikasi.

            Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data.

Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case.

 

Association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda .

b.      Relasi Include

        Memungkinkan satu use case menggunakan fungsionalitas yang disediakan oleh use case lainnya.

 

                          <>  termasuk didalam use case lain (required) / (diharuskan)      

•         Pemanggilan use case oleh use case lain, contohnya adalah  pemanggilan sebuah fungsi program

•         Tanda panah terbuka harus terarah ke sub use case

•         Gambarkan association include secara horizontal

c.       Relasi Extend

      <> perluasan dari use case lain jika kondisi atau syarat terpenuhi

–     Kurangi penggunaan association Extend ini, terlalu banyak  pemakaian association ini membuat diagram sulit dipahami.

–     Tanda panah terbuka harus terarah ke parent/base use case

–     Gambarkan association extend secara vertical

 

d.      Relasi Generelisasi

·      Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum

·      Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case

·      Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition)

 

4.      CONTOH USE CASE DIAGRAM (Proses bisnis)

Deskripsinya :

a.       Tata Usaha membuat jadwal.

b.      Jadwal dapat dilihat oleh guru dan siswa

c.       Tata Usaha membuat kartu ujian untuk siswa

d.      Tata  usaha mencetak raport siswa dan diserahkan kepada siswa

e.       Dan tata usaha cetak laporan tahunan dan diserahkan ke kepala sekolah

5.      PEMODELAN USE CASE

           Pemodelan Use-Case : proses modeling fungsi-fungsi sistem dalam terminologi kejadian bisnis (business events) yang memicu peristiwa, dan bagaimana sistem menanggapi kejadian tersebut

a.       Use-case modeling berakar dari object-oriented modeling. (pemodelan berorientasi obyek)

b.      Merupakan pelengkap dari alat-alat modeling tradisional. (seperti ER Diagram)

Manfaat pemodelan Usecase:

a.       Alat mendokumentasikan kebutuhan fungsional. 

b.      Membantu pembagian lingkup sistem sehingga lebih mudah diatur.

c.        Alat mengkomunikasikan fungsionalitas sistem pada pengguna dan stakeholder lain. Usecase memiliki bahasa yang dapat dimengerti oleh berbagai stakeholder.

d.       Membantu melakukan estimasi lingkup, upaya, dan jadwal sebuah proyek

e.       Dasar untuk melakukan testing (test plans dan test cases)

f.        Dasar untuk user help systems, manual dan dokumentasi sistem

g.       Alat untuk mengetahui kebutuhan  Titik awal untuk identifikasi obyek data atau entitas

h.      Spesifikasi fungsional untuk merancang user system interface

i.         Alat menentukan kebutuhan akses database (menambah, mengubah, menghapus, membaca)

j.         Kerangka untuk mengarahkan proyek pengembangan sistem.

DASAR-DASAR PENGUJIAN PERANGKAT LUNAK

1.      Proses Testing

a.       System Testing

Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system.

Component testing

·                     Pengujian komponen-komponen program

·                     Biasanya dilakukan oleh component developer(kecuali untuk system kritis)

Integration testing

·                     Pengujian kelompok komponen-komponen yang terintegrasi untuk membentuk sub-system ataupun system

·                     Dilakukan oleh tim penguji yang independent

·                     Pengujian berdasarkan spesifikasi sistem       

b.      Acceptance Testing

·                     Pengujian terakhir sebelum sistem dipakai oleh user.

·                     Melibatkan pengujian dengan data dari pengguna sistem.

·                     Biasa dikenal sebagai “alpha test” (“beta test” untuk software komersial, dimana pengujian dilakukan oleh potensial software komersial, dimana pengujian dilakukan oleh customer)

2.      Rencana Pengujian

a.       Proses testing

Deskripsi fase-fase utama dalam pengujian

b.      Pelacakan Kebutuhan

Semua kebutuhan user diuji secara individu

c.       Item yg diuji

Menspesifikasi komponen sistem yang diuji

d.      Jadual Testing

e.       Prosedur Pencatatan Hasil dan Prosedur

f.       Kebutuhan akan Hardware dan Software

g.      Kendala-kendala

Mis: kekuranga staff, alat, waktu dll.

3.      Failures, Faults

Failure: output yang tidak benar/tidak sesuai ketika sistem dijalankan

Fault: kesalahan dalam source code yang mungkin menimbulkan failure ketika code yg fault tsb dijalankan

4.      Prioritas Testing

a.       Hanya test yang meyakinkan sistem terbebas dari kesalahan, lengkap yang  dapat tetapi hal ini sangat sulit dilakukan.

b.      Prioritas dilakukan terhadap pengujian kemampuan sistem, bukan masing-masing komponennya.

c.       Pengujian untuk situasi yg tipikal lebih penting dibandingkan pengujian terhadap nilai batas.

5.      Test data dan kasus test

Test data:  Input yang   direncankan digunakan olehsistem.

Test cases:  Input yang digunakan untuk menguji sistem dan memprediksi output dari input jika sistem beroperasi sesuai dengan spesifikasi.

6.      Structural testing

·         Disebut juga white-box testing

·         Penentuan test case disesuaikan dengan struktur sistem. Knowledge program digunakan untuk mengidentifikasi test case tambahan.

·         Tujuannya untuk menguji semua statement program (debug).

DESAIN TES CASH

A.    Black Box Testing

Test case ini bertujuan untuk menunjukkan fungsi PL tentang cara
beroperasinya, apakah pemasukan data keluaran telah berjalan
sebagaimana yang diharapkan dan apakah informasi yang disimpan
secara eksternal selalu dijaga kemutakhirannya.

B.     White Box Testing

Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya
logikal path (jalur logika) perangkat lunak akan ditest dengan
menyediakan test case yang akan mengerjakan kumpulan kondisi dan
atau pengulangan secara spesifik. Secara sekilas dapat diambil
kesimpulan white box testing merupakan petunjuk untuk mendapatkan
program yang benar secara 100%.

UJI COBA WHITE BOX

Uji coba white box adalah metode perancangan test case yang
menggunakan struktur kontrol dari perancangan prosedural untuk
mendapatkan test case. Dengan rnenggunakan metode white box, analis
sistem akan dapat memperoleh test case yang menjamin seluruh independent path di dalam modul yang dikerjakansekurang-kurangnya sekali mengerjakan seluruh keputusan logikal mengerjakan seluruh loop yang sesuai dengan batasannya
· mengerjakan seluruh struktur data internal yang menjamin validitas

“UJI COBA BASIS PATH”

Uji coba basis path adalah teknik uji coba white box yg diusulkan
Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunakan ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur pengerjaan.

 Test case yg didapat digunakan untuk mengerjakan basis set
yg menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.

PENGUJIAN BLACK-BOX

·         Pengujian black-box berfokus pada persyaratan fungsional PL.

·         Pengujian ini memungkinkan analis system memperoleh kumpulan kondisi input yg akan mengerjakan seluruh keperluan fungsional program.

·         Tujuan metode ini mencari kesalahan pada:

Ø   Fungsi yg salah atau hilang

Ø   Kesalahan pada interface

Ø   Kesalahan pada struktur data atau akses database

Ø   Kesalahan performansi

Ø   Kesalahan inisialisasi dan tujuan akhir Metode ini tidak terfokus pada struktur kontrol seperti pengujian whitebox tetapi pada domain informasi.

“EQUIVALENCE PARTITIONING”

Equivalence partitioning adalah metode pengujian black-box yg memecah atau membagi domain input dari program ke dalam kelas-kelas data sehingga test case dapat diperoleh.

Perancangan test case equivalence partitioning berdasarkan evaluasi kelas
equivalence untuk kondisi input yg menggambarkan kumpulan keadaan yg
valid atau tidak. Kondisi input dapat berupa nilai numeric, range nilai,
kumpulan nilai yg berhubungan atau kondisi Boolean.

C.    PENGUJIAN BASIS DATA ( TUGAS BASIS DATA)

Pengujian basis data merupakan proses mengoperasikan basis data dengan kondisi tertentu, mengamati dan mencatat hasil yang diperoleh, kemudian membuat evaluasinya.

Basis data dioperasikan sedemikian rupa sehingga dapat dinilai:

·         kebenaran integritas data

·         pemenuhan semua informasi yang dibutuhkan

TUJUAN PENGUJIAN BASIS DATA

·         Menilai apakah basis data dapat menjaga integritas data yang disimpannya.

·         Menilai apakah basis data dapat memenuhi kebutuhan informasi yang sudah ditetapkan.

·         Menemukan kesalahan pada rancangan basis data, terutama yang tidak terlihat sebelumnya.

DASAR PENGUJIAN BASIS DATA

·         Kebutuhan informasi:

Ø  Laporan-laporan

Ø  Query

Ø  Informasi tertentu hasil inquiry, retrieve atau pencarian

·         Rancangan basis data:

Ø  Struktur tabel basis data

Ø  Keterkaitan antar tabel

OBJEK PENGUJIAN BASIS DATA

·         Koneksi ke basis data

·         Otoritas akses

·         Integrity constraint

·         Kebutuhan informasi  

PROSEDUR PENGUJIAN BASIS DATA

·         Tentukan objek apa yang akan diuji

·         Tentukan bagaimana cara pelaksanaan pengujian

·         Buat (bangun) kasus uji

·         Tentukan hasil yang diharapkan atau hasil yang sebenarnya

·         Laksanakan pengujian

·         Bandingkan hasil pengujian dengan hasil yang diharapkan

SIAPA YANG MELAKSANAKAN PENGUJIAN?

·         Database Tester

·         Software Tester

·         Database Administrator (DBA)

·         Pemakai basis data

Read More