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

Lecture Slides on Module Dependencies Testing | CS 3110, Study notes of Computer Science

Cornell UniversityComputer Science

Material Type: Notes; Class: Data Structures and Functional Programming; Subject: Computer Science; University: Cornell University; Term: Spring 2008;

Typology: Study notes

Pre 2010

Uploaded on 08/30/2009

koofers-user-f0n
koofers-user-f0n 🇺🇸

9 documents

1 / 9

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
CS 3110
Module dependencies
Testing
Lecture 10
Andrew Myers
30 Sept 08
2
Hierarchical decomposition
•In well-designed code:
– Bottom level code units are methods/functions
(~1–100 LOC)
– Modules have up to a couple of dozen ops
– At most a couple of dozen modules to implement
related functionality
•Top-level modules scale to ~10k LOC progs
•Modularity alone isn’t enough for large
systems—need hierarchy of modules
pf3
pf4
pf5
pf8
pf9

Partial preview of the text

Download Lecture Slides on Module Dependencies Testing | CS 3110 and more Study notes Computer Science in PDF only on Docsity!

CS 3110

Module dependencies

Testing

Lecture 10

Andrew Myers

30 Sept 08

2

Hierarchical decomposition

  • In well-designed code:
    • Bottom level code units are methods/functions (~1–100 LOC)
    • Modules have up to a couple of dozen ops
    • At most a couple of dozen modules to implement related functionality
  • Top-level modules scale to ~10k LOC progs
  • Modularity alone isn’t enough for large

systems—need hierarchy of modules

3 Hierarchical decomposition

  • Divide and conquer: must break large

modules into smaller modules

  • Multiple levels of hierarchy
  • Good design if: only need to think about one

module, one level at a time

  • How to manage large-scale design? 4 Modular structure
  • Program is composed of modules
  • One module depends on another if it uses a

value, function, or type from it

  • Module Dependency Diagram (MDD) helps

understand large-scale program structure

Module 1 Module 2 Module 3 depends on

7 Example 2

(generated from

OCaml source

by dep2dot )

8 Bottom-up development

  • Bottom-up: develop modules before the modules that depend on them
  • Advantage: catch key technology/performance issues early
  • Advantage: always working code, unit testing
  • Disadvantage: catch large- scale design flaws late

A D B

C

F G

E H I

9 Top-down development

  • Top-down: develop using modules before modules they depend on
  • Advantage: get high-level design right from start, do integration testing
  • Advantage: easier to design interfaces well, quickly spec out system
  • Disadvantage: harder to test until program complete

A D B

C

F G

E H I

10 Unit/component testing

  • Test modules through their interfaces
  • Test each implementation against interface separately
  • Write test harness to test each module
  • Good match to bottom-up development A D B

C

F G

THF E H I

THE

13 Waterfall model

  • An abstraction of different activities in software projects
  • Not always this neat!

requirements analysis

design

implementation

validation/verification

maintenance

specs implementation test cases proofs assurance

  • Validation : are requirements right?
  • Verification : does impl meet spec?
  • Formal verification
  • Testing
  • Assurance: reasonable confidence that right system has been built, correctly requirements 14 Testing
  • Goal is assurance that system works
  • (Completely) working system is free of faults:
  • Errors in requirements
  • Errors in specifications
  • Errors in implementation
  • Strategy: build a set of test cases that if

passed give assurance

  • Test: compare actual to expected outputs
  • Test case: inputs to program/component, and expected outputs
  • Collection of test cases: test suite

15 Coverage

  • How can finite test cases give strong assurance?
  • Key: test cases that have good coverage of possible faults
  • Exhaustive testing:
    • Test all possible inputs (against spec; against other, simpler, obviously correct implementation)
    • Usually infeasible (input space too large) val plus: int->int->int has 2^64 inputs (584 years at 1/ns)
    • Sometimes can exhaustively test up to some input “size” -- faults usually have small counterexamples.
  • Random testing:
    • Generate inputs randomly. Idea: if all tests pass, unlikely to see faults in production
    • Problem: only works if inputs have same random distribution as “in nature”. Hard!
  • Usually must design test cases -- an art 16 Black-box testing
  • Idea: test cases achieve coverage based on specification only - Aka “closed-box”
  • Idea: specification divides space of possible inputs into different regions. - Test boundary values and corner cases
  • Examples: plus: int->int->int lmax : int list -> int
  • Advantages:
    • Can write test cases before implementation
    • Can write test cases independently
    • Helps find problems in specifications
  • Disadvantages:
    • May not test all code or test code thoroughly
  • A good place to start designing tests