ferramenta para planejamento e controle de...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
FERRAMENTA PARA PLANEJAMENTO E CONTROLE DE
TESTES - SISCONTROLTEST
EDUARDO CESAR EBERLE
BLUMENAU
2014
2014/2-05
EDUARDO CESAR EBERLE
FERRAMENTA PARA PLANEJAMENTO E CONTROLE DE
TESTES - SISCONTROLTEST
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Sistemas
de Informação — Bacharelado.
Prof. Wilson Pedro Carli, Mestre – Orientador.
BLUMENAU
2014
2014/2-05
FERRAMENTA PARA PLANEJAMENTO E CONTROLE DE
TESTES - SISCONTROLTEST
Por
EDUARDO CESAR EBERLE
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
______________________________________________________
Presidente: Prof. Wilson Pedro Carli, Mestre – Orientador, FURB
______________________________________________________
Membro: Prof. Paulo Fernando da Silva, Mestre – FURB
______________________________________________________
Membro: Prof. Jacques Robert Heckmann, Mestre – FURB
Blumenau, 03 de dezembro de 2014.
Dedico este trabalho a todos os amigos e
familiares, especialmente aqueles que me
ajudaram diretamente na realização deste.
AGRADECIMENTOS
A Deus, por mostrar o caminho correto para atingir os meus objetivos.
À minha família, que sempre esteve presente.
Aos meus amigos, pelos incentivos e ajudas tão importantes para seguir em frente.
Ao meu orientador, professor Wilson Pedro Carli, por ter acreditado na conclusão
deste trabalho e pelas sugestões de melhorias para conclusão deste trabalho.
“Trabalhei muito para chegar ao sucesso, mas
não conseguiria nada se Deus não ajudasse.”
Ayrton Senna
RESUMO
Este trabalho apresenta uma ferramenta web para o planejamento e controle do processo de
automatização de testes de uma equipe de testes de uma empresa desenvolvedora de sistemas
aplicativos. A ferramenta tem como objetivo principal registrar os planos de testes e seus
respectivos casos de testes, possibilitando ao gerente de qualidade ter controle sobre os casos
de testes desenvolvidos para um produto da empresa. Para o desenvolvimento da ferramenta
utilizou-se a linguagem C#, armazenando-se as informações através do banco de dados SQL
SERVER. Com a disponibilização da ferramenta a empresa consegue ter um maior controle
sobre os planos de testes realizados e com seus casos de testes associados, também tendo
controle sobre o log de cada caso de teste, podendo ter os resultados destas execuções de
testes centralizadas em um único local.
Palavras-chave: Planejamento de testes. Controle de cenários de teste. Melhoria de Processo
de Teste Brasileiro (MPT.Br).
ABSTRACT
This paper presents a web tool that can be used to plan and control the automation tests by a
team of an application system developer company. This tool has as main objective to
registries the tests plans and the respective test cases, will allows to with the quality manager
to control the test cases developed to a company's product. To develop this tool it was used
the language C# and the information were stored in a SQL SERVER database. With the
availability of the tool, the company has a bigger control of the tests plans made with your
associated test cases having, also, access to the log of each test case, which allows to have the
results of these procedures centralized in the same database.
Key-words: Test Planning, Control of Test Scenarios. Brazilian Test Process Improvement.
(MPT.Br).
LISTA DE FIGURAS
Figura 1 - Ciclo de um processo de testes de software ............................................................. 16
Figura 2 - Ciclo de um planejamento para equipe de testes ..................................................... 17
Figura 3 - Ciclo de um controle sobre cenários de testes ......................................................... 18
Figura 4 - Relacionamento entre documentos de testes ........................................................... 20
Figura 5 - Tela de seleção de componente para ser utilizado no projeto.................................. 22
Figura 6 - Tela de verificação de objetos e suas propriedades ................................................. 22
Figura 7 - Exemplo de controle via planilha eletrônica............................................................ 24
Figura 8 - Tela de cadastro de planejamento de testes ............................................................. 25
Figura 9 - Tela de consulta de resultados executados .............................................................. 26
Figura 10 - Tela de cadastros de cenários e passos de testes .................................................... 27
Figura 11 - Tela de principal da ferramenta ............................................................................. 27
Figura 12 - Tela de cadastro de plano de testes na ferramenta ................................................. 28
Figura 13 - Tela de cadastro de casos de testes na ferramenta ................................................. 29
Figura 14 - Tela de cadastro de casos de projetos na ferramenta ............................................. 29
Figura 15 - Tela de cadastro de configuração MPT ................................................................. 30
Figura 16 - Tela de cadastro de projeto .................................................................................... 30
Figura 17 - Tela de cadastro de caso de teste ........................................................................... 31
Figura 18 - Diagrama de casos de uso ...................................................................................... 36
Figura 19 - Diagrama de atividades .......................................................................................... 37
Figura 20 - MER da ferramenta ................................................................................................ 38
Figura 21 - Tela da ferramenta Visual Studio 2013 ................................................................. 40
Figura 22 - Relação entre usuário com a ferramenta no padrão MVC ..................................... 41
Figura 23 - Estrutura do Bootstrap ........................................................................................... 45
Figura 24 - Estrutura de classes ................................................................................................ 46
Figura 25 - Entidades da ferramenta......................................................................................... 46
Figura 26 - Referência de DLL no pacote IntegracaoTestComplete ........................................ 47
Figura 27 - Referência da integração ........................................................................................ 47
Figura 28 - Arquivos COM para referência na integração ....................................................... 48
Figura 29 - Configuração da ferramenta TestComplete ........................................................... 49
Figura 30 - Tela de Login com validação ................................................................................. 50
Figura 31 - Tela inicial de administrador ................................................................................. 50
Figura 32 - Tela de gerência de grupos .................................................................................... 52
Figura 33 - Tela cadastro de configuração do sistema com validações .................................... 52
Figura 34 - Tela de cadastro de plano de teste com validações ................................................ 53
Figura 35 - Tela principal de casos de testes ............................................................................ 54
Figura 36 - Tela de cadastro de caso de teste com validação ................................................... 54
Figura 37 - Caso de teste impresso ........................................................................................... 56
Figura 38 - Tela principal de logs de execução ........................................................................ 57
Figura 39 - Tela de visualização do log de execução ............................................................... 58
LISTA DE QUADROS
Quadro 1 - Requisitos funcionais ............................................................................................. 33
Quadro 2 - Requisitos não funcionais ...................................................................................... 34
Quadro 3 - Regras de Negócio ................................................................................................. 35
Quadro 4 - Fragmento de código de um componente .............................................................. 41
Quadro 5 - Fragmento de código de um Controller ................................................................. 42
Quadro 6 - Fragmento de código de uma View ........................................................................ 42
Quadro 7 - Método de conexão com banco de dados ............................................................... 44
Quadro 8 - Código de chamada de relatório em PDF .............................................................. 45
Quadro 9 - Código da geração de gráfico de execuções de testes ............................................ 51
Quadro 10 - Fragmento código de execução da ferramenta TestComplete integrada.............. 55
Quadro 11 - Código de imprimir caso de teste em PDF ........................................................... 56
Quadro 12 - Fragmento de código da tela de logs de execução ............................................... 57
Quadro 13 - Código de download do arquivo de log ............................................................... 58
Quadro 14 - Comparando os trabalhos correlatos com o trabalho desenvolvido ..................... 60
Quadro 15 - Descrição dos casos de uso .................................................................................. 68
Quadro 16 - Dicionário de dados da tabela "UserProfile" ........................................................ 76
Quadro 17 - Dicionário de dados da tabela "webpages_Membership" .................................... 76
Quadro 18 - Dicionário de dados da tabela "webpages_OAuthMembership" ......................... 77
Quadro 19 - Dicionário de dados da tabela "webpages_Roles" ............................................... 77
Quadro 20 - Dicionário de dados da tabela "webpages_UsersInRoles" ................................... 77
Quadro 21 - Dicionário de dados da tabela "__MigrationHistory" .......................................... 77
Quadro 22 - Dicionário de dados da tabela "ConfiguracaoSistema" ........................................ 77
Quadro 23 - Dicionário de dados da tabela "PlanoTeste" ........................................................ 78
Quadro 24 - Dicionário de dados da tabela "CasoTeste" ......................................................... 78
Quadro 25 - Dicionário de dados da tabela "LogCasoTeste" ................................................... 79
Quadro 26 - Dicionário de dados da tabela "PlanoTeste_has_CasoTeste" .............................. 79
LISTA DE SIGLAS
ASP – Active Server Pages
C# – C Sharp
CRUD – Create Retrieve Update and Delete
CSS – Cascading Style Sheets
CTS – Common Type System
CMMI – Modelo de Maturidade em Capacitação Integração
DLL – Dynamic-link library
FK – Foreign Key
HTML – Hyper Text Markup Language
IEEE – Institute of Electrical and Electronic Engineers
MER – Modelo Entidade Relacionamento
MPT.BR – Melhoria do Processo de Teste
MVC – Model View Controller
OpenUp – Open Unified Process
ORM – Object-relational mapping
PDF – Portable Document Format
TCC – Trabalho de Conclusão de Curso
TI – Tecnologia da Informação
WPF – Windows Presentation Foundation
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15
2.1 PLANEJAMENTO DE TESTES ...................................................................................... 15
2.2 CONTROLE DE CENÁRIOS DE TESTE ....................................................................... 17
2.3 CASOS DE TESTES ......................................................................................................... 18
2.4 PADRÃO DE DOCUMENTAÇÃO IEEE 829 ................................................................. 19
2.5 MELHORIA DO PROCESSO DE TESTE BRASILEIRO (MPT.BR) ............................ 20
2.6 FERRAMENTA TESTCOMPLETE ................................................................................ 21
2.7 SISTEMA ATUAL ........................................................................................................... 23
2.8 TRABALHOS CORRELATOS ........................................................................................ 24
2.8.1 FERRAMENTA WEB DE APOIO AO PLANEJAMENTO E CONTROLE DE TESTE
DE SOFTWARE ............................................................................................................. 24
2.8.2 TEST-PLAN: FERRAMENTA DE APOIO AO PLANEJAMENTO E CONTROLE
DAS ATIVIDADES DO PROCESSO DE TESTES ...................................................... 26
2.8.3 FERRAMENTA DE APOIO A IMPLEMENTAÇÃO DO PROCESSO MELHORIA
DE PROCESSO DE TESTE (MPT) ............................................................................... 28
2.8.4 FERRAMENTA DE APOIO A IMPLEMENTAÇÃO DO PROCESSO MELHORIA
DE PROCESSO DE TESTE (MPT) – Extensão ............................................................ 29
3 DESENVOLVIMENTO DA FERRAMENTA ............................................................... 32
3.1 LEVANTAMENTO DE INFORMAÇÕES ...................................................................... 32
3.2 ESPECIFICAÇÃO ............................................................................................................ 33
3.2.1 Requisitos do sistema ...................................................................................................... 33
3.2.2 Diagramas de casos de uso .............................................................................................. 35
3.2.3 Diagramas de atividades ................................................................................................. 37
3.2.4 Modelo de Entidade e Relacionamento........................................................................... 38
3.3 IMPLEMENTAÇÃO ........................................................................................................ 39
3.3.1 Técnicas e ferramentas utilizadas .................................................................................... 40
3.3.1.1 Estrutura da Ferramenta................................................................................................ 46
3.3.1.2 Integrações com ferramenta TestComplete .............................................................. 47
3.3.1.3 Configuração da ferramenta TestComplete ............................................................. 48
3.3.2 Operacionalidade da implementação ............................................................................... 49
3.3.2.1 Tela de login ................................................................................................................. 49
3.3.2.2 Tela de cadastro de grupos ........................................................................................... 51
3.3.2.3 Tela de cadastro de configuração ................................................................................. 52
3.3.2.4 Tela de cadastro de plano de teste ................................................................................ 53
3.3.2.5 Tela principal do caso de teste ...................................................................................... 53
3.3.2.6 Tela principal logs de execução.................................................................................... 57
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 59
4 CONCLUSÕES .................................................................................................................. 62
4.1 EXTENSÕES .................................................................................................................... 63
REFERÊNCIAS ..................................................................................................................... 65
APÊNDICE A – Descrição dos Casos de Uso ...................................................................... 68
APÊNDICE B – Descrição do Dicionário de Dados ............................................................ 76
12
1 INTRODUÇÃO
Existe um reconhecimento por grande parte dos empresários de que investir em
qualidade faz com que os resultados sejam extremamente positivos. Não fazer nada, custa
caro e de tal modo que a imagem da qualidade dos produtos da empresa pode ser vinculada à
mesma (WEBER; ROCHA; NASCIMENTO, 2001). Desta forma, na área da Tecnologia da
Informação (TI) também deve-se investir em qualidade, principalmente quando o serviço é
direcionado para o desenvolvimento de software.
Para se manter a qualidade do software, uma das áreas a ser observada é a de testes de
software. Criar, reaproveitar e analisar testes previamente existentes, que fazem parte do
processo de planejamento, determina que se não conseguir rever o que se fez no passado,
através de uma ferramenta de automação, pouco adianta esta automação. Desta forma, pode-
se observar duas coisas: uma que existe a necessidade de poder rever o planejamento; e outra
que é também o resultado dos testes executados (MOLINARI, 2010).
O Plano de Teste é o documento que contém o projeto ou desenho lógico do
processo de testes e está alinhado com a estratégia de testes correspondente e nele
começam a serem delineados os casos de testes. Desta forma deve ser identificada a
qual estratégia de testes este plano de testes está associado. Este documento define
os objetivos gerais esperados e as expectativas do projeto de testes. (RIOS;
MOREIRA FILHO, 2006, pag. 62).
Os controles de testes são procedimentos, instruções e métodos relacionados ao teste
que são formalizados e controlados de forma a garantir uma maior qualidade do software.
Além disso, os resultados das atividades tornaram-se previsíveis e ações preventivas podem
ser realizadas a fim de evitar a ocorrência de problemas potenciais (INTHURN, 2001).
Apesar da importância das atividades de planejamento e controle de testes de
software, observa-se na literatura técnica da área de testes pouca importância dada a
elas. Poucas abordagens que apoiam a essas atividades são propostas, e normalmente
para um contexto específico, e um número mais reduzido ainda é aplicado na
indústria, caracterizando o estado da arte das atividades de planejamento e controle
de testes. (DIAS NETO; TRAVASSOS, 2006, pag. 250).
Segundo Heineberg (2008), a finalidade do caso de teste é identificar e comunicar
formalmente as condições específicas detalhadas que serão validadas para permitir a avaliação
de determinados aspectos dos itens do teste-alvo. Os casos de teste podem ser motivados por
vários fatores, mas normalmente incluirão um subconjunto dos requisitos e dos riscos
envolvidos no projeto.
13
As falhas em um software podem ser observadas quando se determinam um
conjunto de dados específicos, denominados de casos de testes. O teste bem
sucedido é aquele composto por casos de teste para os quais o programa em teste
falhe. (MYERS, 2004, pag. 43).
Afirma Molinari (2010) que, quando refere-se à gerência de testes é englobado o
processo, isto é, automatizar a gerência significa também automatizar o processo de testes, ou
o controle do processo que gira em torno de uma ferramenta para casos de testes. Algumas
ferramentas precisam ser ajustadas e customizadas para atender o processo. Em outras ocorre
justamente o contrário, a empresa é que se adapta ao processo proposto pela ferramenta.
Os processos abrangem a preparação, a execução e o registro dos resultados de testes.
Esses processos estabelecem uma orientação geral e, se necessário, podem ser modificados
para adequar-se às situações particulares de organização envolvidas nas atividades de testes
conforme a norma de padrão 829 para documentação de testes de software do Institute of
Electrical and Electronic Engineers (IEEE) de número 829 (IEEE 829) (CRESPO, 2008).
Para normatização destes processos tem-se a Associação para Promoção da Excelência
do Software Brasileiro (SOFTEX), que tem como um dos seus objetivos aumentar a qualidade
dos produtos de software, através da otimização e melhoria contínua dos processos de testes.
Com isto pode-se fornecer visibilidade relativa à maturidade do processo de teste de uma
organização para o mercado do software e, por fim, fomentar a melhoria contínua dos
processos de testes no âmbito do desenvolvimento de software de acordo com o processo de
Melhoria de Processo de Teste Brasileiro (MPT.Br) (ASSOCIAÇÃO PARA PROMOÇÃO
DA EXCELÊNCIA DO SOFTWARE BRASILEIRO, 2010a).
Sendo assim, a atividade de teste de software vem recebendo uma maior atenção das
empresas de desenvolvimento de software. Os clientes destas empresas não aceitam receber
softwares com problemas de usabilidade, visual desagradável e principalmente que
apresentem erros em suas funcionalidades durante a sua utilização. Isto faz com que as
empresas desenvolvedoras invistam em metodologias e softwares que auxiliem as atividades
de testes de software.
14
1.1 OBJETIVOS DO TRABALHO
O objetivo geral deste trabalho é apresentar o desenvolvimento de uma ferramenta que
auxilie o gestor de qualidade no gerenciamento de testes.
Os objetivos específicos do trabalho são:
a) permitir ao gestor de qualidade gerenciar os processos de testes internos;
b) disponibilizar interface web aos analistas de testes para o acompanhamento dos
processos de testes vinculados aos cenários de testes;
c) armazenar os históricos de execuções de testes;
d) manter as informações sobre os planos de testes;
e) guardar as informações sobre os casos de testes;
f) integrar a ferramenta desenvolvida com a ferramenta TestComplete.
1.2 ESTRUTURA DO TRABALHO
No primeiro capítulo tem-se a introdução ao tema principal deste trabalho com a
apresentação da justificativa e dos objetivos.
No segundo capítulo apresenta-se a fundamentação teórica pesquisada sobre
planejamento de testes, controle de cenários de testes, casos de testes, padrão de
documentação IEEE 829, melhoria do processo de teste brasileiro (MPT.BR), a ferramenta
TestComplete, o sistema atual e os trabalhos correlatos.
O terceiro capítulo apresenta o desenvolvimento da ferramenta iniciando-se com o
levantamento de informações, tendo na sequência a especificação, os requisitos do sistema, a
operacionalidade do sistema, encerrando com os resultado e discussões.
No quarto capítulo tem-se as conclusões deste trabalho bem como apresentam-se
sugestões para trabalhos futuros.
15
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda os assuntos sobre o planejamento de testes, o controle de cenários
de testes, os casos de testes, o padrão de documentação IEEE 829, a Melhoria de Processo de
Teste Brasileiro (MPT.Br), a ferramenta TestComplete, o sistema atual, além de trabalhos
correlatos.
2.1 PLANEJAMENTO DE TESTES
Planejamento de testes é um processo e plano de teste é o resultado prático desse
planejamento que é seu fruto e artefato (MOLINARI, 2003). Através de um planejamento
detalhado de todas as fases a serem executadas durante o processo de teste, obtêm-se
resultados mais confiáveis, impactando diretamente em um produto melhor testado e de
melhor qualidade (INTHURN, 2001).
O processo de testes de software representa uma estruturação de etapas, atividades,
artefatos, papéis e responsabilidades que buscam a padronização dos trabalhos e ampliar a
organização e o controle de projetos de testes. O processo de teste, como qualquer outro
processo deve ser revisto continuamente, de forma a ampliar sua atuação e possibilitar aos
profissionais uma maior visibilidade e organização dos seus trabalhos, o que resulta em uma
maior agilidade e controle operacional dos projetos de testes (BARTIÉ, 2007).
Na Figura 1 apresenta-se o processo de testes em software completo. Conforme a
legenda apresentada na Figura 1, visualiza-se onde são informados os caminhos críticos e não
críticos de um processo de teste. O plano de teste é realizado pelo gestor conforme a
criticidade ou complexidade do cenário de teste sobre o produto a ser testado. Em seguida faz-
se a especificação dos testes. Após é elaborada a modelagem dos testes. Depois é realizada a
preparação do ambiente. Posteriormente a execução dos testes e a análise dos resultados são
executados em paralelo. Se houver novo ciclo no caso de teste, irá retornar para a preparação
do ambiente novamente ou caso contrário irá finalizar o processo de testes com o
encerramento dos processos.
16
Figura 1 - Ciclo de um processo de testes de software
Fonte: Adaptado de Bartié (2007).
No planejamento de testes, conforme mostrado na Figura 2, é dimensionada a
quantidade de esforço que a equipe terá que desempenhar para entregar um produto com
maior qualidade, menor custo e com maior agilidade para executar os processos do sistema. O
coordenador de testes faz o estudo do projeto, a definição de cenários e a aprovação do
planejamento. O líder de testes e o arquiteto de testes fazem parte de um grupo de estimativas
de testes no qual fazem uma avaliação de impacto, a análise interna e externa de esforço.
17
Figura 2 - Ciclo de um planejamento para equipe de testes
Fonte: Adaptado de Bartié (2007).
O processo de teste possui entradas, saídas, atividades internas ao processo e papéis
aos quais são englobados em uma gerência de projetos de testes para a equipe de testes.
2.2 CONTROLE DE CENÁRIOS DE TESTE
O controle dos testes é responsável por garantir que as informações e
atividades descritas durante o planejamento sejam realizadas conforme o planejado, em caso
de mudanças, que elas sejam relatadas às pessoas envolvidas nas atividades de teste. O
controle dos testes também é responsável pelo registro dos eventos e incidentes ocorridos
durante os testes e, com isso, possibilita a re-execução dos testes após modificações no
produto (DIAS NETO, 2006).
A indisponibilidade de ferramentas adequadas para gestão das atividades de teste é um
dos principais problemas enfrentados pelas equipes de testes de software (WEBER, 2001).
Na Figura 3, mostra-se um ciclo de controle sobre os cenários de testes. O ciclo inicia
com a criação de uma hipótese, que pode ser uma eventual falha no produto. Depois passa-se
a planejar cenários sobre esta hipótese. Em seguida aplicam-se os testes e observam-se os
resultados. Depois, avaliam-se os resultados contra a hipótese levantada, a qual é comprovada
ou não.
18
Figura 3 - Ciclo de um controle sobre cenários de testes
Fonte: Veenendaal (2010).
As estratégias que apoiam o planejamento e controle de testes de software aplicadas na
indústria refletem-se, atualmente, em tentativas individuais de implantar ou mesmo melhorar
o processo de testes utilizado. No teste de software é verificada a existência de uma grande
distância entre o que é desenvolvimento na comunidade acadêmica e o que é utilizado em
organizações de desenvolvimento de software (BERTOLINO, 2004).
2.3 CASOS DE TESTES
Segundo Rios e Moreira Filho (2006), a partir do objeto (ou parte do sistema) definido
no plano de teste devem ser elaborados os casos de testes. O caso de teste desce ao nível de
detalhe de campos de formulários, arquivos, telas, páginas e outros. Desta forma, cada item de
teste deve ter um critério de avaliação e de teste. Deve também ser identificado o plano de
testes que deu origem a cada caso de teste.
Ao tratar de programas de computador, o número de possibilidades a serem
verificadas pode atingir facilmente uma cifra astronômica. Cada teste de função, contendo um
conjunto de entradas diferentes com um único valor é chamado de caso de teste
(KOSCIANSKI; SOARES, 2006).
19
A identificação dos casos de teste serve de base para o projeto e o desenvolvimento
dos procedimentos de teste. A perfeição do teste pode ser medida através da média do teste,
onde pode-se obter o número de casos de testes identificados versus o número de casos de
teste implementados (INTHURN, 2001).
É necessário que haja algum tipo de avaliação contínua dos casos de testes para
verificar o andamento e a eficácia. Considera-se uma cobertura de teste baseada em requisitos,
em que cada caso de teste pesquisa pelo menos uma hipótese de teste e um requisito de
sistema.
2.4 PADRÃO DE DOCUMENTAÇÃO IEEE 829
A norma do Institute of Electrical and Electronic Engineers (IEEE) de número 829
(IEEE-829) está atualmente na versão 2008 e a mesma trata sobre padrões de software e
sistema para documentação de testes. Já a sua versão de 1998, trazia um modelo que define o
padrão de documentação onde as informações serão registradas (KOSCIANSKI; SOARES,
2006).
Um plano de testes da IEEE-829 deve conter em seu padrão campos como o
identificador, a introdução, os itens de testes, as funcionalidades a serem testadas, as
funcionalidades a não serem testadas, a abordagem de teste, os critérios de término dos testes,
os critérios de suspensão dos testes, as entregas, as tarefas, os ambientes, as
responsabilidades, os treinamentos, o cronograma, os riscos e as aprovações (RIOS, 2007).
Ainda, segundo Rios (2007), o caso de teste da IEEE-829 deve conter os campos
identificadores, os itens de testes, as especificações de entrada, as especificações de saída, as
necessidades de ambiente, os requisitos e as dependências entre os casos de testes. O
propósito do caso de teste é definir uma unidade de teste que será executada pelo testador,
seja manualmente ou automaticamente (RIOS, 2007). Na Figura 4, mostra-se um
relacionamento entre os documentos de testes. O processo inicia-se pela preparação do teste,
depois é executado o teste e são realizados os registros dos testes.
20
Figura 4 - Relacionamento entre documentos de testes
Fonte: Crespo (2008).
Os processos não trazem bons resultados quando não possuem documentos
padronizados para que todos profissionais sigam as mesmas premissas (RIOS, 2007).
As empresas utilizam processos de documentação internos semelhantes a IEEE 829 e
padrões de documentações que serão utilizados neste trabalhado para o desenvolvimento de
telas, documentos e relatórios.
2.5 MELHORIA DO PROCESSO DE TESTE BRASILEIRO (MPT.BR)
O MPT.Br é um modelo para Melhoria do Processo de Teste concebido para apoiar as
organizações através dos elementos essenciais para o desenvolvimento da disciplina de teste
no processo de desenvolvimento de software (ASSOCIAÇÃO PARA PROMOÇÃO DA
EXCELÊNCIA DO SOFTWARE BRASILEIRO, 2010a).
A ideia do MPT.Br foi a criação de um modelo para avaliação da maturidade das áreas
de teste de software compatível, mas não necessariamente igual, com o modelo do Processo
21
de Melhoria de Software Brasileiro (MPS.BR), embora totalmente voltado para área de teste
de software (ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO, 2010b).
Segundo Couto (2007), estudos sobre a qualidade no setor de software brasileiro
mostram a necessidade de um esforço significativo capaz de aumentar a maturidade dos
processos de software das empresas brasileiras.
A melhoria do processo passa por envolver a documentação, os processos de testes
internos e os testes respectivamente, inclusive com os testes automatizados onde grande parte
das empresas mantém em separados do processo de documentação, como os casos de testes
que ficarão armazenados na ferramenta desenvolvida.
2.6 FERRAMENTA TESTCOMPLETE
Uma ferramenta de automação é essencial para que os testes funcionais e de regressão
possam ser feitos com eficiência e eficácia (RIOS; MOREIRA, 2006). Sendo assim, o
TestComplete é um ambiente de testes automatizados para uma ampla gama de tipos de
aplicativos e tecnologias, incluindo (mas não limitado) a do Windows, plataforma da
Microsoft para o desenvolvimento de aplicação web (.NET), Windows Presentation
Foundation, que é um conjunto de classes do .NET (WPF), Visual C++, Visual Basic, Delphi,
C++ Builder, Java e web aplicações (SMARTBEER, 2012).
Na Figura 5, mostra-se uma das principais telas da ferramenta TestComplete. Ao criar
um projeto dentro da ferramenta TestComplete, pode-se selecionar um tipo de projeto e
também uma linguagem de programação.
22
Figura 5 - Tela de seleção de componente para ser utilizado no projeto
Fonte: Qualister (2012).
Na Figura 6, mostra-se uma tela de verificação de objetos do sistema. Nesta tela pode-
se utilizar algumas funcionalidades da ferramenta TestComplete para verificação de
propriedades dos componentes do produto que está sendo automatizado.
Figura 6 - Tela de verificação de objetos e suas propriedades
Fonte: Qualister (2012).
23
2.7 SISTEMA ATUAL
Em uma empresa desenvolvedora de sistemas aplicativos do ramo público, utilizam-se
planilhas eletrônicas para guardar os cenários de testes automatizados, sendo que um analista
de testes é quem alimenta essas planilhas. As planilhas eletrônicas são criadas conforme os
módulos dos produtos a terem seus testes automatizados com suas principais funcionalidades,
as quais servem para controle das funcionalidades que estão sendo desenvolvidas. Os casos de
testes para automatização são documentados em formato do editor de texto Word, utilizando-
se um padrão de casos de testes. Para os casos de testes que necessitam serem testados
manualmente, são utilizadas as planilhas de controle das funcionalidades, que necessitam
serem testadas e atualizadas, caso houver a modificação de algum requisito.
A empresa desenvolvedora não conta com um controle que possua alguma referência
sobre quais os casos de testes foram automatizados com relação aos casos de testes
documentados. Estas documentações ficam separadas em servidores correndo o risco de
serem perdidos caso não houver a realização de backups. Os projetos de automatização
também ficam alocados em outros servidores que são diferentes dos servidores da
documentação.
As planilhas eletrônicas também são alocadas em servidores, mas as mesmas só
controlam as funcionalidades desenvolvidas na automatização. Estas planilhas não trazem as
informações de controle sobre qual a documentação que teve como referência a
funcionalidade desenvolvida.
Com a falta de controle destes testes automatizados os gestores não tem como medir o
que está sendo feito de automatização sobre os produtos. Os gestores também não tem como
mostrar os resultados para a diretoria do que está sendo desenvolvido de testes sobre os
produtos e com isto trazendo pouca confiabilidade. A falta de informações em relação ao que
se está automatizando está gerando retrabalho de rotinas. Os testes muitas vezes estão sendo
executados mais que uma vez, sendo que a automatização de algumas rotinas do sistema já
foram realizadas. Isto faz com que os analistas não se concentrem em testes mais específicos
dos produtos gerando uma falta de controle repetindo os mesmos testes já desenvolvidos na
ferramenta de automação.
Na ferramenta TestComplete são desenvolvidos os casos de testes de acordo com o
documento do cenário de teste e estes cenários são executados diariamente para verificação de
possíveis falhas nos produtos. Na Figura 7, mostra-se um exemplo de controle de cenários
24
automatizados realizados pelos testadores e enviado ao gerente de qualidade, a fim de que
esse analise o que foi produzido nos testes.
Figura 7 - Exemplo de controle via planilha eletrônica
2.8 TRABALHOS CORRELATOS
Nesta seção são apresentados trabalhos com características semelhantes às da
ferramenta deste trabalho.
2.8.1 FERRAMENTA WEB DE APOIO AO PLANEJAMENTO E CONTROLE DE
TESTE DE SOFTWARE
Bonecher (2008) apresenta uma ferramenta aplicada à empresa Dynamix Software. A
ferramenta desenvolvida visa auxiliar no planejamento e controle de testes de integração. Foi
proposto também um novo processo para empresa, baseado em Open Unified Process
25
(OpenUp) que é um processo unificado aberto sendo uma metodologia ágil de
desenvolvimento de software. A ferramenta contempla as etapas de planejamento e controle,
automatizando as atividades e artefatos do processo. Também incorpora padrão IEEE 829
para documentação de testes de software (IEEE 829) especificando a forma de uso através de
estágios de teste de software. Na implementação utilizou-se a ferramenta Codecharge Studio
3.0, que era a tecnologia adotada na empresa.
Na Figura 8 mostra-se uma tela de cadastro principal de planejamento de testes, na
qual pode-se cadastrar os casos de teste com principais dados necessários para execução do
cenário e com os itens do caso de testes com seus passos.
Figura 8 - Tela de cadastro de planejamento de testes
Fonte: Bonecher (2008).
Na Figura 9 mostra-se uma tela de consulta de resultados executados dos cenários de
testes. Podem-se realizar consultas de quem realizou a execução do cenário de testes,
consultar pelo responsável ou pela data do resultado e buscar quais casos de testes foram
executados.
26
Figura 9 - Tela de consulta de resultados executados
Fonte: Bonecher (2008).
2.8.2 TEST-PLAN: FERRAMENTA DE APOIO AO PLANEJAMENTO E CONTROLE
DAS ATIVIDADES DO PROCESSO DE TESTES
O Trabalho de Conclusão de Curso (TCC) de Camila Labes é uma ferramenta que foi
aplicada à empresa HBSIS. A ferramenta foi desenvolvida para auxiliar os processos de testes
como recursos, casos de testes e apoiar as atividades gerenciais da área de qualidade da
empresa. Na implementação foi desenvolvida uma exportação de casos de uso para a
ferramenta proposta gerando cenários de testes. A ferramenta foi desenvolvida na linguagem
C# / ASP.NET sobre a plataforma Microsoft (LABES, 2010).
Na Figura 10 mostra-se uma tela de cadastro de cenários e passos de testes. Nesta tela
pode-se cadastrar os cenários detalhadamente com suas funcionalidades, pré-condições e seus
passos a serem executados em sequência (LABES, 2010).
27
Figura 10 - Tela de cadastros de cenários e passos de testes
Fonte: Labes (2010).
Na Figura 11 mostra-se uma tela principal com todas as funcionalidades da
ferramenta, onde são configurados para qual sistema e módulo que serão desenvolvidos os
casos de testes.
Figura 11 - Tela de principal da ferramenta
Fonte: Labes (2010).
28
2.8.3 FERRAMENTA DE APOIO A IMPLEMENTAÇÃO DO PROCESSO MELHORIA
DE PROCESSO DE TESTE (MPT)
Amorim (2011) apresenta a ferramenta que foi desenvolvida no estudo sobre do
modelo Melhoria de Processos de Testes Brasileiros (MPT.BR) baseando-se em processos de
outros modelos como Capability Maturity Model Integration (CMMI) e Melhoria de
Processos de Software (MPS.BR) voltado para o processo de teste. O software foi voltado
para empresas pequenas que não querem investir com altos valores para implantar um modelo
de processo de testes e também utiliza-se do padrão de documentação de testes internacional
(IEEE-829). A ferramenta foi implementada em forma de plug-in que é um módulo de
extensão para adicionar funções para outra ferramenta de desenvolvimento chamada Eclipse,
com intuito de apoiar a gerência de projetos de testes e gerência de requisitos de acordo com
MPT.BR.
Na Figura 12 mostra-se um cadastro de plano de testes informando os dados
necessários para o plano de teste ser executado pela equipe.
Figura 12 - Tela de cadastro de plano de testes na ferramenta
Fonte: Amorim (2011).
Na Figura 13 mostra-se um cadastro de casos de testes informando pré-condições,
passos, resultado esperado e requisitos.
29
Figura 13 - Tela de cadastro de casos de testes na ferramenta
Fonte: Amorim (2011).
Na Figura 14 mostra-se um cadastro de casos de projetos de testes no qual serão
associados aos produtos que necessitam ser testados.
Figura 14 - Tela de cadastro de casos de projetos na ferramenta
Fonte: Amorim (2011).
2.8.4 FERRAMENTA DE APOIO A IMPLEMENTAÇÃO DO PROCESSO MELHORIA
DE PROCESSO DE TESTE (MPT) – Extensão
Bertolini (2014) é uma extensão da ferramenta desenvolvida por Amorim (2011). Em
forma de plug-in para o Eclipse, a ferramenta ajuda na gerência de projetos de teste aderentes
30
ao MPT.BR versão 3.1, através da automatização de algumas áreas dos três níveis do processo
pesquisado. Na Figura 15 mostra-se um cadastro de configuração MPT da ferramenta onde
são informados dados necessários para a parametrização do plug-in.
Figura 15 - Tela de cadastro de configuração MPT
Fonte: Bertolini (2014).
Na Figura 16 mostra-se um cadastro de projeto podendo informar dados que serão
utilizados no plano de teste.
Figura 16 - Tela de cadastro de projeto
Fonte: Bertolini (2014).
31
Na Figura 17 mostra-se um cadastro de caso de teste informando o detalhamento sobre
cada cenário de teste.
Figura 17 - Tela de cadastro de caso de teste
Fonte: Bertolini (2014).
Os quatro trabalhos apresentados correlacionam-se com este trabalho, no sentido de
que todos são aplicados à melhoria de processos de software e ou a melhoria de processos de
testes de software. Não será utilizado neste trabalho a metodologia de Open Unified Process
(OpenUp) que foi proposto no trabalho correlato de Bonecher (2008). Também não irá se
relacionar com nenhuma ferramenta de caso de uso. Será utilizado um padrão semelhante a
norma IEEE-829 de documentação com campos principais necessários para a empresa sobre o
caso de teste.
Este trabalho é proposto para atender à necessidade específica de uma empresa
desenvolvedora de sistemas aplicativos, acoplando-se a ferramenta à desenvolvida ao que já é
utilizado dentro da empresa, ou seja, a ferramenta TestComplete.
32
3 DESENVOLVIMENTO DA FERRAMENTA
Neste capítulo estão descritas as particularidades técnicas desta ferramenta tais como o
levantamento de informações, a especificação de seu funcionamento com os requisitos
funcionais e não funcionais, o diagrama de casos de uso, o diagrama de atividades e o modelo
entidade-relacionamento. Na implementação apresentam-se as técnicas e ferramentas
utilizadas, bem como a operacionalidade da ferramenta, encerrando-se com os resultados e
discussões.
3.1 LEVANTAMENTO DE INFORMAÇÕES
A finalidade deste trabalho é o desenvolvimento de uma ferramenta para planejamento
e controle de cenários de testes automatizados para auxiliar os gestores de qualidade de
software a terem uma organização e um processo definido sobre o desenvolvimento dos casos
de testes. Ela possibilitará o cadastro das informações sobre os casos de testes, detalhando
seus processos necessários a serem realizados para chegar aos resultados esperados, assim
como o cadastro de seu plano de testes, detalhando o objetivo do mesmo.
Será possível executar, através da ferramenta, os cenários desenvolvidos no
TestComplete. Após esta execução, serão importados automaticamente os resultados e pode-
se gerar relatórios sobre estes resultados. A exportação do resultado de execução será
realizada automaticamente pela ferramenta TestComplete ao finalizar. A TestComplete
utiliza-se de uma funcionalidade interna de exportação de log da execução, guardando os
resultados para poder fazer download, além de ter o controle de execuções na própria
ferramenta desenvolvida, podendo abrir o mesmo em um browser qualquer. Na ferramenta
desenvolvida também será possível cadastrar os grupos de usuários. Pode-se adicionar aos
usuários seus respectivos grupos que em primeiro momento seriam o administrador, o gestor
de qualidade e o analista de teste.
Para a construção da ferramenta de planejamento e controle de testes foram utilizadas
as seguintes ferramentas:
a) Visual Studio, linguagem C# como ferramenta de desenvolvimento;
b) SQL Server como servidor de banco de dados;
33
c) ferramenta TestComplete, para a realização da integração.
3.2 ESPECIFICAÇÃO
Nesta seção apresenta-se o diagrama de caso uso, assim como o diagrama de
atividades e o modelo de entidade de relacionamento, sendo que o detalhamento dos
principais casos de uso está descrito no Apêndice A.
3.2.1 Requisitos do sistema
O Quadro 1 apresenta os requisitos funcionais previstos para a ferramenta e sua
rastreabilidade, ou seja, sua vinculação com o(s) caso(s) de uso associado(s).
Quadro 1 - Requisitos funcionais
Requisitos Funcionais Caso de Uso
RF01: A ferramenta deverá permitir ao administrador efetuar login. UC01
RF02: A ferramenta deverá permitir ao administrador manter o cadastro de
grupo de usuários e usuários.
UC02
RF03: A ferramenta deverá permitir ao administrador associar um usuário a
um ou mais grupos de usuários.
UC03
RF04: A ferramenta deverá permitir ao administrador remover a associação
de um usuário a um ou mais grupos de usuários.
UC04
RF05: A ferramenta deverá permitir ao gestor de qualidade manter o
cadastro de configuração da integração com o TestComplete.
UC05
RF06: A ferramenta deverá permitir ao gestor de qualidade manter o
cadastro de planos de testes.
UC06
RF07: A ferramenta deverá permitir ao gestor de qualidade executar no
plano de testes a execução do teste automatizado da ferramenta
TestComplete.
UC07
RF08: A ferramenta deverá permitir manter o vínculo dos planos de testes
com os projetos de testes automatizados.
UC08
34
RF09: A ferramenta deverá permitir ao analista de testes manter o cadastro
de casos de testes.
UC09
RF10: A ferramenta deverá permitir manter o vínculo dos casos de testes
com os cenários de testes automatizados.
UC10
RF11: A ferramenta deverá permitir ao analista de testes emitir um caso de
teste em um padrão para documento de caso de teste.
UC11
RF12: A ferramenta deverá permitir ao analista de testes executar no caso
de teste a execução do teste automatizado da ferramenta TestComplete.
UC12
RF13: A ferramenta deverá importar cenários vinculados aos casos de testes
executados na ferramenta TestComplete.
UC13
RF14: A ferramenta deverá permitir ao analista de testes consultar o log de
execuções.
UC14
RF15: A ferramenta deverá permitir ao analista de testes realizar download
do arquivo de log do TestComplete.
UC15
RF16: A ferramenta deverá permitir ao analista de testes emitir relatório de
usuários com seus grupos.
UC16
RF17: A ferramenta deverá permitir ao analista de testes emitir relatório de
configurações de sistema.
UC17
RF18: A ferramenta deverá permitir ao analista de testes emitir relatório de
planos de testes.
UC18
RF19: A ferramenta deverá permitir ao analista de testes emitir relatório de
casos de testes informando de que plano pertence.
UC19
RF20: A ferramenta deverá permitir ao analista de testes emitir relatório de
logs de execuções de acordo com o filtro selecionado.
UC20
O Quadro 2 lista os requisitos não funcionais previstos para a ferramenta.
Quadro 2 - Requisitos não funcionais
Requisitos Não Funcionais
RNF01: A ferramenta deverá ser desenvolvida em Visual Studio C#.
RNF02: A ferramenta deverá utilizar o banco de dados SQL SERVER.
35
RNF03: A ferramenta deverá integrar-se à ferramenta TestComplete.
RNF04: A ferramenta deverá utilizar Microsoft .NET Framework 4.5.
RNF05: A ferramenta deverá emitir relatórios em formato PDF.
RNF06: A ferramenta deverá permitir filtrar registros por uma coluna pré-definida.
O Quadro 3 lista as regras de negócio previstas para a ferramenta.
Quadro 3 - Regras de Negócio
Regras de Negócio
RN01: A ferramenta não deverá permitir inclusão de usuários com o mesmo login.
RN02: A ferramenta deverá permitir utilizar o mesmo usuário em outros grupos de
usuário.
RN03: A ferramenta não deverá permitir executar um plano de teste sem ter pelo menos
um caso de teste associado.
RN04: A ferramenta não deverá permitir executar um caso de teste com um nome de teste
incompatível.
3.2.2 Diagramas de casos de uso
Será utilizado o diagrama de casos de uso para destacar os elementos relevantes para
um determinado processo.
Na Figura 18 apresenta-se o diagrama de caso de uso da ferramenta mostrando a
interação dos usuários.
36
Figura 18 - Diagrama de casos de uso
No diagrama é apresentado o caso de uso de efetuar login na ferramenta no qual o
usuário terá acesso à funcionalidade de acordo com o grupo de usuários. Na gerência de
acesso o administrador poderá gerenciar grupos de usuários da empresa que poderá liberar o
acesso somente para as pessoas autorizadas a utilizar a ferramenta de acordo com o cargo.
O gestor de qualidade poderá fazer a integração da ferramenta com o TestComplete na
configuração do sistema e podendo também realizar o cadastro de plano de testes associando
a algum projeto de caso de teste automatizado.
O cadastro de um caso de teste irá ser realizado pelo analista de testes que poderá
associar este ao componente “teste item” vinculado ao projeto automatizado. Na tela de
consulta de logs de execução podem ser verificados os status das execuções que foram
importadas automaticamente pela a ferramenta mostrando seus resultados. Os mesmos
poderão ser baixados, já que os logs que o TestComplete gerou foram exportados antes de
importar e também podendo gerar relatórios sobre estas execuções.
37
3.2.3 Diagramas de atividades
No diagrama de atividades da Figura 19 é apresentado o processo completo da
ferramenta. O gestor de qualidade irá iniciar o processo criando uma configuração e um plano
de testes. O analista de testes criará os casos de testes na ferramenta e também irá associar os
scripts aos cenários de testes desenvolvidos no TestComplete. A ferramenta será executada
retornando os resultados para realizar a exportação automaticamente do TestComplete e gerar
uma importação automática para a ferramenta. Ao realizar estes processos será possível gerar
relatórios como o de configurações do sistema, de usuários com seus grupos, dos planos de
testes, dos casos de testes referenciando o plano de teste vinculado e também sobre os logs
gerados, com isso finalizando o processo.
Figura 19 - Diagrama de atividades
38
3.2.4 Modelo de Entidade e Relacionamento
Como um dos objetivos do trabalho é o da ferramenta guardar informações sobre
configurações do sistema, dos casos de testes, dos planos de testes e consulta de logs de
execução dos casos executados, o modelo foi feito para manter informações necessárias para
um controle sobre os testes de produtos da empresa e vinculados aos testes automatizados.
Na Figura 20 mostra-se o Modelo de Entidade Relacionamento (MER) com base nas
tabelas da ferramenta e seus relacionamentos. O dicionário de dados desenvolvido para
especificar o sistema, é apresentado no Apêndice B.
Figura 20 - MER da ferramenta
Destacam-se as tabelas de controle de usuários que foram geradas automaticamente
pela tecnologia utilizada que foi o Entity Framework. As tabelas foram reutilizadas para
realizar o controle de grupos de usuários na ferramenta e estas tabelas são:
a) UserProfile;
b) webpages_Roles;
c) webpages_Membership;
d) webpages_OAuthMembership.
39
A tabela __MigrationHistory é um controlador de versão do projeto da ferramenta,
cada vez que houver alguma alteração esta tabela irá mudar o código de versão da ferramenta
e este código gera um hash de acúmulo de informações guardando nesta tabela.
Na sequência tem-se uma breve descrição sobre as entidades utilizadas para o
desenvolvimento da ferramenta:
a) userprofile: entidade responsável por armazenar usuários da ferramenta;
b) webpages_Roles: entidade responsável por armazenar os grupos de usuários na
ferramenta;
c) webpages_UsersInRoles: entidade responsável por armazenar as referências entre
usuário e grupo da ferramenta;
d) webpages_Membership: entidade responsável por armazenar informações básicas
dos usuários da ferramenta;
e) webpages_OAuthMembership: entidade responsável por ativar a autenticação dos
usuários com a ferramenta;
f) __MigrationHistory: entidade responsável por armazenar um hash da versão da
ferramenta;
g) ConfiguracaoSistema: entidade responsável por armazenar configurações do
sistema cadastrados na ferramenta;
h) PlanoTeste: entidade responsável por armazenar planos de testes cadastrados na
ferramenta;
i) CasoTeste: entidade responsável por armazenar casos de testes cadastrados na
ferramenta;
j) LogCasoTeste: entidade responsável por armazenar logs de execução da
ferramenta;
k) PlanoTeste_has_CasoTeste: entidade responsável por armazenar o relacionamento
entre as tabelas da ferramenta.
3.3 IMPLEMENTAÇÃO
Nesta seção são descritas as técnicas e ferramentas utilizadas na implementação e
também a operacionalidade da ferramenta.
40
3.3.1 Técnicas e ferramentas utilizadas
Para o desenvolvimento da ferramenta SisControlTest foi utilizada o Visual Studio
2013. Também foi utilizada como padrão a arquitetura Model View Controller (MVC) do
ASP.NET e utilizando-se das principais tecnologias do .NET Framework.
O ASP.NET é um modelo de desenvolvimento de aplicações para web baseado nos
princípios de orientação a objetos com amplo suporte do .NET Framework (SPAKI et al.,
2008). O .NET Framework é baseado em um modelo totalmente orientado a objetos e
integrado com as novas tecnologias do mercado. Ele possui o conceito de Common 87 Type
System (CTS), permitindo a utilização de diversas linguagens de programação. O código
compilado irá gerar um aplicativo para a plataforma .NET (SPAKI et al., 2008).
A linguagem de programação utilizada foi o C#, juntamente com linguagem
JavaScript para a chamada de funções e a codificação HTML para apresentação das páginas,
conforme mostra-se na Figura 21.
Figura 21 - Tela da ferramenta Visual Studio 2013
O padrão MVC é composto por Model, View e Controller, onde o Model é um objeto
de aplicação, a View é uma apresentação na tela e o Controller define a maneira como a
interface do usuário reage às entradas do mesmo. Antes do MVC, os projetos de interface para
o usuário tendiam em agrupar esses objetos. Utiliza-se o MVC para aumentar a flexibilidade e
a reutilização (GAMMA et al. 2000, p. 20).
41
No desenvolvimento da ferramenta foi utilizado o padrão MVC como arquitetura,
tendo como vantagens a velocidade de desenvolvimento, maior controle separando código de
negócio dos códigos de layout e tendo melhor organização da ferramenta, conforme mostra a
Figura 22.
Figura 22 - Relação entre usuário com a ferramenta no padrão MVC
Mostra-se no Quadro 4, o fragmento de código de uma classe o qual é uma estrutura
Model e após pode ser utilizada o Entity Framework para gerar as tabelas no banco de dados.
Quadro 4 - Fragmento de código de um componente
namespace ConexaoDB.Entidades public class ConfiguracaoSistema { //Classe da configuração de sistema informando se é campo obrigatório e também sua forma de escrita na visualização da view [Key] [DisplayName("Número")] public int IdConfiguracaoSistema { get; set; } [Required] [DisplayName("Descrição")] public string Descricao { get; set; } [Required] [DisplayName("Nome projeto")] public string NomeProjeto { get; set; } [Required] [DisplayName("Máquina")] public string MaquinaInstalacaoFerramenta { get; set; } [Required] [DisplayName("Nome da ferramenta")] public string NomeExecutavelFerramenta { get; set; } [Required] [DisplayName("Versão da ferramenta")] public string VersaoFerramenta { get; set; } [Required] [DisplayName("Local instalação")] public string LocalInstalacaoFerramenta { get; set; } [Required] [DisplayName("Local LOG")] public string LocalLogFerramenta { get; set; } } }
42
Mostra-se no Quadro 5, fragmento de código de regras de negócio interagindo com o
banco de dados para ser utilizada na ferramenta nas classes.
Quadro 5 - Fragmento de código de um Controller
namespace SisControlTestMVC5.Controllers { public class ConfiguracaoSistemaController : Controller { private Contexto db = new Contexto(); // GET: ConfiguracaoSistema //Chamada da lista de itens de configuração de sistemas para a grid da view public ActionResult Index(string searchString) { if (!string.IsNullOrEmpty(searchString)) { return View(db.ConfiguracaoSistemas.Where(p => p.NomeProjeto.Contains(searchString)).ToList()); } return View(db.ConfiguracaoSistemas.ToList()); } }
}
Mostra-se no Quadro 6, fragmento de código de interface onde são chamados métodos
do Controller.
Quadro 6 - Fragmento de código de uma View
@*Chamadas de campos para o grid de configuração do sistema*@ <table class="table table-striped"> <tr> <th> </th> <th> @Html.DisplayNameFor(model => model.IdConfiguracaoSistema) </th> <th> @Html.DisplayNameFor(model => model.NomeProjeto) </th> <th> @Html.DisplayNameFor(model => model.Descricao) </th> <th> @Html.DisplayNameFor(model => model.MaquinaInstalacaoFerramenta) </th> <th> @Html.DisplayNameFor(model => model.NomeExecutavelFerramenta) </th> </tr>
43
@*Percorre a lista de itens no banco de dados e insere na grid*@ @foreach (var item in Model) { <tr> <td style="width: 110px"> <a class="glyphicon glyphicon-search" data-url="@Url.Action("Details")" style="cursor: pointer" onclick="showModal(this, @item.IdConfiguracaoSistema);" data-toggle="tooltip" data-placement="center" title="Visualizar"></a> <a class="glyphicon glyphicon-edit" data-url="@Url.Action("Edit")" style="cursor: pointer" onclick="showModal(this, @item.IdConfiguracaoSistema);" data-toggle="tooltip" data-placement="center" title="Editar"></a> <a class="glyphicon glyphicon-trash" data-url="@Url.Action("Delete")" style="cursor: pointer" onclick="showModal(this, @item.IdConfiguracaoSistema);" data-toggle="tooltip" data-placement="center" title="Deletar"> </a> </td> <td> @Html.DisplayFor(modelItem => item.IdConfiguracaoSistema) </td> <td> @Html.DisplayFor(modelItem => item.NomeProjeto) </td> <td> @Html.DisplayFor(modelItem => item.Descricao) </td> <td> @Html.DisplayFor(modelItem => item.MaquinaInstalacaoFerramenta) </td> <td> @Html.DisplayFor(modelItem => item.NomeExecutavelFerramenta) </td> </tr> } </table>
A ferramenta SQL SERVER utilizada como banco de dados, permite a criação do
banco onde foram criadas as tabelas necessárias para o funcionamento da ferramenta
desenvolvida.
Utilizou-se também o Visual Studio e SQL SERVER para o desenvolvimento da
ferramenta junto com o padrão MVC, permitindo na implementação a utilização do Entity
Framework para a manipulação de dados do banco, também criando automaticamente os
procedimentos de Create, Update e Delete (CRUD) na manipulação de informações sobre as
entidades da ferramenta.
Segundo Macoratti (2009), o Entity Framework é o framework de Mapeamento Objeto
Relacional (ORM) da Microsoft que transforma objetos de negócio em dados relacionais e
vice-versa. O foco do Entity Framework não é o banco de dados, mas o modelo de negócios e
desta forma uma de suas tarefas é gerar o modelo conceitual a partir do modelo do banco de
dados, sendo que nesta atividade o desenvolvedor não tem que trabalhar diretamente com o
banco de dados, mas com o modelo conceitual e o modelo de entidades.
44
Para realizar a conexão da ferramenta desenvolvida com o banco de dados foi criada
uma classe, referenciada dentro do projeto principal da ferramenta. É responsável por criar as
tabelas no banco de dados através das classes da ferramenta conforme o Quadro 7.
Quadro 7 - Método de conexão com banco de dados
namespace ConexaoDB { public class Contexto : DbContext { //Chamando a variável de conexão do webconfig public Contexto() : base("Conexao") { Configuration.ProxyCreationEnabled = false; Configuration.LazyLoadingEnabled = false; Database.SetInitializer(new MigrateDatabaseToLatestVersion<Contexto, RepositoryMigrationConfiguration>()); } //Criação de tabelas através das classes public DbSet<ConfiguracaoSistema> ConfiguracaoSistemas { get; set; } public DbSet<PlanoTeste> PlanoTestes { get; set; } public DbSet<CasoTeste> CasoTestes { get; set; } public DbSet<LogCasoTeste> LogCasoTestes { get; set; } //Removendo o plural da criação das tabelas protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Conventions.Remove<PluralizingTableNameConvention>(); base.OnModelCreating(modelBuilder); } } public class RepositoryMigrationConfiguration : DbMigrationsConfiguration<Contexto> { public RepositoryMigrationConfiguration() { AutomaticMigrationsEnabled = true; AutomaticMigrationDataLossAllowed = true; } } }
Para o desenvolvimento da interface foram utilizados os componentes do Twitter
Bootstrap que é uma coleção de vários elementos e funções personalizadas para projetos web
empacotado como HTML, CSS e JavaScript, sendo mais rápido para o desenvolvimento web
por terem componentes prontos, podendo utilizar estilos CSS já configurados e tendo
compatibilidade com qualquer navegador, na Figura 23 mostra-se a estrutura de instalação
com seus arquivos instalados na ferramenta.
45
Figura 23 - Estrutura do Bootstrap
Fonte: Spurlock (2013).
O Twitter Bootstrap foi projetado para auxiliar pessoas de todos os níveis de
desenvolvimento. Ele foi desenvolvido para navegadores modernos, mas funciona no Internet
Explorer 7 em diante. Existem dezenas de componentes funcionais totalmente prontos para o
uso, sem falar nos plugins em jQuery. O projeto é open-source, o que significa que pode-se
colaborar para torná-lo cada vez melhor (MARQUES JÚNIOR, 2013).
Rotativa é uma biblioteca baseada no executável wkhtmltopdf que converte HTML
para PDF, usando o motor WebKit usado pelos navegadores Chrome e Safari (FERRARI,
2014). Para o desenvolvimento de relatórios foi utilizada uma biblioteca da Rotativa. Esta
biblioteca instala uma DLL no projeto da ferramenta e um executável conversor de HTML
para PDF. No Quadro 8, apresenta-se um Controller de chamada do relatório utilizando-se da
rotina de conversão para PDF.
Quadro 8 - Código de chamada de relatório em PDF
namespace SisControlTestMVC5.Controllers { public class RelatoriosController : Controller { // GET: Relatorios //Chamada de relatório de configuração do sistema em PDF public ActionResult RelatorioConfiguracaoSistema() { try { using (var context = new ConexaoDB.Contexto()) { var model = context.ConfiguracaoSistemas.ToList(); return new ViewAsPdf("RelatorioConfiguracaoSistema", model); } } catch (Exception ex) { throw new Exception(ex.Message, ex); } } } }
46
3.3.1.1 Estrutura da Ferramenta
A ferramenta desenvolvida foi estruturada em pacotes como a ConexaoDB e a
IntegraçãoTestComplete, conforme apresenta-se na Figura 24.
Figura 24 - Estrutura de classes
A classe ConexaoDB é responsável pela conexão de banco de dados com a
ferramenta e contém as classes de entidades da ferramenta, conforme a Figura 25.
Figura 25 - Entidades da ferramenta
O pacote IntegraçãoTestComplete é responsável pelos métodos de execução da
ferramenta TestComplete e para o funcionamento necessita estar referenciado no pacote do
projeto da ferramenta, conforme mostra-se na Figura 26.
47
Figura 26 - Referência de DLL no pacote IntegracaoTestComplete
3.3.1.2 Integrações com ferramenta TestComplete
Na integração com a ferramenta TestComplete foi adicionada na referência da
ferramenta uma biblioteca do TestComplete no pacote IntegracaoTestComplete, conforme
a Figura 27.
Figura 27 - Referência da integração
48
Para deixar a integração completa foi necessário referenciar duas DLLs da pasta bin do
diretório de instalação da ferramenta TestComplete. Estas DLLs são chamadas de
AutomatedQA.script.dll e AutomatedQA.TestComplete.CSConnectedApp.dll que
auxiliam na execução da ferramenta TestComplete com a integração com a ferramenta
desenvolvida com chamadas de rotinas internas. Conforme apresenta-se na Figura 28
mostram-se as duas DLLs para referenciar o pacote IntegracaoTestComplete.
Figura 28 - Arquivos COM para referência na integração
3.3.1.3 Configuração da ferramenta TestComplete
É necessário configurar o TestComplete conforme a Figura 29. Na configuração de
playback desmarca-se a opção de Stop On Error para evitar que projetos parem de rodar no
primeiro erro que ocorrer, também tendo como principais campos que serão utilizados na
ferramenta desenvolvida o nome do projeto suíte, o nome do sub-projeto como projeto de
referência do plano de teste e o teste item dentro do sub-projeto, como campo principal para
referência no caso de teste.
49
Figura 29 - Configuração da ferramenta TestComplete
3.3.2 Operacionalidade da implementação
Nesta subseção são apresentadas as telas do sistema e suas funcionalidades, além de
fragmentos do código relevantes para o entendimento de algumas rotinas.
3.3.2.1 Tela de login
O usuário administrador terá acesso total na ferramenta, como os cadastros e as
funcionalidades do sistema. O gestor de qualidade terá acesso à parte de gerência de acesso
restringida e com todas as outras funcionalidades da ferramenta liberadas. O analista de testes
também terá acesso restringido para gerência de acesso, cadastro de configurações do sistema
e o cadastro plano de testes que são de responsabilidade do gestor de qualidade. No primeiro
acesso, o usuário comum, por sua vez, não terá funcionalidade alguma liberada até o
administrador adicioná-lo a algum grupo de acesso da ferramenta. Mostra-se uma mensagem
informativa de que é necessário ser liberado para ter acesso à ferramenta. A tela de acesso
pode ser visualizada na Figura 30.
50
Figura 30 - Tela de Login com validação
Entrando como administrador o usuário terá acesso aos menus, bem como também a
visualização do gráfico de execuções da ferramenta na página principal (desde que haja pelo
menos uma execução efetuada) e tendo também ícones de atalhos para facilitar o acesso das
rotinas (Figura 31).
Figura 31 - Tela inicial de administrador
Na página inicial, a view que mostra-se o gráfico sobre os casos de testes ou planos de
51
testes executados até o momento e mostrando sua percentagem de resultados executados. No
Quadro 9 pode-se ver uma parte do código da geração.
Quadro 9 - Código da geração de gráfico de execuções de testes
//Controller que gera o gráfico da tela inicial calculando a quantidade de erros e public ActionResult DataChart() { var model = new HomeModel(); Contexto context = new Contexto(); var total = context.LogCasoTestes.Count(); model.TotalComAdvertencia = context.LogCasoTestes.Count(x => x.QuatidadeAdvertencias > 0) == 0 ? 0 :(context.LogCasoTestes.Count(x => x.QuatidadeAdvertencias > 0) * 100) / total; model.TotalComErros = context.LogCasoTestes.Count(x => x.QuatidadeErros > 0) == 0 ? 0 : (context.LogCasoTestes.Count(x => x.QuatidadeErros > 0) * 100) / total; model.TotalExecutados = context.LogCasoTestes.Count(x => x.QuatidadeAdvertencias <= 0 && x.QuatidadeErros <= 0) == 0 ? 0 : (context.LogCasoTestes.Count(x => x.QuatidadeAdvertencias <= 0 && x.QuatidadeErros <= 0) * 100) / total; var myChart = new Chart(width: 400, height: 200) .AddTitle(" ") .AddSeries(chartType: "Pie", xValue: new[] { model.TotalExecutados + "%", model.TotalComAdvertencia + "%", model.TotalComErros + "%" }, yValues: new[] { model.TotalExecutados, model.TotalComAdvertencia, model.TotalComErros }); return File(myChart.ToWebImage().GetBytes(), "image/png");}
3.3.2.2 Tela de cadastro de grupos
Na tela gerência de grupos de acesso, que somente o administrador tem permissão,
inclui-se novos grupos. Os grupos já são carregados por padrão na ferramenta, conforme tem-
se na Figura 32 e pode-se associar um usuário a um grupo acessando o ícone de usuários.
Depois disto, o usuário terá liberado as funcionalidades de acordo com seu grupo.
52
Figura 32 - Tela de gerência de grupos
3.3.2.3 Tela de cadastro de configuração
Na tela de configuração (Figura 33) são cadastradas as informações necessárias para
rodar a execução de testes de um plano de teste ou caso de teste tendo como principais
campos a versão da ferramenta, local da instalação e local do log.
Figura 33 - Tela cadastro de configuração do sistema com validações
53
3.3.2.4 Tela de cadastro de plano de teste
Na tela de cadastro tem-se a aba projeto automatizado como referência de qual projeto
será executado. Informa-se o nome da estrutura realizada no TestComplete para a execução
tendo como campos importantes a suíte, o projeto e o diretório do arquivo do projeto
automatizado, onde fica localizado o arquivo do projeto suíte do TestComplete (Figura 34).
Figura 34 - Tela de cadastro de plano de teste com validações
Todo campo no qual for necessário informar um endereço de diretório de uma
máquina, será necessário copiar o endereço e cola-lo no respectivo campo. O motivo disto é
porque em navegadores não é possível navegar nos diretórios de qualquer máquina por razões
de segurança do próprio browser.
3.3.2.5 Tela principal do caso de teste
Na tela principal de casos de testes também tem-se as mesmas funcionalidades da tela
de cadastro de plano de teste podendo-se, desta vez, executar os casos de testes
individualmente. Também tem-se uma funcionalidade de diferencial para a impressão de caso
de teste através de uma view sendo convertida para o formato PDF (Figura 35).
54
Figura 35 - Tela principal de casos de testes
Na tela de cadastro de caso de teste tem-se um campo importante chamado item de
teste, é o mesmo campo no TestComplete chamado de Test Item e com isso associando a
ferramenta para execução do caso de teste, conforme apresenta-se na Figura 36.
Figura 36 - Tela de cadastro de caso de teste com validação
Na tela principal de casos de testes tem-se um botão que, assim como também terá na
de plano de teste, pode-se inicializar o processo de execução dos cenários de testes associados
à ferramenta desenvolvida integrada na ferramenta TestComplete, utilizando os campos
obrigatórios para vincular o caso de teste com um script de teste. No Quadro 10 apresenta-se
um trecho do código de execução da ferramenta TestComplete integrada.
55
Quadro 10 - Fragmento código de execução da ferramenta TestComplete integrada
try { //Buscar todos os casos de testes foreach (var casoTeste in ( IdCasoTeste.HasValue ? //Filtra pelo caso de teste se for execu;áo de um caso PlanoTeste.CasosTestes.Where(c => c.IdCasoTeste == IdCasoTeste) : //Caso execucao de plano ele busca todos os casos PlanoTeste.CasosTestes)) { if (caso == true) { //RunProjectTestItem executa o caso de teste IntegrationObject.RunProjectTestItem(PlanoTeste.ProjetoAutomatizado, casoTeste.ScriptAutomatizado); } else { //RunProject executa o plano de teste IntegrationObject.RunProject(PlanoTeste.ProjetoAutomatizado); } while (IntegrationObject.IsRunning()) { } if (IdCasoTeste.HasValue) GeraLog(IntegrationObject); } if (!IdCasoTeste.HasValue) GeraLog(IntegrationObject); } catch (Exception ex) { throw new Exception("Ocorreu erro na execução: " + ex.Message); } finally { // Fecha TestComplete TestCompleteManager.Quit(); // Libera os objetos COM Marshal.ReleaseComObject(IntegrationObject); Marshal.ReleaseComObject(TestCompleteManager); Marshal.ReleaseComObject(TestCompleteObject); }
Na view do relatório de caso de teste é feita a chamada dos campos necessários para
impressão através de seu campo id como identificador do registro selecionado e o relatório
segue um padrão de documentação de caso de teste semelhante ao padrão IEEE 829 (Figura
37).
56
Figura 37 - Caso de teste impresso
Na rotina de imprimir o caso de teste, a ferramenta busca no banco de dados um caso
de teste onde o id informado seja o mesmo no banco e seja o mesmo caso de teste que esteja
referenciado em um plano de teste. No Quadro 11 tem-se um trecho de código para a
impressão de um caso de teste em formato PDF.
Quadro 11 - Código de imprimir caso de teste em PDF
[HttpGet] public ActionResult Imprimir(int id) { try { //busca caso de teste pelo id e associado no seu plano var casoTeste = db.CasoTestes.Where(m => m.IdCasoTeste == id).Include(m => m.PlanoTeste); return new ViewAsPdf("CasoTestePadrao", casoTeste.FirstOrDefault()); } catch (Exception ex) { throw new Exception(ex.Message, ex); } }
57
3.3.2.6 Tela principal logs de execução
Na tela de logs de execução estão contidas as execuções realizadas através da
ferramenta e armazenadas no banco de dados informando seu status conforme são
demonstrados na legenda da página principal e na Figura 38.
Figura 38 - Tela principal de logs de execução
Após o caso de teste ou plano de teste serem executados é gerado o log da execução e
os resultados são inseridos automaticamente no banco de dados, na view da tela de logs de
execução os registros são pintados com cores de acordo com status da legenda, conforme está
apresentado no código que consta no Quadro 12.
Quadro 12 - Fragmento de código da tela de logs de execução
@foreach (var item in Model.OrderByDescending(teste => teste.Fim)) { //Pecorre no banco os logs inseridos e pinta conforme o status do log <tr style="background-color: @(item.Resultado == 0 ? "#73b839" : (item.Resultado == Resultado.Advertencia ? "#fa5a10" : "#c71d22"))"> <td> <a class="glyphicon glyphicon-search" data-url="@Url.Action("Details")" style="cursor: pointer" onclick="showModal(this, @item.IdLogCasoTeste);" data-toggle="tooltip" data-placement="center" title="Visualizar"></a> </td> <td> @Html.DisplayFor(modelItem => item.TipoLog) </td> <td> @Html.DisplayFor(modelItem => item.Resultado) </td>
58
<td> @Html.DisplayFor(modelItem => item.Inicio) </td> <td> @Html.DisplayFor(modelItem => item.Fim) </td> <td> @Html.DisplayFor(modelItem => item.QuatidadeErros) </td> <td> @Html.DisplayFor(modelItem => item.QuatidadeAdvertencias) </td> </tr> }
Na tela de logs de execução pode-se também visualizar o registro de teste executado
visualizando-se suas informações. Pode-se também baixar o log original da ferramenta
TestComplete alocada no diretório padrão de configuração do sistema, conforme apresenta-se
na Figura 39.
Figura 39 - Tela de visualização do log de execução
Na rotina de donwload de arquivo de log é realizada uma busca pelo id do log incluído
na tabela LogCasoTeste no banco de dados e do diretório de armazenamento de logs das
execuções. O Quadro 13 apresenta o código de download do arquivo de log.
Quadro 13 - Código de download do arquivo de log
try { if (id == 0) { return null; }
59
//faz o download pelo id da tabela de logs var logcasoteste = db.LogCasoTestes.Find(id); if (logcasoteste == null) { return null; } var path = string.Empty; if (logcasoteste.TipoLog == TipoLog.CasoTeste) { //busca logs casos de testes associados em um plano var casoTeste = db.CasoTestes.Where(teste => teste.IdCasoTeste == logcasoteste.IdPlanoCaso).Include(teste => teste.PlanoTeste.ConfiguracaoSistema).FirstOrDefault(); path = casoTeste.PlanoTeste.ConfiguracaoSistema.LocalLogFerramenta; } else { //busca logs planos de testes var casoTeste = db.PlanoTestes.Where(teste => teste.IdPlanoTeste == logcasoteste.IdPlanoCaso).Include(teste => teste.ConfiguracaoSistema).FirstOrDefault(); path = casoTeste.ConfiguracaoSistema.LocalLogFerramenta; } System.IO.File.WriteAllBytes(path + id + ".mht", logcasoteste.Log); var ret = File(path + id + ".mht", "application/octet-stream", id + ".mht"); return ret; } catch (Exception ex) { throw new Exception(ex.Message, ex); }
3.4 RESULTADOS E DISCUSSÃO
O objetivo do presente trabalho foi desenvolver uma ferramenta para um planejamento
e controle mais eficaz dos cenários de testes automatizados implementados associando com os
casos de testes documentados junto com seu plano de teste pela empresa. A visualização do
histórico de logs de execução do TestComplete integrado na ferramenta, a gerência de grupos
de usuários, dos cadastros de planos de testes, dos cadastros de casos de testes, dos relatórios
de configurações do sistema, casos de testes, planos de testes, usuários e logs de execução de
acordo com o filtro desejado, visou facilitar e aprimorar a gestão desses cenários de testes
automatizados associados aos dados de casos de testes documentados na ferramenta em um
padrão semelhante ao IEEE-829.
Quanto aos trabalhos correlatos, verificam-se semelhanças com o sistema de Amorim
60
(2011) e Bertolini (2014), porém em outra necessidade que é a melhoria dos processos de
testes utilizando o MPT, também usando a documentação de testes no padrão IEEE-829. Com
o sistema de Labes (2010) tem-se um sistema para controle de testes manuais tendo como
foco da extração de casos de uso para geração de cenários de testes e sendo necessário
registrar cada passo manualmente. O trabalho de Bonecher (2008) é o que tem mais
semelhança com a ferramenta desenvolvida por utilizar o planejamento de planos de testes e
casos de testes com suas execuções sendo registradas. O presente trabalho, por sua vez, é
direcionado para o planejamento e o controle de cenários de testes automatizados ligados aos
casos de testes documentados pela empresa, voltado especificamente para as necessidades da
empresa.
O Quadro 14 descreve semelhanças e diferenças entre os trabalhos correlatos e
trabalho desenvolvido.
Quadro 14 - Comparando os trabalhos correlatos com o trabalho desenvolvido
Características Trabalho
Desenvolvido
Bonecher
(2008)
Labes
(2010)
Amorim
(2011)
Bertolini
(2014)
Criar configuração X - - - X
Criar caso de teste X X X X X
Criar plano de teste X X - X X
Emitir documento caso de teste X - - - -
Realizar download de log X X - - -
Integrar com ferramenta externa X X X X X
Comtempla o IEEE 829 X X - X X
Comtempla o CMMI - - X - -
Comtempla o MPT.BR - - X X X
Tarefa de teste - - - X -
Visualizar Execuções X X X - -
A ferramenta cumpre com satisfação o objetivo da empresa que era ter uma visão
maior sobre o controle de casos de testes documentados que não eram correlacionados com os
cenários de testes automatizados. Com a ferramenta pode-se ver o correlacionamento do plano
de testes com os casos de testes e com os cenários de testes automatizados.
A opinião de um usuário da empresa identificou a facilitação das execuções destes
cenários de testes na ferramenta sem a necessidade de desenvolver um treinamento técnico
61
sobre automação para todos analistas de testes. Com a ferramenta pretende-se melhorar a
visibilidade de qual plano de teste ou caso de teste que está sendo executado na ferramenta.
Com a criação dessa ferramenta, foi possível padronizar e facilitar o controle dos casos de
testes em relação aos cenários automatizados.
Será analisado pela empresa a implantação da ferramenta para o ano de 2015, tendo
como propósito, um maior controle sobre os testes automatizados e sendo melhor visto pelo
gestor de qualidade e apresentando para a diretoria os resultados de testes executados obtidos.
62
4 CONCLUSÕES
Diante do crescimento do mercado as empresas têm buscado mais rentabilidade
financeira investindo em seus produtos. Com isto buscam a melhoria do processo de testes
interno e também a melhoria da qualidade do produto entregue ao cliente. As melhorias de
processos indicam um aumento de satisfação dos clientes, de aumento das vendas dos
produtos e do aumento da competividade do produto perante um mercado globalizado. Com
base nisso, desenvolveu-se um sistema web, que automatiza o processo de teste interno de
uma empresa de software do ramo público com uma ferramenta de planejamento e controle de
testes, e os disponibiliza na intranet local, onde o próprio gestor de qualidade pode buscar
informações sobre atividades realizadas pelos analistas de testes sobre os casos de testes e
sobre a automação de testes.
A ferramenta diminui a possibilidade de perda de documentos com relação aos planos
de testes e casos de testes. Realiza também uma forte interação dos testes automatizados que
eram desenvolvidos na ferramenta TestComplete isoladamente não tendo um controle efetivo
do que era automatizado na empresa. Com isto acabou-se trazendo uma maior organização
integrando dois processos de testes que eram isolados sem controle algum.
O controle feito na ferramenta ficou mais efetivo do que a busca por documentos de
planos de testes e casos de testes em um servidor, como era feito anteriormente. Todos os
campos necessários para a documentação foram incluídos nos cadastros de caso de teste e
plano de teste, permitindo fazer uma consulta sobre os dados necessários e vincular ao projeto
de automatização da ferramenta TestComplete. A integração entre a ferramenta desenvolvida
com a de automatização possibilitou que usuários mais leigos na tecnologia executem os
casos de testes e obtenham os resultados sem a necessidade de entender o funcionamento da
ferramenta de automatização.
A ferramenta desenvolvida atingiu os seus principais objetivos. O administrador da
ferramenta pode gerenciar os grupos de usuários e liberar acesso para as funcionalidades de
acordo com o cargo do usuário. O gestor de qualidade pode configurar a ferramenta de
automatização para poder associá-la em algum plano de testes e também pode manipular estas
informações. O plano de teste é cadastrado pelo gestor de qualidade onde é vinculado ao
projeto automatizado. Este vínculo também é necessário com a vinculação e a configuração
do sistema como pré-requisito e este plano de teste pode ser manipulados posteriormente. O
analista de testes pode cadastrar os casos de testes associados ao plano de teste que já está
63
vinculado em um projeto automatizado, tendo somente que informar o item de teste da
automatização na ferramenta desenvolvida. O gestor de qualidade, juntamente com analista de
testes, poderá fazer o acompanhamento dos casos de testes ou planos testes executados
diariamente consultando os logs na ferramenta e até fazer download de um registro de
execução específico. Outro tipo de controle são os relatórios sobre cada funcionalidade,
podendo os mesmos serem baixados em formato PDF e também podendo fazer uma
visualização dos testes executados até o momento na tela principal da ferramenta.
A principal dificuldade durante o desenvolvimento do sistema foi a utilização de
pacotes de CSS (como o Twitter Bootstrap) para interface de tecnologias mais atuais para
desenvolvimento web. Houve dificuldades de fazer a interface interagir com a parte lógica,
isto porém aumentou o conhecimento sobre a programação web e utilização destas novas
tecnologias.
Para o autor, este trabalho trouxe um grande aprendizado na utilização de novas
tecnologias antes desconhecidas, como o MVC, separando a parte lógica da interface,
ajudando na velocidade do desenvolvimento. O Entity Framework se encarrega das criações
de tabelas de acordo com o modelo de classe, o que ajudou a ter um controle mais eficiente
sobre os dados. Também, outra tecnologia que trouxe vantagem para o desenvolvimento, foi a
Rotativa, que é responsável de criar um relatório sobre seu layout em HTML, com isso
deixando a elaboração de relatórios de uma forma mais produtiva.
4.1 EXTENSÕES
Para dar continuidade ao sistema, pode-se realizar o desenvolvimento de um controle
de codificação de cenários de testes no TestComplete dos quais necessita-se automatizar e
assim tem-se um controle sobre o que está sendo implementado sobre os casos de testes
futuros de cada analista de teste responsável pela automatização. Outro item que pode ser
desenvolvido é a criação de gráficos de desempenho por analistas de testes, sobre os casos de
testes automatizados por horas implementadas e um controle de horas gastas por caso de teste
automatizado de cada analista de teste.
Outra extensão que pode ser desenvolvida futuramente é o relacionamento de um erro
com alguma ferramenta de cadastro de bugs, associando o log de execução para verificação
do erro e informando em qual caso de teste ocorreu o problema na versão que o produto foi
64
executado nos cenários de testes.
Sugere-se realizar um controle de versão de produto ligado ao versionamento do
produto da empresa. Executando-se o processo de atualização do produto antes de rodar um
cenário de teste na ferramenta poderá ter-se uma confiabilidade de que o teste foi realizado
antes da liberação para os clientes.
Desenvolver um módulo de gráficos sobre as execuções que seriam mais detalhadas,
filtrando informações como data de intervalo entre as execuções, sobre os produtos e
mostrando os resultados quais cenários foram mais afetados no mês em algum produto
específico também é uma sugestão futura.
65
REFERÊNCIAS
AMORIM, D. R. Ferramenta de apoio à implantação do Processo de Melhoria de
Processo de teste (MPT). 2011. 92f. Trabalho de Conclusão de Curso (Bacharel em Ciência
da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,
Blumenau.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO.
MPT.Br. Recife, 2010a. Disponível em: <http://www.recife.softex.br/index.php/next-nucleo-
de-excelencia-em-teste-de-softwarempt/?page_id=42>. Acesso em: 14 set. 2014.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO.
MPT.Br – Melhoria de Processo de Teste: guia de implementação – parte 1: nível 1. Recife,
2010b. Disponível em: <http://www.mpt.org.br/wp-
content/uploads/2010/12/MPT_BR_Nivel_1_v_2.2.pdf>. Acesso em: 14 set. 2014.
BARTIÉ, A. Processo de testes de software – Parte 01. [S.l.], 2007. Disponível em:
<http://imasters.com.br/artigo/6102/software/processo-de-teste-de-software-parte-01>.
Acesso em: 14 set. 2014.
BERTOLINI, V. Ferramenta de apoio à implantação do Processo de Melhoria de
Processo de teste (MPT) - Extensão. 2014. 71f. Trabalho de Conclusão de Curso (Bacharel
em Ciência da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional
de Blumenau, Blumenau.
BERTOLINO, A. The (im) maturity Level of Software Testing. New York: ACM
SIGSOFT Software Engineering Notes, 2004.
BONECHER, B. T. Ferramenta WEB de apoio ao planejamento e controle de testes.
2008. 84f. Trabalho de Conclusão de curso (Bacharel em Sistemas de Informação) - Centro de
Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
COUTO, A. B. CMMI: integração dos modelos de capacitação e maturidade de sistemas. Rio
de Janeiro: Ciência Moderna, 2007.
CRESPO, A. N. et al. Uma metodologia para Teste de Software no contexto da Melhoria
de Processo. [S.l], 2008. Disponível em: <
http://www.sbc.org.br/bibliotecadigital/download.php?paper=254>. Acesso em: 14 set. 2014.
DIAS NETO, A. C. Uma Infra-Estrutura Computacional para Apoiar o Planejamento e
Controle de Testes. Rio de Janeiro, 2006. Disponível em: <http://lens-
ese.cos.ufrj.br/ese/index.php?option=com_docman&task=doc_download&gid=2&Itemid=74
&lang=pt_br/>. Acesso em: 14 set. 2014.
DIAS NETO, A. C.; TRAVASSOS, G. H. Maraká: infra-estrutura computacional para apoiar
o planejamento e controle dos testes de software. In Simpósio Brasileiro de Qualidade de
Software, Anais, p. 250-264, Rio de Janeiro, 2006.
66
FERRARI, C. Rotativa PDF em ASP .Net MVC. {S.l.], 2014. Disponível em:
<http://www.tiselvagem.com.br/desenvolvimento/asp-net/mvc-rotativa-pdf/>. Acesso em: 08
nov. 2014.
GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de software Orientado a
Objetos. Porto Alegre: Bookman, 2000.
HEINEBERG, R. Casos de Testes. [S.l.], 2008. Disponível em:<
http://testandosoftware.blogspot.com.br/2008/06/casos-de-testes.html>. Acesso em: 14 set.
2014.
INTHURN, C. Qualidade & Teste de Software. Florianópolis: Visual Books, 2001.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de Software. São Paulo: Novatec, 2006.
LABES, C. Test-Plan: Ferramenta de apoio ao planejamento e controle das atividades do
processo de testes. 2010. 107f. Trabalho de Conclusão de Curso (Bacharel em Sistemas de
Informação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,
Blumenau.
MACORATTI, José C. Introdução ao Entity Framework. [S.l.], 2009. Disponível em:
<http://www.macoratti.net/09/06/vb_iaef.htm>. Acesso em: 01 nov. 2014.
MARQUES JÚNIOR, E. Seja produtivo usando o Twitter Bootstrap. [S.l.], 2013.
Disponível em: <http://www.devmedia.com.br/seja-produtivo-usando-o-twitter-
bootstrap/24967>. Acesso em: 08 nov. 2014.
MOLINARI, L. Testes de Software. 1. São Paulo: Ed. Érica, 2003.
MOLINARI, L. Inovação e automação de testes de software. 1. São Paulo: Ed. Érica, 2010.
MYERS, G. J. The art of software testing. New Jersey, USA: John Wiley & Sons, 2004.
QUALISTER. Guia de Primeiros Passos: TestComplete. Biguaçu. 2012. Disponível em:
<http://www.qualister.com.br/>. Acesso em: 14 set. 2014.
RIOS, E.; MOREIRA FILHO, T. Teste de Software. 2. Rio de Janeiro: Alta Books, 2006.
RIOS, E. Documentação de teste de software: dissecando padrão IEEE-829. Niterói:
Imagem Art Studio, 2007.
SMARTBEER. About TestComplete. Texas, EUA. 2012. Disponível em:
<http://support.smartbear.com/viewarticle/28901/>. Acesso em: 14 set. 2014.
SPAKI, Eduardo et al. Desenvolvendo para Web usando o Visual Studio 2008. Rio de
Janeiro: Brasport, 2008.
SPURLOCK, J. Bootstrap. California, EUA. 2013. Disponível em: <http://it-
ebooks.info/read/2331//>. Acesso em: 01 nov. 2014.
67
VEENENDAAL, E. V. et al. Glossário padrão de termos utilizados em teste de software.
Versão 2.1br. Glossary Working Party, 2010. 71p.
WEBER, K. Qualidade de Software: Teoria e Prática. São Paulo: Prentice Hall, 2001.
WEBER, K. C; ROCHA, A. R. C; NASCIMENTO, C. J. Qualidade e Produtividade em
Software. 4. São Paulo: Makron Books, 2001.
68
APÊNDICE A – Descrição dos Casos de Uso
Neste Apêndice são apresentados o detalhamento dos casos de uso previstos nos
diagramas apresentados na subseção 3.2.2. No Quadro 15 estão descritos os casos de usos da
ferramenta.
Quadro 15 - Descrição dos casos de uso
UC01 – Efetuar Login
Permite ao usuário através de identificação por usuário e senha conectar-se na ferramenta.
Ator: Analista de Teste
Pré-condições: Não possuir um outro usuário igual ao que for utilizado.
Pós-condição: O usuário entra logado na ferramenta.
Cenário Principal:
1. Usuário preenche usuário e senha;
2. Ferramenta valida os dados de usuário e senha;
3. Ferramenta direciona para a página principal.
Fluxo Alternativo 1:
1. Nome de usuário e/ou senha inválidos;
2. Alerta com mensagem “O nome de usuário ou senha está incorreto” é mostrada.
Fluxo Alternativo 2:
1. Nome de usuário e/ou senha vazio;
2. Alerta com mensagem “O campo Usuário é obrigatório” é mostrada.
3. Alerta com mensagem “O campo Senha é obrigatório” é mostrada.
UC02 – Gerência de Grupos de Usuários
Permite ao administrador cadastra grupos de usuários na ferramenta.
Ator: Administrador
Pré-condições: O administrador deve estar logado na ferramenta.
Pós-condição: O administrador cadastra o grupo de usuário.
Cenário Principal:
1. Administrador preenche o nome do grupo;
2. Ferramenta direciona para a página principal de grupos de usuários.
Fluxo Alternativo 1:
1. Nome de grupos de usuários vazio;
2. Alerta com mensagem “O campo Nome é obrigatório” é mostrada.
UC03 – Associar Usuários
Permite ao administrador associar usuários aos grupos de usuários na ferramenta.
69
Ator: Administrador
Pré-condições: O grupo de usuário cadastrado.
Pós-condição: O usuário incluído no grupo de usuário.
Cenário Principal:
1. Administrador seleciona o usuário;
2. Administrador adiciona o usuário ao grupo de usuários;
3. Ferramenta direciona para a página principal de usuários nos grupos de usuários.
UC04 – Remover Associação de Usuários
Permite ao administrador remover a associação de usuários aos grupos de usuários na
ferramenta.
Ator: Administrador
Pré-condições: O usuário está incluído no grupo de usuários.
Pós-condição: O usuário removido do grupo de usuários.
Cenário Principal:
1. Administrador seleciona o usuário;
2. Administrador remove o usuário do grupo de usuários;
3. Ferramenta direciona para a página principal de usuários nos grupos de usuários.
UC05 – Manter Configuração do Sistema
Permite ao gestor de qualidade manter as configurações do sistema na ferramenta.
Ator: Gestor de Qualidade
Pré-condições: A ferramenta TestComplete estar instalada.
Pós-condição: A configuração do sistema instalado.
Cenário Principal:
1. Gestor de Qualidade preenche campos Nome projeto, Descrição, Máquina, Nome
Ferramenta, Versão da ferramenta, Local instalação e Local LOG;
2. Ferramenta valida os campos obrigatórios;
3. Ferramenta direciona para a página principal de configuração do sistema.
Fluxo Alternativo 1:
1. Nome projeto, Descrição, Máquina, Nome Ferramenta, Versão da ferramenta, Local
instalação e Local LOG vazios;
2. Alerta com mensagem “O campo Nome projeto é obrigatório.” é mostrada.
3. Alerta com mensagem “O campo Descrição é obrigatório.” é mostrada.
4. Alerta com mensagem “O campo Máquina é obrigatório.” é mostrada.
5. Alerta com mensagem “O campo Nome Ferramenta é obrigatório.” é mostrada.
6. Alerta com mensagem “O campo Versão da ferramenta é obrigatório.” é mostrada.
7. Alerta com mensagem “O campo Local instalação é obrigatório.” é mostrada.
8. Alerta com mensagem “O campo Local LOG.” é mostrada.
Fluxo Alternativo 2:
70
1. Gestor de Qualidade seleciona o botão de visualizar do cadastro;
2. Gestor de Qualidade visualiza o cadastro;
3. Ferramenta direciona para a página principal de configuração do sistema.
Fluxo Alternativo 3:
1. Gestor de Qualidade seleciona o botão de editar do cadastro;
2. Gestor de Qualidade edita o cadastro;
3. Gestor de Qualidade salva a alteração do cadastro;
4. Ferramenta direciona para a página principal de configuração do sistema.
Fluxo Alternativo 4:
1. Gestor de Qualidade seleciona o botão de excluir do cadastro;
2. Ferramenta retorna uma mensagem da exclusão “Você tem certeza que deseja excluir
a configuração?”;
3. Gestor de Qualidade pressiona o botão Sim;
4. Ferramenta direciona para a página principal de configuração do sistema.
UC06 – Manter Plano de Teste
Permite ao gestor de qualidade manter os planos de testes na ferramenta.
Ator: Gestor de Qualidade
Pré-condições: Uma configuração do sistema cadastrada.
Pós-condição: O plano de testes cadastrado.
Cenário Principal:
1. Gestor de Qualidade preenche campos Configuração, Nome, Descrição, Ambiente,
Abordagem, Treinamento, Produto, Funcionalidade, Suíte, Projeto e Diretório;
2. Ferramenta valida os campos obrigatórios;
3. Ferramenta direciona para a página principal de plano de teste.
Fluxo Alternativo 1:
1. Configuração, Nome, Descrição, Ambiente, Abordagem, Treinamento, Produto,
Funcionalidade, Suíte, Projeto e Diretório vazios;
2. Alerta com mensagem “O campo Nome projeto é obrigatório.” é mostrada.
3. Alerta com mensagem “O campo Descrição é obrigatório.” é mostrada.
4. Alerta com mensagem “O campo Suíte.” é mostrada.
5. Alerta com mensagem “O campo Projeto.” é mostrada.
6. Alerta com mensagem “O campo Diretório.” é mostrada.
Fluxo Alternativo 2:
1. Gestor de Qualidade seleciona o botão de visualizar do cadastro;
2. Gestor de Qualidade visualiza o cadastro;
3. Ferramenta direciona para a página principal de plano de teste.
Fluxo Alternativo 3:
1. Gestor de Qualidade seleciona o botão de editar do cadastro;
2. Gestor de Qualidade edita o cadastro;
3. Gestor de Qualidade salva a alteração do cadastro;
4. Ferramenta direciona para a página principal de plano de teste.
71
Fluxo Alternativo 4:
1. Gestor de Qualidade seleciona o botão de excluir do cadastro;
2. Ferramenta retorna uma mensagem da exclusão “Você tem certeza que deseja excluir
o plano de teste?”;
3. Gestor de Qualidade pressiona o botão Sim;
4. Ferramenta direciona para a página principal de plano de teste.
UC07 – Executar Plano de Teste
Permite ao gestor de qualidade executar os planos de testes que contenham casos de testes na
ferramenta.
Ator: Gestor de Qualidade
Pré-condições: Um plano de teste cadastrado com pelo menos 1 caso de teste.
Pós-condição: Executar o plano de teste com seu caso de teste associado.
Cenário Principal:
1. Gestor de Qualidade seleciona o botão de executar;
2. Ferramenta dispara a rotina de executar do TestComplete;
3. Ferramenta abre uma tela de log de verificação;
4. Ferramenta direciona para a página principal de plano de teste.
UC08 – Manter Vínculo Projeto Automatizado
Permite a ferramenta manter o vínculo dos planos de testes.
Ator: Ferramenta
Pré-condições: O plano de teste sendo cadastrado.
Pós-condição: O plano de teste cadastrado.
Cenário Principal:
1. Gestor de Qualidade informa os campos Suíte, Projeto e Diretório de acordo com o
projeto do TestComplete;
2. Gestor de Qualidade salva o cadastro;
3. Ferramenta direciona para a página principal de plano de teste.
UC09 – Manter Caso de Teste
Permite ao analista de teste manter os casos de testes na ferramenta.
Ator: Analista de Teste
Pré-condições: Um plano de teste cadastrado.
Pós-condição: O caso de testes cadastrado.
Cenário Principal:
1. Analista de Teste preenche campos Planos Testes, Finalidade, Título, Pré-Condição,
Dados de Entrada, Passos do Teste, Resultado Esperado, Situações de Erros, Notas e
Item de Teste;
2. Ferramenta valida os campos obrigatórios;
72
3. Ferramenta direciona para a página principal de caso de teste da ferramenta.
Fluxo Alternativo 1:
1. Planos Testes, Finalidade, Título, Pré-Condição, Dados de Entrada, Passos do Teste,
Resultado Esperado, Situações de Erros, Notas e Item de Teste vazios;
2. Alerta com mensagem “O campo Planos Testes é obrigatório.” é mostrada.
3. Alerta com mensagem “O campo Finalidade é obrigatório.” é mostrada.
4. Alerta com mensagem “O campo Título é obrigatório.” é mostrada.
5. Alerta com mensagem “O campo Pré-Condição é obrigatório.” é mostrada.
6. Alerta com mensagem “O campo Dados de Entrada é obrigatório.” é mostrada.
7. Alerta com mensagem “O campo Passos do Teste é obrigatório.” é mostrada.
8. Alerta com mensagem “O campo Resultado Esperado.” é mostrada.
9. Alerta com mensagem “O campo Situações de Erros.” é mostrada.
10. Alerta com mensagem “O campo Notas.” é mostrada.
11. Alerta com mensagem “O campo Item de Teste.” é mostrada.
Fluxo Alternativo 2:
1. Analista de Teste seleciona o botão de visualizar do cadastro;
2. Analista de Teste visualiza o cadastro;
3. Ferramenta direciona para a página principal de caso de teste.
Fluxo Alternativo 3:
1. Analista de Teste seleciona o botão de editar do cadastro;
2. Analista de Teste edita o cadastro;
3. Gestor de qualidade salva a alteração do cadastro;
4. Ferramenta direciona para a página principal de caso de teste.
Fluxo Alternativo 4:
1. Analista de Teste seleciona o botão de excluir do cadastro;
2. Ferramenta retorna uma mensagem da exclusão “Você tem certeza que deseja excluir
o caso de teste?”;
3. Analista de Teste pressiona o botão Sim;
4. Ferramenta direciona para a página principal de caso de teste.
UC10 – Manter Vínculo Caso de Teste Automatizado
Permite a ferramenta manter o vínculo dos casos de testes.
Ator: Ferramenta
Pré-condições: O caso de teste sendo cadastrado.
Pós-condição: O caso de teste cadastrado.
Cenário Principal:
1. Analista de Teste informa o campo Item de Teste de acordo com o item de teste do
projeto do TestComplete;
2. Gestor de Qualidade salva o cadastro;
3. Ferramenta direciona para a página principal de caso de teste.
UC11 – Emitir Caso de Teste
73
Permite ao analista de teste emitir os casos de testes na ferramenta.
Ator: Analista de Teste
Pré-condições: Um caso de teste cadastrado.
Pós-condição: Imprimir o caso de teste.
Cenário Principal:
1. Analista de Teste seleciona o botão de Imprimir;
2. Ferramenta abre o relatório de caso de teste de acordo com o cadastro selecionado;
3. O Analista de Teste fecha a aba e a ferramenta direciona para a página principal de
caso de teste.
UC12 – Executar Caso de Teste
Permite ao analista de teste executar o caso de teste na ferramenta.
Ator: Analista de Teste
Pré-condições: Um caso de teste cadastrado.
Pós-condição: Executar o caso de teste.
Cenário Principal:
1. Analista de Teste seleciona o botão de executar;
2. Ferramenta dispara a rotina de executar do TestComplete;
3. Ferramenta abre uma tela de log de verificação;
4. Ferramenta direciona para a página principal de caso de teste.
UC13 – Extrair Resultados dos Cenários Executados
Permite a ferramenta extrair os resultados após execução e importar automaticamente na
ferramenta.
Ator: Ferramenta
Pré-condições: Ter um caso executado ou um plano com pelo menos 1 caso associado.
Pós-condição: Importar resultados na tabela de logs de execução.
Cenário Principal:
1. Ferramenta Importa os casos de testes associados aos planos;
2. Ferramenta incluem os registros na tabela de execuções.
UC14 – Consultar Logs de Execução
Permite ao analista de teste consultar os logs de execuções na ferramenta.
Ator: Analista de Teste
Pré-condições: Um caso de teste executado.
Pós-condição: Visualizar o log do caso de teste.
Cenário Principal:
1. Analista de Teste acessa a tela;
2. Ferramenta organizar os status do log de acordo com o resultado;
74
3. Analista de Teste abre uma tela de log de verificação;
4. Analista de Teste retorna para a página principal de log de execução.
UC15 – Realizar Download de Log
Permite ao analista de teste realizar download dos logs de execuções na ferramenta.
Ator: Analista de Teste
Pré-condições: Um log de caso de teste executado.
Pós-condição: Baixar o log de execução.
Cenário Principal:
1. Analista de Teste acessa a tela;
2. Analista de Teste abre uma tela de log de verificação;
3. Analista de Teste baixa o log de execução;
4. Analista de Teste retorna para a página principal de log de execução.
UC16 – Emitir Relatório de Usuários
Permite ao analista de teste emitir relatório dos usuários e seus grupos associados na
ferramenta.
Ator: Analista de Teste
Pré-condições: O cadastro de usuários associado ao grupo.
Pós-condição: Visualizar o relatório de usuário.
Cenário Principal:
1. Analista de Teste acessa o relatório;
2. Analista de Teste visualiza o relatório em outra aba;
3. Analista de Teste fecha a aba e retorna para a página principal.
UC17 – Emitir Relatório de Configuração do Sistema
Permite ao analista de teste emitir relatório das configurações do sistema na ferramenta.
Ator: Analista de Teste
Pré-condições: O cadastro configuração do sistema realizado.
Pós-condição: Visualizar o relatório de configuração do sistema.
Cenário Principal:
1. Analista de Teste acessa o relatório;
2. Analista de Teste visualiza o relatório em outra aba;
3. Analista de Teste fecha a aba e retorna para a página principal.
UC18 – Emitir Relatório de Plano de Teste
Permite ao analista de teste emitir relatório dos planos de testes na ferramenta.
Ator: Analista de Teste
Pré-condições: O cadastro plano de teste realizado.
75
Pós-condição: Visualizar o relatório de plano de teste.
Cenário Principal:
1. Analista de Teste acessa o relatório;
2. Analista de Teste visualiza o relatório em outra aba;
3. Analista de Teste fecha a aba e retorna para a página principal.
UC19 – Emitir Relatório de Caso de Teste
Permite ao analista de teste emitir relatório dos casos de testes associados aos seus planos na
ferramenta.
Ator: Analista de Teste
Pré-condições: O cadastro caso de teste associado ao seu plano de teste.
Pós-condição: Visualizar o relatório de caso de teste associado ao plano de teste.
Cenário Principal:
1. Analista de Teste acessa o relatório;
2. Analista de Teste visualiza o relatório em outra aba;
3. Analista de Teste fecha a aba e retorna para a página principal.
UC20 – Emitir Relatório de Logs de Execução
Permite ao analista de teste emitir relatório dos logs de execução de acordo com o filtro
selecionado na ferramenta.
Ator: Analista de Teste
Pré-condições: Os logs importados.
Pós-condição: Visualizar o relatório de logs de execução de acordo com o filtro
selecionado.
Cenário Principal:
1. Analista de Teste acessa o relatório;
2. Analista de Teste visualiza o relatório em outra aba;
3. Analista de Teste fecha a aba e retorna para a página principal.
76
APÊNDICE B – Descrição do Dicionário de Dados
Este apêndice apresenta o dicionário de dados das tabelas do sistema nos Quadros de
16 a 26 e objetiva fornecer uma breve descrição das tabelas e seus respectivos campos. O
significado de cada tipo de dado de cada campo é descrito abaixo:
a) int: que armazena números inteiros;
b) varchar: que armazena caracteres;
c) longblob: que armazena binário;
d) datetime: que armazena uma data, composta de dia, mês, ano e hora, composta de
hora, minuto e segundo;
e) bit: que armazena zero ou um, zero significa campo desmarcado e um significa
campo marcado.
Quadro 16 - Dicionário de dados da tabela "UserProfile"
UserProfile – Armazena os usuários da ferramenta.
Campo Descrição Tipo Chave Primária
UserId Código do usuário int Sim
UserName Usuário varchar Não
Quadro 17 - Dicionário de dados da tabela "webpages_Membership"
webpages_Membership – Armazena os dados dos usuários da ferramenta.
Campo Descrição Tipo Chave
Primária
UserId Código do usuário int Sim
CreateDate Data de criação datetime Não
ConfirmationToken Confirmação varchar Não
IsConfirmed Confirmado bit Não
LastPasswordFailureDate Última senha falha datetime Não
PasswordFailuresSinceLastSuccess Verificação de falha int Não
Password Senha varchar Não
PasswordChangedDate Data senha alterada datetime Não
PasswordSalt Senha criptografada varchar Não
PasswordVerificationToken Verificação senha varchar Não
PasswordVerificationTokenExpirationDate Expiração de datetime Não
77
verificação
Quadro 18 - Dicionário de dados da tabela "webpages_OAuthMembership"
webpages_OAuthMembership – Armazena a autenticação dos usuários.
Campo Descrição Tipo Chave Primária
Provider Validador Provider varchar Sim
ProviderUserId Código do provider varchar Sim
UserId Código do usuário int Não
Quadro 19 - Dicionário de dados da tabela "webpages_Roles"
webpages_Roles – Armazena os grupos dos usuários.
Campo Descrição Tipo Chave Primária
RoleId Número do grupo int Sim
RoleName Nome do grupo varchar Não
Quadro 20 - Dicionário de dados da tabela "webpages_UsersInRoles"
webpages_UsersInRoles – Armazena o vínculo entre o grupos de usuários com usuários.
Campo Descrição Tipo Chave Primária
UserId FK da tabela UserProfile int Não
RoleId FK da tabela webpages_Roles int Não
Quadro 21 - Dicionário de dados da tabela "__MigrationHistory"
__MigrationHistory – Armazena dados de migração da ferramenta.
Campo Descrição Tipo Chave Primária
MigrationId Código de migração int Sim
ContextKey Código de contexto int Sim
Model Modelo longblob Não
ProductVersion Versão do Produto varchar Não
Quadro 22 - Dicionário de dados da tabela "ConfiguracaoSistema"
ConfiguracaoSistema – Armazena dados da configuração da ferramenta.
Campo Descrição Tipo Chave Primária
IdConfiguracaoSistema Código de configuração int Sim
Descricao Descrição da configuração varchar Não
NomeProjeto Nome do projeto varchar Não
MaquinaInstalacaoFerramenta Máquina de instalação varchar Não
NomeExecutavelFerramenta Nome do executável varchar Não
78
VersaoFerramenta Versão da ferramenta varchar Não
LocalInstalacaoFerramenta Local de instalação varchar Não
LocalLogFerramenta Local do log varchar Não
Quadro 23 - Dicionário de dados da tabela "PlanoTeste"
PlanoTeste – Armazena dados de planos de testes da ferramenta.
Campo Descrição Tipo Chave Primária
IdPlanoTeste Código de plano de teste int Sim
Nome Nome do plano de teste varchar Não
Descricao Descrição do plano de teste varchar Não
Ambiente Ambiente do plano varchar Não
Abordagem Abordagem do plano varchar Não
Treinamento Necessidade de treinamento varchar Não
Produto Produto testado varchar Não
Funcionalidade Funcionalidades testadas varchar Não
ProjetoSuite Suíte do projeto automatizado varchar Não
ProjetoAutomatizado Projeto automatizado varchar Não
DiretorioProjeto Diretório do projeto automatizado varchar Não
IdConfiguracaoSistema FK da tabela ConfiguracaoSistema int Não
Quadro 24 - Dicionário de dados da tabela "CasoTeste"
CasoTeste – Armazena dados de casos de testes da ferramenta.
Campo Descrição Tipo Chave Primária
IdCasoTeste Código de caso de teste int Sim
Finalidade Finalidade do caso de teste varchar Não
Titulo Título do caso de teste varchar Não
PreCondicao Pré-condição para o teste varchar Não
DadosEntrada Dados de entrada do teste varchar Não
PassosTeste Passos do teste varchar Não
ResultadoEsperado Resultado esperado do teste varchar Não
SituacaoErro Situação de erro do teste varchar Não
Notas Notas sobre o teste varchar Não
ScriptAutomatizado Caso automatizado varchar Não
IdPlanoTeste FK da tabela PlanoTeste int Não
79
Quadro 25 - Dicionário de dados da tabela "LogCasoTeste"
LogCasoTeste – Armazena dados de log dos cenários de testes da ferramenta.
Campo Descrição Tipo Chave Primária
IdLogCasoTeste Código de log int Sim
IdCasoTeste FK da tabela CasoTeste int Não
IdPlanoTeste FK da tabela PlanoTeste int Não
IdPlanoCaso Código de Plano ou Caso int Não
TipoLog Tipo de log int Não
Resultado Resultado do log int Não
Inicio Início de execução datetime Não
Fim Fim de execução datetime Não
QuatidadeErros Quantidade de erros no log int Não
QuatidadeAdvertencias Quantidade de advertências no log int Não
TesteFinalizado Teste finalizado sem interrupções bit Não
Log Binário do log gerado longblob Não
Quadro 26 - Dicionário de dados da tabela "PlanoTeste_has_CasoTeste"
PlanoTeste_has_CasoTeste – Armazena o relacionamento entre as tabelas.
Campo Descrição Tipo Chave Primária
IdPlanoTeste FK da tabela PlanoTeste int Não
IdCasoTeste FK da tabela CasoTeste int Não