2019-tcc-rnmendonca

Prévia do material em texto

UNIVERSIDADE FEDERAL DO CEARÁ
CENTRO DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
CURSO DE GRADUAÇÃO EM ENGENHARIA ELÉTRICA
RODRIGO NAGY MENDONÇA
METODOLOGIA DE TESTE DE SISTEMAS EMBARCADOS APLICADA A
MEDIDORES INTELIGENTES E SISTEMAS DE MEDIÇÃO CENTRALIZADA
FORTALEZA
2019
RODRIGO NAGY MENDONÇA
METODOLOGIA DE TESTE DE SISTEMAS EMBARCADOS APLICADA A MEDIDORES
INTELIGENTES E SISTEMAS DE MEDIÇÃO CENTRALIZADA
Trabalho de Conclusão de Curso apresentado ao
Curso de Graduação em Engenharia Elétrica do
Centro de Tecnologia da Universidade Federal
do Ceará, como requisito parcial à obtenção do
grau de bacharel em Engenharia Elétrica.
Orientador: Prof. Dr. Sérgio Daher
FORTALEZA
2019
Dados Internacionais de Catalogação na Publicação 
Universidade Federal do Ceará
Biblioteca Universitária
Gerada automaticamente pelo módulo Catalog, mediante os dados fornecidos pelo(a) autor(a)
M497m Mendonça, Rodrigo Nagy.
 METODOLOGIA DE TESTE DE SISTEMAS EMBARCADOS APLICADA A MEDIDORES
INTELIGENTES E SISTEMAS DE MEDIÇÃO CENTRALIZADA / Rodrigo Nagy Mendonça. – 2019.
 63 f. : il. color.
 Trabalho de Conclusão de Curso (graduação) – Universidade Federal do Ceará, Centro de Tecnologia,
Curso de Engenharia Elétrica, Fortaleza, 2019.
 Orientação: Prof. Dr. Sérgio Daher.
 1. Medidores Inteligentes. 2. Sistemas de Medição Centralizada. 3. Metodologia de Teste. 4. Livro de
Teste. 5. Caso de Teste. I. Título.
 CDD 621.3
UFC
Caixa de texto
Metodologia de teste de sistemas embarcados aplicada a medidores inteligentes e sistemas de medição centralizada
UFC
Caixa de texto
medição centralizada / Rodrigo Nagy Mendonça. – 2019. 
UFC
Caixa de texto
62 f. : il. color
RODRIGO NAGY MENDONÇA
METODOLOGIA DE TESTE DE SISTEMAS EMBARCADOS APLICADA A MEDIDORES
INTELIGENTES E SISTEMAS DE MEDIÇÃO CENTRALIZADA
Trabalho de Conclusão de Curso apresentado ao
Curso de Graduação em Engenharia Elétrica do
Centro de Tecnologia da Universidade Federal
do Ceará, como requisito parcial à obtenção do
grau de bacharel em Engenharia Elétrica.
Aprovada em: 21 de Junho de 2019
BANCA EXAMINADORA
Prof. Dr. Sérgio Daher (Orientador)
Universidade Federal do Ceará (UFC)
Prof. Dr. Diego de Sousa Madeira
Universidade Federal do Ceará (UFC)
Engª. Debora Pereira Damasceno
Universidade Federal do Ceará (UFC)
Dedico este trabalho aos meus pais Raimundo
Mendonça e Nildete Nagy
E aos meus irmãos Anderson Nagy e Natália
Nagy.
AGRADECIMENTOS
Gostaria de agradecer imensamente aos meus pais Raimundo Mendonça e Nildete
Nagy por todo o apoio e por sempre terem acreditado no meu potencial. Mesmo com as
dificuldades que a vida impôs, a educação sempre foi tida como prioridade em nossa família. Eu
amo muito vocês. Agradeço também aos meus irmãos Anderson e Natália, com vocês aprendi
que a vida é muito melhor quando se tem alguém para dividir os momentos especiais.
Agradeço aos meus amigos Debora, Graça, Isadora, Jander, Judá, Monilson, Nael,
Rayssa e Suzane, vocês foram a família que escolhi e aprendi a amar. Cada um do seu jeito,
sempre conseguiram arrancar de mim as melhores risadas e, durante todos esses anos, comparti-
lharam comigo momentos de grande felicidade e de apoio nas horas mais difíceis. Vocês são
realmente raros.
Agradeço ao Eliseu pelo ombro amigo e por ter me escutado todas as vezes que as
dificuldades apareceram e que precisei desabafar. O incentivo dado por você me fez ter forças
para concluir esse trabalho. O meu mais especial muito obrigado.
Agradeço ao professor Sérgio Daher pelo suporte dado, muito obrigado pela atenção
e disponibilidade.
Agradeço à banca pelas valiosas sugestões de melhoria deste trabalho.
Agradeço aos amigos da Eletra Energy Solutions, foram anos de grande aprendizado.
Agradeço à coordenação da Engenharia Elétrica, em especial à Adely por toda ajuda
dada durante a graduação.
Agradeço à Universidade Federal do Ceará pelo ensino de qualidade.
Por fim, agradeço aos amigos que passaram por minha vida, aos que ficaram e aos
que hoje não são tão presentes, com certeza vocês me ajudaram muito nesta conquista.
“Para criaturas tão pequenas como nós, a imensi-
dão só é suportável através do amor.”
(Carl Sagan)
RESUMO
Neste trabalho é sugerida uma metodologia de teste de sistemas embarcados aplicada a Medidores
Inteligentes e Sistemas de Medição Centralizada. O objetivo desta metodologia é definir as
equipes que compõe o fluxo de desenvolvimento de um sistema e estabelecer o papel de cada
uma delas, além de determinar a estrutura básica dos Livros de Teste e dos Casos de Teste. A
metodologia de teste proposta é implementada em amostras de Medidores Inteligentes e de
Sistemas de Medição Centralizada, que são submetidas à avaliação de hardware e software
através da execução dos Livros de Teste. É feita também a análise dos dados obtidos na execução
dos Casos de Teste e o estudo dos problemas relatados ao setor de Pesquisa e Desenvolvimento,
além disso os problemas identificados são classificados em graus de criticidade, níveis de
prioridade de resolução e capacidade de reprodução. Os resultados obtidos com a execução dos
Livros de Teste são apresentados. E por fim, é avaliado o emprego da metodologia na melhoria
do produto final entregue ao mercado, onde 83% dos problemas encontrados foram solucionados
e os demais permaneceram em análise.
Palavras-chave: Medidores Inteligentes. Sistemas de Medição Centralizada. Metodologia de
Teste. Livro de Teste. Caso de Teste.
ABSTRACT
In this final paper it is used an embedded systems test methodology applied to Smart Meters
and Cluster Metering Solution. The purpose of this methodology is to define the teams that
comprise the development flow of a system and to establish the role of each one of them, as
well as to determine the basic structure of the Test Books and the Test Cases. The proposed
test methodology is implemented in samples of Smart Meters and Cluster Metering Solution
which are subjected to the evaluation of hardware and software through the execution of Test
Books. It is also done the analysis of the data obtained in the execution of the Test Cases and the
study of the problems reported to the Research and Development sector, in addition the problems
identified are classified in degrees of criticality, priority levels of resolution and reproduction
capacity. The results obtained with the execution of the Test Books are presented. Finally, the use
of the methodology in the improvement of the final product delivered to the market is evaluated,
where 83% of the problems were solved and the rest remained under analysis.
Keywords: Smart Meters. Cluster Metering Solution. Test Methodology. Test Book. Test case.
LISTA DE FIGURAS
Figura 1 – Representação de Medidor Inteligente e Sistema de Medição Centralizada . 16
Figura 2 – Motivadores para a implatação de Redes Elétricas Inteligentes no Brasil . . 19
Figura 3 – Representação de um Sistema Elétrico de Potência tradicional: geração,
transmissão e distribuição . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figura 4 – Projetos em implementação no mundo até o ano de 2012 . . . . . . . . . . 20
Figura 5 – Projetos de Smart Grid na Europa . . . . . . . . . . . . . . . . . . . . . . . 21
Figura 6 – Instalação de medidores elétricos nos principais mercados entre os anos de
2012 e 2016 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figura 7 – Lista de fabricantes nacionais e globais de medidores inteligentes . . . . . . 25
Figura 8 – Representação de concentrador secundário e mostradores . . . . . . . . . . 27
Figura 9 – Desenho de SMC em aplicação real . . . . . . . . . . . . . . . . . . . . . . 28
Figura 10 – Modelo V - Processo de desenvolvimento de produto e teste . . . . . . . . . 32
Figura 11 – Fluxograma de processo de desenvolvimento e teste porcolaboradores . . . 34
Figura 12 – Modelo de Matriz de Impacto . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 13 – Estrutura básica do Livro de Teste . . . . . . . . . . . . . . . . . . . . . . 41
Figura 14 – Fluxo de vida de caso de teste . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 15 – Estruturação do livro de testes na plataforma Testlink . . . . . . . . . . . . 45
Figura 16 – Exemplo de caso de teste com passo a passo de execução . . . . . . . . . . 46
Figura 17 – Ambiente de relato da plataforma Mantis Bug Tracker . . . . . . . . . . . . 53
Figura 18 – Quantidade de bugs encontrados por modelo . . . . . . . . . . . . . . . . . 54
Figura 19 – Grau de criticidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 20 – Nível de prioridade resolução . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 21 – Capacidade de reprodução . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 22 – Estado de resolução de bugs . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 23 – Percentual de bugs encontrados para os dispositivos que compõem o Sistema
de Medição Centralizada (SMC). . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 24 – Grau de criticidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 25 – Nível de prioridade resolução . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 26 – Capacidade de reprodução . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 27 – Estado de resolução de bugs . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 28 – Exemplo de Caso de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
LISTA DE TABELAS
Tabela 1 – Tipo de registrador de Energia Ativa . . . . . . . . . . . . . . . . . . . . . 24
Tabela 2 – Tipo de registrador de Energia Reativa . . . . . . . . . . . . . . . . . . . . 24
Tabela 3 – Tabela padrão para ações físicas. . . . . . . . . . . . . . . . . . . . . . . . 43
Tabela 4 – Tabela padrão para ações de comando. . . . . . . . . . . . . . . . . . . . . 43
Tabela 5 – Tabela padrão para resultados esperados. . . . . . . . . . . . . . . . . . . . 44
Tabela 6 – Quantidade de casos de teste criados para o medidor monofásico. . . . . . . 48
Tabela 7 – Quantidade de casos de teste criados para o medidor monofásico 3 fios. . . . 48
Tabela 8 – Quantidade de casos de teste criados para o medidor bifásico. . . . . . . . . 49
Tabela 9 – Quantidade de casos de teste criados para o medidor trifásico. . . . . . . . . 49
Tabela 10 – Quantidade de casos de teste criados para o módulo de comunicação Power
Line Communication (PLC). . . . . . . . . . . . . . . . . . . . . . . . . . 49
Tabela 11 – Quantidade de casos de teste criados para o módulo de comunicação Rádio
Frequência (RF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Tabela 12 – Quantidade de casos de teste criados para Unidade Central de Processamento
(CPU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Tabela 13 – Quantidade de casos de teste criados para o Módulo de Medição. . . . . . . 51
Tabela 14 – Quantidade de casos de teste criados para o Mostrador. . . . . . . . . . . . 51
Tabela 15 – Quantidade de casos de teste criados para o Concentrador Primário e Secundário. 51
Tabela 16 – Quantidade de bugs encontrados para o Medidor Inteligente. . . . . . . . . 52
Tabela 17 – Grau de criticidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Tabela 18 – Nível de prioridade de resolução. . . . . . . . . . . . . . . . . . . . . . . . 55
Tabela 19 – Capacidade de reprodução. . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Tabela 20 – Estado de resolução dos bugs. . . . . . . . . . . . . . . . . . . . . . . . . . 56
Tabela 21 – Quantidade de bugs encontrados para os dispositivos que constitui o SMC. . 56
Tabela 22 – Grau de criticidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Tabela 23 – Nível de prioridade de resolução. . . . . . . . . . . . . . . . . . . . . . . . 58
Tabela 24 – Capacidade de reprodução. . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Tabela 25 – Estado de resolução dos bugs. . . . . . . . . . . . . . . . . . . . . . . . . . 59
LISTA DE ABREVIATURAS E SIGLAS
FSK Frequency-shift keying
RFP Request For Proposal
ANATEL Agência Nacional de Telecomunicações
ANEEL Agência Nacional de Energia Elétrica
CP Concentrador Primário
CPU Unidade Central de Processamento
CS Concentrador Secundário
INMETRO Instituto Nacional de Metrologia, Qualidade e Tecnologia
PLC Power Line Communication
PRODIST Procedimentos de Distribuição de Energia Elétrica no Sistema Elétrico Nacional
RF Rádio Frequência
RTM Regulamento Técnico Metrológico
SEP Sistema Elétrico de Potência
SMC Sistema de Medição Centralizada
TLI Terminal de Leitura Individual
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 MEDIDORES ELÉTRICOS INTELIGENTES E SISTEMAS DE ME-
DIÇÃO CENTRALIZADA . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Medidores Elétricos Inteligentes . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Características básicas dos Smart Meters . . . . . . . . . . . . . . . . . . 21
2.1.2 Características construtivas . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.2.1 Portaria INMETRO nº587 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.2.2 Portaria INMETRO nº586 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.3 Modo de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.4 Principais fabricantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Sistemas de Medição Centralizada . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Dispositivos que compõe um SMC . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1.1 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1.2 Módulo de Medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1.3 Concentrador Secundário . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1.4 Mostrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1.5 Concentrador Primário . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Padrões atendidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2.1 Portaria nº371 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2.2 Resolução 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 METODOLOGIA DE TESTE . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Terminologia básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Situações de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 Teste unitário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 Teste de subsistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3 Teste de integração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.4 Teste de regressão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.5 Teste de aceitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Colaboradores: subdivisão da equipe de teste . . . . . . . . . . . . . . . 32
3.3.1 Equipe de produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2 Equipe de elaboração de teste . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3 Equipe de configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.4 Equipe de execução . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 33
3.4 Dispositivos e estratégias de teste de sistemas caixa preta e caixa branca 35
3.4.1 Técnicas de teste de caixa preta . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.2 Arquitetura de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.3 Matriz de impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.3.1 Elementos da matriz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.3.1.1 Nó de função . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.3.1.2 Nó de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.3.1.3 Nó de configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.4 Introdução básica às diretrizes para criar um caso de teste . . . . . . . . . 39
3.4.5 Cobertura do caso de teste, prioridade de eleição e execução . . . . . . . . 39
3.4.6 Definição da estrutura do livro de teste . . . . . . . . . . . . . . . . . . . . 40
3.4.6.1 Estágio de reconhecimento comportamental . . . . . . . . . . . . . . . . . 40
3.4.7 Definição da estrutura do caso de teste . . . . . . . . . . . . . . . . . . . . 41
3.4.7.1 Escrevendo o título . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.7.2 Escrevendo o resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.7.3 Escrevendo a precondição . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.7.4 Escrevendo o passo a passo . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.7.4.1 Execução de ações físicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.7.4.2 Execução de ações de comando . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.7.4.3 Escrevendo o resultado esperado . . . . . . . . . . . . . . . . . . . . . . . 44
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 Livros de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1 Medidor Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1.1 Medidor Monofásico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.1.2 Medidor Monofásico: 3 fios . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.1.3 Medidor Bifásico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.1.4 Medidor Trifásico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.1.5 Módulo de comunicação: PLC . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.1.6 Módulo de comunicação: RF . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.2 Sistema de Medição Centralizada . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.2.1 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.2.2 Módulo de Medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.2.3 Mostrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.2.4 Concentrador Primário e Secundário . . . . . . . . . . . . . . . . . . . . . 51
4.2 Execução dos livros de testes e problemas encontrados . . . . . . . . . . 52
4.2.1 Medidor inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2 Sistema de Medição Centralizada . . . . . . . . . . . . . . . . . . . . . . . 56
5 CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . 60
5.1 Sugestões de Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . 60
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
APÊNDICE A – Exemplo de Caso de Teste . . . . . . . . . . . . . . . . 63
15
1 INTRODUÇÃO
Estudos recentes comprovam que aproximadamente 90% de todos os processadores
em uso no mundo são parte integrante de sistemas embarcados, sendo estes sistemas capazes de
controlar e reagir de maneira autônoma, ou seja, sem inteferência do ser humano, e de modo
contínuo ao meio ambiente. O sistema embarcado também pode ser definido como um sistema
que processa dados e é constituído por componentes de hardware e de software, (SCHULZ et
al., 2002).
Os sistemas embarcados estão presentes nos mais variados dispositivos eletrônicos
empregados na atividade humana, (CARRO; WAGNER, 2003), partindo de simples relógios e
calculadoras digitais, passando por eletrodomésticos e findando em tecnologias de ponta como
sistemas de controle de aeronaves da aviação civil e aplicações militares, a exemplo de mísseis e
foguetes.
É sob este amplo contexto de aplicações dos sistemas embarcados que se tem
justificado o desenvolvimento e emprego de diversas técnicas de teste. Devido ao alto emprego
de dispositivos eletrônicos microprocessados nas atividades do cotidiano, tanto de lazer quanto
de trabalho produtivo, o homem e a natureza estão sujeitos à erros de projetos que podem custar
a vida de uma ou mais pessoas e acidentes que comprometam a fauna e flora de uma região,
podendo ocasionar perdas irreversíveis.
Um exemplo recente de acidente que vitimou 157 vidas humanas foi a queda do avião
Boeing 737 Max 8 da empresa de aviação Ethiopian Airlines ocasionada por um erro no software
MCAS (Sistema de Aumento de Características de Manobra) que corrige automaticamente a
altitude do avião para evitar perda de sustentação. Uma falha no sensor de ângulo de ataque
ativou permanentemente o sistema de antiestolagem, o que levou o bico do avião ser direcionado
para a terra. Este erro fez com que a Boeing recomendasse a suspensão dos voos com este
modelo em todo o mundo até que o software fosse corrigido e testado, (BBC, 2019).
Adentrando em um cenário mais específico dos sistemas embarcados, os medidores
elétricos serão objeto de estudo deste trabalho. Com o incentivo dado por recentes ações
regulatórias que possibilitam a compensação de energia excendente produzida por sistemas de
pequeno porte, a Micro e Mini Geração Distribuída atingiram 359,1 GWh de energia gerada a
partir de um potencial instalado de 246,1 MW. Em destaque tem-se a fonte solar fotovoltáica,
com 165,9 GWh de geração e 174,5 MW de potência instalada, (EPE, 2018). Em consequência
do crescimento da geração distribuída, a indústria de medidores elétricos precisou se adequar
16
ao mercado e desenvolver medidores capazes de medir a energia consumida pelo cliente e a
energia produzida e injetada na rede pela micro ou mini usina de geração distribuída, além
de indicadores de qualidade da energia fornecida à rede elétrica das concessionárias, a estes
medidores dá-se o nome de Medidores Inteligentes. Erros de projeto destes medidores podem
impactar monetariamente tanto as concessionárias quanto os donos destas usinas. Durante a fase
de desenvolvimento, estes medidores devem ser submetidos à rigorosas baterias de testes que
comprovem a integridade dos dados produzidos.
O SMC também será objeto de estudo deste trabalho. A medição centralizada
se caracteriza por preservar a individualização da medição do consumo de energia além de
centralizar todas as informações relativas ao consumo das unidades consumidoras instaladas.
Sendo assim, por compartilharem o mesmo espaço físico há uma significativa redução da
área ocupada em relação à medidores convencionais. As principais vantagens deste tipo de
produto estão quanto a diminuição de perdas não-técnicas provocadas por fraudes, automação
da leitura para faturamento e facilidade de corte e religação de consumidores inadimplentes,
(ALVARENGA, 2008).
A Figura 1 apresenta os sistemas embarcados que serão analisados nesta pequisa.
Ela é composta pela representação de um Medidor Inteligente e de um Sistema de Medição
Centralizada.
Figura 1 – Representação de Medidor Inteligente e Sistema de Medição Centralizada
Fonte – (ELETRA, 2019)
17
1.1 Justificativa
Sabendo da crescente dependência que a sociedade moderna tem da eletricidade e
o impacto real que o seu consumo tem na economia global,este trabalho destina-se a analisar
técnicas de teste aplicadas a medidores de consumo de energia elétrica com o objetivo de
minimizar os erros de projeto destes sistemas embarcados.
O trabalho aplica uma metodologia de teste destinada à análise de sistemas embarca-
dos que compõem Medidores Inteligentes e SMC, onde estes são empregados especialmente em
Micro e Mini Usinas de Geração Distribuída e no combate de perdas não-técnicas provocadas
por fraudes que sobrecarregam a rede das concessionárias de energia elétrica, respectivamente.
1.2 Objetivos
Este trabalho pretende aplicar uma metodologia de teste composta pelas principais
técnicas desenvolvidas e aplicadas na indústria para a análise de sistemas embarcados e no
desenvolvimento de softwares, objetivando a implementação no desenvolvimento de Medidores
Inteligentes e Sistemas de Medição Centralizada. Todos os objetivos estão listados abaixo.
• Descrição funcional de medidores de consumo de energia elétrica e esboço da
aplicabilidade destes dispositivos no mercado;
• Estudo das principais técnicas de teste de sistemas embarcados;
• Implementação da metodologia de teste proposta em amostras de Medidores
Inteligentes e de Sistemas de Medição Centralizada;
• Obtenção dos resultados dos testes;
• Tratamento dos dados obtidos e estudo da criticidade dos bugs relatados ao setor
de Pesquisa e Desenvolvimento;
• Avaliação do emprego da metodologia na melhoria do produto final entregue ao
mercado.
1.3 Organização do texto
Esta monografia foi dividida por capítulos que abordam do princípio teórico até os
resultados obtidos e a sugestão de trabalhos futuros.
• Capítulo 1: introduz o tema e as principais motivações e objetivos do trabalho;
• Capítulo 2: apresenta os Medidores Inteligentes e os SMC, onde estes serão
18
objeto de estudo na aplicabilidade da metodologia de teste;
• Capítulo 3: introduz as principais técnicas de testes utilizadas na indústria, propõe
e descreve a metodologia de teste;
• Capítulo 4: contém os resultados obtidos nos testes propostos neste trabalho e
avalia a criticidade dos problemas encontrados;
• Capítulo 5: finaliza o trabalho com as conclusões obtidas, junto de ideias para
trabalhos futuros;
19
2 MEDIDORES ELÉTRICOS INTELIGENTES E SISTEMAS DE MEDIÇÃO CEN-
TRALIZADA
A crescente necessidade de modernização do Sistema Elétrico de Potência (SEP)
convencional se dá pela exigência de melhoria contínua da qualidade de energia e pelo aperfeiçoa-
mento da eficiência operacional. A implementação de Smart Grids (Redes Elétricas Inteligentes)
tem como objetivo garantir estas melhorias por meio de sistemas de distribuição e transmissão
que usam recursos de tecnologia da informação (TI), telecomunicações e automação de alto
nível, (TEKINER-MOGULKOC et al., 2012). Na Figura 2 tem-se as principais motivações de
implantação de Redes Elétricas Inteligentes no Brasil.
Figura 2 – Motivadores para a implatação de Redes Elétricas Inteligentes no Brasil
Fonte – (BNDES et al., 2013)
Neste contexto de Smart Grids, o fluxo de energia e de comunicação é bidirecional.
Ou seja, além do fluxo tradicional de potência, onde o processo de geração se dá a partir de
grandes usinas de transfomação dos mais variados tipos de energia em energia elétrica, onde esta
é entregue ao usuário final a partir de sistemas de transmissão e distribuíção, como exemplificado
na Figura 3; existe também o fluxo dito reverso, onde o usuário final produz a própria energia
elétrica e injeta na rede de distribuíção o excedente.
Os projetos de Smart Grid estão em rápida aceleração de teste e implantação no
mundo. Na Figura 4 tem-se um panorama da distribuição dos projetos pelo mundo no ano de
2012, e na Figura 5 tem-se os dados mais recentes, ano de 2017, sobre a distribuição dos projetos
na Europa.
Dentre todos os equipamentos que compõem as redes inteligentes, os Smart Meters
(Medidores Elétricos Inteligentes) são responsáveis por fazer o elo final entre o cliente e a rede
da concessionária de energia elétrica. Estes dispositivos medem e registram a energia consumida
e o excedente injetado na rede, realizam a interface de comunicação entre a concessionária e
20
Figura 3 – Representação de um Sistema Elétrico de Potência tradicional: geração, trans-
missão e distribuição
Fonte – (BLUME, 2007) adaptado
Figura 4 – Projetos em implementação no mundo até o ano de 2012
Fonte – Energy Retail Association – UK, 2012
o usuário final e permitem a operação remota de corte e religa, dentre outras funcionalidades
descritas ao longo deste capítulo.
2.1 Medidores Elétricos Inteligentes
Os medidores elétricos inteligentes estão em crescente implatação em diversos
mercados globais. As unidades instaladas passaram de 260 milhões em 2012 para 570 milhões
no ano de 2016, o que representa um aumento de 219% em 5 anos, (IEA, 2017). Somente na
China, mais de 469 milhões de medidores inteligentes foram instalados até o terceiro semestre
de 2017, fato que a torna líder no mercado, respondendo por 68,7% das instalações globais,
21
Figura 5 – Projetos de Smart Grid na Europa
Fonte – European Commission - Joint Research Centre, Smart Electricity Systems and Interoperability group,
2017
(LARGUE, 2018). Na Figura 6 é possível observar a crescente implantação de medidores
elétricos inteligentes em algumas regiões do mundo.
2.1.1 Características básicas dos Smart Meters
As principais características que diferenciam os medidores elétricos inteligentes dos
medidores convencionais são:
• Medição de energia nos quatro quadrantes (energia ativa direta e reversa, energia
reativa direta e reversa - cargas com características indutivas e capacitivas);
• Memória de Massa com registro configurável, tendo por padrão o registro de
grandezas a cada 15 minutos;
• Registro de Demanda Máxima e Acumulada;
• Faturamento automático e horosazonalidade (tarifa branca);
• Análise de Qualidade de Energia conforme o Módulo 8 de Procedimentos de
Distribuição de Energia Elétrica no Sistema Elétrico Nacional (PRODIST) esta-
22
Figura 6 – Instalação de medidores elétricos nos principais mercados entre os anos de
2012 e 2016
Fonte – (IEA, 2017)
belicidos pela Agência Nacional de Energia Elétrica (ANEEL);
• Alarmes de abertura de tampa, abertura de bloco de terminais, detecção de
campo magnético, tensão pós-relé, além de alarmes de subtensão e sobretensão,
subcorrente e sobrecorrente, falta de fase, desbalanceamento de carga, entre
outros;
• Módulo de comunicação sem fio (WiFi, ZigBee e LoRa) e com fio (PLC), por
exemplo;
• Interface de comunicação local, como a óptica, e remota, como os padrões RS232
e RS485;
Tais características representam grande avanço tecnológico em relação aos medidores
tradicionais. Apesar de todas as vantagens mencionadas, a instalação de medidores inteligentes
e implementação de Smart Grids ainda enfretam alguns problemas como: infra-estruturas
ultrapassadas, escassez de plataformas de comunicação integradas, custo de implementação,
compatibilidade com equipamentos antigos, falta de padrões das redes elétricas e de protocolos
utilizados pelos equipamentos e políticas de incentivos dos governos.
23
2.1.2 Características construtivas
No Brasil, o Instituto Nacional de Metrologia, Qualidade e Tecnologia (INMETRO)
define as características construtivas e operacionais mínimas para os medidores eletrônicos
comercializados e fabricados no território nacional. Atualmente duas normas estão virgentes,
são elas as portarias nº586 e nº587.
2.1.2.1 Portaria INMETRO nº587
O Regulamento Técnico Metrológico (RTM) nº587 é a portaria brasileira que esta-
belece os requisitos mínimos para a apreciação técnica dos medidores eletrônicos de energia
elétrica ativa e/ou reativa, sendo modelos monofásicos e pólifásicos (bifásicos e trifásicos), e
índices de classe de precisão D (0,2%), C (0,5%), B (1,0%) e A (2,0%), (INMETRO, 2012b).
Além das características já citadas, a portaria nº 587 define os requisitos mecânicoscomo dimensões de base e tampa, além das propriedades dos materiais utilizados. Define também
valores máximos e mínimos das grandezas medidas e os requisitos mínimos de imunidade
eletromagnética.
2.1.2.2 Portaria INMETRO nº586
O RTM nº586 estabelece os requisitos técnicos mínimos de software necessários
para medidores de energia elétrica controlados por software, (INMETRO, 2012a).
Os requisitos gerais são:
a) Características básicas do sistema/instrumento de medição de energia elétrica;
b) Identificação de software;
c) Integridade do software;
d) Exatidão dos algoritmos e funções de medição;
e) Influência da interface de entrada de dados;
f) Proteção contra mudanças acidentais/não-intencionais;
g) Proteção contra mudanças intencionais não autorizadas;
h) Proteção dos parâmetros;
i) Detecção de falha;
j) Validação do software.
Estes requisitos de software buscam garantir a integridade dos dados metrológicos
24
e tarifários gerenciados pelo medidor e garantir a imunidade a mudanças intencionais com
finalidade de fraude.
2.1.3 Modo de registro
Os medidores elétricos inteligentes devem ser capazes de medir o fluxo de potência
nos quatro quadrantes. No entanto o registro da energia consumida segue três padrões, são eles:
a) Unidirecional: nesta configuração de modo de registro o medidor eletrônico de
energia elétrica (ativa e/ou reativa) é capaz de registrar somente no sentido do fluxo direto;
b) Bidirecional: capaz de registrar a energia (ativa e/ou reativa) consumida em ambos
os sentidos de fluxo;
c) Catraca: registra a energia em um único sentido de fluxo e não é alterado na
ocorrência do fluxo de energia oposto.
As Tabelas 1 e 2 resumem a influência dos quadrantes no cálculo de cada tipo de
registrador de energia ativa e reativa. Onde: Q1 = Quadrante 1, Q2 = Quadrante 2, Q3 =
Quadrante 3 e Q4 = Quadrante 4.
Tabela 1 – Tipo de registrador de Energia Ativa
Tipo de Registro Energia Ativa Direta Energia Ativa Reversa
Unidirecional |Q1| + |Q2| + |Q3| + |Q4| Zero
Bidirecional |Q1| + |Q4| |Q2| + |Q3|
Catraca |Q1| + |Q4| Zero
Fonte: o autor.
Tabela 2 – Tipo de registrador de Energia Reativa
Tipo de Registro
Energia Rea-
tiva Indutiva
Direta
Energia Rea-
tiva Indutiva
Reversa
Energia
Reativa
Capacitiva
Direta
Energia
Reativa
Capacitiva
Reversa
Unidirecional |Q1| + |Q3| Zero |Q4| + |Q2| Zero
Bidirecional |Q1| |Q3| |Q4| |Q2|
Catraca |Q1| Zero |Q4| Zero
Fonte: o autor.
2.1.4 Principais fabricantes
O BNDES listou os principais fornecedores com P&D (Pesquisa e Desenvolvimento)
local e os fornecedores globais de tecnologias de medidores inteligentes e soluções de Smart
25
Grid. A Figura 7 contém uma lista não exaustiva dos principais fabricantes nacionais e globais,
(BNDES et al., 2013).
Figura 7 – Lista de fabricantes nacionais e globais de medidores inteligentes
Fonte – (BNDES et al., 2013)
Devido as características do mercado nacional, a presença de uma base de P&D de
empresas de medidores se faz necessária, isto tem justificado a compra de empresas nacionais
por algumas empresas chinesas, a exemplo da Eletra Energy Solutions comprada pela chinesa
Hexing e da Nansen arrendada pela chinesa Sanxing.
Os altos índices de furto de energia (perdas não-técnicas) são responsáveis pelo
desenvolvimento de alarmes e sistemas de medição centralizada criados para o mercado nacional
e emergente. Isto tem justificado a manutenção de bases de P&D no Brasil pois a tecnologia
aqui desenvolvida garante robustez e aplicabilidade em situações sócio-econômicas diferentes
dos países sede destas empresas.
2.2 Sistemas de Medição Centralizada
Devido as características dos mercados emergentes, uma classe especial de medidores
inteligentes foi desenvolvida para atender requisitos técnicos diferenciados. Enquanto que nos
Estados Unidos e na Europa uma rede é considerada inteligente se propiciar a redução dos
26
gases responsáveis pelo efeito estufa e por reduzir os custos operacionais, no Brasil e em outros
mercados do terceiro mundo, o objetivo que deve ser alcançado pelas redes inteligentes é a
diminuição das perdas não-técnicas e o aumento da confiabilidade da rede, (LEITE, 2013).
Essa classe de medidores voltada para mercados do terceiro mundo são os SMC, um
tipo especial dos medidores elétricos inteligentes. Estes equipamentos apresentam as mesma
características dos medidores inteligentes descritas nas seções anteriores com aplicabilidade
voltada para diminuição de perdas não-técnicas.
Um SMC pode ser definido como sendo um sistema composto por módulos eletrô-
nicos de medição de consumo elétrico proposto à medição individualizada de energia elétrica,
encarregando-se da concentração e do processamento dos dados de consumo gerados pelos mó-
dulos de medição como também pela indicação destes dados de consumo de forma centralizada,
(ANEEL, 2010).
2.2.1 Dispositivos que compõe um SMC
2.2.1.1 CPU
A CPU é responsável pela concentração e processamento de dados de consumo de
energia elétrica gerados pelos módulos de medição que compõe o Concentrador Secundário.
2.2.1.2 Módulo de Medição
O módulo eletrônico de medição de consumo elétrico, dentro do contexto de um
SMC, é responsável por medir e registrar o consumo de uma única unidade consumidora. Um
cliente monofásico tem seu consumo medido e registrado apenas por um módulo de medição, já
um cliente atendido pelo sistema bifásico tem dois módulos de medição e um cliente com carga
trifásica tem seu consumo medido e registrado por três módulos de medição. Ou seja, cada fase
do sistema elétrico é medida individualmente, sendo a CPU responsável pela concentração e
processamento dos registros gerados por cada módulo de medição.
2.2.1.3 Concentrador Secundário
O Concentrador Secundário (CS) é composto pela CPU e por, em média, 12 módulos
de medição, podendo atender até doze clientes no sistema monofásico, ou seis clientes bifásicos,
ou quatro consumidores pelo sistema trifásico, sendo a combinação dos três tipos de clientes
27
também permitida.
O CS também comporta módulos de comunicação responsáveis por enviar os dados
de consumo para os mostradores instalados nas unidades de consumo e por estabelecer conexão
de dados com os concentradores primários. Em geral, estas redes de comunicação com os
mostradores utilizam a tecnologia de RF e com os concentradores primários utilizam a tecnologia
RF Mesh, também conhecida como rede em malha onde uma rede de comunicação tem a
característica de alto grau de escalabilidade e a formação de vários nós de comunicação, sendo
possível um CS se comunicar com um Concentrador Primário através de um outro CS. Dessa
forma a comunicação não precisa, necessariamente, ser feita diretamente entre um concentrador
primário e um concentrador secundário. Outra característica importante é que em geral é utilizada
a tecnologida Frequency-shift keying (FSK), modulação por chaveamento de frequência, na
modulação do sinal de comunicação, além da proteção dos dados por chaves de autenticação e
criptografia. Nas Figuras 8 e 9 estão reproduzidos o esquema mínimo representativo de um CS e
o desenho de uma aplicação real, respectivamente.
Figura 8 – Representação de concentrador secundário e mostradores
Fonte – o autor.
2.2.1.4 Mostrador
Também chamado de Terminal de Leitura Individual (TLI), o mostrador de consumo
de energia elétrica é responsável por exibir os registros de energia realizados pelos módulos
28
Figura 9 – Desenho de SMC em aplicação real
Fonte – Adaptado de (FERNANDES et al., 2016)
de medição. Este dispositivo é instalado em uma caixa modular de medição junto à unidade
consumidora em substituição aos medidores eletrônicos tradicionais. O mostrador recebe os
dados de consumo através de um canal de rádio frequência, onde estes dados são criptografados
na origem e são descriptografados pelo mostrador através de uma chave de criptografia.
2.2.1.5 Concentrador Primário
O Concentrador Primário (CP) é encarregado de estabeler comunicação bidirecionalcom a rede de telecomunicações da concessionária de energia elétrica e com os CS que compõe
a rede de medição.
2.2.2 Padrões atendidos
Assim como os medidores inteligentes, os SMC também devem atender à portarias do
INMETRO, Portarias nº371 e nº586 e à resolução 506 da Agência Nacional de Telecomunicações
(ANATEL).
2.2.2.1 Portaria nº371
A portaria nº371 define os requisitos técnicos e metrológicos mínimos a que devem
satisfazer os Sistemas de Medição Centralizada para uso em medição de energia elétrica em
29
unidades consumidoras, (INMETRO, 2007).
Esta portaria define também os ensaios que o SMC deve ser submetido para aprova-
ção junto ao INMETRO e liberação para comercialização. São eles:
a) ensaio de tensão aplicada;
b) ensaio da corrente de partida;
c) ensaio de marcha em vazio;
d) influência da temperatura ambiente;
e) influência da variação da corrente;
f) influência da variação de tensão;
g) influência da variação da frequência;
h) influência da interrupção de uma ou duas fases;
i) influência do auto-aquecimento;
j) ensaio do dispositivo indicador e do registrador;
k) ensaio do tempo de autonomia;
l) ensaios de compatibilidade eletromagnética: imunidade a descargas eletrostáticas,
imunidade a transientes elétricos, impulso combinado, imunidade a distúrbios conduzidos indu-
zidos por campos eletromagnéticos de alta-freqüência e imunidade a campos eletromagnéticos
de alta frequência
2.2.2.2 Resolução 506
A Resolução 506 da ANATEL tem com objetivo designar os dispositivos de radiação
restrita e determinar as condições de uso de RF, (ANATEL, 2008). Sendo assim todos os
dispositivos que emitem rádio frequência devem estar de acordo com esta norma da ANATEL.
30
3 METODOLOGIA DE TESTE
Visto a rápida e crescente implementação de Smart Grids ao redor do mundo e a
necessidade de equipamentos robustos e de alta performance para atender esta alta demanda,
este capítulo pretende definir uma metodologia de teste de sistemas embarcados que garanta o
desenvolvimento de medidores inteligentes e SMC confiáveis e seguros.
Um caso de teste é um conjunto de condições ou variáveis sob o qual um testador
determinará se um sistema em teste satisfaz os requisitos ou se funciona corretamente. O
processo de desenvolvimento de casos de teste também pode ajudar a encontrar problemas nos
requisitos ou no projeto de um sistema embarcado.
Dito isto, é muito importante escrever bons casos de teste e ter boas práticas durante
a execução de um teste. Para ajudar a atingir estes objetivos, foi desenvolvido um padrão baseado
na norma IEEE STD 829, (IEEE, 2008), para elaborar casos de testes de forma que todos que
trabalham no desenvolvimento de novos produtos sempre entreguem a mesma qualidade. Outra
vantagem é que o padrão possibilita automatizar testes no futuro.
Neste capítulo, há uma breve explicação de todo o processo de elaboração de testes,
com todos os estágios e colaboradores.
3.1 Terminologia básica
• Conjunto de Teste: faz referência ao conjunto de teste ao qual o caso de teste
pertence;
• Resumo: é o resumo/objetivo do caso de teste;
• Precondições: são as precondições que devem ser cumpridas antes da execução
do teste;
• Procedimento de teste: é o procedimento com passo a passo para executar o teste;
• Resultado esperado: é o resultado esperado baseado na documentação do produto;
• Resultado real: é o resultado real do teste a ser preenchido após a execução do
teste;
• Estado: é a comparação entre o Resultado Esperado e o Resultado Real. Pode
ser "Aprovado"ou "Reprovado". Outros estados podem ser "Não Executado"se o
teste não for realizado e "Bloqueado"se o teste for bloqueado por impossibilidade
de execução.
31
• Notas/Descrição: é qualquer comentário sobre o caso de teste ou relacionado à
sua execução.
3.2 Situações de teste
3.2.1 Teste unitário
Uma unidade é a menor parte que pode ser testada. Podendo ser, por exemplo,
algumas linhas de código de um programa pequeno. Normalmente, uma unidade é criada por um
único desenvolvedor e é testada pelo programador que a criou.
3.2.2 Teste de subsistema
Um subsistema é um componente relativamente completo. Geralmente é criado por
uma equipe e testado pela equipe que o criou e por outra equipe de testadores. Alguns produtos
possuem componentes individuais, que funcionam de forma independente, mas o objetivo
principal do produto final só pode ser alcançado quando todos os componentes trabalham juntos.
O componente em si é testado no teste do subsistema e a funcionalidade individual também
é submetida à testes. Para conseguir isso, as outras partes do sistema devem estar livres de
problemas, por isso é aconselhável o uso de Instrumentos Mock. Um instrumento mock é um
instrumento que simula o comportamento de um equipamento real, sendo assim esta técnica é
utilizada quando se quer testar sistemas que interagem com outros sistemas com a finalidade de
isolar os possíveis problemas que um sistema pode inserir no outro.
3.2.3 Teste de integração
Um sistema é um conjunto completo de componentes que se relacionam entre si de
alguma forma. Usualmente, um sistema é testado por uma equipe de testes. Os produtos que
são uma combinação de componentes, que foram testados e, individualmente, estão livres de
problemas, devem ser testados como um único produto. Isso é chamado de Teste de Integração e
visa validar a integração entre os componentes e o funcionamento adequado do produto como
um todo.
32
3.2.4 Teste de regressão
Um teste de regressão é executado após uma correção de bug, garantindo que o bug
foi corrigido ou que uma funcionalidade não foi quebrada após uma alteração. Frequentemente,
é realizado pela equipe de testes após uma resposta da equipe de desenvolvimento de produto.
3.2.5 Teste de aceitação
São testes realizados por órgãos reguladores como o INMETRO. Antes de enviar um
produto para validação junto ao INMETRO, todos os testes de aceitação que serão realizados
pelo órgão regulador são executados pela equipe de teste, para garantir que os testes sejam
executados sem problemas. Os testes de aceitação podem também ser executados por um cliente
para garantir que o sistema tenha todas as funcionalidades solicitadas.
O Modelo V é amplamente adotado no processo de desenvolvimento de produto e a
relação deste com as etapas de teste. Na Figura 10 tem-se um esboço do Modelo V relacionando
as etapas de desenvovimento com as etapas de teste.
Figura 10 – Modelo V - Processo de desenvolvimento de produto e teste
Fonte – o autor.
3.3 Colaboradores: subdivisão da equipe de teste
Como proposta para a metodologia de teste de sistemas embarcados, a equipe de
teste foi dividida em 4 grupos com tarefas distintas objetivando o aumento da cobertura de teste
do produto final. Os grupos são: Equipe de Produto, Equipe de Elaboração de Teste, Equipe
33
de Configuração e Equipe de Execução. A Figura 11 mostra o Fluxograma de processo de
desenvolvimento e teste por colaboradores.
3.3.1 Equipe de produto
A Equipe de Produto não trabalha diretamente com os testes, mas é fornecedor
interno e cliente para o processo de teste. Como fornecedor, a Equipe de Produto elabora
o documento de Request For Proposal (RFP) - Solicitação de Proposta, os documentos de
requisitos, o documento de avaliação de software, os Instrumentos Mock e o Produto que será
submetido aos testes. Como cliente, a equipe de produto recebe o documento de Requisitos de
Instrumentação e o Relatório de Aceitação.
3.3.2 Equipe de elaboração de teste
A Equipe de Elaboração de Teste recebe os requisitos do produto, as funcionalidades
que o novo produto deve ter e, com base nessas funcionalidades, a equipe desenvolve os Livros
de Teste e os requisitos dos instrumentos de teste com base na técnica de Teste de Caixa Preta. A
equipe de produto deve aprovar os livros de testes, garantindo que os testes que serão realizados
estejam de acordo com os requisitos iniciais do produto e que o produto seja desenvolvidodessa
forma.
3.3.3 Equipe de configuração
A Equipe de Configuração recebe os livros de teste, nos quais há uma variedade de
cenários propostos pela Equipe de Elaboração de Teste, e os instrumentos desenvolvidos pela
Equipe de Produto. A equipe de configuração de teste possibilita esses cenários, projetando e
montando a estrutura necessária para os testes. É importante notar que esta equipe é responsável
pela programação dos testes, quando qualquer esforço computacional é necessário.
3.3.4 Equipe de execução
A Equipe de Execução recebe os livros de testes, nos quais há uma variedade de
cenários propostos pela Equipe de Elaboração de Teste, os instrumentos desenvolvidos pela
Equipe de Produto e a estrutura montada pela Equipe de Configuração. Esta equipe é responsável
por executar todos os testes e por relatar os problemas encontrados durante a fase de execução.
34
Figura 11 – Fluxograma de processo de desenvolvimento e teste por colaboradores
Fonte – o autor.
35
3.4 Dispositivos e estratégias de teste de sistemas caixa preta e caixa branca
3.4.1 Técnicas de teste de caixa preta
O colaborador responsável por construir o Livro de Teste deve conhecer bem as
tecnologias empregadas na concepção dos dispositivos, possuir um bom histórico de programação
e, o mais importante, ter um forte pensamento crítico.
A estratégia aplicada na avaliação dos produtos e na construção do Livro de Teste é
uma combinação de técnicas de teste que, dependendo do sistema ou dos dispositivos, são usadas
de maneiras diferentes. As principais técnicas são: a Partição de Equivalência, a Análise do
Valor Limite, e, por último, o Teste de Árvores de Classificação. Devido à grande possibilidade
de funções cruzadas, é altamente recomendável ter um histórico de dados relativo aos requisitos
do produto, em especial as funções mais utilizadas em campo, para concentrar-se neste conjunto
específico de configurações durante a concepção dos testes. Isto significa que todos os testes
devem ser feitos utilizando a implementação em campo como configuração padrão, pois não há
propósito em testar uma função a partir de uma determinada configuração se não houver este
cenário em campo.
Apesar dos testes funcionais parecerem simples, o objetivo dos testes empregados
neste trabalho não é comum, ele visa não somente avaliar funções, mas também obter bugs
não-funcionais. É altamente recomendável ter pelo menos o fluxo gráfico das funções dentro
do dispositivo ou sistema, isto pode economizar tempo e melhorar a partição de equivalência.
No entanto, quando não existe essa informação descrita de forma clara, como no caso de testes
de caixa branca, se faz necessário a exploração comportamental do dispositivo. A maioria dos
bugs conterá informações sobre a execução do algoritmo do dispositivo, e estas indicações
podem ser usadas para correlacionar problemas e prever possíveis problemas futuros. Descobrir
o comportamento interno requer um conhecimento técnico razoável e a previsão baseada em
evidências se mostrou bastante eficaz na solução dos bugs encontrados, no capítulo Resultados
isto está evidente.
Outra particularidade desta metodologia de teste é que o Livro de Teste pode au-
mentar durante o ciclo de vida dos testes. Isso significa que em cada rodada de teste, usando o
resultado dos testes, o Livro de Teste é ajustado e novas situações de testes podem ser acrescen-
tadas. O desafio torna-se maior quando, durante o estágio de reconhecimento comportamental, é
detectado que há problemas relacionados à funções cruzadas, o que significa que determinadas
36
funcionalidades estão impactando em outras funcionalidades, sendo assim isso pode levar a ár-
vore de decisão a outro caminho e o impacto pode variar dependendo da problemática envolvida
e, principalmente, na estratégia de correção de bugs.
O último e talvez mais importante estágio do teste de caixa preta é a avaliação
da robustez do sistema embarcado quanto a pontualidade, o que significa que a correção do
comportamento dos sistemas embarcados depende não apenas como o sistema faz, mas quando
o faz. Assim, a pontualidade acrescenta uma dimensão extra ao teste. As outras técnicas de teste
descritas no segundo parágrafo desta subseção são úteis para identificar erros funcionais e obter
alta cobertura de teste em sistemas embarcados, mas podem não ser suficientemente abrangentes
para descobrir problemas de robustez que ocorrem devido a erros no ambiente, como entrada
incorreta ou inesperadas, estouro de pilha, manipulação de ponteiros errados, mau funcionamento
de interrupção e assim por diante. Idealmente, esse estágio deve ser bem projetado em termos de
uso da versão de campo do código-fonte, um cenário de campo real e variante, e também uma
configuração adequada do sistema embarcado, do ponto de vista de hardware e software.
3.4.2 Arquitetura de teste
Em primeiro lugar, os testes de sistemas devem visar avaliar os elementos da solução
separadamente. Isso significa que uma abordagem baseada em mock é altamente recomendada. A
abordagem de testar um dispositivo único provou ser a melhor maneira de identificar precisamente
os problemas. Como resultado, o estado da qualidade da solução é rastreável pelo dispositivo e
ajuda a gerenciar melhor o esforço de desenvolvimento e teste.
Uma vez que o sistema ou dispositivo é bem conhecido, é necessário ter uma matriz
de impacto por funcionalidade, para ajudar a decidir melhor as árvores dos testes e contribuir
com o que testar primeiro. No caso de sistemas, isto ajudará a ver onde é necessário ter um
modelo e os impactos entre os dispositivos.
3.4.3 Matriz de impacto
As funções do produto e do sistema estão relacionadas de diferentes maneiras.
Normalmente, as funcionalidades dependem da configuração única, no entanto, devido à com-
plexidade de alguns sistemas ou produtos, existem funcionalidades que dependem de mais de
uma configuração ou outra função. Essas relações são complexas e compreendê-las é muito
importante para melhor entendimento do sistema ou produto. O processo de teste requer o
37
desenvolvimento de casos de teste e, para esta etapa do processo, é crucial que o designer de
teste tenha uma noção clara das funcionalidades do produto e de tudo o que influencia cada
função.
Uma matriz de impacto é uma ferramenta desenvolvida para fornecer uma visão
geral de um produto. Ela contém as funcionalidades, os principais fatores que afetam essa função
e os fatores que são influenciados por ela. Para ajudar a construir essa matriz, foi desenvolvido
um padrão para criação de matrizes de impacto de forma que todos que o utilizem, sejam capazes
de entender e sempre ofereçam a mesma qualidade ao criar as matrizes de impacto.
Este trabalho ajudará a manter os seguintes pontos:
1 - Melhor entendimento sobre os requisitos e funções do produto;
2 - Identificar facilmente as funções que mais impactam no funcionamento do
produto;
3 - Promover a identificação da dependência dos parâmetros de cada função;
4 - Melhor construção dos cenários de casos de teste e conhecimento sobre a cobertura
do Livro de Teste;
5 - Promover a avaliação da complexidade de um Livro de Teste.
3.4.3.1 Elementos da matriz
Uma matriz é composta por dois elementos: nó e aresta. Os nós são a estrutura
fundamental da matriz, enquanto as arestas conectam os nós. Ao projetar a matriz de impacto,
as funcionalidades apresentadas no produto serão um dos nós. Um Nó de Função pode estar
relacionado a três tipos diferentes de outros nós: Nós de Estado, Nós de Configuração e Nós de
Função. Cada tipo de nó deve ser representado de forma diferente, de forma que o tipo possa ser
facilmente identificado. O nó de estado e o nó de configuração normalmente são conectados ao
início de uma seta, enquanto que a ponta da seta é conectada ao nó de função. Isso simboliza que
o estado e a configuração modificam as maneiras pelas quais a função se comporta. É importante
observar que o número de setas que podemir e vir de cada nó não é restrito. Na Figura 12 tem-se
um exemplo de modelo de matriz de impacto.
3.4.3.1.1 Nó de função
Uma função é um comportamento esperado do produto descrito pela matriz. O nível
de granularidade da função deve ser definido pelo projetista da matriz, pois uma função pode
38
aparecer em mais de uma saída do produto ou sistema para alcançar o comportamento esperado.
3.4.3.1.2 Nó de estado
Um estado é uma variável usada pelo produto que não é controlada pelo produto
nem definida anteriormente. Essa variável é adquirida por um sensor e reflete o estado real do
produto no momento da aquisição de dados. Os dados adquiridos serão usados instantaneamente
pela função para produzir sua saída. Se um nó de estado for usado por uma função de alguma
forma, ele deve estar relacionada a esse nó de função.
3.4.3.1.3 Nó de configuração
Um nó de configuração é uma variável usada pelo produto que é definido anterior-
mente a chamada de função. A configuração determina alguns comportamentos e, dependendo
de qual configuração é escolhida, a função pode se comportar de maneiras diferentes. Algumas
configurações só podem ser alteradas na fábrica, com o produto desmontado. Algumas outras
configurações podem ser alteradas durante a operação normal. Independentemente da forma
como uma configuração é estabelecida, se um Nó de Configuração alterar a maneira como uma
função se comporta, ela deve estar relacionada a esse Nó de Função.
Figura 12 – Modelo de Matriz de Impacto
Fonte – o autor.
39
3.4.4 Introdução básica às diretrizes para criar um caso de teste
Um bom caso de teste deve ser:
• Preciso: ter propósito bem definido;
• Econômico: sem etapas ou palavras desnecessárias;
• Rastreável: capaz de ser rastreado pelos requisitos;
• Reproduzível: pode ser usado para executar o teste várias vezes.
• Reutilizável: pode ser reutilizado, se necessário.
Para a construção do Livro de Teste a documentação com os requisitos do produto
deve estar sempre acessível e atualizada, pois todos os casos de teste devem ser escritos de acordo
com esses documentos. Outro ponto importante é que a Equipe de Produto deve estar disponível
e acessível a Equipe de Elaboração de Teste. Em caso de dúvida, em relação à documentação
ou aos requisitos, a Equipe de Elaboração de Teste deve tirar todas as dúvidas possíveis com a
Equipe de Produto.
A estrutura proposta neste capítulo deve ser um guia ao escrever um Livro de Teste,
no entanto, a Equipe de Elaboração de Teste deve escrever os testes da melhor maneira possível.
3.4.5 Cobertura do caso de teste, prioridade de eleição e execução
A cobertura do caso de teste deve contemplar uma função com pelo menos um
caso de teste. Normalmente, para cada função, dependendo do escopo do teste, há quatro
casos de teste. Portanto, é comum usar duas ou mais técnicas de teste para testar apenas uma
funcionalidade.
Normalmente, na primeira vez em que um produto é testado, recomenda-se a exe-
cução de todo o livro de teste construído para o produto. É bem sabido que os livros de teste
normalmente são projetados para conter o menor número possível de casos de testes, no entanto,
como este trabalho foca na abordagem de teste de caixa preta, alguns casos de teste podem checar
a mesma funcionalidade em diferentes situações. Como é comum ter muitos testes de regressão,
de acordo com o comportamento do produto, o livro de teste pode diminuir sua cobertura em
diferentes situações, apesar de todos os pontos-chave precisarem estar sempre cobertos.
O livro de teste pode aumentar e diminuir de acordo com a situação a ser testada, por
isso deve ser fornecido um plano de teste que atenda às necessidades da empresa. Sendo assim,
a seleção do caso de teste, dependendo do prazo atribuído ao projeto de teste, e a prioridade de
40
quais casos de teste serão eleitos deve ser discutida pela Equipe de Produto e pela Equipe de
Execução para evitar divergências entre o que é esperado por uma e o que é testado pela outra,
respectivamente.
A prioridade de execução deve ser escolhida para encontrar o número máximo de
erros no menor tempo possível. Normalmente, é recomendável usar a abordagem estatística para
decidir quais funções têm maior probabilidade de ter erros. Então, é importante que a empresa
possua um banco de dados de bugs já encontrados, pois isso pode ser usado na definição dos
melhores cenários de teste. Além disso, modificações profundas no código do sistema embarcado
podem aumentar a probabilidade de surgimento de novos bugs, portanto, essa é outra variável
que pode afetar a prioridade de execução de um caso de teste.
3.4.6 Definição da estrutura do livro de teste
Um livro de teste está sempre relacionado a um único produto. No entanto, se um
produto fizer parte de um sistema, cada parte do sistema terá um livro de testes próprio e o
sistema completo também terá um livro de testes. É importante que, ao projetar um livro de testes
para uma parte de um sistema, as outras partes estejam livres de problemas. Para fornecer isso,
um instrumento simulado (Mock) deve ser desenvolvido para cada uma das outras partes que não
estão em teste. Nas Figuras 13 e 14 é possível observar uma sugestão de estrutura básica para
elaboração do Livro de Teste e o fluxo de vida elementar de um Caso de Teste, respectivamente.
O livro de testes deve ser dividido em dois grandes estágios de teste: Estágio de
Reconhecimento Comportamental e Estágio de Testes Funcionais.
3.4.6.1 Estágio de reconhecimento comportamental
Um conjunto desse estágio representa um grupo de funcionalidades relacionadas.
Dessa forma, deve haver um conjunto para cada funcionalidade. E dentro desse conjunto que
representa uma funcionalidade, deve haver todos os casos de teste que testam essa funcionalidade
específica.
Todos os casos de teste dentro de um conjunto de testes devem estar relacionado
à mesma funcionalidade, e uma diferença possível entre os casos de teste pode ser um dado
específico dentro de um resultado esperado. Outra diferença possível pode ser os valores contidos
nas variáveis que são utilizadas como entrada ao executar o teste. Outro ponto importante é que
o nome desse conjunto de testes deve ser a funcionalidade testada.
41
Figura 13 – Estrutura básica do Livro de Teste
Fonte – o autor.
3.4.7 Definição da estrutura do caso de teste
3.4.7.1 Escrevendo o título
O título deve ter a funcionalidade que está sendo testada e a forma de avaliação da
funcionalidade.
3.4.7.2 Escrevendo o resumo
Uma pequena frase contendo a funcionalidade a ser testada.
42
Figura 14 – Fluxo de vida de caso de teste
Fonte – o autor.
3.4.7.3 Escrevendo a precondição
O ambiente de teste deve ser completamente descrito. Portanto, as seguintes infor-
mações devem ser fornecidas:
• Informações do medidor (tipo de equipamento, tensão nominal, corrente nominal,
entre outros);
• Configuração do medidor (tipo de registro de faturamento, configuração de
mostrador, entre outros).
Outros parâmetros podem ser fornecidos, dependendo do julgamento da Equipe de
43
Elaboração de Teste.
3.4.7.4 Escrevendo o passo a passo
3.4.7.4.1 Execução de ações físicas
Ao executar ações físicas como: fechar modo de fábrica, remover um cabo, soldar
um componente, entre outras ações.
A instrução sobre o caso de teste deve ser colocada em uma tabela no formato
sugerido pela Tabela 3:
Tabela 3 – Tabela padrão para ações físicas.
Ação a ser executada Ação física
Descrição
Localização
Fonte: o autor.
3.4.7.4.2 Execução de ações de comando
No passo do caderno de teste que engloba a execução de um comando, a instrução
de execução deve ser colocada em uma tabela. Seu formato deve mostrar todos os parâmetros
que devem ser definidos, a exemplo da Tabela 4.
Tabela 4 – Tabela padrão para ações de comando.
Ação a ser executada
Tipo de objeto
Nome do objeto
Número de parâmetros
Parâmetros do objeto
Fonte: o autor.
• Ação a ser executada: Informa as ações que devem ser executadas. (Exemplos:Leitura / Escrita / Verificação / Energia / Configurar)
• Objeto: O agente que sofrerá a ação. Composto por tipo e nome;
• Tipo de objeto: Informa a categoria do objeto. (Exemplos: Comando / LED /
Mostrador LCD / Medidor, CPU, Sistema AMI);
• Nome do objeto: Guiado pelo tipo de objeto, o nome permite que a ação localize
o objeto específico. (Exemplos: Modo de Fábrica, Data e Hora / Precisão / Tipo
44
de tela / Terminais);
• Número de parâmetros: Informa o número de parâmetros que a ação recebe;
• Parâmetros do objeto: informa quais parâmetros a ação recebe. (Exemplo: nome
= valor (se aplicável)).
3.4.7.4.3 Escrevendo o resultado esperado
Ao executar um comando, o resultado esperado deve ser apresentado em uma tabela.
Seu formato deve mostrar todos os parâmetros que precisam ser verificados. Na Tabela 5 tem-se
o formato de tabela projetado para o resultado esperado de ações físicas e ações de comando.
Tabela 5 – Tabela padrão para resultados esperados.
Tipo de objeto Nome do objeto Valor esperado
Tipo de objeto 1 Nome do objeto 1 Parâmetros do obejto
Tipo de objeto 2 Nome do objeto 2 Parâmetros do obejto
Fonte: o autor.
45
4 RESULTADOS
Com a metodologia de teste definida e descrita neste trabalho, foi possível desenvol-
ver livros de testes para o medidor inteligente, modelo Zeus, e para o SMC, modelo Pantheon,
sendo os dois dispositivos desenvolvidos e fabricados pela Eletra Energy Solutions, indústria
de medidores de energia elétrica. O Apêndice A apresenta um exemplo de Caso de Teste
desenvolvido utilizando a estrutura proposta na Seção 3.4.7.
Inicialmente, este capítulo apresenta a quantidade de testes criados para cada disposi-
tivo que compõe os sistemas analisados e, em seguida, é avaliado o número de bugs encontrados
e solucionados durante a fase de desenvolvimento. É também avaliado o emprego da metodologia
na melhoria do produto final entregue ao mercado.
4.1 Livros de teste
Os livros de teste foram elaborados na plataforma de teste Testlink. Esta é uma
ferramenta de código fonte aberto para o gerenciamento de projetos de teste, nela é possível
cadastrar planos e casos de testes, além de realizar o controle de execução dos testes. Na Figura
15 tem-se uma visão geral do ambiente virtual de elaboração e execução de testes, e nela é
possível identificar a estruturação do livro de testes e corpo dos testes, com o passo a passo para
execução mostrado na Figura 16 e no Apêndice A.
Figura 15 – Estruturação do livro de testes na plataforma Testlink
Fonte – o autor.
46
Figura 16 – Exemplo de caso de teste com passo a passo de execução
Fonte – o autor.
47
Foram desenvolvidos livros de testes que avaliam e testam todos os dispositivos que
compõe o medidor inteligente e o sistema de medição centralizada. Estão inclusos os módulos de
comunicação do medidor inteligente, que utilizam a tecnologia PLC e RF, e todos os dispositivos
que compõe o SMC.
4.1.1 Medidor Inteligente
O livro de teste do medidor inteligente foi desenvolvido baseado nas características
técnicas do dispositivo. Algumas dessas características são:
a. Classe de exatidão: INMETRO Classe B (1%);
b. Sensor de tensão do tipo divisor resistivo;
c. Sensor de corrente do tipo TC (transformador de corrente);
d. Grandezas medidas: energia ativa e energia reativa;
e. Tipo de medição de energia: bidirecional, ou seja, mede nos quatro quadrantes;
f. Tipo de registro de energia: unidirecional, bidirecional ou catraca;
g. Constantes de pulso: 1000 pulsos/kWh e 1000 pulsos/kVAh;
h. Tensão nomimal: 120 V / 240 V;
i. Tensão de operação: 95 V a 277 V;
j. Corrente nominal: 15 A;
k. Corrente máxima: 120 A;
l. Corrente de partida: 60 mA;
m. Frequência: 60 Hz ou 50 Hz;
n. Temperatua de operação: -10ºC até + 85ºC.
Além destas características técnicas, o medidor inteligente tem as seguintes caracte-
rísticas operacionais:
a. Memória de massa com 18 canais configuráveis;
b. Até quatro tarifas por dia;
c. Tarifas diferenciadas para sábados, domingos e feriados;
d. Horário de verão e 50 feriados;
e. Supercapacitor ou bateria para manutenção do relógio;
f. Registro de demanda máxima e acumulada;
g. 30 alarmes, dentre eles: alarmes de detecção de fraude e alarmes de rede elétrica;
h. Comunicação remota implementada utilizando os protocolos RS232 e RS485;
48
i. Comunicação local através de porta ótica;
j. Interface para módulo de comunicação: módulo RF e PLC.
Estas são algumas das funcionalidades implementadas nos medidores inteligentes
e que foram avaliadas e testadas no livro de teste de cada modelo. Para cada tipo de medidor,
foi criado um livro de teste. Ou seja, há umlivro de teste para o medidor monofásico, para o
medidor bifásico e para o medidor trifásico, além de livros específicos para o módulo RF e para
o módulo PLC.
4.1.1.1 Medidor Monofásico
Para o medidor monofásico foi desenvolvido um livro de teste que contempla 744
casos de teste, afim de atestar o maior número possível de funcionalidades implementadas para
este modelo. Veja a Tabela 6.
Tabela 6 – Quantidade de casos de teste criados para o medidor monofásico.
Modelo Quantidade de casos de teste
Medidor Monofásico 744
Fonte: o autor.
4.1.1.2 Medidor Monofásico: 3 fios
O medidor monofásico 3 fios tem caraterísticas específicas que o diferencia do
medidor monofásico comum, o que produz a necessidade de desenvolvimento de um livro de
teste específico para esse modelo. A principal característica deste medidor é que ele é alimentado
por duas fases defasadas entre si de 180º, onde o neutro é externo ao sistema de medição. Tal
aspecto submete o medidor a situações de fraude devido à ausência de um neutro de referência.
Para este modelo foi criado um livro de teste que abrange 811 casos de testes, veja a
Tabela 7, onde são analisados, dentre outras funcionalidades, os sensores de fraude.
Tabela 7 – Quantidade de casos de teste criados para o medidor monofásico 3
fios.
Modelo Quantidade de casos de teste
Medidor Monofásico 3 fios 811
Fonte: o autor.
49
4.1.1.3 Medidor Bifásico
Para o medidor bifásico foram escritos 1474 casos de teste, conforme a Tabela 8.
Tabela 8 – Quantidade de casos de teste criados para o medidor bifásico.
Modelo Quantidade de casos de teste
Medidor Bifásico 1474
Fonte: o autor.
4.1.1.4 Medidor Trifásico
O medidor trifásico, topologia mais utilizada no mercado para medidores inteligentes,
teve densevolvido um livro de teste com 1589 casos de teste, como mostrado na Tabela 9.
Tabela 9 – Quantidade de casos de teste criados para o medidor trifásico.
Modelo Quantidade de casos de teste
Medidor Trifásico 1589
Fonte: o autor.
4.1.1.5 Módulo de comunicação: PLC
Para o módulo de comunicação que utiliza a tecnologia PLC foram elaborados 260
casos de teste, conforme a Tabela 10.
Tabela 10 – Quantidade de casos de teste criados para o módulo de comunica-
ção PLC.
Modelo Quantidade de casos de teste
Módulo de comunicação PLC 260
Fonte: o autor.
4.1.1.6 Módulo de comunicação: RF
E para o módulo de comunicação RF foram escritos 200 casos de teste, como
mostrado na Tabela 11.
50
Tabela 11 – Quantidade de casos de teste criados para o módulo de comunica-
ção RF.
Modelo Quantidade de casos de teste
Módulo de comunicação RF 200
Fonte: o autor.
4.1.2 Sistema de Medição Centralizada
O livro de teste do SMC foi desenvolvido baseado nas características técnicas do
sistema. A seguir algumas dessas características estão listadas:
a. Classe de exatidão: INMETRO Classe B (1%);
b. Sensor de tensão do tipo divisor resistivo;
c. Sensor de corrente do tipo shunt;
d. Grandezas medidas: energia ativa e energia reativa;
e. Tipo de medição de energia: bidirecional,ou seja, mede nos quatro quadrantes;
f. Tipo de registro de energia: unidirecional, bidirecional ou catraca;
g. Constantes de pulso: 1000 pulsos/kWh;
h. Tensão nomimal: 120 V / 240 V;
i. Tensão de operação: 95 V a 277 V;
j. Corrente nominal: 15 A;
k. Corrente máxima: 100 A;
l. Corrente de partida: 60 mA;m. Frequência: 60 Hz ou 50 Hz;
n. Temperatua de operação: -10ºC até + 75ºC.
O SMC é diferente do medidor inteligente tradicional em sua composição física,
onde vários dispositivos compõem o sistema final, e no seu comportamento funcional. Devido
a sua especificidade, foi desenvolvido um livro de teste para cada dispositivo que compreende
o sistema e um livro de teste que avalia a operabilidade e funcionalidade do produto como um
todo.
4.1.2.1 CPU
Para a CPU foi elaborado um livro de teste com 68 casos de teste, como mostrado na
Tabela 12.
51
Tabela 12 – Quantidade de casos de teste criados para CPU.
Modelo Quantidade de casos de teste
CPU 68
Fonte: o autor.
4.1.2.2 Módulo de Medição
O módulo de medição teve um livro de teste próprio, onde foram escritos 86 casos
de teste conforme a Tabela 13.
Tabela 13 – Quantidade de casos de teste criados para o Módulo de Medição.
Modelo Quantidade de casos de teste
Módulo de Medição 86
Fonte: o autor.
4.1.2.3 Mostrador
O mostrador, por ser um receptor de dados enviados pelo Concentrador Secundário,
deve ser imune a ataques externos. Por essa e outras características foram escritos 79 casos de
teste, como apresentado na Tabela 14.
Tabela 14 – Quantidade de casos de teste criados para o Mostrador.
Modelo Quantidade de casos de teste
Mostrador 79
Fonte: o autor.
4.1.2.4 Concentrador Primário e Secundário
O Concentrador Primário e Secundário é a solução final composta pela CPU, por mó-
dulos de medição e pelo mostrador. Conforme a Tabela 15, para esta solução foram desenvolvidos
564 casos de teste.
Tabela 15 – Quantidade de casos de teste criados para o Concentrador Primário
e Secundário.
Modelo Quantidade de casos de teste
Concentrador Primário e Secundário 564
Fonte: o autor.
52
4.2 Execução dos livros de testes e problemas encontrados
Ao longo do ano de 2018 e do primeiro semestre de 2019 foram executados todos os
livros de testes desenvolvidos para o medidor inteligente e para o sistema de medição centralizada.
Todo o processo de desenvolvimento seguiu a metodologia descrita neste trabalho com o intuito
de aumentar a cobertura de teste e de encontrar possíveis bugs que não foram identificados antes
da adoção desta metodologia.
A seguir tem-se os resultados que avaliam a quantidade de bugs encontrados, a
criticidade, a prioridade de resolução, a reprodutibilidade e o estado de resolução. Todos os bugs
encontrados foram relatados à equipe de desenvolvimento através da plataforma Mantis Bug
Tracker. Esta ferramenta é baseada na web e tem como principal função gerenciar os defeitos de
outros softwares.
Na Figura 17 tem-se o ambiente da plataforma Mantis Bug Tracker, onde os prin-
cipais pontos para o relato dos problemas estão em destaque, são eles: categoria do problema,
frequência, gravidade, prioridade de resolução, versão de hardware e firmware, atribuição do
problema ao responsável pela resolução, resumo do problema, descrição da situação, passo a
passo para a reprodução, informações adicionais, categorização do problema e por fim há a
possibilidade de anexar evidências que comprovam o problema.
4.2.1 Medidor inteligente
Para o medidor inteligente foi encontrada a seguinte quantidade de bugs mostrada na
Tabela 16 e exposta na Figura 18.
Tabela 16 – Quantidade de bugs encontrados para o Medidor Inteligente.
Modelo Quantidade de bugs
Somente medidor Monofásico 12
Somente medidor Polifásico 91
Ambos os modelos 307
Fonte: o autor.
Os bugs encontrados foram divididos em graus de criticidade, nível de prioridade de
resolução e capacidade de reprodução (reprodutibilidade). O grau de criticidade foi segmentado
em: pequeno e grande; o nível de prioridade de resolução foi fragmentado em: normal, alto e
urgente; e a reprodutibilidade foi divida em: sempre, as vezes e randômico. Nas Tabelas 17, 18
53
Figura 17 – Ambiente de relato da plataforma Mantis Bug Tracker
Fonte – o autor.
54
Figura 18 – Quantidade de bugs encontrados por modelo
Fonte – o autor.
e 19 são expostos os dados quantitativos para as classes de avaliação dos bugs descritas neste
parágrafo, respectivamente. E nos gráficos das Figuras 19, 20 e 21 os dados são expostos na
forma percentual com o objetivo de clarificar o impacto de cada classe.
Tabela 17 – Grau de criticidade.
Grau de criticidade Quantidade de bugs por classe
Pequeno 264
Grande 146
Fonte: o autor.
Figura 19 – Grau de criticidade
Fonte – o autor.
Todos os bugs encontrados foram evidenciados e reportados à equipe responsável
pelo desenvolvimento do produto. Após a análise, os problemas que foram solucionados são
retestados e averiguado o impacto da resolução em outras funcionalidades. Na Tabela 20 está
55
Tabela 18 – Nível de prioridade de resolução.
Nível de prioridade de resolução Quantidade de bugs por classe
Normal 307
Alto 51
Urgente 52
Fonte: o autor.
Figura 20 – Nível de prioridade resolução
Fonte – o autor.
Tabela 19 – Capacidade de reprodução.
Reprodutibilidade Quantidade de bugs por classe
Sempre 358
As vezes 34
Randômico 18
Fonte: o autor.
Figura 21 – Capacidade de reprodução
Fonte – o autor.
listado o estado de resolução do bug, que foi categorizado em: resolvido e em aberto; e a
quantidade de bugs por categoria. A Figura 22 apresenta os dados da Tabela 20 no formato de
56
gráfico do tipo pizza.
Tabela 20 – Estado de resolução dos bugs.
Estado de resolução Quantidade de bugs por classe
Resolvido 360
Em aberto 50
Fonte: o autor.
Figura 22 – Estado de resolução de bugs
Fonte – o autor.
4.2.2 Sistema de Medição Centralizada
Para o SMC foram seguidos os mesmos padrões de quantificação e qualificação de
bugs encontrados para os medidores inteligentes.
Na Tabela 21 tem-se a quantidade de bugs encontrados para os dispositivos testados
que compõem o SMC, e na Figura 23 tem-se o percentual de bugs identificados por equipamento
que constitui o sistema final.
Tabela 21 – Quantidade de bugs encontrados para os dispositivos que constitui
o SMC.
Dispositivo Quantidade de bugs
CPU 83
Módulo de Medição 70
Mostrador 56
Concentrador Primário e Secundário 132
Fonte: o autor.
57
Figura 23 – Percentual de bugs encontrados para os dispositivos que compõem o SMC.
Fonte – o autor.
Nas Tabelas 22, 23 e 24 são expostos os dados quantitativos para as classes de
avaliação dos bugs. E nos gráficos das Figuras 24, 25 e 26 os dados são expostos na forma
percentual com o objetivo de clarificar o impacto de cada classe.
Tabela 22 – Grau de criticidade.
Grau de criticidade Quantidade de bugs por classe
Pequeno 287
Grande 54
Fonte: o autor.
Figura 24 – Grau de criticidade
Fonte – o autor.
Na Tabela 25 está listado o estado de resolução do bug, que foi categorizado em:
resolvido e em aberto; e a quantidade de bugs por categoria. A Figura 27 apresenta os dados da
Tabela 25 no formato de gráfico do tipo pizza.
58
Tabela 23 – Nível de prioridade de resolução.
Nível de prioridade de resolução Quantidade de bugs por classe
Normal 211
Alto 121
Urgente 9
Fonte: o autor.
Figura 25 – Nível de prioridade resolução
Fonte – o autor.
Tabela 24 – Capacidade de reprodução.
Reprodutibilidade Quantidade de bugs por classe
Sempre 288
As vezes 24
Randômico 29
Fonte: o autor.
Figura 26 – Capacidade de reprodução
Fonte – o autor.
A taxa de resolução dos problemas encontrados foi superior a 83%, para os medidores
inteligentes e para o sistema de medição centralizada. Os outros problemas se encontram em
59
estado de avaliação para futura resolução pelo desenvolvedor.
Tabela 25 – Estado de resolução dos bugs.
Estado de resolução Quantidade de bugs por classe
Resolvido 284
Em aberto 57
Fonte: o autor.
Figura 27 – Estado de resolução de bugs
Fonte – o autor.
60
5 CONCLUSÕES E TRABALHOS FUTUROS
Este trabalho foi desenvolvido com o objetivo de avaliar a implementação de uma
metodologia de teste em sistemas embarcados, especificamente em medidores inteligentes e
sistemas de medição centralizada. A metodologia teve