Textbook Notes (368,330)
158 (4)
158 .225 (4)
Chapter 10

Chapter 10 Designing Test Cases - UML for the IT Business Analyst

4 Pages
102 Views
Unlock Document

Department
158
Course
158 .225
Professor
Dave Parsons
Semester
Fall

Description
Designing Test Cases Technical test of the software components and architecture. Requirements based tests – Functional tests, see if it works System tests – Non-functional tests, whether it does things well enough. (E.g. Security Level) Testing is an activity aimed at proving that the software system does NOT do what it is supposed to do. There are usually always bugs. Some testing is manual (i.e. humans do exploratory testing) others are automatic (i.e. done with software). Quality Assurance – all different types of testing, testing is not just about the software. A bug is any variance between wheat the system is supposed to do and what is actually does. General Guidelines - Derive test cases from system use cases - Test basic flow scenarios - Test alternative and exception flow scenarios - Test of line-item requirements - Test features in user documentation - Cover valid and invalid data ranges - Relative frequency of use cases, things used more often. - Input/output relationships Structured Testing Process of using standardized techniques to locate flaws (bugs). Activities and Phases: - Structured walkthroughs – Throughout the project - Test cases – discovery phase - Unit tests – construction phase (only tests a single unit) - Black Box testing – construction phase - System tests – before acceptance (how the parts fit together) - User acceptance tests – before closeout (done by the client) Purpose – to locate bugs Goal – locate the maximum number of errors in the time available Test practices – save tests for reuse in regression testing. – prioritise areas that have proved problematic in the past. Structured Walkthroughs Non-computer based tests Done manually with a group (peer review) Can be performed before the software is written E.g. Find flaws in a decision table. Black Box Testing Requirements based No need to know anything about the internals of the software Can only see the output from the software not the code. Limitations as we can only determine the effect of a particular set of inputs by the response and output they give. Decision Tables – testing combinations of input conditions. Use Case Scenario Testing – tests the various scenarios of each use case using the use case documentation. Including basic, alternate and exception flows. White Box Testing Based on the knowledge of the internal workings of the system. Opposite to black box testing. Done by developers. Can look at the code of the system but cannot get total coverage as there are too many combinations of data. Coverage Quality levels: • S
More Less

Related notes for 158 .225

Log In


OR

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


OR

By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.


Submit