do contexto de execução, introdução de inputs, registo e análise de outputs,...). Para o processo funcionar é ainda necessário que o SUT ofereça mecanismos de controlo e observação do sistema (potencialmente por meio de uma API) de forma a se poder verificar se o sistema se comporta segundo o que é expectável em cada um dos esta- dos. Da conjunção de toda esta caracterização remanesce o problema da manutenção, já que os scripts devem estar de acordo, quer com os requisitos, quer com os detalhes de implementação, por via de utilização de uma API.
Como previamente referido, a lógica para a resolução dos problemas enunciados centra-se na elevação da abstracção dos casos de teste e na automatização dos seus di- versos estádios. É neste sentido, de acordo com [25], que foram desenvolvidos outros tipos de processos, tais como o teste conduzido pelos dados, por tabelas, por acções e/ou por palavras-chave, que por essência procuram reduzir a questão da manuten- ção de cariz eminentemente humano. Mais se acrescenta que para estes, o objectivo é abstrair, tanto quanto possível, os casos de teste até um nível em que possam ainda ser interpretados por uma ferramenta de execução. Na prática, e não pretendendo a exaustão do assunto (já que não é peremptório para esta dissertação), o que é feito nos processos conduzidos por palavras/acções/... é definir alguns símbolos (termos, palavras-chave) que correspondam a fragmentos de scripts e que possam ser conver- tidos por meio automático (dito de adaptador), em testes executáveis. Pode concluir- se, portanto, que este último tipo de processo situa os casos de teste num patamar mais alto de elevação, reduzindo a maior parte dos problemas de manutenção. Não obstante, mantém o problema da manualidade da geração de dados para teste, dos oráculos e da verificação de cobertura dos requisitos de teste.
É na sequência da tentativa de resolução dos problemas enunciados que surge o processo de Teste baseado em Modelos, sendo que, em particular, com este é esperada a automatização do desenho de casos de teste funcionais (inclui predição dos outputs) de forma a que se veja reduzido o custo de desenho e que se produzam conjuntos de teste que cubram efectivamente o modelo. Pretende-se ainda com este processo a redução de custos de manutenção e a geração automática da matriz de confrontação entre requisitos e casos de teste, dita de matriz de rastreabilidade.
2.5
O processo de teste baseado em modelos
O processo de Teste Baseado em Modelos introduzido anteriormente, supre a criação manual dos casos de teste através da introdução de uma etapa em que o test designer cria um modelo abstracto do SUT. Obtendo-se um modelo é possível não só extrair casos de teste a partir do modelo de modo automático, como também fazer essa ex-
2. ESTADO DA ARTE 2.5. O processo de teste baseado em modelos
tracção de diversas formas consoante a definição de diferentes critérios de selecção, contribuindo para a redução efectiva do tempo de criação de testes [25].
Requirements
Test Execution Tool
Test Plan Test Results System under Test Model Test Cases Test Case Generator Test Script Generator Test Script Adaptor Requirements Traceability Matrix Model Coverage 5. Analyse 3. Concretize 2. Generate 1. Model 4. Execute
Figura 2.5: Processo de Teste baseado em Modelos
Atentando-se na figura 2.5, ressaltam cinco etapas principais: duas que distinguem este processo dos restantes (criação de um modelo do SUT e geração de testes abstrac- tos a partir do modelo), a transformação dos testes abstractos em testes executáveis, e por fim as que são comuns a qualquer processo já enunciado (execução dos testes e obtenção e classificação de outputs, e análise de resultados).
Em abono da boa compreensão de cada uma das etapas supracitadas, é fundamen- tal perceber no que consiste cada uma delas. Procedendo a uma análise detalhada fica claro que na primeira etapa é desenvolvido um modelo abstracto do sistema, assim intitulado por se se pretender conciso, abstraído dos detalhes e consequentemente de tamanho reduzido em relação ao tamanho do sistema; deve ainda permitir a identifica- ção directa das relações entre o modelo e os requisitos. Por outro lado é importante que
2. ESTADO DA ARTE 2.5. O processo de teste baseado em modelos
o modelo seja implementado em ferramentas que permitam a sua validação/verifica- ção automática através de mecanismos embutidos (verificação de conformidade entre modelo e metamodelo), sendo que em particular, no contexto da presente dissertação, a ferramenta em desenvolvimento recorre-se da plataforma de modelação do Eclipse (EMF-Eclipse Modelling Framework [8]) que possui os mecanismos para esse efeito.
Na segunda etapa - a geração de testes abstractos - o objectivo primordial é a ob- tenção de um conjunto de testes abstractos através da definição de alguns critérios de selecção que permitam guiar a escolha dos mesmos. Em geral, existe uma infinidade de testes passíveis de ser seleccionados e, não sendo possível a geração de todos, têm de ser indicadas explicitamente quais as partes do modelo que devem ser testadas com o fim de restringir a geração. Os critérios podem ser expressos directamente no software de teste em questão através de opções disponibilizadas ou, por outro lado, pode ser especificado através de uma linguagem de especificação de testes. Esta última opção é a que mais se coaduna com esta dissertação, já que na ferramenta em desenvolvimento os testes são especificados através de uma linguagem de definição de intenções de teste (SATEL), que será abordada posteriormente em capítulo próprio.
A terceira etapa tem como objectivo a transformação dos testes abstractos em testes executáveis directamente sobre o SUT. Este objectivo é concretizável por exemplo atra- vés da utilização de ferramentas de transformação que usam templates e/ou mapas de relações com o fim de traduzir cada teste abstracto num teste/script executável. A quarta etapa consiste simplesmente na execução efectiva dos testes sobre o SUT. Na realidade esta etapa pode estar fundida na segunda etapa - geração de testes abstrac- tos - no caso em que todo o processo é feito de forma imediata como um todo. Nesta situação, assim que o teste é produzido, a ferramenta deve executá-lo e recolher a infor- mação de resultados. Dito de outro modo, desta forma as etapas são sucessivamente dependentes e são obrigatoriamente realizadas nos mesmos instantes, em oposição ao teste off-line, em que as etapas, embora dependentes entre si, permitem -se à execução em instantes temporais distintos.
Por fim a quinta etapa confina-se à análise dos resultados obtidos com as execuções e à correcção das causas das respectivas falhas. Sendo um processo baseado em MBT, as causas podem situar-se quer ao nível do modelo, quer ao nível do adaptador (soft- ware responsável por mapear os testes abstractos em executáveis), como também ao nível dos documentos de especificação de requisitos.
Das etapas acima, apenas a primeira e a segunda têm relevância na presente disser- tação, já que apenas há interesse na geração de testes abstractos e do oráculo a partir de um modelo, não se tendo o objectivo de concretizar os testes abstractos em testes executáveis sobre o SUT.