NAMA : ANNISA APRILYA
NPM : 43A87007150346
KELAS : S1/SI/3B/P
BAB 7
CODING DAN PENGUJIAN UNIT
7.1 Pemrograman Prinsip dan Pedoman
Tugas utama sebelum programmer untuk menulis kode yang dapat dibaca dengan beberapa kesalahan di dalamnya. Sebuah gol tambahan adalah untuk menulis kode cepat. Menulis kode padat adalah keterampilan yang hanya dapat diperoleh dengan praktek. Namun, berdasarkan pengalaman, beberapa aturan umum dan pedoman dapat diberikan untuk programmer. pemrograman yang baik (Memproduksi program yang benar dan sederhana) adalah independen praktek target bahasa pemrograman, meskipun bahasa pemrograman yang terstruktur dengan baik membuat pekerjaan programmer sederhana. Pada bagian ini, kita akan membahas beberapa konsep dan praktek yang dapat membantu programmer menulis kode berkualitas tinggi yang juga lebih mudah untuk dipahami.
7.1.1 Pemrograman Terstruktur
Seperti yang dinyatakan sebelumnya tujuan dasar dari kegiatan coding adalah untuk menghasilkan pro-gram yang mudah dimengerti. Telah dikemukakan oleh banyak bahwa praktek pemrograman terstruktur membantu mengembangkan program yang lebih mudah untuk dipahami. Gerakan pemrograman terstruktur dimulai pada tahun 1970-an, dan banyak yang telah dikatakan dan ditulis tentang hal itu. Meskipun ekstensif menggunakan gotos tentu tidak diinginkan, program terstruktur dapat ditulis dengan menggunakan gotos. Berikut kami berikan diskusi singkat tentang apa pemrograman terstruktur adalah.
Sebuah program memiliki struktur statis serta struktur yang dinamis. Struktur statis adalah struktur teks dari program, yang hanya orga-nization linear laporan program. Struktur dinamis dari program ini adalah urutan pernyataan dijalankan selama pelaksanaan program. Dengan kata lain, baik struktur statis dan perilaku dinamis adalah urutan laporan; sedangkan urutan mewakili struktur statis dari sebuah program adalah tetap, urutan laporan dijalankan dapat berubah dari eksekusi eksekusi.
Ini jelas akan lebih mudah untuk memahami perilaku dinamis jika struktur dalam perilaku dinamis menyerupai struktur statis. Semakin dekat persesuaian antara pelaksanaan dan struktur teks, semakin mudah program ini adalah untuk memahami, dan lebih dipahami struktur selama eksekusi, semakin sulit akan berdebat tentang perilaku dari teks program. Tujuan dari pemrograman terstruktur adalah untuk memastikan bahwa struktur statis dan struktur dinamis adalah sama. Artinya, tujuan dari pemrograman terstruktur adalah menulis program sehingga urutan laporan dijalankan selama mantan ecution dari sebuah program adalah sama dengan urutan pernyataan dalam teks program itu. Seperti pernyataan dalam teks program yang diselenggarakan secara linear, tujuan dari pemrograman terstruktur menjadi mengembangkan program yang kontrol aliran selama eksekusi adalah linier dan mengikuti organisasi linear dari teks program.
Menggunakan notasi Hoare ini , untuk memverifikasi program, pernyataan dasar tentang segmen program ini dalam bentuk
P {S}Q.
Penafsiran ini adalah bahwa jika pernyataan P benar sebelum mengeksekusi S, maka pernyataan Q akan menjadi kenyataan setelah melaksanakan S, jika eksekusi S berakhir. Sikap tegas P adalah pra-kondisi program dan Q adalah pasca-kondisi. pernyataan ini adalah tentang nilai-nilai yang diambil oleh variabel dalam program sebelum dan setelah pelaksanaannya. Pernyataan umumnya tidak menentukan nilai nominal tertentu untuk variabel, tetapi mereka menentukan sifat umum dari nilai-nilai dan hubungan di antara mereka.
Gunakan pemrograman terstruktur di mana program ini adalah urutan yang sesuai single-entry konstruksi single-exit membuat program yang mudah untuk memahami dan memverifikasi. praktek-praktek lainnya seperti menggunakan menyembunyikan informasi, cocok coding stan-dards, dan praktek pemrograman yang baik juga membantu meningkatkan pembacaan kode dan kualitas. Tujuan dasar menggunakan konstruksi terstruktur adalah untuk linearize aliran kontrol sehingga perilaku eksekusi lebih mudah untuk di bawah-berdiri dan berdebat tentang. Dalam aliran kontrol linier, jika kita memahami perilaku masing-masing konstruksi dasar benar, perilaku program dapat dianggap sebagai komposisi perilaku dari laporan. Untuk pendekatan ini untuk bekerja, itu tersirat bahwa kita dapat dengan jelas memahami dan menentukan perilaku setiap konstruk.
Titik utama adalah bahwa setiap konstruk tidak terstruktur harus digunakan hanya jika alternatif terstruktur lebih sulit untuk memahami. Pandangan ini dapat diambil hanya karena kita berfokus pada pembacaan. Jika tujuannya adalah pemastian formal, pemrograman terstruktur mungkin akan diperlukan.
7.1.2 Informasi Menyembunyikan
Sebuah solusi perangkat lunak untuk masalah selalu berisi struktur data yang dimaksudkan untuk mewakili informasi dalam domain masalah. Artinya, ketika perangkat lunak dikembangkan untuk memecahkan masalah, perangkat lunak menggunakan beberapa struktur data untuk menangkap informasi dalam domain masalah.
Secara umum, hanya operasi tertentu dilakukan pada beberapa informasi. Artinya, sepotong informasi dalam masalah domain hanya digunakan dalam sejumlah cara dalam domain masalah. Sebagai contoh, sebuah buku besar di akuntan memiliki beberapa kegunaan yang sangat jelas: debit, kredit, memeriksa saldo, dll Sebuah operasi di mana semua debet dikalikan bersama-sama dan kemudian dibagi dengan jumlah semua kredit biasanya tidak dilakukan.
Ketika informasi tersebut direpresentasikan sebagai struktur data, prinsip yang sama harus diterapkan, dan hanya beberapa operasi yang didefinisikan harus dilakukan pada struktur data. Ini, pada dasarnya, adalah prinsip bersembunyi informasi. Informasi yang ditangkap dalam struktur data harus disembunyikan dari sisa dari sistem, dan hanya akses fungsi pada struktur data yang mewakili operasi yang dilakukan pada informasi yang harus terlihat. Dengan kata lain, ketika informasi tersebut ditangkap di struktur data dan kemudian pada struktur data yang mewakili beberapa informasi, untuk setiap operasi pada informasi fungsi akses harus disediakan.
Untuk pengembang, hal ini sangat efektif untuk mengembangkan kode secara bertahap. Hal ini dapat dilakukan dengan menulis kode sedikit demi sedikit, dan pengujian dan debugging setiap kenaikan sebelum menulis kode lebih. Atau, pengembangan uji-driven dapat diikuti di mana uji kasus yang ditulis pertama dan kemudian kode ditulis untuk lulus uji kasus ini. Meskipun coding dari modul umumnya dilakukan oleh programmer individu, alternatif adalah pasangan pemrograman, di mana coding dilakukan oleh sepasang programmer-baik strategi bersama-sama berkembang, struktur data, algoritma dll.
7.1.3 Beberapa Praktek Pemrograman
Konsep yang dibahas di atas dapat membantu dalam menulis kode sederhana dan jelas dengan beberapa bug. Ada banyak praktek pemrograman yang juga dapat membantu ke arah tujuan itu. Kita bahas di sini beberapa aturan yang telah ditemukan untuk membuat kode lebih mudah dibaca serta menghindari beberapa kesalahan.
Informasi Menyembunyikan: Seperti telah dibahas sebelumnya, informasi bersembunyi harus didukung mana mungkin. Hanya fungsi akses untuk struktur data harus dibuat terlihat saat bersembunyi struktur data di balik fungsi tersebut.
Jenis Buatan Pengguna: bahasa modern memungkinkan pengguna untuk menentukan jenis seperti tipe enumerasi. Ketika fasilitas tersebut tersedia, mereka harus ex-ploited mana yang berlaku.
Nesting: Jika bersarang jika-maka-lain konstruksi menjadi terlalu dalam, maka logika menjadi sulit untuk memahami.
Modul Ukuran: Kami membahas masalah ini selama desain sistem. Seorang programmer harus hati-hati memeriksa setiap fungsi dengan terlalu banyak laporan (mengatakan lebih dari 100). modul besar sering tidak akan fungsional kohesif. Tidak ada aturan keras-dan-cepat tentang ukuran modul; prinsip harus kohesi dan kopling.
Modul Interface: Sebuah modul dengan antarmuka yang kompleks harus diteliti dengan seksama. Sebagai aturan praktis, setiap modul yang antarmuka memiliki lebih dari lima parameter harus diteliti dengan seksama dan patah menjadi beberapa modul dengan antarmuka sederhana jika mungkin.
Kode Berkembang perlu dikelola dengan baik. Hal ini dapat dilakukan melalui kontrol alat kode sumber yang tepat yang memungkinkan manajemen mudah dari versi berbeda yang bisa dibuat, serta mudah kehancuran perubahan yang perlu digulung kembali.
7.1.4 Standar Coding
Secara umum, standar coding memberikan pedoman bagi programmer mengenai
penamaan, organisasi berkas, pernyataan dan deklarasi, dan tata letak dan komentar. Untuk memberikan gambaran tentang standar pengkodean (sering disebut konvensi atau gaya
pedoman), kita membahas beberapa panduan untuk Java, berdasarkan tersedia untuk umum standar (dari www.geosoft.no atau java.sun.com/docs).
Mengomentari dan Layout Komentar adalah pernyataan tekstual yang dimaksudkan
untuk program pembaca untuk membantu pemahaman kode. Tujuan dari komentar tidak menjelaskan dalam bahasa Inggris logika program-jika logika begitu kompleks yang memerlukan komentar untuk menjelaskannya, lebih baik untuk menulis ulang dan
menyederhanakan kode sebaliknya.
Secara umum, komentar harus menjelaskan apa kode melakukan atau mengapa kode yang ada, sehingga kode dapat menjadi hampir-standar dalone untuk memahami sistem. Komentar umumnya harus disediakan untuk blok kode, dan dalam banyak kasus, hanya komentar untuk modul perlu disediakan.
Menyediakan komentar untuk modul yang paling berguna, sebagai modul membentuk unit
pengujian, kompilasi, verifikasi, dan modifikasi. Komentar untuk modul yang sering disebut prolog untuk modul, yang menggambarkan fungsi dan Tujuan dari modul, antarmuka publik dan bagaimana modul yang akan digunakan, parameter antarmuka, asumsi itu membuat tentang parameter, dan efek samping itu. Fitur lain dapat juga dimasukkan. Perlu dicatat bahwa prolog berguna hanya jika mereka tetap konsisten dengan logika modul. Jika modul tersebut dimodifikasi, maka prolog juga harus diubah jika diperlukan.
Java menyediakan komentar dokumentasi yang dibatasi oleh "/ ** ... * /", dan yang bisa diambil ke file HTML. Komentar ini sebagian besar digunakan sebagai prolog untuk kelas dan metode-metode dan bidang, dan dimaksudkan untuk memberikan dokumentasi untuk pengguna kelas yang mungkin tidak memiliki akses ke sumber kode. Selain prolog untuk modul, standar pengkodean dapat menentukan bagaimana dan di mana komentar harus berada. Beberapa pedoman tersebut adalah:
- Satu baris komentar untuk blok kode harus sejajar dengan kode mereka dimaksudkan untuk.
- Harus ada komentar untuk semua variabel utama menjelaskan apa yang mereka wakili.
- Sebuah blok komentar harus didahului oleh kosong baris komentar hanya dengan "/ *" dan diakhiri dengan baris yang berisi hanya "* /".
- Trailing komentar setelah laporan harus singkat, pada baris yang sama, dan bergeser cukup jauh untuk memisahkan mereka dari laporan.
Pedoman tata letak fokus pada bagaimana program harus menjorok, bagaimana seharusnya menggunakan baris kosong, ruang putih, dll, untuk membuatnya lebih mudah dibaca. Lekukan
pedoman kadang-kadang disediakan untuk setiap jenis pemrograman membangun.
Namun, kebanyakan programmer belajar ini dengan melihat kode dari orang lain dan
Kode fragmen dalam buku-buku dan dokumen, dan banyak dari ini telah menjadi cukup
standar selama bertahun-tahun. Kita tidak akan membahas mereka lebih jauh kecuali untuk mengatakan bahwa programmer harus menggunakan beberapa konvensi, dan menggunakannya secara konsisten.
7.2 Bertahap Mengembangkan Kode
Aktivitas coding dimulai ketika beberapa bentuk desain yang telah dilakukan dan spesifikasi dari modul untuk dikembangkan tersedia. Dengan desain, modul ditugaskan untuk pengembang untuk coding. Ketika modul ditugaskan untuk pengembang, mereka menggunakan beberapa proses untuk mengembangkan kode.
7.2.1 Sebuah Incremental Coding Proses
Proses diikuti oleh banyak pengembang untuk menulis kode untuk modul yang saat ini ditetapkan, dan ketika dilakukan, melakukan unit testing di atasnya dan memperbaiki bug yang ditemukan. Maka kode tersebut akan diperiksa dalam repositori proyek untuk membuatnya tersedia untuk orang lain dalam proyek tersebut. (Kami akan menjelaskan proses memeriksa kemudian.)
Sebuah proses yang lebih baik untuk coding, yang sering diikuti oleh berpengalaman pengembang, adalah untuk mengembangkan kode secara bertahap. Artinya, menulis kode untuk im-plementing hanya bagian dari fungsi modul. Kode ini disusun dan diuji dengan beberapa tes cepat untuk memeriksa kode yang telah ditulis sejauh ini. Ketika kode melewati tes ini, pengembang hasil untuk menambah fungsionalitas lebih lanjut untuk kode, yang kemudian diuji lagi.
7.2.2 Uji-Driven Development
Test-Driven Development (TDD) adalah proses coding yang berbalik pendekatan umum untuk coding. Alih-alih menulis kode dan kemudian mengembangkan kasus uji untuk memeriksa kode, di TDD itu adalah sebaliknya-programmer pertama menulis skrip tes, dan kemudian menulis kode untuk lulus tes. Seluruh proses dilakukan secara bertahap, dengan tes yang ditulis berdasarkan spesifikasi dan kode yang ditulis untuk lulus tes.
Beberapa poin yang perlu diperhatikan tentang TDD. Pertama, pendekatan mengatakan bahwa Anda menulis kode hanya cukup untuk lulus tes. Dengan mengikuti ini, kode ini selalu sinkron dengan tes. Hal ini tidak selalu terjadi dengan pendekatan kode-pertama, di mana itu semua terlalu umum untuk menulis sepotong panjang kode, tapi kemudian hanya menulis beberapa tes yang hanya mencakup beberapa bagian kode.
Tulisan ini kasus uji sebelum kode ditulis membuat pengembangan penggunaan-driven. Sejak kasus uji harus tertulis pertama dari spesifikasi, bagaimana kode tersebut akan digunakan mendapat perhatian pertama. Ini akan membantu memastikan bahwa interface dari perspektif pengguna kode dan skenario penggunaan kunci. Hal ini dapat membantu mengurangi kesalahan antarmuka.
Dalam TDD, beberapa jenis prioritas untuk pengembangan kode alami hap-pena. Hal ini kemungkinan besar bahwa beberapa tes pertama cenderung fokus pada menggunakan fungsi utama. Umumnya, kasus uji untuk fitur-prioritas yang lebih rendah atau func-tionality akan dikembangkan kemudian.
7.2.3 Pair Programming
Pair programming juga merupakan proses coding yang telah diusulkan sebagai metodologi kunci tech-nique dalam pemrograman ekstrim (XP) [7]. Dalam pemrograman pasangan, kode tidak ditulis oleh programmer individu tetapi oleh sepasang programmer. Artinya, pekerjaan coding ditugaskan untuk tidak individu tetapi untuk sepasang individu. Pasangan ini bersama-sama menulis kode.
Proses dipertimbangkan adalah bahwa satu orang akan ketik program sementara yang lain akan secara aktif berpartisipasi dan terus-menerus meninjau apa yang sedang diketik. Ketika kesalahan perhatikan, mereka menunjukkan dan diperbaiki. Jika diperlukan, pasangan membahas algoritma, struktur data, atau strategi yang akan digunakan dalam kode yang akan ditulis. Peran yang diputar sering membuat kedua pasangan sama dan memiliki peran yang sama.
7.3 Mengelola Berkembang Kode
Selama proses coding, kode yang ditulis oleh programmer (atau sepasang) berevolusi-mulai dari nol untuk akhirnya memiliki modul teruji. Selama proses ini kode mengalami perubahan. Selain perubahan karena proses pembangunan, perubahan kode juga dibutuhkan karena perubahan spesifikasi modul, yang mungkin terjadi karena perubahan persyaratan. Sedemikian skenario dinamis, mengelola kode berkembang adalah sebuah tantangan. Di sini kita membahas dua aspek ini-bagaimana mengelola perbedaaan versi yang bisa dibuat, dan bagaimana mempertahankan kualitas kode di bawah perubahan.
7.3.1 Source Code Control dan Build
Dalam proyek banyak beberapa orang mengembangkan kode sumber. Setiap programmer membuat file sumber, yang akhirnya digabungkan bersama-sama untuk menciptakan executable. Programmer terus berubah file sumber mereka sebagai kode berevolusi, seperti yang kita lihat dalam proses dibahas di atas, dan sering membuat perubahan dalam file sumber lain juga. Dalam rangka menjaga kontrol atas sumber dan evolusi mereka, kontrol kode sumber hampir selalu digunakan dalam proyek-proyek menggunakan alat seperti CVS pada UNIX (www.cvshome.org) atau sumber visual aman (VSS) pada Windows (msdn.microsoft.com / VStudio / sebelumnya / ssafe). Di sini kita memberikan penjelasan singkat tentang bagaimana alat ini digunakan dalam proses coding. Diskusi kita didasarkan pada CVS.
Sebuah sistem kontrol sumber kode yang modern berisi repositori, yang essen-tially struktur direktori dikontrol, yang membuat sejarah revisi penuh dari semua file yang dihasilkan oleh programmer didalam tim proyek. Untuk e FFI efisiensi, sejarah berkas umumnya disimpan sebagai delta atau increment dari file base. Hal ini memungkinkan setiap versi lama dari file yang akan dibuat ulang, sehingga memberikan fleksibilitas untuk dengan mudah membuang perubahan, harus perlu timbul. repositori adalah juga "o FFI resmi" sumber untuk semua file.
7.3.2 Refactoring
Refactoring adalah teknik untuk meningkatkan kode yang ada dan mencegah kerusakan desain ini dengan waktu. Refactoring adalah bagian dari coding di bahwa itu dilakukan selama masa coding, tetapi tidak coding biasa. Refactoring telah dipraktekkan di masa lalu oleh programmer, tetapi baru-baru ini telah mengambil bentuk yang lebih konkrit, dan telah diusulkan sebagai langkah kunci dalam praktek XP. Refactoring juga memainkan peran penting dalam test-driven development-kode perbaikan langkah dalam proses TDD benar-benar melakukan refactoring.
Refactoring didefinisikan sebagai perubahan yang dibuat dengan struktur internal perangkat lunak untuk membuatnya lebih mudah untuk memahami dan lebih murah untuk memodifikasi tanpa mengubah perilaku yang dapat diamati yang titik kunci di sini adalah bahwa perubahan sedang dibuat dengan desain yang terkandung dalam kode sumber (yaitu, struktur internal) secara eksklusif untuk tujuan perbaikan.
Tujuan dasar dari refactoring adalah untuk memperbaiki desain. Namun, perlu diketahui bahwa ini bukan tentang meningkatkan desain selama tahap desain untuk menciptakan desain yang akan kemudian dilaksanakan (yang merupakan fokus dari desain metode-ologies), tetapi tentang meningkatkan desain kode yang sudah ada. Dengan kata lain, refactoring, meskipun dilakukan pada kode sumber, memiliki tujuan untuk meningkatkan desain yang kode mengimplementasikan. Oleh karena itu, prinsip-prinsip dasar desain memandu proses refactoring. Akibatnya, refactoring umumnya menghasilkan satu atau lebih hal berikut:
- Mengurangi kopling
- kohesi Peningkatan
- kepatuhan yang lebih baik untuk membuka-menutup prinsip
- Kode Duplikat. Ini sangat umum. Salah satu alasan untuk ini adalah bahwa beberapa fungsi kecil sedang dijalankan di beberapa tempat (misalnya, usia dari tanggal lahir dapat dihitung di setiap tempat yang membutuhkan tanggal). Alasan lain yang umum adalah bahwa ketika ada beberapa subclass dari kelas, maka setiap subclass mungkin berakhir melakukan hal yang sama. kode duplikat berarti bahwa jika logika ini atau fungsi harus diubah, itu harus diubah di semua tempat yang ada, membuat perubahan jauh lebih sulit dan lebih mahal.
- Metode Long. Jika metode besar, sering menggambarkan situasi di mana ia mencoba untuk melakukan terlalu banyak hal dan karena itu tidak kohesif.
- Panjang Class. Demikian pula, kelas besar dapat menunjukkan bahwa itu encapsulating beberapa konsep, membuat kelas tidak kohesif.
- Panjang Parameter Daftar. interface yang kompleks jelas tidak diinginkan-mereka membuat kode lebih sulit untuk mengerti. Seringkali, kompleksitas tidak intrinsik tetapi tanda desain yang tidak tepat.
- Beralih Laporan. Dalam program berorientasi objek, jika polimorfisme yang tidak digunakan dengan benar, kemungkinan untuk menghasilkan pernyataan switch di mana-mana perilaku adalah untuk menjadi perbedaan tergantung pada properti. Kehadiran laporan beralih simi-lar di ditempat berbeda adalah tanda bahwa alih-alih menggunakan hirarki kelas, beralih pernyataan sedang digunakan. Kehadiran pernyataan switch membuat lebih sulit untuk memperpanjang kode-jika kategori baru yang akan ditambahkan, semua pernyataan switch akan harus diubah.
- Generality spekulatif. Beberapa hierarki kelas mungkin ada karena benda-benda di subclass tampaknya berbeda. Namun, jika perilaku objek subclass erent di ff adalah sama, dan tidak ada alasan mendesak untuk berpikir bahwa perilaku mungkin berubah, maka itu adalah kasus kompleksitas yang tidak perlu.
Terlalu Banyak Komunikasi Antara Objek. Jika metode dalam satu kelas membuat banyak panggilan ke metode objek lain untuk mencari tahu tentang keadaan, ini adalah tanda kopling kuat. Ada kemungkinan bahwa ini mungkin tidak diperlukan dan karenanya situasi tersebut harus diperiksa untuk refactoring.
- Pesan Chaining. Salah satu metode panggilan metode lain, yang hanya melewati panggilan ini ke objek lain, dan sebagainya. rantai ini berpotensi menyebabkan kopling yang tidak perlu.
Ini bau buruk secara umum adalah indikasi dari desain miskin. Jelas ada kemungkinan tak terbatas dari bagaimana kode dapat refactored untuk meningkatkan desain.Namun demikian, beberapa "standar" refactorings yang dapat diterapkan dalam banyak situasi. Untuk katalog refactorings umum, dan langkah-langkah untuk melakukan masing-masing, pembaca disebut .
7.4 Satuan Pengujian
Unit testing adalah sangat populer dan paling sering digunakan praktek oleh programmer untuk memverifikasi kode yang mereka tulis. Dalam unit testing, programmer menguji / nya kode nya dalam isolasi. Untuk bahasa prosedural ini sering satu set kecil prosedur atau fungsi, dan untuk bahasa berorientasi objek ini umumnya kelas atau satu set kecil kelas. pengujian unit membutuhkan driver dan stub, dan dapat difasilitasi oleh penggunaan kerangka yang memungkinkan tes otomatis eksekusi script. kerangka yang baik seperti Cunit dan Junit ada untuk kedua bahasa prosedural dan bahasa berorientasi objek.
7.4.1 Pengujian Unit Prosedural
Dalam unit testing, satu, atau koleksi kecil, modul ini adalah untuk diuji dengan serangkaian uji kasus. Sebagai perilaku modul tergantung pada nilai parameter serta negara secara keseluruhan sistem yang merupakan bagian (misalnya, negara variabel global), kasus uji untuk modul f () akan melibatkan pengaturan baik keadaan sistem yang perilaku f () tergantung serta nilai parameter. Nilai yang sebenarnya dan keadaan sistem untuk kasus uji tergantung pada tujuan yang tester telah merancang uji kasus ini.
Pengujian modul f () dengan kasus uji maka akan melibatkan langkah-langkah berikut:
- Mengatur sistem negara yang diperlukan oleh uji kasus ini.
- Nilai Set parameter sesuai.
- Panggil prosedur f () dengan parameter.
- Bandingkan hasil f dengan hasil yang diharapkan.
- Menyatakan apakah kasus uji telah berhasil atau gagal.
7.4.2 Pengujian Unit Kelas
Untuk pengujian dari CUT kelas (kelas yang diuji) dengan Junit, tester harus menciptakan kelas lain yang mewarisi dari Junit (misalnya, kelas cuttest meluas Junit). Kerangka Junit harus diimpor oleh kelas ini. kelas ini adalah driver untuk pengujian CUT.
Inspeksi kode adalah teknik lain yang sering diterapkan pada tingkat unit. Hal ini dapat dilihat sebagai "pengujian statis" di mana cacat terdeteksi dalam kode tidak dengan mengeksekusi kode tetapi melalui proses manual. inspeksi kode, seperti pengujian, diterapkan hampir seluruhnya di tingkat unit, yaitu, hanya unit program menjadi sasaran pemeriksaan. Oleh karena itu, kami menganggap itu sebagai bentuk lain dari unit testing. Ini harus menunjukkan bahwa pemeriksaan adalah pendekatan verifikasi umum yang dapat diterapkan untuk mendeteksi cacat pada dokumen.
Tujuan dasar dari inspeksi adalah untuk meningkatkan kualitas kode dengan menemukan cacat. Beberapa karakteristik kunci dari inspeksi adalah:
- Inspeksi Kode dilakukan oleh programmer dan programmer
- Ini adalah proses yang terstruktur dengan peran yang ditetapkan untuk peserta.
- Fokusnya adalah pada identifikasi cacat, tidak memperbaiki mereka.
-Inspeksi data yang dicatat dan digunakan untuk memantau efektifitas dari proses pemeriksaan.
7.5.1 Perencanaan
Tujuan dari tahap perencanaan adalah untuk mempersiapkan untuk pemeriksaan. Sebuah tim inspeksi terbentuk, yang harus mencakup programmer yang kode untuk ditinjau. Tim harus terdiri dari setidaknya tiga orang, meskipun kadang-kadang tim empat atau lima anggota juga terbentuk. Sebuah moderator ditunjuk.
Penulis kode memastikan bahwa kode siap untuk diperiksa dan bahwa kriteria entri puas. Umumnya kriteria masuk yang digunakan adalah bahwa kode mengkompilasi dengan benar dan alat analisis statis yang tersedia telah diterapkan. moderator memeriksa bahwa kriteria masuk puas dengan kode.
7.5.2 Self-Ulasan
Pada fase ini, setiap resensi melakukan self-review kode. Selama self-review, resensi melewati seluruh kode dan log semua cacat potensial ia menemukan di log diri persiapan. Seringkali pengulas akan menandai cacat pada produk pekerjaan itu sendiri, dan dapat memberikan ringkasan dari diri-review dalam log.
Idealnya, diri-review harus dilakukan dalam satu rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu, produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu kurang dari dua jam.
7.5.3 Group Meeting Ulasan
Tujuan dasar dari pertemuan kajian kelompok adalah untuk datang dengan daftar cacat akhir, berdasarkan daftar awal dari cacat yang dilaporkan oleh pengulas dan yang baru ditemukan selama pembahasan dalam pertemuan tersebut. Kriteria masuk untuk langkah ini adalah bahwa moderator puas bahwa semua pengulas siap untuk pertemuan. Keluaran utama dari tahap ini adalah log cacat dan ringkasan laporan cacat.
7.6 Metrik
Secara tradisional, bekerja pada metrik telah difokuskan pada produk akhir, yaitu, kode. Dalam arti, semua metrik untuk produk antara persyaratan dan desain pada dasarnya digunakan untuk memastikan bahwa produk akhir memiliki kualitas tinggi dan produktivitas proyek tetap tinggi. Artinya, tujuan dasar dari metrik untuk produk antara adalah untuk memprediksi atau mendapatkan beberapa ide tentang metrik dari produk akhir.
7.6.1 Tindakan Ukuran
Ukuran produk adalah ukuran sederhana, yang dapat mudah untuk menghitung. Alasan utama untuk kepentingan dalam tindakan ukuran adalah bahwa ukuran adalah faktor utama yang ff sebuah proyek-biaya proyek. Ukuran sendiri adalah menggunakan sedikit; itu adalah hubungan ukuran dengan biaya dan kualitas yang membuat ukuran metrik penting. Hal ini juga digunakan untuk mengukur produktivitas selama proyek (misalnya, KLOC per orang-bulan).
Sejumlah metrik ada untuk kuantitasnya di kualitas kode. Yang paling umum digunakan adalah metrik ukuran, karena mereka digunakan untuk menilai produksi-tivity orang dan sering digunakan dalam estimasi biaya.Untuk ukuran paling umum adalah baris kode (LOC), yang juga digunakan di sebagian besar model biaya. Tujuan dari metrik kompleksitas adalah untuk mengukur kompleksitas perangkat lunak, sebagai com-plexity merupakan faktor penting sebuah produktivitas proyek dan merupakan faktor dalam estimasi biaya. Sejumlah metrik di ff erent ada, yang paling umum adalah kompleksitas cyclomatic, yang didasarkan pada logika internal program dan mendefinisikan kompleksitas sebagai jumlah siklus independen dalam grafik aliran program. Dalam program kita mendefinisikan jumlah terukur berikut:
- N1 adalah jumlah operator yang berbeda
- N2 adalah jumlah operan yang berbeda
- F1, j adalah jumlah kejadian dari j Operator yang paling sering
- F2, j adalah jumlah kemunculan j paling operan sering Kemudian kosakata n dari sebuah program didefinisikan sebagai
n = n1 + n2.
7.6.2 Kompleksitas Metrik
Produktivitas, jika diukur hanya dari segi baris kode per satuan waktu, dapat bervariasi banyak tergantung pada kompleksitas sistem yang akan dikembangkan. Jelas, seorang programmer akan menghasilkan jumlah yang lebih rendah dari kode untuk program sistem yang sangat kompleks, dibandingkan dengan program aplikasi sederhana.
Cyclomatic Kompleksitas Berdasarkan kemampuan pikiran manusia dan pengalaman orang, umumnya diakui bahwa kondisi dan pernyataan kontrol menambahkan kompleksitas program. Mengingat dua program dengan ukuran yang sama, program dengan jumlah yang lebih besar dari pernyataan keputusan cenderung lebih kompleks.
kesederhanaan, seperti pada contoh). Dalam grafik tersebut akan ada jalur dari node masuk ke setiap node dan jalur dari setiap node ke node keluar (dengan asumsi program tidak memiliki anomali seperti kode unreachable). Untuk grafik tersebut, jumlah cyclomatic dapat 0 jika kode adalah urutan linear dari laporan tanpa pernyataan kontrol. Jika kita menarik busur dari node keluar ke node entri, grafik akan sangat terhubung karena ada jalur antara dua node. Jumlah cyclomatic dari grafik untuk program apapun maka akan nol, dan itu diinginkan untuk memiliki kompleksitas nol untuk program yang sederhana tanpa persyaratan apa pun (setelah semua, ada beberapa kompleksitas dalam program seperti itu).
Untuk modul, kompleksitas cyclomatic didefinisikan sebagai jumlah cyclomatic dari grafik tersebut untuk modul.
Ternyata kompleksitas cyclomatic dari modul (atau cyclomatic num-ber grafik nya) adalah sama dengan jumlah maksimum sirkuit bebas linear dalam grafik. Satu set rangkaian linear jika ada sirkuit yang benar-benar terkandung dalam sirkuit lain atau merupakan kombinasi dari sirkuit lainnya.
Jumlah cyclomatic merupakan salah satu ukuran kuantitatif kompleksitas modul. Hal ini dapat diperluas untuk menghitung kompleksitas seluruh program, meskipun itu lebih cocok pada tingkat modul.
Jumlah ini juga dapat digunakan sebagai jumlah jalur yang harus diuji selama pengujian. kompleksitas cyclomatic adalah salah satu kompleksitas mea-langkah-paling banyak digunakan. Percobaan menunjukkan bahwa kompleksitas cyclomatic sangat berkorelasi dengan ukuran modul di LOC (setelah semua, lebih baris kode semakin besar jumlah keputusan).
7.4.2 Pengujian Unit Kelas
Unit testing adalah sangat populer dan paling sering digunakan praktek oleh programmer untuk memverifikasi kode yang mereka tulis. Dalam unit testing, programmer menguji / nya kode nya dalam isolasi. Untuk bahasa prosedural ini sering satu set kecil prosedur atau fungsi, dan untuk bahasa berorientasi objek ini umumnya kelas atau satu set kecil kelas. pengujian unit membutuhkan driver dan stub, dan dapat difasilitasi oleh penggunaan kerangka yang memungkinkan tes otomatis eksekusi script. kerangka yang baik seperti Cunit dan Junit ada untuk kedua bahasa prosedural dan bahasa berorientasi objek.
Inspeksi kode adalah teknik lain yang sering diterapkan pada tingkat unit. Hal ini dapat dilihat sebagai "pengujian statis" di mana cacat terdeteksi dalam kode tidak dengan mengeksekusi kode tetapi melalui proses manual. inspeksi kode, seperti pengujian, diterapkan hampir seluruhnya di tingkat unit, yaitu, hanya unit program menjadi sasaran pemeriksaan. Oleh karena itu, kami menganggap itu sebagai bentuk lain dari unit testing. Ini harus menunjukkan bahwa pemeriksaan adalah pendekatan verifikasi umum yang dapat diterapkan untuk mendeteksi cacat pada dokumen.
Tujuan dasar dari inspeksi adalah untuk meningkatkan kualitas kode dengan menemukan cacat. Beberapa karakteristik kunci dari inspeksi adalah:
- Inspeksi Kode dilakukan oleh programmer dan programmer
- Ini adalah proses yang terstruktur dengan peran yang ditetapkan untuk peserta.
- Fokusnya adalah pada identifikasi cacat, tidak memperbaiki mereka.
- Inspeksi data yang dicatat dan digunakan untuk memantau efektifitas dari proses pemeriksaan.
7.5.1 Perencanaan
Tujuan dari tahap perencanaan adalah untuk mempersiapkan untuk pemeriksaan. Sebuah tim inspeksi terbentuk, yang harus mencakup programmer yang kode untuk ditinjau. Tim harus terdiri dari setidaknya tiga orang, meskipun kadang-kadang tim empat atau lima anggota juga terbentuk. Sebuah moderator ditunjuk.
Penulis kode memastikan bahwa kode siap untuk diperiksa dan bahwa kriteria entri puas. Umumnya kriteria masuk yang digunakan adalah bahwa kode mengkompilasi dengan benar dan alat analisis statis yang tersedia telah diterapkan. moderator memeriksa bahwa kriteria masuk puas dengan kode.
7.5.2 Self-Ulasan
Pada fase ini, setiap resensi melakukan self-review kode. Selama self-review, resensi melewati seluruh kode dan log semua cacat potensial ia menemukan di log diri persiapan. Seringkali pengulas akan menandai cacat pada produk pekerjaan itu sendiri, dan dapat memberikan ringkasan dari diri-review dalam log.
Idealnya, diri-review harus dilakukan dalam satu rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu, produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu kurang dari dua jam.
7.5.3 Group Meeting Ulasan
Tujuan dasar dari pertemuan kajian kelompok adalah untuk datang dengan daftar cacat akhir, berdasarkan daftar awal dari cacat yang dilaporkan oleh pengulas dan yang baru ditemukan selama pembahasan dalam pertemuan tersebut.
Idealnya, diri-review harus dilakukan dalam satu rentang waktu kontinu. Waktu yang disarankan adalah kurang dari dua jam-yaitu, produk kerja cukup kecil sehingga dapat diperiksa secara penuh dalam waktu kurang dari dua jam. Fase ini dari proses peninjauan berakhir ketika semua pengulas telah benar dilakukan mereka diri review dan mengisi diri log peninjauan.
