1 / 54

Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak. Software Testing. Outline of this presentation. What Testing is Testing In Development Process Types Of Testing and Definitions Verification & Validation Purpose and Goal of Testing Who Tests Software Testing Technique Testing Step Testing Strategy. A=0.

selvage
Download Presentation

Rekayasa Perangkat Lunak

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Rekayasa Perangkat Lunak Software Testing

  2. Outline of this presentation • What Testing is • Testing In Development Process • Types Of Testing and Definitions • Verification & Validation • Purpose and Goal of Testing • Who Tests Software • Testing Technique • Testing Step • Testing Strategy

  3. A=0 A=A + 0.1 A=2 ? Print A Print A T F What’s Wrong?

  4. What testing is..................

  5. Mau Tau ya....?

  6. Mau Tau aja atau mau tau banget ???

  7. What testing is.................. 1) Common definition Testing is to execute a program with the purpose of finding defects testing 2) Wider definition ”Testing is a technical investigation of a product, done to expose quality-related information.”

  8. Testing in Development Process • Testing activities take place in all parts of software development • From requirement eliciting to final shipment • Testing is part of the development process • Testing is part of the company business process

  9. Testing in Development Process • Testing During implementation: test to verify that software behaves as intended by the designer. • Testing After implementation: test for conformance with requirements and reliability, and other non functional requirement

  10. Types of testing and definitions • Validation and Verification • Validate • correctness or suitability • vertical experts to confirm master results • Verification • confirm software operates as it is required • double check to ensure results match those previously validated and if not then re-validate them

  11. Phase Inception Elaboration Construction Transition Requirements Analysis Design Development Testing Maintenance Rational Unified Process (RUP) Core Workflow Testing can take place as part of each phase of development .

  12. Phase Inception Elaboration Construction Transition Requirements Analysis Design Development Testing Maintenance Rational Unified Process (RUP) Core Workflow Testing can take place as part of each core workflow involved in development organization.

  13. Verification & Validation • Software V & V defined as a systems engineering methodology to ensure that quality is built into the software during development. • Software V & V is complementary to and supportive of quality assurance, project management, systems engineering, and development.

  14. Verification & Validation versus Debugging • Verification & Validation • a process that establish the existenceof defects in a system • Debugging • a process that locates and corrects these defects

  15. VerificationversusValidation • Software Verification Process • is a process for determining whether the software products of an activity fulfill the requirements or conditions imposed on them in the previous activities. • Software Validation Process • is a process for determining whether the requirements and the final, as-built system or software product fulfills its specific intended use.

  16. Verification versusValidation • Verification: • “Are we building the system in the right way?” • The system should conform to the specification • It does what you specified it should do • Validation: • “Are we building the right system?” • The system should do what the users really requires

  17. The V & V Objectives • There are two principal objectives: • To discover and rectify defects in a system • To assess whether or not the system is usable in an operational situation.

  18. The V & V Objectives • Software V & V determines that the software performs its intended functions correctly. • Ensure that the software performs no unintended functions • Measure and assess the quality and reliability of software.

  19. The V & V Objectives • As a software engineering discipline, software V & V also assesses, analyzes, and tests the software on • how it interfaces with systems elements • Influences the performance, or reacts to stimuli from system elements

  20. The V & V process • V & V Is a whole life-cycle process • V & V should be applied at each stage in the software process.

  21. Static and Dynamic V&V Are we building the system In the right way? Check correspondence between a program and its specification Static Verification R equir ements High-le v el F or mal Detailed Code/ Program specifica tion design specifica tion design Dynamic Pr ototype Validation Are we building the right system? Execution base testing

  22. Static and Dynamic V&V • Static Verification • Concerned with analysis of the static system representation to discover problems • Analysis of all documentsproduced that represent the system • Can be applied during all stages of the software process

  23. Dynamic = “testing” Inspect artifacts Execute systems V & V Static observing product behaviour (dynamic validation) to discover problems (static verification)

  24. Dynamic = “testing” Inspect artifacts Execute systems Complements each other V & V Static

  25. Static Dynamic = ”Testing” Unit test Integrationtest System test Acceptance test Review Inspection Walkthrough V & V

  26. Purpose and goal of testing are situation dependent • Find defects • Maximize bug count • Block premature product releases • Help managers make ship/no-ship decisions • Assess quality • Minimize technical support costs

  27. Purpose and goal of testing are situation dependent • Conform to regulations • Minimize safety-related lawsuit risk • Assess conformance to specification • Find safe scenarios for use of the product (find ways to get it to work, in spite of the bugs) • Verify correctness of the product • Assure quality

  28. Purpose and goal of testing are situation dependent • Testing cannot show the absence of errors, only their presence • We test a program to find the existence of an error • If we find no errors then we have been unsuccessful • If an error is found debugging should occur

  29. Show that a system does what it is supposed to do Showing that a system is without errors Unsuitable objectives with testing

  30. Who Tests Software? user developer independent tester

  31. Who Tests Software? Software Developer Understand system Test gently Driven by delivery Independent Tester Doesn’t understand system Will try to break it Quality driven

  32. Who Tests Software? User Test while using it It’s not in purpose to do so Indirect test

  33. Static verification Review (desk checking) Code reading done by a single person, informal. Uneffective compared to walkthrough or inspection Walkthrough The programmer(s) ”walks through”/”executes” his code while invited participants ask questions and makes comments. Relatively informal Inspection Usually a checklist of common errors is used to compare the code against.

  34. Testing Technique Two views on Software testing: • White Box Testing Black box • Black Box Testing

  35. Testing Technique • White box testing - tests what the program does. Test sets are developed by using knowledge of the algorithms, data structures, and control statements.

  36. Testing Technique Black box • Black box testing - tests what the program is supposed to do. Test sets are developed and evaluated solely on the specification. There is no knowledge of the algorithms, data structures, or control statements.

  37. White-box testing • Also known as: • Structure based (Structural) testing • Code based testing • Glass box testing • Clear box testing • Logic driven testing

  38. White-box (or Structural) testing: Use knowledge of the program to derive test cases to provide more complete coverage Problem: What criteria to use? White-box testing

  39. White-box testing ... our goal is to ensure that all Statements, decisions, conditions, and paths have been executed at least once ...

  40. White-box testing • The system is looked upon as an open box. • The test cases is based on the internal structure of the system (code) • Theoretically desirable but impossible and insufficient goal: all paths of the code exercise

  41. Also known as: Functional Testing because it test all the functions Behavioral Testing because the program is tested against the expected behavior (described by requirements and/or design) Black-box testing Black box

  42. The software is viewed as a black box which transforms input to output based on the specifications of what the software is supposed to do. Black-box testing requirements output input events

  43. Check The Conformity of the tested S/W against established behaviour, and Detect errors generated by fault Software fault is a software part which is not according to its definition provided in the development document Black-box testing

  44. Functional tests examine the observable behavior of software as evidenced by its outputs without reference to internal functions. If the program consistently provides the desired features with acceptable performance, then specific source code features are irrelevant. Black-box testing

  45. Should consider only from the standpoint of its: Input data Output data Knowledge of its internal structured should not be It is very often impossible to test all the input data It is hence necessary to select a subset of possible input Black-box testing

  46. Testing Steps Design specifications System functional requirements Other software requirements Customer requirements specification User environment Unit test Unit code Unit test Unit code . . . Integration test Function test Performance test Acceptance test Installation test Unit test SYSTEM IN USE! Integrated modules Functioning system Verified, validated software Accepted system Unit code

  47. Testing StepsAcceptance Test software tests customer developer site • type of acceptance testing performed by customer at the developer’s site is usually called alpha testing

  48. Testing StepsAcceptance Test software tests customer customer site • beta testing is a type of acceptance testing involving a software product to be marketed for use by many users • selected users receive the system first and report problems back to the developer • users enjoy it - usually receive large discounts and feel important • developers like it - exposes their product to real use and often reveals unanticipated errors

  49. Testing Strategy Big Bang! Top-down Sandwich Compromise Bottom-up incremental non-incremental

  50. Testing Strategy • Big bang integration • (all components together) • Bottom up integration • (from lower levels No test stubs necessary) • Top down integration • (from higher levels  no test drivers are needed) • Sandwich testing • (combination of bottom-up and top-down  no • test stubs and drivers needed)

More Related