Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Software Testing and Quality Assurance Lecture 37 – Software Quality Assurance.

Similar presentations


Presentation on theme: "1 Software Testing and Quality Assurance Lecture 37 – Software Quality Assurance."— Presentation transcript:

1 1 Software Testing and Quality Assurance Lecture 37 – Software Quality Assurance

2 2 Lecture Objectives Basic Execution Time Model Operational Profiles Time Understanding Reliability Growth Software Safety

3 3 Basic Execution Time Model – Operational Profiles Helps us relate programs back to the environment in which program execute. Many programs execute in finite time Finite time still means much longer time span than the few seconds it takes to execute a typical desktop application. Programs may be required to execute for weeks or months, or even years in case of embedded systems.

4 4 Basic Execution Time Model – Operational Profiles Typically, many different functions are implemented in a single system. For example, an editor has functions for inserting text, graphics, deleting text and moving text etc. In order to arrive at an operational profile for a program The functions can be performed by the system need to be identified We will view each execution of a program as choosing and executing some subset of these functions.

5 5 Basic Execution Time Model – Operational Profiles Each function has associated with it an input domain, similar to testing. We want to determine the set of inputs that will cause a function of the program to be executed.

6 6 Basic Execution Time Model – Operational Profiles Input State – an element of the input domain that triggers the execution of one of the program’s functions. Operational Profile – set of input states for the program and the probability with which each input state can occur in the program environment.

7 7 Basic Execution Time Model – Operational Profiles Determining operational profiles can be done Via manual estimation, by running the programs a number of times to get an approximation of amount of times different inputs states occur. For example, a word processor, Single character will occur with higher probability than the input of inserting an image. Estimate operational profile by looking at documents and counting the number of characters and number of images etc.

8 8 Basic Execution Time Model – Time Reliability is measured with respect to time. Execution time – the time spent by the processor in executing the instructions of the program; Calendar time – the normal passage of time measured in hours, days and months. Clock time – the time elapsed from the start of program execution and includes the wait and execution time of other programs.

9 9 Basic Execution Time Model – Time

10 10 Basic Execution Time Model – Time Execution time for Program A T1 + T 3 + T6 Elapsed time is T1 + T2 + T3 + T4 + T5 + T6 Time measurements are rarely repeatable. Chief source of error in estimating model parameters. Choosing the right clock to record failure times is important.

11 11 Basic Execution Time Model – Time Issue of Scale Errors due to timing measurements have significantly less impact if failure times are measured at small time scales; and Failure occur at large time scales. For example, an error in time measurement of about 100 milli- second hardly influences the basic execution time. If the time interval between failures is in the order of days.

12 12 Understanding Reliability Growth

13 13 Understanding Reliability Growth

14 14 Understanding Reliability Growth

15 15 Software Safety Safety in systems involving software is becoming important. For example, Computer Aided Dispatch Systems (CAD); Electronic Flight Control Systems (EFCS). Train Protection Systems; Chemical Plant control systems.

16 16 Software Safety

17 17 Software Safety We wish to avoid in engineering and operating our platforms is Accidents. The system that we build must avoid the hazards that lead to accidents.

18 18 Software Safety Accident – an event of sequence of events leading to harm; that is, death, injury, environmental damage or financial loss. Hazard – a physical situation or state of the platform that can lead to an accident.

19 19 Software Safety To understand the safely of a system Understand how they can fail. Investigate accidents and accident sequences To understand the sequence of events leading to the accident and to try and determine which subsystem failed. Accidents are usually caused by combination of failures and circumstances.

20 20 Key points Operational Profiles Helps us relate programs back to the environment in which program execute. Reliability is measured with respect to time. Software Safety Accidents and Hazards


Download ppt "1 Software Testing and Quality Assurance Lecture 37 – Software Quality Assurance."

Similar presentations


Ads by Google