3156-14 - COMS W3156: Software Engineering, Fall 2001...

Info iconThis preview shows pages 1–13. Sign up to view the full content.

View Full Document Right Arrow Icon
COMS W3156: Software Engineering, Fall 2001 Lecture #14: Implementation II, LDAP Janak J Parekh janak@cs.columbia.edu
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Administrativia LDAP configured HW2 due now Design due in one week Requirements update pending (v1.2) LDAP renaming Missing some boolean operators Something else? Webboard… You are supposed to do the homework
Background image of page 2
Next class I’m debating
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Today’s class Implementation, continued (testing) LDAP
Background image of page 4
From last class Conclusion: we need a compromise – highlight faults, while accepting that not all faults will be detected Black-box test cases first (specifications) Then, develop additional glass-box techniques (code)
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Black-box module testing Goal: devise small number of test cases that cover most of the possibilities Every test case must be chosen to detect a previously undetected fault: don’t repeat Equivalence testing and boundary value analysis
Background image of page 6
Equivalence class testing Break down cases into equivalence classes Example: database with max 16,000 records If it works for 251, it’ll probably work for 12,000 Define classes that need to be tested Less than 1 record From 1 to 16,000 records More than 16,000 records
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Boundary testing Take the equivalence classes to the next level 0 records 1 record 2 records 723 records 16,382 records 16,383 records 16,384 records
Background image of page 8
Boundary testing (II) Test both sides of the classes While the example referred to input specifications, can also boundary-test output cases Example: payroll Test deductions between, and including, min and max deduction values, as well as beyond them Devise test cases to get these results
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Boundary testing (III) • In general, for a range {R 1 , R 2 }, 5 test cases: – Less than R 1 – Equal to R 1 – Greater than R 1 , less than R 2 – Equal to R 2 – Greater than R 2 Need to start thinking this way
Background image of page 10
Functional testing Test on functionalities of module Step 1: determine functions of module Step 2: Devise test data for each low-level function Step 3: Determine higher-level functions (picture) This is hybrid black-box and glass-box
Background image of page 11

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Functional testing (II) In practice, need to do functional analysis, since it’s not always so simple Often, cross-module functionality Object-oriented doesn’t help Difficult to resolve at times, but general principle remains sound
Background image of page 12
Image of page 13
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 06/09/2010 for the course COMS W3156 taught by Professor Janakjparekh during the Fall '01 term at Columbia.

Page1 / 41

3156-14 - COMS W3156: Software Engineering, Fall 2001...

This preview shows document pages 1 - 13. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online