BR102014030880A2 - método para realização de testes automatizados - Google Patents

Abstract

método para realização de testes automatizados, na presente invenção o método provê um framework que facilita o desenvolvimento de cenários de teste automatizados, composto por ferramentas opensource e componentes que visam otimizar o esforço e o tempo na construção de um ambiente automatizado de testes de aplicativos para diferentes plataformas tecnológicas como web e mobile, abrangendo três níveis de testes: unitário, integração e sistêmico. este framework padroniza a execução de procedimentos de testes e facilita a implementação de robôs e scripts, pois utiliza abordagem de processos da qualidade em conjunto com componentes de fácil reutilização, constituindo uma estrutura flexível de fácil manutenção devido à reutilização de componentes e adaptação a novas tecnologias com pouco impacto. a solução atende à qualidade de software, realizando validação e verificação sistêmica em todo o ciclo de desenvolvimento, antecipando a descoberta de falhas e evitando um custo maior para a cadeia de desenvolvimento. uma das premissas deste framework é a padronização das atividades de testes, assim como a existência de uma estrutura comum de gerenciamento de dados de entrada, de resultados esperados e de tratamento de falhas, entre outros.

Description

“MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS” CAMPO DA INVENÇÃO

[0001] A presente invenção se aplica à área de desenvolvimento de software, mais especificamente no campo de automação de testes.

[002] Nas evoluções e manutenções de produtos há também uma grande aplicabilidade, cuja demanda de testes de regressão é alta, e a execução de teste manual geralmente é muito custosa.

TERMINOLOGIAS

[0003] Para melhor entendimento deste pedido de patente se faz premente definir algumas siglas, expressões e termos utilizados: [0004] Aplicativo Mobile - também conhecido como “app”, é um software desenvolvido para ser instalado em dispositivos eletrônicos móveis, tais como: PDA, telefone celular, smartphone e tablets.

[0005] Aplicativo Web - Sistemas informatizados, projetados para utilização por meio de navegadores, Internet e aplicativos desenvolvidos utilizando tecnologias Web.

[0006] API - Application Programming Interface (Interface de Programação de Aplicativos) - um conjunto de rotinas e padrões estabelecidos por um software para a utilização das suas funcionalidades por aplicativos que não pretendem envolver-se em detalhes da implementação do software, mas apenas usar seus serviços.

[0007] Camada de negócio - Camada de software onde ficam as funções e as regras de negócios.

[0008] Componente - Elemento de software que encapsula uma série de funcionalidades, normalmente criado de forma genérica e independente de sistemas, podendo ser reutilizável.

[0009] Dados de entrada - Informação solicitada para realizar um determinado processamento, muito utilizada em testes de sistemas que apresentam um resultado de acordo com a informação fornecida.

[0010] LOG - Registro de eventos relevantes num sistema computacional.

[0011] Robô - Script (aplicativo de software) construído para substituir pessoas na execução de testes.

[0012]XML - (eXtensible Markup Language) linguagem de marcação para codificação simples de sequências de dados em um arquivo eletrônico no formato texto-puro, capaz de ser lido tanto por pessoas quanto por máquinas computacionais.

DESCRIÇÃO DO ESTADO DA TÉCNICA

[0003] Hoje, o que existe disponível no mercado são arranjos de sistemas opensource para automação que não seguem integralmente os processos de testes. Também é conhecido o modelo “V”, ilustrado na figura 1, que demonstra como os níveis de testes devem ser aplicados em todo o ciclo de desenvolvimento do software.

[0014] Também são conhecidos alguns documentos de patentes que versam sobre a matéria em apreço, como o US 2007/0038890 A1 “Configurable System and Methods for Writing and Executing Test Components” em que os autores propõem uma arquitetura flexível e automatizada, que permite uma pluralidade de testes de componentes para que o teste seja executado em várias ordens, fornecendo uma API que determina o subconjunto dos testes, uma ordem de execução dos testes, ou uma resposta a falhas. Porém, o método não implementa um framework para gerar um ambiente de desenvolvimento de software com uma estrutura ampla e flexível que possibilite a execução de testes unitários, sistêmicos e de integração, com uso procedimental e simples, que dê suporte aos usuários com poucos conhecimentos em desenvolvimento de softwares e/ ou nos processos de testes, resultando em uma padronização do trabalho dos desenvolvedores de forma adequada e totalmente fiel aos processos de testes.

[0015] 0 US 2007/094543 A3 “Automated Software Testing Architecture Using a Muíti-Level Framework”, reivindica uma arquitetura de teste de software de um framework com estrutura multi-camadas com três níveis, sendo o primeiro nível de fonte de dados que especifica as páginas de teste, o segundo nível de fonte de dados especifica os casos de testes e o terceiro nível que especifica dados para os casos de testes. É um método capaz de testar cenários em múltiplos estágios e também incluir e salvar uma fonte de dados para uma entidade intermediária.

Neste documento anterior é apresentada uma invenção focada nesses três níveis, não havendo nenhum conflito com o método proposto que determina um framework com metodologia voltada aos processos de testes que seguem etapas pré-definidas para elaboração dos testes em um ambiente com estruturas reutilizáveis, com geração de evidências de testes configuráveis e padronizadas.

[0016] No documento US 2007/0168970 “Method and System for Automated Distributed Software Testing” são propostos métodos e sistemas para testes automatizados de software distribuído. Os testes automatizados podem contar com uma arquitetura distribuída que fornece uma estrutura padronizada para escrita de testes, agendamento dos testes, coleta e relatório de resultado dos testes. Porém, o método atua em software distribuído e a solução proposta abrange um universo de teste maior, que vai desde testes em aplicativos web até testes em aplicativos mobiles.

[0017] 0 US 2012/0290527 A1 “Data Extraction and Testing Method and System” é proposto um método para automação de testes de integração de dados e projetos business Intelligence, com extração, carga de dados e arquitetura de validação. Dessa forma, não existe conflito com o método do presente pedido, pois o mesmo não limita a automação dos testes aos tipos compreendidos no documento anterior. [0018jO KR 20080109361 “Framework” os autores citam a criação de uma plataforma para desenvolvimento web, para reduzir o tempo de desenvolvimento e o custo de operação, melhorando a manutenibilidade e facilitando extensões. Por se tratar de um framework para desenvolvimento de aplicações web, não há conflito ou comparação com o framework proposto que independe de tecnologia.

[0019jO CN 102541732 “Method for Constructing Web Automatic Testing Framework”, os autores citam a criação de um método para construção de testes automáticos na web, a partir de quatro passos. Esse framework não apresenta reivindicação que conflite com o framework proposto, por se tratar apenas de aplicação web, em uma linguagem específica (.NET) e que propõe a criação de um browser específico para que possa ser executado e controlado na máquina do cliente. Não propõe formas de documentação, controle e manutenção avançados.

[0020]0 WO 2009061703 “Automated Test Input Generation for Web Applications” é proposto uma forma automatizada de gerar testes baseados em aplicações web, usando-se o código, dados variáveis de entrada e resultados obtidos. Os testes vão se direcionando à novas situações e assim, gerando novas entradas. Difere-se completamente do framework proposto em que os fluxos são tratados programaticamente.

[0021 ]0 US 2009/089618 A1 “System and Method for Providing Automatic Test Generation for Web Applications” descreve um método de autogeração de massa de dados para execução de testes automatizados utilizando um modelo base. O framework apresentado não utiliza em sua estrutura o mecanismo ora reivindicado. Inclusive, a geração de massa de dados, que caracteriza os dados de entrada são realizados por analistas de testes, não de modo automático.

[0022]Q EP 2413259 A2 “Methods and Systems for Test Automation of Forms in Web Applications” descreve um método que acessa uma página que contém um formulário web e extrai o código de validação dos campos em relação aos dados inseridos. A partir da captação dessas validações, o teste consegue incluir dados pré-programados para execução dos testes automatizados, mapeando os campos da tela automaticamente. No framework ora desenvolvido não há utilização de nenhum método igual ou meramente parecido com o que este documento descreve. O mapa de interface, que no documento de anterioridade, é gerado automaticamente, no framework depende de um analista de testes que apoiado pelo uso de uma ferramenta opensource é capaz de mapear e identificar os campos da tela manualmente. A estruturação da massa de dados, assim como a ordem de execução dos testes também ficam sob responsabilidade do mesmo analista, seguindo o processo de testes. Desta maneira, a ideia proposta não apresenta qualquer semelhança com o documento de anterioridade analisado.

OBJETIVOS DA INVENÇÃO

[0004] Face ao exposto constitui um objetivo da invenção prover um método que implementa um framework para gerar um ambiente de desenvolvimento de software com uma estrutura ampla e flexível que possibilite a execução de testes unitários, sistêmicos e de integração.

[0024] A invenção também objetiva aumentar a produtividade e a qualidade dos projetos em desenvolvimento, incentivando a automatização de testes, diminuindo, assim, a necessidade de execução de testes manuais e permitindo execuções e regressões a qualquer momento.

[0025] 0utro objetivo da invenção é proporcionar uma estrutura componentizada, de uso procedimental e simples, que dê suportes a usuários com poucos conhecimentos em desenvolvimento de softwares el ou nos processos de testes, resultando em uma padronização do trabalho dos desenvolvedores de forma adequada e totalmente fiel aos processos de testes.

[0026] Mais um objetivo da invenção é a redução de custos de desenvolvimento e de implantação das aplicações, por meio da utilização de ferramentas opensource que permitam facilidades de manutenção, evolução e reutilização dos componentes criados.

[0027] É, ainda, um objetivo da invenção, a inovação que está na integração entre todos os softwares opensource que compõe o framework de automação de testes, de tal forma que os Scripts criados provejam integração contínua entre os softwares, possibilitando separá-los em componentes conforme suas funções.

DESCRIÇÃO GERAL DA INVENÇÃO

[0005] A invenção apresenta um framework para automação de testes que permite uso no desenvolvimento de produtos de softwares para garantir a qualidade, a automação dos testes nasce junto com o projeto de software desde o início, é tratada como um dos requisitos do projeto e todas as estruturas de desenvolvimento apresentam atividades preparatórias para a elaboração dos robôs de testes e execução dos mesmos.

[0029] A presente invenção contempla os processos de testes, partindo da gestão dos casos de testes e chegando à geração de evidências, logs e relatórios de execução.

[0030] 0 presente método se baseia no modelo “V” para extrair os cenários de testes automatizados, sendo que o planejamento dos testes é feito de cima para baixo e a execução realizada de baixo para cima. Este modelo ajuda a combater um problema que geralmente ocorre nos projetos de automação, em que o analista programador implementa os robôs de testes sem ter o entendimento funcional da aplicação como um todo, assim, muitos robôs são construídos sem um sentido que agregue na qualidade final, em que a aplicação deveria atender os requisitos definidos para o sistema e acabam realizando testes não efetivos para detecção das regras de negócios.

DESCRIÇÃO DOS DESENHOS

[0006] A invenção será melhor compreendida a partir da descrição detalhada que segue e das figuras que a ela se referem, em que: A FIG. 1 ilustra o modelo “V”. A FIG. 2 ilustra as etapas do framework. A FIG. 3 ilustra o modelo “V” utilizado na automação dos robôs. A FIG. 4 ilustra a arquitetura do framework - visão da construção.

A FIG. 5 ilustra a arquitetura do framework - visão da execução. DESCRIÇÃO DETALHADA DA REALIZAÇÃO DA INVENÇÃO

[0007] O framework de automação de teste reivindicado é voltado à introdução do teste automatizado desde o início de um projeto de software e contempla uma modelagem a cada etapa do projeto para dar suporte à automação. Todas as disciplinas participantes no projeto são consideradas para o sucesso da automação, entre elas os requisitos, a arquitetura, a implementação e testes.

[0008] O presente método segue etapas que atribuem à solução proposta um valor diferenciado do que existe atualmente, pois os processos de testes estão presentes como ponto forte no mecanismo desenvolvido, conforme ilustrado na figura 2.

[0034]Adicionalmente, este framework atende aos processos de testes dos modelos CMMI e da norma IEEE 829 para a qualidade de software. Esses modelos estão presentes no desenvolvimento de sistemas de software, utilizando os mais variados ciclos de vida de um projeto de produção tecnológica (iterativo, cascata e incrementai). Para todos esses ciclos de vida, estão previstas as atividades de requisitos, análise e desenho, implementação e testes, em que o modelo “V” combina bem com a dinâmica dos projetos de software na qual a presente invenção é passível de ser aplicada.

[0035] 0 framework é concebido a partir de cenários de testes de sistemas, baseados em requisitos, análise e desenho, sendo os mesmos modelados com foco em testes manuais e automatizados. Os cenários automatizados são os mesmos elaborados por analistas de testes, não havendo necessidade que um analista programador despenda tempo com essa atividade que não faz parte do seu perfil. Já os analistas de testes, em geral, têm facilidade para realizar a construção de robôs de teste utilizando o framework, conforme detalhado na etapa 4 da figura 2.

[0036] Desta forma, os cenários de teste passam a ser mais robustos, pois servem como requisitos para implementação dos robôs de testes que executarão os testes automatizados conforme ilustrado na figura 3.

[0037] 0s roteiros de testes gerados para o modelo “V” seguem os critérios para os níveis de testes unitário, integração e sistêmico.

[0038] As etapas de definição do plano de teste (1), especificação dos cenários de teste (2) e definição e elaboração da massa de dados (3) apresentadas na figura 2 constituem a base para a construção dos testes automatizados. Para a implementação dessas etapas, pode-se usar desde planilhas eletrônicas até ferramentas para gestão de testes dando suporte ao planejamento dos testes, execução e gerenciamento dos testes.

[0039] Etapa 1 - Definição do plano de teste - no início do projeto de software é definido um plano de teste com base no escopo dos requisitos. Nessa etapa inicial são planejados os tipos de testes e os níveis de testes que serão executados, assim como o tipo de teste automatizado a ser realizado, a definição do escopo da automação e o percentual de cobertura de testes automatizados.

[0040] 0 plano de teste recebe como insumo, o escopo de requisitos do projeto, que contempla a sua visão geral e funcionalidades.

[0041 ]Os principais itens compreendidos no plano de teste são: funcionalidades, tipos de testes (manuais e automatizados) e níveis de testes (funcional, integração e unitário), conforme descrito abaixo: ^Testes unitários ou teste de unidade - foco nos cenários de fluxo básico, considerando a especificação dos testes funcionais escritos pela equipe de teste de sistemas. Tem por objetivo testar a menor unidade do software, tentando provocar falhas de regra de negócio em pequenos trechos de código isoladamente. ^Teste de integração - foco na parte (componente) crítica, fluxos de integração com maior demanda, verificando falhas entre módulos e interfaces. ^Teste de sistema - foco nas funcionalidades estáveis que demandem teste de regressão ou em funcionalidades críticas que, se alteradas, podem propagar defeitos para outras funcionalidades. Os testes de sistemas têm como objetivo a avaliação do sistema como um todo, na visão de um usuário final. Nestes testes são inseridos dados reais e analisado se seus resultados atendem aos requisitos.

[0042] Para cada funcionalidade a ser testada são definidos o tipo, o nível de testes e o percentual de teste automatizado requeridos.

[0043] Nesta etapa também são elaborados os planos de execução de testes, a partir dos quais são obtidos os roteiros de testes, por tipo e nível de testes.

[0044] 0 plano de testes registra todas as rodadas de testes e os resultados associados, e leva em consideração os cenários de testes e a massa de dados de entrada tratados, respectivamente, pelas etapas de especificação de cenários de testes (2) e definição e elaboração de massa de dados (3).

[0045] Etapa 2 - Especificação dos cenários de testes - os cenários de testes são modelados conforme o modelo “V”. Esses cenários de testes são armazenados em um repositório para que sejam compartilhados pelos planos de execução, por exemplo, um plano de execução manual poderá contemplar o mesmo cenário de teste que um plano de execução automatizado.

[0046] Na elaboração dos cenários de testes, os analistas de testes definem se os cenários de testes serão reaproveitados para automação e indicam com uma marcação que o mesmo será executado automaticamente. Esses cenários contém todo o passo a passo para a execução dos testes, a massa de dados e os dados de entrada associados.

[0047] Etapa 3 - definição e elaboração de massa de dados - os analistas de teste avaliam os cenários de testes na etapa de especificação dos cenários de teste (2) e definem a massa de dados e os dados de entrada para cada teste. O framework disponibiliza estruturas adequadas para a realização da carga de massa de dados e layouts padronizados para entrada de dados.

[0048] Massa de dados - para a massa de dados, o framework apresenta uma estrutura de carga de massa de dados que realiza a leitura e a carga dos dados a partir de vários formatos de arquivos, tais como: CSV, TXT, XLS, XML, etc. Esses arquivos contemplam um layout pré-definido em que os dados são reconhecidos independentemente do formato do arquivo utilizado e carregados na base de dados. Nesta etapa, é papel do analista de testes montar essa massa de dados, utilizando a estrutura de carga de dados, sejam os dados elaborados pelo próprio analista de testes, ou mesmo extraídos de uma outra base de dados. Independente da origem dos dados, os mesmos deverão estar em um padrão estabelecido pelo framework e disponíveis no repositório de massa de dados do framework, para que sejam consumidos na execução dos testes, deixando o ambiente propício para verificação e validação.

[0049] Dados de entrada - os dados de entrada compõem uma estrutura de arquivos que contêm todas as informações a serem utilizadas na execução dos testes automatizados. Cada arquivo contém a identificação do elemento da tela web e a informação que deve ser utilizada neste elemento. O framework é capaz de utilizar os formatos TXT, XLS e XML para criação dos arquivos de entrada.

[0050] Esses formatos de arquivos foram selecionados pela facilidade de criação, de integração ao código dos robôs e de manutenção, já que podem ser geridos por ferramentas simples de edição de texto, além de exigirem pequeno espaço de armazenamento. Ainda tratando de armazenamento, são documentos que podem ser versionados por uma ferramenta de controle de versão, o que garante a homogeneidade dos dados para todos os integrantes da equipe técnica durante todo o processo da cadeia de desenvolvimento.

[0051] Estruturalmente são criados os casos de teste e, para cada um deles, seu robô de teste e seu arquivo de dados de entrada. Essa associação de 1 para n minimiza esforços em futuros retrabalhos, já que todos os robôs com os seus respectivos arquivos de entrada são identificados, o que delimita as estruturas a serem alteradas pelo analista de testes.

[0052] A fim de manter a rastreabilidade entre as estruturas de arquivos, cada arquivo de entrada recebe em seu título o mesmo nome do robô que irá executá-lo, assim como o identificador do caso de teste escrito na ferramenta de gerenciamento dos testes.

[0053] Etapa 4 - construção dos testes automatizados - nesta etapa, o foco está na construção de robôs, sendo que o framework disponibiliza um ambiente com uma estrutura de componentes que se adaptam a qualquer tipo de testes, pois possui componentes mandatórios que estão presentes na construção de todos os robôs e alternativos que são utilizados para determinadas tecnologias.

[0054] Além disso, o framework possui uma biblioteca evolutiva, que é realimentada a cada construção dos testes automatizados. Desta forma, a facilidade em operar o framework vai aumentando com o uso, já que os desenvolvedores vão incluindo novos elementos (rotinas de códigos, estrutura de dados, etc.) nas estruturas componentizadas das bibliotecas, tornando o processo dinâmico e progressivamente mais eficiente. Essa propriedade do framework permite que robôs mais simples poderíam ser feitos até por um analista de testes com pouca familiaridade com programação.

[0055] A seguir serão detalhados os demais componentes utilizados na construção dos robôs, conforme ilustrado na figura 4.

[0056] Mapa de interface - o mapa de interface descreve todas as telas do software a ser testado, identificando cada um dos seus campos, por meio de um código identificador, comumente chamado de ID, ou por um nome. Neste procedimento, a ordem de preenchimento destes campos pelos robôs é de suma importância.

[0057] Desta forma, a fim de identificar esses campos de modo simples e rápido, é utilizada uma ferramenta que provê a coleta e a gravação dos dados de uma aplicação em execução. Isto significa que a ferramenta é capaz de gravar a execução de ações realizadas pelo analista de testes em uma interface web, de modo que essa gravação possa ser visualizada quantas vezes forem necessárias. Em resumo, a ferramenta gera um vídeo com ações do usuário na tela do navegador, tais como: preenchimento de campos, seleção de opções em combo e confirmação de uma operação.

[0058] A coleta e a gravação dos dados em execução são sempre utilizadas preliminarmente à construção dos robôs, a fim de fornecer ao analista de teste todos os identificadores para programação do código de automação com segurança e rapidez. Inclusive, os campos identificados nesta etapa podem ser utilizados no detalhamento dos passos dos casos de testes.

[0059] Evidências - as evidências são coletadas durante a execução do teste e garantem que os resultados obtidos e registrados durante o teste sejam anexados na ferramenta de gerenciamento de testes. Como os testes são automatizados, no código dos robôs são criados eventos que disparam automaticamente, em momentos de execução específicos e importantes, a criação de vídeos ou captura de snapshots.

[0060] Cada evidência recebe como nome o mesmo identificador do caso de teste da ferramenta de gerenciamento de teste, e é armazenada no repositório do projeto. Além do mais, no registro do resultado do teste, é inserido em cada caso de teste o link de localização das respectivas evidências no repositório.

[0061 ]Logs - a principal função dos logs é o registro de execução dos testes. No momento em que são gerados são armazenados no repositório do projeto. A partir disto, assim que os resultados dos testes são registrados automaticamente na ferramenta de gerenciamento de teste, os logs já são referenciados na mesma ferramenta por meio de links o que permite ao analista consultar o log com rapidez quando na análise dos resultados.

[0062] 0 framework de automação está preparado para gerar os arquivos nas extensões XML e TXT.

[0063] A estrutura básica de informações obrigatórias do log é: s ID do teste - mesmo identificador do testlink. s Nome do teste - que inclusive deve ser o mesmo nome do robô. S Lista com resultado de cada passo do teste - OK e NOK. S Resultado da execução - OK e NOK. s Mensagens - sucesso e falha. s Ambiente de teste - nome do navegador, versão do navegador, sistema operacional, versão do sistema operacional e baseline. S Data e hora da execução. s Dados de entrada.

[0064] Resultado esperado - este módulo é importante para verificação do resultado do teste automatizado, os dados para análise do resultado estarão definidos neste módulo, de forma que para cada passo do teste em execução o seu resultado esperado esteja definido para que se possa realizar a comparação com o resultado obtido na execução. O conjunto de todos os resultados esperados de cada passo deverão estar corretos para que um resultado seja de sucesso (OK), caso contrário o teste é de falha (NOK).

[0065] Deixar o resultado esperado desacoplado do código de implementação dos robôs traz flexibilidade para reutilização dos robôs, pois com a alteração de dados de entrada e dos dados esperados um novo teste poderá ser realizado pelo mesmo robô. Neste cenário é possível utilizar um robô para executar n cenários de testes.

[0066] Robôs - o ambiente para a construção dos robôs traz facilidades e padronização, de forma que o código fica simples e bem estruturado. Com a utilização dos módulos o robô é implementado focando no fluxo que precisa seguir para reproduzir o teste automatizado. Neste cenário ele utiliza os módulos de massa de dados, entrada de dados, mapa de interface, resultado esperado, log e evidências que ficam disponíveis no ambiente.

[0067] Para construção, o ambiente também conta com uma biblioteca que disponibiliza componentes reutilizáveis modulares para atender as diversas tecnologias web, desktop, mobile, webservices, etc.

[0068] Alguns componentes são mandatórios para o tipo de tecnologia escolhida, eles contêm a estrutura pronta para a utilização dos módulos do framework e também métodos e funções aplicáveis no contexto de teste. Os componentes opcionais exploram funções específicas e são independentes da estrutura dos módulos do framework, dando a flexibilidade de criação de algoritmos otimizados para determinados testes.

[0069] 0 ambiente para a construção do robô é aplicável a qualquer tipo de tecnologia, pois não limita que o código seja feito utilizando o framework, apesar do ambiente induzir a utilização, já que muitas facilidades estão prontas e disponíveis para uso.

[0070] Biblioteca - é um módulo importante do framework, pois é nela que está o arcabouço para a construção dos robôs, contemplando desde métodos isolados a até componentes que contêm os variados arranjos de soluções para implementação dos cenários de testes.

[0071] Os desenvolvedores criam os métodos e os componentes e incluem de forma estruturada com as devidas documentações para que sejam reutilizadas com facilidade, tornando a biblioteca dinâmica. O ambiente do framework suporta essas bibliotecas e as deixa disponíveis para utilização. Elas são organizadas por tecnologia e portanto o ambiente pode ser ativado carregando somente a biblioteca da tecnologia selecionada.

[0072] A ideia é que sejam criadas APIS e estruturas que possam ser utilizadas como um verdadeiro template, onde o conteúdo específico será encorpado por quem entende do negócio e não necessariamente por um programador, pois com algumas configurações, a mesma poderá ser utilizada. Como exemplo, pode-se visualizar um template para testes de inclusão, exclusão, alteração e consulta em um cadastro web.

[0073] Controlador - tem a função de integrar todos os módulos, ele que é responsável pelo funcionamento do robô com os módulos e controla a execução de cada uma dessas partes. O roteiro de execução possui todas as configurações que o controlador suporta disponíveis para que sejam utilizadas.

[0074] Na estrutura do controlador, o roteiro de execução está montado, faltando somente às configurações que indicam quais são os módulos ativos para o teste. Ela não obriga que todos os módulos sejam usados, isso fica a cargo das configurações de ativar ou desativar um módulo para o robô de teste, trazendo flexibilidade para o framework.

[0075] Etapa 5 - construção do ambiente de teste automatizado - nesta etapa, o ambiente de teste automatizado é criado, o analista de teste faz o levantamento de toda a estrutura que deverá contemplar este ambiente, como máquinas, sistema operacional, banco de dados, etc. Ele deverá ser independente do ambiente de teste manual.

[0076] 0 framework fará uso da integração contínua, que será iniciada a cada build liberada pelo desenvolvimento, fazendo com que o robô seja executado automaticamente a cada novo pacote de executável disponibilizado no ambiente de desenvolvimento. E cada pacote liberado deverá possuir uma baseline associada para controle e rastreabilidade dos problemas detectados.

[0077] Uma ferramenta de integração contínua é recomendada nesta fase para que a integração seja feita, ela deverá ser capaz de integrar com a ferramenta de gerenciamento de teste, onde estão armazenados os roteiros de testes. A integração com o robô de teste sob execução possibilitará o sincronismo dos resultados obtidos na execução do robô com a ferramenta de gerenciamento, criando o ciclo completo de processamento dos testes.

[0078] Etapa 6 - execução e registro de resultado - o framework controla todas as execuções de rodadas dos testes automatizados e as armazena de acordo com as baselines. Os roteiros de testes contemplam o plano de execução e para cada cenário de testes um robô é disparado conforme a integração realizada com o controlador que coloca o robô sob execução, registrando o resultado do teste com os logs e evidências capturados.

[0079] Ao final de cada execução, o resultado obtido durante a execução é sincronizado por meio da integração entre a execução com a ferramenta de execução contínua e a ferramenta de gerenciamento dos testes. O resultado do teste é registrado no cenário de teste do plano de execução com a indicação de sucesso ou falha e as evidências e logs do passo a passo da execução são associados no cenário de teste para que fiquem disponíveis para consulta e auditoria.

[0080] A visão da execução implementa as etapas configuração do ambiente de teste automatizado (5), execução e registro de resultado e evidências (6) e gerenciamento dos testes (7), com a integração contínua disparando a execução e a integração entre o roteiro de teste para registrar o resultado na ferramenta de gerenciamento de testes, conforme apresentado na figura 5.

[0081] Etapa 7 - gerenciamento dos testes - o framework realiza a gestão dos testes pela ferramenta de gerenciamento de teste que foi realimentada em todas as etapas do teste automatizado. Ela disponibiliza relatórios e gráficos para análise do resultado e possibilita o acompanhamento da qualidade, registrando insumos que certificam que o sistema está atendendo ou não aos requisitos.

[0082] Durante a execução dos robôs na etapa execução e registro de resultado e evidências (6) foram coletados, logs, evidências e resultados dos testes, que foram registrados na ferramenta de gerenciamento, deixando a análise e o acompanhamento imediato e simples.

[0083] Nesta etapa pode-se ter a visão desde o requisito até o resultado da execução dos testes automatizados, pois o framework implementa a integração contínua dos testes e também a integração com a ferramenta de gerenciamento dos testes. A cada execução dos testes automatizados todos os seus registros são atualizados na ferramenta, possibilitando o gerenciamento dos testes automatizados.

[0084] Para acompanhamento e análise dos resultados são gerados vários relatórios, que a própria ferramenta de gerenciamento disponibiliza, detalhados abaixo: S Plano de teste - caderno de teste com todos os cenários de testes planejados para uma iteração do projeto. s Relatório de teste - relatório com o resultado da execução do plano de teste. s Matriz de resultados - relatório com o resultado de todas as rodadas de testes sob uma iteração do projeto. S Métricas gerais do plano de teste - relatório de métricas obtidas sob o status da última execução na iteração do projeto: o Resultado das métricas de teste por baseline. o Resultado pela suíte de teste, o Resultado dos testes de acordo com a prioridade. S Relatório de casos de teste com falha e não executados. •s Gráficos - métricas gerais do plano de teste - gráfico de pizza com todos os cenários de teste com status ‘passou’, com falha, bloqueados e não executados. •s Bugs por casos de teste - este relatório exibe todos os bugs abertos a cada cenário de teste.

REIVINDICAÇÕES

Claims (25)

1) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS, caracterizado por propor um framework para automação de testes introduzido desde o início de um projeto de software, que contempla uma modelagem a cada etapa do projeto para dar suporte a automação considerando todas as disciplinas entre elas os requisitos, a arquitetura, a implementação e testes; todas as estruturas de desenvolvimento apresentam atividades preparatórias para a elaboração dos robôs de testes e execução dos mesmos; o framework é concebido a partir de cenários de testes de sistemas, baseados em requisitos, análise e desenho, sendo os mesmos modelados com foco em testes manuais e automatizados.

2) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 1, caracterizado por etapas do framework consistirem de definição do plano de testes (1), especificação dos cenários de testes (2), definição e elaboração da massa de dados (3), construção dos testes automatizados (4), configuração do ambiente de teste automatizado (5), execução e registro de resultado e evidências (6) e gerenciamento de testes (7).

3) MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com as reivindicações 1 e 2, caracterizado por etapas de definição do plano de teste (1), especificação dos cenários de teste (2) e definição e elaboração da massa de dados (3) constituírem a base para a construção dos testes automatizados.

4) MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com as reivindicações 1, 2 e 3, caracterizado por etapa de definição do plano de teste (1) no início do projeto de software ser definido um plano de teste com base no escopo dos requisitos; na etapa inicial são planejados os tipos de testes e os níveis de testes que serão executados, assim como o tipo de teste automatizado a ser realizado, a definição do escopo da automação e o percentual de cobertura de testes automatizados; o plano de teste recebe como insumo, o escopo de requisitos do projeto, que contempla a sua visão geral e funcionalidades; para cada funcionalidade a ser testada são definidos o tipo, o nível de testes e o percentual de teste automatizado requeridos.

5) MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 4 caracterizado por etapa de definição do plano de teste (1) serem elaborados os planos de execução de testes, a partir dos quais são obtidos os roteiros de testes, por tipo e nível de testes; o plano de testes registra todas as rodadas de testes e os resultados associados, e leva em consideração os cenários de testes e a massa de dados de entrada tratados, respectivamente, pelas etapas de especificação de cenários de testes (2) e definição e elaboração de massa de dados (3); compreender no plano de teste: funcionalidades, tipos de testes (manuais e automatizados) e níveis de testes (funcional, integração e unitário).

6) MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 5, caracterizado por testes unitários ter foco nos cenários de fluxo básico; teste de integração ter foco na parte crítica, fluxos de integração com maior demanda, e teste de sistema ter foco nas funcionalidades estáveis que demandem testes de regressão ou em funcionalidades críticas.

7) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com as reivindicações 1, 2 e 3, caracterizado por etapa de especificação dos cenários de testes (2), os cenários de testes serem modelados conforme o modelo “V”; os cenários de testes são armazenados em um repositório para que sejam compartilhados pelos planos de execução.

8) MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 7, caracterizado por elaboração dos cenários de testes (2), os analistas de testes definirem se os cenários de testes serão reaproveitados para automação indicando com uma marcação que o mesmo será executado automaticamente; esses cenários contém todo o passo a passo para a execução dos testes, a massa de dados e os dados de entrada associados.

9) MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com as reivindicações 1, 2 e 3, caracterizado por etapa definição e elaboração de massa de dados (3), os analistas de teste avaliam os cenários de testes na etapa de especificação dos cenários de teste (2) e definem a massa de dados e os dados de entrada para cada teste.

10) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 9, caracterizado por uma a massa de dados, o framework apresentar uma estrutura de carga de massa de dados que realiza a leitura e a carga dos dados a partir de vários formatos de arquivos, tais como: CSV, TXT, XLS, XML; ser papel do analista de testes montar a massa de dados, utilizando a estrutura de carga de dados, sejam os dados elaborados pelo próprio analista de testes, ou mesmo extraídos de uma outra base de dados, em um padrão estabelecido pelo framework e disponíveis no repositório de massa de dados do framework, para que sejam consumidos na execução dos testes, deixando o ambiente propício para verificação e validação; os dados de entrada compõem uma estrutura de arquivos que contêm todas as informações a serem utilizadas na execução dos testes automatizados; cada arquivo contém a identificação do elemento da tela web e a informação que deve ser utilizada neste elemento; o framework é capaz de utilizar os formatos TXT, XLS e XML para criação dos arquivos de entrada; estruturalmente serem criados os casos de teste e, para cada um deles, seu robô de teste e seu arquivo de dados de entrada; cada arquivo de entrada receber em seu título o mesmo nome do robô que irá executá-lo, assim como o identificador do caso de teste escrito na ferramenta de gerenciamento dos testes.

11) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com as reivindicações 1 e 2, caracterizado por construção dos testes automatizados (4) o foco está na construção de robôs, sendo que o framework disponibiliza um ambiente com uma estrutura de componentes que se adaptam a qualquer tipo de testes.

12) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 11, caracterizado por um framework possuir uma biblioteca evolutiva, que é realimentada a cada construção dos testes automatizados, tornando o processo dinâmico.

13) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 1, caracterizado por utilizar os componentes na construção do robô: mapa de interface, evidências, logs, resultado esperado, robôs, biblioteca e controlador.

14) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 13, caracterizado por mapa de interface descrever todas as telas do software a ser testado, identificando cada um dos seus campos, por meio de um código identificador, comumente chamado de ID, ou por um nome; gerar uma ferramenta que provê a coleta e a gravação de dados de uma aplicação em execução; a gravação é realizada em uma interface web; a ferramenta gera um vídeo com ações do usuário na tela do navegador, tais como: preenchimento de campos, seleção de opções em combo e confirmação de uma operação.

15) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 13, caracterizado por evidências serem coletadas durante a execução do teste e garantindo que os resultados obtidos e registrados durante o teste sejam anexados na ferramenta de gerenciamento de testes; como os testes são automatizados, no código dos robôs são criados eventos que disparam automaticamente, em momentos de execução específicos e importantes, a criação de vídeos ou captura de snapshots.

16) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 13, caracterizado por uma principal função dos logs ser o registro da execução dos testes; assim que os resultados dos testes são registrados automaticamente na ferramenta de gerenciamento de teste, os logs já são referenciados na mesma ferramenta por meio de links; os logs apresentam a informação do ID do teste; nome do teste; lista com resultado de cada passo do teste; resultado de execução OK e NOK; mensagens de sucesso e falha; ambiente de teste com nome do navegador, versão do navegador, sistema operacional, versão do sistema operacional; data e hora de execução e dados de entrada.

17) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 13, caracterizado por resultado esperado ser importante para verificação do resultado do teste automatizado, os dados para análise do resultado estarão definidos neste módulo, de forma que para cada passo do teste em execução o seu resultado esperado esteja definido para que se possa realizar a comparação com o resultado obtido na execução; o resultado esperado fica desacoplado do código de implementação dos robôs trazendo flexibilidade para reutilização dos robôs.

18) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 13, caracterizado por módulo do robô ser implementado focando no fluxo que precisa seguir para reproduzir o teste automatizado; neste cenário ele utiliza os módulos de massa de dados, entrada de dados, mapa de interface, resultado esperado, log e evidências que ficam disponíveis no ambiente; alguns componentes são mandatórios para o tipo de tecnologia escolhida, eles contêm a estrutura pronta para a utilização dos módulos do framework e também métodos e funções aplicáveis no contexto de teste; os componentes opcionais exploram funções específicas e são independentes da estrutura dos módulos do framework, dando a flexibilidade de criação de algoritmos otimizados para determinados testes.

19) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 13, caracterizado por biblioteca estar o arcabouço para a construção dos robôs, contemplando desde métodos isolados a até componentes que contêm os variados arranjos de soluções para implementação dos cenários de testes; as bibliotecas são organizadas por tecnologia e portanto o ambiente pode ser ativado carregando somente a biblioteca da tecnologia selecionada.

20) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 13, caracterizado por um controlador ter a função de integrar todos os módulos, sendo responsável pelo funcionamento do robô com os módulos e controlar a execução de cada uma dessas partes.

21) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com as reivindicações 1 e 2, caracterizado por etapa de construção do ambiente de teste automatizado (5) o ambiente de teste automatizado ser criado, o analista de teste fazer o levantamento de toda a estrutura que deverá contemplar este ambiente, como máquinas, sistema operacional, banco de dados; este ambiente deverá ser independente do ambiente de teste manual; o framework faz uso da integração contínua, que será iniciada a cada build liberada pelo desenvolvimento, fazendo com que o robô seja executado automaticamente a cada novo pacote de executável disponibilizado no ambiente de desenvolvimento; cada pacote liberado possuir uma baseline associada para controle e rastreabilidade dos problemas detectados.

22) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com as reivindicações 1 e 2, caracterizado por etapa de execução e registro de resultado (6) o framework controlar todas as execuções de rodadas dos testes automatizados e as armazenar de acordo com as baselines.

23) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 22, caracterizado por roteiros de testes contemplarem o plano de execução e para cada cenário de testes um robô é disparado conforme a integração realizada com o controlador que coloca o robô sob execução, registrando o resultado do teste com os logs e evidências capturados; ao final de cada execução, o resultado obtido durante a execução ser sincronizado por meio da integração entre a execução com a ferramenta de execução contínua e a ferramenta de gerenciamento dos testes; o resultado do teste é registrado no cenário de teste do plano de execução com a indicação de sucesso ou falha e as evidências e logs do passo a passo da execução são associados no cenário de teste para que fiquem disponíveis para consulta e auditoria.

24) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com as reivindicações 1 e 2, caracterizado por na etapa gerenciamento dos testes (7) o framework realizar a gestão dos testes pela ferramenta de gerenciamento de teste que foi realimentada em todas as etapas do teste automatizado.

25) “MÉTODO PARA REALIZAÇÃO DE TESTES AUTOMATIZADOS”, de acordo com a reivindicação 24, caracterizado por disponibilizar relatórios e gráficos para análise do resultado e possibilita o acompanhamento da qualidade, registrando insumos que certificam que o sistema está atendendo ou não aos requisitos.