Software Testing and Quality Assurance Testing Interactions

Click here to load reader

  • date post

    19-Jan-2016
  • Category

    Documents

  • view

    223
  • download

    1

Embed Size (px)

Transcript of Software Testing and Quality Assurance Testing Interactions

  • Software Testing and Quality AssuranceTesting Interactions

  • Reading AssignmentJohn McGregor and David A. Sykes, A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001, ISBN: 0-201-325640.Chapter 6: Testing Interactions

  • ObjectivesTo understand different types of interactions.Learn techniques on how to select test cases to run.

  • Topics coveredIntroductionObject interactionsTesting object interactionsSampling test casesTesting off-the-shelf componentsProtocol testingTest patternsTesting exceptions

  • Object InteractionsAn instance of a trusted primitive class, for example, may contain no faults, but if the services of that instance are not used correctly by other program components, then the program contains faults. Thus the correct collaborationor interactionof objects in a program is critical to the correctness of the program.

  • IntroductionObject-oriented program comprises a collection of objects that collaborate to solve some problem.Most classes have collaborators:The methods in the class interact with instances of other classes.The interactions being tested are between objects at runtime.The focus of interaction testing is ensuring that messaging occurs correctly with objects whose classes have already been tested separately.

  • Object interactionsAn object interaction is simply a request by one object (the sender) to another (the receiver) to perform one of the receivers operations and all of the processing performed by the receiver to complete the request.Object interactions include:Messages between an object and its componentsMessages between an object and other objects with which it is associated.We want to consider the impact of these interactions both on the internal state of the receiving object and on those objects with which it has an association

  • Partial Class TestingPartial class testing is a result of the iterative, incremental development approach.In general, It is not possible to sequence the development of a class so that all the classes it needs to interact with are totally developed and tested.

    A project's schedule is usually based on delivery of end-user functionality (use cases).

  • Partial Class Testing (cont.)Lower level Primitive classes are more likely to be completely developed at one time and tested as a complete unit.

    Other classes are therefore developed and tested incrementally.

  • Object Interactions: Identifying Interactions A primitive class is one that can be used without any collaboration with other objects.

    A nonprimitive class is one that requires collaboration with other objects in order to accomplish its objectives.

  • Object Interactions: Identifying Interactions (cont...)Possible collaborations:Parameter: public operation collaborates with an object passed in as an argument (formal parameter).Return: public operation returns an object with which it collaborates.Internal: a method of a class creates an instance of another as part of its implementation.Global: reference to a global instance of some class (undesired).

  • Object Interactions: Identifying Interactions (cont...)Categories of nonprimitive classes based on degree of interaction:

    Collection classes: maintain references to instances of other classes, but do not interact with those instances.

    Collaborating classes: interacts directly with its associated classes classes that are not collection classes.

  • Object Interactions: Identifying Interactions Collection ClassesCollection classes: Use objects in their specifications but never actually collaborate with any of them.

    Instead they do one of the following:Store referencesCreate instancesDelete instances

    Examples: lists, stacks, and queues.

  • Object Interactions: Identifying Interactions Collaborating Classes Collaborating ClassesNon-primitive classes that are not collection classes.They are classes that use other objects in one or more operations as part of their implementation.When a post condition of an operation in a class's interface refers to the state of an instance of an object and/or specifies that some attribute of that object is used or modified, then that class is a collaborating class.

  • Object Interactions: Identifying Interactions Collaborating Classes (cont...)The number of potential collaborations can become impossibly large quickly .

    Often the bugs that are most serious do not arise from the interaction of two objects, but from the interactions between a complete set of objects.

  • Object Interactions: Identifying Interactions Collaborating Classes (cont...)Factors that determine the size for testing:Composition and association:The interaction of the composing object with its composed attributes is tested.

    The interaction between an object and its associated objects are tested as successive layers of aggregation are integrated.

    The number of layers of aggregations created between interaction tests is closely related to the visibility of defects.

  • Object Interactions: Identifying Interactions Collaborating Classes (cont...)Object complexity: the more complex the objects, the fewer that should be integrated prior to a round of testing.

    number of parameters for each method, number of methods, number of attributes in each object.

    Trying to test a chunk that is too complex often results in defects that successfully hide from the tests.

  • Testing Object Interactions: Testing Collection ClassesCollection classes are tested using techniques for primitive classes: A test driver will create instances that are passed as parameters in messages to a collection being tested.

    Test cases center around ensuring that those instances are correctly incorporated into and removed from the collection class

    If defensive design has been used then include negative test cases in the test suite.

  • Specifying Interactions Assume that operations defined by a class are specified by preconditions, post conditions, and class invariants. It is important to know whether defensive design or design by contract has been used in creating the specification of the particular interface to be tested.

  • Specifying Interactions (Cont.)Defensive design assumes that little or no checking of parameter boundaries occurs prior to a message being sent. reduces the number of clauses in preconditions, requires checks internally for violations of attribute constraints, increases the number of clauses in post conditions.

  • Specifying Interactions (Cont.)Design by contract assumes that appropriate preconditions are checked prior to a message being sent and that the message is not sent if any of the parameters are outside acceptable limits. increases the number of clauses in preconditions, requires no checking internally for violations of attribute constraints, and reduces the number of clauses in the post condition clause.

  • Testing Object Interactions: Testing Collaborator ClassesThe complexity of testing a collaborating class is greater than that of testing a collection class or a primitive class.For a collaborator class under test:Identify the collaborating classesDetermine the sequence of testingCollaborating classes, Next level of collaborationThen the next level of collaboration and so on

  • The Interaction between Testing and Design Approach Contract design places more responsibility on the human designer than on error-checking code. This reduces the amount of class-level testing since there are fewer paths due to a smaller amount of error-checking code. At the interaction level, there is more testing required in order to be certain that the human designer has complied with the client side of the contract using precondition constraints.A focus of interaction testing is whether the preconditions of methods in a receiving object are being met by the sending object.

  • The Interaction between Testing and Design Approach (Cont.)It is not legitimate to build test cases that violate these preconditions. The intention is to determine that the sending object checks the preconditions of the receiving object before sending the message inappropriately. The test should also check whether the sending object aborts correctly, probably by throwing an appropriate exception.

  • Sampling Test CasesWhen the number of test cases is too large to handle reasonably

    A systematic technique is needed for determining which ones to use.

    We are interested with a testing approach in which the level of coverage can be increased systematically.

  • Sampling Test CasesPopulation: all possible test cases that can be executed. It includes all preconditions and all possible combinations of input values.A sample is a subset of a population that has been selected based on some probability distribution.Possibilities for determining which test cases to selectBased on probability distributionA probability distribution defines, for each data value in a population, a set of allowable values and the probability that value will be selected.

    Uniform probability distributionEach value in the population is assigned the same selection probability

  • Sampling Test Cases (cont...)A stratified sample is a set of samples in which each sample represents a specific subpopulationStratified sample tests are selected from a series of categories.A population of tests is divided into subsets so that a subset contains all of the tests that exercise a specific component. Sampling occurs on each subset independent of the others Example: select a sample of test cases from the use cases of each actor

  • Sampling Test Cases (cont...)Stratifying the test case samples by ea