Avaliacaoefetividadesuite-Pereira-2019

Prévia do material em texto

Iuri Guerra de Freitas Pereira
Avaliação da efetividade de uma suite de teste
de sistema aplicada ao contexto do Middleware
Ginga
Natal-RN
2019
Iuri Guerra de Freitas Pereira
Avaliação da efetividade de uma suite de teste de
sistema aplicada ao contexto do Middleware Ginga
Dissertação de Mestrado apresentada ao Pro-
grama de Pós-graduação em Engenharia de
Software da Universidade Federal do Rio
Grande do Norte como requisito para a ob-
tenção do grau de Mestre em Engenharia de
Software.
Universidade Federal do Rio Grande do Norte – UFRN
Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Engenharia de Software – PPgSW
Orientador: Prof. Dr. Eiji Adachi Medeiros Barbosa
Natal-RN
2019
Pereira, Iuri Guerra de Freitas.
 Avaliação da efetividade de uma suite de teste de sistema
aplicada ao contexto do Middleware Ginga / Iuri Guerra de
Freitas Pereira. - 2019.
 124f.: il.
 Dissertação (Mestrado)-Universidade Federal do Rio Grande do
Norte, Instituto Metrópole Digital, Programa de Pós-Graduação em
Engenharia de Software, Natal, 2020.
 Orientador: Dr. Eiji Adachi Medeiros Barbosa.
 1. Teste de Software - Dissertação. 2. Cobertura de Código -
Dissertação. 3. Teste de Sistema - Dissertação. 4. Efetividade
de Suite de Teste - Dissertação. I. Barbosa, Eiji Adachi
Medeiros. II. Título.
RN/UF/BCZM CDU 004.4
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Elaborado por Raimundo Muniz de Oliveira - CRB-15/429
Dissertação de Mestrado sob o título Um processo de avaliação de efetividade de suíte de
teste de sistema aplicado ao contexto do Middleware Ginga apresentada por Iuri Guerra
de Freitas Pereira e aceita pelo Programa de Pós-graduação em Engenharia de Software
da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros
da banca examinadora abaixo especificada:
Prof. Dr. Eiji Adachi Barbosa
Presidente
IMD – Instituto Metrópole Digital
UFRN – Universidade Federal do Rio Grande do
Norte
Prof. Dr. Bruno Barbieri de Pontes Cafeo
Examinador
FACOM – Faculdade de Computação
UFMS – Universidade Federal de Mato Grosso do
Sul
Prof. Dr. Uirá Kulesza
Examinador
DIMAP – Departamento de Informática Aplicada
UFRN – Universidade Federal do Rio Grande do
Norte
Natal-RN, 11 de Junho de 2019.
Iuri Guerra de Freitas Pereira
Avaliação da efetividade de uma suite de teste de
sistema aplicada ao contexto do Middleware Ginga
Dissertação de Mestrado apresentada ao Pro-
grama de Pós-graduação em Engenharia de
Software da Universidade Federal do Rio
Grande do Norte como requisito para a ob-
tenção do grau de Mestre em Engenharia de
Software.
Trabalho aprovado. Natal-RN, 11 Junho de 2019:
Prof. Dr. Eiji Adachi Medeiros
Barbosa
Orientador
Prof. Dr. Bruno Barbieri de Pontes
Cafeo
Examinador
Prof. Dr. Uirá Kulesza
Examinador
Natal-RN
2019
À minha mãe, que nunca deixou de acreditar no filho.
Agradecimentos
A presente dissertação de mestrado não poderia chegar até onde chegou sem o
precioso apoio de várias pessoas.
Em primeiro lugar, a Deus que me permitiu a oportunidade de estudar, adquirir
conhecimento e usufruir dos meus sentidos para um bem que possa trazer benefícios para
a sociedade. A Ele sou grato pela vida e por mais essa oportunidade de servir.
Em segundo lugar, ao meu orientador, Eiji Adachi Medeiros Barbosa, por toda
paciência, empenho e disciplina com que me orientou durante todo o processo desse
mestrado. O seu auxílio e as suas correções foram fundamentais para que eu pudesse ter o
mínimo de noção de onde estava caminhando rumo a carreira acadêmica.
Agradeço aos meus colegas de trabalho da MOPA Embedded Systems, que me
ajudaram muito no desenvolvimento desse trabalho de pesquisa ao entender o sistema no
qual estava trabalhando. Dhiogo Boza, Enock Gomes e Cláudio Schneider foram muito
pacientes e me ensinaram muito no decorrer de toda a pesquisa.
Agradeço aos meus colegas do mestrado, principalmente ao Heitor Rosa Faustino
dos Santos, que nos momentos mais difíceis não me deixou desistir e, por causa desse
incentivo, estou aqui escrevendo esse agradecimento.
Agradeço ao corpo docente do PPGTI (Programa de Pós-Graduação em Tecnologia
da Informação) e aos funcionários do IMD (Instituto Metrópole Digital).
Por fim, quero agradecer a minha família pelo apoio incondicional, especialmente a
minha mãe que nunca deixou de acreditar em mim e que sempre soube que tudo iria dar
certo.
“Toda ação humana, quer se torne positiva ou negativa, precisa depender de motivação.”
(Dalai Lama)
Avaliação da efetividade de uma suite de teste de
sistema aplicada ao contexto do Middleware Ginga
Autor: Iuri Guerra de Freitas Pereira
Orientador: Prof. Dr. Eiji Adachi Barbosa
Resumo
Qualidade de software tem se tornado um fator fundamental no processo de desenvolvimento
de software atualmente. Conseguir mensurar a qualidade de tipos de testes diversos se torna
hoje um desafio importante a ser atingido. A pesquisa realizada nesse estudo considerou a
avaliação da efetividade de testes de sistemas realizados pela empresa MOPA Embedded
Systems na utilização do middleware Ginga para TV Digital. Para realizar a avaliação
da suite de teste de sistema executada pela empresa, foi proposta uma metodologia de
avaliação da mesma através do critério de cobertura de código, seguida de um estudo
exploratório para investigar possíveis motivos para os resultados obtidos da cobertura.
Por fim foram realizados testes exploratórios com o objetivo de confirmar as descobertas
provenientes da fase de estudo exploratório. Através dessas etapas, foi possível estabelecer
um parecer sobre a qualidade dos testes realizados, bem como da automatização realizada
pela empresa.
Palavras-chave: Teste de Software, Cobertura de Código, Teste de Sistema, Efetividade de
Suíte de Teste.
Evaluation of test suite effectiveness of a system
applied to the context of the Ginga Middleware
Author: Iuri Guerra de Freitas Pereira
Supervisor: Prof. Dr. Eiji Adachi Barbosa
Abstract
Software quality has become a key factor in the software development process nowadays. To
be able to measure the quality of different types of tests is today an important challenge to
be met. The research conducted in this study considered the evaluation of the effectiveness
of systems tests performed by MOPA Embedded Systems in the use of Ginga middleware
for Digital TV. To perform the system test suite evaluation performed by the company, it
was proposed a methodology to evaluate it through the code coverage criterion, followed
by an exploratory study to investigate possible reasons for the results obtained from
the coverage. Finally, exploratory tests were conducted to confirm the findings from the
exploratory study phase. Through these steps, it was possible to establish an opinion on
the quality of the tests performed, as well as the automation performed by the company.
Keywords: Software testing, code coverage, System testing, Test Suite Effectiveness, Testing
Process.
Lista de ilustrações
Figura 1 – Resultado do teste canvas_TC-018_5 no ambiente Desktop . . . . . . . 20
Figura 2 – Posição do texto no caso de teste canvas_TC-018_5 em ambiente Desktop 21
Figura 3 – Evolução do tempo de execução dos testes manuais na MOPA . . . . . 21
Figura 4 – Evolução dos testes manuais na MOPA . . . . . . . . . . . . . . . . . . 22
Figura 5 – Processo de testes na MOPA Embedded Systems . . . . . . . . . . . . 24
Figura 6 – Relação entre níveis, tipos e técnicas de teste . . . . . . . . . . . . . . 28
Figura 7 – Arquitetura do middleware Ginga segunda a norma ABNT NBR 15606-1 33
Figura 8 – Resultado do caso de teste animation_TC-001_1 . . . . . . . . . . . . . 37
Figura 9 – Processo de comparação de imagem pelo Screen-Tester . . . . . . . . . 42
Figura 10 – Trecho do relatório do GCOVR . . . . . . . . . . . . . . . . . . . . . . 45
Figura 11 – Boxplot para a métricaLOC . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 12 – Histograma de linhas de código (LOC) . . . . . . . . . . . . . . . . . . 48
Figura 13 – Histograma de porcentagem de cobertura . . . . . . . . . . . . . . . . . 49
Figura 14 – Histograma de porcentagem de cobertura . . . . . . . . . . . . . . . . . 49
Figura 15 – Gráfico de dispersão da cobertura por LOC . . . . . . . . . . . . . . . 50
Figura 16 – Tempo de experiência dos participantes do questionário . . . . . . . . . 59
Figura 17 – Legenda de referência utilizada no questionário . . . . . . . . . . . . . 60
Figura 18 – Resultado do teste automatizado components_TC-152_1 . . . . . . . . . 68
Figura 19 – Trecho da função createTeamporalAnchor mostrando a chamada da
função UTCTimeIntervalAnchor sem cobertura . . . . . . . . . . . . . 71
Figura 20 – Trecho da função createTeamporalAnchor mostrando a chamada da
função UTCTimeIntervalAnchor com cobertura . . . . . . . . . . . . . 73
Figura 21 – Histograma da cobertura após teste exploratório 1 . . . . . . . . . . . . 75
Figura 22 – Histograma da cobertura após o teste exploratório 2 . . . . . . . . . . 75
Figura 23 – Boxplot comparativo para a métrica cobertura de LOC entre os testes
exploratórios e a amostra inicial . . . . . . . . . . . . . . . . . . . . . . 76
Lista de tabelas
Tabela 1 – Resumo da cobertura extraída dos testes do fórum SBTVD pelo GVOV/G-
COVR em Junho de 2019 . . . . . . . . . . . . . . . . . . . . . . . . . 46
Tabela 2 – Estatística descritiva da métrica LOC . . . . . . . . . . . . . . . . . . 47
Tabela 3 – Estatística descritiva da métrica Cobertura . . . . . . . . . . . . . . . 48
Tabela 4 – Resumo dos participantes do estudo . . . . . . . . . . . . . . . . . . . 54
Tabela 5 – Resumo da quantidade de testes mapeados versus alterados na revisão
manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Tabela 6 – Resumo da quantidade de testes categorizados e modificados por módulo 67
Tabela 7 – Arquivos afetados pelo teste de âncora temporal UTC Time . . . . . . 73
Tabela 8 – Resumo do comparativo entre as baterias de testes . . . . . . . . . . . 74
Tabela 9 – Estatística descritiva comparativa da métrica Cobertura . . . . . . . . 76
Tabela 10 – Caso de teste canvas_TC-018_5 . . . . . . . . . . . . . . . . . . . . . . 93
Tabela 12 – Relatório de cobertura extraído pelo GCOV/GCOVR para os testes
automatizados o Ginga . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Tabela 13 – Mapeamento dos arquivos não exercitados pelos testes automatizados . 113
Tabela 14 – Arquivos afetados pela automatização de parte dos testes do fórum
SBTVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Tabela 15 – Tabela de análise e categorização dos dados coletados nas entrevistas
semiestruturadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Glossário
ABDI Agência Brasileira de Desenvolvimento Industrial
ABNT Associação Brasileira de Normas Técnicas
API Interface de Programação de Aplicações
CSS Cascading Style Sheet
DOM Modelo de Objeto de Documento
GIF Graphics Interchange Format ou Formato para Intercâmbio de Gráficos
HTML Hypertext Markup Language ou Linguagem de Marcação de Hipertexto
IPTV Internet Protocol Television ou Televisão por IP
ISDB-TB Integrated Services Digital Broadcasting Terrestrial ou Serviço Integrado de
Transmissão Digital Terrestre
ITU-T Telecommunication Standardization Sector ou Setor de Normatização das Teleco-
municações
JPEG Joint Photographic Experts Group
LAViD Laboratório de Aplicações de Vídeo Digital
MCTIC Ministério da Ciência, Tecnologia, Inovações e Comunicações
MDIC Ministério da Indústria, Comércio Exterior e Serviços
MF Ministério da Fazenda
MOV Arquivo de vídeo em formato Apple Quicktime
MP3 Tipo de arquivo comprimido de áudio
MPEG Moving Picture Experts Group
MPEG-2 Codec de vídeo formato MPEG
MRE Ministério das Relações Exteriores
NCL Nested Context Language
PDF Portable Document Format
PNG Portable Network Graphics
PUC Pontifícia Universidade Católica
SBTVD Sistema Brasileiro de TV Digital
UFPB Universidade Federal da Paraíba
VoD Video on Demand ou Vídeo sob Demanda
WMA Windows Media Audio
XHTML EXtensible HyperText Markup Language ou Linguagem Extensível para Marca-
ção de Hipertexto
XML Extensible Markup Language
Sumário
Capítulo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1.1 Execução dos testes do Fórum SBTVD . . . . . . . . . . . . . . . . . . . 19
1.1.2 Automatização dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1.3 Benefícios e limitações da automatização . . . . . . . . . . . . . . . . . . 24
1.2 Problema de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3 Objetivo de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.5 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . 26
Capítulo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 28
2.1 Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.1 Níveis de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1.1 Teste de Unidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1.2 Teste de Integração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1.3 Teste de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.2 Tipos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.2.1 Teste de Funcionalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.2.2 Teste Não-Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.2.3 Teste de Regressão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.3 Técnicas de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.3.1 Teste funcional (caixa preta) . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.3.2 Teste estrutural (caixa branca) . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.3.2.1 Critérios de Cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2 O Middleware Ginga . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.1 Arquitetura do Ginga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.2 A linguagem NCL e seus elementos . . . . . . . . . . . . . . . . . . . . . 34
2.2.2.1 Sincronismo com elos e conectores . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.3 O Fórum SBTVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.3.1 Os testes do fórum SBTVD . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Capítulo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3 ANÁLISE DE COBERTURA DOS CASOS DE TESTE DO FÓRUM
SBTVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1 Screen-Tester: Ferramenta de automatização dos testes do Fórum
SBTVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.1 O processo do Screen-Tester . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.1.1 O oráculo de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.1 Critério de cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.2 Infraestrutura de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.3 Sistema alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Análise dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 46
3.3.1 Tamanho dos arquivos do Ginga . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.2 Cobertura de linhas de código do Ginga . . . . . . . . . . . . . . . . . . . 48
3.3.3 Tamanho dos arquivos versus Cobertura . . . . . . . . . . . . . . . . . . . 50
3.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Capítulo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 ESTUDO EXPLORATÓRIO . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Contexto do estudo exploratório . . . . . . . . . . . . . . . . . . . . . 51
4.2 Definições de questões de pesquisa . . . . . . . . . . . . . . . . . . . 52
4.3 Entrevistas semiestruturadas . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.1 Coleta dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Perfil dos participantes das entrevistas . . . . . . . . . . . . . . . . . . . . 53
4.3.3 Análise dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.3.1 QP1: Na opinião dos desenvolvedores, por que ainda é um desafio para a empresa
confiar na automatização dos casos de testes atual do fórum SBTVD? . . . . . 55
4.3.3.2 QP2: Na opinião dos desenvolvedores, qual o motivo pelo qual alguns arquivos
nunca são cobertos ou são cobertos com baixa cobertura pelos testes automatizados? 56
4.3.3.3 QP3: Na opinião dos desenvolvedores, como seria possível aumentar a cobertura? 58
4.4 Survey de validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.1 Confiar na automatização atual dos testes do fórum SBTVD . . . . . . . . 60
4.4.2 Motivo pelo qual alguns arquivos nunca são cobertos pelos testes automatizados 61
4.4.3 Como aumentar a cobertura? . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5 Ameaças a validade do estudo . . . . . . . . . . . . . . . . . . . . . . 62
4.6 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Capítulo 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5 TESTES EXPLORATÓRIOS . . . . . . . . . . . . . . . . . . . . . . 64
5.1 Teste 1 - Configuração de parte dos testes automatizados do fórum
SBTVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.1 Ameaças da viabilidade do teste exploratório 1 . . . . . . . . . . . . . . . 67
5.1.2 Análise dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 Teste 2 - Âncora de conteúdo temporal (UTC) . . . . . . . . . . . . 69
5.2.1 Âncoras de conteúdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.2 Implementação do teste NCL para âncora temporal UTC . . . . . . . . . . 70
5.2.3 Análise de cobertura de código para o teste de âncora temporal . . . . . . 72
5.2.4 Registro e correção de falha de segmentação . . . . . . . . . . . . . . . . 74
5.3 Análise estatística descritiva dos resultados dos testes exploratórios 74
5.4 Ameaças a viabilidade dos testes exploratórios . . . . . . . . . . . . . 76
5.5 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5.1 Limitações da automatização . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5.2 Escopo da suíte do fórum SBTVD . . . . . . . . . . . . . . . . . . . . . . 77
5.5.3 Código Morto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Capítulo 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 79
6.1 Cobertura de código e efetividade da suíte de teste . . . . . . . . . 79
6.2 Trabalhos relacionados no contexto do Middleware Ginga . . . . . . 80
Capítulo 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 83
7.1 O processo de teste da empresa . . . . . . . . . . . . . . . . . . . . . 83
7.1.1 Limitação do ambiente Desktop . . . . . . . . . . . . . . . . . . . . . . . 84
7.2 Limitações da automatização . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.1 Código legado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.3 Efetividade da suíte de teste do Fórum SBTVD . . . . . . . . . . . . 85
7.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.5 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
APÊNDICES 92
APÊNDICE A – CASO DE TESTE: CANVAS_TC-018_5 . . . . . . 93
APÊNDICE B – RELATÓRIO DE COBERTURA - GCOV/LCOV
PARA O GINGA . . . . . . . . . . . . . . . . . . . 99
APÊNDICE C – MAPEAMENTO DOS ARQUIVOS NÃO EXER-
CITADOS PELOS TESTES AUTOMATIZADOS . 113
APÊNDICE D – ARQUIVOS AFETADOS PELA AUTOMATIZA-
ÇÃO DE PARTE DOS TESTES DO FÓRUM SBTVD117
APÊNDICE E – ANÁLISE DOS DADOS DAS ENTREVISTAS . . 119
APÊNDICE F – SURVEY SOBRE AUTOMATIZAÇÃO DOS TES-
TES DO FÓRUM SBTVD . . . . . . . . . . . . . 121
APÊNDICE G – CASO DE TESTE - ÂNCORA DE TEMPO UTC
TIME . . . . . . . . . . . . . . . . . . . . . . . . . 122
18
1 Introdução
Produzir software de qualidade sempre foi um objetivo a ser alcançado, desde os
primórdios da Engenharia de Software. Atualmente, com ambientes tecnológicos e de
negócio em constante e rápida evolução, alcançar tal objetivo é uma demanda cada vez
mais difícil de ser satisfeita. Desta forma, torna-se fundamental a definição, o planejamento
e a realização de processos de controle de qualidade durante o processo de desenvolvimento
do software.
Dentre os diversos processos de controle de qualidade que podem ser realizados
durante o processo de desenvolvimento de software, o Teste de Software é, possivelmente,
um dos mais reconhecidos, sendo identificado em diferentes modelos de qualidade, como
ISO/IEC 12207, ISO/IEC 15504 e CMMI e já amplamente adotado em empresas de
desenvolvimento de software. O Teste de Software pode ser definido como a verificação
dinâmica de que um programa provê comportamentos esperados, de acordo com alguma
especificação, quando exercitado por um conjunto finito de casos de testes.
Apesar dos potenciais benefícios de se adotar o Teste de Software no processo de
desenvolvimento, esta nem sempre é uma tarefa fácil para uma empresa de software. Os
motivos para esta dificuldade são diversos. Crespo et al. (2004) listam as seguintes razões
que justificam a dificuldade em se adotar um processo de teste de software: há falta de
profissionais especializados na área de teste; o teste de software é um processo caro; há
pouco conhecimento sobre a relação do custo-benefício dos testes e há desconhecimento
sobre como planejar o processo de teste de software.
Neste trabalho, apresentaremos uma avaliação da efetividade de uma abordagem
de automatização de testes implementada no contexto da empresa MOPA Embbedded
Systems. Mais especificamente, a abordagem de automatização da suíte de testes aplicada
ao middleware Ginga. No restante deste capítulo, apresentaremos na seção (1.1) o contexto
no qual esse projeto de pesquisa foi desenvolvido, na seção (1.2) o problema de pesquisa,
na seção (1.3) o objetivo da pesquisa, na seção (1.4) a metodologia empregada e na seção
(1.5) uma breve descrição de como os próximos capítulos estão estruturados.
1.1 Contexto
Este projeto de pesquisa foi realizado no contexto da equipe de desenvolvimento
da empresa MOPA Embedded Systems, que trabalha há mais de dez anos no ramo de
software para TV Digital. Dentre suas principais atividades, a MOPA implementa sua
própria versão do Ginga, que é o Middleware de código aberto do Sistema Nipo-Brasileiro
Capítulo 1. Introdução 19
de TV Digital que foi adotado pelo sistema brasileiro de TV Digital em 2007 (Sá, 2015).
Visando garantir a qualidade das mais diversas implementações do middleware e
suas integrações com diferentes arquiteturas de hardware e software, o Fórum do Sistema
Brasileiro de TelevisãoDigital (SBTVD) prevê que o Ginga deve passar por um conjunto
de testes, em conformidade com as especificações da norma ABNT NBR 15606-1 e ABNT
NBR 15606-2.
O resultado dos testes deve ser a base do documento de declaração de fornecedor, o
qual declara a garantia do fornecedor de que o middleware Ginga embarcado na plataforma
alvo está totalmente aderente aos requisitos de um dos perfis definidos na ABNT NBR
15606-1, Seção 9. Da mesma forma, as aplicações interativas enviadas ao receptor, por
qualquer meio físico, devem ser ensaiadas para a validação (ABNT, 2018, p. 35). Ou seja,
é tanto da responsabilidade de quem está implementando o middleware em sua plataforma
quanto de quem está transmitindo aplicações para o middleware, que as aplicações estejam
aderentes à norma.
1.1.1 Execução dos testes do Fórum SBTVD
O fórum SBTVD define uma suíte de testes que visa garantir que uma determinada
implementação do Ginga esteja conforme com a especificação da norma ABNT. Esta suíte
de testes do fórum SBTVD possui atualmente 2.812 casos de teste. Cada caso de teste
definido pelo fórum SBTVD é definido como uma especificação de uma aplicação de TV
Digital que roda sobre o Ginga e de um estado final esperado para esta aplicação (ex.:
após a execução de uma determinada aplicação, é esperado que seja exibido na tela da TV
uma determinada imagem, com um determinado tamanho e numa determinada posição).
Os testes podem ser executados em dois ambientes: num ambiente desktop e
diretamente numa placa de TV, que é a plataforma de hardware considerada o ambiente
de produção do Ginga. O ambiente desktop proporciona ferramentas que possibilitam a
simulação do funcionamento do middleware Ginga no computador, enquanto que na placa
de TV as entradas e saídas são realizadas diretamente com o software embutido na placa.
No contexto da empresa MOPA, inicialmente, os testes do fórum SBTVD eram
executados unicamente de forma manual e diretamente na placa de TV, visto que este é o
ambiente final onde o produto será usado quando for lançado ao mercado. A execução
manual destes testes quer dizer que um testador era responsável por implantar o Ginga
numa plataforma de hardware, por carregar as aplicações de TV digital definidas em cada
caso de teste, por executar essas aplicações, por verificar o resultado final da aplicação e
por registrar o resultado desta verificação numa planilha de controle.
Para demonstrar um exemplo prático de como os testes eram executados e veri-
ficados, e de como a execução manual vinha trazendo alguns problemas de custos para
Capítulo 1. Introdução 20
a empresa, iremos apresentar um exemplo de um caso de teste específico. Tal exemplo,
apesar de simples, apresenta algumas características que dificultavam a tarefa de executá-lo
manualmente. Tais características são comuns a maioria dos 2.812 casos de testes do fórum
SBTVD.
Tomemos o exemplo do caso de teste real canvas_TC-018_5. Para esse caso de teste,
o engenheiro de software responsável pela execução do teste necessita ter a especificação
do caso de teste para entendimento do que deve ser verificado, uma planilha para controle
do resultado do teste e ter à disposição o ambiente onde realizará o teste.1
O caso de teste canvas_TC-018_5 especifica que, após a execução da sua aplicação
de TV digital, deve aparecer na tela uma mídia de imagem com cor azul preenchendo todo
o background da tela. Deve também ser disponibilizada uma mídia de texto com as cores
RGBA (0,57,255,28) com tamanho de 36 pixels, fonte do tipo Tiresias e com o conteúdo
"Testing the RGBA color of text.". Esse texto deverá aparecer numa localização situada
20 pixels à esquerda da tela e 20 pixels ao topo da tela. Como resultado da execução da
aplicação de TV digital deste caso de uso, o Ginga reproduz na tela da TV a imagem
apresentada na Figura 1.
Figura 1 – Resultado do teste canvas_TC-018_5 no ambiente Desktop
Observando a Figura 1, o leitor pode achar que o teste falhou, pois não enxerga a
mídia de texto com as propriedades especificadas, mas o resultado produzido pelo Ginga
está de acordo com o esperado e o teste, na verdade, obteve sim sucesso. O que se percebe
neste caso é uma extrema dificuldade em distinguir o elemento de texto que a aplicação
de TV digital construiu como resultado de sua execução. Note que mesmo realçando a
região onde o texto aparece, como destacado na Figura 2, ainda assim é difícil identificar
a mídia de texto esperada. Por possuir praticamente a mesma cor do background e ainda
1 A especificação completa deste caso de teste, conforme definido pelo fórum SBTVD, e como era usada
na execução manual dos testes, é apresentada no Apêndice A deste documento.
Capítulo 1. Introdução 21
ter um atributo de transparência, é difícil a identificação da mídia de texto. Esse é um
exemplo de como os testes do fórum SBTVD podem gerar ambiguidades e incertezas na
sua verificação quando executados manualmente. Tal característica pode levar o testador
a cometer erros, além de tomar muito tempo para identificar se o teste está fazendo o
que se propõe, bem como anotando o resultado na planilha, procedimento que também é
realizado manualmente para cada teste.
Figura 2 – Posição do texto no caso de teste canvas_TC-018_5 em ambiente Desktop
Durante os testes manuais, três testadores executavam os casos de testes de forma
paralela e selecionando um módulo por vez; cada caso de teste era executado apenas uma
vez por um testador. Ao todo, os 2.812 testes do fórum SBTVD cobrem 16 módulos do
Ginga. Na Figura 3 é mostrada a evolução do custo em horas de trabalho para a execução
dos 2.812 casos de testes em cada release do Ginga que foi submetida aos testes manuais
do fórum SBTVD.
Figura 3 – Evolução do tempo de execução dos testes manuais na MOPA
Capítulo 1. Introdução 22
Na Figura 3 percebe-se uma melhoria no tempo de execução dos testes com o
passar do tempo. Enquanto na primeira versão (release 215) o tempo gasto com os testes
foi de aproximadamente 116 horas, na última versão (release 584) esse total caiu para
aproximadamente 20 horas. Isso pode refletir uma curva de aprendizado dos testadores,
uma vez que não houve rotatividade na equipe que executava os testes nesse período. A
figura 4 apresenta os resultados dessas baterias de testes manuais ao longo da evolução do
Ginga.
Figura 4 – Evolução dos testes manuais na MOPA
Como pode ser percebido na figura 4, o resultado de cada teste manual é classificado
em quatro categorias: PARCIAL, N/A, FAIL e OK. A categoria “PARCIAL” significa testes
que, segundo a interpretação do testador, passaram na especificação, porém apresentaram
mais algum comportamento não especificado. O testador ao se deparar com esse tipo
de teste o categoriza como “PARCIAL” e abre um issue de investigação para resolver
posteriormente e melhorar o processo. “N/A” é a categoria que o testador selecionava
quando não conseguia, por algum motivo, reproduzir o caso de teste. Por exemplo, ainda
não se pode reproduzir casos de teste que executem o protocolo Real Time Streamming
Protocol (RTSP). “FAIL“ é a categoria selecionada quando o teste falha, ou seja, quando ele
não atende a especificação ou quando há alguma falha fatal, como falhas de segmentação,
deadlocks ou loops infinitos, por exemplo. E “OK“ é quando o testador considera que
o teste executa com sucesso, ou seja, o comportamento esperado está coerente com a
especificação do teste e não há necessidade de melhorias.
Ao longo da evolução do Ginga, além da melhoria no tempo de execução, também é
percebida uma melhoria nos resultados dos casos de testes com status de sucesso. Podemos
perceber que na primeira versão (release 215), o número de casos de teste que obtiveram o
status "OK" foi de 1.612 (57,32%). Esse valor foi aumentando com o passar das versões e,
Capítulo 1. Introdução 23
na última, atingiu 2.455 (87,30%) casos de testes com status "OK". O que representa uma
melhoria de 52,29%.
Apesar da melhoria no tempo de execução do testes manuais e nos resultados
obtidos, o processo detestes baseado na execução manual dos testes do fórum SBTVD
ainda apresentava limitações e custo elevado. O fator humano tende a prejudicar a
interpretação dos testes, que são todos de característica audiovisual, o que comprometia a
reprodutibilidade dos testes. Além disso, havia um grande custo associado à reexecução
dos testes manuais quando falhas eram identificadas durante o processo de testes.
Este cenário em que os testes do fórum SBTVD eram executados manualmente
representa o estado em que se encontrava o processo de testes na empresa MOPA anteri-
ormente à realização deste trabalho de pesquisa. Concomitantemente a realização desta
pesquisa, a automatização de testes mostrou-se um investimento necessário e a empresa
MOPA deu início a um processo de automatização dos testes do fórum SBTVD. Na
seção seguinte, será apresentado como se deu o processo de adoção de uma estratégia de
automatização dos testes do fórum SBTVD no contexto da empresa MOPA.
1.1.2 Automatização dos testes
Como dito anteriormente, os testes do fórum SBTVD para o Ginga podem ser exe-
cutados em ambiente desktop, simulando o funcionamento do middleware, ou diretamente
numa placa de TV digital, que é o ambiente onde o Ginga roda em produção. Diante da
necessidade de adotar uma primeira abordagem de automatização dos testes do fórum
SBTVD, a empresa optou por um processo para automatizar a execução destes testes em
ambiente desktop.
Dessa forma, ao realizar testes em ambiente desktop é possível utilizar ferramentas
que capturem entradas do usuário e simulem interações com as aplicações de TV digital que
são usadas para testar o Ginga. Por outro lado, realizar o mesmo procedimento na placa
de TV digital requer instrumentação para captura de entradas e estratégias como gravação
de imagem com câmeras para saídas da TV, tornando esse procedimento mais complexo e
custoso do que o em ambiente desktop. Neste contexto, a abordagem de automatização
dos testes do fórum SBTVD segue o processo visto na figura 5.
Capítulo 1. Introdução 24
Figura 5 – Processo de testes na MOPA Embedded Systems
De acordo com figura 5, após uma modificação no código fonte, que pode ser de
uma nova funcionalidade ou correção de algum bug, o processo de validação dos testes de
conformidade do fórum SBTVD devem ser realizados. Dessa forma, a bateria automatizada
realiza os testes e caso haja alguma falha que indique regressão, um incidente é aberto e o
processo é pausado até que esse incidente seja corrigido, uma nova alteração no código seja
feita e o processo é reinicializado. Havendo sucesso em todo o processo automatizado em
ambiente desktop, os testes devem ser novamente validados no ambiente da placa de TV,
agora de forma manual. Como a placa de TV é o produto final, foi uma decisão estratégica
da empresa continuar realizando os testes manuais na placa de TV digital, mesmo após a
execução dos testes em ambiente desktop de forma automatizada.
1.1.3 Benefícios e limitações da automatização
A bateria de testes automatizada com todos os 2.812 casos de teste do fórum
SBTVD dura cerca de 30 minutos para ser concluída em média. Se compararmos essa
execução com a execução da release manual com o melhor desempenho, há uma melhoria
de desempenho de aproximadamente 20 horas para 30 minutos em média (40 vezes mais
rápido). Essa automatização permite identificar algumas regressões de maneira mais ágil
do que no processo manual empregado pela empresa anteriormente.
No entanto, ainda não está claro até que ponto a abordagem de automatização
dos testes do fórum SBTVD implementada pela empresa MOPA é, de fato, efetiva. Cabe
ressaltar que a automatização realizada pela empresa MOPA baseia-se numa ferramenta
desenvolvida por sua própria equipe de desenvolvimento e que a configuração dos testes foi
realizada de maneira padrão para toda a suíte de testes do fórum SBTVD. Desta forma,
há a possibilidade de que alguns testes não estejam sendo executados adequadamente.
Também existem limitações no ambiente desktop que dificultam ou mesmo impossibilitam
a automatização adequada dos testes, como nos casos em que os testes dependem de
mídias de áudio e vídeo. Portanto, fica claro que o processo de automatização de testes da
Capítulo 1. Introdução 25
empresa encontra-se em um estágio inicial, ainda em fase de amadurecimento e requer
uma análise criteriosa sobre a sua efetividade.
1.2 Problema de Pesquisa
É comum encontrar em pesquisas acadêmicas e na indústria a prática de usar
critérios de cobertura para avaliar suítes de testes no sentido de garantir a sua qualidade,
pois são de fácil compreensão e seu critério de parada de teste é bem estabelecido (GROCE;
ALIPOUR; GOPINATH, 2014) (SCHWARTZ; HETZEL, 2016). A cobertura de código
irá avaliar o quão bem o código cobre os elementos estruturais do sistema (SCHWARTZ;
HETZEL, 2016). Irá medir qual parte do código foi executada pelos testes, porém não
leva em conta se um método foi testado com uma afirmação correta ou se foi executado
sem nenhuma afirmação ou com afirmações incompletas (NIEDERMAYR; JUERGENS;
WAGNER, 2016). Alguns estudos já mostraram que gerar suítes de teste para satisfazer
critérios de cobertura de código tiveram um efeito positivo em achar falhas (GOPINATH;
JENSEN; GROCE, 2014), (NAMIN; ANDREWS, 2009), (NIEDERMAYR; JUERGENS;
WAGNER, 2016), (Gay, 2017), enquanto outros estudos não (INOZEMTSEVA; HOLMES,
2014) e (Gay et al., 2015). O estudo de (INOZEMTSEVA; HOLMES, 2014) sugeriu que o
critério de cobertura, enquanto útil para identificar partes não testadas de um programa,
não deveria ser utilizado como indicador de efetividade para uma suíte de teste, pois a
correlação entre cobertura de código e efetividade era de baixa a moderada para suítes
de teste unitárias considerando um número de casos de testes controlados. Todos esses
estudos, todavia, permeiam o contexto de testes unitários.
Tendo em vista que existem significativos estudos com resultados divergentes quanto
a efetividade de uma suíte de teste estar ou não correlacionada com a cobertura do código,
é possível afirmar que esse campo de estudo na linha de suíte de testes em nível unitário já
vem sendo bem explorado. Todavia quando nos deparamos com suítes de testes em nível
de sistemas, existe uma maior dificuldade de se encontrar pesquisas que definam bem os
critérios para avaliar a efetividade da suíte ou estudem a sua eficiência quanto a encontrar
falhas.
Portanto, no contexto dessa dissertação, o problema consiste em verificar se a
análise de cobertura de código para suíte de teste de sistemas é suficiente para validar a
efetividade dos testes realizados na empresa MOPA.
1.3 Objetivo de Pesquisa
O objetivo de pesquisa geral desse trabalho é:
Realizar um estudo sobre o processo automatizado de teste de sis-
Capítulo 1. Introdução 26
tema implementado pela Empresa MOPA Embedded Systems com
o propósito de analisar a sua efetividade.
São objetivos específicos deste trabalho:
• Avaliar a efetividade da suíte de teste automatizada;
• Identificar e compreender limitações e melhorias potenciais no processo de automati-
zação estabelecido;
• Explorar possibilidades de melhorar o processo de automatização;
1.4 Metodologia
Nesta seção são apresentados os procedimentos adotados para alcançar o objetivo
deste trabalho.
Análise de cobertura: Foi realizada a análise de cobertura de uma versão do
código baseada no critério da data em que a mesma foi lançada. A partir dessa análise, é
possível verificar qual é a influência dos testes automatizados no código fonte.
Estudo exploratório: Foi conduzido um estudo exploratório onde foram realizadas
entrevistas semiestruturadas com os desenvolvedores afim de investigar particularidades
do processo de desenvolvimento e teste de software da empresa. Tais entrevistas foram
fundamentais para entender a natureza dos testes realizados pela empresa e qual a real
dificuldade que a automatização enfrentara para ser confiável. Afim de validar os resultados
obtidos nas entrevistas foi realizado um survey de validaçãocom todos os colaboradores
da empresa.
Testes Exploratórios: A partir de alguns pontos levantados na fase do estudo
exploratório, ficou evidente que era necessário a realização de testes que buscassem validar
alguns pontos levantados na fase do estudo exploratório. Essa fase dos testes exploratórios
investigou dois principais pontos que seriam cruciais para melhorar a cobertura de código
e propôs testes que buscassem melhorar sua métrica. Com o resultado dos testes, era
esperado que se pudesse obter uma conclusão sobre a efetividade da automatização dos
testes automatizados realizados pela empresa.
1.5 Estrutura do Documento
Este trabalho está dividido em 7 capítulos, ficando o restante do documento
estruturado da seguinte forma:
Capítulo 1. Introdução 27
• O Capítulo 2 apresenta conceitos teóricos relacionados a testes de software, middeware
Ginga e o contexto dos testes do fórum SBTVD;
• O Capítulo 3 apresenta a análise de cobertura extraída da automatização com os
testes do fórum SBTVD;
• O Capítulo 4 apresenta o estudo exploratório realizado contendo o resultado das
entrevistas semiestruturadas e do survey de validação;
• O Capítulo 5 discorre sobre dois testes exploratórios decorrentes das conclusões das
entrevistas e seus respectivos resultados;
• O Capítulo 6 apresenta os trabalhos relacionados a esta pesquisa;
• Por fim, o Capítulo 7 trata das considerações finais, propostas para a empresa e
trabalhos futuros.
28
2 Referencial teórico
Este capítulo irá apresentar o referencial teórico que será abordado durante a
pesquisa. A seção (2.1) falará dos testes de software, seus níveis, tipos e as fases em que eles
são empregados. Já a seção (2.2) trata do middleware Ginga, sua arquitetura, a linguagem
NCL e o fórum SBTVD.
2.1 Teste de Software
Teste de Software é definido por Myers e Sandler (2004) como o processo de executar
um programa com o objetivo de encontrar erros. De fato, quando se testa um programa,
deseja-se adicionar algum valor a ele. Adicionar valor através de teste significa incrementar
a qualidade ou confiabilidade do programa. Um aumento na confiabilidade do programa
significa achar e remover erros. Todavia, não se testa um programa para provar que ele
funciona, ao invés disso, é assumido que o programa contém erros e testamos o programa
para encontrá-los (MYERS; SANDLER, 2004).
Podemos dividir os Testes de Software em três dimensões ortogonais. A figura 6
representa estas dimensões de modo visual em um modelo adaptado do trabalho de Crespo
et al. (2004).
Figura 6 – Relação entre níveis, tipos e técnicas de teste
Modelo adaptado do trabalho de (CRESPO et al., 2004)
Como pode ser visto na figura 6, as dimensões do Teste de Software são definidas
Capítulo 2. Referencial teórico 29
em termos de “Quando”, “O que” e “Como” testar o software. A dimensão “Quando testar”
está associada às fases do desenvolvimento do software, definindo testes de software em
diferentes níveis de abstração: Teste de Unidade, Teste de Integração e Teste de Sistema.
Ortogonalmente a esses níveis, está a dimensão “Como” testar, que está relacionada a
qual técnica de teste será escolhida para realizar os testes. Por fim, a dimensão “O que”
testar está relacionada a qual atributo de qualidade será o foco do teste, podendo ser a
funcionalidade ou a característica do software, por exemplo.
O contexto dessa dissertação aborda os testes de conformidade do fórum SBTVD
para TV Digital no middleware Ginga, que são testes funcionais caixa-preta e se enquadram
no nível de testes de sistemas.
2.1.1 Níveis de Teste
Os níveis de teste estão relacionados com as fases do desenvolvimento do software
e dizem respeito mais precisamente a quando determinado teste deve ser empregado. Nas
seções a seguir descrevemos estes níveis.
2.1.1.1 Teste de Unidade
O teste de unidade focaliza o esforço na verificação da unidade, isto é, da menor
unidade testável do projeto de software, tipicamente um componente ou módulo de software
(PRESSMAN, 2009). Esse teste foca na lógica de processamento e as estruturas de dados
dentro dos limites de uma unidade. Geralmente o teste de unidade é considerado um
auxiliar na etapa de desenvolvimento. O projeto de teste de unidade pode ocorrer até
mesmo antes da etapa de codificação começar ou após o código-fonte ter sido gerado.
2.1.1.2 Teste de Integração
O teste de integração buscar verificar se as interdependências das unidades de-
senvolvidas contém erros, ou seja, se duas ou mais unidades conseguem se comunicar
corretamente entre si. Esse nível de teste é considerado uma fase intermediária entre
os testes de unidade e de sistema. Ou seja, após verificarmos a corretude das unidades,
verificamos se a comunicação entre as unidades está correta. Em seguida, verificamos
propriedades de mais alto nível, que são verificadas através de testes de sistema.
2.1.1.3 Teste de Sistema
O teste de sistema tem o objetivo de verificar se todas as funcionalidades e todos
os atributos de qualidade especificados nos documentos de requisitos estão corretamente
implementadas. Ou seja, nos testes de sistemas são verificados não apenas os requisitos
funcionais, mas também os requisitos não-funcionais do sistema. Desta forma, testes de
Capítulo 2. Referencial teórico 30
sistema podem focar em diferentes atributos de qualidade de software, como segurança,
performance, usabilidade, portabilidade, etc.
2.1.2 Tipos de Teste
Os tipos de testes estão relacionados a “O que” testar no programa. Em outras
palavras, estão relacionados a qual o objetivo a ser alcançado pelos testes. Estes objetivos
podem ser: uma funcionalidade que deve ser provida por um determinado módulo do
sistema (Teste de Funcionalidade); um determinado atributo de qualidade que deve ser
atendido num determinado grau (Teste Estrutural); ou garantir que as funcionalidades do
software não regridam ao longo da evolução do sistema (Teste de Regressão).
2.1.2.1 Teste de Funcionalidade
O teste de funcionalidade é o processo de teste que busca encontrar discrepâncias
entre o comportamento do programa e suas especificações externas. Uma especificação
externa é uma descrição precisa do comportamento do programa pela perspectiva do
usuário final. É geralmente uma atividade de técnica caixa-preta (MYERS; SANDLER,
2004).
2.1.2.2 Teste Não-Funcional
Teste Não-Funcional refere-se ao tipo de teste cujo objetivo é verificar se um
determinado atributo de qualidade de software é atendido num determinado grau. Ou seja,
neste tipo de teste, é verificado se e até que ponto um determinado software atende um
requisito não-funcional relacionado a um atributo de qualidade. Este tipo de teste cobre,
tipicamente, atributos de qualidade como segurança, desempenho, confiabilidade, dentre
outros.
2.1.2.3 Teste de Regressão
Teste de regressão é um tipo de teste que objetiva identificar se funcionalidades
do software regrediram ao longo da evolução do sistema. Em outras palavras, objetiva
identificar casos em que funcionalidades que antes funcionavam deixaram de funcionar
devido a mudanças realizadas no sistema. O teste de regressão é realizado após mudanças
no sistema, que podem ser uma melhoria funcional ou uma correção no programa ter sido
realizada. Usualmente é realizado através da execução de um subconjunto de casos de
teste. O teste de regressão é importante porque defeitos tendem a ser introduzidos no
código durante a realização de mudanças e correções de erros.
Capítulo 2. Referencial teórico 31
2.1.3 Técnicas de Teste
As técnicas de teste estão relacionadas ao conceito de como testar o programa. As
principais técnicas de teste são a funcional (não confundir com o teste de funcionalidade
descrito anteriormente), a estrutural e a mutação. Mais detalhes sobre cada um dessas
técnicas nos tópicos a seguir.
2.1.3.1 Teste funcional (caixa preta)
O teste funcional é um teste baseado na especificação, os casos de teste são
construídos baseados apenas no que o documento de especificação diz que ele tem que
fazer e não no que está implementado.Consideram-se apenas entradas e saídas da unidade,
módulo ou componente a ser testado (DELAMARO; MALDONADO; JINO, 2016).
2.1.3.2 Teste estrutural (caixa branca)
A técnica de teste estrutural estabelece os requisitos de teste baseado em uma
implementação, requerendo a execução de partes ou de componentes elementares do
programa. Os caminhos lógicos são testados, fornecendo-se casos que põe a prova tanto
um conjunto específico de condições e/ou laços bem como valores limites de suas variáveis
(DELAMARO; MALDONADO; JINO, 2016).
2.1.3.2.1 Critérios de Cobertura
Critérios de cobertura são métricas tipicamente associadas ao teste estrutural
que expressam qual proporção de um determinado elemento de código de um software é
executada quando se rodam uma suíte de testes.
Os principais critérios de cobertura utilizados são:
• Cobertura por função: Mede quantas funções ou sub-rotinas de um programa
foram executadas.
• Cobertura por statements: Também conhecida como cobertura por linhas de
código, mede quantas vezes que uma linha de código foi executada pelos testes.
• Cobertura por branches: Mede a quantas vezes que uma estrutura de controle
foi executada. Uma estrutura de controle pode ser entendida como um if..else no
código, por exemplo.
• Cobertura por condição: Também conhecida com cobertura de predicado, mede
se cada uma das condição de booleanas foi testada no código.
Capítulo 2. Referencial teórico 32
Quando ao se avaliar suítes de teste, é importante dizer que cobertura de código é
uma métrica meramente quantitativa que não deve ser utilizada para aferir qualidade do
conjunto de teste por si só. Tem por objetivo demonstrar quanto do código foi exercitado
pelo teste e deve ser levada em consideração para verificar em quais pontos do código o teste
passou ou se nunca passou por aquele ponto. É importante frisar que aumentar os índices
de cobertura de uma suíte de teste nem sempre significa que essa suíte de teste estará sendo
efetiva em descobrir falhas para o sistema exercitado por ela (INOZEMTSEVA; HOLMES,
2014) (NIEDERMAYR; JUERGENS; WAGNER, 2016). Por outro lado, suites de teste
que não tenham um bom nível de cobertura necessitam de atenção para melhorias tanto
nos testes que estão sendo executados quanto no código que não está sendo exercitado,
pois claramente levantam a suspeita de que ao não se exercitar parte do código, esse código
obscuro pode esconder falhas.
2.2 O Middleware Ginga
Ginga é o nome do Middleware Aberto do Sistema Nipo-Brasileiro de TV Digital
(ISDB-TB) e Recomendação ITU-T para serviços IPTV (GINGA, 2008). O Ginga é fruto
do desenvolvimento de projetos de pesquisa coordenados pelos laboratórios Telemídia da
PUC-Rio e LAViD da UFPB (GINGA, 2008).
Um middleware é uma camada de software posicionada entre o código das aplicações
e a infra-estrutura de execução (plataforma de hardware e sistema operacional). Um
middleware para aplicações de TV digital consiste de máquinas de execução das linguagens
oferecidas e bibliotecas de funções que permitem o desenvolvimento rápido e fácil de
aplicações.
O ambiente de apresentação Ginga-NCL é o subsistema lógico obrigatório do Ginga,
responsável pela execução de aplicações declarativas Nested Context Language (NCL).
O Ginga trabalha com o conceito de perfis. Cada perfil está relacionado às ca-
racterísticas dos receptores para suportarem o middleware. Atualmente existem 4 perfis,
tratados como perfis A, B, C e D.
Essa pesquisa de mestrado está contextualizada no perfil C do Ginga.
2.2.1 Arquitetura do Ginga
Na figura 7 temos uma visão macro de toda a arquitetura do middleware Ginga.
Como pode ser visto na figura 7, a arquitetura do Ginga segue um modelo em
camadas. A arquitetura tem dois componentes principais: a máquina de execução ou
Ginga-J e a máquina de apresentação (Ginga-NCL e Ginga-HTML5).
Capítulo 2. Referencial teórico 33
Figura 7 – Arquitetura do middleware Ginga segunda a norma ABNT NBR 15606-1
Arquitetura do middleware Ginga segunda a norma ABNT NBR 15606-1
O universo das aplicações Ginga pode ser particionado em um conjunto de aplicações
declarativas e um conjunto de aplicações imperativas. Uma aplicação declarativa pura é
aquela na qual o conteúdo de todas as entidades é do tipo declarativo. Já uma aplicação
imperativa pura é aquela na qual o conteúdo de todas as entidades é do tipo imperativo.
Uma aplicação híbrida é aquela cujo conjunto de entidades possui tanto conteúdo do tipo
declarativo quanto do tipo imperativo. Uma aplicação Ginga não necessita ser puramente
declarativa ou imperativa.
A máquina de execução ou Ginga-J é o subsistema lógico do middleware responsável
pelo processamento de aplicações imperativas escritas utilizando a linguagem Java. É um
item opcional da norma ABNT NBR 15606-4 (SOARES, 2009).
A máquina de apresentação Ginga-NCL é o subsistema lógico do middleware
responsável pelo processamento de aplicações declarativas NCL (Nested Context Language),
e sua linguagem de script Lua compõem a base para o desenvolvimento de aplicações
declarativas no SBTVD (SOARES, 2009).
A máquina de apresentação Ginga-HTML5 é o subsistema lógico que pertence ao
perfil D do Ginga, não tratado nessa dissertação de mestrado. É o subsistema responsável
pelo processamento de aplicações nativas HTML5 conforme especificadas na norma ABNT
NBR 15606-10.
Também vemos o monitor de ciclo de vida de aplicação ou recurso do sistema
operacional para controle do software. Esse componente tem a função de controlar todo o
Capítulo 2. Referencial teórico 34
ciclo de vida da aplicação, incluindo início, término e controle. Cada aplicação pode ser
escrita para as respectivas máquinas de apresentação, para a máquina de execução ou para
ambas. O componente outras mídias é composto de streams de mídia tais como áudio e
dados de monomídias como imagens estáticas e texto (ABNT-NBR-16606-1, 2018).
A máquina de apresentação Ginga-NCL é o foco deste trabalho, pois é por lá que
passam todos os testes do fórum SBTVD. A NCL é uma linguagem declarativa, uma
aplicação XML. Baseada no modelo conceitual NCM (Nested Context Model), a NCL traz
uma separação clara entre os conteúdos de mídia e a estrutura de uma aplicação. Um
documento NCL apenas define como os objetos de mídia são estruturados e relacionados,
no tempo e no espaço. Como uma linguagem de cola, ela não restringe nem prescreve os
tipos de conteúdo dos objetos de mídia de uma aplicação (SOARES; BARBOSA, 2011).
2.2.2 A linguagem NCL e seus elementos
Para que se entenda como uma aplicação de TV digital para o Ginga é criada, é
importante ter algumas noções da linguagem NCL. A linguagem NCL orquestra objetos
de mídia e vários tipos diferentes, relacionando-os no tempo e no espaço, criando o que
se denomina de uma apresentação multimídia. O autor da apresentação deve informar à
máquina de apresentação o que ela deve tocar, onde, como e quando.
Um documento NCL é um aquivo XML cuja estrutura está dividida em duas partes
principais: o cabeçalho (elemento <head>) e o corpo (elemento <body>). No cabeçalho
ficam as bases de informação que especificam onde e como o conteúdo deve ser exibido.
No corpo está descrito o que é o conteúdo e quando ele deve ser exibido.
O nós de mídia (elementos <media>), definem o que tocar, ou seja, quais os
conteúdos que serão exibidos. Os nós de mídia são definidos dentro de um outro tipo de
nó, denominado nó de composição ou contexto (elemento <context>). Pode-se ter objetos
de imagem (GIF, JPEG, etc.), de vídeo (MPEG, MOV, etc.), de áudio (MP3, WMA, etc.),
de texto(TXT, PDF, etc.), de execução(Xlet, Lua, etc.), entre outros, como objeto de
mídia NCL.
Nós de contexto tem a função de encapsular outros nós, que podem ser tanto nós
de mídia como também nós de contexto, recursivamente. Para que seja possível acessar
um nó interno a um contexto, é necessário definir nesse contexto um ponto de entrada ou
porta (elemento <port>) que aponte para tal nó interno. O corpo do documento (elemento
<body>) também é um contexto, que é tratado pela máquinade apresentação como o
contexto principal do documento. Todos os outros nós (de mídia ou de composição) estão
contidos no corpo do documento. Ao encapsular outros nós, um nó de contexto também
tem as funções de estruturar e permitir o reúso de partes de um documento NCL.
Regiões são nós que especificam a informação de onde uma mídia deve ser exibida.
Capítulo 2. Referencial teórico 35
São denominados pelo elemento <region>. Uma região define uma área na tela onde uma
mídia é apresentada. São definidas através da sua posição (top, bottom, left, right), sua
altura (height) e largura (width). Toda região também deve ter um atributo id, que é
utilizado pelo descritor para associá-la a uma ou outras mídias.
Descritor (elemento <descriptor>) são elementos utilizados para associar uma
mídia a uma região. Eles definem como nós de mídia são apresentados. Por exemplo: uma
mídia de áudio pode estar associada a um descritor que estabelece que sua apresentação
ocorre com volume a 50% do original; uma imagem pode ser associada a um descritor
que estabelece uma transparência de 80% entre outros. O descritor também possui um
atributo id que é único e utilizado pelo objeto de mídia para se associar a esse descritor
(SANT’ANNA CARLOS DE SALLES SOARES NETO, 2012).
2.2.2.1 Sincronismo com elos e conectores
Uma aplicação multimídia elaborada requer que seja possível para o autor especificar
os relacionamentos de mídias. Exemplos de relacionamentos de mídia são: quando começar
a exibição da mídia X, deve terminar a exibição da mídia Y; quando terminar a exibição de
X, pausa Y; quando começar X, depois de 2 segundos inicia Y. O uso desses relacionamentos
é uma forma natural para um autor de uma apresentação multimídia especificar quando
uma mídia deve ser exibida.
Os relacionamentos são realizados através de elos (elementos <link>). Para facilitar
a definição dos elos, os mesmos são escritos tendo com base relações hipermídia. Relações
em NCL são escritas como restrições ou sentenças causais, onde uma ação é realizada
quando uma condição é satisfeita. Isso é especificado untilizando conectores (elementos
<causalConnector>).
Conectores são especificados no elemento <connectorBase> dentro do cabeçalho
<head>. No perfil para TV Digital, NCL define apenas os conectores causais. Um conector
causal é definido como um conjunto de papeis de condição que devem ser satisfeitos para a
ativação de elos que usam aquele conector, além de um conjunto de papeis de ações que são
executadas caso elos usando aquele conector se tornem ativos. Em um conector é necessário
que se defina pelo menos uma condição e uma ação. Cada condição ou ação está associada
a um papel (role) que, posteriormente, é associado à âncora de um nó, através de ligações
(elementos <bind>) nos elos. As condições e ações em NCL podem estar associadas tanto
à apresentação como à seleção ou atribuição em nós de mídia (SANT’ANNA CARLOS
DE SALLES SOARES NETO, 2012).
Para demonstrar de forma bem simples o comportamento de uma aplicação NCL,
veremos o caso de teste animation_TC-001_1 na listagem (2.1) que passa pelos conceitos
descritos anteriormente.
Capítulo 2. Referencial teórico 36
1
2 <?xml ve r s i on = ‘ ‘1 .0 ‘ ‘ encoding= ‘ ‘ISO−8859−1 ‘ ‘ s tanda lone = ‘ ‘no ‘ ‘ ?>
3 <nc l xmlns= ‘ ‘ h t tp : //www. nc l . org . br/NCL3.0/ EDTVProfile ‘ ‘ id = ‘ ‘NCL_0‘ ‘>
4 <head>
5 <!−−HEAD_0−−>
6 <regionBase id = ‘ ‘REGIONBASE_0‘ ‘>
7 <reg ion he ight = ‘ ‘200 ‘ ‘ id = ‘ ‘REGION_0‘ ‘ r i g h t = ‘ ‘50 ‘ ‘ top = ‘ ‘300 ‘ ‘
width = ‘ ‘200 ‘ ‘/>
8 </ reg ionBase>
9 <desc r ip to rBase id = ‘ ‘DESCRIPTORBASE_0‘ ‘>
10 <de s c r i p t o r id = ‘ ‘DESCRIPTOR_0‘ ‘ r eg i on = ‘ ‘REGION_0‘ ‘ />
11 </ desc r ip to rBase>
12 <connectorBase id = ‘ ‘CONNECTORBASE_0‘ ‘>
13 <causalConnector id = ‘ ‘CAUSALCONNECTOR_0‘ ‘>
14 <simpleCondit ion r o l e = ‘ ‘ onBegin ‘ ‘>
15 <!−−SIMPLECONDITION_0−−>
16 </ simpleCondit ion>
17 <simpleAct ion eventType= ‘ ‘ a t t r i bu t i on ‘ ‘ r o l e = ‘ ‘ set ‘ ‘ va lue
= ‘ ‘450 ‘ ‘>
18 <!−−SIMPLEACTION_0−−>
19 </ simpleAct ion>
20 </ causalConnector>
21 </connectorBase>
22 </head>
23 <body id = ‘ ‘BODY_0‘ ‘>
24 <port component= ‘ ‘MEDIA_0‘ ‘ id = ‘ ‘PORT_0‘ ‘ />
25 <media d e s c r i p t o r = ‘ ‘DESCRIPTOR_0‘ ‘ id = ‘ ‘MEDIA_0‘ ‘ s r c = ‘ ‘medias/
images /sampleImg04 . png ‘ ‘ type= ‘ ‘ image/png ‘ ‘>
26 <property name= ‘ ‘ r i ght ‘ ‘>
27 <!−−PROPERTY_0−−>
28 </property>
29 </media>
30 <l i n k id = ‘ ‘LINK_0‘ ‘ xconnector = ‘ ‘CAUSALCONNECTOR_0‘ ‘>
31 <bind component= ‘ ‘MEDIA_0‘ ‘ r o l e = ‘ ‘ onBegin ‘ ‘>
32 <!−−BIND_0−−>
33 </bind>
34 <bind component= ‘ ‘MEDIA_0‘ ‘ i n t e r f a c e = ‘ ‘ r i ght ‘ ‘ r o l e = ‘ ‘ set ‘ ‘>
35 <!−−BIND_1−−>
36 </bind>
37 </ l i n k>
38 </body>
39 </ nc l>
Listing 2.1 – Caso de teste animation_TC-001_1
Na listagem (2.1) vemos que no cabeçalho (<head>), na linha 4, é demarcada uma
Capítulo 2. Referencial teórico 37
região com 200 pixel de largura por 200 pixels de altura e posicionada 50 pixels à direita e
300 pixels acima da tela. Essa região é encapsulada dentro de um container <regionBase>.
Na linha 9, o container <descriptoBase> é definido e dentro dele o <descriptor> irá
associar a região com a mídia através do seu identificador. Na linha 12 é definido o container
<connectorBase> e dentro dele os papeis e as condições que a mídia estará sujeita. No
caso do exemplo temos o container <causalConnector>, que encapsula duas condições
simples que definem um papel (role) no início da apresentação (onBegin) e outro papel
do tipo set para um tipo de evento de atribuição para o valor 450. Em resumo, quando a
mídia inicia, alguma atribuição será setada para o valor 450.
No corpo do documento <body>, primeiramente é descrita a porta para associar
qual o primeiro nó de mídia a ser tocado, através do atributo <component>. Isso é feito
na linha 24. Logo após a mídia que será mostrada é importada na linha 25 e associada ao
descritor. Logo após na linha 26, definimos a propriedade da mídia que será alterada pela
condição causal. Na linha 29 fazemos os relacionamentos entre os componentes. Dizemos
que quando a mídia iniciar, imediatamente a propriedade right será atribuída o papel set
que muda o valor da mesma para 450. Ou seja, A imagem terá que mudar de 50 pixels
para 450 pixels à direita da tela.
Como resultado da implementação acima, vemos o seguinte resultado na figura 8.
Figura 8 – Resultado do caso de teste animation_TC-001_1
2.2.3 O Fórum SBTVD
Para implantar o Sistema Brasileiro de TV Digital, o governo brasileiro estimulou
a criação de um fórum como órgão de apoio do comitê de desenvolvimento. O Fórum
Sistema Brasileiro de TV Digital (SBTVD) é composto, entre outros, por representantes
Capítulo 2. Referencial teórico 38
do setor de radiodifusão, do setor industrial e da comunidade científica e tecnológica.
As atividades do fórum tiveram início em 2006 e, segundo Filho (2007), tiveram a
proposta de promover a definição, desenvolvimento, planejamento, implantação e imple-
mentação dos padrões técnicos voluntários ou obrigatórios do Sistema Brasileiro de TV
Digital por meio de:
• identificação e harmonização dos requisitos;
• definição das especificações técnicas;
• coordenação da cooperação técnica entre as indústrias eletroeletrônica e de radiodi-
fusão;
• organização e divulgação das especificações técnicas referentes ao SBTVD a serem
elaboradas e que incluem sistemas voltados para geração, distribuição e recepção
para a televisão digital, incluindo, porém não se limitando àqueles referentes à alta
definição;
• desenvolvimento de soluções para questões relacionadas à propriedade intelectual no
processo de implantação do SBTVD;
• promoção de discussões e soluções para questões relacionadas aos recursos humanos
do SBTVD.
O resultado dessas definições e planejamentos resultou nas normas técnicas da
ABNT que descrevem como o middleware deve se comportar para as diversas plataformas
e formatos.
2.2.3.1 Os testes do fórum SBTVD
A suíte de teste do fórum SBTVD é resultado de estudose reuniões do fórum que
culminaram em casos de teste de conformidade para garantir que as implementações do
middleware estivessem aderentes às normas ABNT, especialmente às aplicações interativas
de natureza declarativa. Foram elaborados 2.812 casos de testes com formato semelhante
ao apresentado no apêndice (A) desse documento. Esses documentos ficaram à disposição
das entidades associadas ao fórum SBTVD e a implementação dos casos de testes era de
responsabilidade de cada parte. Os casos de teste do fórum SBTVD, quando interpretados,
gerariam uma aplicação declarativa NCL que seria executava pelo middleware, funcionando
como entrada do sistema e, em caso de ser executada com sucesso, geram as saídas
esperadas para o caso de teste na tela conforme especificadas pela especificação do fórum
SBTVD.
Capítulo 2. Referencial teórico 39
Haja visto que cada entidade pode ter a sua própria implementação do Ginga em
linguagens de programação distintas, as mesmas têm que atender aos critérios estabelecidos
pelas normas ABNT para que a sua implementação do middleware esteja conforme. A
principal maneira pela qual se verifica que a implementação está conforme atualmente é
executando os casos de teste do fórum SBTVD. Nada impede que entidades criem seus
próprios casos de teste, porém se alguma entidade associada ao fórum SBTVD considerar
que algum caso de teste da suíte de teste oficial deve ser removida ou acrescentar algum
novo caso de teste, esse procedimento deve ser realizado mediante reuniões do módulo
técnico e aprovação de seus membros.
40
3 Análise de Cobertura dos casos de teste do
Fórum SBTVD
Como já visto anteriormente, esta dissertação foi realizada no contexto da equipe
de desenvolvimento da empresa MOPA Embedded Systems, mais especificamente, no
contexto do processo de testes do middleware Ginga. Tal processo baseia-se fortemente na
suíte de 2.812 casos de testes definidos pelo fórum do Sistema Brasileiro de TV Digital
(SBTVD). Os testes do fórum SBTVD são obrigatoriamente executados pela empresa
porque seus resultados servem de base ao documento de declaração do fornecedor, o qual
deve garantir que o middleware Ginga esteja totalmente aderente aos requisitos de um dos
perfis definidos na norma ABNT NBR 15606-1, Seção 9 (ABNT, 2018, p. 35).
Os casos de testes do fórum SBTVD são definidos como especificações de aplicações
NCL que exercitam o código do middleware Ginga. Estes testes visam cobrir requisitos
funcionais e não-funcionais de diferentes funcionalidades do middleware e não requerem o
conhecimento do seu código-fonte para serem executados e verificados. Sendo assim, os
testes do fórum SBTVD podem ser categorizados como testes funcionais (caixa-preta) no
nível de sistema.
Inicialmente, os casos de teste do fórum SBTVD eram executados manualmente por
testadores, num processo lento e tedioso. Ao longo do tempo, a equipe de desenvolvimento
buscou automatizar estes testes e, para isso, desenvolveu a ferramenta de automatização
para ambiente desktop chamada de screen-tester, que utiliza uma estratégia de teste
denominada Record and Replay. Essa estratégia é uma maneira de automatizar os testes
sem que exista necessariamente o conhecimento do código. A ferramenta screen-tester
permite que ações pré-determinadas sejam configuradas em um arquivo de configuração
e lidos para cada caso de teste. Dessa forma, o teste pode ser gravado e sua saída pode
depois ser comparada com o estado corrente da aplicação. Essa comparação realizada pelo
screen-tester é denominada na literatura de oráculo de teste (Barr et al., 2015). O oráculo
de teste é um instrumento, diferente do sistema sob teste, pelo qual se decide se uma
determinada saída de uma execução do sistema está de acordo com a saída esperada.
Resumidamente, o screen-tester automatiza a execução do Ginga e das aplicações
NCL especificadas pelos testes do fórum SBTVD e emula entradas que simulam os botões
do controle remoto da TV através de uma estratégia Record and Replay. Para verificar
o comportamento da versão atual do Ginga, a screen-tester registra um screen shot do
estado final da aplicação NCL para cada caso de teste e compara-o a uma imagem que
representa o estado final da mesma aplicação NCL numa versão anterior do Ginga. Isso
é o que pode-se denominar de oráculo de teste para o sistema. Desta forma, é realizado
Capítulo 3. Análise de Cobertura dos casos de teste do Fórum SBTVD 41
um tipo de teste de regressão para verificar se mudanças realizadas no código do Ginga
introduziram mudanças no comportamento das aplicações NCL.
É importante ressaltar que o processo de teste adotado pela empresa MOPA
encontra-se em um estágio de maturidade inicial, evoluindo de um estágio em que o
processo de testes baseava-se na execução manual dos testes do fórum SBTVD para um
estágio em que o processo de teste passa a contar com uma suíte de testes automatizados
para identificar regressões durante os ciclos de desenvolvimento. Cabe ressaltar também
que, num momento posterior, os testes do fórum SBTVD são executados manualmente no
ambiente da placa da TV, que é o ambiente em que o Ginga será operado em produção.
Neste contexto de maturação do processo de testes da empresa MOPA, em especial
da automatização dos testes do fórum SBTVD, percebeu-se a necessidade de avaliar e
mensurar a efetividade da suíte de testes automatizados executada em ambiente desktop
com o apoio da ferramenta screen-tester. Considerando que a suíte de testes automatizados
está exercitando o código-fonte do middleware Ginga através da execução das aplicações
NCL, decidimos avaliar o grau em que o código do Ginga é exercitado nesta estratégia de
automatização dos testes do fórum SBTVD. Em outras palavras, usaremos um critério de
cobertura como um critério de avaliação da efetividade da suíte de teste. Assim, é esperado
coletarmos dados iniciais que evidenciem até que ponto a suíte de testes automatizando os
casos de testes do fórum SBTVD realizada pela empresa MOPA cobre as principais partes
do código do Ginga, apoiando a equipe de desenvolvimento a decidir se e até que ponto
tal suíte é minimamente efetiva em detectar defeitos no código do middleware Ginga.
Este capítulo está dividido da seguinte forma: Na seção (3.1) é descrita a ferramenta
desenvolvida pela empresa para automatização dos testes visuais. Na seção (3.2) é descrita
a metodologia utilizada para coletar e analisar os dados da cobertura dos testes do fórum
SBTVD, e na seção (3.3) são mostrados o resultados obtidos com a análise da cobertura
dos testes.
3.1 Screen-Tester: Ferramenta de automatização dos testes do Fó-
rum SBTVD
Para apoiar a automatização dos testes do fórum SBTVD, a empresa MOPA
desenvolveu a ferramenta denominada screen-tester 1. Essa ferramenta é escrita em
linguagem C++, encontra-se em fase de desenvolvimento contínuo dentro da empresa e
foi pensada para auxiliar no processo de verificação dos testes de sistema realizados pela
empresa que lidem com comparação de imagens e entradas de usuários.
1 A ferramenta screen-tester foi desenvolvida em paralelo à pesquisa, mas não configura um trabalho
fruto da mesma.
Capítulo 3. Análise de Cobertura dos casos de teste do Fórum SBTVD 42
Os testes do fórum SBTVD são, basicamente, simulações de aplicações para TV
Digital rodando sobre o middleware Ginga. Isto é, os testes são definidos como aplicações
multimídia NCL que apresentam mídias diversas, como texto, imagem, vídeo e áudio, em
uma determinada sequência ao usuário final numa tela de TV. Os testes definem ainda o
estado final esperado para cada aplicação NCL, especificando qual o conteúdo deve ser
exibidos na tela, incluindo a especificação das propriedades deste conteúdo, como cor,
tamanho ou posicionamento. Por este motivo, a screen-tester foi projetada para trabalhar
com o conceito de oráculo de teste (Barr et al., 2015), onde o oráculo são imagens referentes
aos estados finais das aplicações NCL gravados em um determinado momento em que o
sistema está sendo executado.
A ferramenta executao middleware Ginga em ambiente desktop em uma estratégia
Record and Playback e, para os testes do fórum SBTVD, faz a captura e comparação de
imagens para verificar o estado da aplicação com um estado previamente tido como correto.
O processo macro pelo qual a ferramenta funciona pode ser visto na seção (3.1.1).
3.1.1 O processo do Screen-Tester
O processo apoiado pela ferramenta é apresentado na figura a seguir.
Figura 9 – Processo de comparação de imagem pelo Screen-Tester
caixas cinzas são etapas automatizadas e caixas claras são etapas manuais
A figura 9 mostra basicamente o funcionamento do processo da ferramenta screen-
tester. Ela aguarda um determinado intervalo de tempo configurável para cada caso de
teste e captura uma imagem que servirá de oráculo do teste. Esse oráculo é salvo em um
diretório com o nome do caso de teste correspondente. A ferramenta é então configurada
para executar cada caso de teste e comparar com o seu oráculo correspondente. O oráculo
de tese é uma imagem que foi capturada uma única vez e guardada em um servidor único.
Todas as versões do Ginga que irão sofrer alterações terão que ser comparadas com esse
oráculo, que está salvo no servidor. Conforme o processo da figura 9, caso as duas imagens
sejam iguais, o caso de teste "PASSA", caso contrário ele "FALHA". Em caso de falha
uma pasta de erro com o nome do caso de teste é criada com as duas imagens que foram
Capítulo 3. Análise de Cobertura dos casos de teste do Fórum SBTVD 43
consideradas diferentes pelo algoritmo de comparação. Nesse momento o testador precisa
avaliar as imagens e verificar se o erro que foi registrado no teste corresponde realmente a
uma falha no teste ou se houve alguma mudança no código que necessitasse de alteração
no oráculo de teste. Havendo a necessidade de alterar o oráculo de teste, o mesmo é
modificado manualmente no repositório.
3.1.1.1 O oráculo de teste
O oráculo de teste é criado em um modo da ferramenta screen-tester que roda
todos os testes com um parâmetro de configuração habilitado para, ao invés de comparar as
imagens, capturar a imagem em um intervalo de tempo configurável e defini-la como sendo
a representação correta para aquele caso de teste. Esse processo é realizado uma única vez
como uma forma de calibrar o servidor, salvando todos os oráculos como imagens de um
estado final a aplicação em um servidor. Quando há mudanças no código que impliquem a
mudança de algum caso de teste esse procedimento é realizado no processo apresentado na
figura 9.
Por padrão, o screen-tester foi configurado para comparar o estado da aplicação
com o seu oráculo no tempo de 5 segundos para todos os testes.
A ferramenta utiliza um conjunto de ferramentas auxiliares:
• Xvfb (X11): também conhecido como X virtual framebuffer, é um servidor de
display que implementa o protocolo de servidor de display X11. O Xvfb realiza todas
as operações gráficas na memória virtual sem mostrar nenhuma tela de saída. O
uso primário desse servidor é para ser um servidor de testes (WIKIPEDIA, 2019)
(WIGGINS, 2019).
• xdotool (X11): é uma ferramenta de instruções que permite aos programadores
emularem o pressionamento de teclas do teclado e mouse, além de manipular janelas.
• ImageMagick: é um conjunto de aplicações para edição não interativa de imagens,
ou seja, com ele é possível editar, converter, combinar imagens de diversos tipos
(LLC, 2019).
• ctest (CMake): o executável ctest é o programa de teste do CMake. É gerado através
do CMake quando suas flags de compilação ENABLE_TESTING e ADD_TEST são
suportadas no build do Ginga. Esse programa roda os testes e reporta os resultados
(KITWARE; CONTRIBUTORS, 2019).
O Xvfb cria um framebuffer virtual. Combinado com xdotool e o ImageMagick é
possível enviar e capturar eventos da aplicação e tirar snapshots para então comparar essas
imagens entre si. Os testes são parametrizados através do framework do GoogleTest, de
Capítulo 3. Análise de Cobertura dos casos de teste do Fórum SBTVD 44
forma que o caso de teste é um arquivo de configuração (um para cada teste) que contém
o caminho da aplicação NCL, as instruções de entrada e saída (quando necessário), o
caminho para a imagem do oráculo, que vamos chamar aqui de golden sample, e o tempo
de espera para o snapshot. Segue um exemplo do caso de teste animation_TC-001_1:
1 MAIN_FILE=$GINGA_TESTS_PATH/Testes−ForumSBTVD/NCL/animation /animation_TC
−001_1/main . nc l
2 GOLDEN_SAMPLE=golden . png
3 INITIAL_DELAY=5
Listing 3.1 – test.sh - Caso de teste parametrizado para o animation_TC-001_1
No exemplo da listagem (3.1) acima o screen-tester irá executar a aplicação em
NCL_MAIN_FILE, esperar 5 segundos e tirar um snapshot e depois comparar com a
golden.png, que é a imagem congelada do tempo de execução da aplicação no tempo de
5 segundos. Isso se repete para todos os casos de teste do fórum SBTVD. Apesar da
ferramenta permitir mais opções e flexibilidade de automatização, a empresa ainda não
trabalhou nesse sentido e as automatizações que se tem hoje são tipicamente semelhantes
as do exemplo acima.
3.2 Metodologia
Esta pesquisa tem o objetivo de avaliar a efetividade da suíte de teste automatizada
do fórum SBTVD com o propósito de verificar a sua capacidade de encontrar falhas através
da métrica de cobertura de código. Esse objetivo visa ser alcançado do ponto de vista do
desenvolvimento no contexto de uma empresa de desenvolvimento de software para TV
Digital.
3.2.1 Critério de cobertura
Foi considerada a análise de cobertura por linha (LOC). Essa abordagem foi
escolhida por permitir maior granularidade ao se analisar o código. É possível enxergar
com maior clareza quais partes do código foram atingidas ou não pelos testes. No contexto
dessa pesquisa é importante identificar quais são as partes que nunca são exercitadas pelos
testes, de forma clara e precisa. Também é importante observar que estamos analisando
testes de sistema, onde um teste exercita várias linhas de vários arquivos do sistema. A
cobertura por branch é uma opção que, aliada com a cobertura por linha, torna a análise
da cobertura ideal para testes unitários, porém ao lidar com testes de sistemas, não temos
um feedback tão direto relacionado ao teste que está sendo executado e aos arquivos que
esse teste está atingindo. A melhor métrica, portanto, dentro das características dessa
pesquisa, é a de cobertura por linha de código.
Capítulo 3. Análise de Cobertura dos casos de teste do Fórum SBTVD 45
O Ginga-NCL é escrito em C++ com o compilador GCC2. O GCC possui uma
ferramenta de análise de cobertura denominada GCOV que já vem distribuída no pacote
do GCC. Para poder obter as métricas de cobertura de código dos arquivos é necessário
compilar esse arquivos através do GCC com as flags de compilação relacionadas a cobertura
como demonstrada abaixo:
1 g++ arquivo . cpp −g −O0 −−coverage − f p r o f i l e −a r c s − f t e s t −coverage
Listing 3.2 – Exemplo de como habilitar a cobertura de código em um arquivo .cpp
Foi utilizada a ferramenta GCOVR (AUTHORS, 2019) que é um utilitário para
extrair relatórios do GCOV e permite extrair e visualizar relatórios de cobertura em
formato HTML. O GCOV foi utilizado na versão 8.3.0 e o GCOVR na versão 4.2.
Uma vez que o build tenha sido realizado com as flags de compilação, cada vez que
uma aplicação NCL referente a um teste do fórum SBTVD for executada, serão gerados
múltiplos arquivos de cobertura (no formato do GCOV) para cada arquivo pelo qual o
teste foi exercitado. Já sabemos que os testes em questão são testes de sistema e, portanto,
sabemos que eles irão, por definição, exercitar diversas unidades do sistema alvo.
O Ginga foi preparado para ser executado gerando dados de cobertura para cada
teste. O screen-tester foi configurado para rodar os 2.812 testes com o tempo de delay
padrão de 5 segundos para cada teste. Após finalizado esse processo, foi utilizada a
ferramenta GCOVR para gerar um relatório em html contendo todas as informações dos
dados da cobertura da execução dos testes. O relatório