Docsity
Log inSign up
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
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 Store documents

The best documents sold by students who completed their studies

Search through all study resources
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

University Rankings

Discover the best universities in your country according to Docsity users

Free resources

Our save-the-student-ebooks!

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

From our blog

Exams and Study
Go to the blog

Formal Test Cases - Banking - Lecture Slides, Slides of Banking and Finance

Bhupendra Narayan Mandal UniversityBanking and Finance

Banking is an ever green field of study. In these slides of Banking, the Lecturer has discussed following important points : Formal Test Cases, Software System, Instructions Designed, Test Plans, Classification, Descriptive Title, Subsystem Or Module, Instructions, Expected Result, Cleanup

Typology: Slides

2012/2013

Uploaded on 07/29/2013

sathyanarayana
sathyanarayana 🇮🇳

4.4

(21)

140 documents

1 / 15

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
10.8 Writing Formal Test Cases and Test
Plans
A test case is an explicit set of instructions designed to
detect a particular class of defect in a software system.
• A test case can give rise to many tests.
•Each test is a particular running of the test case on a
particular version of the system.
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download Formal Test Cases - Banking - Lecture Slides and more Slides Banking and Finance in PDF only on Docsity!

10.8 Writing Formal Test Cases and Test

Plans

A test case is an explicit set of instructions designed to detect a particular class of defect in a software system.

  • A test case can give rise to many tests.
  • Each test is a particular running of the test case on a particular version of the system.

Test plans

A test plan is a document that contains a complete set of test cases for a system —Along with other information about the testing process.

  • The test plan is one of the standard forms of documentation.
  • If a project does not have a test plan: —Testing will inevitably be done in an ad-hoc manner. —Leading to poor quality software.
  • The test plan should be written long before the testing starts.
  • You can start to develop the test plan once you have developed the requirements.

Levels of importance of test cases

  • Level 1: —First pass critical test cases. —Designed to verify the system runs and is safe. —No further testing is possible.
  • Level 2: —General test cases. —Verify that day-to-day functions correctly. —Still permit testing of other aspects of the system.
  • Level 3: —Detailed test cases. —Test requirements that are of lesser importance. —The system functions most of the time but has not yet met quality objectives.

Determining test cases by enumerating

attributes

It is important that the test cases test every aspect of the requirements.

  • Each detail in the requirements is called an attribute. —An attribute can be thought of as something that is testable. —A good first step when creating a set of test cases is to enumerate the attributes. —A way to enumerate attributes is to circle all the important points in the requirements document.
  • However there are often many attributes that are implicit.

Top down testing

  • Start by testing just the user interface.
  • The underlying functionality are simulated by stubs. —Pieces of code that have the same interface as the lower level functionality. —Do not perform any real computations or manipulate any real data.
  • Then you work downwards, integrating lower and lower layers.
  • The big drawback to top down testing is the cost of writing the stubs.

Bottom-up testing

  • Start by testing the very lowest levels of the software.
  • You needs drivers to test the lower layers of software. —Drivers are simple programs designed specifically for testing that make calls to the lower layers.
  • Drivers in bottom-up testing have a similar role to stubs in top-down testing, and are time-consuming to write.

Vertical strategies for incremental integration

testing

The test-fix-test cycle

When a failure occurs during testing:

  • Each failure report is entered into a failure tracking system.
  • It is then screened and assigned a priority.
  • Low-priority failures might be put on a known bugs list that is included with the software’s release notes.
  • Some failure reports might be merged if they appear to result from the same defects.
  • Somebody is assigned to investigate a failure.
  • That person tracks down the defect and fixes it.
  • Finally a new version of the system is created, ready to be tested again.

Regression testing

  • It tends to be far too expensive to re-run every single test case every time a change is made to software.
  • Hence only a subset of the previously-successful test cases is actually re-run.
  • This process is called regression testing. —The tests that are re-run are called regression tests.
  • Regression test cases are carefully selected to cover as much of the system as possible.

The “law of conservation of bugs”:

  • The number of bugs remaining in a large system is proportional to the number of bugs already fixed

Deciding when to stop testing

  • All of the level 1 test cases must have been successfully executed.
  • Certain pre-defined percentages of level 2 and level 3 test cases must have been executed successfully.
  • The targets must have been achieved and are maintained for at least two cycles of ‘builds’. —A build involves compiling and integrating all the components. —Failure rates can fluctuate from build to build as: - Different sets of regression tests are run. - New defects are introduced.