16
Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

Embed Size (px)

Citation preview

Page 1: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

Lecture 11Testing and Debugging

SFDV2002 - Principles of Information Systems

Page 2: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

2

Recap of the Implementation phaseHardware Acquisition Software Acquisition

Make or buy decision Build: Database, programming and user interface

User preparation Documentation Ongoing training and user support

Deployment Site preparation Data preparation Installation and start-up

Testing and quality assurance User Acceptance

Page 3: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

3

Page 4: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

4

Overview

Verification versus ValidationInsuring quality software

Reviewing software Testing software

Debugging Tips and Strategies Techniques

Page 5: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

5

Verification versus ValidationVerification:

“Are we building the product right?”• Checking that the system meets its specified

functional and non-functional requirements.Validation:

“Are we building the right product?” checking that the software meets the

expectations of the customer.Techniques

Reviews/Peer reviews Testing - “The process of executing a program

with the intent of finding errors”

[Source: Boehm, 1979]

Page 6: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

6

ReviewsReviews:

Peers looking at all elements of the system/project searching for problems

Types of reviews Managerial Technical

Purpose of reviews, in particular technical reviewsTypes of technical reviews

Walkthrough Code readings Inspections

Objectives of Technical Reviews (Pressman)• To uncover errors in function, logic, or

implementation for any representation of the software

• To verify that the software under review meets it requirements

• To ensure that the software has been represented according to predefined standards

• To achieve software that is developed in a uniform manner

• To make projects more manageable

Page 7: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

7

Walkthroughs “… a static analysis

technique in which a designer or programmer leads members of the development team and other interested parties through a software product, the participants ask questions and make comments about possible errors, violation of development standards, and other problems”

[Source

: Sta

ir and R

eynold

s, 20

03

]

[Source: IEEE., 1997]

Participants•Developer•Implementer•Manager responsible for the product•Representative from SQA group

Page 8: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

8

Testing vs. Debugging

Software testing “… is a process that can be systematically

planned and specified. Test case design can be conducted, a strategy can be defined, and results can be evaluated against prescribed expectations”

Debugging “… occurs as a consequence of successful

testing. That is, when a test case uncovers an error, debugging is the process that results in the removal of the error”

[Pressman, 1997]

[Pressman, 1997]

Page 9: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

9

Testing Definitions

Defect, failures and errors (observe failure caused by defect)

Test cases Statement (event), input, and output

Test suite Collection of test cases

Defect testing – expose the defect Functional testing - focusing on result Structural testing – focusing on how the result is

produced

Page 10: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

10

Defect and failure•Defect: is the result of an error made in the systems construction•Failure: is an instance of an defect observed by the user (“symptom”)•Errors: “so we observe failures, which are caused by defects, which result from errors”

Test cases•Input to the test•Expected output from the system•Statement of what is being tested•Example:

Statement (squaring function) input 2 expected output 4Statement (function: getting the first name from the whole name) input: full name “Lance Elder” expected output: first name “Lance”

•Use test cases to test the systemTest suite

•Is a collection of test cases (both inputs and outputs)Defect testing

•The goal of defect testing is to expose the latent defects on a software system before the system is delivered•A successful defect test is when the system performs incorrectly and hence exposes a defect•Functional testing focusing on the result •Structural testing focusing on how the result is produced

Page 11: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

11

Structural TestingAlso known as white-box, glass-box or clear-box testingTest cases can derived for:

Operators, variables, constants, etc. Statements Branches Paths Functions

Test can device that • All independent paths within the module have been exercised

at least once (path testing)• Exercise all logical decisions on their true and false sides• Execute all loops at their boundaries and within their

operational bounds• Exercise internal data structures to assure their validity

Page 12: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

12

Functional TestingAlso known as black-box testing

“functional” testing because the tester is only concerned with the functionality and not the implementation of the software Attempts to find the following categories of errors:

Incorrect or missing functionalInterface errors other external elements.

Page 13: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

13

Other Testing IssuesManagement issues

Testing prioritisation Testing cost Developers

Other forms of testing Stress (volume) Testing - Test to see if a

system performs under load Regression Testing - Rechecking to uncover

bugs introduced in the testing/debugging process

Usability testing - for measuring how well people can actually use something

Page 14: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

14

Debugging Techniques

Commenting out suspicious lines of code Best to minimize to small sections Uncomment one section before commenting

out anotherDisplaying messages

MessageBox.Show() MsgBox()

Debugger When a program crashes – a debugger helps

the developer to locate the problem

Page 15: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

15

Debugging Techniques Examples

Dim x, y As Integer

x = 0

x = x + 1

‘x = y * 10

‘y = y * (x + 2)

Comment Method Message Box Method

Dim x, y As Integer

x = 0MsgBox(x)x = X + 1MsgBox(x)x = y * 10MsgBox(x & space(1) & y)y = y * (x + 2)MsgBox(x & space(1) & y)

Page 16: Lecture 11 Testing and Debugging SFDV2002 - Principles of Information Systems

16

References

Sommerville, Software Engineering, 7th Edition, Addison Wesley, 2004

Stazinger, et al., Systems Analysis and Design in a changing world, 4th Edition, Thomson, 2007

Pressman, Software Engineering: A Practitioner’s Approach, 4th Edition, 1997

Stair and Reynolds, Principles of Information Systems, 7th Edition, 2006

Sprague, Microsoft Visual Basic .NET: Introduction to Programming, 2nd Edition, 2003

--------------------------------------------------------- Note : End ot Tutorial 4 & Practical Sessions

5