Article Oriented Testing and Test-Driven Development .


40 views
Uploaded on:
Description
Goals. To talk about when testing happens in the life cycleTest-driven advancement advocates early testing!To spread the procedures and devices connected with item arranged testingAnalysis and Design TestingClass TestsIntegration TestsValidation TestsSystem TestsTo examine test arrangements and execution for ventures.
Transcripts
Slide 1

Question Oriented Testing and Test-Driven Development Based on notes from James Gain ( jgain@cs.uct.ac.za ) Larman, part 21 and notes on Larman from George Blank of NJIT in addition to Glenn Blank\'s elaborations and extensions

Slide 2

Objectives To talk about when testing happens in the life cycle Test-driven advancement advocates early testing! To cover the procedures and apparatuses connected with protest situated testing Analysis and Design Testing Class Tests Integration Tests Validation Tests System Tests To talk about test arrangements and execution for ventures ? investigation configuration test code

Slide 3

Object-Oriented Testing When ought to testing start? Investigation and Design: Testing starts by assessing the OOA and OOD models How would we test OOA models (prerequisites and utilize cases)? How would we test OOD models (class and succession graphs)? Organized walk-throughs, models Formal audits of accuracy, culmination and consistency Programming: How does OO make testing not the same as procedural programming? Idea of a "unit" expands because of class epitome Integration concentrates on classes and their setting of an utilization case situation or their execution over a string Validation may even now utilize customary discovery strategies

Slide 4

Test-driven programming eXtreme Programming (XP) advocates composing tests for units before composing real code for units Why may this practice be a smart thought? Compels code to outline: How so? Plan - > Test - > Code … in little emphasess Promotes approval and unwavering quality: Why? Continuously rerun all tests (simpler with computerized testing) before coordinating new code in a discharge Increases certainty to change code: Why? Changes shouldn\'t break old code in the event that you can test old code Creed of XP: "grasp change"

Slide 5

The Bug Curve

Slide 6

Criteria for Completion of Testing When are we done testing? (Are we there yet?) How to answer this question is still an examination address One view: testing is never done… the weight just moves from the designer to the client Or: testing is done when you come up short on time or cash Or utilize a factual model: Assume that blunders rot logarithmically with testing time Measure the quantity of mistakes in a unit period Fit these estimations to a logarithmic bend Can then say: "with our tentatively substantial factual model we have done adequate testing to state that with 95% certainty the likelihood of 1000 CPU hours of disappointment free operation is no less than 0.995"

Slide 7

YAHOO!

Slide 8

Strategic Issues for an effective programming testing methodology: Specify item prerequisites much sooner than testing begins For instance: convenientce, practicality, ease of use Do so in a way that is unambiguous and quantifiable Understand the clients of the product, with utilize cases Develop a testing arrangement that accentuates "fast cycle testing" Get snappy input from a progression of little incremental tests Build powerful programming that is intended to test itself Use statements, exemption taking care of and computerized testing instruments (Junit). Lead formal specialized surveys to evaluate test methodology and experiments - "Who watches the watchers?"

Slide 9

Testing Analysis and Design Syntactic accuracy: Are UML and ADT documentation utilized effectively? Semantic rightness: Does the model mirror this present reality issue? Is UML utilized as planned by its creators? Is the ADT configuration finish (catching every one of the classes and operations in UML chart) and reasonable? Testing for consistency: A conflicting model has representations in one section that are not reflected in different parts of the model

Slide 10

Testing the Class Model Revisit the Use Cases, CRC cards and UML class demonstrate. Watch that all joint efforts are legitimately spoken to. Examine the portrayal of each CRC list card to ensure a designated obligation is a piece of the partner\'s definition. Case: in a state of offer framework. A read Visa duty of a credit deal class is expert if fulfilled by a Visa colleague Invert associations with guarantee that every partner requested an administration is accepting solicitations from a sensible source Example: a charge card being requested a buy sum Have you tried your investigation and plan? If not, who will isn\'t that right?

Slide 11

Testing OO Code Class tests Integration tests System tests Validation tests

Slide 12

[1] Class (Unit) Testing Smallest testable unit is the epitomized class Test every operation as a major aspect of a class progressive system since its class chain of importance characterizes its setting of utilization Approach: Test every technique (and constructor) inside a class Test the state conduct (qualities) of the class between strategies How is class trying not quite the same as ordinary testing? Routine testing concentrates on info prepare yield, while class testing concentrates on every strategy, then planning arrangements of techniques to practice conditions of a class But white-box testing can at present be connected

Slide 13

Class Testing Process How to test? class to be tried outcomes programming engineer test cases Why a circle?

Slide 14

Class Test Case Design Identify every experiment remarkably - Associate experiment unequivocally with the class and additionally technique to be tried State the reason for the test Each experiment ought to contain: A rundown of messages and operations that will be practiced as an outcome of the test A rundown of special cases that may happen as the question is tried A rundown of outer conditions for setup (i.e., changes in the earth outside to the product that must exist keeping in mind the end goal to appropriately lead the test) Supplementary data that will help in comprehension or actualizing the test Automated unit testing instruments encourage these prerequisites

Slide 15

Challenges of Class Testing Encapsulation: Difficult to acquire a preview of a class without building additional strategies which show the classes\' state Inheritance and polymorphism: Each new setting of utilization (subclass) requires re-testing in light of the fact that a strategy might be executed in an unexpected way (polymorphism). Other unaltered strategies inside the subclass may utilize the reclassified strategy and should be tried White box tests: Basis way, condition, information stream and circle tests can all apply to individual techniques, however don\'t test connections between techniques

Slide 16

Random Class Testing Identify techniques appropriate to a class Define requirements on their utilization – e.g. the class should dependably be instated first Identify a base test arrangement – an operation grouping that characterizes the base life history of the class Generate an assortment of irregular (however substantial) test successions – this activities more mind boggling class occurrence life histories Example: A record class in a saving money application has open , setup , store , pull back , adjust , outline and close techniques The record must be opened first and shut on consummation Open – setup – store – pull back – close Open – setup – store –* [deposit | pull back | adjust | summarize] – pull back – close . Create irregular test successions utilizing this layout

Slide 17

[2] Integration Testing OO does not have a various leveled control structure so customary top-down and base up reconciliation tests have small importance Integration connected three distinctive incremental systems: Thread-based testing: incorporates classes required to react to one info or occasion Use-based testing: coordinates classes required by one utilize case Cluster testing: coordinates classes required to show one joint effort What mix testing procedures will you utilize?

Slide 18

Random Integration Testing Multiple Class Random Testing For every customer class, utilize the rundown of class techniques to produce a progression of irregular test arrangements. Techniques will send messages to other server classes. For every message that is created, decide the teaming up class and the relating strategy in the server protest. For every strategy in the server protest (that has been conjured by messages sent from the customer question), decide the messages that it transmits For each of the messages, decide the following level of techniques that are summoned and fuse these into the test grouping

Slide 19

[3] Validation Testing Are we fabricating the correct item? Approval succeeds when programming capacities in a way that can be sensibly expected by the client. Concentrate on client noticeable activities and client conspicuous yields Details of class associations vanish at this level Apply: Use-case situations from the product prerequisites spec Black-box testing to make an insufficiency list Acceptance tests through alpha (at engineer\'s site) and beta (at client\'s site) trying with real clients How will you approve your term item?

Slide 20

Acceptance testing, anybody?

Slide 21

[4] System Testing Software might be a piece of a bigger framework. This regularly prompts to "blame dispensing" by other framework dev groups Finger directing guard: Design blunder taking care of ways that test outside data Conduct a progression of tests that recreate awful information Record the consequences of tests toward use as proof Types of System Testing: Recovery testing: how well and rapidly does the framework recoup from shortcomings Security testing: check that insurance components incorporated with the framework will shield from unapproved get to (programmers, displeased workers, fraudsters) Stress testing: put strange load on the framework Performance testing: research the run-time execution inside the setting of a coordinated framework

Slide 22

Can we improve?

Slide 23

Testing Summary Testing influences all phases of programming building cycle One procedure is a base up approach – class, joining, approval and framework level testing XP advocates test-driven advancement: arrange tests before you compose any code, then test any progressions Other systems: white box (investigate specialized interior subtle elements) discovery (see the outer conduct)

Recommended
View more...