Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Gd test kieu_test

895 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/U2kmk ◀ ◀ ◀ ◀
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/U2kmk ◀ ◀ ◀ ◀
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

Gd test kieu_test

  1. 1. Stages of Test and Types of Test Tài liệu đào tạo
  2. 2. Agenda  Test methods  Types of Test  Stages of Test  Test Web Application  Demo Tool Test WAPT
  3. 3. Two Fundamental Approaches Structural Testing – – Also known as: white box testing. Test is based on the structure of the code. Functional Testing - Also known as: black box testing, functional testing, behavioral testing. - Test is based on the behavior of the software. The code itself is not looked at.
  4. 4. White Box vs. Black Box Testing White Box INPUT INPUT OUTPUT OUTPUT
  5. 5. White Box (Structural) Testing     Examines internal software design. Requires the tester to have detailed knowledge of the software structure. Static structural analysis – Complexity – Code coverage – Paths Dynamic structural analysis – Call pairs – Control Flow – Data flow – Memory leaks
  6. 6. White Box Testing - Definition A test case design method that uses the control structure of the procedural design to derive test cases.
  7. 7. White Box Testing  Driven by program structure  Looks at the implementation details.  Concerned with: – – – – – Programming style Control method Language Database design Coding details
  8. 8. Black Box (Functional) Testing    Based upon functional operation, does not require knowledge of the code or software structure. Functional test coverage (requirements tracing). Examples: – – – – – – – Requirements based testing Use case testing State machine testing Boundary value testing (domain testing) Equivalence class partitioning Syntax testing Data flow testing
  9. 9. Stages of Test – V Model
  10. 10. Developer Testing vs. Independent Testing (Tester)     Some testing is done by the code developers. Some testing is done by an independent testing group. The presence of an independent test group does not mean that the developers stop testing. The need for independent Testing: Developers know how to make their code word so they miss a lot of bugs
  11. 11. Organizational Roles - Testing Unit Testing Code Developers Independent Test Group Integration Testing System Testing
  12. 12. Unit Test        Test individual units of program: method, function, procedure Done by the developers. White box testing. Test cases are defined by specifying paths. Focus on a relatively small segment of code. A path is an instruction sequence that threads through the entire program form initial entry to final exit. Simplest approach is to ensure that every statement is exercised once. More stringent: Require coverage of every path. Usually not practical.
  13. 13. Unit Test (cont.)  What to test: • • • • • Data structure is examined Boundary conditions are tested to ensure that the module operates properly for input and output data All independent paths are exercised Error handling paths are tested Use of stubs (modules to be called) and drivers (modules that calls)
  14. 14. Integration Test Test integrated components/modules, interface of program – Executed by developers, testers Combining the individual components Problems may occur due to: – Data lost across interface – One module can have an adverse affect on another – Sub functions may not produce the desired major functions – Individual acceptable imprecision but unacceptable if magnified – Global data structures presents problems Is a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing Objective is to take unit tested modules and build a program structure that has been dictated by design –    
  15. 15. System Test – – – Testing system as whole Testing requirements and business processes Executed by testers
  16. 16. How to perform System test   Objectives  To make sure the software functions properly in accordance with software requirements specification. Method  Black-Box Testing  Input – Compare results – Log defect (if any)
  17. 17. System Test Categories          Functionality Reliability/Availability – To find problems based upon continuous running of the system. Load/Stress – To identify problems caused by peak load conditions. Volume – To find problems in the system’s ability to process a heavy load continuously. Performance – To determine the actual response time and CPU loading conditions of the system. Installablities: Recovery – Force the system to fail and then find problems in the recovery processing of the system. .Particularly data. Security – To find holes in the system’s security provision. Serviceability – Maintenance and repair procedures.
  18. 18. Acceptance Test – – – – – – it is the customer’s way to verify that what was wanted is what is built uncovers more than requirements discrepancies allows the customers to determine what they really want, whether specified in the document or not. new problems may arise rapid prototyping changes may not only mean improper definition of requirement, but also because customers may decide that the problem is changed and a different solution is needed
  19. 19. Acceptance Test  To validate that the delivered system meets the actual business needs of the corporation.  Executed by customer  The customer may write the acceptance test criteria and request that these be executed by the developer,  The developer may produce the acceptance test criteria which are to be approved by the customer.
  20. 20. Type of Test – – – – – – – – – – – Functional testing (F) User Interface testing (U) Performance testing (P) Data & Data integrity testing (D) Security & Access control testing (A) Load testing (L) Stress testing (S) Volume testing (V) Regression testing (R) Installation testing (I) Business Cycle Testing (B)
  21. 21. Functional testing    Function testing of the target-of-test should focus on any requirements for test that can be traced directly to use cases or business functions and business rules. The goals of these tests are to verify proper data acceptance, processing, and retrieval, and the appropriate implementation of the business rules. This type of testing is based upon black box techniques that are verifying the application
  22. 22. Functional testing (cont.)  Test Objective: Technique: Test functions follow requirements Ensure proper target-of-test functionality, including navigation, data entry, processing, and retrieval. Execute each use case, use-case flow, or function, using valid and invalid data, to verify the following: - The expected results occur when valid and invalid data is used. - Valid input data is updated correctly to database - Each business rule is properly applied. Completion Criteria: - All planned tests have been executed. Special  Considerations: Functional test on Max OS X
  23. 23. User Interface testing  Objective: – – – Verify navigation Verify using of access methods (tab keys, mouse movements, accelerator keys) Window objects and characteristics, such as menus, size, position, state, and focus conform to standards
  24. 24. User Interface testing (cont.)  Technique: – Create or modify tests for each window to verify proper navigation and object states for each application window and objects  Completion – Criteria: Each window successfully verified to remain consistent with benchmark version or within acceptable standard
  25. 25. Performance testing  Objective: verify performance requirements have been achieved – – – Response time Transaction rates Other time-sensitive requirements are measured and evaluated
  26. 26. Performance Testing (Cont.)   Technique: – Use Test Procedures developed for Function or Business Cycle Testing – Modify data files to increase the number of transactions or the scripts to increase the number of iterations each transaction occurs Completion Criteria: – Single Transaction: Successful completion of the test scripts without any failures and within the expected or required time allocation per transaction – Multiple transactions: Successful completion of the test scripts without any failures and within acceptable time allocation
  27. 27. Data & Data integrity testing  Objective: –  Technique: – –  Ensure database access methods and processes function properly and without data corruption Check the returned data to ensure that the correct data was retrieved for the correct transaction Check the database to ensure the data has been populated as intended, all database events occurred properly Completion Criteria: – All database access methods and processes function as designed and without any data corruption
  28. 28. Security & Access control testing  Application-level – Check user right: verify that an actor/user can access only those functions or data if they have right  System-level – Security Security Verify that only those users granted access to the system are capable of accessing the applications and only through the appropriate gateways
  29. 29. Load testing        Forcing the system to do a large amount of processing Depends on the type of system. Large number of transactions. Large files. Large number of files. Large number of clients. Repeated operations.
  30. 30. Load testing (cont.)  Objective: – Verify performance behavior time for designated transactions or business cases under varying workload conditions Technique: – Use tests developed for Function or Business Cycle Testing – Modify data files to increase the number of transactions or the tests to increase the number of times each transaction occurs  Completion Criteria:  – – Multiple transactions or multiple users: Successful completion of the tests without any failures and within acceptable time allocation Performed on a dedicated machine or at a dedicated time
  31. 31. Stress testing  Objective: verify functions work without error under the following stress conditions: – – –  Little or no memory available on the server (RAM) Maximum actual or physically capable number of clients connected or simulated Multiple users performing the same transactions against the same data or accounts Technique: – – Use tests developed for Performance Profiling or Load Testing To test limited resources, tests should be run on a single machine, and RAM on server should be reduced or limited
  32. 32. Volume testing  Objective: – Test with large amounts of data to determine if limits are reached that cause the software to fail  Technique: – – Data and database integration Use tests developed for Function testing
  33. 33. Regression testing  Objective – Validate modified parts of the software, to make sure that the modification does not cause errors in other parts  Technique – Reuse the set of test cases from an existing test suite to test a modified module
  34. 34. Regression testing (cont.)  What is Regression test Test the system as a whole. Similar to System test  Usually take a lot of efforts   When to perform Regression test – Regression test usually is performed when: Total number of change requests arisen since the latest baseline (with regression test) > the number of requirements in that baseline  The total number of post-release defects is out of a pre-defined threshold  As planned in Maintenance plan (with Maintenance projects) 
  35. 35. Installation testing  To identify problems in the installation procedures
  36. 36. Business Cycle Testing  Objective: – Ensure proper target-of-test and background processes function according to required business models and schedules  Technique: – – – All functions that occur on a periodic schedule will be executed or launched at the appropriate time Testing will include using valid and invalid data Each business rule is properly applied
  37. 37. Type of Test Stage of Test Unit Integration System Acceptance X X X X User Interface Tests X X Performance X X Load Testing X Security and Access control Tests X Functional Tests
  38. 38. Test Web Application  What to test: • All components of a Web application on both the client and server side • Validation or Functional Testing • HTML Validation • Link Testing • Load and stress Testing • Security Testing • Regression Testing
  39. 39. Test Web Application (cont.)  Problem: – – –  Impossible to test all possible dependencies and everything that could go wrong with this site. Impossible to test varied target audience and platforms that a web applications addresses Tools used for load test, volume test Solution: – – Determine where to focus testing efforts within budget and schedule constraints Analyse risks and set priorities based on risk analysis