Tier 2a Option 2: Calculation of Threshold Values with the maximum permissible

Uma característica do Carina Parking é que ele usa pacotes da pilha de navegação do ROS, de modo que, quase todo o código-fonte (7 processos) está incluído do núcleo do ROS. Dessa forma, somente os executáveis encontram-se na máquina em que o sistema está sendo executado. Essa limitação dificultou o teste do Carina Parking, pois, como a abordagem de teste também é estrutural é necessário o acesso ao código-fonte, não somente aos executáveis, para a geração do PSCFG. A solução para esse problema foi acessar os códigos-fonte dos processos que continham somente os executáveis a partir do repositório oficial do ROS4, mesmo local que os desenvolvedores baixam os pacotes para reúso. Em razão dessa particularidade, ficou inviável obter o rastreamento do fluxo de execução por meio de marcações no código sem uma 4 _{https://github.com/ros}

6.2. Estudo de caso exploratório I: Carina Parking 109

ferramenta de suporte ao teste, já que parte do código precisaria ser recompilado e, como essa parte do código reside no middleware, testar esses pacotes se tornou também o teste do código do ROS. Para obter então medidas de cobertura, a solução foi obter o rastro da execução por meio da análise dos logs do sistema com a ajuda de ferramentas integradas ao ROS, como rostopic, rosnode, dentre outras. Os elementos requeridos para os critérios que tratam do envio e recebimento de mensagens foram avaliados dessa forma. Para o critério todas-k-mensagens não foi possível a análise de cobertura, dado que as informações necessárias não são fornecidas pelas ferramentas utilizadas para avaliação da cobertura dos demais critérios.

Outra dificuldade na condução dos testes foi com relação ao oráculo do teste. A identifi- cação do ponto objetivo fornecido pelo usuário e a avaliação da saída obtida quando comparada com a esperada. Apesar das coordenadas do ponto objetivo não serem fornecidas na interface gráfica da Rviz, quando a rota é calculada essa informação fica disponível em uma das telas do sistema, dado utilizado como base para as comparações.

Outro problema é que na interface da Rviz não há as delimitação das vagas do estaciona- mento para que o usuário escolha a vaga objetivo corretamente. Em decorrência dessa limitação o testador precisa inserir várias vezes um ponto objetivo até se certificar de que o ponto objetivo ocupa os limites de apenas uma vaga. Porém, observou-se que quando o sistema é executado, a saída (posição do robô estacionado) não é exatamente a esperada, talvez por uma limitação do planejador ou das dimensões do próprio robô em relação à rota. Considerou-se nos testes a saída esperada satisfatória quando o robô ocupa somente a vaga do estacionamento marcada como ponto objetivo.

Observou-se também com os cenários de teste que o sistema aceita como entrada qualquer sentido para o vetor objetivo fornecido pelo usuário. Como o sistema é para estacionamento, para essa configuração de mapa, seria conveniente limitar o sentido do vetor objetivo apenas para os sentidos existentes nas vagas, esquerda para direita (theta 0) e direita para esquerda (theta 8) a fim de maximizar o espaço do estacionamento. Quatro casos de teste, 24, 25, 26 e 27, testam essa situação com vetores objetivos com sentidos inclinados, porém, em nenhum dos casos o robô estacionou obedecendo o sentido objetivo (Figura15), tendo esses casos de teste revelado falhas.

Dos 27 casos de teste especificados para cobrir os cenários de teste, 18 revelaram falhas. Notou-se que o planejador utilizado neste sistema para calcular a rota não se comporta da melhor forma possível, dadas as características desse ambiente e robô. Ao traçar a rota o algoritmo não considera as dimensões do robô e proximidade de obstáculos. Durante a execução da trajetória, em alguns casos, o robô colide com um obstáculo ou se aproxima de tal forma que ele não consegue continuar o trajeto iniciado. Isso aconteceu para o caso de teste 3, situação ilustrada na Figura16. Acredita-se que esse comportamento do planejador seja atribuído pela vertente do reúso, no qual o planejador foi desenvolvido para traçar rotas para robôs de forma geral e o reúso nesse contexto deveria considerar essa particularidade (dimensões do robô e proximidade de obstáculos) pela criticidade do sistema.

Figura 15 – Execução para o cenário 10, caso de teste 25

Fonte: Elaborada pelo autor.

Figura 16 – Execução para o cenário 3, caso de teste 3

Fonte: Elaborada pelo autor.

Uma situação observada durante os testes com relação aos casos de teste 2, 3 e 4, que testam cenários de navegação do robô com dados de laser desativados ou manipulados, foi que independente dos dados do laser o robô atingiu o objetivo. Isso acontece porque o sistema utiliza

6.2. Estudo de caso exploratório I: Carina Parking 111

dois planejadores: 1) um global, para calcular a rota que o robô deve percorrer do ponto inicial até o ponto objetivo utilizando para isso o mapa do ambiente previamente obtido com informações sobre os obstáculos e; 2) um local, que usa os dados do laser para verificar se há algum obstáculo móvel na trajetória. Então, sem o sensor, o veículo segue a trajetória normalmente utilizando a rota calculada, pois nesse teste não há situações de inserir obstáculos móveis na trajetória do robô.

Outra falha revelada durante a execução dos casos de teste 11, 12, 18, 19, 20, 21 e 25 é que o robô encontra dificuldades para fazer curvas à esquerda. Curvas à direita ele realiza facilmente, mas quando necessário à esquerda raramente ele obtém sucesso, como ilustrado na Figura17, em que ele não continua a trajetória.

Figura 17 – Execução para o cenário 10, caso de teste 24

Fonte: Elaborada pelo autor.

Foram identificadas possibilidades para obtenção de um melhor desempenho do sistema. O processo amcl é usado para a geração do mapa e após a conclusão dessa tarefa o processo continua executando, mesmo sem enviar ou receber dados de outros processos. Um processo em execução consome recursos do sistema e, dessa forma, sua desativação após a geração do mapa poderia melhorar o desempenho total do sistema.

Como conclusão do primeiro estudo, a abordagem de teste tem sua aplicabilidade indicada por ter apresentado um custo viável, considerando sua aplicação por um testador. Além disso, ela foi capaz de revelar a presença de defeitos no sistema em teste.

6.3

Estudo de caso exploratório II: RobAFISApplication