1 / 7

OO TESTING

OO TESTING. Module testing -> Class testing Integration testing Validation testing, system testing, alpha testing, beta testing OO software can be designed and built in many ways and using different kinds of modeling and documentation techniques

Download Presentation

OO TESTING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. OO TESTING • Module testing -> Class testing • Integration testing • Validation testing, system testing, alpha testing, beta testing • OO software can be designed and built in many ways and using different kinds of modeling and documentation techniques • Testing should reflect these techniques and models (if, for instance, you use use cases in analysis and design, then you should use them as input for testing as well). Software Engineering 2003 Jyrki Nummenmaa

  2. Class testing • Follows unit/module testing principles. • Typically classes represent an encapsulated (and hopefully rather independent) unit. • This is typically the software developers job. Software Engineering 2003 Jyrki Nummenmaa

  3. Integration testing • When using incremental software development, you typically first integrate test the new increment. • Then you integrate test the new increment with the existing system. EARLIER INCREMENTS NEW INCREMENT Software Engineering 2003 Jyrki Nummenmaa

  4. Validation testing • Use use cases! • If use cases are described using sequence diagrams or activity diagrams, it would be good to use them (unfortunately there is not much tool support…) • Typically an increment implements a small set of use cases -> test them. • You as a software developer should initially check if you can run through the use cases. And it would be nice to get a trace from the system to see if processing goes according to the sequence or activity diagram. Software Engineering 2003 Jyrki Nummenmaa

  5. General advice • When you develop your software, you test it. • Build your tests as programs or methods of your classes and store your inputs. • This helps you in regression testing (when you have changed something you will want to know if you have broken something that was ok). • Document the test set you create (at least make a list of test material you have and how to run them). • Test design was at least partly discussed in Pressman’s video. Software Engineering 2003 Jyrki Nummenmaa

  6. Test documentation • An overall testing plan for the software • Each test case: method and input • Each test execution: date, user, outcome • This is all, of course, only when the software moves into “official” testing. • Resources: http://www.rspa.com -> SE Resources -> Software Engineering Documents -> Software Test Plan – Sample Software Engineering 2003 Jyrki Nummenmaa

  7. General • Some systems can be very hard to test (e.g. distributed multi-layer systems) • Plan testing well ahead, so that you can implement necessary testing resources while you implement the system. • Otherwise you may find out, that good testing is really hard or practically impossible. • Note: The testing part on this course module was largely based on Pressman’s videotapes. Software Engineering 2003 Jyrki Nummenmaa

More Related