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 Testing: Definitions, Approaches, and Best Practices, Study notes of Software Engineering

Georgia Institute of Technology - Main CampusSoftware Engineering

Definitions and explanations for various terms related to software testing, including verification, validation, testing, error, fault, and failure. It also covers different approaches to verification and testing, such as testing, inspection, formal proof, and debugging. The importance of testing in the software development lifecycle and the concept of adequacy criterion. It also covers different types of testing, including black box and white box testing, and various testing strategies and techniques.

Typology: Study notes

Pre 2010

Uploaded on 08/05/2009

koofers-user-24i-2
koofers-user-24i-2 🇺🇸

10 documents

1 / 7

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
• Testing
– Chapter 23
– Chapter 22
– testplan.doc
Definitions
•Verification: has the program been implemented
correctly?
– "Are we building the program right?"
– Process question
•Validation: has the correct program been
implemented?
– "Are we building the right program?"
– Product question
•Testing: the process of executing a program with
the intent of detecting problems
– Can be used for either verification or validation
•Error: a (human) mistake made in the
process of constructing software
•Fault/bug/defect: the manifestation of an
error in the software
•Failure: a condition arising when executing
software produces an incorrect result
•-
α
(alpha) test: informal, in-house, early
•-
β
(beta) test: formal, out-of-house, pre-
release
•Sanity check: quick-and-dirty, just before
shipping
pf3
pf4
pf5

Partial preview of the text

Download Software Testing: Definitions, Approaches, and Best Practices and more Study notes Software Engineering in PDF only on Docsity!

• Testing

  • Chapter 23
  • Chapter 22
  • testplan.doc

Definitions

  • Verification : has the program been implemented correctly? - "Are we building the program right?" - Process question
  • Validation : has the correct program been implemented? - "Are we building the right program?" - Product question
  • Testing : the process of executing a program with the intent of detecting problems - Can be used for either verification or validation

• Error : a (human) mistake made in the

process of constructing software

• Fault/bug/defect : the manifestation of an

error in the software

• Failure : a condition arising when executing

software produces an incorrect result

• - α (alpha) test: informal, in-house, early

• - β (beta) test: formal, out-of-house, pre-

release

• Sanity check: quick-and-dirty, just before

shipping

Approaches to Verification

• Testing: exercising software to try and

generate failures

• Inspection/review/walkthrough: systematic

group review of program text to detect

faults

• Formal proof: proving that the program text

implements the program specification

• (execution vs. non-execution based testing)

Comparison

  • Testing:
    • purpose: create failure
    • danger: inadequate test set
  • Proof
    • p: prove correctness
    • d: only/select functionality
  • Review
    • p: detect defects
    • d: informal
  • Debugging
    • p: find and correct defects
    • d: local fixes and new defects

Testing and S/W Lifecycle

Requirements ..................................... Acceptance Testing Design ................................. Integration Testing Coding ................ Unit Testing Maintenance ..... Regression Testing

The V-model of development

Black Box

Generate tests to check desired program functionality without knowledge of how the code works

  • Equivalence partitioning: divide possible test sets into equivalence classes (for valid and invalid inputs), and run one test from each class
  • Boundary value analysis: look for test cases on the boundaries of the equivalence classes
  • Exhaustive testing: run every possible input (infeasible)
  • Functional testing: construct tests directly from the requirements document
  • Random: if the tests are randomly generated with a distribution that corresponds to the expected usage of the program, then you can get a reliability estimate, such as MTBF, to use as an adequacy criterion

White Box

• exhaustive not possible (in reality)

• alone not sufficient

  • forgets about specs
  • doesn’t check if logic is flawed
  • are proper equations used?

White Box testing - Coverage

  • Adequacy based on control or data flow properties
  • Statement coverage: % of all executable statements exercised during testing - Testing a statement once does not guarantee that the statement is correct - Some statements may be "dead code"
  • Branch coverage: % of conditional branches exercised - (do tests exercise both the then and else branches of each if statement even if one of them is empty?) - Condition coverage: % of boolean expression constituents exercised - Was there a test that caused the then branch to be taken because a was true? Because b was true? if (a || b) then ... else ... - Path coverage: % of program paths executed (infeasible or impossible) - Data flow coverage measures - For a given use of a variable and for each assignment to that variable that could "reach" that use, is there a test that causes execution to proceed from the assignment to the use?

Error-based testing

  • Look for evidence of a specific class of errors, such as “off by one”, known to occur in programs - error checklists, (may be language-dependent)
  • Adequacy is the extent of possible error opportunities evaluated
  • Mutation analysis (fault seeding)
    • Generate a set of program variants ( mutants ) containing a comprehensive set of intentionally seeded bugs representative of typical errors
    • Compose tests sufficient to distinguish the generated programs from the original (kill the mutant)

non-functional testing/analysis

• Performance

• Load

• Usability

• Security

• Portability

• Maintainability / complexity metrics

• Coding standards

  • you will maybe look at performance, load, reliability, usability…
  • need operational model
  • instrumentation of the code?
  • still need quantifiable adequacy criteria – when are you done testing, when do you determine that system meets this non-functional requirement
  • stress-testing valuable, even if conditions outside of operational model

Guideliness

  • "Program testing can best show the presence of errors but never their absence" - Dijkstra
  • 50% of program development effort goes into testing, primarily integration testing
  • "The act of designing tests is one of the most effective error prevention mechanisms known" - Beizer

Bug Tracking

  • database w/ bug reports
  • bug id, name/title, (keywords)
  • area where it occurred, version number
  • priority, (high, low… must fix for release x); severity
  • conditions under which occurred, platform/environment, … -> how to reproduce, what occurred vs. expected outcome
  • status fixed, will not fix, duplicate, non-reproducible, by design…
  • assigned to -> who should fix it
  • don’t overkill bug tracking interface – should be easy to use, so that it actually gets used!
  • products (e.g., Bugzilla)