Week 8 Software Testing - Fundamentals of Software Engineering PDF

Fundamentals of Software Engineering Testing Aspects of Testing 2 aspects to testing: Planning this activity  Carrying the activity out  Note this will draw on/enhance your experience in other modules. Testing The testing process is primarily concerned with finding defects within a piece of s...

Fundamentals of Software Engineering Testing Aspects of Testing 2 aspects to testing: Planning this activity  Carrying the activity out  Note this will draw on/enhance your experience in other modules. Testing The testing process is primarily concerned with finding defects within a piece of software. Testing can only show the presence of errors, not there absence Defect Finding How do you know that you have a defect in the software that you are developing? You find it by testing! An input-output model of program testing Verification and Validation Validation Are we building the right product? Verification Are we building the product right? Verification The aim of verification is to check that the software meets its stated functional and non functional requirements. Validation The aim of validation is to ensure that the product meets the customers expectations. Inspections and Reviews This involves “reading” any readable representation of the software such as the source code and specification. Inspections Source Code Reading through the source code can reveal errors of various kinds. Compare this with the pair programming approach used in some versions of Agile development. Source Code inspections This activity may help to find: Semantic errors  Inefficiencies  Algorithm use  Poor programming style (may affect maintainability of the system and lead to difficulty in performing updates)  Semantic/Logic Error double x; double b; double c; double a; x = -b + Math.sqrt(((b*b) – 4*a*c)/2*a); Where is the possible logical error here? Inefficiencies if (a <= 0) { // do something } if (a > 0) { // do something else } Code sample if (a <= 0) { // do something } else { // do something else } Inspection Issues Inspections may not find problems with: Interactions between systems  Timing problems  System performance  Inspections and testing A model of the software testing process Stages of Testing 3 stages of testing can be identified: Developmental testing  Release testing  User testing  Developmental Testing This sub phase consists of: Unit testing  Component Testing  System Testing  Unit Testing This is the process of testing program components, such as methods or object classes. You should design your tests to provide coverage of all the features of the object. Unit Testing activities You should: Test all operations associated with the object  Set and check the value of all attributes associated with the object  Put the object into all possible states.  Automated Test An automated test has three parts: Automated Test 1 Part 1 A set up part where you initialize the system with the test case, namely the inputs and expected outputs. Automated Test 2 Part 2 A call part where you call the object or method to be tested. Automated Test 3 Part 3 An assertion part where you compare the result of the call with the expected result. If the assertion evaluates to true, the test has been successful; if false then it has failed. The weather station object interface Equivalence partitioning Equivalence partitions Test-driven development Benefits of Test Driven Development Code Coverage  Regression Testing  Simplified Debugging  System Documentation  Regression Testing This involves running test sets that have successfully executed after changes have been made to a system  The regression test checks that these changes have not introduced new bugs into a system and that the new code interacts as expected with the existing code.  Release Testing This type of testing occurs when you have something worth releasing to a customer. It consists of: Requirements Based Testing  Scenario testing  Performance Testing  A usage scenario for the MHC-PMS Kate is a nurse who specializes in mental health care. One of her responsibilities is to visit patients at home to check that their treatment is effective and that they are not suffering from medication side -effects. On a day for home visits, Kate logs into the MHC-PMS and uses it to print her schedule of home visits for that day, along with summary information about the patients to be visited. She requests that the records for these patients be downloaded to her laptop. She is prompted for her key phrase to encrypt the records on the laptop. One of the patients that she visits is Jim, who is being treated with medication for depression. Jim feels that the medication is helping him but believes that it has the side -effect of keeping him awake at night. Kate looks up Jim’s record and is prompted for her key phrase to decrypt the record. She checks the drug prescribed and queries its side effects. Sleeplessness is a known side effect so she notes the problem in Jim’s record and suggests that he visits the clinic to have his medication changed. He agrees so Kate enters a prompt to call him when she gets back to the clinic to make an appointment with a physician. She ends the consultation and the system re-encrypts Jim’s record. After, finishing her consultations, Kate returns to the clinic and uploads the records of patients visited to the database. The system generates a call list for Kate of those patients who she has to contact for follow-up information and make clinic appointments. User Testing In practice there are 3 types of User Testing Alpha Testing  Beta testing  Acceptance Testing  The acceptance testing process Black Box Testing Black-box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied to virtually every level of software testing: unit, integration, system and acceptance. White Box Testing White-box testing is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality. In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing.