Teknik Informatika S1 Rekayasa Perangkat Lunak Testing.

Presentasi berjudul: "Teknik Informatika S1 Rekayasa Perangkat Lunak Testing."— Transcript presentasi:

1 Teknik Informatika S1 Rekayasa Perangkat Lunak Testing

2 SILABUS MATA KULIAH 8. Pembahasan UTS + Tugas SKPL 9. Presentasi SKPL
10. Design + Tugas DPPL 11. Presentasi DPPL 12. Testing 13. Presentasi Tugas Besar (1) 14. Presentasi Tugas Besar (2)

3 Software Testing Software Testing Objectives
Strategic Approach to Software Testing Verification and Validation Organizing for Software Testing Unit Testing Integration Testing Validation Testing Acceptance Testing System Testing

4 Software Testing Objectives
Pengujian? Testing is the process of executing a program with the intent of finding errors A good test case is one with a high probability of finding an as-yet undiscovered error. A successful test is one that discovers an as-yet-undiscovered error.

5 Software Testing Objectives
Pengujian adalah proses eksekusi program dengan maksud menemukan kesalahan. Sebuah test case yang baik adalah dengan probabilitas tinggi untuk menemukan suatu yang belum ditemukan kesalahan. Sebuah tes yang sukses adalah menemukan kesalahan yang belum ditemukan. Testing is the process of executing a program with the intent of finding errors A good test case is one with a high probability of finding an as-yet undiscovered error. A successful test is one that discovers an as-yet-undiscovered error.

6 Strategic Approach to Software Testing
Pengujian dimulai pada tingkat komponen dan bekerja ke luar menuju integrasi seluruh sistem yang berbasis komputer. Teknik pengujian yang berbeda sesuai pada berbagai titik dalam waktu. Pengembang perangkat lunak melakukan pengujian dan dapat dibantu oleh kelompok uji independen (ITG) untuk proyek-proyek besar. Pengujian dan debugging merupakan aktivitas yang berbeda. * Debugging harus diakomodasi dalam strategi pengujian. Testing begins at the component level and works outward toward the integration of the entire computer-based system. Different testing techniques are appropriate at different points in time. The developer of the software conducts testing and may be assisted by independent test groups (ITG) for large projects. Testing and debugging are different activities. Debugging must be accommodated in any testing strategy.

7 Verification and Validation
Verifikasi (are we building the product right?) Validasi (are we building the right product?) Pengujian Software adalah hanya salah satu unsur Software Quality Assurance (SQA) Kualitas harus dibangun untuk proses pembangunan, Anda tidak dapat menggunakan pengujian untuk menambah kualitas setelah fakta yang ada Make a distinction between verification (are we building the product right?) and validation (are we building the right product?) Software testing is only one element of Software Quality Assurance (SQA) Quality must be built in to the development process, you can't use testing to add quality after the fact

8 Organizing for Software Testing
Peran Uji Kelompok Independen (ITG) adalah untuk menghilangkan konflik kepentingan yang melekat ketika pembangun sedang menguji produk sendiri. Kesalahpahaman mengenai penggunaan tim pengujian independen yang: Pengembang harus melakukan pengujian yang tidak ada sama sekali Software dilempar "over the wall" kepada orang-orang untuk menguji tanpa ampun Penguji tidak terlibat dengan proyek ini sampai saatnya untuk itu harus diuji Para pengembang dan ITGC harus bekerja sama di seluruh proyek perangkat lunak untuk memastikan bahwa tes menyeluruh akan dilakukan The role of the Independent Test Group (ITG) is to remove the conflict of interest inherent when the builder is testing his or her own product. Misconceptions regarding the use of independent testing teams are The developer should do no testing at all Software is tossed "over the wall" to people to test it mercilessly Testers are not involved with the project until it is time for it to be tested The developer and ITGC must work together throughout the software project to ensure that thorough tests will be conducted

9 Software Testing Strategy for Traditional Software Architectures
Unit Testing Menitikberatkan pada penggunaan teknik pengujian aliran kontrol tertentu untuk mendeteksi kesalahan dalam setiap komponen perangkat lunak individual Integration Testing Berfokus pada isu-isu yang terkait dengan verifikasi dan konstruksi program sebagai komponen yang berinteraksi satu sama lain Unit Testing makes heavy use of testing techniques that exercise specific control paths to detect errors in each software component individually Integration Testing focuses on issues associated with verification and program construction as components begin interacting with one another Validation Testing provides assurance that the software validation criteria (established during requirements analysis) meets all functional, behavioral, and performance requirements System Testing verifies that all system elements mesh properly and that overall system function and performance has been achieved

10 Software Testing Strategy for Traditional Software Architectures
Validation Testing Memberikan jaminan bahwa kriteria validasi perangkat lunak (selama analisis kebutuhan) memenuhi semua persyaratan fungsional, perilaku, dan kinerja System Testing Memverifikasi bahwa semua elemen sistem berjalan dengan benar dan bahwa fungsi sistem secara keseluruhan dan kinerja yang telah dicapai Unit Testing makes heavy use of testing techniques that exercise specific control paths to detect errors in each software component individually Integration Testing focuses on issues associated with verification and program construction as components begin interacting with one another Validation Testing provides assurance that the software validation criteria (established during requirements analysis) meets all functional, behavioral, and performance requirements System Testing verifies that all system elements mesh properly and that overall system function and performance has been achieved

11 Strategic Testing Issues
Tentukan persyaratan produk secara kuantitatif sebelum pengujian dimulai. Tentukan tujuan pengujian secara eksplisit. Mengidentifikasi kategori pengguna untuk perangkat lunak dan mengembangkan profil untuk masing-masing. Mengembangkan rencana tes yang menekankan pengujian siklus yang cepat. Specify product requirements in a quantifiable manner before testing starts. Specify testing objectives explicitly. Identify categories of users for the software and develop a profile for each. Develop a test plan that emphasizes rapid cycle testing. Build robust software that is designed to test itself. Use effective formal reviews as a filter prior to testing. Conduct formal technical reviews to assess the test strategy and test cases. Develop a continuous improvement approach for the testing process.

12 Strategic Testing Issues
Membangun perangkat lunak yang kuat yang dirancang untuk menguji dirinya sendiri. Gunakan bahasa formil efektif sebagai filter sebelum pengujian. Melakukan tinjauan teknis formal untuk menilai strategi tes dan uji kasus. Mengembangkan pendekatan perbaikan terus-menerus untuk proses pengujian. Specify product requirements in a quantifiable manner before testing starts. Specify testing objectives explicitly. Identify categories of users for the software and develop a profile for each. Develop a test plan that emphasizes rapid cycle testing. Build robust software that is designed to test itself. Use effective formal reviews as a filter prior to testing. Conduct formal technical reviews to assess the test strategy and test cases. Develop a continuous improvement approach for the testing process.

13 Unit Testing Interface modul diuji untuk aliran informasi yang tepat.
Data lokal diperiksa untuk memastikan bahwa integritas dipertahankan. Kondisi batas diuji. Dasar (independen) jalur diuji. Semua jalur penanganan kesalahan harus diuji.

14 Integration Testing Pengujian integrasi Top-down
Main control modul yang digunakan sebagai test driver dan stub merupakan pengganti untuk komponen langsung bawahan untuk itu. Rintisan bertopik bawahan diganti satu per satu dengan komponen yang nyata (setelah depth-first atau breadth-first approach). Pengujian dilakukan karena setiap komponen terintegrasi. Setelah menyelesaikan setiap rangkaian tes dan rintisan lainnya diganti dengan komponen nyata, pengujian regresi dapat digunakan untuk memastikan bahwa kesalahan baru tidak diperkenalkan. Top-down integration testing Main control module used as a test driver and stubs are substitutes for components directly subordinate to it. Subordinate stubs are replaced one at a time with real components (following the depth-first or breadth-first approach). Tests are conducted as each component is integrated. On completion of each set of tests and other stub is replaced with a real component, regression testing may be used to ensure that new errors not introduced. Bottom-up integration testing Low level components are combined into clusters that perform a specific software function. A driver (control program) is written to coordinate test case input and output. The cluster is tested. Drivers are removed and clusters are combined moving upward in the program structure.

15 Integration Testing Pengujian integrasi Bottom-up
Komponen tingkat rendah digabungkan ke dalam kelompok yang melakukan fungsi perangkat lunak tertentu. Program kontrol ditulis untuk mengkoordinasikan masukan kasus uji dan output. Cluster ini diuji. Driver dihapus dan cluster dikombinasikan bergerak ke atas dalam struktur program. Top-down integration testing Main control module used as a test driver and stubs are substitutes for components directly subordinate to it. Subordinate stubs are replaced one at a time with real components (following the depth-first or breadth-first approach). Tests are conducted as each component is integrated. On completion of each set of tests and other stub is replaced with a real component, regression testing may be used to ensure that new errors not introduced. Bottom-up integration testing Low level components are combined into clusters that perform a specific software function. A driver (control program) is written to coordinate test case input and output. The cluster is tested. Drivers are removed and clusters are combined moving upward in the program structure.

16 Integration Testing (2)
Pengujian regresi Digunakan untuk memeriksa cacat disebarkan ke modul lain dengan perubahan yang dibuat untuk program yang ada Sampel yang representatif dari kasus uji yang ada digunakan untuk melaksanakan semua fungsi perangkat lunak. Kasus uji tambahan memfokuskan fungsi perangkat lunak mungkin akan terpengaruh oleh perubahan itu. Tes kasus yang berfokus pada komponen perangkat lunak berubah. (baik top-down atau bottom integrasi dapat digunakan).

17 Integration Testing (2)
Smoke Testing Komponen perangkat lunak yang sudah diterjemahkan ke dalam kode diintegrasikan ke dalam untuk membangun. Serangkaian tes yang dirancang untuk mengekspos kesalahan dari fungsi yang diciptakan. Pembangunan ini terintegrasi dengan yang lain.

18 General Software Test Criteria
Interface integrity Interface modul internal dan eksternal diuji karena setiap modul atau cluster ditambahkan ke perangkat lunak Validitas fungsional Tes untuk mengungkap cacat fungsional dalam perangkat lunak Information content Tes untuk kesalahan dalam struktur data lokal atau global Performance Batas kinerja tertentu diuji Interface integrity internal and external module interfaces are tested as each module or cluster is added to the software Functional validity test to uncover functional defects in the software Information content test for errors in local or global data structures Performance specified performance bounds are tested

19 Acceptance Testing Memastikan perangkat lunak tersebut bekerja dengan benar untuk pengguna dimaksudkan dalam lingkungan kerja yang normal. Pengujian Alpha - Versi perangkat lunak lengkap diuji oleh pelanggan di bawah pengawasan pengembang di situs pengembang Pengujian beta - Versi perangkat lunak yang lengkap diuji oleh pelanggan pada situs-nya sendiri tanpa pengembang yang hadir

20 System Testing Recovery testing Security testing
Memeriksa kemampuan sistem untuk pulih dari kegagalan Security testing Memverifikasi bahwa mekanisme perlindungan sistem mencegah penetrasi yang tidak tepat atau terjadi perubahan data

21 System Testing Stress testing Performance testing
Program diperiksa untuk melihat seberapa baik berkaitan dengan tuntutan sumber daya yang abnormal (yaitu, jumlah, frekuensi, atau volume) Performance testing Dirancang untuk menguji kinerja run-time perangkat lunak, khususnya perangkat lunak real-time

22 Debugging Debugging (penghapusan cacat) terjadi sebagai konsekuensi dari pengujian yang berhasil. Beberapa orang lebih baik dalam debugging daripada yang lain. Pendekatan umum: Brute force - dump memori dan jejak run-time diperiksa untuk petunjuk penyebab kesalahan Backtracking - kode sumber diperiksa dengan melihat mundur dari gejala untuk potensi penyebab kesalahan Cause elimination - menggunakan partisi biner untuk mengurangi jumlah lokasi yang potensial (di mana kesalahan bisa eksis)

23 Pertimbangan Bug Removal
Apakah penyebab bug direproduksi di bagian lain dari program ini? Apa "bug berikutnya" mungkin diperkenalkan oleh perbaikan yang diusulkan? Apa yang bisa dilakukan untuk mencegah bug ini di tempat pertama?

24 Software Testability Checklist
Operability Semakin baik kerja software semakin efisien untuk diuji Observabilty Apa yang Anda lihat adalah apa yang anda uji Controllability Perangkat lunak lebih baik dapat dikontrol lebih sehingga pengujian dapat diotomatisasi dan dioptimalkan Decomposability Dengan mengontrol ruang lingkup pengujian, semakin cepat masalah dapat diisolasi dan diuji ulang dengan cerdas

25 Software Testability Checklist
Simplicity Semakin sederhana perangkat lunak, semakin cepat kita menguji Stability Semakin sedikit perubahan, semakin sedikit gangguan pengujian Understandability Semakin banyak informasi diketahui, semakin cerdas pengujian

26 Good Test Attributes Sebuah tes yang baik memiliki probabilitas tinggi untuk menemukan kesalahan. Sebuah tes yang baik adalah tidak berlebihan. Sebuah tes yang baik harus berkembang. Sebuah tes yang baik tidak boleh terlalu sederhana atau terlalu rumit. A good test has a high probability of finding an error. A good test is not redundant. A good test should be best of breed. A good test should not be too simple or too complex.

27 Test Case Design Strategies
Black-box or behavioral testing Mengetahui fungsi tertentu produk adalah untuk melakukan dan menunjukkan operasi yang benar hanya berdasarkan spesifikasi tanpa memperhatikan logika internal White-box or glass-box testing Mengetahui kerja internal suatu produk, tes dilakukan untuk memeriksa kerja dari semua kemungkinan jalur logika

28 Test Case Design Strategies
White-box or glass-box testing (Struktural) White box testing adalah pengujian yang didasarkan pada pengecekan terhadap detail perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.

29 Test Case Design Strategies
Kelebihan White Box Testing Kesalahan logika. Digunakan pada sintaks ‘if’ dan pengulangan. Dimana White Box Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan mendeteksi kapan proses pengulangan akan berhenti. Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai dengan kenyataan, untuk di analisa dan diperbaiki. Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat case sensitive. Kelemahan White Box Testing Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk melakukannya.

30 Test Case Design Strategies
Black-box or behavioral testing Black box testing adalah pengujian yang dilakukan hanya mengamati hasil eksekusi melalui data uji dan memeriksa fungsional dari perangkat lunak. Jadi dianalogikan seperti kita melihat suatu kotak hitam, kita hanya bisa melihat penampilan luarnya saja, tanpa tau ada apa dibalik bungkus hitam nya. Sama seperti pengujian black box, mengevaluasi hanya dari tampilan luarnya (interfacenya), fungsionalitasnya tanpa mengetahui apa sesungguhnya yang terjadi dalam proses detilnya (hanya mengetahui input dan output).

31 Test Case Design Strategies
Kelebihan Black-box or behavioral testing Dapat memilih subset test secara efektif dan efisien Dapat menemukan cacat Memaksimalkan testing investment Kelemahan Black-box or behavioral testing  Tester tidak pernah yakin apakah PL tersebut benar – benar lulus uji.

32 TERIMA KASIH

33 Present Tugas Besar Point 1 - 10 letakkan di slide Presentasi:
Cover + Kontribusi Angg. Judul Aplikasi Fungsi Produk Karakteristik Pengguna DFD (Diagram Konteks dan DFD Level 1) ERD Kamus Data Dekomposisi Modul (Gambar Dekomposisi) Interface/ Tampilan Layar (Tampilkan secara garis besar, min. 5) Matriks Keterunutan DPPL DEMO APLIKASI Usahakan Pembagian Presentasi Rata, agar nilainya bisa sama  Urutan Maju akan di Random Minggu depan 1 Pertemuan 4 Kelompok Semua Kelompok harus Siap maju di minggu depan, jika mundur nilai presentasi hanya 80%