built-in contract testing
DESCRIPTION
Built-In Contract Testing. João dos Prazeres. Motivação. Novo desafio na Engenharia de Software: Reuso Componentes é uma abordagem para facilitar reuso Mas há o problema de integração dos componentes Built-In Contract Testing: Testes embutidos nos componentes clientes e servidores - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/1.jpg)
Built-In Contract Testing
João dos Prazeres
![Page 2: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/2.jpg)
Motivação
• Novo desafio na Engenharia de Software: Reuso
• Componentes é uma abordagem para facilitar reuso
• Mas há o problema de integração dos componentes
• Built-In Contract Testing:
– Testes embutidos nos componentes clientes e servidores
– Testam os contratos entre os componentes
![Page 3: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/3.jpg)
BICT
• Testing Profile aborda apenas black-box conformance test
• SUT (system under test) só interfaces funcionais
• BICT requer interfaces que mostre o estado interno.
![Page 4: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/4.jpg)
• Baseado nas relações cliente/servidor aplicada ao nível de componentes.
• O componente cliente contém um sub-componente testador
• Testa as interfaces do servidor antes que a interação entre eles se inicie.
Artefatos de BICTServer Tester
![Page 5: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/5.jpg)
Artefatos de BICT
Context
<<component>>Client
<<component>>Server
<<acquires>>
<<creates>>
<<component>>Server Tester
<<acquires>>
Context
<<component>>Client
<<component>>Server
<<acquires>>
<<creates>>
Server Tester
![Page 6: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/6.jpg)
• Server Tester (subcomponente do cliente) se utiliza da interface Server, que passa a se chamar Testable Server.
• Esta abordagem também é utilizada para modelar BICT a componentes de terceiros.
Artefatos de BICTServer Tester – 1 abordagem
<<component>>Testable ServerPublic interface
<<component>>Testing Client
Server Tester
![Page 7: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/7.jpg)
• O Testable Server (antigo Server Component) disponibiliza um conjunto de interfaces que expõe seus estados internos para facilitar testes – Testing Interfaces
Artefatos de BICTServer Tester – 2 abordagem
<<component>>Testable ServerPublic
interface
Testing interface
<<component>>Testing Client
Server Tester
![Page 8: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/8.jpg)
• Há três maneiras para a implementação das interfaces de teste:
1. A primeira trata de implementa-la criando vários métodos para determinar e verificar cada estado.
2. A segunda, cria atributos para cada estado, e cria apenas dois métodos genéricos para determinar e verificar o estado, passando-o como parâmetro.
3. A terceira abordagem cria um componente que herda do componente a ser testado, e neste utiliza a segunda abordagem.
Artefatos de BICTServer Tester
![Page 9: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/9.jpg)
• Testing Interface – Formas de Implementar Testing Interfaces
Artefatos de BICT
<<component>>Testable ServerPublic
interface
Testing interface
![Page 10: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/10.jpg)
Perguntas?!?
![Page 11: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/11.jpg)
Transparências
Complementares
![Page 12: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/12.jpg)
SPEM – Software Process Engineering MetaModel
• A modelagem é feita através do uso de estereótipos• Os principais estereótipos definidos pelo SPEM são:
– WorkProduct– WorkDefinition– ProcessPerformer– ProcessRole– ProcessPackage– Phase– Process– Document– UMLModel– Activity– Guidance
![Page 13: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/13.jpg)
SPEM – Software Process Engineering MetaModel
• WorkProduct: classe de produto de trabalho produzido em um processo e está associado a um tipo de produto. Ex: documento, código fonte, etc. Artefato
• Notação:
• WorkDefinition: é um tipo de operação que descreve o trabalho realizado no processo. É a representação para atividades compostas por outras sub-atividades.
• Notação:
![Page 14: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/14.jpg)
SPEM – Software Process Engineering MetaModel
• ProcessPerformer: define o “realizador” de um conjunto de WorkDefinitions do processo.
• Notação:
• ProcessRole: define responsabilidades em relação a WorkProducts específicos e define papéis que realizam e auxiliam atividades específicas.
• Notação:
![Page 15: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/15.jpg)
SPEM – Software Process Engineering MetaModel
• ProcessPackage: notação especial para pacotes no contexto SPEM
• Notação:
• Phase: é uma especialização de um WorkDefinition em que sua pré-condição define a fase de critérios de entrada e seus objetivos definem a fase de critérios de saída
• Notação:
![Page 16: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/16.jpg)
SPEM – Software Process Engineering MetaModel
• Process: representa um processo completo, em toda
sua extensão.
• Notação:
• Document: notação específica para diferentes tipos de WorkProducts
• Notação:
![Page 17: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/17.jpg)
SPEM – Software Process Engineering MetaModel
• UMLModel: notação específica para diferentes tipos de WorkProducts
• Notação:
• Activity: descreve uma parte do trabalho realizado por um ProcessRole: suas tarefas, operações e ações executadas por um papel ou de que forma o papel deve auxiliar
• Notação:
![Page 18: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/18.jpg)
SPEM – Software Process Engineering MetaModel
• Guidance: Informação mais detalhada sobre o elemento associado fornecida aos praticantes Ex:Guidelines, Metrics, Tools, Checklists e Templates.
• Notação:
![Page 19: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/19.jpg)
Unified ProcessOPEN
«uses»
KobrA
PuLSE
«uses»
Catalysis
Cleanroom
SELECT Perspective
«uses»
BICT
«uses»«extends»
«uses»«uses»
BICT Reuse
![Page 20: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/20.jpg)
Step 1 - Identification of Tested Interactions
Identify removable built in testing
Identify pernament built in testing
Identify client-servership interaction
Identified associations in component diagram
Software engineerComponent diagram
[updated]
Este passo trata de analisar se os elementos de BICT devem ficar permanentes num contexto ou se devem ser removidos após a integração dos componentes e como identificar as interações testáveis.
![Page 21: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/21.jpg)
Step 2 – Definition and Modeling of the Testing Architecture
Software engineer
Component Diagram
Add Tester Components
Component diagram with new associations
Provide Testing Interface in the servers
Testing Component Architecture
Component diagram with Testable Komponents
Replace Server by Testable Komponents
Este passo é a explicitação de como estender o modelo do sistema para considerar elementos do modelo de contract testing. Os elementos do modelo que pertencem a testes devem ser indicados com o estereótipo <<Testing ...>>.
![Page 22: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/22.jpg)
Step 3 – Specification of the Testing Interfaces for the identified
associations
Software engineer[no more operations to be
specified]
[has operation to be specified]
Specify functional specification of the
operation
Operation funcional especificationFusion method template Component diagram
[updated]
Add setting and checking state operations to
Testable Komponent
Testable Komponent protocol state machine
diagram
Create Testable Komponent behavioral
model
Como entrada é necessário uma especificação funcional completa das operações do servidor (como previsto no método Kobra). A especificação funcional é informação suficiente para definir as operações de verificação e determinação do estado do componente, as quais constituem as interfaces de teste.
![Page 23: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/23.jpg)
Step 4 – Realization of the Testing Interfaces
Software engineer
Realize Testable Komponent
Testable Komponent class diagram with OCL
Testable Komponent communication diagram
Testable Komponent activity diagram
Este passo trata da realização da interface de testes para o papel servidor de uma associação. A realização das interfaces de teste dependem diretamente da realização do componente servidor a qual ela pertence.
![Page 24: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/24.jpg)
Step 5 – Tester Component Specification
Software engineer
Define Quality Assurance Plan
Test case selection techniques
Select test case tequiniques
Test cases
Quality assurance plan
Quality Engineer
Specify Tester Komponent
Komponent protocol state machine diagram
Tester Komponent component diagram
Testable Komponent realization model
Os componentes testadores são identificados e desenvolvidos na especicificação do componente cliente (Testing Component). Os casos de teste são derivados de acordo com a realização do modelo comportamental do componente cliente que o contém.
![Page 25: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/25.jpg)
Step 6 – Realization of the Tester Component
Software engineerRealize Tester Komponent
Test cases
Source code
{OR}
Tester Komponent class diagram with OCL
Tester Komponent communication diagram
Tester Komponent activity diagram
A realização de um componente testador está relacionado a como um o componente será organizado e implementado e que testes ele conterá. Eles podem conter sub-componentes testadores ou que auxiliam nos testes.
![Page 26: Built-In Contract Testing](https://reader036.vdocuments.us/reader036/viewer/2022062315/56815186550346895dbfbeeb/html5/thumbnails/26.jpg)
Step 7 – Integration of the Components
Software engineer
Define client wrapper
Define server wrapper
Create adaptor
or
or
Implement client wrapper
Implement server wrapper Running System
Este passo trata de definir adaptadores ou wrapers entre os clientes e servidores que já possuem artefatos de BICT. Trata também da criação de stubs para a execução de testes. Tais stubs, seguindo os conceitos de Testing Profile, teriam o estereótipo <<Test Component>>.