Software Testing and Quality Assurance Lecture 18 - Test Analysis & Design Models (Chapter 4, A Practical Guide to Testing Object-Oriented Software)

Lecture Outline Testing Specific Types of Models

Testing specific types of models: requirements model Acceptance testing often finds faults that result from problems with the requirements (missing requirements, contradiction in requirements). There is no UML model on which the requirements are based, so comparison to the basis model refer to documents produced by marketing, system engineering or client organization.

Testing specific types of models: requirements model (cont...) Outline of testing the requirements models: Develop the ranking of use cases by computing combined frequency and criticality information for a use case. Determine the total number of test cases that can be constructed given the amount of resources available.

Testing specific types of models: requirements model (cont...) Ration the tests based on the ranking Write scenarios based only on the knowledge of those in the domain expert’s role Check for completeness, consistency, and correctness

Testing specific types of models: requirements model example (cont...) Use Frequency Criticality Combined value Rank Number of test cases Start Brickles Medium High 1 3 Pause Brickles Low Stop Brickles 2 Break brick Wins Loses

Testing specific types of models: requirements model (cont...) Criteria for requirement inspection: Any system functionality is specified in the same manner everywhere it is described. Consistency Each use case accurately represents a requirement. Correctness The use cases represent all of the functionality needed for a satisfactory product. No use case is needed that is not required functionality. Completeness Interpretation for domain modeling Criteria

Testing specific types of models: analysis models Domain analysis model Application analysis model A domain model is a representation of the knowledge in a domain as seen through the eyes of a set of domain experts.

Testing specific types of models: analysis models— domain analysis model Two groups are formed: Group one: developers group ―creates the domain model Group two: testers and domain expert group ―serves as testers of that model. (this group creates the test cases of the model).

Interpretation for domain modeling Testing specific types of models: analysis models— domain analysis model (cont...) Criteria for domain analysis model inspection Model elements should be consistent with company’s definitions and meanings Consistency The description of domain concepts are accurate; the algorithms will produce the expected results Correctness The concepts are sufficient to cover the scope of the content specified. Sufficient detail is given to describe concepts to the required path. Completeness Interpretation for domain modeling Criteria

Testing specific types of models: analysis models— application analysis model Multiple domain models contribute to the single application analysis model. Criteria for application analysis model inspection.

Interpretation for domain modeling Testing specific types of models: analysis models— application analysis model Where there are multiple ways to represent a concept of action, those ways are equivalent Consistency Experts agree with the attributes and behaviors assigned to each concept; on the steps in each algorithm; major states for each conceptual entity. Correctness The ideas expressed in each use case can be represented by the concepts and algorithms in the model. No design information is included in the model. Completeness Interpretation for domain modeling Criteria

Testing specific types of models: design models Architectural design model: provided the basic structure of the application by defining how a set of interfaces are related. Detailed class design model: provides the precise semantics of each class and identifies the architectural interface to which the class corresponds.

Testing specific types of models: design models— architectural model The architectural model is the skeleton of the entire application. Non-functional requirements are blended with functional requirements. A software architectural model is the basic structure that defines the system in terms of computational components and interactions among those components.

Testing specific types of models: design models— architectural model (cont...) Representations of the architecture: To represent an architecture: Relationships States Algorithms Tool support: Rational Rose performs a variety of consistency checks on the static-relationship model.

Testing specific types of models: design models— architectural model (cont...) Consistency checks will prevent certain types of connection from being established. However, it is not sufficient for determining whether the functionality is correctly implemented Architecture description languages provide the capability to represent a system at a high level of abstraction (e.g. Rapide)

Testing specific types of models: design models— architectural model (cont...) Testing the architecture: The Software Architecture Testing (SAT) technique is a special type of guided inspection that requires the following steps: Test cases are constructed. The tests are conducted on the product The results of the test are evaluated for correctness.

Testing specific types of models: design models— architectural model (cont...) Constructing test cases: Test cases are constructed from the use cases. The test cases for the architecture are defined at a higher level than more detailed design models.

Interpretation for the architectural design model Testing specific types of models: design models— architectural model (cont...) Criteria for the architectural design model inspection: Each use of the system can be handled only in one set of interfaces. Consistency The architecture satisfies its constraints; uses the appropriate architecture patterns; represents the interactions between interfaces. Correctness A sufficient set of interfaces are defined to provide all of the services needed for the application’s functionality. The relationship between the interfaces allows for the flow of control and data necessary to realize all of the uses described in the use case diagram. Completeness Interpretation for the architectural design model Criteria

Testing specific types of models: design models— architectural model (cont...) Test execution: Test cases are executed by constructing a message-sequence diagram. The diagram reflects preconditions for a test case.

Testing specific types of models: design models— architectural model (cont...) Verification of results: When the output from the test is in the form of diagrams, the resulting diagrams must be verified after each test execution by domain experts. When the output is the result of an execution, the test result can be verified by having those domain experts construct event sequences that would be produced by an architecture that performs correctly.

Key points Testing the requirements models: Develop the ranking of use cases by computing combined frequency and criticality information for a use case. Determine the total number of test cases that can be constructed given the amount of resources available. Ration the tests based on the ranking Write scenarios based only on the knowledge of those in the domain expert’s role Check for completeness, consistency, and correctness

Key points A domain model is a representation of the knowledge in a domain as seen through the eyes of a set of domain experts. Multiple domain models contribute to the single application analysis model. Design models Architectural design model Detailed class design model

Announcement Quiz # 3 Saturday November 22, 2008