Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Engineering of Standalone Programs University of Colorado

Similar presentations


Presentation on theme: "Software Engineering of Standalone Programs University of Colorado"— Presentation transcript:

1 Software Engineering of Standalone Programs University of Colorado
Testing Object-Oriented Software – Part One Object-Oriented Principles from a testing perspective Test early, test often, test enough. Software Engineering of Standalone Programs University of Colorado January 20, 2002 ECEN OO Testing - University of Colorado

2 ECEN5033 - OO Testing - University of Colorado
Primary reference A Practical Guide to Testing Object-Oriented Software John McGregor and David A. Sykes Addison Wesley – Object Technology Series, 2001 ISBN January 20, 2002 ECEN OO Testing - University of Colorado

3 What is software testing?
The evaluation of the work products created during a software development effort Done throughout development effort Applied to all development products (models) before as well as after code is written More specifically The process of uncovering evidence of defects Since a defect can be introduced at any phase, testing efforts find defects in all phases Testing is not the debugging, isolation, or repair of bugs January 20, 2002 ECEN OO Testing - University of Colorado

4 ECEN5033 - OO Testing - University of Colorado
What is software? The instruction codes and data necessary to accomplish some task on a computer or microprocessor All representations of those instructions and data Analogy Architects and builders can examine blueprints to spot problems We can examine analysis and design models before the code is written with a form of “execution.” January 20, 2002 ECEN OO Testing - University of Colorado

5 ECEN5033 - OO Testing - University of Colorado
Assumptions Development process is incremental with iterations within each increment Models are expressed in UML Software design in accordance with good design principles inheritance data hiding abstraction low coupling high cohesion January 20, 2002 ECEN OO Testing - University of Colorado

6 Testing vs. Quality Assurance
Responsible for test plans and system testing Monitor testing during development Keep statistics Testing is a necessary but insufficient part of a QA process QA addresses activities designed to prevent defects remove defects Testing helps in identifying problems and failures Testing helps QA by identifying them early in dev. January 20, 2002 ECEN OO Testing - University of Colorado

7 What’s special about testing OO software?
Features such as class inheritance and interfaces support polymorphism in which code manipulates objects without their exact class being known Testers must ensure the code works no matter what the exact class of such objects might be. Features that support data hiding complicate testing because operations must be added to a class interface (by the developer) just to support testing January 20, 2002 ECEN OO Testing - University of Colorado

8 OO Testing Is Still Testing
We still do unit testing but we change the definition of unit integration testing to make sure subsystems work correctly together system testing to verify that requirements are met regression testing to make sure previous functionality still works after new functionality is added January 20, 2002 ECEN OO Testing - University of Colorado

9 OO Testing Is Not Just Old Style Testing
Fundamental aspect of OO software OO Software is designed as a set of objects that essentially model a problem and then collaborate to effect a solution While the solution may change over time, the structure and components of the problem do not change as frequently a program structured from the problem is more adaptable to changes later components derived from the problem can be reused in development of other programs to solve related problems January 20, 2002 ECEN OO Testing - University of Colorado

10 ECEN5033 - OO Testing - University of Colorado
Benefit Many analysis models map straightforwardly to design models which, in turn, map to code Start testing during analysis Refine the same tests for design Refine those tests for code January 20, 2002 ECEN OO Testing - University of Colorado

11 Advantages of testing analysis and design models
Test cases can be identified earlier in the process, even while determining requirements Early test cases help analysts and designers to better understand and express requirements ensure that specified requirements are testable Bugs can be found early – saving time and money Test cases can be reviewed for correctness early in the project If test cases are applied to models early, misunderstandings of requirements on the part of testers can be corrected early January 20, 2002 ECEN OO Testing - University of Colorado

12 Avoid the “bugging phase”
In other words, model testing helps to ensure that testers and developers have a consistent understanding of the system requirements early in the project. However, code testing is still important January 20, 2002 ECEN OO Testing - University of Colorado

13 Categories of OO Testing
Model testing Class testing instead of unit testing Class interaction testing instead of integration testing System and subsystem testing Acceptance testing Self-testing Should you try to apply all of these? Probably not if you want to be taken seriously and be employed. You should learn to recognize approaches and techniques that will apply to your project in a useful and affordable way. January 20, 2002 ECEN OO Testing - University of Colorado

14 ECEN5033 - OO Testing - University of Colorado
Testing perspective Skeptical, objective, thorough, systematic Look at any development product and question its validity Attitude that should be held by a developer as well as a full-time tester To ensure a. the software will do what it is supposed to do b. the software will not do what it is not supposed to do Ensuring “a.” does not automatically ensure “b.” January 20, 2002 ECEN OO Testing - University of Colorado

15 ECEN5033 - OO Testing - University of Colorado
Object An operational entity that encapsulates both specific data values and the code that manipulates those values. Provides the mechanisms needed to receive messages dispatch methods return results associates instance attributes with methods January 20, 2002 ECEN OO Testing - University of Colorado

16 Objects from a testing perspective
ECEN5033 Testing OO Software January 20, 2002 Objects from a testing perspective Encapsulates – the complete definition of the object is easy to identify, easy to pass around, easy to manipulate Hides information – can make changes to the object hard to observe which makes checking test results difficult Has a state that persists for its life. This state can become inconsistent and can be the source of incorrect behavior Has a lifetime – can be examined during its lifetime to check if it is in the right state based on its lifetime. Common source of failures – construction of an object too late or destruction of it too early In the referenced book, describe a variety of techniques for testing the interactions among objects in Chapter 6 other aspects of testing objects in Chapter 5 and Chapter 7 January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

17 ECEN5033 Testing OO Software
January 20, 2002 Message Message – a request that an operation be performed by some object. can include actual parameters used to perform that operation receiver can return a value OO program is a community of objects that collaborate to solve a problem. This is achieved by sending messages to one another Can result in a return value Can result in an exception from receiver to sender Execution of an OO program typically begins with instantiation of some objects “start” sends a message to one of the objects the receiver sends messages to other objects or to itself to perform computations Event-driven environment – the environment repeatedly sends messages and waits for replies in response to external events such as mouse clicks, key presses, etc. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

18 Messages from a testing perspective
A message has a sender who determines when to send and may make an incorrect decision about this has a receiver may not be ready for the specific msg it receives may not take the correct action if msg is unexpected may include actual parameters used by or updated by the receiver objects passed as parameters must be in correct states before and after the message is processed implement the interfaces expected by the receiver January 20, 2002 ECEN OO Testing - University of Colorado

19 Those issues are the primary focus of interaction testing
January 20, 2002 ECEN OO Testing - University of Colorado

20 ECEN5033 - OO Testing - University of Colorado
Interface Aggregation of behavioral declarations Example: a set of behaviors related to being a moving item on a screen such as the ball in (the old game of) Pong Building block for specifications A specification is the total set of public behaviors for a class. Java: has a syntactic construct interface; doesn’t allow declaration of any state variables C++: declare an abstract base class with only public, pure virtual methods January 20, 2002 ECEN OO Testing - University of Colorado

21 Interfaces from a testing perspective
ECEN5033 Testing OO Software January 20, 2002 Interfaces from a testing perspective Interface encapsulates operation specifications which build the specifications of larger groupings such as classes If it contains behaviors that do not belong with the other behaviors, implementations of the interface will have unsatisfactory designs Interface has relationships with other interfaces and classes. may be specified as the parameter type for a behavior to allow any implementer of that interface to be passed as a parameter Interface describes a set of behavior declarations whether or not we use the interface syntax Controller pattern is an interface to the domain layer facade use case or session controller January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

22 ECEN5033 Testing OO Software
January 20, 2002 Class Set of objects that share a common conceptual basis. Class definition says what members (objects) of the set look like, what they have in common. Objects form the basic elements for executing OO programs Classes are the basic elements for defining OO programs Any concept to be represented in a program must first be defined in a class. Then objects defined by that class are created (instantiation) and are called instances object = instance Some refer to a class as a template for creating objects. This makes apparent the role of classes in writing OO programs. McGregor and Sykes prefer to think of a class as a set. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

23 ECEN5033 Testing OO Software
January 20, 2002 Class as object Note: OO languages usually allow a class to be an object itself and can have operations and attributes defined for it In C++ and Java, operations and data values associated with a class are identified by the keyword static and these operations are called static operations Public static operations in a class specification mean the class itself is an object that can be messaged we must treat the class as an object and create tests for the class as well as for its instances Scary thought: non-constant static data associated with a class can affect the behavior of the instances (yikes!) nonconstant static data ... an oxymoron January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

24 ECEN5033 - OO Testing - University of Colorado
ClassA SubClassA2 SubClassA1 January 20, 2002 ECEN OO Testing - University of Colorado

25 ECEN5033 Testing OO Software
January 20, 2002 Operations A class specification includes a specification for each of the operations that can be performed by each of its instances An operation is an action that can be applied to an object to obtain a certain effect. Accessor (inspector) operations – provide information about the object but do not change the object Modifier (mutator) operations – change the state of the object by setting one or more attributes to have new values (perhaps not every time) Accessors are tested differently than modifiers. If it provides information AND modifies, must be tested in both ways. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

26 Two special operations
Constructor – a class object operation used to create a new object includes initializing a new instance when it comes into existence Destructor – an instance object operation used to perform any processing needed just prior to the end of the object’s lifetime Differ from accessors & modifiers invoked implicitly as a result of the birth and death of objects January 20, 2002 ECEN OO Testing - University of Colorado

27 What do we expect of a class specification?
A description of what a class represents. It’s either a concept in the problem being solved or in the solution to that problem Some meaning and constraints to be associated with each of the operations defined in the class specification So ... each operation should have a specification that describes what it does, including its preconditions and invariants January 20, 2002 ECEN OO Testing - University of Colorado

28 ECEN5033 - OO Testing - University of Colorado
Reminder Preconditions Conditions that must hold before the operation can be performed. Post conditions Conditions that must hold after the operation is performed. Invariants Conditions that must always hold within the lifetime of the object An operation’s method may violate invariants during execution but it must “hold” again by completion. January 20, 2002 ECEN OO Testing - University of Colorado

29 ECEN5033 - OO Testing - University of Colorado
Preconditions Usually stated in terms of one or more of the following: attributes of the object containing the operation attributes of any actual parameters in the message requesting that an operation be performed January 20, 2002 ECEN OO Testing - University of Colorado

30 ECEN5033 - OO Testing - University of Colorado
Post conditions Usually stated in terms of one or more of the following: attributes of the object containing the operation attributes of any actual parameters in the message requesting that the operation be performed the value of any reply the exceptions that might be raised January 20, 2002 ECEN OO Testing - University of Colorado

31 ECEN5033 Testing OO Software
January 20, 2002 Invariants A class invariant describes a set of operating boundaries for an instance of a class It is possible to define interface invariants and operational invariants A class invariant can be treated as an implied post condition for EACH operation in the class Usually stated in terms of attributes of an object states of an object Makes no sense for class invariants to be stated in terms of the actual parameters of the message requesting an operation to be performed. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

32 Behavior of the instances of a class
The aggregate of the specifications of all of the operations in a class provides part of the description of the behavior of its instances Behavior difficult to infer from operation specifications alone typically designed and represented at a higher form of abstraction defining a set of states for an instance describing how various operations effect transitions from state to state January 20, 2002 ECEN OO Testing - University of Colorado

33 To write a specification for an operation
To define the interface between the receiver and the sender Contract approach – emphasizes preconditions but has simpler post conditions Defensive programming approach -- emphasizes post conditions but has simpler preconditions January 20, 2002 ECEN OO Testing - University of Colorado

34 Contract approach to class design from a testing perspective
ECEN5033 Testing OO Software January 20, 2002 Contract approach to class design from a testing perspective Preconditions specify obligation of the sender If met, receiver is obligated to meet the requirements set form in the post conditions and class invariant Care must be taken in the design of the class interface to ensure that the preconditions are sufficient to allow a receiver to meet the post conditions a sender can determine whether all preconditions are met before sending a message post conditions address all possible outcomes of an operation, assuming preconditions were met Sender determines preconditions are met before sending message probably by using accessor methods January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

35 Defensive approach to class design from a testing perspective
ECEN5033 Testing OO Software January 20, 2002 Defensive approach to class design from a testing perspective Interface defined primarily in terms of the receiver and any assumptions it makes on its own state and the values of any inputs (arguments or global data) at the time of the request. Operation typically returns some indication re status of the result of the request (success or failure), traditionally as a return code associating a value with each possible outcome can provide to sender an object that encapsulates the status of the request Identify “garbage in” and eliminate “garbage out” by checking for improper values coming in and reporting the status of processing the request to the sender Tends to increase complexity of software because each sender must follow a request for an operation with code to check the processing status for each possible outcome provide code to take an appropriate recovery action Takes increased time because receiver checks inputs on every call even though sender may have already checked them January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

36 What does this mean for tester?
ECEN5033 Testing OO Software January 20, 2002 What does this mean for tester? The approach used in an interface determines the types of testing that need to be done. Contract approach simplifies class testing complicates interaction testing – must ensure any sender meets the preconditions Defensive approach complicates class testing – test cases must address all possible outcomes complicates interaction testing – must ensure all possible outcomes are produced and that they are properly handled by the sender Still useful for debugging to include code to check preconditions – preferably with a compiler option so the checks can remain in the file but be removed before final testing Meyer – the originator of the concept in OO– provides means in Eiffel (his language) to make this code compiler switchable. Even he doesn’t fail to check during debugging. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

37 ECEN5033 - OO Testing - University of Colorado
During design and design inspections of a class – how maintain testing perspective? Review the preconditions and post conditions for testability Are the constraints clearly stated? Does the specification include the means by which one can check preconditions? (the sender does not want to be an expert on the receiver; receiver should explain how to check for the preconditions) January 20, 2002 ECEN OO Testing - University of Colorado

38 ECEN5033 Testing OO Software
Class implementation January 20, 2002 Describes how an object represents its attributes and carries out its operations. It is made of several components: A set of data values stored in data members (aka instance variables or variables) – some or all of the values associated with the attributes of an object. A set of methods (aka member functions) – code used to implement an algorithm to accomplish an operation declared in the public or private class specification. A set of constructors to initialize a new instance. A destructor to handle any processing associated with destruction of an instance A set of private operations in a private interface – provide support for the implementation of public operations. Not necessarily a 1-1 mapping of attributes to data values. Some attributes can be derived from others. Some redundant representation of derivable attributes is sometimes desirable in order to improve the performance. Some attributes identified for an object might not be represented at all because the attribute is not needed in an application. If we remove it, we reduce memory space needed to hold such an object. CODE typically uses or sets an object’s variables. It processes any actual parameter values. It checks for exception conditions. It computes a return value if one is specified for the operation. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

39 Importance of class testing
Classes define the building blocks for OO programs A class is an abstraction of the commonalities among its instances – therefore, the testing process must ensure that a representative sample of members are selected for testing. January 20, 2002 ECEN OO Testing - University of Colorado

40 Classes from a testing perspective
ECEN5033 Testing OO Software January 20, 2002 Classes from a testing perspective A class specification contains operations to construct instances. They may not properly initialize the attributes of new instances. Class relies on collaboration to define its behaviors and attributes. The other classes may be implemented incorrectly and contribute to failure of the class that relies on them. A class’ implementation “satisfies” its specification – does not mean the specification is correct. Might not support all required operations; may perform them incorrectly. Might not provide a way for a precondition to be checked by a sender before sending a message Bullet 3 Implementation may, for example, violate a higher requirement such as design criteria or may incorrectly model the underlying concept it represents. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

41 ECEN5033 - OO Testing - University of Colorado
Inheritance Relationship between classes that allows the definition of a new class based on the definition of an existing class. allows reuse of both specification & implementation important advantage: the preexisting class does not have to be modified or made aware of the new class New class is called subclass or derived class Parent class is called superclass or base class Each class (except the root) has one or more ancestors; the chain of ancestors up to the root is called inheritance hierarchy January 20, 2002 ECEN OO Testing - University of Colorado

42 Good OO Design Use of Inheritance
Used only to implement an is-a or is-a-kind-of relationship Best use: with respect to specifications and not implementation – inclusion polymorphism, for example (more on that in a moment) January 20, 2002 ECEN OO Testing - University of Colorado

43 Inheritance from a testing perspective
ECEN5033 Testing OO Software January 20, 2002 Inheritance from a testing perspective Provides a mechanism by which bugs can be propagated from a class to each of its descendants  Important reason to test classes as they are developed to eliminate fault propagation Provides a mechanism by which we can reuse test cases. subclass inherits part of its specification and implementation from its superclass, potentially can reuse test cases from superclass to subclass Models an is a kind of relationship Use of inheritance solely for code reuse will probably lead to maintenance difficulties Common mistake in OO development In inspections, check that inheritance is used properly. Proper use of inheritance in design leads to benefits in execution testing of classes (Chapter 7 in book) BULLET 3 explained on next slide January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

44 Inheritance models is-a-kind-of relationship
If D is a subclass of C, then D is a kind of C If so, an instance of D can be used whenever an instance of C is expected To work, the behavior of D must somehow conform to that which is associated with C Behavior of a class observable states of an instance the semantics associated with the operations defined for an instance of that class Behavior of a subclass – incremental changes to the observable states and operations defined by its superclass January 20, 2002 ECEN OO Testing - University of Colorado

45 Substitution Principle
ECEN5033 Testing OO Software January 20, 2002 Substitution Principle Only the following changes are allowed in defining the behavior associated with a new subclass: Preconditions for each operation must be the same or weaker – less constraining – than those of the superclass Post conditions for each operation must be the same or stronger – do at least as much as defined by the superclass Class invariant – must be the same or stronger; add more constraints Class invariant is an implied post condition for each operation. No wonder that in the behavior associated with a subclass, the subclass invariant must be the same or stronger than the class invariant. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

46 Substitution Principle of Inheritance from a testing perspective
Developers must enforce (in inspections, if not before) the constraints of this principle on behavior changes Observable states and all transitions between them associated with the superclass must be preserved by the subclass The subclass may add transitions between these states The subclass may add observable states as long as each is either concurrent or a substate of an existing state In other words, don’t use inheritance because you are too lazy to specify a class that is similar but is-not-a-kind-of January 20, 2002 ECEN OO Testing - University of Colorado

47 ECEN5033 Testing OO Software
January 20, 2002 Polymorphism Ability to treat an object as belonging to more than one type. Not necessarily the safest approach to programming Supports designs that are flexible Inclusion polymorphism is the occurrence of different forms in the same class Can substitute an object whose specification matches another object’s specification for the latter object in a request for an operation i.e., a sender can use an object as a parameter based on its implementation of an interface rather than its full class Some people call inclusion polymorphism dynamic binding. Dynamic binding is an association at runtime between the operation specified in a a message and a method to process the requested operation. However, dynamic binding is the mechanism by which inclusion polymorphism is implemented by various runtime environments. In C++, dynamic binding must be requested by the keyword virtual in a member function declaration. In Java, inclusion polymorphism is supported through inheritance between classes and an implementation relationship between interfaces and classes. A sender can manipulate objects with a reference declared for either a class or an interface. If a reference is associated with a class, then the reference can be bound to an instance of that class or any of its descendants. If a reference is associated with an interface, then the reference can be bound to an instance of any class that is declared to implement that interface. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

48 A class is a set of objects that share a common conceptual basis.
This definition is influenced primarily by associating inheritance and inclusion polymorphism The class at the root (top of tree graph) establishes a common conceptual basis for all objects in the set. A descendant refines the behavior established by the root class and intermediate ancestors Objects in the descendant class are still in the set of objects in the root class – a subset of each of the sets defined by its ancestors January 20, 2002 ECEN OO Testing - University of Colorado

49 ECEN5033 - OO Testing - University of Colorado
Two perspectives of sets representing classes – both are useful during testing Class’ perspective – each set contains all instances, maybe an infinite number; most easily represented with Venn diagrams Executing program’s perspective – each set is drawn with one element per instance in existence. January 20, 2002 ECEN OO Testing - University of Colorado

50 A Matter of Perspective
When a class is to be tested outside context of any application program, we test it by selecting arbitrary instances using the class perspective in context of an executing application program or in context of object persistence, we use the other perspective ensure size of set is correct ensure elements correspond to appropriate objects in the problem or solution January 20, 2002 ECEN OO Testing - University of Colorado

51 Inclusion polymorphism – powerful capability
Can perform all design and programming to interfaces without regard to exact class of the object sent to a message to perform an operation Takes design and programming to a higher level of abstraction Can define classes for which no instances exist but for which its subclasses have instances An abstract class’ purpose is to define an interface that is supported by all of its descendants Exploits polymorphism during design to extend a system incrementally by adding classes instead of modifying existing ones January 20, 2002 ECEN OO Testing - University of Colorado

52 Inclusion polymorphism from a testing perspective
ECEN5033 Testing OO Software Inclusion polymorphism from a testing perspective January 20, 2002 A polymorphic reference hides the actual class of a referent (referent is the thing being referred to). All referents are manipulated through their common interface. Allows systems to be extended by adding classes rather than modifying existing ones – unanticipated interactions can occur in the extensions Allows any operation to have 1 or more parameters of a polymorphic reference – increases the number of possible kinds of actual parameters that should be tested Allows operation to specify replies that are polymorphic references – actual class of referent could be unanticipated by the sender C++ and Java provide support for determining the actual class of a referent at runtime. Good OO design requires such runtime type inspections be held to a minimum because they create a maintenance point since the extension of a class hierarchy introduces more types to be inspected. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

53 Impact of this dynamic nature of OO
Puts more importance on testing a representative sample of runtime configurations Static analyses provide potential interactions that might occur Only runtime configuration illustrates what actually happens In the McGregor & Sykes book, they explain a statistical technique to assist in determining which configurations will expose the most faults for the least cost of resources January 20, 2002 ECEN OO Testing - University of Colorado

54 Each subclass must be a subtype
ECEN5033 Testing OO Software Each subclass must be a subtype January 20, 2002 That is, each specification for the subclass must fully meet all specifications of its direct ancestor This is an enforceable design requirement when these rules are applied (refers to diagram on next slide): The tryit method in A, the sender, satisfies the preconditions of the doIt operation of B before tryit calls doIt. If an instance of C or D is to be substituted, the preconditions for C’s doIt or D’s doIt must not add any new conditions to those for B’s doIt. (Why?) If an instance of C or D is to be substituted when A’s tryit sends a message to B’s doIt, the post conditions on B’s doIt must still be true although C or D can add additional post conditions. Similarly for the invariant for B – must still be true in instances of C and D although additional invariants may be added. C or D’s preconditions on doIt must not add any new conditions to those for B’s because we would have to modify A to accommodate C and D If A does not know that B may substitute C or D’s doIt, then A may not take advantage of the additional post conditions, if any. A can take advantage of the invariant post condition for B but will not be able to take advantage of any additional invariants associated with C or D. January 20, 2002 ECEN OO Testing - University of Colorado University of Colorado

55 Design solution with inclusion polymorphism
A B tryit(B b) doIt( ) {...} tryit(B b) { b.doIt( );} C D doIt( ) {...} doIt( ) {...} January 20, 2002 ECEN OO Testing - University of Colorado

56 Parametric Polymorphism
The capability to define a type in terms of one or more parameters – rather like a macro C++ provides this with the concept of templates a compile-time ability to instantiate a “new” class “new” because an actual parameter is provided for the formal parameter (at compile-time) in the definition Instances of the new class can then also be created Used a lot in the C++ Standard Template Library Almost looks like a kind of inheritance but it isn’t If the template works for one instantiation, no guarantee it will work for another January 20, 2002 ECEN OO Testing - University of Colorado

57 Parametric Polymorphism from a testing perspective
Need to inspect details of the template code to understand what it will do with various parameters It is possible to write templated drivers for testing many parts of templates January 20, 2002 ECEN OO Testing - University of Colorado

58 ECEN5033 - OO Testing - University of Colorado
Abstraction The process of removing detail from a representation. Allows us to look at a problem in various levels of detail. leave out details that are irrelevant for a given consideration OO technologies use abstraction extensively inheritance hierarchy, for example system models whose detail increases during development January 20, 2002 ECEN OO Testing - University of Colorado

59 Layers of abstraction from a testing perspective
Layers of abstraction in the development process are paralleled by layers of testing analysis If we begin testing analysis with the highest levels of abstraction of development models, we provide a more thorough examination of the development product and, therefore, a more effective and accurate set of tests January 20, 2002 ECEN OO Testing - University of Colorado


Download ppt "Software Engineering of Standalone Programs University of Colorado"

Similar presentations


Ads by Google