Simulação e verificação
A equipe de robótica da escola montou um robô para a feira de ciências. Na primeira tentativa, ele bateu na parede e queimou um componente que custou R$ 40,00. Será que dava para descobrir o erro antes de ligar qualquer fio? Dava, e a resposta está na simulação. Vamos ver como, e como saber se o seu programa realmente funciona.
Por que simular antes de montar
Um protótipo físico custa dinheiro, demora para ser montado e pode quebrar no primeiro erro. Um modelo que roda na tela do computador não quebra. Por isso, antes de conectar sensores e atuadores reais, testamos o programa em um simulador.
Veja alguns exemplos do que o simulador costuma idealizar, e como verificar cada um na bancada:
| O que o simulador ignora | Como verificar na bancada |
|---|---|
| Fio solto ou mau contato na protoboard | Mexer nos fios e medir a continuidade com o multímetro |
| Tensão da bateria mais baixa que o previsto | Medir a tensão nos terminais com o motor ligado |
| Resistores com valor um pouco diferente do nominal (tolerância) | Medir o resistor com o multímetro e comparar com o valor marcado |
| Motor com atrito ou carga maior que a do modelo | Testar o motor sozinho, sem carga, e depois com carga |
Explique o que é um simulador de circuitos ou de robótica e dê duas vantagens de testar nele antes de fazer a montagem real.
Explique o que é um simulador de circuitos ou de robótica e dê duas vantagens de testar nele antes de fazer a montagem real.
Explique a diferença entre simular um circuito no computador e montá-lo em uma placa de ensaio real: o que se ganha e o que se perde com cada método.
Explique a diferença entre simular um circuito no computador e montá-lo em uma placa de ensaio real: o que se ganha e o que se perde com cada método.
No simulador seu programa funciona perfeitamente, mas na montagem real o motor não gira. Dê três causas possíveis que um simulador não detecta e explique como você…
No simulador seu programa funciona perfeitamente, mas na montagem real o motor não gira. Dê três causas possíveis que um simulador não detecta e explique como você verificaria cada uma na bancada.
Elaboração de casos de teste
Uma boa forma de organizar é uma tabela com entrada → saída esperada. Exemplo para um alarme que toca quando a porta é aberta:
| Caso | Entrada simulada | Saída esperada |
|---|---|---|
| 1 | Porta fechada | Alarme desligado |
| 2 | Porta aberta | Alarme tocando |
Por que o caso limite é tão importante? Porque é nele que costumam estar os erros de «maior que» no lugar de «maior ou igual». Considere um programa que aprova o aluno com nota a partir de 5:
| Nota | Resultado esperado |
|---|---|
| 3 | reprovado |
| 5 | aprovado |
| 4,9 | reprovado |
Se o programador escreveu nota > 5 em vez de nota >= 5, só o teste com a nota 5 revela o erro. Os outros dois passariam.
Quando a lógica combina várias entradas, é preciso testar todas as combinações. Na porta XOR (saída ligada só quando exatamente uma das entradas está ligada), são quatro casos.
Além dos casos normais e limite, pense nos casos de erro (o «caminho infeliz»). Num caixa eletrônico de brinquedo, por exemplo: cartão inválido → recusar e devolver o cartão; saldo insuficiente → negar o saque e mostrar mensagem. Um teste de estresse leva o sistema a condições extremas: um estacionamento com todas as vagas ocupadas e carros chegando sem parar, ou com o sensor de entrada disparando várias vezes seguidas.
Escreva dois casos de teste para um programa que faz soar um alarme quando uma porta é aberta: que entrada se simula e que saída se espera em cada caso.
Escreva dois casos de teste para um programa que faz soar um alarme quando uma porta é aberta: que entrada se simula e que saída se espera em cada caso.
Um programa deve ligar um ventilador quando a temperatura superar $26\ ^\circ\text{C}$. Defina três casos de teste (dado de entrada e resultado esperado) para…
Um programa deve ligar um ventilador quando a temperatura superar $26\ ^\circ\text{C}$. Defina três casos de teste (dado de entrada e resultado esperado) para verificá-lo, incluindo o valor limite de $26\ ^\circ\text{C}$, e justifique por que esse último caso é importante.
Explique o que é um «caso limite» ao verificar um programa e por que são tão importantes. Dê um exemplo com um programa que decide se uma nota é de aprovação a partir de…
Explique o que é um «caso limite» ao verificar um programa e por que são tão importantes. Dê um exemplo com um programa que decide se uma nota é de aprovação a partir de 5.
Projete uma tabela de verificação para um semáforo de pedestres: estados (vermelho, verde, amarelo intermitente), entradas (botão pressionado, tempo decorrido) e a saída…
Projete uma tabela de verificação para um semáforo de pedestres: estados (vermelho, verde, amarelo intermitente), entradas (botão pressionado, tempo decorrido) e a saída esperada em cada transição entre estados.
Verificar e validar: duas perguntas diferentes
Explique com suas palavras o que significa verificar um programa e em que se diferencia de «testá-lo um pouco para ver se funciona».
Explique com suas palavras o que significa verificar um programa e em que se diferencia de «testá-lo um pouco para ver se funciona».
Uma equipe verifica seu programa apenas no «caminho feliz», ou seja, quando tudo dá certo. Explique o que são os casos de erro e escreva dois para um caixa eletrônico de…
Uma equipe verifica seu programa apenas no «caminho feliz», ou seja, quando tudo dá certo. Explique o que são os casos de erro e escreva dois para um caixa eletrônico de brinquedo (cartão inválido, saldo insuficiente).
Uma equipe simula um robô seguidor de linha preta: na tela o algoritmo reage em 0,02 s, os motores respondem de forma instantânea e o robô completa o circuito a 1,2 m/s…
Uma equipe simula um robô seguidor de linha preta: na tela o algoritmo reage em 0,02 s, os motores respondem de forma instantânea e o robô completa o circuito a 1,2 m/s sem nenhuma falha. No entanto, ao carregar o mesmo programa no robô real com os mesmos sensores, ele oscila bruscamente de um lado para o outro e acaba perdendo a linha na primeira curva.
- a) Identifique e justifique três fatores do mundo físico que o simulador omitiu ou idealizou e que explicam essa discrepância.
- b) Proponha duas modificações técnicas (uma nos parâmetros do software de controle e outra na montagem física) para compensar esses efeitos reais sem substituir os sensores.
Uma equipe programa um robô transportador para um armazém. Ao executar o plano de testes no simulador, o robô desvia de 100 % dos obstáculos e freia diante de qualquer…
Uma equipe programa um robô transportador para um armazém. Ao executar o plano de testes no simulador, o robô desvia de 100 % dos obstáculos e freia diante de qualquer pessoa, mas o algoritmo sempre resolve os desvios realizando a manobra em marcha à ré, percorrendo os corredores em sentido contrário ao fluxo de trabalho do armazém. O professor afirma: «O software está perfeitamente verificado, mas o sistema não está validado».
- a) Justifique tecnicamente a afirmação do professor aplicando as definições operacionais de verificação e validação a este caso concreto.
- b) Reformule o documento de requisitos técnicos do robô para garantir que uma futura verificação assegure também a sua correta validação no ambiente de trabalho.
Depuração passo a passo
Erros típicos de programas de controle: uma condição escrita ao contrário (< no lugar de >, e o ventilador liga justo quando esfria) e um limiar mal definido (o valor de corte errado, e o sistema liga cedo ou tarde demais).
Em um simulador, duas técnicas simples ajudam muito: executar passo a passo (uma instrução por vez) e observar o valor das variáveis a cada passo, como num teste de mesa.
Outra técnica é o registro de execução (log): o programa escreve, a cada instante, os valores que lê e o estado em que está, por exemplo pela porta serial, e você analisa essas linhas depois. Cada linha traz o tempo, as leituras (distância, temperatura, tensão da bateria) e o estado do robô. Compare as linhas ao longo do tempo: se a temperatura sobe e a tensão cai pouco antes de o robô parar, a causa provável é física (superaquecimento ou bateria fraca), e não um erro de lógica no código.
O que é uma «falha» ou bug em um programa de controle? Dê dois exemplos simples (uma condição escrita ao contrário, um limiar mal definido) e o efeito que cada um teria.
O que é uma «falha» ou bug em um programa de controle? Dê dois exemplos simples (uma condição escrita ao contrário, um limiar mal definido) e o efeito que cada um teria.
Explique o que significa depurar um programa e nomeie uma técnica simples para fazê-lo em um simulador (executar passo a passo, observar o valor das variáveis).
Explique o que significa depurar um programa e nomeie uma técnica simples para fazê-lo em um simulador (executar passo a passo, observar o valor das variáveis).
Um robô móvel utiliza um sensor de ultrassom frontal (faixa útil: 2,0 cm a 400,0 cm) e deve parar e virar se detectar um obstáculo a menos de 20,0 cm. Projete uma matriz…
Um robô móvel utiliza um sensor de ultrassom frontal (faixa útil: 2,0 cm a 400,0 cm) e deve parar e virar se detectar um obstáculo a menos de 20,0 cm. Projete uma matriz de testes para verificar o código no simulador antes de transferi-lo para o robô real. Seu plano deve conter pelo menos 4 casos de teste distintos que incluam valores de fronteira e anomalias de leitura. Para cada caso você deve indicar: valor numérico simulado de entrada, comportamento esperado dos motores e justificativa técnica de por que é imprescindível verificar esse caso concreto.
Um robô rastreador para de forma errática depois de funcionar corretamente por cerca de cinco minutos. Para diagnosticar a falha, ativa-se o registro pela porta serial…
Um robô rastreador para de forma errática depois de funcionar corretamente por cerca de cinco minutos. Para diagnosticar a falha, ativa-se o registro pela porta serial (log) e extraem-se estas linhas-chave antes da parada:
-
t = 295,0 s | Distância: 35,0 cm | Temp_driver: 50,0 °C | Vbateria: 7,4 V | Estado: AVANÇAR
-
t = 298,5 s | Distância: 34,0 cm | Temp_driver: 78,0 °C | Vbateria: 7,2 V | Estado: AVANÇAR
-
t = 300,0 s | Distância: 35,0 cm | Temp_driver: 92,0 °C | Vbateria: 6,1 V | Estado: PARADA_EMERGÊNCIA
- a) Interprete os dados do registro para determinar a causa física da falha, refutando o relatório inicial da equipe, que afirmava que a falha se devia a um defeito do sensor de ultrassom.
- b) Projete quais variáveis adicionais ou condições de alerta precoce você incluiria no registro e no código de controle para gerenciar esse problema de forma progressiva, sem chegar ao desligamento abrupto.
Voltando ao começo: se a equipe tivesse simulado o programa antes, com casos normais, limite e de erro, o robô não teria batido na parede nem queimado o componente.