Pengujian Perangkat Lunak PSIM 7 Definisi Pengujian perangkat

Pengujian Perangkat Lunak PSI-M 7

Definisi Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean. Pengujian menyajikan anomali yang menarik bagi perekayasa perangkat lunak.

Definisi Software testingis the process of analyzing a software item to detect the differences between existing and required conditions (thatis, bugs) and to evaluate the features of the software item

Pengujian Perangkat Lunak • Pada proses perangkat lunak, perekayasa pertama berusaha membangun perangkat lunak dari konsep abstrak ke implementasi yang dapat dilihat, baru dilakukan pengujian. • Perekayasa menciptakan sederetan test case yang dimaksudkan untuk “membongkar” perangkat lunak yang sudah dibangun. Pada dasarnya, pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang dapat dianggap (paling tidak secara psikologis) sebagai hal yang destruktif daripada konstruktif

Tujuan Pengujian • Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan • Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya • Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya.

Mengapa Harus Diuji? • Setiap produk berjalan melalui siklus dasar yang sama, terlepas dari apakah itu perangkat lunak atau produk fisik. Hal ini dapat ditunjukkan dalam diagram di bawah ini: Idea – Seseorang memiliki gagasan dan memiliki kemampuan. Build – Setelah ide dimiliki maka proses pembuatan Test – Setelah proses pembuatan selesai maka di uji Release – Dan Hasil tes bagus maka akan di rilis

Mengapa Harus Diuji? • Kita bukan seorang programmer yg cukup baik • Kita kadang buruk dalam mengerjakan sesuatu • Memastikan perangkat lunak sesuai dengan yang dibutuhkan • Pengujian benar-benar diperlukan untuk menunjukkan cacat dan kesalahan yang dibuat selama fase pembuatan. • Memastikan Keandalan dari perangkat lunak demi menjaga tingkat kepuasan pelanggan • Menjamin Kualitas Produk • Mengurangi kesalahan yang dihasilkan dari produk agar dimasa yang akan datang jika mengalami perbaikan tidak memerlukan biaya besar

concepts • Mistake– a human action that produces an incorrect result. • Fault [or Defect]– an incorrect step, process, ordata definition in a program. • Failure– the inability of a system or component to perform its required function within the specified performance requirement. • Error– the difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. • Specification – a document that specifies in a complete, precise, verifiable manner, the requirements, design, behavior, orother characteristicof a system or component, and often the procedures for determining whether these provisions have been satisfied.

Tipe Pengujian 1. 2. 3. 4. Black box testing White box testing Unit testing Incremental integration testing 5. Integration testing 6. Functional testing 7. System testing 8. End-to-end testing 9. Sanity testing 10. Regression testing 11. Acceptance testing 12. Load testing 13. Stress testing 14. Performance testing 15. Usability testing 16. Install/uninstall testing 17. Recovery testing 18. Security testing 19. Compatibility testing 20. Comparison testing 21. Alpha testing 22. Beta testing

Black. Box Testing

verification and validation • Verification (the first V) isthe process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase • Validationis the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements • Verification: Are we building the product right? • Validation: Are webuilding the rightproduct?

Black box testing - Steps • Initially requirements and specifications of the system are examined. • Tester chooses valid inputs (positive test scenario) to check whether SUT processes them correctly. Also some invalid inputs (negative test scenario) are chosen to verify that the SUT is able to detect them. • Tester determines expected outputs for all those inputs. • Software tester constructs test cases with the selected inputs. • The test cases are executed. • Software tester compares the actual outputs with the expected outputs. • Defects if any are fixed and re-tested.

Types of Black Box Testing • Functional testing - This black box testing type is related to functional requirements of a system; it is done by software testers. • Non-functional testing - This type of black box testing is not related to testing of a specific functionality , but nonfunctional requirements such as performance, scalability, usability. • Regression testing - Regression testing is done after code fixes , upgrades or any other system maintenance to check the new code has not affected the existing code.

Tools used for Black Box Testing • For Functional/ Regression Tests you can use - QTP • For Non-Functional Tests you can use - Loadrunner

Black box testing strategy • Equivalence Class Testing: It is used to minimize the number of possible test cases to an optimum level while maintains reasonable test coverage. • Boundary Value Testing: Boundary value testing is focused on the values at boundaries. This technique determines whether a certain range of values are acceptable by the system or not. It is very useful in reducing the number of test cases. It is mostly suitable for the systems where input is within certain ranges. • Decision Table Testing: A decision table puts causes and their effects in a matrix. There is unique combination in each column. •