UNIVERSIDADE DO VALE DO RIO DOS SINOS

UNIDADE ACADÊMICA DE GRADUAÇÃO

CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

PABLO DA SILVA KLEIM

THANOS:
Um processo para geração automática de testes a partir de Histórias de Usuário
utilizando PLN

SÃO LEOPOLDO
2022
 Pablo Da Silva Kleim

THANOS:
Um processo para geração automática de testes a partir de Histórias de Usuário
utilizando PLN

Artigo apresentado como requisito parcial para

obtenção do título de Bacharel em Ciência da
Computação, pelo Curso de Ciência da Compu-
tação da Universidade do Vale do Rio dos Sinos
(UNISINOS)

Orientador(a): Dr. Leandro Teodoro Costa

SÃO LEOPOLDO
2022
 1

THANOS Um processo para geração automática de testes a partir de Histórias de

Usuário utilizando PLN

Pablo Da Silva Kleim1

Leandro Teodoro Costa2

Resumo: A etapa de testes de software busca garantir que os requisitos definidos sejam aten-
didos pelo produto que será entregue, reduzindo o retrabalho, aumentando a qualidade dos
produtos e acrescentando grande valor nas entregas. Com objetivo de identificar oportunidades
de melhorias nessa etapa, foi realizado um estudo da arte cujo foco inicial foi analisar diver-
sos trabalhos e abordagens para geração de testes automatizados. A partir desta análise, foi
possível evidenciar diversas lacunas, tais como, o alto custo para gerar e manter códigos de
teste automatizado. Com o objetivo de mitigar estes problemas, neste trabalho, é apresentado
o processo thanoS, o qual provê a geração automática de códigos de teste para APIs backend
utilizando técnicas de Processamento de Linguagem Natural, a partir de requisitos descritos em
Histórias de Usuário. Com base neste processo, foi desenvolvido um protótipo de ferramenta
chamado thanoS Tool, o qual implementa as etapas do processo thanoS. Por fim, com o obje-
tivo de avaliar a aplicabilidade do processo thanoS e seu protótipo, foi realizada uma análise
quantitativa em que foram comparados os tempos de geração de códigos de teste utilizando a
abordagem manual e automatizada com o thanoS Tool. A partir desta análise, foi evidenciado
que o thanoS Tool se demonstrou mais eficiente, gerando os códigos de teste em um tempo
consideravelmente menor, se comparado com a abordagem manual.

Palavras-chave: Processamento de Linguagem Natural. Teste de Software. Metodologia Ágil.

Teste Automatizado. Rest Assured. Gherkin. IA.

1 INTRODUÇÃO

A etapa de teste de software tem como objetivo identificar e validar os cenários criados na
implementação de um sistema, a fim de encontrar possíveis erros e verificar se o seu funciona-
mento está de acordo com os requisitos solicitados. Portanto, a etapa de teste é imprescindível
para garantir a qualidade das entregas, entretanto, quando os testes são realizados de forma
manual, essa etapa se torna repetitiva e propensa a falhas humanas.
Considerando estas limitações, os testes manuais começaram a ser substituídos, no fluxo
de desenvolvimento, por testes automatizados. Desta forma, o advento da automação de testes
possibilitou maior controle dos cenários cobertos e proporcionou o reuso dos testes.

1.1 Problema

Embora a adoção da prática de testes automatizados apresente diversos benéficos, há o ônus

de custo e tempo para o desenvolvimento e manutenibilidade dos testes automatizados (SAL-
1
Graduando em de Ciência da Computação pela Unisinos. Email: pablo.190777@gmail.com
2
Doutor em Ciência da Computação pela PUCRS. Email: lteodoroc@unisinos.br
 2

MAN, 2020). Além disso, a migração do processo manual para automatizado exige que os
profissionais da área sejam treinados no desenvolvimento dos testes.
Também é importante destacar que, no mercado atual, muitos dos profissionais que exer-
ciam a função de executar testes manuais, têm apresentado dificuldades em se adaptar para o
formato de desenvolvimento dos testes automatizados, e mesmo os que possuem o conheci-
mento necessário, concordam que é um processo com custo elevado, mas que ainda acrescenta
grande valor para a qualidade final do produto (CARDEAL; PARREIRA, 2015).
Além disso, existe o agravante de que, é necessário utilizar diferentes tecnologias de teste
para validar as diversas partes do sistema, ou seja, para testar o frontend e o backend de uma
mesma aplicação são utilizadas tecnologias de teste distintas. Desta forma, o profissional de
teste acaba necessitando se capacitar em diversas tecnologias para validar todo o sistema.
Atualmente, existem diversos trabalhos (citar uns 3 trabalhos) que apresentam abordagens
de automação de testes. No entanto, nenhum deles propõe soluções de automação de teste
backend, a partir de Histórias de Usuário (COHN, 2004) utilizando técnicas Processamento de
Linguagem Natural (PLN)(BARBOSA; VIEIRA, 2017).

1.2 Objetivos

Com o objetivo de mitigar as limitações supracitadas, neste trabalho, é proposto o processo

thanoS (Appling NLP Algorithms to Automate Backend Test Generation from User Stories),
para a geração automática de teste para Interfaces de Programação de Aplicação (Application
Programming Interface - APIs) desenvolvidas no padrão Rest (RICHARDSON; RUBY, 2007).
Sendo assim, os códigos de testes são gerados com base nos requisitos funcionais, descritos
em Histórias de Usuário, utilizando algoritmos de PLN para processamento e tradução do texto
para o código de teste automatizado equivalente. A partir do processo thanoS, foi desenvolvido
um protótipo de ferramenta chamado thanoS Tool, o qual implementa as etapas deste processo,
e foi utilizado para validar suas vantagens.
Desta forma, o thanoS Tool permite que o testador não necessite de um conhecimento apro-
fundado em automação de testes, possibilitando que a atividade de teste seja mais simples,
eficiente e não propensa a falhas humanas. Para isto destacam-se os seguintes objetivos especí-
ficos:

a) Identificar a partir de Histórias de Usuário os requisitos a serem validados pela automação

de teste;

b) Utilizar de técnicas de PLN no processamento das Histórias de Usuário.

c) Desenvolver um protótipo de ferramenta capaz de gerar os códigos de teste a partir dos

Histórias de Usuário;

d) Avaliar os resultados obtidos e propor melhorias;

 3

2 FUNDAMENTAÇÃO TEÓRICA

Nesta seção, serão apresentados temas relacionados à proposta de pesquisa, i.e., metodolo-
gias ágeis, teste de software, metodologias e frameworks utilizados para o processo de automa-
ção de testes, bem como as etapas do Processamento de Linguagem Natural.

2.1 Processo de Software Ágil

O processo de desenvolvimento de software, refere-se ao ciclo de uma funcionalidade desde

a sua concepção até a sua entrega, esta pode ser realizada de diversas maneiras e busca propor
padrões de trabalho para facilitar a interação das pessoas com o projeto a ser realizado.
Sendo assim, baseado no fluxo de linhas de produção industrial, o modelo cascata foi o
principal formato adotado por times de desenvolvimento de software para organizar seu fluxo
de trabalho, apresentando um processo estático e sequencial do produto entre as diversas etapas
do software, onde inicialmente são definidos os requisitos, seguindo para o desenvolvimento e
por fim teste do sistema, e apenas ao após todas as etapas concluídas o projeto é entregue ao
cliente, conforme pode ser visto na Figura 1.

Figura 1 – Modelo de Fluxo Cascata

Fonte: Adaptado de Soares (2005)

Entretanto, esse modelo apresenta problemas principalmente em cenários onde são requi-
sitadas mudanças em fases mais avançadas do fluxo, necessitando que o processo seja reinici-
ado para atender a nova demanda, essas alterações se tornam mais frequentes devido a baixa
interação do cliente no processo de desenvolvimento do software, que comumente ocorre ex-
clusivamente na fase de levantamento de requisitos e na entrega do produto (ALEXANDRU
 4

ANDREI COSMIN, 2019) .

Desta forma, Com o incremento da complexidade dos sistemas, o fluxo de desenvolvimento
se torna mais demorado, aumentando a probabilidade de necessitar de mudanças durante o an-
damento, e consequentemente impactando o prazo da entrega final. As metodologias ágeis vêm
então como uma alternativa ao modelo cascata, propondo ciclos de trabalhos menores e entre-
gas incrementais ao produto, possibilitando que sejam entregues pequenas partes do sistema
por vez, e cada parte contendo seu próprio fluxo, reduzindo o retrabalho causado por possíveis
mudanças de requisito (SOARES, 2005).

2.2 Metodologia Scrum

O Scrum é a metodologia ágil mais difundida em times de desenvolvimento de propósito

geral (AL-SAQQA; SAWALHA; ABDELNABI, 2020), é uma interpretação do manifesto ágil,
o qual foi proposto por profissionais experientes no assunto gerando o compilado que descreve
um direcionador com princípios práticas ágeis (BECK; BEEDLE; BENNEKUM, 2001).
Deste modo, o Scrum consolida estes conceitos em um modelo prático baseado em itera-
ções, onde cada iteração nesse modelo é denominada Sprint, representando um período que
pode variar de acordo com a necessidade dos times, este período é delimitado para possibilitar
que os times revisem as necessidades do processo e do negócio com mais frequência durante os
projetos, o fluxo de trabalho de um time Scrum pode ser observado na Figura 2.

Figura 2 – Modelo de Fluxo Scrum

Fonte: (SCHWABER; BEEDLE, 2002)

2.2.1 Time Scrum

O time Scrum incentiva comportamentos multifuncionais, onde todos devem ser capazes de
atender as tarefas, desde a análise ao teste do produto, e espera-se que o time seja autogeren-
ciável, por isso se tem um número reduzido de profissionais compondo cada time. Além disso,
 5

segundo o Scrum Guide (SCHWABER; SUTHERLAND, 2020), os times devem ser formados
por os seguintes componentes:

• Scrum Master: tem como objetivo direcionar o time nas melhores práticas da metodologia
ágil.

• Product Owner: ou dono do produto, é o representante do cliente no time, ele deve ser
capaz de entender as necessidades e passar ao time.

• Desenvolvedores: todos os profissionais necessários para definir e entregar os requisitos

solicitados, sendo comumente analistas, desenvolvedores e testadores;

2.2.2 Cerimônias Scrum

As cerimônias são marcos dentro dos ciclos realizados pelo time, comumente referidas
como reuniões, devido a característica iterativa da metodologia, estas são realizadas para que
os ciclos sejam evoluídos a cada iteração, e têm diversos objetivos desde troca de informações
internamente e externamente à reflexões sobre o processo. Algumas das cerimonias propostas
pelo Scrum Guide (SCHWABER; SUTHERLAND, 2020) são:

• Planning: Momento onde são priorizadas as Histórias de Usuário que serão trabalhadas
no ciclo que irá se iniciar;

• Daily: Ocorre diariamente com objetivo de trocar e alinhar informação entre o time, a fim
de verificar riscos para a entrega;

• Review: Realizada ao fim da Sprint, nesse momento o Product Owner e os clientes são
convidados a validar a entrega realizada no período;

• Retrospectiva: Momento onde os times fazem uma auto-critica e refletem com objetivo
de aprimorar o processo de software para as próximas iterações.

2.2.3 História de Usuário

Artefatos de especificação de requisitos são uma parte fundamental de um projeto, neles

ficam formalizados as necessidades a serem atendidas para a entrega do sistema. No modelo
cascata, comumente são utilizados de casos de uso, documentos complexos escritos de forma
rígida e extremamente descritiva com foco, em definir cada cenário possível e trazendo como
principal objetivo as interações do usuário com o sistema, buscando maior formalidade do re-
quisito (COHN, 2004), conforme evidenciado na Figura .
Sendo assim, para melhor se enquadrar nos princípios ágeis, uma proposta é aderir ao uso de
Histórias de Usuário, buscando separar os requisitos em diferentes artefatos menores, mas que
mantêm algum valor de negócio, assim elas tendem a ser mais objetivas e facilmente legíveis por
 6

Figura 3 – Exemplo Caso de Uso

Fonte: Adaptado de (COHN, 2004)

todos do time, focando no que precisa ser feito e não em como fazer, deixando as especificidades
dos técnicas cenários para outros documentos com tal objetivo.
Com objetivo de padronizar o conteúdo das Histórias de Usuário, um formato frequente-
mente utilizado em times ágeis (INSTITUTE, 2016), é contar uma história do ponto de vista
do usuário, para isso, deve-se considerar quem será o principal ator envolvido, e responder as
perguntas:

• Quem? As necessidades de quem a História está buscando a atender;

• Oque? Oque deve ser feito para atender esta necessidade;

• Porque? Os motivos para a necessidade dessa História de Usuário, bem como a criticidade
da mesma.

Deste modo, respondendo estas perguntas a partir da visão do usuário, coloca-se a necessidade
de trazer valor para o usuário final em primeiro lugar, deixando claro o que deve ser feito, e
qual o problema busca-se resolver, de forma simples e facilmente compreensível entre todos do
time, conforme pode ser observado na Figura 4. Além disso, para auxiliar na escrita de uma
História de Usuário de qualidade, alguns critérios podem ser considerados na elaboração da
mesma, para isto, em (COHN, 2004) propõe-se o padrão INVEST, acrônimo para:

• Independent: Independente das demais Histórias de Usuário;

 7

• Negotiable: Negociável, referente a estar aberto para alterações de prazo e escopo;

• Valuable: Valiosa, deve agregar valor de negócio para os clientes;

• Estimable: Estimável, ou seja, o time é capaz de entender o esforço necessário;

• Testable: Testável.

Figura 4 – Exemplo História de Usuário

Fonte: Adaptado de (SCHWABER;

BEEDLE, 2002)

2.3 Teste de Software

Com objetivo de garantir o devido funcionamento e a qualidade dos softwares desenvolvi-

dos, é necessário validar os artefatos que são gerados, para isso é incluído no fluxo de desenvol-
vimento a fase de testes, o momento onde são verificados possíveis defeitos técnicos e também
se o que está sendo entregue atende aos requisitos solicitados, reduzindo a probabilidade de
entregas defeituosas para ambientes produtivos.
Sendo assim, o planejamento do teste de software, inicia-se a partir dos documentos le-
vantados que definem os requisitos da entrega, como por exemplo as Histórias de Usuário, em
seguida é necessário extrair os cenários de testes, que são os possíveis caminhos que podem ser
executados no processo, podendo ser caminhos de sucesso e exceção. Isso acaba por gerar ou-
tro documento, chamado de Caso de Teste, que armazena os critérios que serão avaliados para
definir se o software está de acordo quando o teste for realizado (GRAHAM; VANS; BLACK,
2007).
Desta forma, a execução do teste ocorre com o software já desenvolvido, este então é subme-
tido aos cenários previamente definidos e é avaliado se o retorno está de acordo com o esperado
e documentado as evidências de sucesso ou erro. Para realizar os cenários existem diversas
possibilidades que podem variar conforme o software em questão ou as práticas adotadas pelos
profissionais de qualidade.
 8

2.3.1 Níveis de Teste

Segundo (FARIAS, 2008), os níveis de teste são classificações da abstração e escopo que
serão utilizados na execução do teste, e quanto mais abrangentes mais complexo se torna o
processo, alguns desses grupos são:

• Teste de componente ou unidade: nesse caso é levado em consideração apenas o que foi
desenvolvido, focando na funcionalidade em específico, abstraindo questões externas ou
outros componentes com o qual pode se comunicar, apenas verificando se essa unidade
atende ao requisito;

• Teste de integração: testa-se além do que foi construído, todo o grupo de componentes
com o qual há relacionamento.

• Teste de aceitação: com uma visão mais alto nível, tenta-se simular a interação externa
com o sistema em uma posição de cliente, testando se o sistema como um todo atende ao
requisito;

2.3.2 Tipos de Teste

Segundo (GRAHAM; VANS; BLACK, 2007), os três principais tipos de teste são funci-
onal, não funcional e de regressão, todos podem ser aplicados nos diferentes níveis de teste,
diferenciando apenas o objetivo especifico de cada um conforme a necessidade do item a ser
testados.
O teste funcional, é definido com base nos documentos de requisitos, realizando intera-
ções com a aplicação e comparando do resultado esperado, a fim de definir se o sistema tem o
comportamento especificado. Segundo (FARIAS, 2008), esse teste pode ser chamado também
de teste de caixa preta, referindo-se ao software em questão como a caixa preta, sendo assim,
apenas tem se a visão de fora do sistema podendo utilizar das entradas para definir o resultado.
Por outro lado, os testes não funcionais, tem como objetivo garantir que o sistema conse-
gue entregar o requisito funcional com qualidade, testando então o ambiente que suporta este
software. Estes podem ser sub categorizados entre:

• Teste de carga: tem o objetivo de verificar o comportamento do sistema quando submetido

a um valor crescente de interações.

• Teste de desempenho: pode ser realizado para evidenciar o tempo de resposta do sistema
em diferentes cenários de carga.

• Teste de stress: utilizado para sobrecarregar o sistema e verificar sua estabilidade.

 9

• Testes de regressão: nesse caso não se tem especificado um requisito em particular a ser
testado, mas busca-se garantir que funcionalidades críticas seguem no comportamento
esperado, após mudanças no sistema.

2.3.3 Execução de Testes

Após mapeados os critérios a serem atendidos pelo software e a estratégia de testes defi-
nida, resta então executar o processo de teste do sistema, passando pelos cenários definidos
para verificar o resultado obtido. Em um teste funcional, por exemplo, esse processo pode ser
realizado de forma manual, ou seja, uma pessoa interage manualmente com o sistema execu-
tando os passos definidos e verificando a resposta obtida, e normalmente são evidenciados tais
passos realizados a fim de comprovar o comportamento.
Entretanto, para cenários específicos, pode fazer sentido realizar os testes nesse formato,
mas quando tomamos de exemplo os testes de regressão, pode se evidenciar gargalos no fluxo
de desenvolvimento, como visto anteriormente, os testes regressivos visam manter funcionali-
dades críticas do sistema estáveis, então todos esses processos precisam ser manualmente tes-
tados e evidenciados repetidamente, trazendo a vista a característica de repetição dos processos
manuais.
Desta forma, os testes automatizados propõem uma abordagem diferente, buscando dispo-
nibilizar uma ferramenta capaz de realizar as funções que poderiam ser efetuadas de forma
manual, possibilitando uma forma simples de executar o teste e provendo reusabilidade para
eventuais necessidades posteriores.
Sendo assim, o esforço é utilizado para criar a ferramenta e não efetivamente executar os
passos, isso ao custo do incremento do tempo e complexidade dessa etapa (PINHEIRO; VA-
LENTIM; VINCENZ, 2015), uma comparação entre o tempo e esforço exigido entre testes
automatizados e manuais pode ser vista na Figura 5, em que evidencia-se que os testes auto-
matizados em geral custam mais para o desenvolvimento mas apresentam maior valor ao longo
prazo.

Figura 5 – Comparação Teste Automatizado e Manual

Fonte: Adaptado de (Farias, 2008)

 10

2.4 Teste Orientado ao Desenvolvimento

Contribuindo para a programação ágil de software, uma prática interessante que pode ser
adotada Teste Orientado ao Desenvolvimento (Test Driven Development - TDD), que propõe
para os desenvolvedores de um software que pensem também na qualidade do software em
primeiro lugar, criando seus próprios testes para aumentar a confiabilidade do código, cola-
borando assim para o processo de compartilhar a responsabilidade pela qualidade do software
entre o time (PINHEIRO; VALENTIM; VINCENZ, 2015).
Além disso, a adoção desta prática possibilita que parte da etapa de teste seja realizada para
durante o desenvolvimento da funcionalidade, diminuindo assim o custo de tempo para entrega
do software, já que no formato padrão o teste apenas poderia começar ao fim do desenvolvi-
mento.

2.5 Desenvolvimento Orientado ao Comportamento

O Desenvolvimento Orientado A Comportamento (Behavior Driven Development - BDD) é

um método de alinhar a automação de testes junto ao processo ágil, buscando deixar automações
mais acessíveis, definindo o foco para os comportamentos esperados do sistema, extraindo as-
sim os critérios de aceitação e os definindo de forma mais compreensível ao time (PINHEIRO;
VALENTIM; VINCENZ, 2015).
Para implementação desse método, pode-se utilizar do Gherkin, uma linguagem que pos-
sibilita descrição de tais comportamentos BDD, padronizados de forma humanamente legível
(FURKAN; OVATMAN, 2016), conforme demonstrado na Figura 6, sendo as palavras-chave
da linguagem destacadas em negrito.

Figura 6 – Sintaxe Gherkin

Fonte: Adaptado de (ONEDAYTESTING, 2019)

2.6 Serviços Rest

Os serviços Rest, tem o objetivo de disponibilizar funcionalidades do sistema na rede para

utilização, mas abstraindo a sua implementação, possibilitando assim a comunicação, com base
no Protocolo de Transferência de Hipertexto (Hypertext Transfer Protocol - HTTP), entre dife-
rentes sistemas que não precisam compartilhar da mesma arquitetura. A arquitetura Rest, por
 11

sua vez propõe um padrão para desenvolvimentos de aplicações do lado do servidor, e para
comunicação entre as mesmas (RICHARDSON; RUBY, 2007).
Sendo assim, para realizar uma requisição a uma funcionalidade exposta por um serviço
Rest, são necessárias algumas informações, como a rota, para identificar o recurso e a sua
funcionalidade desejada, o método HTTP, que é utilizado para definir o tipo de comportamento
que se deseja acessar.
Deste modo, por exemplo, para recuperar um recurso sem alterá-lo, deve-se utilizar o mé-
todo HTTP get, já para persistir um novo recurso deve-se utilizar o método post. Além disso,
o corpo da requisição, é uma forma mais densa de passar informações que serão utilizadas pelo
serviço, outra característica do HTTP, que é importante nas comunicações são as situações das
requisições, que retornam um código representando erro ou sucesso do processo (TREVISAN,
2016).
No padrão Rest, recomenda-se que o conteúdo enviado nas requisições entre aplicações seja
formatado em Json (BARBAGLIA; MURZILLI; CUDINI, 2016), sendo o esta uma forma de
representar dados em formato chave e valor, sua vantagem quando comparado a outros padrões
de representação de dados, é o tamanho reduzido do resultado final, se tornando a melhor opção
para trafegar a informação pela rede. Desta forma, uma representação Json pode ser vista na
Figura 7, em que se tem a chave “nome” com valor igual a “Alexandre Gama”.

Figura 7 – Exemplo Json

Fonte: (ALEXANDRE, 2011)

2.6.1 Teste de APIs Rest

Para validar uma API Rest, deve-se avaliar os tipos e níveis de testes que serão aplicados,
assim podendo ser realizado de forma manual, efetuando as requisições e evidenciando o seu
retorno, ou automatizada, gerando os Casos de Testes (Test Case - TC) que fazem a validação
do resultado esperado, para facilitar a criação desses cenários existem diversas ferramentas que
buscam facilitar o processo.

2.6.2 Rest Assured

O Rest Assured é um framework de desenvolvimento Java, focado em serviços Rest, que

proporciona facilidades na criação, execução e análise de resultados de teste automatizados
 12

(TREVISAN, 2016). Tais automações podem ser aplicadas submetendo o serviço a um cenário,
representado como a entrada enviada, e comparando se o retorno ou comportamento se da con-
forme o esperado. Após desenvolvidos os cenários, a automação fica disponível para posteriores
execuções, e caso necessário para realizar possíveis testes regressivos.
O framework disponibiliza então ferramentas para realizar a requisição ao serviço a ser
testado, e obter o retorno para que o mesmo seja submetido as devidas validações, como por
exemplo, verificar se a situação retornada é a esperada, ou se há um determinado valor no corpo
retornado. Estas regras devem ser construídas conforme os critérios de aceite informados no
documento de requisitos do software, com os cenários automatizados é então composto o grupo
de critérios que definirão se o sistema está conforme os requisitos (TREVISAN, 2016).
Conforme pode ser visto na Figura 6, o método when representa a preparação dos dados, ou
o cenário, é utilizado na sequência o comando get, que representa o verbo HTTP a ser requi-
sitado, e como parâmetro é informado a rota, contendo o identificador do recurso de interesse.
Para validação após o then é requisitado as informações retornadas pelo serviço, no caso sendo
o código de retorno 200 representando sucesso, e ainda é verificado se o valor da chave "lottoId"
da entidade "lotto" é igual a 5, caso essas asserções sejam verdadeiras o teste e encerrado com
sucesso.

Figura 8 – Exemplo Rest Assured

Fonte: (HALEBY, 2011)

2.7 Processamento de Linguagem Natural

O Processamento de Linguagem Natural, é uma especificação do estudo de Inteligência

Artificial, que tem como objetivo extrair informação a partir de linguagens humanas, como o
português e o inglês, e modelar esses dados de forma útil para o sistema (MOULINIER, 2007).
A grande complexidade deste tipo de algoritmo se dá devido a ambiguidade presente nas
formas de comunicação (PINTO, 2008), o que facilmente é resolvido por humanos, mas se
torna um grande desafio para classificação, exigindo uma análise complexa do contexto, já que
a mesma palavra pode ter diversos significados dependendo de sua utilização, sendo assim,
diferentes palavras, ou combinações, podem levar ao mesmo resultado.
 13

Deste modo, para modelar uma ferramenta capaz de compreender toda essa diversidade das
linguagens humanas, tradicionalmente o conteúdo é submetido à uma série de etapas, conforme
ilustrado na Figura 9, com objetivo de filtrar e corrigir possíveis conflitos de forma granular em
cada etapa (BARBOSA; VIEIRA, 2017).

Figura 9 – Etapas PLN

Fonte: Adaptado de (BARBOSA;

VIEIRA, 2017)

2.7.1 Tokenização

A Tokenização é a primeira fase do processo, e tem como objetivo delimitar a separação do

conteúdo em partes menores com significado próprio, em uma linguagem natural esses novos
blocos são referidos como tokens e representam as palavras, que são classificadas com base no
dicionário de palavras conhecidas desta linguagem.
Desta forma, o critério para a divisão dos blocos de tokens pode variar, mas nas linguagens
europeias, a estratégia mais comum é delimitar o limite das palavras pelo caractere de espaço,
realizando assim a divisão de um novo token a cada espaço encontrado no conteúdo.

2.7.2 Análise Léxica

Seguindo na ordem da pipeline de etapas, com a coleção de tokens devidamente construída,

é realizado então o processo de análise léxica, que busca extrair informações a fim de categorizar
os tokens conforme um dicionário previamente disponibilizado, que deve conter as palavras no
contexto da linguagem.
Desta forma, quando categorizados os tokens são reunidos com seus devidos lemmas, que
são representações canônicas das palavras que tem como objetivo agrupar palavras que derivam
de outra, por exemplo, a palavra ENTREGADOR pertence ao lema ENTREGAR, o conjunto
desse lemma é composto também das palavras ENTREGA, ENTREGANDO e ENTREGUE.
 14

2.7.3 Análise Sintática

A partir da fase de análise sintática, inicia-se o processo de agrupar as informações geradas

nas etapas anteriores compondo assim as frases, a fim de gerar um contexto. A construção
destas frases é composta por diversas regras, as quais devem estar definidas em uma gramática
da linguagem (GONZALEZ; LIMA, 2008), e utilizando das classificações realizadas na etapa
de análise léxica, as palavras são devidamente arranjadas nas frases.

2.7.4 Análise Semântica

Ao contrário da etapa anterior, em que se preocupava com a estrutura das frases, na fase
de análise semântica, é analisado então o contexto da frase, para se extrair o significado do
que de fato deseja-se passar com o texto em questão. Sendo essa a etapa mais complexa do
processamento, devido a necessidade de resolver ambiguidades, que são conflitos no sentido de
uma palavra dependendo de sua utilização.

2.7.5 SpaCy

Deste modo, para implementar as etapas do PLN, existem diversas bibliotecas que dispo-
nibilizam abstrações para facilitar o uso destes algorítimos, sendo uma delas, o Python SpaCy
(VASILIEV, 2003), uma biblioteca para a linguagem Python. O SpaCy disponibiliza algorit-
mos para realizar a Tokenização de frases e comparação de similaridade entre palavras. Além
disso, é disponibilizado pela biblioteca um vasto dicionário de palavras reconhecidas em di-
versas linguagens, como Português e Inglês, dicionários estes que também são disponibilizadas
pela ferramenta.
O algoritmo de cálculo da similaridade entre palavras, fornecido pela biblioteca SpaCy, é a
chave para o processo thanoS e será abordado posteriormente na seção 5, este utiliza interna-
mente de algoritmos que possibilitam a geração de um valor, interpretado como a similaridade
entre as palavras, sendo estes principalmente o Word2vec e a Distância Euclidiana.
O Word2vec, é um algoritmo de incorporação de palavras, que no contexto da ferramenta, é
responsável por transformar as palavras em vetores, com valores que representam suas caracte-
rísticas. Sendo assim, este algoritmo utiliza de uma rede neural previamente treinada, utilizando
método SkipGram, no qual a rede é treinada para receber uma frase, omitindo uma palavra e
tenta-se elencar probabilidades para possíveis palavras serem a que foi omitida originalmente
(CHUAN; AGRES; HERREMANS, 2018).
Deste modo, com os vetores gerados pelo Word2Vec, é utilizado do algoritmo de Distância
Euclidiana para delimitar a distância entre os vetores representantes das palavras que estão a
ser comparadas, a distância normalizada entre os dois gera um número, sendo este o valor
interpretado como a similaridade das palavras.
 15

3 METODOLOGIA DE PESQUISA

A elaboração deste estudo, foi baseada na metodologia de pesquisa exploratória, com ob-
jetivo de evidenciar pontos de relevantes para o estudo como, o estado da arte, as soluções e
problemas existentes no processo de teste de software, assim como, esclarecer conceitos para
melhor entendimento da proposta do trabalho. Explorando estes conceitos busca-se apresentar
e validar hipóteses, que poderão contribuir para área de desenvolvimento de software em geral.
Para embasar a pesquisa, foi realizado uma revisão da literatura, conforme descrito na seção
2, em que foram realizas buscas por referências em literaturas e artigos, priorizando pela sua
data de publicação e relevância ao tema do trabalho, conforme proposto em (MARCONI; LA-
KATOS, 2010), para que seja possível identificar e propor possíveis melhorias para o processo
de teste de software.
Desta forma, a partir deste estudo, será desenvolvido processo, e um protótipo de ferramenta
o implementando, que utilizando de algorítimos de PLN, será capaz de processar artefatos de
requisitos, como as Histórias de Usuário propostas pelo Scrum, e com base nestas gerar códigos
de testes de forma automatizada, validando os requisitos descritos no artefato.
Além disso, para a construção do protótipo, serão realizadas integrações com ferramentas
preexistentes, que disponibilizem recursos de interesse para facilitar o processo, tais como, a
biblioteca Python SpaCy, que fornece algoritmos de PLN, o Cucumber (SMART, 2014), para
integração de critérios escritos em Gherkin, com o seu devido código representante, bem como,
o TestNG (GRAHAM; VANS; BLACK, 2016) para execução dos códigos de teste gerados, a
utilização específica destas é descrita na Seção 5.
Para validação da viabilidade do processo e protótipo, serão submetidos a testes quantita-
tivos, a fim de medir seu desempenho, quando comparado ao processo manual de escrita de
códigos, a partir dos mesmos artefatos de requisitos.

4 TRABALHOS RELACIONADOS

Devido a necessidade constante de tornar o processo de teste de software mais ágil, diversos
estudos foram realizados buscando propor tecnologias, métodos e técnicas para otimizar o pro-
cesso de testes. A seguir, são apresentados os estudos e pesquisas relacionados ao tema, bem
como, uma análise comparativa com a solução proposta neste trabalho.
Em (SINGH; SHARMA, 2015), foi proposta uma ferramenta para geração de testes auto-
matizados com base a partir de requisitos descritos em diagramas de Caso de Uso UML (Use
Case - UC). Porém, uma das limitações da ferramenta proposta pelo autor, refere-se ao esforço
e conhecimento adicional para criar os Casos de Uso, a partir dos quais são gerados os cenários
de testes automatizados. Além disso, diferentemente do processo thanoS, a solução proposta
pelo autor não utiliza PLN e algoritmos de Inteligência Artificial para a geração automática de
testes.
 16

Uma abordagem similar ao processo thanoS é apresentada em (FARIAS, 2008), a qual apre-
senta uma técnica que utiliza PLN para classificar automações previamente escritas e, posterior-
mente, realizar consultas por palavras-chave a fim de reutilizar o código dos testes (Test Script
- TS). Entretanto, a proposta do autor exige a interação do testador para modelar o teste resul-
tante, sendo assim, é um processo parcialmente automatizado.
A partir desta técnica, o autor também desenvolveu uma ferramenta denominada NLScripts,
a qual foi classificada como composição assistida de testes, sendo assim, uma solução limitada
por ser um processo parcialmente automatizado, já que exige interação e esforço dos testadores
para escolher e modelar o código de teste resultante. Outra limitação do trabalho proposto pelo
autor, diz respeito a não utilização de um artefato da metodologia ágil descrever os requisitos
do sistema, como as Histórias de Usuário. Além disso, o autor não utiliza Inteligência Artificial
para determinar quais casos de teste são mais adequados a serem gerados.
Em (REOLON, 2020), foi proposto um método alternativo para testar páginas web utili-
zando o framework Selenium (BIRMINGHAM, 2014) para a geração de testes frontend. Neste
trabalho, foi desenvolvido um protótipo de ferramenta que utiliza PLN no processamento de
Histórias de Usuário. O protótipo foi nomeado TFA e é uma solução mais eficiente do que a
execução manual doe teste. Entretanto, diferentemente do processo thanoS, esta ferramenta não
pode ser aplicada para testes automatizados de APIs backend.
A partir dos cenários de testes já especificados, (SALMAN, 2020) propõe uma abordagem
utilizando PLN e algoritmos de Inteligência Artificial, para geração automatizada de códigos de
teste. Entretanto, esta abordagem se limita a composição de testes utilizando apenas códigos de
automações previamente desenvolvidas, as quais são utilizadas no treinamento da Inteligência
Artificial. Uma das limitações deste trabalho, é que todo o processo de geração de códigos de
teste, inicia a partir de cenários de teste que necessitam ser previamente criados pelo testador
a partir de uma especificação funcional. Tal limitação não existe no processo thanoS, uma vez
que a automação da escrita de códigos de teste é iniciada a partir de um artefato que descrevem
requisitos funcionais, tais como Histórias de usuário.
Com base nos estudos analisados, foram evidenciadas algumas lacunas, e.g., a não utiliza-
ção de PLN e algoritmos de inteligência artificial para a geração de testes de APIs backend.
Além disso, estes trabalhos fornecem uma automação parcial, i.e., necessitam da interação dos
testadores para a geração de cenário de teste, ou mesmo a seleção de termos utilizados para
posterior geração dos testes. Por outro lado, o processo thanoS prove uma automação mais
completa, sendo capaz de gerar os códigos de teste, utilizando o framework Rest Assured, a
partir de requisitos descritos em Histórias de Usuário.
A Tabela 1 apresenta uma comparação das principais características entre as abordagens
e metodologias propostas pelos trabalhos supracitados. Essas comparações fornecem alguns
indicadores relacionados à eficácia e vantagens do processo thanoS em relação a outras me-
todologias. No entanto, esta é uma proposta experimental e um estudo aprofundado deve ser
considerado para comprovar essas supostas vantagens.
 17

Tabela 1 – Comparação Trabalhos Relacionados

Critérios thanoS SINGH REOLON SALMAN FARIAS
Artefato Base US UC US TC TS
PLN Sim Não Sim Sim Sim
Esforço para configuração Médio Médio Médio Alto Alto
Conhecimento exigido para utilização Baixa Médio Baixa Baixa Alto
Gera de teste de API Sim Não Não Sim Não
Gera documentação dos cenários Sim Não Sim Não Não
Possui automação Não Não Não Não Sim
Fonte: Elaborada pelo autor.

5 PROCESSO THANOS

O processo thanoS propõe uma forma automática para a geração de testes para APIs Rest,
com base nos cenários definidos nas Histórias de Usuários, escritas na linguagem Gherkin, na
qual pode-se descrever os cenários a serem validados de modo humanamente compreensível.
As Histórias de Usuário são processadas por algoritmos de PLN, a fim de gerar testes automa-
tizados em Java, que representam a necessidade a ser verificada. As etapas específicas deste
processo são apresentadas na Figura 10 e detalhadas nas subseções seguintes.

Figura 10 – Proceso thanoS

Fonte: Elaborada pelo autor.

 18

5.1 Análise da História de Usuário - (a)

A primeira etapa, inicia com o recebimento de uma História de Usuário, escrita em lingua-
gem natural, seguindo o padrão Gherkin, conforme exemplificado na Figura 11. As palavras
Cenário, Dado, Quando e Então, são palavras reservadas da linguagem e identificam o
objetivo de cada frase do cenário. Portanto, cada frase deve ser iniciada por uma das palavras
reservadas, e cada palavra é classificada entre configuração e validação.
Por exemplo, as frases iniciadas com a palavra reservada Quando, são classificadas como
comandos de configuração, e os dados contidos nesta frase (“nome” e “pablo”), estão repre-
sentados entre aspas, uma vez que se trata de um padrão da linguagem Gherkin para identifica-
ção de dados parametrizáveis. Por fim, estes dados são utilizados posteriormente para a geração
da requisição HTTP da API a ser testada.
Por outro lado, as frases que iniciam com Então e E, são classificadas como comandos
de validação, sendo utilizadas posteriormente para validar o retorno obtido na requisição. Por
exemplo, o dado parametrizável “200” corresponde ao valor esperado do status da requisi-
ção HTTP. É importante destacar, que as frases iniciadas por outras palavras reservadas são
ignoradas, pois não são necessárias no processo thanoS, uma vez que as palavras supracitadas
satisfazem o objetivo de geração automatizada dos testes.

Figura 11 – Critério de Aceite Escrito em Gherkin

Fonte: Elaborada pelo autor.

5.2 Tokenização da História de Usuário - (b)

Com a História de Usuário devidamente separada e classificada no padrão Gherkin, inicia-

se o processo de geração dos tokens. Na prática, as palavra da História de Usuário passam por
um processo de Tokenização, em que cada palavra é classificada em um determinado padrão
gramatical. Por exemplo a palavra gravar é categorizada como verbo, enquanto a palavra
igual é classificada como adjetivo (ver Tabela 2). Portanto, os tokens são utilizadas para
identificar características de interesse nas palavras, como sua classe gramatical, prefixo, sufixo,
tempo verbal e o seu vetor representante, para que essa informação seja utilizada em etapas
posteriores.
Sendo assim, as palavras eu, gravar, pessoa e igual contidas na História de Usuário
da Figura 11, ao passar pelo processo de Tokenização são classificadas em diferentes classes
gramáticas, conforme é evidenciado na Tabela 2.
 19

Deste modo, para gerar os tokens, o processo thanoS pode utilizar diversas bibliotecas para
geração automática de tokens. Neste trabalho foi utilizada a biblioteca Pyhon SpaCy, um
vez que ela provê algoritmos de PLN treinados com bases de dados em diversas linguagens,
como o Português Brasileiro, proporcionando um vasto dicionário de palavras reconhecidas
pelo mesmo.

Tabela 2 – Exemplo de Classificação das Classes Gramaticais

Palavra Classe Gramatical
eu pronome
gravar verbo
pessoa substantivo
igual adjetivo
Fonte: Elaborada pelo autor.

5.3 Separação das Palavras de Interesse - (c)

Nesta etapa do processo thanoS, o objetivo é identificar palavras de interesse do grupo de

palavras tokenizadas na etapa anterior. Para isso, são elencadas as palavras que possuem classes
gramaticais de interesse, ao passo que, elementos e palavras que não possuem grande relevância
para o processo são ignoradas, e.g, verbos auxiliares e pontuação. As classes de principal
interesse para o processo thanoS são os verbos e adjetivos, os quais indicam, respectivamente,
o tipo de requisição HTTP a ser realizada e o retorno esperado para execução do teste.
Desta forma, conforme a História de Usuário da Figura 11, é possível identificar na frase
iniciada pela palavra Quando, que existem duas palavras classificadas como palavras de inte-
resse, i.e., o verbo gravar e o adjetivo igual. Estas palavras são utilizadas na próxima etapa
para análise de similaridade.

5.4 Comparação de Similaridade - (d)

Após definidas as palavras de interesse a serem analisadas em cada frase, é necessário re-
alizar a correlação entre uma palavra em um verbo HTTP específico. Por exemplo, a palavra
cadastrar representa o verbo HTTP POST, enquanto a palavra consultar é representada
pelo verbo GET (ver Tabela 3).
Para realizar esta correlação entre uma palavra e um verbo HTTP, no processo thanoS,
realiza-se uma análise de similaridade, em que uma palavra é comparada com um grupo de
palavras que melhor representam os verbos HTTP. Este grupo de palavras foi definido a partir
de testes com diversas combinações de palavras. Por exemplo, consulta e busca corres-
pondem ao grupo de palavras que melhor representa o verbo GET. Assim como, as palavras
cria e cadastra correspondem ao grupo de palavras que melhor representa o verbo POST.
 20

Os demais grupos de palavras e seus respectivos verbos HTTP são apresentados na Tabela 3.
A análise de similaridade é realizada a partir de uma funcionalidade disponibilizada pela
biblioteca SpaCy, que realiza comparações de similaridades entre palavras tokenizadas. Para o
funcionamento desta funcionalidade, o SpaCy utiliza internamente algoritmos como o Word2vec.
Este algoritmo gera vetores que representam características chave das palavras sendo compara-
das. Além disso, o SpaCy também utiliza o algoritmo chamado Distância Euclidiana, o qual é
responsável pelo cálculo da distância entre os vetores resultantes, retornando um valor entre 0
e 1, este valor é interpretado como o coeficiente de similaridade das palavras. Maiores detalhes
sobre o funcionamento destes algoritmos são apresentados na subseção 2.7.5.

Tabela 3 – Métodos HTTP e Suas Palavras Representantes

Verbo HTTP Palavras Representantes
GET consulta e busca
POST cria e cadastra
PATCH atualiza e troca
DELETE deleta e apaga
Fonte: Elaborada pelo autor.

A partir do grupo de palavras representantes da Tabela 3, foram realizados testes cujo

objetivo foi verificar o devido funcionamento da etapa de análise de similaridade. Nestes testes,
19 palavras passaram pelo algoritmo de análise de similaridade (o resultado completo pode ser
visto no Apêndice A), e uma seleção com as palavras mais relevantes, bem como o coeficiente
da sua similaridade com os verbos HTTP, é apresentada na Tabela 4. É possível observar, que
os testes foram efetivos, pois cada palavra analisada foi devidamente correlacionada ao verbo
HTTP esperado. Por exemplo, a palavra pesquisar foi corretamente correlacionada ao verbo
HTTP GET, pois ela apresentou o maior coeficiente de similaridade (i.e., 0,31) em comparação
com os demais verbos HTTP. Da mesma forma, as palavras inserir, excluir e mudar
foram corretamente correlacionadas, respectivamente, aos verbos POST, DELETE e PATCH.

Tabela 4 – Resultado do Teste de Similaridade

Verbo HTTP pesquisar inserir excluir mudar
GET 0,31 0,23 0,19 0,13
POST 0,17 0,28 0,20 0,13
PATCH 0,21 0,26 0,20 0,19
DELETE 0,07 0,19 0,27 0,14
Fonte: Elaborada pelo autor.

5.5 Conversão Para o Código de Testes - (e)

Nesta etapa, após correlacionar as palavras tokenizadas com os seus respectivos verbos
HTTP, inicia-se a geração do código de teste automatizado. Estes testes são gerados através da
 21

correlação entre determinados trechos de código Rest Assured, verbos HTTP e adjetivos que
correspondem aos métodos de validação.
Na prática, os dados parametrizáveis definidos na História de Usuário, são utilizados nos
trechos de código Rest Assured. Por exemplo, os dados parametrizados “nome” e “pablo”,
definidos na História de Usuário da Figura 11, são agora utilizados como parâmetros de re-
quisição HTTP (i.e., GET, POST, PACTH e DELETE) nos trechos de código Rest Assured (ver
Tabela 5).
Da mesma forma, os dados parametrizados “nome” e “pablo” são utilizados como parâ-
metros para os códigos dos métodos de validação (i.e., IGUAL, MAIOR e MENOR) do retorno
do teste (ver Tabela 6).

Tabela 5 – Métodos HTTP e Códigos Rest Assured Equivalentes

Verbos HTTP Código Rest Assured Equivalente
GET given().param("nome", "pablo").when().get(URL);
PATCH given().param("nome", "pablo").when().patch(URL);
DELETE given().param("nome", "pablo").when().delete(URL);
POST given().when().body("{"nome":"pablo"}").post(URL);
Fonte: Elaborada pelo autor.

Tabela 6 – Métodos de Validação e Códigos Rest Assured Equivalentes

Métodos de Validação Código Rest Assured Equivalente
IGUAL ("nome", Matchers.equalTo("pablo"));
MENOR ("nome", Matchers.graterThan("pablo"));
MAIOR ("nome", Matchers.lessThan("pablo"));
Fonte: Elaborada pelo autor.

5.6 Execução dos Testes Automatizados - (f)

Por fim, com os códigos de testes automatizados gerados na etapa anterior pelo processo
thanoS, é possível seguir para sua execução. Os testes são executados usando o software In-
telliJ e podem ser reexecutados repetidas vezes conforme demanda. O resultado de cada teste
apresenta um status de sucesso ou falha, conforme as regras definidas na História de Usuário.

6 EXEMPLO DE APLICAÇÃO

Para avaliar o processo thanoS, foi criado um protótipo de ferramenta para a geração auto-
mática de códigos teste para APIs Rest, o thanoS Tool o qual implementa as etapas do processo
thanoS.
 22

6.1 thanoS Tool

O thanoS Tool foi desenvolvido na ferramenta Pycharm (ISLAM, 2015), utilizando a lin-
guagem Python 3 (PERKINS, 2012), e a biblioteca SpaCy, que disponibiliza algoritmos de
PLN. O protótipo recebe como entrada um arquivo de texto com a História de Usuário escrita
na linguagem Gherkin, a qual descreve as funcionalidades a serem testadas.
A saída gerada pela thanoS Tool corresponde ao código de teste gerado para a linguagem
Java, utilizando framework Rest Assured. Os códigos de teste gerados podem ser vinculados
a História de Usuário, integrando a execução com a ferramenta Cucumber para execução inte-
grada com JUnit (HUNT; THOMAS, 2020) ou TestNG (GRAHAM; VANS; BLACK, 2016).
Deste modo, a execução do thanoS Tool se dá a partir de uma linha de comando utilizando
Python, onde os parâmetros são, respectivamente, o arquivo da História de Usuário e o diretório
onde será gerado o código de testes automatizado na linguagem Java.

6.2 Validação do thanoS Tool

Nesta subseção, o objetivo é realizar a comparação entre duas abordagens. A primeira

abordagem corresponde a geração de testes manuais em que um analista de teste, a partir das
requisitos descritos em uma História de Usuário, escreve o código de automação de teste ma-
nualmente. A segunda abordagem, corresponde a geração de testes de forma automatizada,
utilizando o protótipo thanoS Tool, a partir da mesma História de Usuário. Para cada uma das
abordagens são medidos os tempos de execução, com objetivo final de determinar qual é capaz
de gerar testes em menor tempo e com menor esforço.
A História de Usuário utilizada na validação é composta de 3 cenários de teste, conforme
apresentado na Figura 12. Estes cenários foram escritos na linguagem Gherkin e representam
cenários para validação de uma API Rest que expõe funcionalidades de manutenção do recurso
pessoa, sendo possível utilizar as operações de cadastro e consulta de pessoa por seu nome e
número de documento. Portanto, cada cenário descreve a operação a ser realizada, os parâme-
tros a serem informados e o resultado esperado para cada uma das requisições. Estes cenários
são descritos a seguir:

a) Cadastrar uma pessoa por nome e número de documento, esperando retorno de sucesso.

b) Consultar uma pessoa por nome e número de documento, esperando retorno de sucesso.

c) Consultar uma pessoa por documento, esperando retorno de erro.

A partir desta História de Usuário, foram gerados os códigos de testes em Rest Assured
utilizando a abordagem automatizada e manual e obtidos os tempos de execução de cada abor-
dagem. Para isso, conforme descrito anteriormente, foi utilizada para ambas as abordagens a
mesma História de Usuário.
 23

Figura 12 – Históra de Usuário Escrita em Gherkin

Fonte: Elaborada pelo autor.

6.3 Análise dos Resultados

Após a geração e execução dos testes utilizando as abordagens manual e automatizada, foi
possível obter os dados quantitativos de tempo de criação dos códigos de teste.
Desta forma, conforme apresentado na Tabela 7, o tempo para geração do código de teste
utilizando o thanoS Tool foi igual a 15 segundos. Um exemplo de código de teste gerado
pelo protótipo de ferramenta pode ser observado na Figura 13. Por outro lado, o tempo de
geração dos códigos de teste utilizando a abordagem manual e realizada por um profissional
com experiencia nas tecnologias utilizadas foi de 20 minutos.
É importante destacar, que o conhecimento necessário em tecnologias de teste para o pro-
fissional escrever o código de teste manualmente, não é demasiado relevante quando utilizado
o thanoS Tool, uma vez que não é necessário um conhecimento aprofundado em tecnologias e
frameworks de teste para a utilização deste.

Tabela 7 – Comparação de Tempo de Geração de Testes Utilizando o Processo thanoS

CRITÉRIO TEMPO
Criação dos testes a partir de cenários de aceite com thanoS 15 segundo
Criação dos testes a partir de cenários de aceite sem thanoS 20 minutos
Fonte: Elaborada pelo autor.

Entretanto, o tempo de geração dos códigos de testes não é a única vantagem observada do
processo thanoS. A partir do protótipo thanoS Tool, foi possível observar também vantagens
nos tempos para manutenções dos códigos de testes. Nesse caso, é necessário apenas manter a
História de Usuário com os requisitos atualizados e realizar uma nova execução do thanoS Tool
para obter os códigos de teste atualizados. Além de incentivar a cultura de manter as Histórias
de Usuário atualizadas, o thanoS Tool também contribui para os testes de regressão.
Além disso, utilizando o thanoS Tool, foi possível mitigar a possibilidade de erro humano,
bem como, pode-se observar uma cobertura total dos testes em relação aos requisitos defini-
 24

Figura 13 – Trecho de Código Gerado Pelo Protótipo

Fonte: Elaborada pelo autor.

dos na História de Usuário. Processo este que quando executado manualmente, frequentemente
pode estar cobrindo apenas parcialmente os requisitos. Também afetado pelo fator humano, a
qualidade do código pode ser levada em consideração, já que a o protótipo é capaz de desen-
volver um código padronizado, e o mesmo processo manual pode resultar em uma qualidade
variável dependendo do profissional que o realizar.
Deste modo, analisando os resultados obtidos a partir dos testes supracitados, evidencia-
se a relevância do processo thanoS, bem como, sua viabilidade com base no protótipo thanoS
Tool. Uma comparação direta entre as abordagem automatizada (utilizando thanoS Tool) e a
abordagem manual de geração dos códigos pode ser observada na Tabela 7.

Tabela 8 – Comparação do Processo thanoS e Processo Manual

CRITÉRIO COM thanoS SEM thanoS
Conhecimento prévio necessário BAIXO ALTO
Esforço para criação dos códigos de teste BAIXO MÉDIO
Esforço para manutenção dos códigos de teste BAIXO MÉDIO
Confiabilidade dos cenários cobertos ALTO VARIÁVEL
Padronização do código de teste ALTO VARIÁVEL
Fonte: Elaborada pelo autor.
 25

7 CONSIDERAÇÕES FINAIS

Este estudo teve como objetivo analisar o processo de software, com foco no seu impacto
na área de testes, a partir da análise de abordagens e técnicas propostas por diversos autores
da comunidade cientifica. Portanto, com base nestes estudos, evidencia-se que a adesão dos
testes automatizados se mostra uma solução eficaz quando comparado com a execução de testes
manuais. Porém, mesmo com as vantagens oriundas da automação de testes, são necessários
profissionais capacitados e tempo para o desenvolvimento dos códigos de teste, aumentando
assim a complexidade técnica do processo.
Nesse contexto, para mitigar o custo de desenvolvimento de testes automatizados, nesse
trabalho foi proposto o processo thanoS, que utiliza algoritmos de Inteligência Artificial, para a
geração dos testes de forma automatizada. Para isso, foram utilizadas técnicas de PLN, a partir
dos cenários descritos em Histórias de Usuário, previamente desenvolvidos pelos times ágeis,
para criar automaticamente o código de teste, utilizando o framework Rest Assured para testes
de APIs backend.
Deste modo, a partir das etapas definidas para o processo thanoS, foi desenvolvido um
protótipo de ferramenta para validação do processo, com base em algoritmos de Inteligência
Artificial preexistentes, disponibilizados pelo Python SpaCy, que realizam o processamento de
Histórias de Usuário e, posteriormente, a geração de código de teste automatizado. Portanto,
com o thanoS Tool, foi possível evidenciar sua eficácia por meio de uma análise quantitativa,
onde mediu-se os tempos para a geração de códigos de teste utilizando a ferramenta proposta
neste trabalho e uma abordagem manual.

7.1 Trabalhos Futuros

Embora o processo thanoS tenha obtido um resultado satisfatório, o protótipo desenvolvido

ainda está limitado e precisa ser aperfeiçoado para aumentar sua abrangência, tanto nos méto-
dos de validação de retornos, quanto nos modelos de requisição HTTP que não estão cobertos
atualmente.
Além disso, analisando possíveis pontos de melhoria para o processo e protótipo desen-
volvidos, observa-se a oportunidade de estender o protótipo para atender um escopo maior de
linguagens, bem como gerar código em outras linguagens de programação, tornando o processo
mais compatível com as necessidades de cada time. Estes pontos não foram levados a diante
devido ao escopo delimitado do estudo, mas podem ser exploradas posteriormente. Portanto,
apresentam-se a seguir sugestões de melhoria e trabalhos futuros:

a) Processar critérios escritos em outras linguagens, além do português;

b) Gerar códigos em linguagens de programação além do Java;

c) Atender mais cenários alterativos, para requisição e validação do retorno.

 26

d) Melhorar a usabilidade do protótipo de ferramenta, não foi o foco desse estudo, mas está
aberta para modificação a fim de melhorar a experiência do usuário.

Referências

AL-SAQQA, S.; SAWALHA, S.; ABDELNABI, H. Agile software development:

Methodologies and trends. iJIM, 2020.

ALEXANDRE. O que é JSON. 2011. Disponível em: <https://www.devmedia.com.br/o-que-

e-json/23166>. Acesso em: 28 outubro 2022.

ALEXANDRU ANDREI COSMIN, S. C. B. A STUDY ON USING WATERFALL AND

AGILE METHODS IN SOFTWARE PROJECT MANAGEMENT. [S.l.]: JOURNAL OF
INFORMATION SYSTEMS OPERATIONS MANAGEMENT, 2019.

BARBAGLIA, G.; MURZILLI, S.; CUDINI, S. Definition of rest web services with json
schema. SPE, 2016.

BARBOSA, J.; VIEIRA, J. Introdução ao Processamento de Linguagem Natural usando

Python. [S.l.: s.n.], 2017.

BECK, K.; BEEDLE, M.; BENNEKUM, A. Manifesto for Agile Software Development.
[S.l.: s.n.], 2001.

BIRMINGHAM, S. A. Selenium WebDriver 3 Practical Guide. [S.l.]: Packt Publishing Ltd,

2014.

CARDEAL, W.; PARREIRA, W. Estudo sobre a utilização de testes automatizados em projeto

de software de grande porte. Simpósio de Pós-Graduação do IFTM, 2015.

CHUAN, C.-H.; AGRES, K.; HERREMANS, D. From context to concept: exploring semantic
relationships in music with word2vec. Springer, 2018.

COHN, M. User Stories Applied-For Agile Software Development. [S.l.: s.n.], 2004.

FARIAS, J. dos P. NLScripts: composição assistida de scripts de testes a partir de

descrições em linguagem natural controlada. Dissertação (Mestrado) — UNIVERSIDADE
FEDERAL DE PERNAMBUCO, 2008.

FURKAN, A.; OVATMAN, T. Testing of web services using behavior-driven development.

Department of Computer Engineering, Istanbul Technical University, 2016.

GONZALEZ, M.; LIMA, V. L. S. de. Recuperação de informação e processamento da

linguagem natural. PUCRS, 2008.

GRAHAM, D.; VANS, I.; BLACK, R. FOUNDATIONS OF SOFTWARE TESTING. [S.l.]:

Thomson Learning, 2007.

GRAHAM, D.; VANS, I.; BLACK, R. Next Generation Java Testing: TestNG and
Advanced Concepts. [S.l.]: Cédric Beust and Hani Suleiman, 2016.

HALEBY, J. Testing REST Services in Java. 2011. Disponível em: <https://rest-assured.io/>.

Acesso em: 28 outubro 2022.
 27

HUNT, A.; THOMAS, D. Pragmatic Unit Test. [S.l.: s.n.], 2020.

INSTITUTE, S. The Scrum Product Backlog. 2016. Disponível em:

<Http://www.scruminstitute.org/>. Acesso em: 28 outubro 2022.

ISLAM, Q. N. Mastering PyCharm. [S.l.: s.n.], 2015.

MARCONI, M.; LAKATOS, M. Fundamentos de metodologia científica. [S.l.: s.n.], 2010.

MOULINIER, J. Natural language processing for online applications: Text retrieval, extraction
and categorization. John Benjamins Publishing, 2nd edition, 2007.

ONEDAYTESTING. GHERKIN: INTRODUZINDO SEUS CONCEITOS E BENEFÍ-

CIOS. 2019. Disponível em: <https://blog.onedaytesting.com.br/gherkin/>. Acesso em: 28
outubro 2022.

PERKINS, J. Python 3 Text Processing with NLTK 3. [S.l.: s.n.], 2012.

PINHEIRO, V.; VALENTIM, N.; VINCENZ, A. Um comparativo na execução de testes

manuais e testes de aceitação automatizados em uma aplicação web. Centro Universitário do
Norte–Laureate International Universities(UNINORTE), 2015.

PINTO, S. C. S. Processamento de Linguagem Natural e Extração de Conhecimento.

Dissertação (TrabalhoTese de Mestrado Engenharia Informática) — Faculdade de Ciências e
Tecnologias Universidade de Coimbra, 2008.

REOLON, C. Tfa: Um método para geração automática de scripts de teste funcional baseado
em userstories. Porto Alegre, 2020.

RICHARDSON, L.; RUBY, S. RESTful Web Services. [S.l.]: O’Reilly Media, 2007.

SALMAN, A. Test case generation from specifications using natural language processing.
KTH ROYAL INSTITUTE OF TECHNOLOGY, 2020.

SCHWABER, K.; BEEDLE, M. Agile software development with scrum. Prentice-Hall, 2002.

SCHWABER, K.; SUTHERLAND, J. The Scrum Guide. 2020. Disponível em:

<https://www.scrum.org/resources/scrum-guide>. Acesso em: 28 outubro 2022.

SINGH, A.; SHARMA, S. Functional test cases generation based on automated generated use
case diagram. International Journal of Innovative Research in Advanced Engineering,
2015.

SMART, J. BDD in Action. [S.l.: s.n.], 2014.

SOARES, M. D. S. Comparação entre metodologias Ágeis e tradicionais para o

desenvolvimento de software. Unipac - Universidade Presidente Antônio Carlos, 2005.

TREVISAN, T. B. APLICABILIDADE DO FRAMEWORK REST ASSURED

SOBRE UM WEB SERVICE DE UMA EMPRESA REAL. Dissertação (Mestrado) —
UNIVERSIDADE TECNOLOGICA FEDERAL DO PARANÁ, 2016.

VASILIEV, Y. Natural Language Processing with Python and spaCy: A Practical

Introduction. [S.l.: s.n.], 2003.
 28

APÊNDICE A – TABELA COMPLETA TESTE DE SIMILARIDADE

Tabela 9 – Resultado completo do Teste de Similaridade

Palavras GET POST PATCH DELETE
cadastro 0,2585 0,2777 0,2416 0,0986
consultar 0,3446 0,2462 0,2618 0,1054
buscar 0,3387 0,1575 0,1951 0,0485
pesquisar 0,3079 0,1705 0,2086 0,0661
inserir 0,2271 0,2757 0,2716 0,1894
criar 0,1974 0,3349 0,1971 0,1000
cadastrar 0,2502 0,3349 0,2736 0,1387
deletar 0,0821 0,1586 0,1657 0,3855
excluir 0,1921 0,2012 0,2055 0,2682
apagar 0,0427 0,0853 0,1128 0,3854
mudar 0,1282 0,1306 0,1816 0,1475
atualizar 0,2934 0,2605 0,3535 0,1734
alterar 0,1986 0,1994 0,2480 0,1968
trocar 0,1415 0,1425 0,2980 0,1745
consultando 0,3846 0,2392 0,2835 0,1059
cadastrando 0,2996 0,3255 0,2826 0,1419
deletando 0,1406 0,1722 0,2004 0,3486
alterando 0,2285 0,2123 0,2631 0,1800
Fonte: Elaborada pelo autor.