Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Software Engineering: Testing and Fault Classification, Study notes of Software Engineering

University of Pittsburgh (Pitt) - Medical Center-Health SystemSoftware Engineering

An overview of software testing and fault classification. It discusses various types of faults, such as algorithmic, syntax, documentation, and stress or overload faults. The document also introduces different fault classification schemes, including ibm's orthogonal defect classification and hp's fault classification. Additionally, it covers testing strategies, techniques, and tools, as well as the importance of code reviews and formal proof techniques.

Typology: Study notes

Pre 2010

Uploaded on 09/02/2009

koofers-user-olu
koofers-user-olu 🇺🇸

9 documents

1 / 11

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
CS 1530 Software Engineering Fall
2004
Software Engineering
CS / COE 1530
Testing
How does software fail?
■Wrong requirement: not what the
customer wants
■Missing requirement
■Requirement impossible to implement
■Faulty design
■Faulty code
■Improperly implemented design
Terminology
■Fault identification: what fault caused
the failure?
■Fault correction / removal: change the
system to take out the fault
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Software Engineering: Testing and Fault Classification and more Study notes Software Engineering in PDF only on Docsity!

CS 1530 Software 2004 Engineering Fall

Software Engineering

CS / COE 1530

Testing

How does software fail?

■ Wrong requirement: not what the

customer wants

■ Missing requirement

■ Requirement impossible to implement

■ Faulty design

■ Faulty code

■ Improperly implemented design

Terminology

■ Fault identification: what fault caused

the failure?

■ Fault correction / removal: change the

system to take out the fault

Types of faults

■ Algorithmic fault

■ Syntax fault

ν ≠ syntax error

■ Computation and precision

fault

■ Documentation fault

■ Stress or overload fault

■ Capacity or boundary fault

■ Timing or coordination fault

 Throughput or performance

fault

 Recovery fault

 Hardware and system software

fault

 Standards and procedures fault

CS 1530 Software Engineering Fall 2004

Chillarege et al.’s Orthogonal

Defect Classification

■ Orthogonal

■ each classified item belongs to exaclty one

class

■ Fault of omission

■ Fault of commission

Table 8.1. IBM orthogonal defect classification. Fault type Meaning Function Fault that affects capability, end-user interfaces, product interfaces, interface with hardware architecture, or global data structure Interface Fault in interacting with other components or drivers via calls, macros, Checking control blocks or parameter listsFault in program logic that fails to validate data and values properly before they are used Assignment Timing/serialization Fault in data structure or code block initialization.Fault that involves timing of shared and real-time resources Build/package/merge Fault that occurs because of problems in repositories, management changes, Documentation or version controlFault that affects publications and maintenance notes Algorithm Fault involving efficiency or correctness of algorithm or data structure but not design

CS 1530 Software 2004 Engineering Fall

Test Organization (2)

■ Performance testing

■ with respect to specified hardware and software

environment

■ Validation testing

■ test in customer’s actual working environment

■ validated system if successful

■ Acceptance test

■ system is checked against customer’s

requirements at site

■ followed by final installation run

CS 1530 Software Engineering Fall 2004

Test Organization

CS 1530 Software 2004 Engineering Fall

Black Box vs. White Box

Testing

■ Black box

■ tester does not know anything about the

test object internals

■ White box

■ tester knows about internals and exploits

that knowledge to write good test cases

■ Example: know logic structure can ensure

branch coverage in test cases

CS 1530 Software 2004 Engineering Fall

How to Find Faults?

■ Reviews

■ Proof techniques

■ static analysis techniques

■ Testing

■ Dynamic Analysis

■ tools such as preFix, ESP, valgrind

CS 1530 Software Engineering Fall 2004

Code Review

■ Walkthrough

■ developer presents code and doucumentation and

leads review

■ Inspection

■ review team checks code & documentation against

a list of concerns

■ overview meeting + individual inspection +

inspection meeting

■ Jones showed that code review is most

effective technique for finding faults

Proving code correct

■ Formal proof techniques

■ done by hand

■ Symbolic execution

■ Recently successful: symbolic model checking

■ build model and check if no fault the original

system is correct

■ Automated theorem-proving

■ works well in specialized domains but hard in

general

Comparing techniques

Table 8.5. Fault discovery percentages by fault origin. Discovery technique Requirements Design Coding Documentation Prototyping Requirements review (^4040 3515 350 ) Design review 15 55 0 15 Code inspection Unit testing 201 405 6520 250 Table 8.6. Effectiveness of fault discovery techniques. (Jones 1991) Requirements faults Design faults Code faults Documentation faults Reviews Fair Excellent Excellent Good Prototypes Good Fair Fair Not applicable Testing Correctness Poor^ Poor^ Good^ Fair proofs Poor Poor Fair Fair CS 1530 Software Engineering Fall 2004

Test Strategy Strength

Integration testing

■ Bottom-up

■ Top-down

■ Big-bang

■ Sandwich testing

■ Modified top-down

■ Modified sandwich

CS 1530 Software 2004 Engineering Fall

Example Hierarchy

CS 1530 Software Engineering Fall 2004

Bottom-up Integration Testing

  • Uses

Component

Drivers

CS 1530 Software 2004 Engineering Fall

Top-down Integration Testing

Uses component stubs

CS 1530 Software 2004 Engineering Fall

Microsoft Synch-and-Stabilize

CS 1530 Software Engineering Fall 2004

Traditional vs. OO-Testing

Test planning

■ Establish test objectives

■ Design test cases

■ Write test cases

■ Test test cases

■ Execute tests

■ Evaluate test results

CS 1530 Software 2004 Engineering Fall

The Test Plan

■ Describes how software will be

demonstrated to be correct

■ have to know requirements, specifications,

& design

■ Plan contents:

■ series of tests (at unit, integration,

functional, acceptance & installation level)

■ how tests will be run and criteria when test

is complete and satisfactory