1 / 18

Subject Name: SOFTWARE TESTING Subject Code:10IS65 Prepared By: HARKIRANPREET Department: ISE

Subject Name: SOFTWARE TESTING Subject Code:10IS65 Prepared By: HARKIRANPREET Department: ISE Date: 25 MARCH 2015. Chapter 2 A Framework for test and analysis. Validation & Verification.

ivyk
Download Presentation

Subject Name: SOFTWARE TESTING Subject Code:10IS65 Prepared By: HARKIRANPREET Department: ISE

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. Subject Name: SOFTWARE TESTING Subject Code:10IS65 Prepared By: HARKIRANPREET Department: ISE Date: 25 MARCH 2015

  2. Chapter 2A Framework for test and analysis

  3. Validation & Verification Assessing the degree to which a software system actually fulfills its requirements, in the sense of meeting the user real needs is called validation. Verification is checking the consistency of an implementation with a specification. It includes clutter and also checks for well-formedness.

  4. Degrees of freedom • Undesiability:- undesiability of a property S implies that for each verification technique for checking S, there is at least one pathological program for which that technique cannot obtain a correct answer in finite time. • Pessimistic:- it may be pessimistic meaning that it is not guaranteed to accept a program even if the program does possess the property being analysed. • Optimistic:- if it may accept some programs that do not possess the property.

  5. Chapter 3 Basic principles

  6. Sensitivity The sensitivity principle states that it is better to fail every time than sometimes. It says that we should try to make these faults easier to detect by making them cause failure more often. It can be applied in 3 ways: a) at the design level b) at the analysis and testing level c) at the environment level

  7. Redundancy Redundancy is the opposite of independence. If one part of a software architect constraints the content of another, then they are not entirely independent and it is possible to check them for consistency. Checkable redundancy is not limited to program source code.

  8. Restriction When there is no acceptable cheap and effective ways to check a property, sometimes one can change the problem by checking a different, more restrictive property or by limiting the check to a smaller, more restrictive class of programs.

  9. Partition It is often known as divide and conquer principle. Dividing a complex problem into smaller sub problems to be attacked and solved independently is probably the most common human problem solving strategy. Partitioning can be applied at both process and technique levels. They divide the overall analysis into two subtasks: first simplify the system and then prove the property

  10. Visibility and feedback • Visibility means the ability to measure progress or status against goals. • Visibility is closely related to observability, the ability to extract useful information from a software artifact. • Feedback applies to analysis and testing. It applies both to process itself and to individual techniques. • Systematic inspection and walkthrough derive part of their success from feedback.

  11. Chapter 4Test and Analysis Activities within a software Process.

  12. The Quality process • Quality depends on every part of software process, not only on software analysis and testing. • The quality process should be structured for completeness, timeliness and cost effectiveness. • Completeness means that appropriate activities are planned to detect each class of faults. • Timeliness means faults are detected at a point of high leverage. • Cost effectiveness means to the constraint of completeness and timeliness.

  13. Planning and monitoring • Planning is the integral to the quality process and is elaborated & revised through the whole project. • It encompasses both an overall strategy for test and analysis. • It includes objectives of test and analysis activities. • The final analysis and test plan includes additional information about constraints, pass and fail criteria, schedule, deliverables, hardware and software requirements.

  14. Quality goals • Product qualities are the goals of software quality engineering and process qualities are means to achieve goals. • Software product qualities are divided into those that are directly visible to a client and those primarily affect the software development organization. • Properties that are visible to users are called as external properties and others are internal properties. • Other properties are dependability, usefulness etc.

  15. Dependability properties • The simplest of dependability properties is correctness. • Reliability is approximation to correctness. • Availability is an appropriate measure when a failure has some duration in time. • MTBF is another measure of reliability. • Safety and hazards: safety is concerned with preventing certain undesirable behaviors called hazards.

  16. Analysis and testing • Manual inspection and automated analysis can be applied at any development stage. • Inspection can be applied to any document, test plans and test cases. • Test are executed when the corresponding codes are available, but testing activities start earlier.

  17. Improving the process • Long lasting errors are common. • It is important to structure the process for identifying most critical persistant faults . • Tracking them to frequent errors. • Adjusting the development & quality process to elaborate errors. • Feedback mechanisms are most difficult part to implement and is useful in improving the process.

  18. Organizational factors • The development team may attempt to maximize the productivity to the detriment of quality. • The quality assurance team is divided into analysis and testing group responsible for dependability and usability of the system. • Responsibility for security issued are assigned to the infrastructure development group.

More Related